Appendix

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.

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.

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

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.

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:

rebuildrecalculaterevalidaterefresh

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:

insertdelete

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: ManySequences of one or more XForms
Actions have a deferred effect on the
instance dataXForms model
and user interface processingwhen 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
handlerXForms
model can be thought of as having a set of deferred update Boolean flags,
initially falseat 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:

rebuildrecalculaterevalidaterefresh

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

insertdelete

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 rebuildfor the model over which they
operate. The XForms Actions in this category are:

setvalue

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

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.

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

10 Clarify XForms Type Validation

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.

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.

Here, we have illustrated two ways in which an XML Schema type can
be associated with an element.

Changed specification wording:

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

Computed Expression: No.

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

Default Value: xsd:string.

Inheritance Rules: does not inherit.

The effect of this model item property is the same as placing
attribute xsi:type on the instance data. However, in
contrast to xsi:type, type can be added to
both elements and attributes.

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.

When a recalculation event begins, there will be a list L
of one or more instance nodes whose values have been changed, e.g., by
user input being propagated to the instance.

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

An XForms Processor should perform only a single recalculation
of each compute that is computationally dependent on one or more of
the elements in L.

An XForms Processor must recalculate a compute C
after recalculating all computes of instance nodes on which
C is computationally dependent. (Equivalently, an XForms
Processor must recalculate a compute C before
recalculating any compute that is computationally dependent on the
instance node associated with C.)

...

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.

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

An XForms Processor must perform only a single
recalculation of each compute that is computationally dependent on
one or more of the elements in L.

An XForms Processor must recalculate a compute C
after recalculating all computes of instance nodes on which
C is computationally dependent. (Equivalently, an XForms
Processor must recalculate a compute C before
recalculating any compute that is computationally dependent on the
instance node associated with C.)

...

12 Clarification of Precedence Rule for value
Element

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

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

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:

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

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.

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.

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.

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

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.

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.

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:

