W3C

XForms 1.0 Second Edition Recommendation Errata

19 July 2007

This version:
http://www.w3.org/2006/03/REC-xforms-20060314-errata-20070719.html
Latest version:
http://www.w3.org/2006/03/REC-xforms-20060314-errata.html
Previous version:
http://www.w3.org/2006/03/REC-xforms-20060314-errata-20061215.html

Editor:
John M. Boyer, IBM

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.


Status of this Document

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:

Table of Contents

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

Appendices

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


1 Re-Initializing the repeat Index

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.

1.1 Repeat re-initialization during delete action (Section 9.3.6)

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.

Current specification wording:

To re-initialize a repeat means to change the index to 0 if it is empty, otherwise 1.

Changed specification wording:

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.

2 Submission error if no relevant element node

The case of not having a relevant element node of data to submit is not handled by submission processing.

2.1 Default action of xforms-submit event (Section 11.1)

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.

Current specification wording:

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.

Changed specification wording:

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.

3 Evaluation Context for setindex Action

The evaluation context node for the setindex action is not specified.

3.1 Specify evaluation context for index attribute of setindex (Section 9.3.7)

The evaluation context for the index attribute of the setindex action is specified.

Current specification wording:

Required XPath expression that evaluates to a 1-based offset into the sequence.

Changed specification wording:

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

4 Behavior of setvalue Action

The recommendation does not directly indicate the behavior of the setvalue action when the Single-Node Binding does not select a node.

4.1 The setvalue Action Behavior on Empty Single-Node Binding (Section 10.1.9)

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 valueresult, nor is there even a context node for evaluating the value attribute.

Current specification wording:

This action explicitly sets the value of the specified instance data node.

Changed specification wording:

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.

5 Deferred Update of XForms Action Sequences

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.

5.1 Main Description of Deferred Update

Modified Description of Deferred Update and moved it out of Section 10.1.1.

Current specification wording from 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.

Moved specification wording to the end of Section 10.1, and modified specification wording as follows:

An outermost action handler is an action that is activated when the XForms processor is not executing any other action handlers.

An inner action handler is an action that is activated when the XForms processor is executing the declared actions of an outermost action handler. An inner action handler may be within the content of the outermost action handler, or it may be executed as the response to an event dispatched while performing all of the actions initiated by the outermost action handler.

Deferred Updates: Sequences of one or more XForms Actions have a deferred effect on XForms model and user interface processing . Implementations are free to use any strategy to accomplish deferred updates, but the end result must be as follows: Instance data changes performed by a set of actions do not result in immediate computation dependency rebuilding, recalculation, revalidate and form control refreshing until the termination of the outermost action handler, as described here. Each XForms model can be thought of as having a set of deferred update Boolean flags, initially false at the start of an outermost action handler, to indicate whether each of the actions rebuild, recalculate, revalidate, and refresh are required for that model upon termination of the outermost action handler.

Execution of an outermost action handler begins by setting the XForms processor into the state of executing an outermost action handler. The outermost action handler is then performed, which may include the execution of inner action handlers. Finally, the XForms processor is set into the state of not executing an outermost action handler and then the deferred update is performed for each model. The deferred update behavior for a model consists of examining each deferred update Boolean flag in the order of rebuild, recalculate, revalidate, and refresh, and for each true flag, set the flag to false and then dispatch the proper event to the model for that deferred update flag (i.e. dispatch xforms-rebuild for a true rebuild flag, xforms-recalculate for a true recalculate flag, xforms-revalidate for a true revalidate flag, and xforms-refresh for a true refresh flag).

Note:

The XForms processor is not considered to be executing an outermost action handler at the time that it performs deferred update behavior for XForms models. Therefore, event handlers for events dispatched to the user interface during the deferred refresh behavior are considered to be new outermost action handler.

Actions that directly invoke rebuild, recalculate, revalidate, or refresh always have an immediate effect, and clear the corresponding deferred update flag. The XForms Actions in this category are:

rebuild
recalculate
revalidate
refresh

XForms Actions that change the tree structure of instance data result in setting all four deferred update flags to true for the model over which they operate. The XForms Actions in this category are:

insert
delete

XForms Actions that change only the value of an instance node results in setting the deferred update flags for recalculate, revalidate, and refresh to true and making no change to the deferred update flag for rebuild for the model over which they operate. The XForms Actions in this category are:

