Copyright ©2000 eBusiness Technologies, Inc. Distribution policies are governed by the W3C intellectual property terms
In many applications of XML, there is a requirement for using XML in conjunction with a scripting language. Many times, this results in a scripting language such as JavaScript being bound within the XML content (like the <script> tag). XEXPR is a scripting language that uses XML as its primary syntax, making it easily embeddable in an XML document. In addition, XEXPR takes a functional approach, and hence maps well onto the syntax of XML.
This document is one component of a submission request to the World Wide Web Consortium from eBusiness Technologies, Inc. (see Submission Request, W3C Staff Comment). For a full list of all acknowledged Submissions, please see Acknowledged Submissions to W3C.
This document is a Note made available by W3C for discussion only. This work does not imply endorsement by, or the consensus of the W3C membership, nor that W3C has, is, or will be allocating any resources to the issues addressed by the Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.
This document is submitted to the W3C in the hope that it will serve an educational and advisory role for future efforts. It is hoped that future effort requiring an XML-based syntax for expressions will use XEXPR.
Should any changes be required to the document, we would expect future versions to be produced by the W3C process. eBT maintains ownership of the XEXPR specification and reserves the right to maintain and evolve the XEXPR specification independently and such independent maintenance and evolution shall be owned by eBT.
A list of current W3C technical documents can be found at the Technical Reports page.
The grammar for the XEPR language - a deliberate pun on SEXPR, is defined below. The grammar cannot be expressed completely in a DTD, because DTDs assume a fixed vocabulary (fixed set of tags), and the XEXPR language allows arbitrary definitions (arbitrary tag definitions) to occur. From a practical perspective this means that a document with arbitrary XEXPRs embedded within it cannot be validated against a DTD unless the DTD is extended to include definitions of all the tags found in the expressions in the document.
This is the grammar defined in pseudo-BNF.
function : '<' id bindings '>' constants '</' id '>'
;
bindings : id "=" "\"" value "\""
: id "=" "\'" value "\'"
;
id : [a-zA-Z\-\.]+
;
value : string
| number
;
constants : constant
| constants constant
;
constant : function
| string
| number
;
number : 0x[0-9A-Fa-f]+
| [0-9]+
| [0-9]+.[0-9]+
| [0-9]+.[0-9]+[+-][eE][0-9]+
;
The language is very close to a typical LISP or combinator-based language where the primary means of programming is through functional composition. The only real exception is the bindings construct.
The bindings construct is designed to make XEXPR somewhat more naturally expressed in XML. It allows attributes to be used as a form of named parameter. In XEPR attributes are a shorthand form of a <define> function. For example, the following two expressions are equivalent.
<email to="authors@ebt.com">hello</email> <email> <define name="to">authors@ebt.com</define> hello </email>
In this case, the <email> function is expecting a value called to to be bound to a value in it's environment, which is what the <define> function does.
Note that <define> is a special case because
<define name="ebt">eBusiness Technologies</define>
cannot be fully decomposed.
Precedence is given to expressions over bindings as the expressions are evaluated as part of the evaluation of the function, and hence override the binding in the environment. For example, the following would print 3, not 2.
<print x="2"><define name="x">3</define><x/></print>
The grammar above is somewhat ambiguous in that the constant construct, when PCDATA is encountered, has ill-defined semantics. For example, the following is ambiguous.
<foo>This is the 0xdeadbeef constant.</foo>
The ambiguity lies in whether there is a single string constant, or multiple constants (strings and numbers). Likewise, how many objects form the constant construct in the following example?
<foo>This is a <constant>constant</constant>.</foo>
In the XEXPR language, PCDATA is fully parsed. This means that in the first example, 3 objects match the constant construct. Shown graphically, the parse tree would look like the following.
Parse tree for "<foo>This is the 0xdeadbeef constant.</foo>"
The second example would be similar, with the <constant> function forming a sub-tree of it's own.
In addition, XEPXR has a notion of insignificant whitespace. In XEXPR, all whitespace following a start tag is ignored, up to the first non-whitespace character. In addition, all whitespace following a non-whitespace character, up to the end tag, is ignored.
<foo> This is a test. </foo>
This example would result in the following parse tree.
Resulting parse tree
Note that the leading and trailing whitespace are not part of the constant.
This of course begs the question of how one defines a string with leading and trailing whitespace. The answer is to use the <string> function.
The <string> function serves two roles. Firstly, it acts as a typical combinatorial constant function. Secondly it acts as a signal to the XEXPR parser to pass on the content verbatim. For example, the following expression
<foo>
<string>
abc
def
</string>
</foo>
will result in the following parse tree
Parse tree using <string>
which is quite different from the parse tree shown earlier.
Note that the content of a <string> function is still PCDATA, so elements will be parsed as elements, causing errors: the content of <string> must be a sequence of characters.
XEXPR allows functions to be defined and invoked in a way somewhat different from both traditional procedural languages and LISP systems. When the <define> function is invoked, the result is a function, in much the same way that lambda works in LISP. The following expressions all result in functions.
<define name="pi">3.14</define> <define name="2pi"> <multiply><pi/>2</multiply> </define> <define name="square" args="x"> <multiply><get>x</get> 2</multiply> </define>
The first returns a function, which returns the numeric constant 3.14. The second returns a function that returns the value of <pi/> multiplied by 2. The last returns a function with a required argument x. If this last one is invoked without arguments, an error will occur. Note that bound arguments such as the above can be accessed either through the <get> function, or directly. The following two definitions are equivalent.
<define name="square" args="x"> <multiply><get>x</get><get name="x"/></multiply> </define> <define name="square" args="x"> <multiply><x/><x/></multiply> </define>
Function invocation is fairly traditional. Essentially, all tags get turned into function calls, and the content into arguments. For example
<email><string>gtn@ebt.com</string></email>
invokes the email function with a single argument. If the function definition requires arguments, the arguments are evaluated and bound to the names of the corresponding argument in the argument list. For example
<square>2</square>
calls the square function defined earlier with the argument (numeric constant 2) bound to the x variable in the environment.
Unbound arguments are evaluated, just as bound arguments are, and hence can have side-effects. For example
<square>2<define name="x">4</define></square>
will not evaluate to 4, but instead 16, because the x variable bound in the environment is given a different value by the define call in the argument list. The set function could just as easily been used.
An XEXPR interpreter is not guaranteed to be safely tail recursive, even though recursion is allowed. As such, it is generally better to use an iterative form rather than a tail recursive form.
The following defines the linear recursive form of factorial. This is simple to code, and easy to understand, but for large numbers, it may cause a stack overflow.
<define name="factorial" args="x">
<if>
<lt><x/>2</lt>
<x/>
<multiply>
<x/>
<factorial><subtract><x/>1</subtract></factorial>
</multiply>
</if>
</define>
The following is the linear iterative form of the same algorithm. While it accomplishes the same thing as the above, it uses far less stack.
<define name="factorial" args="x">
<define name="iterator" args="product counter max">
<if>
<gt><counter/><max/></gt>
<product/>
<iterator>
<multiply><counter/><product/></multiply>
<add><counter/>1</add>
<max/>
</iterator>
</if>
</define>
<iterator>1 1 <x/></iterator>
</define>
This is obviously more complex than the simple recursive form.
This section documents the functions that form elements of the XEXPR language or syntax. These functions typically have side effects.
<define> generates a function with the body given by the value provided, and binds it to the name given. If an args parameter is supplied, the function is required to have enough arguments to bind all the names when it is invoked.
<define> requires a name argument, and may also have an args argument that supplies a list of names for arguments.
A function object is returned.
<define name="pi">3.14</define> <define name="times2" args="x"> <multiply><get name="x"/>2</multiply> </define> <pi/> --> <float>3.14</float> <times2>10</times2> --> <integer>20</integer> <times2> 2 <set name="x">4</set> </times2> --> <integer>8</integer> <times2> 2 <define name="x">5</define> </times2> --> <integer>10</integer>
<print> is a function that prints its evaluated argument list to standard output.
This function takes zero or more expressions as arguments. If the newline attribute has the value true, a newline will also be printed.
<true>
<print><add>2 2</add></print> <print>Hello World</print> <print newline="true"/>
<println> is a function that prints a new line to standard output.
No arguments are necessary or used.
<true>
<println/>
Get the value of a variable from the environment.
<get> takes a name argument. It will first look in the environment to see if a name variable has been specified. If a name variable does not exist, it uses the first argument as the name. Note that in most cases; <get> is superfluous because the same effect can be accomplished by using a tag with the name of the value.
<get> will return an object. If an object with the given name doesn't exist, <nil/> is returned.
<get name="x"/> <get>x</get> <x/>
<set> binds a name to a value in the current environment. If a variable of the given name is not found in the environment, a new variable is created. Note that the difference between <set> and <define> is that <set> evaluates it's arguments, whereas <define> does not.
<set> takes a name and a value argument. These can be any combination of named and unnamed arguments. <set> looks first for variables bound to those names, and if they don't exist, uses the first two passed arguments.
The value passed is returned.
<set name="x" value="hello"/> --> <string>hello</hello> <set name="x">hello</hello> --> <string>hello</string> <set>hello 123</set> --> <integer>123</integer>
<expr> is a function that acts as a grouping mechanism for expressions. In many ways, it is similar to lambda in LISP.
This function can take an arbitrary list of arguments, which will then comprise the body of the function. If none are supplied, <nil/> is provided as a body.
<expr> returns the evaluated form of the last expression in the function body. If no function body is provided as arguments, the return result is <nil/>.
<expr> <set name="x"gt;3</set> <print><x/></print> </expr>
This function is used to signal early exit from a function. It is provided solely to provide a little syntactic sugar for structuring function definitions.
<return> takes an arbitrary set of expressions as arguments.
<return> returns the evaluated value of the last argument passed to it. If no arguments were supplied, it will return <nil/>.
<define name="foo"> <return>bar</return> </define>
This section documents the constant functions. Constant functions are provided as a way to bind constants to a function. In addition, the content of the constant functions is limited to the valid syntactic structures of the constant type.
<string> is used to mark a given expression as a string. No markup can occur within it. The primary intent of this function is to provide an escape from the normal PCDATA parsing rules of XEXPR.
<string> takes a string as an argument.
This function returns a string constant.
<string>This is #1</string>
The <integer> function evaluates to an integer constant.
This function takes a number as an argument. If the argument is not a number, an exception is thrown.
This function returns an integer constant.
<integer>123</integer>
The <float> function evaluates to a floating point constant.
This function takes an integer or floating point constant as an argument. If the argument is not a number, an exception is thrown.
This function returns a floating point constant.
<float>123</float> <float>123.143</float>
<true/> acts both as a self-evaluating function and a constant. It represents the Boolean truth-value.
No arguments are required or used.
<true/>
<true/>
<false/> acts both as a self-evaluating function and a constant. It represents the Boolean false-value.
No arguments are required or used.
<false/>
<false/>
<nil/> represents an empty expression. It acts both as a function and as a constant. Note that for Boolean tests, <nil/> and <false/> are equivalent, but when compared directly using <eq/> they are considered different objects.
No arguments are required or used.
<nil/>
<nil/>
This section defines the standard arithmetic operators provided by the XEXPR language.
Add a list of arguments together.
<add> takes an arbitrary sequence of expressions. All arguments are fully evaluated.
The return result is dependent upon the first argument supplied. If it is a string, the return result is a string representation of all the arguments concatenated together. If the first argument is numeric, the result is also numeric provided that all arguments are also numeric. It is an error for a leading numeric argument to be followed by anything other than numeric arguments.
<add>1 2 3</add> --> <integer>6</integer> <add>1 2 3.0></add> --> <float>6.0</float> <add>Hello World#<add>2 2</add></add> --> Hello Word#4 <add><set>x 3</set>2</add> --> <integer>5</integer>
Subtract a list of numbers from the initial number. The first value is taken as the starting point and then subsequent numbers are subtracted from it.
<subtract> takes an arbitrary set of expressions as arguments. All arguments are fully evaluated. If any of the evaluated arguments do not result in a numeric constant, an error occurs.
<subtract> returns a numeric constant.
<subtract>10 2 1</subtract> --> <integer>7</integer>
Multiply a list of numbers. The first value is taken as the starting point and it is then multiplied by subsequent arguments.
<multiply> takes an arbitrary set of expressions as arguments. All arguments are fully evaluated. If the evaluated arguments do not result in a numeric constant, and error occurs.
<multiply> returns a numeric constant.
<multipy>10 2 1</multiply> --> <integer>20</integer>
Divide a list of numbers. The first value is taken as the starting point and it is then divided by subsequent arguments.
<divide> takes an arbitrary set of expressions as arguments. All arguments are fully evaluated. If the evaluated arguments do not result in a numeric constant, and error occurs.
<divide> returns a numeric constant.
<divide>20 2 2</divide> --> <integer>5</integer>
This section describes the comparison functions available in the XEXPR language.
Test a sequence of arguments for equality. Equality means that the evaluated values have the same type and the same value, not the same identity.
<eq> takes a sequence of expressions to be tested.
<true/> or <false/>
<eq> <string>A</string> A <set name="x">A</set> </eq> --> <true/> <eq> 1 1 1 <define name="x">1</define> </eq> --> <true/> <eq> <string>A</string> A <define name="x">B</define> </eq> --> <false/> <eq> 1 1 1 <define name="x">2</define> </eq> --> <false/>
Check a sequence of expressions for inequality.
<neq> takes a sequence of expressions to be tested.
<true/> or <false/>
<neq> <string>A</string> B <define name="x">C</define> </neq> --> <true/> <neq> 1 2 3 <define name="x">4</define> </neq> --> <true/> <neq> <string>A</string> B <define name="x">B</define> </neq> --> <false/> <neq> 1 1 2 <define name="x">2</define> </neq> --> <false/>
Evaluate a list of expressions and test if they are sequentially less than or equal to one another. The arguments must all evaluate to the same type of object otherwise <false/> is returned.
<leq> takes a sequence of expressions to be tested.
<true/> or <false/>
<leq> <string>C</string> B <define name="x">B</define> </leq> --> <true/> <leq> 4 3 2 1 <define name="x">1</define> </leq> --> <true/> <leq> <string>C</string> B <define name="x">C</define> </leq> --> <false/> <leq> 4 3 2 1 <define name="x">2</define> </leq> --> <false/>
Evaluate a list of expressions and test if they are sequentially greater than or equal to one another. The arguments must all evaluate to the same type of object otherwise <false/> is returned.
<geq> takes a sequence of expressions to be tested.
<true/> or <false/>
<geq> <string>A</string> B <define name="x">B</define> </geq> --> <true/> <geq> 1 2 3 <define name="x">3</define> </geq> --> <true/> <geq> <string>A</string> B <define name="x">A</define> </geq> --> <false/> <geq> 1 1 2 <define name="x">1</define> </geq> --> <false/>
Evaluate a list of expressions and test if they are sequentially less than one another. The arguments must all evaluate to the same type of object otherwise <false/> is returned.
<lt> takes a sequence of expressions to be tested.
<true/> or <false/>
<lt> <string>A</string> B <define name="x">C</define> </lt> --> <true/> <lt> 1 2 3 <define name="x">4</define> </lt> --> <true/> <lt> <string>A</string> B <define name="x">B</define> </lt> --> <false/> <lt> 1 2 3 <define name="x">3</define> </lt> --> <false/>
Evaluate a list of expressions and test if they are sequentially greater than one another. The arguments must all evaluate to the same type of object otherwise <false/> is returned.
<gt> takes a sequence of expressions to be tested.
<true/> or <false/>
<gt> <string>C</string> B <define name="x">A</define> </gt> --> <true/> <gt> 4 3 2 <define name="x">1</define> </gt> --> <true/> <gt> <string>C</string> B <define name="x">C</define> </gt> --> <false/> <gt> 4 3 2 <define name="x">3</define> </gt> --> <false/>
<and> sequentially evaluates its arguments. If all evaluate to <true/> it returns <true/> otherwise it will return <false/>. Arguments that evaluate to anything other than <true/> result in <false/> being returned, including arguments of anything other than Boolean type. Note that this is a logical, not a bitwise and.
<and> can take an arbitrary list of arguments.
<and> returns <true/> or <false/> depending on the arguments supplied. If no arguments are supplied, <and> returns <true/>.
<and> <true/> <define name="x"><true/></define> </and> --> <true/> <and> <true/> <define name="x"><false/></define> </and> --> <false/>
<or> evaluates its arguments sequentially. If any are <true/> it returns <true/> otherwise <false/>. Note that this is a logical or, not a bitwise or.
<or> can take an arbitrary list of arguments.
<or> returns <true/> or <false/> depending on the arguments supplied. If no arguments are supplied, <or> returns <true/>.
<or> <true/> <define name="x"><true/></define> </or> --> <true/> <or> <true/> <define name="x"><false/></define> </or> --> <true/> <or> <false/> <define name="x"><false/></define> </or> --> </false>
<not> evaluates its arguments sequentially. If any are <false/> it returns <true/> otherwise <false/>. Note that this is a logical not, not a bitwise not.
<not> can take an arbitrary list of arguments.
<not> returns <true/> or <false/> depending on the arguments supplied. If no arguments are supplied, <not> returns <true/>.
<not><true/></not> --> <false/> <not><false/></not> --> <true/> <not><nil/></not> --> <true/> <not>1</not> --> <false/>
<if> represents a conditional branching of program flow.
<if> requires at least 2 arguments to be passed: the test and the expression to evaluate if the test evaluates to <true/>. This is roughly akin to an if-then logic flow. <if> can also take a 3rd argument which is the expression to evaluate if the test evaluates to <false/>, in which case, the if expression is equivalent to an if-then-else statement.
<if> returns the evaluated result of the expression selected by the test. If the test fails and only 2 arguments are supplied, <if> will return <nil/>.
<if>
<eq>1 2</eq>
<expr>
<print>equal</print>
</expr>
<expr>
<print>not equal</print>
</expr>
</if>
<switch> is similar to <if> but represents a multi-way branch.
<switch> requires a list of <case> expressions. Each <case> expression in turn must be made up of a test expression, and an expression to evaluate if the test is evaluated to <true/>.
Each of the tests in the <case> expressions is evaluated in turn. The first test that evaluates to <true/> decides the result of the <switch>, which is the evaluated result of the expression part of the <case> expression. If none evaluate to <true/>, <nil/> is returned.
<define name="test1" args="x">
<switch>
<case>
<eq><x/>1</eq>
1
</case>
<case>
<true/>
2
</case>
</switch>
</define>
<define name="test2" args="x">
<switch>
<case>
<eq><x/>1</eq>
1
</case>
</switch>
</define>
<test1>1</test1> --> <integer>1</integer>
<test1>2</test1> --> <integer>2</integer>
<test2>1</test2> --> <integer>1</integer>
<test2>2</test2> --> <nil/>
This section documents the looping constructs XEXPR provides. Note that in addition to these, linear iterative forms can be used to form loops.
<while> loops over a given expression so long as the supplied test evaluates to <true/></>
<while> takes two arguments. The first is the test expression, the second is the expression to be executed so long as the test evaluates to <true/>.
<while> returns the value of the last evaluated expression.
<while>
<gt><x/> 0</gt>
<expr>
<print newline="true"><x/><print>
<subtract><x/> 1</subtract>
</expr>
</while>
<do> loops over a given expression so long as the supplied test evaluates to <true/>. It will execute the body at least once.
<do> takes two arguments. The first is the body to be executed, the second is the expression to be tested.
<do> returns the value of the last evaluated expression.
<do>
<expr>
<print newline="true"><x/><print>
<subtract><x/> 1</subtract>
</expr>
<gt><x/> 0</gt>
</do>
The namespace URI for XEXPR is
http://www.ebt.com/xexpr
People using this namespace are encouraged to use the xexpr namespace prefix.
The public identifier for XEXPR is
-//EBT//DTD XML Expression Language//EN
<!DOCTYPE xexpr [
<!ENTITY % expression "bind|define|get|set
|expr|add|subtract|multiply
|divide|string|integer|float
|true|false|nil|eq|neq|leq
|geq|lt|gt|and|or|not|if
|switch|do|while|print
|println">
<!ELEMENT xexpr (%expression;)*>
<!ELEMENT bind EMPTY>
<!ATTLIST bind class CDATA #REQUIRED
name CDATA #IMPLIED>
<!ELEMENT define (%expression;)*>
<!ATTLIST define name CDATA #REQUIRED
args CDATA #IMPLIED>
<!ELEMENT get EMPTY>
<!ATTLIST get name CDATA #REQUIRED>
<!ELEMENT set (%expression;)*>
<!ATTLIST set name CDATA #REQUIRED>
<!ELEMENT expr (%expression;)*>
<!ELEMENT add (%expression;)*>
<!ELEMENT subtract (%expression;)*>
<!ELEMENT multiply (%expression;)*>
<!ELEMENT divide (%expression;)*>
<!ELEMENT string (#PCDATA)>
<!ELEMENT integer (#PCDATA)>
<!ELEMENT float (#PCDATA) >
<!ELEMENT true EMPTY>
<!ELEMENT false EMPTY>
<!ELEMENT nil EMPTY>
<!ELEMENT eq (%expression;)*>
<!ELEMENT neq (%expression;)*>
<!ELEMENT leq (%expression;)*>
<!ELEMENT geq (%expression;)*>
<!ELEMENT lt (%expression;)*>
<!ELEMENT gt (%expression;)*>
<!ELEMENT and (%expression;)*>
<!ELEMENT or (%expression;)*>
<!ELEMENT not (%expression;)*>
<!ELEMENT if (%expression;)*>
<!ELEMENT switch (case*) >
<!ELEMENT case (%expression;)*>
<!ELEMENT do (%expression;)*>
<!ELEMENT while (%expression;)*>
<!ELEMENT print (#PCDATA|%expression;)*>
<!ATTLIST print newline (true|false) #IMPLIED>
<!ELEMENT println (#PCDATA|%expression;)*>
]>
The following is a list of recommended reading.