The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: new, added text, changed text, and deleted text.
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 © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document records Forms Working Group resolutions for known errors in the XForms 1.0 Second Edition Recommendation: http://www.w3.org/TR/2006/REC-xforms-20060314/
Relative to the prior version of this errata document, the following changes occurred:
1 Re-Initializing the repeat Index
1.1 Repeat re-initialization during delete action (Section 9.3.6)
2 Submission error if no relevant element node
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 Model Construct Behaviors
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 Clarify Node-Set Binding Attributes (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 The case and toggle Elements
18.1 Default for selected Attribute
18.2 Actions in Element case (Section 9.2)
18.3 Order of Events and Behaviors in toggle Action (Section 9.2.3)
19 Defaults for bubbles and cancelable Attributes of dispatch
20 The action Attribute on submission is Optional
21 The method Attribute includes multipart-post
22 Clarifications for Binding Attributes
22.1 Single-Node Binding (Section 3.2.3)
22.2 Node-Set Binding (Section 3.2.4)
23 Attributes of bind Element are Optional
24 Clarification of Optional Attributes in Form Controls
25 Single Node Binding Misnamed on input Element
26 The resource Attribute is Optional on the load Element
27 Event Sequence for submit Element
28 Data Model Update on Submission
29 Corrections to the Behaviors of xforms-rebuild and xforms-model-construct
29.1 Amend Default Processing of xforms-model-construct
(Section 4.2.1)
29.2 Amend Default Processing of xforms-rebuild
(Section 4.3.7)
30 Clarifications to the Marking Notification Events for Dispatching
30.1 Amend Notification Event Marking in xforms-recalculate
(Section 4.3.6)
30.2 Amend Notification Event Marking in xforms-revalidate
(Section 4.3.5)
31 The Behavior of Non-relevant Groups and Switches, Non-selected Cases, and Their Content
31.1 Ensure that non-relevant controls are required to be unavailable
(Section 6.1.4)
31.2 Rigorously Define Non-relevant Form Control
(Section 8.1.1)
31.3 Rigorously Define Non-relevant Group
(Section 9.1.1)
31.4 Non-Relevance and the switch Element
(Section 9.2.1)
31.5 Non-selected case Elements
(Section 9.2.2)
32 Resolving ID References in Repeated Content, and Switch in Repeat
32.1 Single-Node Bindings
(Section 3.2.3)
32.2 Node-Set Bindings
(Section 3.2.4)
32.3 Resolving IDREFs to Repeated Content
(Section 4)
32.4 Note in index() Function
(Section 7.8.5)
32.5 Note in toggle Action
(Section 9.2.3)
32.6 Add switch to Content Model of repeat
(Section 9.2.3)
32.7 Note in setindex Action
(Section 9.3.7)
32.8 Amend Repeat User Interaction
(Section 9.3.10)
32.9 Note in dispatch Action
(Section 10.1.2)
32.10 Note in setfocus Action
(Section 10.1.7)
33 Input Focus and Repeat Index
34 Clarify Namespace Context Used in type Attribute
34.1 Better Indication of Namespace for Implicit Datatypes
(Section 5.1)
34.2 Namespace Context for type Attribute
(Section 6.1.1)
35 Clarify the model selected when model attribute is omitted
36 Clarify that a Violation of a Binding Restriction results in xforms-binding-exception
37 The itemset Element is not a Target for xforms-select/xforms-deselect
37.1 Target List for xforms-select/xforms-deselect (Section 4.4.3)
37.2 Description of itemset (Section 9.3.3)
38 Clarify that the behavior of help and hint occurs as default action.
39 Lexicographically Order the Glossary
40 Consistent Use of QNameButNotNCNAME
41 Versioning XForms Content
41.1 Add version attribute to model
41.2 Add xforms-version-exception
41.3 Terminology used to define version
41.4 The version attribute in the XForms Schema
A References
A.1 Normative References from XForms 1.0
A.2 Informative References from XForms 1.0
B Select Terms from the Glossary of 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. Also, for
consistency with the behavior of the setindex
action, the index is initialized to the size of the homogeneous collection when the startindex
is too big. This setting goes to zero when the homogeneous collection is empty.
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 the size of the homogeneous collection if it contains less than
startindex
items.
The case of not having a relevant element 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 non-relevant node, or a non-element node.
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,
a non-relevant node or a non-element node, 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: Many
Sequences of one or more XForms Actions have a deferred effect on
the instance data XForms model and user interface
processing 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
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 takes effect immediately and 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).
If this action is contained within an action
element,
it This action has special
deferred update behavior
(
10.1.1 The action Element).
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 sequence of operations affects the
deferred update behavior by clearing the
deferred update flags associated with the operations performed.
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 the value of 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 that are computed from other values.
Such computed value can be expressed as a computed expression using the values of other model items.
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
linking attributes are 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.
A host language must permit an attribute of type xsd:ID
on each XForms 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: associates a Schema datatype.
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.
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.
<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>
...
Withdrawn due to Erratum E29.
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 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 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 , 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.
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. If an outermost binding element is contained by a model
, then the context node for the outermost binding element is the top-level document element node of the default instance of the containing model
element. Otherwise, the context node for outermost binding elements is the top-level document element node of the default instance in the default model. For outermost binding elements, the context size and position are 1., or the single node returned by /*
.
The context node, position and size for non-outermost binding elements is the first node ofdetermined using the binding expression attribute or in-scope evaluation context of the immediately enclosing nearest ancestor binding 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". 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 expresses 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 expresses 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 expresses 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.
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.
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 top-level 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 PathExpr 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.
The default of the attribute selected
of element case
was not
recorded in the schema. Also, the recommendation and schema did not appropriately
reflect the ability of form authors to write actions in a case
to respond to
xforms-select
and xforms-deselect
events was not reflected
in the recommendation and schema, nor was the dispatch order of those events
relative to the change of state of the containing switch
.
Record the default for the selected
attribute in schema.
<xsd:attribute name="selected" type="xsd:boolean" use="optional"/>
<xsd:attribute name="selected" type="xsd:boolean" use="optional" default="false"/>
The case
element can contain XForms actions because the form author must
be able to write handlers for xforms-select
and xforms-deselect
.
Under Minimal Content Model for element case
:
label?, (( Form Controls | group|switch|repeat)*
Under Minimal Content Model for element case
:
label?, (( Form Controls | Action | group|switch|repeat)*
<xsd:choice> <xsd:group ref="xforms:Form.Controls"/> <xsd:element ref="xforms:group"/> <xsd:element ref="xforms:switch"/> <xsd:element ref="xforms:repeat"/> <!-- containing document language to add additional allowed content here --> </xsd:choice>
<xsd:choice>
<xsd:group ref="xforms:Form.Controls"/>
<xsd:group ref="xforms:Action"/>
<xsd:element ref="xforms:group"/>
<xsd:element ref="xforms:switch"/>
<xsd:element ref="xforms:repeat"/>
<!-- containing document language to add additional allowed content here -->
</xsd:choice>
The description of toggle
stated that the cases were selected and deselected before the
events were dispatched for xforms-select
and xforms-deselect
. This leads
to the possibility of reading the event dispatch for the xforms-deselect
as going to
the just selected case, not the one just deselected. Also, some implementations treat a case
or at least its contained UI controls as unavailable when the case is not selected. Hence, this change
ensures that the case deselection and selection occurs in between the xforms-deselect
and
xforms-select
events.
This action adjusts all selected
states (not the attribute values) on the affected
case
s to reflect the new state of the switch
containing the identified
case
, and then performs the following:
Dispatching an xforms-deselect
event to the currently selected case
.
Dispatching an xform-select
event to the case
to be selected.
This action adjusts all selected
states (not the attribute values)
on the affected case
s to reflect the new state of the switch
containing the
identified case
, and then performs the following:
Dispatches an xforms-deselect
event to the currently selected case
in the switch
containing the identified case
.
Adjusts the selected
states (not the attribute values) on the
affected cases to reflect the new state of the switch
containing the
identified case
.
Dispatches an xform-select
event to the case
just selected.
When dispatch
ing custom events, the default expressed in the schema for bubbles
and cancelable
is true
. This change brings the recommendation text into line
with the schema.
Optional boolean indicating if this event bubbles—as defined in [DOM2 Events]. The default value depends on the definition of a custom event. For predefined events, this attribute has no effect.
Optional boolean indicating if this event bubbles—as defined in [DOM2 Events].
The default value depends on the definition of
is true
for a custom event.
For predefined events, this attribute has no effect.
Optional boolean indicating if this event is cancelable—as defined in [DOM2 Events]. The default value depends on the definition of a custom event. For predefined events, this attribute has no effect.
Optional boolean indicating if this event is cancelable—as defined in
[DOM2 Events].
The default value depends on the definition of
is true
for a custom event.
For predefined events, this attribute has no effect.
A submission requires a URI, but the action
attribute is optional
according to the schema because the URI can be obtained from the base URI of the
originating document.
Required destination URI...
Required Optional attribute indicating the destination URI ...
The XForms schema omitted multipart-post
from the enumeration defined for the method
attribute.
<xsd:union memberTypes="xforms:QNameButNotNCNAME"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="post"/> <xsd:enumeration value="put"/> <xsd:enumeration value="get"/> <xsd:enumeration value="form-data-post"/> <xsd:enumeration value="urlencoded-post"/> </xsd:restriction> </xsd:simpleType> </xsd:union>
<xsd:union memberTypes="xforms:QNameButNotNCNAME">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="post"/>
<xsd:enumeration value="put"/>
<xsd:enumeration value="get"/>
<xsd:enumeration value="multipart-post"/>
<xsd:enumeration value="form-data-post"/>
<xsd:enumeration value="urlencoded-post"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:union>
When a binding attribute group is applied to an element, the group is
required unless the element explicitly declares that the binding is optional.
Within the binding attribute group, the model
attribute is optional,
and one of ref
and bind
is required only when the
binding is required.
XForms Model selector. Specifies the ID
of an XForms Model to
be associated...
Optional XForms Model selector.
Specifies the ID
of an XForms Model to be associated...
One of ref
or bind
is required.
When bind
is used, the node is determined by the referenced
bind
.
In this specification, when an XForms element is declared to have a Single-Node Binding, then the Single-Node Binding is required unless the element explicitly states that it is optional.
When the Single-Node Binding is required,
one of ref
or bind
is required.
When bind
is used, the node is determined by the referenced
bind
.
XForms Model selector. Specifies the ID
of an XForms Model to
be associated...
Optional XForms Model selector.
Specifies the ID
of an XForms Model to be associated...
One of nodeset
or bind
is required.
When bind
is used, the node-set is determined by the
referenced bind
.
In this specification, when an XForms element is declared to have a Node-Set Binding, then the Node-Set Binding is required unless the element explicitly states that it is optional.
When the Node-Set Binding is required,
one of nodeset
or bind
is required.
When bind
is used, the node-set is determined by the
referenced bind
.
This erratum clarifies that the nodeset
attribute and the model item
property attributes are optional. It also deletes two statements that were oversimplified or inaccurate.
Note:
The reference to 7.4 Evaluation Context in the changed specification wording below is as amended by Erratum 17.3 Evaluation Context (Section 7.4).
Element bind
selects a node-set selected from the
instance data
with a
model binding expression
in the nodeset
attribute. Other attributes on element bind
encode
model item properties
to be applied to each node in the
node-set. When bind
has an attribute of type xsd:ID
, the bind
then associates that identifier with the selected node-set.
Common Attributes: Common Model Item Properties
Special Attributes:
A
model binding expression
that selects the set of nodes on which this bind
operates, as defined in
7.5.2 Model Binding Expressions.
When additional nodes are added through action insert
, the newly added nodes
are included in any node-sets matched by binding expressions—see action insert
in
9.3.5 The insert Element
.
See 7.4 Evaluation Context for details on how binding affects the evaluation context.
Element bind
selects a node-set selected from the
instance data
with a
model binding expression
in the nodeset
attribute. Other attributes on element bind
encode
model item properties
to be applied to each node in the
node-set. When bind
has an attribute of type xsd:ID
, the bind
then associates that identifier with the selected node-set.
Common Attributes: Common Model Item Properties (Optional)
Special Attributes:
An optional attribute containing a
model binding expression
that selects the set of nodes on which this bind
operates
, as defined in
7.5.2 Model Binding Expressions
.
When additional nodes are added through action insert
, the newly added nodes
are included in any node-sets matched by binding expressions—see action insert
in
9.3.5 The insert Element
.
See
7.4 Evaluation Context
for details on how binding affects
the evaluation context is determined for each attribute of the bind
element..
This erratum clarifies that the inputmode
, appearance
,
value
and mediatype
attributes on form controls are optional.
input
Element):This form control accepts an input mode hint...
Optional. This form control accepts an input mode hint...
secret
Element):This form control accepts an input mode hint...
Optional. This form control accepts an input mode hint...
textarea
):This form control accepts an input mode hint...
Optional. This form control accepts an input mode hint...
output
Element):This form control does not use the UI Common attribute group, but nevertheless still contains an appearance
attribute, as defined above.
This form control does not use the UI Common attribute group, but nevertheless still contains an optional appearance
attribute, as defined above.
value
attribute in Section 8.1.5 The output
Element:An XPath expression to be evaluated. The string result of the evaluation is rendered by the form control. If binding attributes are present to select a node, this attribute has no effect. The evaluation context is the same as would be applied to the evaluation of the single node binding. This XPath expression is re-evaluated whenever there is a change in any node to which the expression refers.
Optional. An XPath expression to be evaluated. The string result of the evaluation is rendered by the form control. If binding attributes are present to select a node, this attribute has no effect. The evaluation context is the same as would be applied to the evaluation of the single node binding. This XPath expression is re-evaluated whenever there is a change in any node to which the expression refers.
upload
Element):Space-separated list of suggested media types, used by the XForms Processor to determine the possible sources of data to upload.
Optional. Space-separated list of suggested media types, used by the XForms Processor to determine the possible sources of data to upload.
The Single Node Binding attributes are called Single Node UI Binding attributes in the
description of the input
, which is inconsistent with the rest of the spec.
Single Node UI Binding
Single Node UI Binding
The description of the load
element states that a URI must be provided by either the resource
attribute or the node identified by a single node binding. The single node binding attribute bundle is marked
optional, so this erratum also marks the resource
attribute optional.
resource
attribute in Section 10.1.8 The load Element:Link to external resource to load...
Optional. Link to external resource to load...
The relationship between the DOMActivate
event on the submit
element and the
dispatch of the xforms-submit
event is corrected.
Implementation Requirements: Upon receiving event DOMActivate
, this form control
dispatches event xforms-submit
to the submission
element specified by
required attribute submission
.
Implementation Requirements: Upon receiving
The default action for event DOMActivate
, this form control dispatches
is to dispatch
event xforms-submit
to the submission
element specified by
required attribute submission
.
XForms actions that occur immediately before a submission
is invoked (e.g.
by a send
action) may cause the calculated values, constraints, or other
model item properties to be stale due to the deferred update behavior of XForms actions.
The default action of xforms-submit
is augmented to perform rebuild and
recalculate operations if needed based on examining the deferred update flags.
Otherwise, default action for this event results in the following steps:
Otherwise, the default action for this event results in the following steps:
The data model is updated. Specifically, if the deferred update rebuild
flag is
set for the model
containing this submission
, then the
rebuild operation is performed without dispatching an event to invoke the operation.
Then, if the deferred update recalculate
flag is set for the model
containing this submission
, then the recalculate operation is performed without
dispatching an event to invoke the operation. Performing the operations clears the flags.
Note:
The steps of the default action currently numbered 1 and higher are incremented to be 2 and higher.
The binds are processed by rebuild, which is invoked by model construction. This erratum moves the material on bind processing to its proper location in rebuild and also amends the text to be more precise. As a result, xforms-model-construct must perform the behaviors of xforms-rebuild, xforms-recalculate and xforms-revalidate without dispatching events. This erratum further clarifies that the notification events marked for dispatching by these operations are cleared since the user interface is constructed in xforms-model-construct-done.
Remove bind processing from model construction and make two other editorial adjustments.
The default action for this event results in the following:
All XML Schemas loaded. If an error occurs while attempting to access or process a remote document, processing halts with an exception (Section 4.5.2).
If an external source for the initial instance data is given, an XPath data model [Section 7]. is constructed from it; otherwise if inline initial instance data is given, that is used instead. If the external initial instance data is not well-formed XML or cannot be retrieved, processing halts with an exception (Section 4.5.2). If neither are given, the data model is not constructed in this phase, but during user interface construction (Section 4.2.2).
If applicable, P3P initialized. [P3P 1.0]
Instance data is constructed. All strings inserted into the instance data are
subject to Unicode normalization.
All model item properties are initialized by processing all bind
elements in
document order. For each bind
:
The attribute nodeset
attached to the bind is evaluated, resulting in a set
of nodes selected.
For each node in the node-set, model item properties are applied according to the
remaining attributes on bind
:
the string value of each attribute (with a name matching one of the properties defined in
Section
6.1).
is copied as the local value of the model item property of the same name.
If the node already contains a model item property of the same name, XForms processing for this containing document halts with an exception (Section 4.5.1).
Perform 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).
The default action for this event results in the following:
All XML Schemas are loaded. If an error occurs while attempting to access or process a remote document, processing halts with an exception (Section 4.5.2).
If an external source for the initial instance data is given, an XPath data model [Section 7]. is constructed from it; otherwise if inline initial instance data is given, that is used instead. If the external initial instance data is not well-formed XML or cannot be retrieved, processing halts with an exception (Section 4.5.2). If neither are given, then default processing of this event ends because the data model is not constructed in this phase, but during user interface construction (Section 4.2.2).
If applicable, P3P initialized. [P3P 1.0]
Instance data is constructed. All strings inserted into the instance data are
subject to Unicode normalization.
All model item properties are initialized by processing all bind
elements in
document order. For each bind
:
The attribute nodeset
attached to the bind is evaluated, resulting in a set
of nodes selected.
For each node in the node-set, model item properties are applied according to the
remaining attributes on bind
:
the string value of each attribute (with a name matching one of the properties defined in
Section
6.1).
is copied as the local value of the model item property of the same name.
If the node already contains a model item property of the same name, XForms processing for this containing document halts with an exception (Section 4.5.1).
Perform the behaviors of xforms-rebuild
,
xforms-recalculate
, and xforms-revalidate
in sequence
, for on this model
element
without dispatching events to invoke the behaviors.
(The notification event markings for these
operations are discarded, and the
xforms-refresh
behavior is not
performed since the user interface has not yet been initialized).
Add bind processing text formerly described in xforms-model-construct, and amend it to be more accurate regarding the storage of model item property values.
The default action for this event results in the following:
The default action for this event is that the computational dependency data structures are rebuilt,
then the change list L is set to contain references to all instance nodes that have an
associated computational expression such that a full recalculate is performed the next time
the xforms-recalculate
event is dispatched to the model.
The default action for this event results in the following:
All model item properties are initialized by processing all bind
elements
in document order. For each bind
:
If the attribute nodeset
is attached to the bind, it is evaluated to select an
XPath node-set. Otherwise, if the bind
does not have a nodeset
attribute,
then the selected XPath node-set consists of the in-scope evaluation context.
For each node in the selected XPath node-set, model item properties are applied according to
the remaining attributes on the bind
element (for details on the model item properties,
see
Section 6).
If a node already contains a model item property of the same name due to the processing of prior
bind
elements, then XForms processing for the containing document halts with an exception
(Section
4.5.1).
For each node in the selected XPath node-set, any child bind
elements are recursively
processed as described in the three points of this list.
The default action for this event is that
After initial processing of the bind
elements,
the computational dependency data structures
are rebuilt, and then the change list L is set to
contain references to all instance nodes that have an associated computational expression
so that a full
recalculation is performed the next time the
behavior of
xforms-recalculate
is invoked.
The recalculate and revalidate behaviors mark various notification events for dispatching. For boolean events such as xforms-valid/xforms-invalid, this erratum clarifies that marking the one event means that a prior marking for the opposing event is cleared. The intent is for the notification events to be marked in such a way that an xforms-refresh only dispatches notification events that reflect the most up-to-date state of the model, even when xforms-refresh behavior is recursively entered due to an action handler for a notification event dispatched by xforms-refresh.
In addition to contributing further node value changes that will cause xforms-value-changed notifications in xforms-refresh, the model item properties that change are marked to help xforms-revalidate and xforms-refresh to determine the notification events to dispatch.
If the required model item property changes, then either the xforms-required event must be marked for dispatch if required is true or the xforms-optional event must be marked for dispatch if required is false.
If the readonly model item property changes, then either the xforms-readonly event must be marked for dispatch if readonly is true or the xforms-readwrite event must be marked for dispatch if readonly is false.
If the relevant model item property changes, then either the xforms-enabled event must be marked for dispatch if relevant is true or the xforms-disabled event must be marked for dispatch if relevant is false.
In addition to contributing further node value changes that will cause xforms-value-changed notifications in xforms-refresh, the model item properties that change are marked to help xforms-revalidate and xforms-refresh to determine the notification events to dispatch.
If the required model item property changes, then either the xforms-required event must be marked for dispatch if required is true or the xforms-optional event must be marked for dispatch if required is false. Marking one of these events for dispatch unmarks the other.
If the readonly model item property changes, then either the xforms-readonly event must be marked for dispatch if readonly is true or the xforms-readwrite event must be marked for dispatch if readonly is false. Marking one of these events for dispatch unmarks the other.
If the relevant model item property changes, then either the xforms-enabled event must be marked for dispatch if relevant is true or the xforms-disabled event must be marked for dispatch if relevant is false. Marking one of these events for dispatch unmarks the other.
All instance data nodes in all instance
elements in the model
are checked
for validity according to the above
definition. If the validity of a node changes, then the
node is marked for dispatching the appropriate
notification event (xforms-valid or xforms-invalid)
to bound form controls during xforms-refresh as follows:
If the node changes from invalid to valid, then the node is marked for dispatching the xforms-valid event.
If the node changes from valid to invalid, then the node is marked for dispatching the xforms-invalid event.
All instance data nodes in all instance
elements in the model
are checked
for validity according to the above
definition. If the validity of a node changes, then
the node is marked for dispatching the appropriate
notification event (xforms-valid or xforms-invalid)
to bound form controls during xforms-refresh as follows:
either the xforms-valid event must be marked for
dispatch if the node changes from valid to invalid
or the xforms-invalid event must be marked for
dispatch if the node changes from valid to invalid.
Marking one of these events for dispatch unmarks the other.
If the node changes from invalid to valid, then the node is marked for dispatching the xforms-valid event.
If the node changes from valid to invalid, then the node is marked for dispatching the xforms-invalid event.
The table indicated the proper required nature of the connection between non-relevance and unavailability of controls, but other material in the section were improperly using other terms that implied the connection was recommended or optional.
The relevant
model item property provides hints to the
XForms user interface regarding visibility, focus, and navigation order. In general,
when true
, associated form controls should be made visible.
When false
, associated form controls (and any children) and group and switch elements
(including content) should be made unavailable, removed from the
navigation order, and not allowed focus.
The relevant
model item property provides information to the
XForms user interface regarding visibility, focus, and navigation order. In general,
when true
, associated form controls should be made visible.
When false
, associated form controls (and any children) and group and switch elements
(including content) must be made unavailable, removed from the
navigation order, and not allowed focus. Typically, non-relevant content is
not presented, or it may be styled as disabled.
The following table shows the user interface interaction between required
and
relevant
.
required="true()" | required="false()" | |
relevant="true()" | The form control (and any children) must be visible or available to the user. The XForms user interface may indicate that a value is required. | The form control (and any children) must be visible or available to the user. The XForms user interface may indicate that a value is optional. |
relevant="false()" | The form control (and any children) must be hidden or unavailable to the user. Entering a value or obtaining focus should not be allowed. The XForms user interface may indicate that should the form control become relevant, a value would be required. | The form control (and any children) must be hidden or unavailable to the user. Entering a value or obtaining focus should not be allowed. |
All of the channels of non-relevance for a form control are collected together in the implementation requirements. Also, the eventing that occurs on state changes is given. A critical part of this erratum is that XForms action handlers for events on the form control are disabled when the control is non-relevant.
Form controls must provide a default explanation for the above when no user-specified explanation is available.
Form controls must provide a default explanation for the above when no user-specified explanation is available.
Form controls are considered to be non-relevant if any of the following apply:
the Single Node Binding is expressed and resolves to empty nodeset,
the Single Node Binding is expressed and resolves to a non-relevant instance node,
the form control is contained by a non-relevant switch
or
group
(which includes a non-relevant repeat
item), or
the form control is contained by a non-selected case
element of
a switch
.
When a form control becomes non-relevant, it must receive event
xforms-disabled
and then the
XForms action handlers that are listening for events on the non-relevant
form control must be disabled.
When a non-relevant form control changes to being relevant,
the XForms action handlers that listen for
events on the form control must become enabled and then the form control
must be updated to represent the
current value(s) and model item properties of the instance node(s) to
which it is bound or to which it refers.
The following events must be dispatched to the form control:
xforms-enabled
, xforms-value-changed
,
one of xforms-valid
or xforms-invalid
,
one of xforms-readonly
or xforms-readwrite
,
one of xforms-required
or xforms-optional
,
and one of xforms-in-range
or xforms-out-of-range
.
All of the channels of non-relevance for a group are collected together
in the implementation requirements. Also, the eventing that occurs on state changes is given.
Any XForms action handlers for events on the group
are disabled when it is non-relevant.
The group
element is used as a container for defining a hierarchy of form controls.
Groups can be nested to create complex hierarchies. A group is considered to
be non-relevant if and only if the single node binding resolves to an empty nodeset or a
non-relevant node.
The group
element is used as a container for defining a hierarchy of form controls.
Groups can be nested to create complex hierarchies. A group is considered to
be non-relevant if and only if:
the Single Node Binding is expressed and resolves to empty nodeset,
the Single Node Binding is expressed and resolves to a non-relevant instance node,
the group
is contained by a non-relevant
switch
or group
(which includes a non-relevant
repeat
item), or
the group
is contained by a non-selected case
element
of a switch
.
All content elements (e.g. form controls, groups, switches, repeats and host language
content) within a non-relevant group are handled as non-relevant. When a group
becomes
non-relevant, it must receive event xforms-disabled
and then the
XForms action handlers that are listening for events on the non-relevant group
must
be disabled. When a non-relevant group
changes to being relevant, the XForms action handlers
that listen for events on the group
must become enabled and then the group
must receive the event xforms-enabled
.
The eventing that occurs on relevance state change is provided. Any XForms action handlers for
events on the switch
are disabled when the switch is non-relevant.
This element contains one or more case
elements, any one of which is rendered at a
given time.
The non-relevance of a switch is determined in the same way as it is for group
and similarly applies to the entire content.
Note:
This is separate from XForms relevant
processing (see
6.1.4
The relevant Property),
which is based on the current state of the XForms Model. As an example, portions of a questionnaire
pertaining to the user's automobile may become relevant only if the user has answered in the
affirmative to the question 'Do you own a car?'.
This element contains one or more case
elements, any one of which is rendered
at a given time.
Note:
This is separate from XForms relevant
processing (see
6.1.4
The relevant Property),
which is based on the current state of the XForms Model. As an example, portions of a questionnaire
pertaining to the user's automobile may become relevant only if the user has answered in the
affirmative to the question 'Do you own a car?'.
The non-relevance of a switch is determined in the same way as it is for group
and similarly applies to the entire content. Also, as with group
,
when a switch
becomes non-relevant, it must receive event xforms-disabled
and then the XForms action handlers that are listening for events on the non-relevant
switch
must be disabled. As well, when a non-relevant switch
changes to
being relevant, the XForms action handlers that listen for events on the switch
must become enabled and then the switch
must receive the event
xforms-enabled
.
The content of a non-selected case must behave as if it is in a non-relevant group. This is especially important for ensuring that the XForms action handlers for events on elements of the content are disabled whenever the case is non-selected.
This element encloses markup to be conditionally rendered.
The attribute selected
determines the initial selected state.
This element encloses markup to be conditionally rendered.
The content elements (e.g. form controls,
groups, switches, repeats and host language elements) within a non-selected case
behave as if they were in
a non-relevant group
(see
Section 9.1.1).
Similarly, content elements in a case
that becomes
selected behave as if they were in a group
that has become relevant.
The attribute selected
determines the initial selected state.
A Single-Node Binding can be expressed with a bind
attribute, which may refer
to a bind
element that is repeated by an outer, containing bind
element.
When bind
is used, the node is determined by the referenced bind
.
When bind
is used, the node is determined by the referenced bind
.
See
4.7.2 References to Elements within a bind Element
for details on selecting an identified bind
that is iterated by one or more
containing bind
elements.
A Node-Set Binding can be expressed with a bind
attribute, which may refer
to a bind
element that is repeated by an outer, containing bind
element.
When bind
is used, the node-set is determined by the referenced bind
.
When bind
is used, the node-set is determined by the referenced bind
.
See
4.7.2 References to Elements within a bind Element
for details on selecting an identified bind
that is iterated by one or more
containing bind
elements.
An IDREF in a static XML document has no ambiguity. However, in XForm an element bearing an ID
may be iterated more than once, e.g. with a repeat
or bind
element. This material
describes how the correct copy of the repeated element is obtained.
4.7 Resolving ID References in XForms
The element of a document for which an IDREF must be resolved is called the source element, and the element bearing the matching ID, if there is one, is called the target element. Due to the run-time expansion of repeated content in XForms, it is possible that there will be more than one occurrence of both the source and target elements. This section describes how XForms IDREF resolution works to accommodate such repetition of the originating document's content.
Each run-time occurrence of the source element is called a source object, and each run-time occurrence of the target element is called a target object. It is the source object that performs the IDREF resolution, and the result of the search is either null or a target object.
Whether or not repeated content is involved, a null search result for an IDREF resolution
is handled differently depending on the source object. If there is a null search result for
the target object and the source object is an XForms action such as dispatch
,
send
, setfocus
, setindex
or toggle
, then the action is
terminated with no effect. Similarly, a submit
form control does not dispatch
xforms-submit
if its submission
attribute does not indicate an existing
submission
element. Likewise, when an XPath function associated with the source
object performs the IDREF search and a null result is obtained, the function returns an
empty result such as NaN
for the index()
function or empty nodeset
for the instance()
function. However, an xforms-binding-exception
occurs if there is a null search result for the target object indicated by attributes
bind
, model
and instance
.
If the target element is not repeated, then the search for the target object is trivial since there is only one associated with the target element that bears the matching ID. This is true regardless of whether or not the source object is repeated. However, if the target element is repeated, then additional information must be used to help select a target object from among those associated with the identified target element.
When the target element that is identified by the IDREF of a source object has one or more
repeat
elements as ancestors, then the set of ancestor repeats are partitioned into
two subsets, those in common with the source element and those that are not in common.
Any ancestor repeat
elements of the target element not in common with the source
element are descendants of the repeat
elements that the source and target element
have in common, if any.
For the repeat
elements that are in common, the desired target object exists in the
same set of run-time objects that contains the source object. Then, for each ancestor
repeat
of the target element that is not in common with the source element, the current
index of the repeat
determines the set of run-time objects that contains the desired
target object.
When a source object expresses a Single Node Binding or Node Set Binding with a bind
attribute,
the IDREF of the bind
attribute is resolved to a target bind object whose associated nodeset is
used by the Single Node Binding or Node Set Binding. However, if the target bind
element has one
or more bind
element ancestors, then the identified bind
may be a target element that is
associated with more than one target bind object.
If a target bind
element is outermost, or if all of its ancestor bind
elements have
nodeset
attributes that select only one node, then the target bind
only has one
associated bind object, so this is the desired target bind object whose nodeset is used in the
Single Node Binding or Node Set Binding. Otherwise, the in-scope evaluation context node of the
source object containing the bind
attribute is used to help select the appropriate
target bind object from among those associated with the target bind
element.
From among the bind objects associated with the target bind
element, if there exists a
bind object created with the same in-scope evaluation context node as the source object, then that
bind object is the desired target bind object. Otherwise, the IDREF resolution produced a
null search result.
The index() function must be able to return the index of a repeated repeat
.
Note:
The IDREF obtained from the function parameter may not uniquely identify
the desired repeat
if the repeat
element bearing the
matching ID resides
in a repeating construct such as element repeat
.
The general method described in
4.7 Resolving ID References in XForms
is used to determine the desired run-time case object.
The toggle
action must be able to toggle the case of a repeated switch.
Note:
The IDREF obtained from the case
attribute may not uniquely identify
the desired case
if the case
element bearing the
matching ID resides
in a repeating construct such as element repeat
.
The general method described in
4.7 Resolving ID References in XForms
is used to determine the desired run-time case object.
The toggle
action must be able to toggle the case of a repeated switch.
Element | Attributes | Minimal Content Model |
---|---|---|
repeat | Common, UI Common, Node Set Binding, startindex (xsd:positiveInteger), number (xsd:nonNegativeInteger) | ((Form Controls)|group|repeat)* |
Element | Attributes | Minimal Content Model |
---|---|---|
repeat | Common, UI Common, Node Set Binding, startindex (xsd:positiveInteger), number (xsd:nonNegativeInteger) | ((Form Controls)|group|switch|repeat)* |
<xsd:element name="repeat"> <xsd:complexType> <xsd:sequence> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:choice> <xsd:group ref="xforms:Form.Controls"/> <xsd:element ref="xforms:group"/> <xsd:element ref="xforms:repeat"/> <!-- containing document language to add additional allowed content here --> </xsd:choice> </xsd:sequence> </xsd:sequence> <xsd:attributeGroup ref="xforms:Common.Attributes"/> <xsd:attributeGroup ref="xforms:Nodeset.Binding.Attributes"/> <xsd:attributeGroup ref="xforms:UI.Common.Attrs"/> <xsd:attribute name="startindex" type="xsd:positiveInteger"/> <xsd:attribute name="number" type="xsd:nonNegativeInteger"/> </xsd:complexType> </xsd:element>
<xsd:element name="repeat">
<xsd:complexType>
<xsd:sequence>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
<xsd:group ref="xforms:Form.Controls"/>
<xsd:element ref="xforms:group"/>
<xsd:element ref="xforms:switch"/>
<xsd:element ref="xforms:repeat"/>
<!-- containing document language to add additional allowed content here -->
</xsd:choice>
</xsd:sequence>
</xsd:sequence>
<xsd:attributeGroup ref="xforms:Common.Attributes"/>
<xsd:attributeGroup ref="xforms:Nodeset.Binding.Attributes"/>
<xsd:attributeGroup ref="xforms:UI.Common.Attrs"/>
<xsd:attribute name="startindex" type="xsd:positiveInteger"/>
<xsd:attribute name="number" type="xsd:nonNegativeInteger"/>
</xsd:complexType>
</xsd:element>
The setindex
action must be able to set the index of a repeated repeat
.
Note:
The IDREF from the repeat
attribute may not uniquely identify the desired
repeat if the repeat
element bearing the matching ID resides within the content
of another repeat
. The general method described in
4.7 Resolving ID References in XForms
is used to determine the desired run-time repeat object.
Replace wording that calls for more implementation experience with wording that describes the results of the experience.
Notice that the markup encapsulated by element repeat
acts as the template for the user
interaction that is presented to the user. As a consequence, it is not possible to refer to portions
of the generated user interface via statically authored idref
attributes. A necessary
consequence of this is that XForms 1.0 does not specify the behavior of construct switch
within element repeat
. Future versions of XForms may specify the behavior of
switch
inside repeat
based on implementation experience and user feedback.
Notice that the markup encapsulated by element repeat
acts as the template
for the user interaction that is presented to the user. As a consequence, it is not possible to
refer to portions of the generated user interface via statically authored idref
attributes. A necessary consequence of this is that XForms 1.0 does not specify the behavior of
construct switch
within element repeat
. Future versions of XForms may specify
the behavior of switch
inside repeat
based on implementation experience and
user feedback.
Notice that the markup encapsulated by element repeat
acts as the template
for the user interface that is presented to the user. As a consequence, statically authored
IDREF
attributes must be interpreted based on a combination of repeat indexes and
where the IDREF attributes appear relative to the element bearing the matching ID. Based on the
IDREF resolution rules given in
4.7 Resolving ID References in XForms
it is possible to toggle the
case
of a switch
even when it is within one or more repeat
elements.
Similarly, it is possible to set the focus to controls and dispatch events to elements that are
within one or more repeat
elements.
The dispatch
action must be able to dispatch its event to repeated elements.
Note:
The IDREF obtained from the target
attributemay not uniquely identify
the desired target object if the element bearing the matching ID resides in a repeating
construct such as element repeat
. The general method described in
4.7 Resolving ID References in XForms
is used to determine the desired target object.
The setfocus
action must be able to dispatch its event to repeated elements.
Note:
The IDREF obtained from the control
attribute may not uniquely identify
the desired form control if the element bearing the matching ID resides in a repeating
construct such as element repeat
. The general method described in
4.7 Resolving ID References in XForms
is used to determine the desired form control.
When a control receives the input focus, whether by programmatic means or by user interaction,
the index values of any containing repeat
elements are updated to reflect the current
repeat item containing the focused control.
If the focus is transferred to a control within a repeat
by any means,
such as by an XForms action or by user interaction, the index of the repeat
is changed
to indicate the item of the homogeneous collection that contains the control. This effect is
recursive; the index of each containing repeat
is adjusted appropriately.
The implicit datatypes did not include the xsd:
prefix because they were listed as
datatypes supported from XML schema. This erratum clarifies that the type
model item property
attribute value is interpreted as a QName
with a namespace context derived from the location
where the type
attribute appears.
Amend the implicit datatypes.
Built-in primitive types:
dateTime *
time *
date *
gYearMonth *
gYear *
gMonthDay *
gDay *
gMonth *
string *
boolean *
base64Binary *
hexBinary
float
decimal *
double
anyURI *
QName
Note:
The built-in datatype xsd:duration
is not supported, except as an abstract datatype.
Instead, either xforms:dayTimeDuration
or xforms:yearMonthDuration
should be used.
Built-in derived types:
normalizedString
token
language
Name
NCName
ID
IDREF
IDREFS
NMTOKEN
NMTOKENS
integer *
nonPositiveInteger *
negativeInteger *
long *
int *
short *
byte *
nonNegativeInteger *
unsignedLong *
unsignedInt *
unsignedShort *
unsignedByte *
positiveInteger *
Built-in primitive types:
xsd:dateTime *
xsd:time *
xsd:date *
xsd:gYearMonth *
xsd:gYear *
xsd:gMonthDay *
xsd:gDay *
xsd:gMonth *
xsd:string *
xsd:boolean *
xsd:base64Binary *
xsd:hexBinary
xsd:float
xsd:decimal *
xsd:double
xsd:anyURI *
xsd:QName
Note:
The built-in datatype xsd:duration
is not supported, except as an abstract datatype.
Instead, either xforms:dayTimeDuration
or xforms:yearMonthDuration
should be used.
Built-in derived types:
xsd:normalizedString
xsd:token
xsd:language
xsd:Name
xsd:NCName
xsd:ID
xsd:IDREF
xsd:IDREFS
xsd:NMTOKEN
xsd:NMTOKENS
xsd:integer *
xsd:nonPositiveInteger *
xsd:negativeInteger *
xsd:long *
xsd:int *
xsd:short *
xsd:byte *
xsd:nonNegativeInteger *
xsd:unsignedLong *
xsd:unsignedInt *
xsd:unsignedShort *
xsd:unsignedByte *
xsd:positiveInteger *
The namespace context used to interpret the type
attribute value is given.
Legal Values: Any xsd:QName
representing a datatype definition in an XML Schema.
Legal Values: Any xsd:QName
representing a datatype definition in an XML Schema.
The namespace context from the parent bind
of the type
attribute is used to resolve the namespace qualification of the value.
The model
attribute is optional on actions rebuild
,
recalculate
, revalidate
, refresh
and reset
.
This erratum clarifies what model is selected when the model attribute is not given.
Optional XForms Model selector, as defined in Section 3.2.3.
Optional XForms Model selector, as defined in
Section 3.2.3. If this attribute is omitted, then the default is the
model
associated with the in-scope evaluation context node.
xforms-binding-exception
Clarify that the data binding restrictions are enforced.
All form controls must meet the following implementation requirements:
Form controls that write simpleContent to instance data must do so exactly as defined by the XForms Action Section 10.1.9 The setvalue Element:
All form controls that read simpleContent instance data must do so as follows:
Element nodes: if text child nodes are present, returns the string-value of the first text child node. Otherwise, returns "" (the empty string)
Attribute nodes: returns the string-value of the node.
Text nodes: returns the string-value of the node.
Namespace, processing instruction, comment, and the XPath root node: behavior is undefined.
All form controls must meet the following implementation requirements:
If a form control violates its data binding restriction, an xforms-binding-exception
must occur.
Form controls that write simpleContent to instance data must do so exactly as defined by the XForms Action Section 10.1.9 The setvalue Element:
All form controls that read simpleContent instance data must do so as follows:
Element nodes: If element child nodes are present, then
an xforms-binding-exception
occurs. Otherwise,
if text child nodes are present, returns the string-value of the first text child node.
Otherwise, returns "" (the empty string)
Attribute nodes: returns the string-value of the node.
Text nodes: returns the string-value of the node.
Namespace, processing instruction, comment, and the XPath root node: behavior is undefined.
The itemset
element was listed as a target of the xforms-select
and
xforms-deselect
events because the content model of itemset
allows
actions, such as those that provide handlers for xforms-select
and xforms-deselect
.
However, these action handlers are generated for and associated with the item
elements.
Remove itemset
from the target list.
Target: item
or itemset
or case
Target: item
or itemset
or case
Explain the behavior of XForms Actions appearing within an itemset
.
Note:
The reference to 7.4 Evaluation Context in the changed specification wording below is as amended by Erratum 17.3 Evaluation Context (Section 7.4).
This element allows the creation of dynamic selections within controls select
and
select1
, where the available choices are determined at run-time. The node-set that holds
the available choices is specified via attribute nodeset
. As with repeat
, this
nodeset should refer to a homogeneous collection.
Child elements label
and value
indirectly specify the label and storage values.
Notice that the run-time effect of itemset
is the same as using element choices
to statically author the available choices.
This element allows the creation of dynamic selections within controls select
and
select1
, where the available choices are determined at run-time. The node-set that holds the
available choices is specified via attribute nodeset
the Node Set Binding. As with repeat
, this nodeset should refer
to a homogeneous collection. Child elements label
and value
indirectly specify the label and storage values. Notice that the run-time effect of
itemset
is the same as using element choices
with child
item
elements to statically author the available choices.
For each node of the Node Set Binding, an associated item
is created.
XForms Actions appearing in the content of an itemset
are created within each item
element, and the in-scope evaluation context for these XForms Actions is based on the node for which the
item
was generated as described in Section
7.4 Evaluation Context
An XForms processor must not allow XForms Actions contained by an itemset
to handle events on the
itemset
.
The description of events xforms-help
and xforms-hint
describes that the
help or hint message occur as the default action of the event. The specification wording removed by
this erratum attempted to be more specific about how the message is provided by stating the behavior
in terms of a message
action. However, this incorrectly implied that the help or hint
behavior occurs due to an event handler and not as a default action, so the wording is removed.
This is equivalent to a <message level="modeless" ev:event="xforms-help" ev:propagate="stop">
.
This is equivalent to a <message level="modeless" ev:event="xforms-help" ev:propagate="stop">
.
This is equivalent to a handler for event xforms-hint
that responds with a <message level="ephemeral">
.
This is equivalent to a handler for event xforms-hint
that responds with a <message level="ephemeral">
.
Two definitions in the glossary were placed close to related definitions rather than in
the proper lexicographic position. The definitions of Model Binding expression
and UI or action binding expression
are moved to the correct lexicographic
position within the glossary of
Section 13.
The XForms schema defines a datatype called QNameButNotNCNAME. The datatype is used in several places in the specification, though it sometimes appears hyphenated, with different capitalization and in one table is erroneously prefixed by the xforms namespace prefix. This erratum applies QNameButNotNCName consistently throughout the specification and adds the definition to the glossary of Section 13.
It has always been the intent of the working group to provide a mechanism for indicating the version of XForms to which content conforms. Originally, the working group had planned to achieve versioning using a change of namespace URI. Due to community feedback, this plan was changed to using an attribute. Further community feedback noted that the change necessitated adding the version attribute to XForms 1.0 to help distinguish XForms 1.0 content from XForms 1.1 content now that both are in the same namespace.
The version
attribute must be added to the table describing the attributes of element model
,
and the description of the attribute must be added to Special Attributes of the model
.
..., functions (QNameList), schema (list of xsd:anyURI)
..., functions (QNameList), schema (list of xsd:anyURI), version xforms:versionList
Optional attribute with a default value of empty string and legal values defined by the datatype xforms:versionList. Examples are "1.0"
and "1.0 1.1"
. If one or more versions are indicated by this attribute on the default model
, then an XForms Processor must support at least one of the listed language versions of XForms. Otherwise, the XForms Processor must terminate processing after dispatching the event xforms-version-exception to the default model
. If the XForms Processor supports more than one language version indicated by the version setting on the default model
or if the version setting on the default model
is empty string (whether specified or by default), then the XForms Processor may execute the XForms content using any language conformance level available to it. If any non-default model
has a version setting that is incompatible with the language version selected by the XForms Processor, or if any model
contains an illegal version
attribute value, then the XForms Processor must terminate processing after dispatching the event xforms-version-exception to the default model
.
The version
attribute is optional to implement, but future versions of XForms are expected to support it, so implementation support is strongly encouraged.
It is necessary to add an exception type, xforms-version-exception
, to indicate the failure of a version check.
Event name | Cancelable? | Bubbles? | Target element |
---|---|---|---|
xforms-version-exception | No | Yes | the default model |
4.5.5 The xforms-version-exception Event
Dispatched as an indication of failure of the version checks defined in the description of the version
attribute in Section 3.3.1 The model Element.
Target: the default model
Bubbles: Yes
Cancelable: No
Context Info: None
The default action for this event results in the following: Fatal error.
The description of the version
attribute depends on datatype definitions provided here.
[Definition: A list ([XML Schema part 2]) with an atomic datatype ([XML Schema part 2]) of versionNumber.]
[Definition: A string consisting of a non-zero digit (1 to 9) followed by zero or more digits (0 to 9), then a period character (.), and then one or more digits (0-9). A version number is derived from string by restriction based on the following pattern value (excluding the quote marks): "[1-9]\d*\.\d+"
.]
The version
attribute described by the rest of this erratum should also appear in the XForms 1.0 schema.
model
element:<xsd:attribute name="version" type="xforms:versionList" use="optional"/>
<xsd:simpleType name="versionList">
<xsd:list itemType="xforms:versionNumber"/>
</xsd:simpleType>
<xsd:simpleType name="versionNumber">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[1-9]\d*\.\d+"/>
</xsd:restriction>
</xsd:simpleType>
[Definition: A software application or program that implements and conforms to the XForms specification.]