XForms 1.0 Second Edition Recommendation Errata

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 0 if the homogeneous collection contains less than startindex items.

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.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.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.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 operation is associated with special deferred update behavior. Submit processing then concludes after dispatching xforms-submit-done.

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

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.

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.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.The context node for outermost binding elements is the top-level document element node of the default instance in the default model, and the context size and position are 1.

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 expressing a Single-Node binding, then the in-scope evaluation context of the non-outermost binding element has a context size and position of 1 and the context node is the one resulting from the Single-Node binding of the nearest ancestor binding element.

   3. If the nearest ancestor binding element expressing a Node Set binding, then the XForms processor dynamically generates an occurrence of the non-outermost binding element for each of the nodes in the Node Set Binding of the nearest ancestor binding element. The dynamic in-scope evaluation context for each generated occurrence of the non-outermost binding element has a context size equal to the size of the nodeset identified by the Node Set Binding of the nearest ancestor binding element, the context node is the node for which the occurrence of the non-outermost binding element was generated, and the position is equal to the position of the generator node in the nodeset identified by the Node Set Binding of the nearest ancestor binding element.

   4. If the nearest ancestor binding element expressing a Node Set binding, then the non-outermost binding element has its own in-scope evaluation context separately from those of its dynamically generated occurences described above. The in-scope evaluation context has a context position of 1, and the context node and size are set by the first node and the size of the nodeset identified by the Node Set binding of the nearest ancestor binding element.

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

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.