setvalue

Finally, the reset action clears all of the deferred update flags for a model. Similarly, if the default processing of xforms-submit replaces instance data in a model, then the deferred update flags for that model are cleared immediately before the behaviors are peformed for xforms-rebuild, xforms-recalculate, xforms-revalidate, and xforms-refresh.

5.2 Clarify Deferred Update Behavior within Specific Action Subsections

The links to deferred update behavior in several subsections describing actions appeared within text that did not reflect the updated definition of outermost action.

Current specification wording in Section 9.3.5, Section 9.3.6, Section 10.1.3, Section 10.1.4, Section 10.1.5, Section 10.1.6, Section 10.1.9, and Section 10.1.11:

If this action is contained within an action element, it has special deferred update behavior ( 10.1.1 The action Element).

Changed as follows:

This action has special deferred update behavior .

5.3 Further Clarify that rebuild, recalculate, revalidate and refresh Actions Occur Directly

Due to the prior wording of the deferred update behavior, the meaning of the phrase "bypassing the normal event flow" was not clear.

Current specification wording in Section 10.1.3:

bypassing the normal event flow.

Changed specification wording:

bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-rebuild event).

Current specification wording in Section 10.1.4:

bypassing the normal event flow.

Changed specification wording:

bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-recalculate event).

Current specification wording in Section 10.1.5:

bypassing the normal event flow.

Changed specification wording:

bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-revalidate event).

Current specification wording in Section 10.1.6:

bypassing the normal event flow.

Changed specification wording:

bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-refresh event).

5.4 Clarify that the Instance Replacement of a Submission Clears Deferred Update Flags

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.

Current specification wording in Section 11.1, part 5, second bullet point:

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.

Changed specification wording:

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.

6 Clarify that calculate assigns a string

The calculate model item property cannot be used to assign an XML subtree as new content for the associated instance data node.

6.1 Specify that calculate assigns a string value (Section 6.1.5)

Clarify that string() is applied to the result of a calculate expression.

Current specification wording:

Description: supplies an expression used to calculate the value of the associated instance data node.

Changed specification wording:

Description: supplies an expression used to calculate a string value for the associated instance data node.

Current specification wording:

An XForms Model may include model items that are computed from other values.

Changed specification wording:

An XForms Model may include model items whose string values are computed from other values.

Current specification wording:

Changed specification wording:

Such computed values can be expressed with calculate properties, whose XPath expressions are evaluated and converted to strings with the XPath string() function.

7 The load Element

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.

7.1 Clarify that linking attributes is a reference to the resource attribute (Section 10.1.8)

Modify description of load action behavior to refer specifically to the resource attribute rather than linking attributes.

Current specification wording:

Either the Single-Node Binding attributes, pointing to a URI in the instance data, or the linking attributes are required.

Changed specification wording:

Either the Single-Node Binding attributes, pointing to a URI in the instance data, or the resource attribute is required.

7.2 The load Action Behavior on Empty Single-Node Binding (Section 10.1.8)

The load action performs no operation when the Single-Node Binding produces an empty nodeset result.

Current specification wording:

If both are present, the action has no effect.

Changed specification wording:

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.

8 Align Schema with Recommendation for instance Attribute

The instance attribute of the submission element must appear in the schema for the element.

Add to Schema for submission:

<xsd:attribute name="instance" type="xsd:IDREF" use="optional"/>

9 Express an ID attribute in Common Attributes

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

Current Specification Wording from Section 3.2.1:

A host language must permit an attribute of type xsd:ID on each XForms element.

Change Specification Wording:

id

The optional id attribute of type xsd:ID assigns an identity to the containing element.

Add to Schema for Common Attributes group:

<xsd:attribute name="id" type="xsd:ID" use="optional"/>

10 Clarify XForms Type Validation

The descriptions of node validation and of the type model item property are clarified.

10.1 Type Validation (Section 4.3.5)

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.

Current specification wording:

the node satisfies any applicable XML schema definitions (including those associated by the type model item property)

Changed specification wording:

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)

10.2 The type Model Item Property Description (Section 6.1.1)

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.

Current specification wording:

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.

Attaching a XML Schema type constraint
<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.

Changed specification wording:

