7 XPath Expressions in XForms
XForms uses XPath to address instance data nodes in binding expressions, to express constraints, and to specify calculations. At the time of evaluation, an XPath expression must be syntactically correct. In addition, the namespaces the expression references must be in scope and the functions and variables it references must be defined. If any of these conditions is not satisfied, an exception (4.5.2 The xforms-compute-exception Event) is raised, except for binding expressions, which produce a different exception (4.5.1 The xforms-binding-exception Event).
An XPath implementation can use either [XPath 1.0] or [XPath 2.0] to evaluate these expressions. Many expressions that are likely to be used in XForms are the same in both versions (simple element tests, ancestor and descendant tests, string-based attribute tests, etc.).
Form authors may specify the version of XPath that they require. The attribute xpath-version may be used on the default model to identify the XPath version that must be used to evaluate XPath expressions. Omitting the attribute has the same effect as specifying an xpath-version of 1.0.
The following rules determine how the indicated version and the implementation's actual version interact:
- If the indicated version and the implementation version are the same, then that version is used.
If the indicated version is 1.0 and the implementation uses XPath 2.0 (or later), the expression must be evaluated in XPath 1.0 compatibility mode. If a 2.0 processor encounters an XPath 1.0 expression and it does not support XPath 1.0 compatibility mode an exception (4.5.2 The xforms-compute-exception Event) is raised, except for binding expressions, which produce a different exception (4.5.1 The xforms-binding-exception Event)
Otherwise: If the processor encounters an xpath-version that it does not support an exception (4.5.2 The xforms-compute-exception Event) is raised, except for binding expressions, which produce a different exception (4.5.1 The xforms-binding-exception Event)
7.2 Evaluation Context
The static contextXP of an XPath expression appearing in a form is initialized as follows. In these rules, the term containing element means the element within the form that is the parent of the attribute whose value contains the XPath expression in question.
XForms processor that uses an [XPath 1.0] implementation
The statically known namespacesXP are the namespace declarations that are in scope for the containing element.
The default element/type namespaceXP is the null namespace.
No in-scope variablesXP are available.
The function signaturesXP are the core functions defined in [XPath 1.0], the additional functions defined in this specification, the custom functions defined in the Form, plus any extension functions bound using implementation-defined mechanisms.
The base URIXP is the base URI of the containing element.
XForms processor that uses an [XPath 2.0] implementation
- XPath 1.0 compatibility mode is set to true if and only if the indicated XPath version on the model is 1.0 or omitted
The statically known namespacesXP are the namespace declarations that are in scope for the containing element.
The default element/type namespaceXP is the null namespace.
The default function namespaceXP is the standard function namespace, defined in [Functions and Operators]. This means that it is not necessary to declare this namespace in the form, nor is it necessary to use the prefix fn (or any other prefix) in calls to the core functions.
The in-scope schema definitionsXP for the XPath expression are as specified in 5 Datatypes.
No in-scope variablesXP are available.
The function signaturesXP are the core functions defined in [Functions and Operators], the constructor functions for all the atomic types in the in-scope schema definitionsXP, the additional functions defined in this specification, the custom functions defined in the Form, plus any extension functions bound using implementation-defined mechanisms.
The statically known collationsXP are implementation-defined. However, the set of in-scope collations must always include the Unicode codepoint collation, defined in Section 7.3 Equality and Comparison of StringsFO.
The default collationXP is Unicode code point collation..
The base URIXP is the base URI of the containing element.
For convenience, the dynamic context is described in two parts: the focus, which represents the place in the source document that is currently being processed, and a collection of additional context variables.
[copy from XF11 spec]
No dynamic variablesXP are available.
- The current date and time represents an implementation-dependent point in time during processing of an expression.
The implicit timezoneXP is implementation-defined.
The available documentsXP, and the available collectionsXP are implementation-defined.
7.5 The XForms Function Library
The XForms Function Library defines additional functions that are useful for creating forms. The functions will be made available in the XForms namespace.
Note: An implementation may choose to make these additional function also available in the default function namespace if he has a good reason for it (e.g.: Backwards compatibility).
The following sections define additional required functions for use within XForms : 7.6 Boolean Functions, 7.7 Number Functions, 7.8 String Functions, 7.9 Date and Time Functions, 7.10 Node-set Functions , and 7.11 Object Functions.
The function library provided by an XForms processor may also contain other extension functions as described in 7.12 Extension Functions.
If an error occurs in an XPath function, then an 4.5.2 The xforms-compute-exception Event or 4.5.1 The xforms-binding-exception Event occurs.
The arguments and return types of the XForms functions will be specified as XML Schema Built-in datatype and sequences of those.
The following rules should be used to convert the XML Schema Built-in datatypes to [XPath 1.0] types:
- xs:float, xs:double, xs:decimal and types derived from xs:decimal will be represented as a number
- xs:boolean will be represented as a boolean
- all other XML Schema Built-in datatypes will be represented as a string
Sequences will be be represented as node sets. By consequence the empty sequence will be represented as the empty nodeset
XForms functions:
XForms 1.1 definition |
XForms 1.2 definition |
boolean boolean-from-string(string) |
xs:boolean boolean-from-string(xs:string) |
boolean is-card-number(string?) |
xs:boolean is-card-number(xs:string?) |
number avg(node-set) |
numeric avg(xs:anyAtomicType*) |
number min(node-set) |
numeric min(xs:anyAtomicType*) |
number max(node-set) |
numeric max(xs:anyAtomicType*) |
number count-non-empty(node-set) |
xs:integer count-non-empty(node()*) |
number index(string) |
xs:integer index(xs:string) |
number power(number, number) |
numeric power(numeric, numeric) |
number random(boolean?) |
numeric random(xs:boolean?) |
number compare(string, string) |
xs:integer compare(xs:string, xs:string) |
string if(boolean, string, string) |
|
string property(string) |
xs:string property(xs:string) |
string digest(string, string, string?) |
xs:string digest(xs:string, xs:string, xs:string?) |
string hmac(string, string, string?) |
xs:string hmac(xs:string, xs:string, xs:string?) |
string local-date() |
xs:date local-date() |
string local-dateTime() |
xs:dateTime local-dateTime() |
string now() |
xs:string now() |
number days-from-date(string) |
xs:integer days-from-date(xs:string) |
string days-to-date(number) |
xs:date days-to-date(numeric) |
number seconds-from-dateTime(string) |
xs:integer seconds-from-dateTime(xs:string) |
string seconds-to-dateTime(number) |
xs:string seconds-to-dateTime(numeric) |
string adjust-dateTime-to-timezone(string) |
xs:dateTime adjust-dateTime-to-timezone(xs:dateTime) (requires xs:dateTime constructor to convert xs:string to xs:dateTime in form) |
number seconds(string) |
xs:integer seconds(xs:string) |
number months(string) |
xs:integer months(xs:string) |
node-set instance(string?) |
node() instance(xs:string?) |
node-set current() |
item() current() |
node-set id(object, node-set?) |
element()* id(xs:string*, node()*) |
|
element()* id(element()*, node()*) |
node-set context() |
item() context() |
object choose(boolean, object, object) |
item()* choose(xs:boolean, item()*, item()*) |
object event(string) |
item()* event(xs:string) |
Pending questions
Sequences
XPath 2.0 has the notion of sequences. A sequence is an ordered collection of zero or more items. An item is either an atomic value or a node. An atomic value is a value in the value space of an atomic type, as defined in [XML Schema]. (note a nodeset of XPath 1.0 doesn't allows you to change the order of the nodes in the set, they are always in document order, as the term set hints of course)
In XForms we have the nodeset attribute, which can be used on for example binds, repeats, insert and delete actions. For some of these concepts supporting sequences containing atomic values would be neat. Allowing sequences that contain atomic values on the nodeset attribute of a repeat increases the power of what can be done with repeats without requiring the implementer doing something besides using an XPath 2.0 implementation. On the other hand allowing sequences with atomic values on bind can be nearly impossible to implement in some implementations (and the usefulness of this feature is in my opinion less than the trouble to implement it). Some spec changes are also necessary for the insert and delete to cope with sequences containing atomic values.
I think we should decide as a group where we want to support sequences containing atomic values before I start to make changes all over the XForms spec. (Note: This is not a problem introduced by supporting XPath 2.0 in XPath 1.0 you could already have number(/my/path) which resulted in a number, we could decide to only support sequences of type node()*)
We could introduce an extra attribute items on xf:repeat that accepts sequences of nodes and or atomic values. * We decided to use select should also be available on xf:output
Conflicting functions in XForms 1.1 vs XPath 2.0
There aren't that many conflicting functions, the one I found are sum, avg, min and max. These functions return NaN in XForms if the result can't be computed. In XPath 2.0 an empty sequence is returned if an empty sequence is provided as argument, in all other cases were the result couldn't be computed a type error is raised.