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.
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( ).
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.
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.