Description: The type model item property can be applied to both elements and attributes. The type model item property is not applied to instance nodes that contain child elements. The type model item property associates a datatype (as defined in [XML Schema part 2]) with the string-value (as defined in [XPath 1.0]) of an instance node. The datatype being associated can be obtained from a simpleType definition or a simpleContent definition from a complexType. If the datatype cannot be obtained as just described, then the Default Value of xsd:string is used.

Computed Expression: No.

Legal Values: Any xsd:QName representing a datatype definition in an XML Schema.

Default Value: xsd:string.

Inheritance Rules: does not inherit.

Associating datatypes with instance nodes
<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.

11 Recalculation Clarification

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.

Current specification wording in Section 4.3.6:

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.

  1. An XForms Processor should not recalculate computes that are not computationally dependent on one or more of the elements in L.

  2. 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.

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

  4. ...
Changed specification wording:

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.

  1. An XForms Processor must recalculate computes for nodes in L and nodes that are computationally dependent on nodes in L.

  2. 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.

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

  4. ...

12 Clarification of Precedence Rule for value Element

The specification refers to the ref attribute rather than to the term Single Node Binding.

Current specification wording in Section 8.2.3:

If inline content and a ref attribute are both specified, the ref attribute is used.

Changed specification wording:

If inline content and a Single Node Binding are both specified, the Single Node Binding is used.

13 Clarification of User Interface Creation for message Action

The message action must be able to show the current instance data, even if the message content is constructed with output controls.

Current specification wording in Section 10.1.12:

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>

...

Changed specification wording:

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>

...

14 Clarification of Model Construct Behaviors

Withdrawn due to Erratum E29.

15 Clarification of Default Processing of Model Construct Done Event

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.

Current specification wording in Section 4.2.2:

After all form controls have been initialized, an xforms-ready event is dispatched to each model element.

Changed specification wording:

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.

16 Access to Default Instance by instance() Function

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.

16.1 The getInstanceDocument() DOM function (Section 7.3.1)

The getInstanceDocument() function available to DOM implementations provides this correction by allowing the empty string to refer to the default instance.

Current specification wording:

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.

Changed specification wording:

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.

16.2 The instance() XPath function (Section 7.3.1)

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.

Current specification wording:

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.

Changed specification wording:

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.

17 Binding Expressions and Evaluation Context

The meaning and evaluation context of binding expressions and binding expression attributes are clarified.

17.1 Clarify Single-Node Binding Attributes (Section 3.2.3)

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.

Current specification wording:

The following attributes define a binding between a form control or an action and an instance data node defined by an XPath expression.

Changed specification wording:

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.

17.2 Clarify Node-Set Binding Attributes (Section 3.2.4)

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.

Current specification wording:

The following attributes define a binding between a form control or an action and a node-set defined by the XPath expression.

Changed specification wording:

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.

17.3 Evaluation Context (Section 7.4)

Clarify the calculation of evaluation context, especially for generated content.

Current specification wording:

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:

  1. 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.

  2. 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".

  3. The context node always resides within the context model, which is determined choosing the first item that applies from this list:

    1. If a model attribute is present on the binding element, the attribute determines the context model.

    2. If the binding element has an immediately enclosing binding element, the context model of the immediately enclosing binding element is used.

    3. The first model in document order is used.

  4. The context node for computed expressions (occurring on element bind) is the node currently being processed.

  5. 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.

  6. No variable bindings are in place.

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

  8. Any namespace declarations in scope for the attribute that defines the expression are applied to the expression.

Binding Expression Context Nodes
<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:

Sample XML Instance Data
<level1>
  <level2>
    <level3 attr="xyz"/>
  </level2>
</level1>
Changed specification wording:

Within XForms, the default model is the first model in document order. The default instance of any model is the first child instance in document order within that model.. XPath expressions appearing in various XForms attributes are used to reference instance data . Every XPath expression requires an evaluation context consisting of a node, position, size, variable bindings, function set, and namespace context. For all evaluation contexts in XForms,

  1. No variable bindings are in place.

  2. The available function library is defined below in 7.6 XForms Core Function Library .

  3. Any namespace declarations in scope for the attribute that defines the expression are applied to the expression.

  4. 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:

  1. 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.

  2. The context node, position and size for non-outermost binding elements is determined using the binding expression attribute or in-scope evaluation context of the nearest ancestor binding element. This is also referred to as "scoped resolution". For a non-outermost binding element:

    1. 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.

    2. 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.

    3. 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.

    4. 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.

  3. Once the context node of the in-scope evaluation context has been determined according to the rules above, if the binding element expresses a model attribute that refers to a model other than the one containing the context node, then the context node of the in-scope evaluation context is changed to be the top-level document element node of the default instance of the referenced model, and the context position and size are changed to 1.