The context node for outermost binding elements is the
top-level element node, or the single node returned by
/*. A binding element is any element that is
explicitly allowed to have a binding expression attribute. A
binding element is "outermost" when the node-set returned by
the XPath expression ancestor::* includes no binding
element nodes.

The context node for non-outermost binding elements is the
first node of the binding expression of the immediately enclosing
element. An element is "immediately enclosing" when it is
the first binding element node in the node-set returned by the
XPath expression ancestor::*. This is also referred to
as "scoped resolution".

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

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

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

The first model in document order is used.

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

For Single-Node binding expressions, the context size and
position are 1. For Nodeset binding expressions, the context size
is the size of the node-set, and the context position is the
document order position of the node currently being processed
within the node-set.

No variable bindings are in place.

The available function library is defined below, plus any
functions supplied by the implementation. Extension functions
required for operation of the form should be declared, as described
at 7.12
Extension Functions.

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

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 abstract instance data , instead of a concrete XML document. This
reference is called a binding
expression in this specification. Every XPath
expression requires an evaluation context consisting of a node, position, size, variable
bindings, function set, and namespace context. For all
evaluation contexts in XForms,

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

The context node, position and size are determined according
to rules described below.

A binding element is any element that is explicitly allowed
to have a binding expression attribute, and a bound element is any element that
explicitly declares a binding expression attribute. A
binding expressionattribute contains an XPath
expression that references zero or more nodes of instance data. Every
XPath expression requires an evaluation context. The in-scope evaluation context of a
binding element provides an evaluation context for the binding
expression attribute. The following rules are used in determining the
node, position and size of the in-scope evaluation
context:

A binding element is "outermost" if the element has no
ancestor binding elements. If an outermost binding element is
contained by a model, then the context node for the
outermost binding element is the top-level document element node of the default instance of the containing
model element. Otherwise, the context
node for outermost binding elements is the top-level document element node of the default instance in the default
model. For outermost binding elements, the context size and
position are 1., or the
single node returned by /*.

The context node, position and
size for non-outermost binding elements is the first node ofdetermined using the binding
expression attribute or in-scope
evaluation context of the immediately enclosingnearest ancestor binding
element. An element is "immediately
enclosing" when it is the first binding element node in the
node-set returned by the XPath expression
ancestor::*. This is also referred to as
"scoped resolution". For a non-outermost binding element:

If the nearest ancestor binding element is not a bound
element, then the in-scope evaluation context of the
non-outermost binding element is equivalent to the in-scope
evaluation context of the nearest ancestor binding element.

If the nearest ancestor binding element expresses a
Single-Node binding, then the in-scope evaluation context of
the non-outermost binding element has a context size and
position of 1 and the context node is the one resulting from
the Single-Node binding of the nearest ancestor binding
element.

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

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

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

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

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

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

The first model in document order is used.

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

For Single-Node binding expressions, the context size and
position are 1. For Nodeset binding expressions, the context size
is the size of the node-set, and the context position is the
document order position of the node currently being processed
within the node-set.

Note:

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

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

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

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

In the following example,
the group has a binding expression of
level2/level3. According to the rules above, this
outermost element node would have a context node of
/level1, which is the top-leveldocument element node of the
instance data. The select1 form control then inherits a
context node from the parent 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.

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.

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:

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

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

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

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

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

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

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.

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 depends on the definition ofis true for a custom
event. For predefined events, this attribute has no effect.

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

Changed specification wording:

Optional boolean indicating if this event is cancelable—as
defined in [DOM2 Events]. The default
value depends on the definition
ofis 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.

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.

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.

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.

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.

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.

27 Event Sequence for submit Element

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: Upon
receivingThe default action
for event DOMActivate, this form control dispatchesis 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.

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:

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.

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:

All XML Schemas loaded. If an error occurs while attempting to
access or process a remote document, processing halts with an
exception (Section
4.5.2).

If an external source for the initial instance data is given,
an XPath data model [Section
7]. is constructed from it; otherwise if inline initial
instance data is given, that is used instead. If the external
initial instance data is not well-formed XML or cannot be
retrieved, processing halts with an exception (Section
4.5.2). If neither are given, the data model is not constructed
in this phase, but during user interface construction (Section
4.2.2).

Instance data is constructed. All strings inserted into the
instance data are subject to Unicode normalization. All model item
properties are initialized by processing all bind
elements in document order. For each bind:

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

For each node in the node-set, model item properties are
applied according to the remaining attributes on
bind: the string value of each attribute (with a
name matching one of the properties defined in Section
6.1). is copied as the local value of the model item
property of the same name.

If the node already contains a model item property of the
same name, XForms processing for this containing document halts
with an exception (Section
4.5.1).

Perform xforms-rebuild,
xforms-recalculate, and xforms-revalidate
in sequence, for this model element. (The
xforms-refresh is not performed since the user
interface has not yet been initialized).

Changed specification wording:

The default action for this event results in the following:

All XML Schemas are
loaded. If an error occurs while attempting to
access or process a remote document, processing halts with an
exception (Section
4.5.2).

If an external source for the initial instance data is given,
an XPath data model [Section
7]. is constructed from it; otherwise if inline initial
instance data is given, that is used instead. If the external
initial instance data is not well-formed XML or cannot be
retrieved, processing halts with an exception (Section
4.5.2). If neither are given, then
default processing of this event ends because the
data model is not constructed in this phase, but during user
interface construction (Section
4.2.2).

Instance data is constructed. All strings inserted into the
instance data are subject to Unicode normalization. All model item
properties are initialized by processing all bind
elements in document order. For each bind:

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

For each node in the node-set, model item properties are
applied according to the remaining attributes on
bind: the string value of each attribute (with a
name matching one of the properties defined in Section
6.1). is copied as the local value of the model item
property of the same name.

If the node already contains a model item property of the
same name, XForms processing for this containing document halts
with an exception (Section
4.5.1).

Perform the behaviors of
xforms-rebuild,
xforms-recalculate, and xforms-revalidate
in sequence , foron this model
element without dispatching events to
invoke the behaviors. (The notification event markings for these
operations are discarded, and the xforms-refreshbehavior
is not performed since the user interface has not
yet been initialized).

Add bind processing text formerly described in xforms-model-construct, and
amend it to be more accurate regarding the storage of model item property
values.

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:

If the attribute nodeset is attached to the bind,
it is evaluated to select an XPath node-set. Otherwise, if the
bind does not have a nodeset attribute,
then the selected XPath node-set consists of the in-scope
evaluation context.

For each node in the selected XPath node-set, model item
properties are applied according to the remaining attributes on the
bind element (for details on the model item
properties, see Section
6). If a node already contains a model item property of the
same name due to the processing of prior bind
elements, then XForms processing for the containing document halts
with an exception (Section
4.5.1).

For each node in the selected XPath node-set, any child
bind elements are recursively processed as described
in the three points of this list.

The default action for this event is
thatAfter 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-recalculateis 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.

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-revalidate and
xforms-refresh to determine the notification events to dispatch.

If the required model item property changes, then either the
xforms-required event must be marked for dispatch if required is
true or the xforms-optional event must be marked for dispatch if
required is false. Marking one of
these events for dispatch unmarks the other.

If the readonly model item property changes, then either the
xforms-readonly event must be marked for dispatch if readonly is
true or the xforms-readwrite event must be marked for dispatch if
readonly is false. Marking one of
these events for dispatch unmarks the other.

If the relevant model item property changes, then either the
xforms-enabled event must be marked for dispatch if relevant is
true or the xforms-disabled event must be marked for dispatch if
relevant is false. Marking one of
these events for dispatch unmarks the other.

All instance data nodes in all instance elements in
the model are checked for validity according to the above
definition. If the validity of a node changes, then the node is marked
for dispatching the appropriate notification event (xforms-valid or
xforms-invalid) to bound form controls during xforms-refresh as
follows:

If the node changes from invalid to valid, then the node is
marked for dispatching the xforms-valid event.

If the node changes from valid to invalid, then the node is
marked for dispatching the xforms-invalid event.

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 the node is marked for dispatching the
appropriate notification event (xforms-valid or xforms-invalid) to
bound form controls during xforms-refresh as follows:either the xforms-valid event must be
marked for dispatch if the node changes from valid to invalid or the
xforms-invalid event must be marked for dispatch if the node changes
from valid to invalid. Marking one of these events for dispatch unmarks
the other.

If the node changes from invalid to valid, then the node is
marked for dispatching the xforms-valid event.

If the node changes from valid to invalid, then the node is
marked for dispatching the xforms-invalid event.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 interaction that is presented to the
user. As a consequence, it is not possible to refer to portions of the
generated user interface via statically authored idref
attributes. A necessary consequence of this is that XForms 1.0 does not
specify the behavior of construct switch within element
repeat. Future versions of XForms may specify the behavior
of switch inside repeat based on
implementation experience and user feedback.

Notice that the markup encapsulated by element repeat
acts as the template for the user interface that is presented to the
user. As a consequence, statically authored IDREF
attributes must be interpreted based on a combination of repeat indexes
and where the IDREF attributes appear relative to the element bearing
the matching ID. Based on the IDREF resolution rules given in 4.7 Resolving ID References in XForms it is
possible to toggle the case of a switch even
when it is within one or more repeat elements. Similarly,
it is possible to set the focus to controls and dispatch events to
elements that are within one or more repeat elements.

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

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.

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.

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.

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.

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)

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.

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 attribute nodesetthe 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 choiceswith
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.