This document is also available in these non-normative formats: diff-marked version .
The English version of this specification is the only normative version. Non-normative translations may also be available.
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document records resolutions of known errors in the XForms 1.0 Second Edition Recommendation: http://www.w3.org/TR/2006/REC-xforms-20060314/
1 Initializing repeat with startindex
1.1 Repeat re-initialization during delete action
(Section 9.3.6)
2 Submission error on empty nodeset
2.1 Default action of xforms-submit event (Section
11.1)
3 Evaluation Context for setindex Action
3.1 Specify evaluation context for index attribute of
setindex (Section 9.3.7)
4 Behavior of setvalue Action
4.1 The setvalue Action Behavior on Empty Single-Node
Binding (Section 10.1.9)
5 Deferred Update of XForms Action Sequences
5.1 Main Description of Deferred Update
5.2 Clarify Deferred Update Behavior within Specific
Action Subsections
5.3 Further Clarify that rebuild, recalculate,
revalidate and refresh Actions Occur Directly
5.4 Clarify that the Instance Replacement of a
Submission Clears Deferred Update Flags
6 Clarify that calculate assigns a string
6.1 Specify that calculate assigns a string value
(Section 6.1.5)
7 The load Element
7.1 Clarify that linking attributes is a reference to
the resource attribute (Section 10.1.8)
7.2 The load Action Behavior on Empty Single-Node
Binding (Section 10.1.8)
8 Align Schema with Recommendation for instance
Attribute
9 Express an ID attribute in Common Attributes
10 Clarify XForms Type Validation
10.1 Type Validation (Section 4.3.5)
10.2 The type Model Item Property Description
(Section 6.1.1)
11 Recalculation Clarification
12 Clarification of Precedence Rule for value Element
13 Clarification of User Interface Creation for message
Action
14 Clarification of Dispatching Events from Model
Construct
15 Clarification of Default Processing of Model Construct Done
Event
16 Access to Default Instance by instance() Function
16.1 The getInstanceDocument() DOM function (Section
7.3.1)
16.2 The instance() XPath function (Section
7.3.1)
17 Binding Expressions and Evaluation Context
17.1 Clarify Single-Node Binding Attributes (Section
3.2.3)
17.2 Specific problem (Section 3.2.4)
17.3 Evaluation Context (Section 7.4)
17.4 Clarify Binding Expression Definition (Section
7.5)
17.5 Clarify Function Library for XPaths (Section
7.6)
18 References
18.1 Normative References from XForms
1.0
When the index of a repeat
is initialized or re-initialized,
the index should be set equal to the value of the startindex
attribute when possible.
The repeat
index re-initialization that occurs during a
delete
action uses 1, not startindex
. Although the
re-initialization is technically part of the repeat
processing
associated with instance node deletion, the current specification wording
appears in the section on the delete
action, specifically at the
end of the third numbered point in the description of the at
attribute.
To re-initialize a repeat means to change the index to 0 if it is empty, otherwise 1.
To re-initialize a repeat index means to change
its value to be equal to startindex
, or to 0
if the homogeneous collection contains less than
startindex
items.
The case of not having a node of data to submit is not handled by submission processing.
The first step of submission event default action processing states that a
node of instance data is selected by the attributes of the
submission
element. This erratum handles the case of those
attributes selecting an empty nodeset.
A node from the instance data is selected, based on attributes on
the submission
element. The indicated node and all nodes
for which it is an ancestor are considered for the remainder of the
submit process. Any node which is considered not relevant as defined in
6.1.4
The relevant Property is removed.
A node from the instance data is selected, based on attributes on
the submission
element. If the attributes of
submission
select an empty nodeset, then submission
processing is stopped after dispatching event
xforms-submit-error
. Otherwise, the indicated node
and all nodes for which it is an ancestor are considered for the
remainder of the submit process. Any node which is considered not
relevant as defined in 6.1.4
The relevant Property is removed.
The evaluation context node for the setindex
action is not
specified.
The evaluation context for the index
attribute of the
setindex
action is specified.
Required XPath expression that evaluates to a 1-based offset into the sequence.
Required XPath expression that evaluates to a 1-based offset into the sequence. The evaluation context is determined in the same manner as the evaluation context for a Single-Node Binding (see 7.4 Evaluation Context).
The recommendation does not directly indicate the behavior of the
setvalue
action when the Single-Node Binding does not select a
node.
The recommendation states that the result of the value
attribute replaces the content of the instance node selected by the
Single-Node Binding. This erratum directly states that the
setvalue
action should perform no operation. This is in accord
with the implications of the current specification since, if no instance node
is selected, then there is nowhere to put the value
result, nor
is there even a context node for evaluating the value
attribute.
This action explicitly sets the value of the specified instance data node.
This action explicitly sets the value of the specified instance data node. This action has no effect if the Single-Node Binding does not select an instance data node.
The automatic rebuild, recalculate, revalidate, refresh behaviors of XForms actions are deferred to the end of execution of an outermost action handler. This erratum recognizes that an action can be outermost relative not only to actions it contains but also actions that it executes by way of dispatching events. This erratum also clarifies the processing of deferred update flags across multiple models and in response to reset actions and instance replacement submissions. It also clarifies that deferred update behaviors are performed by dispatching events to models and that the XForms processor exits the deferred behavior state before these events are dispatched on behalf of an outermost action handler.
Modified Description of Deferred Update and moved it out of Section 10.1.1.
Deferred Updates: Many XForms Actions have a deferred
effect on the instance data when specified as a descendant of an
action
element.
Implementations are free to use any strategy to accomplish deferred
updates, but the end result must be as follows: Instance data changes
performed by a set of actions do not result in immediate computation
dependency rebuilding, recalculation, revalidate and form control
refreshing until the termination of the outermost action handler, as
described here. Each outermost action handler can be thought of as
having a set of Boolean flags, initially false
, to
indicate whether each of the actions rebuild
,
recalculate
, revalidate
, and
refresh
are required upon termination of the outer action
handler.
Actions that directly invoke rebuild, recalculate, revalidate, or refresh always have an immediate effect, and clear the corresponding flag. The XForms Actions in this category are:
rebuild
recalculate
revalidate
refresh
XForms Actions that change the tree structure of instance data
result in setting all four flags to true
. The XForms
Actions in this category are:
insert
delete
XForms Actions that change only the value of an instance node
results in setting the flags for recalculate
,
revalidate
, and refresh
to true
and making no change to the flag for rebuild
. The XForms
Actions in this category are:
setvalue
Finally, the reset
action takes effect immediately and
clears all of the flags.
An outermost action handler is an action that is activated when the XForms processor is not executing any other action handlers.
An inner action handler is an action that is activated when the XForms processor is executing the declared actions of an outermost action handler. An inner action handler may be within the content of the outermost action handler, or it may be executed as the response to an event dispatched while performing all of the actions initiated by the outermost action handler.
Deferred Updates: Sequences
of one or more XForms Actions have a deferred effect on
XForms model and user interface processing .
Implementations are free to use any strategy to accomplish deferred
updates, but the end result must be as follows: Instance data changes
performed by a set of actions do not result in immediate computation
dependency rebuilding, recalculation, revalidate and form control
refreshing until the termination of the outermost action handler, as
described here. Each XForms model can be thought of as
having a set of deferred update Boolean flags, initially
false
at the start of an outermost action handler, to
indicate whether each of the actions rebuild
,
recalculate
, revalidate
, and
refresh
are required for that model upon
termination of the outermost action handler.
Execution of an outermost action handler begins by
setting the XForms processor into the state of executing an outermost action handler. The outermost action handler
is then performed, which may include the execution of inner action handlers. Finally, the
XForms processor is set into the state of not executing an outermost action handler and then
the deferred update is performed for each model. The deferred update
behavior for a model consists of examining each deferred update Boolean
flag in the order of rebuild
, recalculate
,
revalidate
, and refresh
, and for each
true
flag, set the flag to false
and then
dispatch the proper event to the model for that deferred update flag
(i.e. dispatch xforms-rebuild
for a true
rebuild
flag, xforms-recalculate
for a true
recalculate
flag, xforms-revalidate
for a
true revalidate
flag, and xforms-refresh
for
a true refresh
flag).
Note:
The XForms processor is not considered to be executing an outermost action handler at the time that it performs deferred update behavior for XForms models. Therefore, event handlers for events dispatched to the user interface during the deferred refresh behavior are considered to be new outermost action handler.
Actions that directly invoke rebuild, recalculate, revalidate, or refresh always have an immediate effect, and clear the corresponding deferred update flag. The XForms Actions in this category are:
rebuild
recalculate
revalidate
refresh
XForms Actions that change the tree structure of instance data
result in setting all four deferred update flags to
true
for the model over which they operate.
The XForms Actions in this category are:
insert
delete
XForms Actions that change only the value of an instance node
results in setting the deferred update flags for
recalculate
, revalidate
, and
refresh
to true
and making no change to the
deferred update flag for rebuild
for
the model over which they operate. The XForms Actions in this
category are:
setvalue
Finally, the reset
action clears all of the
deferred update flags for a model.
Similarly, if the default processing of
xforms-submit
replaces instance data in a model, then the
deferred update flags for that model are cleared immediately before the
behaviors are peformed for xforms-rebuild
,
xforms-recalculate
, xforms-revalidate
, and
xforms-refresh
.
The links to deferred update behavior in several subsections describing actions appeared within text that did not reflect the updated definition of outermost action.
If this action is contained within an action
element,
it has special deferred update behavior (10.1.1 The action
Element).
This action has special deferred update behavior .
Due to the prior wording of the deferred update behavior, the meaning of the phrase "bypassing the normal event flow" was not clear.
bypassing the normal event flow.
bypassing the normal event flow (i.e. the behavior occurs
without dispatching the xforms-rebuild
event).
bypassing the normal event flow.
bypassing the normal event flow (i.e. the behavior occurs
without dispatching the xforms-recalculate
event).
bypassing the normal event flow.
bypassing the normal event flow (i.e. the behavior occurs
without dispatching the xforms-revalidate
event).
bypassing the normal event flow.
bypassing the normal event flow (i.e. the behavior occurs
without dispatching the xforms-refresh
event).
Successful instance replacement by the default processing of
xforms-submit
is followed by performing the behaviors of
rebuild, recalculate, revalidate and refresh. This correction clarifies the
fact that the deferred update flags for the affected model are cleared
immediately before performing the behaviors.
Once the XML instance data has been replaced, the rebuild,
recalculate, revalidate and refresh operations are performed on the
model, without dispatching events to invoke those four operations.
Submit processing then concludes after dispatching
xforms-submit-done
.
Once the XML instance data has been replaced, the rebuild,
recalculate, revalidate and refresh operations are performed on the
model, without dispatching events to invoke those four operations.
This operation is associated with special deferred update behavior.
Submit processing then concludes after dispatching
xforms-submit-done
.
The calculate
model item property cannot be used to assign an
XML subtree as new content for the associated instance data node.
Clarify that string() is applied to the result of a calculate
expression.
Description: supplies an expression used to calculate the value of the associated instance data node.
Description: supplies an expression used to calculate a string value for the associated instance data node.
An XForms Model may include model items that are computed from other values.
An XForms Model may include model items whose string values are computed from other values.
Such computed values can be expressed with
calculate
properties, whose XPath expressions are
evaluated and converted to strings with the XPath string()
function.
The load
action does not describe what to do if the
single-node binding does not resolve to a node. It also uses the term linking
attributes to refer to the resource
attribute.
Modify description of load
action behavior to refer
specifically to the resource
attribute rather than linking
attributes.
Either the Single-Node Binding attributes, pointing to a URI in the instance data, or the linking attributes are required.
Either the Single-Node Binding attributes, pointing to a URI in
the instance data, or the resource
attribute is
required.
The load
action performs no operation when the Single-Node
Binding produces an empty nodeset result.
If both are present, the action has no effect.
If both the Single-Node Binding and the
resource
attribute are present, the action has no
effect. This action has no effect if the Single-Node Binding is
present and does not select an instance data node.
The instance
attribute of the submission
element
must appear in the schema for the element.
submission
:<xsd:attribute name="instance" type="xsd:IDREF" use="optional"/>
This erratum alters the means by which XForms imposes the requirement to have ID mechanism to support processing of the many XForms elements containing attributes of type IDREF. This is achieved by placing an optional local attribute of type ID in the Common Attributes bundle so that all XForms elements may be identified. Host languages may still also provide a global attribute of type ID or support xml:id (or both).
A host language must permit an attribute of type
xsd:ID
on each XForms element.
The optional id
attribute of type
xsd:ID
assigns an identity to the containing
element.
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
The descriptions of node validation and of the type
model
item property are clarified.
The intent of the wording is to say that the node must satisfy any Schema definitions applied to or associated with the node. The current wording could be read as saying the node is valid if the node satisfies any one of the schema definitions.
the node satisfies any applicable XML schema definitions (including those associated by the type model item property)
the node satisfies all applicable XML schema
definitions (including those associated by the type
model
item property , by an external or an inline schema, or by
xsi:type
)
This erratum clarifies that the type
model item property
associates type information with a node by providing information related to
the validation of its content. It also clarifies that the type
model item property is not used for complex content validation.
An element with simple content but an attribute is technically a complex
type. The type
model item property can be used to associate with
the node a simple type or a complex type with simple content. The first
assignment is legal since only the node content is validated according to the
simple type. The second assignment is legal since only the underlying simple
type of the simple content is used to validate the node content. In both
cases, the attribute is not validated by the association. A separate
type
model item property could be used to associate a type with
the attribute node directly.
Description: associates a Schema datatype.
Computed Expression: No.
Legal Values: Any xsd:QName
representing a datatype
definition in an XML Schema.
Default Value: xsd:string
.
Inheritance Rules: does not inherit.
The effect of this model item property is the same as placing
attribute xsi:type
on the instance data. However, in
contrast to xsi:type
, type
can be added to
both elements and attributes.
<instance> <my:person-name> <my:first-name /> <my:last-name xsi:type="my:nonEmptyString" /> </my:person-name> </instance> <bind type="my:nonEmptyString" nodeset="/my:person-name/my:first-name" />
Here, we have illustrated two ways in which an XML Schema type can be associated with an element.
Description: The type model item property can be applied to
both elements and attributes. The type model item property is not
applied to instance nodes that contain child elements. The type model
item property associates a datatype (as defined in [XML Schema part 2]) with the string-value
(as defined in [XPath 1.0]) of an instance
node. The datatype being associated can be obtained from a simpleType
definition or a simpleContent definition from a complexType. If the
datatype cannot be obtained as just described, then the Default Value
of xsd:string
is used.
Computed Expression: No.
Legal Values: Any xsd:QName
representing a datatype
definition in an XML Schema.
Default Value: xsd:string
.
Inheritance Rules: does not inherit.
<model xmlns:my="http://example.org"> <xsd:schema targetNamespace="http://example.org" xmlns:my="http://example.org"> <xsd:simpleType name="Currency"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="USD"/> <xsd:enumeration value="EUR"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="Price"> <xsd:simpleContent> <xsd:extension base="xsd:double"> <xsd:attribute name="currency" type="my:Currency" use="optional" default="USD"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:schema> <instance> <data xmlns="http://example.org"> <aString>Hello, world!</aString> <simpleType> <price>100.00</price> <price>abc</price> <price currency="EUR">100.00</price> <price currency="EUR">abc</price> </simpleType> <complexType> <price>100.00</price> <price>abc</price> <price currency="abc">100.00</price> <price currency="EUR">abc</price> </complexType> </data> </instance> <bind nodeset="my:aString" type="xsd:string"/> <bind nodeset="my:simpleType/my:price" type="xsd:double"/> <bind nodeset="my:complexType/my:price" type="my:Price"/> <bind nodeset="my:complexType/my:price[3]/@currency" type="my:Currency"/> <bind nodeset="/my:data" type="xsd:string"/> </model>
The first bind expresses the default datatype of xsd:string.
The second and third binds place type model item properties on each
of the four price
element children of the elements
simpleType
and complexType
. Both binds
associate the datatype xsd:double
with the nodes. In both
cases, the first and third nodes are considered valid according to the
type model item property because their content matches the
xsd:double
datatype constraint. For both binds, the second
and fourth price
nodes are not valid due to their
content.
The fourth bind places a type model item property on the
currency
attribute of the third price
element. According to this association, the currency
attribute node is not valid because its content does not match the
enumeration given for my:Currency
. Note that the
containing element price
is valid according to its type
model item property.
The fifth bind attempts to associate a datatype with the
data
element. The association is ignored since the
data
element contains child elements.
The recalculation after a rebuild is intended to re-evaluate the
calculate
expressions of all calculated instance values, not
just those expressions that depend on some node of instance data. The current
wording of the algorithm in Appendix D makes this clear, but one aspect of
the wording in the xforms-recalculate event processing does not.
When a recalculation event begins, there will be a list L of one or more instance nodes whose values have been changed, e.g., by user input being propagated to the instance.
An XForms Processor should not recalculate computes that are not computationally dependent on one or more of the elements in L.
An XForms Processor should perform only a single recalculation of each compute that is computationally dependent on one or more of the elements in L.
An XForms Processor must recalculate a compute C after recalculating all computes of instance nodes on which C is computationally dependent. (Equivalently, an XForms Processor must recalculate a compute C before recalculating any compute that is computationally dependent on the instance node associated with C.)
When a recalculation event begins, there will be a list L of one or more instance nodes whose values may have been changed, e.g., by user input being propagated to the instance.
An XForms Processor must recalculate computes for nodes in L and nodes that are computationally dependent on nodes in L.
An XForms Processor must perform only a single recalculation of each compute that is computationally dependent on one or more of the elements in L.
An XForms Processor must recalculate a compute C after recalculating all computes of instance nodes on which C is computationally dependent. (Equivalently, an XForms Processor must recalculate a compute C before recalculating any compute that is computationally dependent on the instance node associated with C.)
The specification refers to the ref
attribute rather than to
the term Single Node Binding.
If inline content and a ref
attribute are both
specified, the ref
attribute is used.
If inline content and a Single Node Binding are both specified, the Single Node Binding is used.
The message
action must be able to show the current instance
data, even if the message content is constructed with output
controls.
A graphical browser might render a modal message as follows:
<model> <message level="modal" ev:event="xforms-ready">This is not a drill!</message> ... </model>
...
The user interface for the message
action is
considered to be created at the time the action occurs. If the message
is obtained from the inline content of the message
action,
then the output of any output
controls in the
message
content is determined based on the instance data
available when the message
action occurs. For example, the
following example displays the message Hello, world!
:
<model> <instance xmlns=""> <data> <name>John</name> </data> </instance> <action ev:event="xforms-ready"> <setvalue ref="name">world</setvalue> <message level="modal">Hello, <output ref="name"/>!</message> ...</action> </model>
In this example, the message includes the latest user input even
though other form controls not in the message
action are
not guaranteed to be updated until the end of the
xforms-refresh
event processing:
<input ref="birthday"> <label>Enter birthday:</label> <message ev:event="xforms-invalid"><output ref="."/> isn't a valid birthday</message> </input>
Note:
Due to deferred update behavior, if a message
action is
preceded in an action sequence by other actions that change instance
nodes, and the message references nodes that are computationally
dependent on the changed nodes, then the form author should invoke the
recalculate
action before the message
action.
A graphical browser might render a modal message as follows:
<model> <message level="modal" ev:event="xforms-ready">This is not a drill!</message> ... </model>
...
The specification refers performing xforms-rebuild, xforms-recalculate and xforms-revalidate during xforms-model-construct, by it means dispatch the events corresponding to those names.
Perform an xforms-rebuild
,
xforms-recalculate
, and xforms-revalidate
in
sequence, for this model
element. (The
xforms-refresh
is not performed since the user interface
has not yet been initialized).
Dispatch xforms-rebuild
,
xforms-recalculate
, and xforms-revalidate
in
sequence to this model
element. (The
xforms-refresh
is not dispatched since the
user interface has not yet been initialized).
In Section
4.2.1, the XForms processor is tasked with dispatching an
xforms-model-construct-done
to each model
after all
models have been initialized. Similarly, according to the last sentence of Section
4.2.2, the XForms processor must dispatch an xforms-ready
event to each model
after all
xforms-model-construct-done
events have been completed. However,
the sentence which says this is confused with the description of the default
processing for the xforms-model-construct-done
due to
positioning in the text and due to the fact that the default processing for
the first xforms-model-construct-done
initializes all form
controls regardless of the model to which they bind. Confusing the dispatch
of xforms-ready
events with the default processing of the first
xforms-model-construct-done
would cause non-default models to
receive xforms-ready
before
xforms-model-construct-done
, which is incorrect.
After all form controls have been initialized, an
xforms-ready
event is dispatched to each
model
element.
The above steps comprise the default processing of
xforms-model-construct-done
.
After all form controls have been initialized and all
xforms-model-construct-done
events have been
processed, an xforms-ready
event is dispatched to
each model
element.
The argument to the instance()
function is supposed to be
optional, not required, to allow access to the default instance without
mandating the assignment of an identifier. This is also key to being able to
perform calculations on data in non-default instances using data in the
default instance without having to place an identifier on the default
instance.
The getInstanceDocument()
function available to DOM
implementations provides this correction by allowing the empty string to
refer to the default instance.
This method returns a DOM Document that corresponds to the
instance data associated with the instance
element
containing an ID
matching the instance-id
parameter. If there is no matching instance data, a
DOMException
is thrown.
If the instance-id
parameter is the empty
string, then the document element of the default instance is returned.
Otherwise, this method returns a DOM Document that corresponds
to the instance data associated with the instance
element
containing an ID
matching the instance-id
parameter. If there is no matching instance data, a
DOMException
is thrown.
The instance()
function available to XPath provides this
correction by allowing the argument to be optional and by responding to empty
string, both of which result in returning the default instance's document
element.
node-set instance(string?)
An XForms Model can contain more that one instance. This function allows access to instance data, within the same XForms Model, but outside the instance data containing the context node.
The argument is converted to a string as if by a call to the
string
function. This string is treated as an IDREF, which
is matched against instance
elements in the containing
document. If a match is located, and the matching instance data is
associated with the same XForms Model as the current context node, this
function returns a node-set containing just the root element node (also
called the document element node) of the referenced instance data. In
all other cases, an empty node-set is returned.
node-set instance(string?)
An XForms Model can contain more that one instance. This function allows access to instance data, within the same XForms Model, but outside the instance data containing the context node.
If the argument is omitted or is equal to the empty string, then the root element node (also called the document element node) is returned for the default instance in the model that contains the current context node.
Otherwise, the argument is converted to a string as if
by a call to the string
function. This string is treated
as an IDREF, which is matched against instance
elements in
the containing document. If a match is located, and the matching
instance data is associated with the same XForms Model as the current
context node, this function returns a node-set containing just the root
element node (also called the document element node) of the referenced
instance data. In all other cases, an empty node-set is returned.
The meaning and evaluation context of binding expressions and binding expression attributes are clarified.
The original text implies that a Single-Node Binding attribute can only be
used to bind a form control or action to a node, which is the usual case but
not the entirety of cases. For example, the ref
attribute can
appear on a submission
element, and when it does, the rules for
determining its in-scope evaluation context and for evaluating it are
consistent with the rules used when the ref
attribute appears on
form controls or actions.
The following attributes define a binding between a form control or an action and an instance data node defined by an XPath expression.
The following attributes define a binding between an XForms element such as a form control or an action and an instance data node defined by an XPath expression.
The original text implies that a Node-Set Binding attribute can only be
used to bind a form control or action to a node, which is the usual case but
not the entirety of cases. For example, the nodeset
attribute
can appear on a bind
element, and when it does, the rules for
determining its in-scope evaluation context and for evaluating it are
consistent with the rules used when the nodeset
attribute
appears on a repeat
element or the insert
or
delete
actions.
The following attributes define a binding between a form control or an action and a node-set defined by the XPath expression.
The following attributes define a binding between an XForms element such as a form control or an action and a node-set defined by the XPath expression.
Clarify the calculation of evaluation context, especially for generated content.
Within XForms, XPath expressions reference abstract instance data, instead of a concrete XML document. This reference is called a binding expression in this specification. Every XPath expression requires an evaluation context. The following rules are used in determining evaluation context when evaluating XPath expressions as part of XForms:
The context node for outermost binding elements is the
top-level element node, or the single node returned by
/*
. A binding element is any element that is
explicitly allowed to have a binding expression attribute. A
binding element is "outermost" when the node-set returned by
the XPath expression ancestor::*
includes no binding
element nodes.
The context node for non-outermost binding elements is the
first node of the binding expression of the immediately enclosing
element. An element is "immediately enclosing" when it is
the first binding element node in the node-set returned by the
XPath expression ancestor::*
. This is also referred to
as "scoped resolution".
The context node always resides within the context model, which is determined choosing the first item that applies from this list:
If a model
attribute is present on the
binding element, the attribute determines the context model.
If the binding element has an immediately enclosing binding element, the context model of the immediately enclosing binding element is used.
The first model in document order is used.
The context node for computed expressions (occurring on element bind) is the node currently being processed.
For Single-Node binding expressions, the context size and position are 1. For Nodeset binding expressions, the context size is the size of the node-set, and the context position is the document order position of the node currently being processed within the node-set.
No variable bindings are in place.
The available function library is defined below, plus any functions supplied by the implementation. Extension functions required for operation of the form should be declared, as described at 7.12 Extension Functions.
Any namespace declarations in scope for the attribute that defines the expression are applied to the expression.
<group ref="level2/level3"> <select1 ref="@attr" ... > <label>...</label> </select1> </group>
In this example, the group
has a binding expression of
level2/level3
. According to the rules above, this
outermost element node would have a context node of
/level1
, which is the top-level element node of the
instance data. The select1
form control then inherits a
context node from the parent group. Matching instance data, represented
as serialized XML, follows:
<level1> <level2> <level3 attr="xyz"/> </level2> </level1>
Within XForms, the default model is the first
model
in document order. The default instance of
any model
is the first child instance
in
document order within that model
.. XPath
expressions appearing in various XForms attributes are
used to reference instance data . Every XPath expression requires an
evaluation context consisting of a node, position, size, variable
bindings, function set, and namespace context. For all
evaluation contexts in XForms,
No variable bindings are in place.
The available function library is defined below in 7.6 XForms Core Function Library .
Any namespace declarations in scope for the attribute that defines the expression are applied to the expression.
The context node, position and size are determined according to rules described below.
A binding element is any element that is explicitly allowed to have a binding expression attribute, and a bound element is any element that explicitly declares a binding expression attribute. A binding expression attribute contains an XPath expression that references zero or more nodes of instance data. Every XPath expression requires an evaluation context. The in-scope evaluation context of a binding element provides an evaluation context for the binding expression attribute. The following rules are used in determining the node, position and size of the in-scope evaluation context:
A binding element is "outermost" if the element has no ancestor binding elements.The context node for outermost binding elements is the top-level document element node of the default instance in the default model, and the context size and position are 1.
The context node, position and size for non-outermost binding elements is determined using the binding expression attribute or in-scope evaluation context of the nearest ancestor binding element. This is also referred to as "scoped resolution". For a non-outermost binding element:
If the nearest ancestor binding element is not a bound element, then the in-scope evaluation context of the non-outermost binding element is equivalent to the in-scope evaluation context of the nearest ancestor binding element.
If the nearest ancestor binding element expressing a Single-Node binding, then the in-scope evaluation context of the non-outermost binding element has a context size and position of 1 and the context node is the one resulting from the Single-Node binding of the nearest ancestor binding element.
If the nearest ancestor binding element expressing a Node Set binding, then the XForms processor dynamically generates an occurrence of the non-outermost binding element for each of the nodes in the Node Set Binding of the nearest ancestor binding element. The dynamic in-scope evaluation context for each generated occurrence of the non-outermost binding element has a context size equal to the size of the nodeset identified by the Node Set Binding of the nearest ancestor binding element, the context node is the node for which the occurrence of the non-outermost binding element was generated, and the position is equal to the position of the generator node in the nodeset identified by the Node Set Binding of the nearest ancestor binding element.
If the nearest ancestor binding element expressing a Node Set binding, then the non-outermost binding element has its own in-scope evaluation context separately from those of its dynamically generated occurences described above. The in-scope evaluation context has a context position of 1, and the context node and size are set by the first node and the size of the nodeset identified by the Node Set binding of the nearest ancestor binding element.
Once the context node of the in-scope evaluation context has
been determined according to the rules above, if the binding
element expresses a model
attribute that refers to a
model
other than the one containing the context node,
then the context node of the in-scope evaluation context is changed
to be the top-level document element node of the default instance
of the referenced model
, and the context position and
size are changed to 1.
Note:
The rules above for determining the in-scope evaluation context are
applicable to XForms elements that can contain a binding expression
attribute even if they cannot contain a Single Node Binding or Node Set
Binding. The elements bind
and submission
are
examples.
The in-scope evaluation context of an element that is not a
binding element is the same as if the element were a binding element.
For example, the in-scope evaluation context for the
setindex
action element is required to provide the context
for evaluating the index
attribute, so it is determined as
if the element could contain a binding expression attribute.
XPath expressions also appear in model item property attributes of
the bind
element to define computed expressions. If the
bind
element does not express a Node Set binding, then the
in-scope evaluation context for model item property attributes of the
bind
is equal to the in-scope evaluation context for the
bind
. Otherwise, the bind
has a Node Set
binding, and computed expressions for each model item property
attribute are generated for each node. For each computed expression
generated, the evaluation context node, position and size are
determined by the same method as dynamic in-scope evaluation context
rule above, except the computed expression is used in lieu of a binding
expression attribute such that the bind
element is the
nearest ancestor binding element.
XPath expressions also appear in the special attributes of several
other XForms elements, such as the value
attribute on
setvalue
and output
, the at
attribute of insert
and delete
, or the
index
attribute of setindex
. Generally, if
the containing element does not express a Single Node Binding or Node
Set Binding, then the special attribute is evaluated using the in-scope
evaluation context. Special attributes may be evaluated using the
in-scope evaluation context even if the containing element expresses a
Single Node Binding or Node Set Binding. However, for some special
attributes, the evaluation context node, position and size are based on
the result of the Single Node Binding or Node set Binding. Each special
attribute that contains an XPath expression describes how its
evaluation context node, position and size are determined.
In the following example, the group
has a
binding expression of level2/level3
. According to the
rules above, this outermost element node would have a context node of
/level1
, which is the document element node
of the instance data. The select1
form control then
inherits a context node from the parent group.
<level1> <level2> <level3 attr="xyz"/> </level2> </level1>
<group ref="level2/level3"> <select1 ref="@attr" ... > <label>...</label> </select1> </group>
This section describes how the in-scope evaluation context of an
element is determined, not whether the in-scope evaluation will be
used. The Single-Node Binding or Node Set Binding of a non-outermost
binding element is not evaluated if the in-scope evaluation context
does not contain a context node. This can occur if the Single-Node
Binding or Node Set Binding of the nearest ancestor bound element
produces an empty nodeset. Also, if the Single-Node Binding or Node Set
Binding of an element is expressed with the bind
attribute, then the resulting node or nodeset is obtained from the
referenced bind
element. The nodeset
attribute of a bind
element is evaluated using the
in-scope evaluation of the bind
element, not the in-scope
evaluation context of an element that references it with a
bind
attribute.
Binding expressions allow full XPaths, not just PathExpr. This is a missed case from Erratum E67 to XForms 1.0 first edition.
A binding expression is an XPath PathExpr ...
A binding expression is an XPath expression ...
The specific sections that help define the function library are given to avoid ambiguity.
The following sections define additional required functions for use within XForms.
The following sections define additional required functions for use within XForms : 7.7 Boolean Functions, 7.8 Number functions, 7.9 String functions, 7.10 Date and Time functions and 7.11 Node-set functions .
The function library provided by an XForms processor may also contain other extension functions as described in 7.12 Extension Functions.