Note:

The rules above for determining the in-scope evaluation context are applicable to XForms elements that can contain a binding expression attribute even if they cannot contain a Single Node Binding or Node Set Binding. The elements bind and submission are examples.

The in-scope evaluation context of an element that is not a binding element is the same as if the element were a binding element. For example, the in-scope evaluation context for the setindex action element is required to provide the context for evaluating the index attribute, so it is determined as if the element could contain a binding expression attribute.

XPath expressions also appear in model item property attributes of the bind element to define computed expressions. If the bind element does not express a Node Set binding, then the in-scope evaluation context for model item property attributes of the bind is equal to the in-scope evaluation context for the bind. Otherwise, the bind has a Node Set binding, and computed expressions for each model item property attribute are generated for each node. For each computed expression generated, the evaluation context node, position and size are determined by the same method as dynamic in-scope evaluation context rule above, except the computed expression is used in lieu of a binding expression attribute such that the bind element is the nearest ancestor binding element.

XPath expressions also appear in the special attributes of several other XForms elements, such as the value attribute on setvalue and output, the at attribute of insert and delete, or the index attribute of setindex. Generally, if the containing element does not express a Single Node Binding or Node Set Binding, then the special attribute is evaluated using the in-scope evaluation context. Special attributes may be evaluated using the in-scope evaluation context even if the containing element expresses a Single Node Binding or Node Set Binding. However, for some special attributes, the evaluation context node, position and size are based on the result of the Single Node Binding or Node set Binding. Each special attribute that contains an XPath expression describes how its evaluation context node, position and size are determined.

In the following example, the group has a binding expression of level2/level3. According to the rules above, this outermost element node would have a context node of /level1, which is the document element node of the instance data. The select1 form control then inherits a context node from the parent group.

Sample XML Instance Data
<level1>
  <level2>
    <level3 attr="xyz"/>
  </level2>
</level1>
Binding Expression Context Nodes
<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.

17.4 Clarify Binding Expression Definition (Section 7.5)

Binding expressions allow full XPaths, not just PathExpr. This is a missed case from Erratum E67 to XForms 1.0 first edition.

Current specification wording:

A binding expression is an XPath PathExpr ...

Changed specification wording:

A binding expression is an XPath expression ...

17.5 Clarify Function Library for XPaths (Section 7.6)

The specific sections that help define the function library are given to avoid ambiguity.

Current specification wording:

The following sections define additional required functions for use within XForms.

Changed specification wording:

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.

18 The case and toggle Elements

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.

18.1 Default for selected Attribute

Record the default for the selected attribute in schema.

Current schema declaration:

<xsd:attribute name="selected" type="xsd:boolean" use="optional"/>

Changed schema declaration:

<xsd:attribute name="selected" type="xsd:boolean" use="optional" default="false"/>

18.2 Actions in Element case (Section 9.2)

The case element can contain XForms actions because the form author must be able to write handlers for xforms-select and xforms-deselect.

Current specification wording:

Under Minimal Content Model for element case:

