You are reading O'Reilly XForms Essentials by Micah Dubinko. (What is this?) - Buy XForms Essentials Online

Computed Expressions
Prev Chapter 3. XPath in XForms Next

Computed Expressions

The preceding section discussed how addressing works in XPath. The language is also capable of performing simple computations that return strings, booleans, or numbers. XForms defines the term Computed Expression to represent this special usage of XPath.

Datatypes in XPath and XForms

The term datatype can get a little confusing during discussions on XForms, since both XPath and XML Schema contain the notion of a datatype—and the two don't always agree on the details.

XPath expressions have four major datatypes: node-sets, strings, booleans, and numbers. (Note that only the expressions contain the notion of datatypes, and the Data Model itself is datatype free, although early drafts of XPath 2.0 appear to change this) Of these, string and boolean are similar to the XML Schema datatypes of the same name, although XML Schema booleans differ in that they allow both "1" and "true" for true, and "0" and "false" for false. Because of this, hacky workarounds are sometimes needed, as described later. The number datatype in XPath represents a double-precision floating point number under the rules defined by the IEEE (which includes positive and negative infinity, positive and negative zero, and a special 'not a number' value), and is thus comparable with the XML Schema datatype double. Node-sets do not have a convenient analog in XML Schema.

One other convention you might run into in the XPath specification is a datatype called "object", which simply means 'any datatype'. The XPath function descriptions below use this same convention.

It's unusual to run into type conflicts in XPath, mainly because the flexible type conversion rules, which are defined below as the functions string( ), number( ), and boolean( ), tend to stay out of your way. In short, nearly any time a specific datatype is expected, a different datatype will get automatically converted into the expected datatype. For example, the expression "a/b * a/c" might seem to multiply two node-sets, at first glance. This works as expected, however, since the multiplication operator first converts each node-set into a number, then multiplies to arrive at a result (just as if the expression had been "number(a/b) * number(a/c)"). Operators and function parameters in XPath behave this way, which avoids a lot of pain for those who need to write XPath expressions.

XPath includes all the arithmetic basics: plus, minus, multiply, divide, modulus, and unary minus (which negates the single operand). All of these operators convert their operands into numbers if needed, as with a call to number( ).

Order of Precedence

Any time an expression uses more than one operator, it is necessary to know what precedence is used. For XPath, this is (lowest to highest, with semicolons as separators where necessary):

  1. or

  1. and

  1. =; !=

  1. <=; <; >=; >

  1. +; -

  1. *; div; mod; unary -

  1. | (union)

Operators at the same precedence level are always evaluated left-to-right. Parentheses can be used to force the expression to evaluate in a different order than the default.

Comparing whether one thing is the same as another or not is straightforward, though some of the type combinations get interesting.

When comparing two node-sets, the comparison looks at the individual nodes. If any node in the left-hand node-set has a string-value that meets the equals or not-equals comparison with the string-value of any node in the right-hand node-set, the overall comparison succeeds. Similarly, if one side is a node-set and the other side is either a string or a number, the comparison will succeed if any node in the node-set meets the comparison. In comparing a boolean and any other datatype, the other datatype is converted as with a call to boolean( ) before comparison. Otherwise, if at least one object to be compared is a number, then the other object is converted as with a call to number( ) before comparison. Finally, comparisons between the same datatypes for strings, numbers, and booleans can be done directly.

The rules for relational comparisons follow the same rules as above when at least one operand is a node-set. In all other cases, both operands are converted if necessary into a number, as with a call to number( ) before comparison.

Boolean expressions can be connected together with logical or and and operators. (Note that not( ) is available also, but as a function, not an operator)

A final operator performs a union operation on a node-set. Note that the resulting node-set (like all node-sets) will contain no duplicate nodes.

XPath defines a number of built-in functions, and XForms adds a few more. This section lists every built-in function. Note that even though function parameters are unnamed in XPath, the descriptions below include parameter names for descriptive purposes.

The XPath specification itself is silent on the issue of implementation-specific or "extension" functions. XSLT, on the other hand, defines a framework in which extension functions can be used. Similarly, XForms provides a general outline of how extension functions fit in.

Extension functions are easily recognizable since all built-in functions are unprefixed names, while all extension functions contain a leading prefix and a colon character. A group of volunteers at the web site http://www.exslt.org/ collect and maintain a number of extension functions that are suitable for use in XForms.

The main disadvantage of extension functions is non-portability. Since these functions are implementation-specific, any form that uses them will only work inside implementations that also support the functions used. To make this explicit, any form that uses extension functions should list the QNames of the functions in the functions attribute of the model element. For example, a form that needed a few more date and time functions from the EXSLT library would use the following declaration: 

<xforms:model xmlns:exslt="http://exslt.org/dates-and-times"
functions="exslt:leap-year exslt:month-name exslt:day-name">
...

Upon initialization, the XForms Processor will check to make sure that all the listed functions are available and immediately signal an error if they are not. For this reason, only functions that are absolutely necessary to the proper functioning of the form should be listed here. On the other hand, failing to list a function here will likely cause a run-time XPath error in some implementations, such as when the user is filling out the form and gets to the point where the XPath engine will try (and fail) to locate the extension function.

Prev Up Next
Location Paths Home position( )