label?, (( Form Controls | group|switch|repeat)*

Changed specification wording:

Under Minimal Content Model for element case:

label?, (( Form Controls | Action | group|switch|repeat)*

Current schema declaration:

	<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>

Changed schema declaration:

	<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>

18.3 Order of Events and Behaviors in toggle Action (Section 9.2.3)

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.

Current specification wording:

This action adjusts all selected states (not the attribute values) on the affected cases to reflect the new state of the switch containing the identified case, and then performs the following:

  1. Dispatching an xforms-deselect event to the currently selected case.

  2. Dispatching an xform-select event to the case to be selected.

Changed specification wording:

This action performs the following:

  1. Dispatches an xforms-deselect event to the currently selected case in the switch containing the identified case.

  2. Adjusts the selected states (not the attribute values) on the affected cases to reflect the new state of the switch containing the identified case.

  3. Dispatches an xform-select event to the case just selected.

19 Defaults for bubbles and cancelable Attributes of dispatch

When dispatching 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.

Current specification wording (Section 10.1.2):

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.

Changed specification wording:

Optional boolean indicating if this event bubbles—as defined in [DOM2 Events]. The default value is true for a custom event. For predefined events, this attribute has no effect.

Current specification wording (Section 10.1.2):

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.

Changed specification wording:

Optional boolean indicating if this event is cancelable—as defined in [DOM2 Events]. The default value is true for a custom event. For predefined events, this attribute has no effect.

20 The action Attribute on submission is Optional

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.

Current specification wording (Section 3.3.3):

Required destination URI...

Changed specification wording:

Optional attribute indicating the destination URI ...

21 The method Attribute includes multipart-post

The XForms schema omitted multipart-post from the enumeration defined for the method attribute.

Current schema declaration:

	<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>

Changed schema declaration:

	<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>

22 Clarifications for Binding Attributes

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.

22.1 Single-Node Binding (Section 3.2.3)

Current specification wording:

XForms Model selector. Specifies the ID of an XForms Model to be associated...

Changed specification wording:

Optional XForms Model selector. Specifies the ID of an XForms Model to be associated...

Current specification wording:

One of ref or bind is required. When bind is used, the node is determined by the referenced bind.

Changed specification wording:

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.

22.2 Node-Set Binding (Section 3.2.4)

Current specification wording:

XForms Model selector. Specifies the ID of an XForms Model to be associated...

Changed specification wording:

Optional XForms Model selector. Specifies the ID of an XForms Model to be associated...

Current specification wording:

One of nodeset or bind is required. When bind is used, the node-set is determined by the referenced bind.

Changed specification wording:

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.

23 Attributes of bind Element are Optional

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

Current specification wording (Section 3.3.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:

nodeset

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.

Changed specification wording:

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:

nodeset

An optional attribute containing a model binding expression that selects the set of nodes on which this bind operates .

See 7.4 Evaluation Context for details on how the evaluation context is determined for each attribute of the bind element..

24 Clarification of Optional Attributes in Form Controls

This erratum clarifies that the inputmode, appearance, value and mediatype attributes on form controls are optional.

Current specification wording (Section 8.1.2 The input Element):

This form control accepts an input mode hint...

Changed specification wording:

Optional. This form control accepts an input mode hint...

Current specification wording (Section 8.1.3 The secret Element):

This form control accepts an input mode hint...

Changed specification wording:

Optional. This form control accepts an input mode hint...

Current specification wording (Section 8.1.4 The textarea):

This form control accepts an input mode hint...

Changed specification wording:

Optional. This form control accepts an input mode hint...

Current specification wording (Section 8.1.5 The output Element):

This form control does not use the UI Common attribute group, but nevertheless still contains an appearance attribute, as defined above.

Changed specification wording:

This form control does not use the UI Common attribute group, but nevertheless still contains an optional appearance attribute, as defined above.

Current specification wording for 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.

Changed specification wording:

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.

Current specification wording (Section 8.1.6 The upload Element):

Space-separated list of suggested media types, used by the XForms Processor to determine the possible sources of data to upload.

Changed specification wording:

Optional. Space-separated list of suggested media types, used by the XForms Processor to determine the possible sources of data to upload.

25 Single Node Binding Misnamed on input Element

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.

Current specification wording (Section 8.1.2):

Single Node UI Binding

Changed specification wording:

Single Node Binding

26 The resource Attribute is Optional on the load Element

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.

Current specification wording for resource attribute in Section 10.1.8 The load Element:

Link to external resource to load...

Changed specification wording:

Optional. Link to external resource to load...

27 Event Sequence for submit Element

The relationship between the DOMActivate event on the submit element and the dispatch of the xforms-submit event is corrected.

Current specification wording (Section 8.1.9):

Implementation Requirements: Upon receiving event DOMActivate, this form control dispatches event xforms-submit to the submission element specified by required attribute submission.

Changed specification wording:

Implementation Requirements: The default action for event DOMActivate is to dispatch event xforms-submit to the submission element specified by required attribute submission.

28 Data Model Update on 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.

Current specification wording (Section 11.1):

Otherwise, default action for this event results in the following steps:

Changed specification wording:

Otherwise, the default action for this event results in the following steps:

  1. 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.

29 Corrections to the Behaviors of xforms-rebuild and xforms-model-construct

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.

29.1 Amend Default Processing of xforms-model-construct (Section 4.2.1)

Remove bind processing from model construction and make two other editorial adjustments.

Current specification wording:

The default action for this event results in the following:

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

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

  3. If applicable, P3P initialized. [P3P 1.0]

  4. 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:

    1. The attribute nodeset attached to the bind is evaluated, resulting in a set of nodes selected.

    2. 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.

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

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

Changed specification wording:

The default action for this event results in the following:

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

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

  3. If applicable, P3P initialized. [P3P 1.0]

  4. Perform the behaviors of xforms-rebuild, xforms-recalculate, and xforms-revalidate in sequence 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.

29.2 Amend Default Processing of xforms-rebuild (Section 4.3.7)

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.

Current specification wording:

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.

Changed specification wording:

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:

  1. 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.

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

  3. 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.

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.

30 Clarifications to the Marking Notification Events for Dispatching

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.

30.1 Amend Notification Event Marking in xforms-recalculate (Section 4.3.6)

Current specification wording:

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.

Changed specification wording:

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

30.2 Amend Notification Event Marking in xforms-revalidate (Section 4.3.5)

Current specification wording:

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.

Changed specification wording:

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

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)

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.

Current specification wording:

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.

Changed specification wording:

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.

Removed specification wording:

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.

31.2 Rigorously Define Non-relevant Form Control (Section 8.1.1)

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.

Current specification wording:
  • Form controls must provide a default explanation for the above when no user-specified explanation is available.

Changed specification wording:
  • 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.

31.3 Rigorously Define Non-relevant Group (Section 9.1.1)

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.

Current specification wording:

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.

Changed specification wording:

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.

31.4 Non-Relevance and the switch Element (Section 9.2.1)

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.

Current specification wording:

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?'.

Changed specification wording:

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.

31.5 Non-selected case Elements (Section 9.2.2)

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.

Current specification wording:

This element encloses markup to be conditionally rendered. The attribute selected determines the initial selected state.

Changed specification wording:

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.

32 Resolving ID References in Repeated Content, and Switch in Repeat

32.1 Single-Node Bindings (Section 3.2.3)

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.

Current specification wording:

When bind is used, the node is determined by the referenced bind.

Changed specification wording:

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.

32.2 Node-Set Bindings (Section 3.2.4)

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.

Current specification wording:

When bind is used, the node-set is determined by the referenced bind.

Changed specification wording:

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.

32.3 Resolving IDREFs to Repeated Content (Section 4)

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.

Add specification wording:

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.

4.7.1 References to Elements within a repeat 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.

4.7.2 References to Elements within a bind Element

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.

32.4 Note in index() Function (Section 7.8.5)

The index() function must be able to return the index of a repeated repeat.

Add specification wording:

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.

32.5 Note in toggle Action (Section 9.2.3)

The toggle action must be able to toggle the case of a repeated switch.

Add specification wording:

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.

32.6 Add switch to Content Model of repeat (Section 9.2.3)

The toggle action must be able to toggle the case of a repeated switch.

Current specification wording in Section 9.3:
ElementAttributesMinimal Content Model
repeatCommon, UI Common, Node Set Binding, startindex (xsd:positiveInteger), number (xsd:nonNegativeInteger)((Form Controls)|group|repeat)*
Change specification wording:
ElementAttributesMinimal Content Model
repeatCommon, UI Common, Node Set Binding, startindex (xsd:positiveInteger), number (xsd:nonNegativeInteger)((Form Controls)|group|switch|repeat)*
Current schema declaration:

<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>
	                    

Changed schema declaration:

<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>
	                    

32.7 Note in setindex Action (Section 9.3.7)

The setindex action must be able to set the index of a repeated repeat.

Add specification wording:

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.

32.8 Amend Repeat User Interaction (Section 9.3.10)

Replace wording that calls for more implementation experience with wording that describes the results of the experience.

Current specification wording:

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.

Changed specification wording:

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.

32.9 Note in dispatch Action (Section 10.1.2)

The dispatch action must be able to dispatch its event to repeated elements.

Add specification wording:

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.

32.10 Note in setfocus Action (Section 10.1.7)

The setfocus action must be able to dispatch its event to repeated elements.

Add specification wording:

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.

33 Input Focus and Repeat Index

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.

Append specification wording to Section 9.3.10:

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.

34 Clarify Namespace Context Used in type Attribute

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.

34.1 Better Indication of Namespace for Implicit Datatypes (Section 5.1)

Amend the implicit datatypes.

Current specification wording:

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 *

Changed specification wording:

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 *

34.2 Namespace Context for type Attribute (Section 6.1.1)

The namespace context used to interpret the type attribute value is given.

Current specification wording:

Legal Values: Any xsd:QName representing a datatype definition in an XML Schema.

Changed specification wording:

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.

35 Clarify the model selected when model attribute is omitted

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.

Current specification wording in Section 10.1.3, Section 10.1.4, Section 10.1.5, Section 10.1.6, and Section 10.1.11:

Optional XForms Model selector, as defined in Section 3.2.3.

Changed specification wording in Section 10.1.3, Section 10.1.4, Section 10.1.5, Section 10.1.6, and Section 10.1.11:

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.

36 Clarify that a Violation of a Binding Restriction results in xforms-binding-exception

Clarify that the data binding restrictions are enforced.

Current specification wording:

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.

Changed specification wording:

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.

37 The itemset Element is not a Target for xforms-select/xforms-deselect

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.

37.1 Target List for xforms-select/xforms-deselect (Section 4.4.3)

Remove itemset from the target list.

Current specification wording:

Target: item or itemset or case

Changed specification wording:

Target: item or case

37.2 Description of itemset (Section 9.3.3)

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

Current specification wording:

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.

Changed specification wording:

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

38 Clarify that the behavior of help and hint occurs as default action.

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.

Current specification wording from Section 8.3.4:

This is equivalent to a <message level="modeless" ev:event="xforms-help" ev:propagate="stop">.

Remove the above wording from Section 8.3.4.

Current specification wording from Section 8.3.5:

This is equivalent to a handler for event xforms-hint that responds with a <message level="ephemeral">.

Remove the above specification wording from Section 8.3.5.

39 Lexicographically Order the Glossary

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.

40 Consistent Use of QNameButNotNCNAME

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.

41 Versioning XForms Content

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.

41.1 Add version attribute to model

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.

Current specification wording:

..., functions (QNameList), schema (list of xsd:anyURI)

Changed specification wording in Section 3.3:

..., functions (QNameList), schema (list of xsd:anyURI), version xforms:versionList

Add Specification Wording to Section 3.3.1:

version

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.

41.2 Add xforms-version-exception

It is necessary to add an exception type, xforms-version-exception, to indicate the failure of a version check.

Add specification wording to the events overview table in Section 4.1:

Event nameCancelable?Bubbles?Target element
xforms-version-exceptionNoYesthe default model

Add specification wording to Section 4.5:

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.

41.3 Terminology used to define version

The description of the version attribute depends on datatype definitions provided here.

Add specification wording to Section 13:

versionList

[Definition: A list ([XML Schema part 2]) with an atomic datatype ([XML Schema part 2]) of versionNumber.]

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+".]

41.4 The version attribute in the XForms Schema

The version attribute described by the rest of this erratum should also appear in the XForms 1.0 schema.

Add to declaration of model element:

<xsd:attribute name="version" type="xforms:versionList" use="optional"/>

Add to new simpleTypes:

<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>

A References

A.1 Normative References from XForms 1.0

DOM2 Events
Document Object Model (DOM) Level 2 Events Specification, Tom Pixley, 2000. W3C Recommendation available at: http://www.w3.org/TR/DOM-Level-2-Events/.
XPath 1.0
XML Path Language (XPath) Version 1.0, James Clark, Steve DeRose, 1999. W3C Recommendation available at: http://www.w3.org/TR/xpath.
XML Schema part 2
XML Schema Part 2: Datatypes, Paul V. Biron, Ashok Malhotra, 2001. W3C Recommendation available at: http://www.w3.org/TR/xmlschema-2/.

A.2 Informative References from XForms 1.0

P3P 1.0
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, Lorrie Cranor, Marc Langheinrich, Massimo Marchiori, Martin Presler-Marshall, Joseph Reagle, 2001. W3C Last Call Working Draft available at: http://www.w3.org/TR/P3P/.

B Select Terms from the Glossary of XForms 1.0

XForms Processor

[Definition: A software application or program that implements and conforms to the XForms specification.]