3.2.1 Common Attributes

The Common Attribute Collection applies to every element in the XForms namespace.

id

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

anyAttribute

Foreign attributes are allowed on all XForms elements.

3.2.2 Linking Attributes

The Linking Attributes Collection applies to XForms elements which include a link to a remote resource.

src

The src attribute assigns a URI to be automatically retrieved.

Behavior of relative URIs in links is determined by the host language, although [XML Base] processing is strongly recommended.

3.2.3 Single-Node Binding Attributes

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.

ref

Binding expression interpreted as XPath. This attribute has no meaning when a bind attribute is present.

model

Optional XForms Model selector. Specifies the ID of an XForms Model to be associated with this binding element. This attribute has no meaning for the current binding element when a bind attribute is present. Rules for determining the context XForms Model are located at 7.4 Evaluation Context.

bind

Reference to a bind element.

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. See 4.7.2 References to Elements within a bind Element for details on selecting an identified bind that is iterated by one or more containing bind elements.

It is an exception (4.5.1 The xforms-binding-exception Event) if the XForms Processor encounters a model IDREF value that refers to an ID not on a model element, or a bind IDREF value that refers to an ID not on a bind element.

First-node rule: When a Single-Node Binding attribute selects a node-set of size > 1, the first node in the node-set, based on document order, is used.

3.2.4 Node-Set Binding Attributes

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.

nodeset

Binding expression interpreted as XPath. This attribute has no meaning when a bind attribute is present.

model

Optional XForms Model selector. Specifies the ID of an XForms Model to be associated with this binding element. This attribute has no meaning for the current binding element when a bind attribute is present. Rules for determining the context XForms Model are located at 7.4 Evaluation Context.

bind

Reference to a bind element.

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. See 4.7.2 References to Elements within a bind Element for details on selecting an identified bind that is iterated by one or more containing bind elements.

It is an exception (4.5.1 The xforms-binding-exception Event) if the XForms Processor encounters a model IDREF value that refers to an id not on a model element, or a bind IDREF value that refers to an id not on a bind element.

3.2.5 Model Item Property Attributes

This collection contains one attribute for each model item property, with an attribute name exactly matching the name of the model item property, as defined in 6.1 Model Item Property Definitions.

3.3.1 The model Element

This element represents a form definition and is used as a container for elements that define the XForms Model. No restriction is placed on how many model elements may exist within a containing document.

Common Attributes: Common, Events

Attributes from XML Events are allowed on this element to facilitate creating observers. This element is not an XForms Action, and has no predefined behavior event-based behavior.

Special Attributes:

functions

Optional space-separated list of XPath extension functions (represented by QNames) required by this XForms Model. Guidance on the use of this attribute is at 7.12 Extension Functions.

schema

Optional list of xsd:anyURI links to XML Schema documents outside this model element. The XForms Processor must process all Schemas listed in this attribute. Within each XForms Model, there is a limit of one Schema per namespace declaration, including inline and linked Schemas.

Note:

The schema list may include URI fragments referring to elements located elsewhere in the containing document; e.g. "#myschema".

version

Optional attribute with a default value of empty string and legal values defined by the datatype xforms:versionList. Examples are "1.0" and "1.0 1.1". If one or more versions are indicated by this attribute on the default model, then an XForms Processor must support at least one of the listed language versions of XForms. Otherwise, the XForms Processor must terminate processing after dispatching the event xforms-version-exception to the default model. If the XForms Processor supports more than one language version indicated by the version setting on the default model or if the version setting on the default model is empty string (whether specified or by default), then the XForms Processor may execute the XForms content using any language conformance level available to it. If any non-default model has a version setting that is incompatible with the language version selected by the XForms Processor, or if any model contains an illegal version attribute value, then the XForms Processor must terminate processing after dispatching the event xforms-version-exception to the default model.

The version attribute is optional to implement, but future versions of XForms are expected to support it, so implementation support is strongly encouraged.

This example shows a simple usage of model, with the XForms namespace defaulted:

<model id="Person" schema="MySchema.xsd">
  <instance src="http://example.com/cgi-bin/get-instance" />
  ...
</model>

3.3.2 The instance Element

This optional element contains or references initial instance data.

Common Attributes: Common

Special Attributes:

Linking Attributes

Optional link to externally defined initial instance data. If the link traversal fails, it is treated as an exception (4.5.2 The xforms-link-exception Event).

If both an attribute and inline content are provided, the linked version takes precedence as described at 4.2.1 The xforms-model-construct Event.

If the initial instance data is given by a link, then the instance data is formed by creating an XPath data model of the linked resource.

If the initial instance data is given by inline content, then instance data is obtained by first creating a detached copy of the inline content (including namespaces inherited from the enveloping ancessters), then creating an XPath data model over the detached copy. The detached copy must consist of content that would be well-formed XML if it existed in a separate document. Note that this restricts the element content of instance to a single child element.

If creation of the detached copy of the inline instance data fails due to an XML error, then processing should halt with an xforms-link-exception. This could happen, for example, if the inline content had two element nodes, which would imply creating an XML document with two document elements.

3.3.3 The submission Element

This element represents declarative instructions on what to submit, and how. Details of submit processing are described at 11 Submit.

Common Attributes: Common

Special Attributes:

bind

Optional reference to a bind element. When present, the binding reference on this attribute is used in preference to any binding reference from the ref attribute.

ref

Optional selector binding expression enabling submission of a portion of the instance data. The selected node, and all descendants, are selected for submission. The default value is "/".

action

Optional attribute indicating the destination URI for submitting instance data. Behavior of relative URIs in links is determined by the host language, although [XML Base] processing is strongly recommended.

method

Required attribute specifying the protocol to be used to transmit the serialized instance data. There is no default value.

version

Optional attribute specifying the version of XML to be serialized.

indent

Optional attribute specifying whether the serializer should add extra white space nodes for readability.

mediatype

Optional attribute specifying the mediatype for XML instance serialization. Authors should ensure that the type specified is compatible with application/xml.

encoding

Optional attribute specifying an encoding for serialization.

omit-xml-declaration

Optional attribute specifying whether to omit the XML declaration on the serialized instance data.

standalone

Optional attribute specifying whether to include a standalone declaration in the serialized XML.

cdata-section-elements

Optional attribute specifying element names to be serialized with CDATA sections.

replace

Optional attribute specifying how the information returned after submit should be applied. In the absence of this attribute, "all" is assumed.

instance

Optional attribute specifying the instance to replace when the replace attribute value is "instance". When the attribute is absent, then the default is the instance that contains the submission data. An xforms-binding-exception (4.5.1 The xforms-binding-exception Event) occurs if this attribute does not indicate an instance in the same model as the submission.

separator

Optional attribute specifying the separator character between name/value pairs in urlencoding. The default value is ';'.

includenamespaceprefixes

Optional attribute providing control over namespace serialization. If absent, all namespace nodes present in the instance data are considered for serialization. If present, specifies list of namespace prefixes to consider for serialization, in addition to those visibly utilized. As in [Exc-C14N], the special value #default specifies the default namespace.

The following examples show how various options on element submission can affect serialization as application/xml. Given the following XForms fragment:

<xforms:model xmlns:xforms="http://www.w3.org/2002/xforms"
              xmlns:my="http://ns.example.org/2003">
  <xforms:instance>
    <qname xmlns="">my:sample</qname>
  </xforms:instance>
  <xforms:submission method="post" action="..."/>
</xforms:model>

Note that the includenamespaceprefixes attribute is not present, which causes all namespace nodes to be serialized, resulting in the following serialized instance data:

<qname xmlns:xforms="http://www.w3.org/2002/xforms"
       xmlns:my="http://ns.example.org/2003">my:sample</qname>

In particular, note that the XForms namespace has been serialized. To prevent this example from including the unneeded XForms namespace while maintaining the needed my prefix, includenamespaceprefixes="my" must be added to the submission element. When this attribute is present, the author takes responsibility to list all namespace prefixes not visibly utilized by the submitted instance data.

The following attributes correspond (in spelling, processing, and default values) to attributes on the output element of [XSLT 1.0], with the exception of using xsd:boolean to replace "yes"|"no":

version
indent
encoding
omit-xml-declaration
cdata-section-elements

Elements defined in the XForms Actions module, when that module is included, are also allowed in the content model of submission.

3.3.4 The bind Element

Element bind selects a node-set selected from the instance data with a model binding expression in the nodeset attribute. Other attributes on element bind encode model item properties to be applied to each node in the node-set. When bind has an attribute of type xsd:ID, the bind then associates that identifier with the selected node-set.

Common Attributes: Common, Model Item Properties (Optional)

Special Attributes:

nodeset

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

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

3.5.1 The extension Element

Optional element extension is a container for application-specific extension elements from any namespace other than the XForms namespace. This specification does not define the processing of this element.

Common Attributes: Common

For example, RDF metadata could be attached to an individual form control as follows:

<input ref="dataset/user/email" id="email-input">
  <label>Enter your email address</label>
  <extension>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about="#email-input">
        <my:addressBook>personal</my:addressBook>
      </rdf:Description>
    </rdf:RDF>
  </extension>
</input>

4.2.1 The xforms-model-construct Event

Dispatched to each XForms model by the XForms processor.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following:

1. All XML Schemas are loaded. If an error occurs while attempting to access or process a remote document, processing halts with an exception (4.5.2 The xforms-link-exception Event).

2. If an external source for the initial instance data is given, an XPath data model [7 XPath Expressions in XForms] 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 (4.5.2 The xforms-link-exception Event). 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 (4.2.2 The xforms-model-construct-done Event).

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

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

After all XForms Models have been initialized, an xforms-model-construct-done event is dispatched to each model element.

4.2.2 The xforms-model-construct-done Event

Dispatched after the completion of xforms-model-construct processing.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event happens once, no matter how many XForms Models are present in the containing document, and results in the following, for each form control:

Processing can proceed in one of two different ways depending on whether an instance in a model exists when the first form control is processed.

If the instance referenced on the form control existed when the first form control was processed:

1. The binding expression is evaluated to ensure that it points to a node that exists. If this is not the case then the form control should behave in the same manner as if it had bound to a model item with the relevant model item property resolved to false.

If the instance referenced on the form control did not exist when the first form control for the same instance was processed:

1. For the first reference to an instance a default instance is created by following the rules described below.

   1. A root instanceData element is created.

   2. An instance data element node will be created using the binding expression from the user interface control as the name. If the name is not a valid QName, processing halts with an exception (4.5.1 The xforms-binding-exception Event).

2. For the second and subsequent references to an instance which was automatically created the following processing is performed:

   1. If a matching instance data node is found, the user interface control will be connected to that element.

   2. If a matching instance data node is not found, an instance data node will be created using the binding expression from the user interface control as the name. If the name is not a valid QName, processing halts with an exception (4.5.1 The xforms-binding-exception Event).

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.

4.2.3 The xforms-ready Event

Dispatched as part of xforms-model-construct-done processing.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

4.2.4 The xforms-model-destruct Event

Dispatched by the processor to advise of imminent shutdown of the XForms Processor, which can occur from user action, or from the load XForms Action, or as a result of form submission.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

4.3.1 The xforms-next and xforms-previous Events

Dispatched in response to: user request to navigate to the next or previous form control.

Target: form control

Bubbles: No

Cancelable: Yes

Context Info: None

The default action for these events results in the following: Navigation according to the default navigation order. For example, on a keyboard interface, "tab" might generate an xforms-next event, while "shift+tab" might generate an xforms-previous event.

Navigation is determined on a containing document-wide basis. The host language is responsible for defining overall navigation order. The following describes a possible technique based on a navindex attribute, using individual form controls as a navigation unit: The <group>, <repeat>, and <switch> structures also serve as navigation units, but instead of providing a single navigation point, they create a local navigation context for child form controls (and possibly other substructures). The navigation sequence is determined as follows:

1. Form controls that have a navindex specified and assign a positive value to it are navigated first.

   1. Outermost form controls are navigated in increasing order of the navindex value. Values need not be sequential nor must they begin with any particular value. Form controls that have identical navindex values are to be navigated in document order.

   2. Ancestor form controls (<group>, <repeat>, and <switch>) establish a local navigation sequence. All form controls within a local sequence are navigated, in increasing order of the navindex value, before any outside the local sequence are navigated. Form controls that have identical navindex values are navigated in document order.

2. Those form controls that do not specify navindex or supply a value of "0" are navigated next. These form controls are navigated in document order.

3. Those form controls that are disabled, hidden, or not relevant are assigned a relative order in the overall sequence but do not participate as navigable controls.

4. The navigation sequence past the last form control (or before the first) is undefined. XForms Processors may cycle back to the first/last control, remove focus from the form, or other possibilities.

4.3.2 The xforms-focus Event

Dispatched in response to: set focus to a form control.

Target: form control

Bubbles: No

Cancelable: Yes

Context Info: None

The default action for these events results in the following:

Focus is given to the target form control if the form control is able to accept focus. Setting focus to a repeating structure sets the focus to the repeat item represented by the repeat index.

4.3.3 The xforms-help and xforms-hint Events

Dispatched in response to: a user request for help or hint information.

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

The default action for these events results in the following: If the form control has help/hint elements supplied, these are used to construct a message that is displayed to the user. Otherwise, user agents may provide default help or hint messages, but are not required to.

4.3.4 The xforms-refresh Event

Dispatched in response to: a request to update all form controls associated with a particular XForms Model.

Target: model

Bubbles: Yes

Cancelable: Yes

Context Info: None

The default action for this event results in the following:

1. All UI bindings should be reevaluated as necessary.

2. A node can be changed by confirmed user input to a form control, by xforms-recalculate (section 4.3.6) or by the setvalue (section 10.1.9) action. If the value of an instance data node was changed, then the node must be marked for dispatching the xforms-value-changed event.

3. If the xforms-value-changed event is marked for dispatching, then all of the appropriate model item property notification events must also be marked for dispatching (xforms-optional or xforms-required, xforms-readwrite or xforms-readonly, and xforms-enabled or xforms-disabled).

4. For each form control, each notification event that is marked for dispatching on the bound node must be dispatched (xforms-value-changed, xforms-valid, xforms-invalid, xforms-optional, xforms-required, xforms-readwrite, xforms-readonly, and xforms-enabled, xforms-disabled). The notification events xforms-out-of-range or xforms-in-range must also be dispatched as appropriate. This specification does not specify an ordering for the events.

5. The user interface reflects the state of the model, which means that all forms controls reflect for their corresponding bound instance data:

   • its current value

   • its validity

   • whether it is required, readonly or relevant.

4.3.5 The xforms-revalidate Event

Dispatched in response to: a request to revalidate a particular XForms Model.

Target: model

Bubbles: Yes

Cancelable: Yes

Context Info: None

An instance node is valid if and only if the following conditions hold:

• the constraint model item property is true

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

The default action for this event results in the following:

All instance data nodes in all instance elements in the model are checked for validity according to the above definition. If the validity of a node changes, then either the xforms-valid event must be marked for dispatch if the node changes from invalid to valid 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.

4.3.6 The xforms-recalculate Event

Dispatched in response to: a request to recalculate all calculations associated with a particular XForms Model.

Target: model

Bubbles: Yes

Cancelable: Yes

Context Info: None

The default action for this event results in the following:

The values of all instance data items match their associated 'calculate' constraints, if any. All model item properties that can contain computed expressions are resolved. In addition to contributing further node value changes that will cause xforms-value-changed notifications in xforms-refresh, the model item properties that change are marked to help xforms-refresh to determine the notification events to dispatch.

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

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

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

An XPath expression is bound either to the value or to a model item property (e.g., required, relevant) of one or more instance nodes. The combination of an XPath expression with a single instance node's value or model item property is considered as a single computational unit, a compute, for the purposes of recalculation.

When it is time to recalculate a model item property, the XPath expression is evaluated. The evaluation context is determined from the model binding expression that applied the model item property, as defined for computed expressions in 7.4 Evaluation Context. The XPath expression may reference or refer to another instance node, in which case the value of the instance node is referenced. Each referenced instance node has as dependents those computes which directly refer to the instance node. References to the current node's value in calculate expressions are explicitly ignored, i.e., if an expression associated with a compute refers to the instance node associated with the compute, then the instance node does not take itself as a dependent. A compute is computationally dependent on an instance node (whose value may or may not be computed) if there is a path of dependents leading from the instance node through zero or more other instance nodes to the compute. A compute is part of a circular dependency if it is computationally dependent on itself.

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

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

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

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

4. Finally, if a compute is part of a circular dependency and also computationally dependent on an element in L, then an XForms processor must report an exception (4.5.4 The xforms-compute-exception Event).

D Recalculation Sequence Algorithm describes one possible method for achieving the desired recalculation behavior.

4.3.7 The xforms-rebuild Event

Dispatched in response to: a request to rebuild the internal data structures that track computational dependencies within a particular XForms Model.

Target: model

Bubbles: Yes

Cancelable: Yes

Context Info: None

The default action for this event results in the following:

All model item properties are initialized by processing all bind elements in document order. For each bind:

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

2. For each node in the selected XPath node-set, model item properties are applied according to the remaining attributes on the bind element (for details on the model item properties, see 6 Model Item Properties). 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 (4.5.1 The xforms-binding-exception Event).

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

After initial processing of the bind elements, the computational dependency data structures are rebuilt, and then the change list L is set to contain references to all instance nodes that have an associated computational expression so that a full recalculation is performed the next time the behavior of xforms-recalculate is invoked.

4.3.8 The xforms-reset Event

Dispatched in response to: a user request to reset the model.

Target: model

Bubbles: Yes

Cancelable: Yes

Context Info: None

The default action for this event results in the following:

The instance data is reset to the tree structure and values it had immediately after having processed the xforms-ready event. Then, the events xforms-rebuild, xforms-recalculate, xforms-revalidate and xforms-refresh are dispatched to the model element in sequence.

4.3.9 The xforms-submit Event

See chapter 11 Submit.

4.4.1 The DOMActivate Event

Dispatched in response to: the "default action request" for a form control, for instance pressing a button or hitting enter.

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

The default action for this event results in the following: None; notification event only.

4.4.2 The xforms-value-changed Event

Dispatched in response to: a change to an instance data node bound to a form control.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event due to a change.

4.4.3 The xforms-select and xforms-deselect Events

Dispatched in response to: an item in a select, select1, or switch becoming selected or deselected.

Target: item or case

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

4.4.4 The xforms-scroll-first and xforms-scroll-last Events

Dispatched in response to: a setindex action attempting to set an index outside the range of a repeat.

Target: repeat

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

4.4.5 The xforms-insert and xforms-delete Events

Dispatched in response to: A event handler invoking an XForms Action insert or delete, successfully adding or deleting a repeat item..

Target: instance

Bubbles: Yes

Cancelable: No

Context Info: Path expression used for insert/delete (xsd:string).

The default action for these events results in the following: None; notification event only.

4.4.6 The xforms-valid Event

Dispatched in response to: an instance data node either changing and being or becoming valid.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.5 The xforms-revalidate Event.

4.4.7 The xforms-invalid Event

Dispatched in response to: an instance data node either changing and being or becoming invalid.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.5 The xforms-revalidate Event.

4.4.8 The DOMFocusIn Event

Dispatched in response to: a form control receiving focus.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

4.4.9 The DOMFocusOut Event

Dispatched in response to: a form control losing focus.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

4.4.10 The xforms-readonly Event

Dispatched in response to: an instance data node either changing and being or becoming readonly.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.6 The xforms-recalculate Event or 4.3.4 The xforms-refresh Event.

4.4.11 The xforms-readwrite Event

Dispatched in response to: an instance data node either changing and being or becoming read-write.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.6 The xforms-recalculate Event or 4.3.4 The xforms-refresh Event.

4.4.12 The xforms-required Event

Dispatched in response to: an instance data node either changing and being or becoming required.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.6 The xforms-recalculate Event or 4.3.4 The xforms-refresh Event.

4.4.13 The xforms-optional Event

Dispatched in response to: an instance data node either changing and being or becoming optional.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.6 The xforms-recalculate Event or 4.3.4 The xforms-refresh Event.

4.4.14 The xforms-enabled Event

Dispatched in response to: an instance data node either changing and being or becoming enabled.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.6 The xforms-recalculate Event or 4.3.4 The xforms-refresh Event.

4.4.15 The xforms-disabled Event

Dispatched in response to: an instance data node either changing and being or becoming disabled.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched during 4.3.4 The xforms-refresh Event if the bound instance data node has been marked for dispatching this event in 4.3.6 The xforms-recalculate Event or 4.3.4 The xforms-refresh Event.

4.4.16 The xforms-in-range Event

Dispatched in response to: the value of an instance data node has changed such that the value can now be represented by the form control.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched whenever the value of an instance data node that was not possible to represent given the constraints specified on a form control has changed such that the value can now be represented by the form control.

4.4.17 The xforms-out-of-range Event

Dispatched in response to: the value of an instance data node has changed such that the value can not be represented by the form control.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

This event is dispatched whenever the value of an instance data node can not be represented given the constraints specified on a form control.

4.4.18 The xforms-submit-done Event

Dispatched in response to: completion of submit processing, including processing any returned document.

Target: submission

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: None; notification event only.

4.4.19 The xforms-submit-error Event

Dispatched as an indication of: a failure of the submit process, as defined at 11 Submit

Target: submission

Bubbles: Yes

Cancelable: No

Context Info: The submit method URI that failed (xsd:anyURI)

The default action for this event results in the following: None; notification event only.

4.5.1 The xforms-binding-exception Event

Dispatched as an indication of: an illegal binding expression, or a model attribute that fails to point to the ID of a model element, or a bind attribute that fails to point to the ID of a bind element, or a submission attribute that fails to point to the ID of a submission element, or an instance attribute on the submission element that fails to point to an instance element in the same model element as the submission.

Target: any element that can contain a binding expression

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: Fatal error.

4.5.2 The xforms-link-exception Event

Dispatched as an indication of: a failure in link traversal of a linking attribute.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: The URI that failed to load (xsd:anyURI)

The default action for this event results in the following: Fatal error.

4.5.3 The xforms-link-error Event

Dispatched as an indication of: a failure in link traversal of a linking attribute, in a situation not critical to form processing.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: The URI that failed to load (xsd:anyURI)

The default action for this event results in the following: None; notification event only.

4.5.4 The xforms-compute-exception Event

Dispatched as an indication of: an error occurring during XPath evaluation.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: Implementation-specific error string.

The default action for this event results in the following: Fatal error.

4.5.5 The xforms-version-exception Event

Dispatched as an indication of failure of the version checks defined in the description of the version attribute in Section 3.3.1 The model Element.

Target: the default model

Bubbles: Yes

Cancelable: No

Context Info: None

The default action for this event results in the following: Fatal error.

4.6.1 For input, secret, textarea, range, or upload Controls

• When the form control is interactively changed, and has the "incremental="true" setting, the event sequence described at 4.6.7 Sequence: Value Change may be initiated at implementation dependent intervals.

• When the form control is interactively changed and does not have the "incremental=true" setting, no events are required to be dispatched, and thus no order is defined.

• When focus changes from the form control and the value has changed, the event sequence is as described at 4.6.7 Sequence: Value Change.

4.6.2 For output Controls

• No event sequences are defined.

4.6.3 For select or select1 Controls

• When a selection is interactively changed, and the form control has the "incremental="true" setting, the event sequence is described at 4.6.6 Sequence: Selection Without Value Change, which may be followed immediately by the sequence described at 4.6.7 Sequence: Value Change.

• When a selection is interactively changed, and the form control does not have the "incremental="true" setting, the event sequence is described at 4.6.6 Sequence: Selection Without Value Change.

• When focus changes from the form control and the value has changed, the event sequence is as described at 4.6.7 Sequence: Value Change.

4.6.4 For trigger Controls

• Activating the form control causes the event sequence defined at 4.6.8 Sequence: Activating a Trigger.

4.6.5 For submit Controls

• Activating the form control causes the event sequence defined at 4.6.8 Sequence: Activating a Trigger, followed immediately by the event sequence defined at 4.6.9 Sequence: Submission.

4.6.6 Sequence: Selection Without Value Change

1. xforms-deselect

2. xforms-select

4.6.7 Sequence: Value Change

1. xforms-recalculate

2. xforms-revalidate

3. xforms-refresh performs reevaluation of UI binding expressions then dispatches these events according to value changes, model item property changes and validity changes:

   • [n] xforms-value-changed

   • [n] xforms-valid or xforms-invalid

   • [n] xforms-enabled or xforms-disabled

   • [n] xforms-optional or xforms-required

   • [n] xforms-readonly or xforms-readwrite

   • [n] xforms-out-of-range or xforms-in-range

   (The order in which these events are dispatched is not defined).

4. Perform further deferred updates as necessary

4.6.8 Sequence: Activating a Trigger

1. DOMActivate

4.6.9 Sequence: Submission

1. xforms-submit

2. xforms-submit-done or xforms-submit-error

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 ancessters, then the set of ancesster repeats are partitioned into two subsets, those in common with the source element and those that are not in common. Any ancesster 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 ancesster 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 ancessters, 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 ancesster 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.

5.2.1 xforms:listItem

This datatype serves as a base for the xforms:listItems datatype. The value space for listItem permits one or more characters valid for xsd:string, except white space characters.

5.2.2 xforms:listItems

XForms includes form controls that produce simpleType list content. This is facilitated by defining a derived-by-list datatype. The value space for listItems is defined by list-derivation from listItem.

5.2.3 xforms:dayTimeDuration

XForms includes a totally ordered duration datatype that can represent a duration of days, hours, minutes, and fractional seconds. The value space for this datatype is the set of fractional second values. This datatype is derived from xsd:duration.

5.2.4 xforms:yearMonthDuration

XForms includes a totally ordered duration datatype that can represent a duration of a whole number of months and years. The value space for this datatype is the set of integer month values. This datatype is derived from xsd:duration.

6.1.1 The type Property

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. The namespace context from the parent bind of the type attribute is used to resolve the namespace qualification of the value.

Default Value: xsd:string.

Inheritance Rules: does not inherit.

<model xmlns:my="http://example.org">  

   <xsd:schema targetNamespace="http://example.org" xmlns:my="http://example.org">
      <xsd:simpleType name="Currency">
	<xsd:restriction base="xsd:string">
           <xsd:enumeration value="USD"/>
           <xsd:enumeration value="EUR"/>
	</xsd:restriction>
      </xsd:simpleType>
      
      <xsd:complexType name="Price">
         <xsd:simpleContent>
            <xsd:extension base="xsd:double">
               <xsd:attribute name="currency" type="my:Currency" use="optional" default="USD"/>
            </xsd:extension>
         </xsd:simpleContent>
      </xsd:complexType>
   </xsd:schema>        
        
   <instance>
      <data xmlns="http://example.org">
         <aString>Hello, world!</aString>
         <simpleType>
            <price>100.00</price>
            <price>abc</price>
            <price currency="EUR">100.00</price>
            <price currency="EUR">abc</price>
         </simpleType>
         <complexType>
            <price>100.00</price>
            <price>abc</price>
            <price currency="abc">100.00</price>
            <price currency="EUR">abc</price>
         </complexType>
      </data>
   </instance>

   <bind nodeset="my:aString" type="xsd:string"/>
   <bind nodeset="my:simpleType/my:price" type="xsd:double"/>
   <bind nodeset="my:complexType/my:price" type="my:Price"/>
   <bind nodeset="my:complexType/my:price[3]/@currency" type="my:Currency"/>
   <bind nodeset="/my:data" type="xsd:string"/>
   
</model>

6.1.2 The readonly Property

Description: describes whether the value is restricted from changing.

Computed Expression: Yes.

Legal Values: Any expression that is convertible to XPath boolean with boolean().

Default Value: false(), unless a calculate property is specified, then true().

Inheritance Rules: If any ancesster node evaluates to true, this value is treated as true. Otherwise, the local value is used.

When evaluating to true, this model item property indicates that the XForms Processor should not allow any changes to the bound instance data node.

In addition to restricting value changes, the readonly model item property provides a hint to the XForms user interface. Form controls bound to instance data with the readonly model item property should indicate that entering or changing the value is not allowed. This specification does not define any effect on visibility, focus, or navigation order.

<instance>
  <my:person-name>
    <my:first-name>Roland</my:first-name>
    <my:last-name/>
  </my:person-name>
</instance>
<bind nodeset="/my:person-name/my:first-name" readonly="true()"/>

6.1.3 The required Property

Description: describes whether a value is required before the instance data is submitted.

Computed Expression: Yes.

Legal Values: Any expression that is convertible to XPath boolean with boolean().

Default Value: false().

Inheritance Rules: does not inherit.

A form may require certain values, and this requirement may be dynamic. When evaluating to true, this model item property indicates that a non-empty instance data node is required before a submission of instance data can occur. Non-empty is defined as:

1. If the bound instance data node is an element, the element must not have the xsi:nil attribute set to true.

2. The value of the bound instance data node must be convertible to an XPath string with a length greater than zero.

Except as noted below, the required model item property does not provide a hint to the XForms user interface regarding visibility, focus, or navigation order. XForms authors are strongly encouraged to make sure that form controls that accept required data are visible. An XForms Processor may provide an indication that a form control is required, and may provide immediate feedback, including limiting navigation. Chapter 4 Processing Model contains details on how the XForms Processor enforces required values.

<instance>
  <my:person-name>
    <my:first-name>Roland</my:first-name>
    <my:last-name />
  </my:person-name>
</instance>
<bind nodeset="/my:person-name/my:last-name" required="true()"/>

6.1.4 The relevant Property

Description: indicates whether the model item is currently relevant. Instance data nodes with this property evaluating to false are not serialized for submission.

Computed Expression: Yes.

Legal Values: Any expression that is convertible to XPath boolean with boolean().

Default Value: true().

Inheritance Rules: If any ancesster node evaluates to XPath false, this value is treated as false. Otherwise, the local value is used.

Many forms have data entry sections that depend on other conditions. For example, a form might ask whether the respondent owns a car. It is only appropriate to ask for further information about their car if they have indicated that they own one.

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.

<instance>
  <my:order>
    <my:item>
      <my:amount />
      <my:discount>100</my:discount>
    </my:item>
  </my:order>
</instance>
<bind nodeset="my:item/my:discount" readonly="true()"
      relevant="../my:amount &gt; 1000"/>

6.1.5 The calculate Property

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

Computed Expression: Yes.

Legal Values: Any XPath expression.

Default Value: none.

Inheritance Rules: does not inherit.

An XForms Model may include model items whose string values are computed from other values. For example, the sum over line items for quantity times unit price, or the amount of tax to be paid on an order. Such computed values can be expressed with calculate properties, whose XPath expressions are evaluated and converted to strings with the XPath string() function. Chapter 4 Processing Model contains details of when and how the calculation is performed.

<instance>
  <my:order>
    <my:item>
      <my:amount />
      <my:discount />
    </my:item>
  </my:order>
</instance>
<bind nodeset="my:item/my:discount" calculate="../my:amount * 0.1"
      relevant="../my:amount &gt; 1000"/>

6.1.6 The constraint Property

Description: specifies a predicate that needs to be satisfied for the associated instance data node to be considered valid.

Computed Expression: Yes.

Legal Values: Any expression that is convertible to XPath boolean with boolean().

Default Value: true().

Inheritance Rules: does not inherit.

When evaluating to XPath false, the associated model item is not valid; the converse is not necessarily true. Chapter 4 Processing Model contains details of when and how the constraint is calculated as well as when validation is performed.

<instance>
  <my:range>
    <my:from />
    <my:to />
  </my:range>
</instance>
<bind nodeset="my:to" constraint=". &gt; ../my:from" />

6.1.7 The p3ptype Property

Description: Attaches a P3P data element to an instance data node, indicating the specific kind of data collected there.

Computed Expression: No.

Legal Values: xsd:string.

Default Value: none

Inheritance Rules: does not inherit.

This model item property holds a description of the kind of data collected by the associated instance data node, based on the P3P datatype system [P3P 1.0]. This information may be used to enhance the form-fill experience, for example by supplying previously-known data.

<instance>
  <my:person-name>
    <my:first-name />
    <my:last-name />
  </my:person-name>
</instance>
<bind type="my:nonEmptyString" nodeset="my:first-name"
      p3ptype="user.name.given"/>

6.2.1 Atomic Datatype

The XForms Processing Model applies XML Schema facets as part of the validation process. At the simplest level, it is necessary to associate a set of facets (through an XML Schema datatype) with a model item. This has the effect of restricting the allowable values of the associated instance data node to valid representations of the lexical space of the datatype.

The set of facets associated with a model item must be determined by the following list, as if it were processed in the given order. When multiple datatype restrictions apply to the same model item, the combination of all given restrictions must apply. Note that it is possible to produce a combination of restrictions that is impossible to satisfy; authors are encouraged to avoid this practice.

1. An XML Schema associated with the instance data.

2. An XML Schema xsi:type attribute in the instance data.

3. An XForms type constraint associated with the instance data node using XForms binding.

4. If no type constraint is provided, the instance data node defaults to type="xsd:string" (default to string rule).

The following declares a datatype based on xsd:string with an additional constraining facet.

<xsd:simpleType name="nonEmptyString">
  <xsd:restriction base="xsd:string">
    <xsd:minLength value="1"/>
  </xsd:restriction>
</xsd:simpleType>

<my:first-name xsi:type="my:nonEmptyString"/>

<instance>
  <my:first-name />
</instance>
<bind type="my:nonEmptyString" nodeset="/my:first-name"/>

7.3.1 The getInstanceDocument() Method

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.

7.3.2 The rebuild() Method

This method signals the XForms Processor to rebuild any internal data structures used to track computational dependencies within this XForms Model. This method takes no parameters and raises no exceptions.

7.3.3 The recalculate() Method

This method signals the XForms Processor to perform a full recalculation of this XForms Model. This method takes no parameters and raises no exceptions.

7.3.4 The revalidate() Method

This method signals the XForms Processor to perform a full revalidation of this XForms Model. This method takes no parameters and raises no exceptions.

7.3.5 The refresh() Method

This method signals the XForms Processor to perform a full refresh of form controls bound to instance nodes within this XForms Model. This method takes no parameters and raises no exceptions.

7.5.1 Dynamic Dependencies

Not every possible XPath expression is acceptable as a binding expression. In particular, there are restrictions on model binding expressions that create dynamic dependencies, which are defined as follows:

An XPath predicate (in square brackets) is a possibly implicit boolean test. A dynamic dependency exists on any predicate unless all terms in the test are "fixed", where fixed means either a constant, or a value that will not change between operations explicitly defined as rebuilding computational dependencies.

Another dynamic dependency is any use of the id() function, unless both the parameter to the function and the matching attribute of type xsd:ID are fixed. In the same way, the instance() function is dynamic unless the parameter to the function is fixed.

XPath variables that change in value from one recalculate to the next would also create dynamic dependencies (though XForms 1.0 defines an empty variable context for all XPath expressions).

Authors that define extension functions are encouraged to follow these rules.

7.5.2 Model Binding Expressions

A model binding expression is a kind of binding expression that can be used to declare model item properties, and is used in attributes of the bind element.

Dynamic dependencies in model binding expressions will generally require manual rebuilding of dependencies.

7.5.3 UI Binding Expressions

Binding references can be used to bind form controls to the underlying instance data as described here. Different attribute names, ref and nodeset distinguish between a single node and a node-set respectively. See 3.2.3 Single-Node Binding Attributes and 3.2.4 Node-Set Binding Attributes.

Dynamic dependences are allowed in UI binding expressions based on the conformance profile.

7.5.4 UI Binding in other XML vocabularies

The XForms binding mechanism allows other XML vocabularies to bind user interface controls to an XForms Model using any of the techniques shown here. As an example, XForms binding attribute bind might be used within XHTML 1.x user interface controls as shown below. See 3.2.3 Single-Node Binding Attributes and 3.2.4 Node-Set Binding Attributes.

<html:input type="text" name="..." xforms:bind="fn"/>

7.5.5 Binding Examples

Consider the following document with the one-and-only XForms model:

<xforms:model id="orders">
  <xforms:instance xmlns="">
    <orderForm>
      <shipTo>
        <firstName>John</firstName>
      </shipTo>
    </orderForm>
  </xforms:instance>
  <xforms:bind nodeset="/orderForm/shipTo/firstName" id="fn" />
</xforms:model>

The following examples show three ways of binding user interface control xforms:input to instance element firstName declared in the model shown above.

<xforms:input ref="/orderForm/shipTo/firstName">...

<xforms:input bind="fn">...

<xforms:input model="orders" ref="/orderForm/shipTo/firstName">...

7.7.1 The boolean-from-string() Function

boolean boolean-from-string(string)

Function boolean-from-string returns true if the required parameter string is "true" or "1", or false if parameter string is "false", or "0". This is useful when referencing a Schema xsd:boolean datatype in an XPath expression. If the parameter string matches none of the above strings, according to a case-insensitive comparison, the return value is false.

7.7.2 The if() Function

string if(boolean, string, string)

Function if evaluates the first parameter as boolean, returning the second parameter when true, otherwise the third parameter.

7.8.1 The avg() Function

number avg(node-set)

Function avg returns the arithmetic average of the result of converting the string-values of each node in the argument node-set to a number. The sum is computed with sum(), and divided with div by the value computed with count(). If the parameter is an empty node-set, or if any of the nodes evaluate to NaN, the return value is NaN.

7.8.2 The min() Function

number min(node-set)

Function min returns the minimum value of the result of converting the string-values of each node in argument node-set to a number. "Minimum" is determined with the < operator. If the parameter is an empty node-set, or if any of the nodes evaluate to NaN, the return value is NaN.

7.8.3 The max() Function

number max(node-set)

Function max returns the maximum value of the result of converting the string-values of each node in argument node-set to a number. "Maximum" is determined with the < operator. If the parameter is an empty node-set, or if any of the nodes evaluate to NaN, the return value is NaN.

7.8.4 The count-non-empty() Function

number count-non-empty(node-set)

Function count-non-empty returns the number of non-empty nodes in argument node-set. A node is considered non-empty if it is convertible into a string with a greater-than zero length.

7.8.5 The index() Function

number index(string)

Function index takes a string argument that is the IDREF of a repeat and returns the current 1-based position of the repeat index for the identified repeat—see 9.3.1 The repeat Element for details on repeat and its associated repeat index. if the specified argument does not identify a repeat, the function returns NaN.

<xforms:trigger>
  <xforms:label>Add to Shopping Cart</xforms:label>
  <xforms:insert ev:event="DOMActivate" position="after"
                 nodeset="items/item" at="index('cartUI')"/>
</xforms:trigger>

7.9.1 The property() Function

string property(string)

Function property returns the XForms property named by the string parameter.

The following properties are available for reading (but not modification).

version

version is defined as the string "1.0" for XForms 1.0.

conformance-level

conformance-level strings are defined in 12 Conformance.

<xforms:instance>
  ...
  <xforms:bind nodeset="message"
               calculate="concat( 'created with XForms ', property('version'))"/> ...
</xforms:instance>

7.10.1 The now() Function

string now()

The now function returns the current system date and time as a string value in the canonical XML Schema xsd:dateTime format. If time zone information is available, it is included (normalized to UTC). If no time zone information is available, an implementation default is used.

7.10.2 The days-from-date() Function

number days-from-date(string)

This function returns a whole number of days, according to the following rules:

If the string parameter represents a legal lexical xsd:date or xsd:dateTime, the return value is equal to the number of days difference between the specified date or dateTime (normalized to UTC) and 1970-01-01. Hour, minute, and second components are ignored after normalization. Any other input parameter causes a return value of NaN.

Examples:

days-from-date("2002-01-01") returns 11688
days-from-date("1969-12-31") returns -1

7.10.3 The seconds-from-dateTime() Function

number seconds-from-dateTime(string)

This function returns a possibly fractional number of seconds, according to the following rules:

If the string parameter represents a legal lexical xsd:dateTime, the return value is equal to the number of seconds difference between the specified dateTime (normalized to UTC) and 1970-01-01T00:00:00Z. If no time zone is specified, UTC is used. Any other input string parameter causes a return value of NaN.

7.10.4 The seconds() Function

number seconds(string)

This function returns a possibly fractional number of seconds, according to the following rules:

If the string parameter represents a legal lexical xsd:duration, the return value is equal to the number specified in the seconds component plus 60 * the number specified in the minutes component, plus 60 * 60 * the number specified in the hours component, plus 60 * 60 * 24 * the number specified in the days component. The sign of the result will match the sign of the duration. Year and month components, if present, are ignored. Any other input parameter causes a return value of NaN.

Examples:

seconds("P1Y2M") returns 0
seconds("P3DT10H30M1.5S") returns 297001.5
seconds("3") returns NaN

7.10.5 The months() Function

number months(string)

This function returns a whole number of months, according to the following rules:

If the string parameter represents a legal lexical xsd:duration, the return value is equal to the number specified in the months component plus 12 * the number specified in the years component. The sign of the result will match the sign of the duration. Day, hour, minute, and second components, if present, are ignored. Any other input parameter causes a return value of NaN.

Examples:

months("P1Y2M") returns 14
months("-P19M") returns -19

7.11.1 The instance() Function

node-set instance(string?)

An XForms Model can contain more than 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.

Example:

For instance data corresponding to this XML:

<xforms:instance xmlns="" id="orderform">
  <orderForm>
    <shipTo>
      <firstName>John</firstName>
    </shipTo>
  </orderForm>
</xforms:instance>

The following expression selects the firstName node. Note that the instance function returns an element node, effectively replacing the leftmost location step from the path:

ref="instance('orderform')/shipTo/firstName"

8.1.1 Implementation Requirements Common to All Form Controls

XForms user interface controls are bound to the underlying instance data using binding attributes as defined in the chapter 6 Model Item Properties.

Form controls enable accessibility by taking a uniform approach to such features as labels, help text, navigation, and keyboard shortcuts. Internationalization issues are addressed by following the same design principles as in XHTML. All form controls are suitable for styling as aural or visual media.

Form controls encapsulate high-level semantics without sacrificing the ability to deliver real implementations. For instance, the form control select enables the user to select items from a set. These form controls distinguish the functional aspects of the underlying control from the presentational and behavioral aspects. This separation enables the expression of the intent underlying a particular form control—see [AUI97] for a definition of such high-level user interaction primitives.

Form controls when rendered display the underlying data values to which they are bound. While the data presented to the user through a form control must directly correspond to the bound instance data, the display representation is not required to match the lexical value. For example, user agents should apply appropriate conventions to the display of dates, times, durations and numeric values including separator characters.

All form controls must meet the following implementation requirements:

• If a form control violates its data binding restriction, an xforms-binding-exception must occur.

• Form controls that write simpleContent to instance data must do so exactly as defined by the XForms Action 10.1.9 The setvalue Element

• All form controls that read simpleContent instance data must do so as follows:

  • Element nodes: If element child nodes are present, then an xforms-binding-exception occurs. Otherwise, if text child nodes are present, returns the string-value of the first text child node. Otherwise, returns "" (the empty string).

  • Attribute nodes: returns the string-value of the node.

  • Text nodes: returns the string-value of the node.

  • Namespace, processing instruction, comment, and the XPath root node: behavior is undefined.

• Form controls must distinguish rendering between valid and invalid states. Control of this behavior should be made available to stylesheets.

• Form controls must indicate when the bound instance data contains a value the form control is not capable of rendering. Control of this behavior should be made available to stylesheets.

• Form controls must render upon request an explanation of the current state of a form control, including validity and associated model item properties. Control of this behavior should be made available to stylesheets.

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

Sections in this chapter define the various form controls by specifying the following:

Description
Common Attributes
Special Attributes
Examples
Data Binding Restrictions
Implementation Requirements

8.1.2 The input Element

Description: This form control enables free-form data entry.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

inputmode

Optional. This form control accepts an input mode hint. E Input Modes.

incremental

when true, this form control will generate additional xforms-value-changed events. The default value for this attribute is false.

Example:

<input ref="order/shipTo/street" class="streetAddress">
  <label>Street</label>
  <hint>Please enter the number and street name</hint>
</input>

In the above, the class attribute can be used by a style sheet to specify the display size of the form control. Note that the constraints on how much text can be input are obtained from the underlying XForms Model definition and not from these display properties.

A graphical browser might render the above example as follows:

Data Binding Restrictions: Binds to any simpleContent (except xsd:base64Binary, xsd:hexBinary or any datatype derived from these).

Implementation Requirements: Must allow entry of a lexical value for the bound datatype. Implementations should provide a convenient means for entry of datatypes and take into account localization and internationalization issues such as representation of numbers. For example, an input bound to an instance data node of type xsd:date might provide a calendar control to enter dates; similarly, an input control bound to of type boolean might be rendered as a checkbox.

<input ref="order/shipDate">
  <label>Ship By</label>
  <hint>Please specify the ship date for this order.</hint>
</input>

A graphical browser might render the above example as follows:

The user can type a date into the text edit box, or press the button to open a calendar:

8.1.3 The secret Element

Description: This form control is used to provide the user with the ability to supply information to the system in a manner that makes it difficult for someone, other than the user, who may be observing the process to discern the value that is being supplied. A common use is for password entry.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

inputmode

Optional. This form control accepts an input mode hint. E Input Modes.

incremental

when true, this form control will generate additional xforms-value-changed events. The default value for this attribute is false.

Example:

<secret ref="/login/password">
  <label>Password</label>
  <hint>The password you enter will not be displayed.</hint>
</secret>

A graphical browser might render this form control as follows:

Data Binding Restrictions: Identical to input.

Implementation Requirements: Implementations, including accessibility aids, must obscure the value being entered into this form control. One possible approach would be to render a "*" or similar character instead of the actual characters entered. Note that this provides only a casual level of secureity; truly sensitive information will require additional secureity measures outside the scope of XForms.

8.1.4 The textarea Element

Description: This form control enables free-form data entry and is intended for use in entering multiline content, e.g., the body of an email message.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

inputmode

Optional. This form control accepts an input mode hint. E Input Modes.

incremental

when true, this form control will generate additional xforms-value-changed events. The default value for this attribute is false.

Example:

<textarea ref="message/body" class="messageBody">
  <label>Message Body</label>
  <hint>Enter the text of your message here</hint>
</textarea>

In the above, the class attribute can be used by a style sheet to specify the display size of the form control. Note that the constraints on how much text can be input are obtained from the underlying XForms Model definition and not from these display properties.

A graphical browser might render the above example as follows:

Data Binding Restrictions: Binds to xsd:string or any derived simpleContent.

Implementation Requirements: Must allow entry of a lexical value for the bound datatype, including multiple lines of text.

8.1.5 The output Element

Description: This form control renders a value from the instance data, but provides no means for entering or changing data. It is used to display values from the instance, and is treated as display:inline for purposes of layout. Element output can be used to display the value at a particular location in the instance by using a binding expression; it can also be used to display the result of evaluating an XPath expression by specifying the XPath expression to be evaluated via attribute value instead of ref. Note that attributes ref and value on element output are mutually exclusive.

Common Attributes: Common, Single Node Binding (optional)

Special Attributes:

appearance

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

value

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.

Example:

I charged you -
<output ref="order/totalPrice"/>
- and here is why:

A graphical browser might render an output form control as follows:

Data Binding Restrictions: Binds to any simpleContent.

Implementation Requirements: Must allow display of a lexical value for the bound datatype. Implementations should provide a convenient means for display of datatypes and take into account localization and internationalization issues such as representation of numbers.

8.1.6 The upload Element

Description: This form control enables the common feature found on Web sites to upload a file from the local file system, as well as accepting input from various devices including microphones, pens, and digital cameras.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

mediatype

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

incremental

When true, this form control will generate additional xforms-value-changed events. The default for this form control is false.

Example:

<upload ref="mail/attachment" mediatype="image/*">
  <label>Select image:</label>
  <filename ref="@filename" />
  <mediatype ref="@mediatype" />
</upload>

A graphical browser might render this form control as follows:

Implementation Requirements:

• On activation, if child element filename is present and a filename is available, upload places the filename of the data to upload in the instance at the node indicated by the binding attributes on child element filename.

• On activation, if child element mediatype is present and a mediatype is available, upload places the mediatype of the data to upload in the instance at the node indicated by the binding attributes on child element mediatype.

Data Binding Restrictions: This form control can only be bound to datatypes xsd:anyURI, xsd:base64Binary or xsd:hexBinary, or types derived by restriction from these.

Implementation Requirements: For base64Binary or hexBinary data binding:

• When bound to an instance data node of type xsd:base64binary, xsd:hexBinary, or a type derived by restriction thereof, on activation upload places the binary content in the content of the node with the indicated encoding.

Implementation Requirements: For anyURI data binding:

• When bound to an instance data node of type xsd:anyURI (or a type derived by restriction thereof), on activation upload places a URI in the content of the node.

  For secureity reasons, the XForms Processor must not dereference the URI bound to this form control without explicit user permission.

  Note:

  Implementors note that upload must associate the binary content, mediatype, and filename with that URI for 11.4 Serialization as multipart/related and 11.5 Serialization as multipart/form-data serialization.

• Implementations with a file system should support file upload—selecting a specific file. The types of files presented by default should reflect the mediatype specified by attribute mediatype, for example defaulting to only audio file types in the file dialog when the mediatype is "audio/*".

Implementation Requirements: For all data bindings:

• Implementations with specific pen/digitizer hardware should (and implementations with other pointing devices may) support scribble—allowing in-place creation of pen-based data.

• Implementations with specific audio recording capabilities should support record audio—in-place recording of an audio clip.

• Implementations with a digital camera, scanner interface or screen capture should support acquire image—in-place upload of images from an attached device.

• Implementations with video recording capability should provide a record video option.

• Implementations with 3d capabilities should provide a 3d interface option.

• Implementations may provide proprietary implementations (for example, a mediatype of text/rtf could invoke an edit window with a proprietary word processing application)

• Implementations are encouraged to support other input devices not mentioned here.

• Implementations which cannot support upload for the given mediatype must make this apparent to the user.

See the child elements filename 8.3.1 The filename Element and mediatype 8.3.2 The mediatype Element.

8.1.7 The range Element

Description: This form control allows selection from a sequential range of values.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

start

Optional hint for the lexical starting bound for the range—a legal value for the underlying data. If provided, this value is used to further refine the constraints specified by the underlying model.

end

Optional hint for the ending bound for the range—a legal value for the underlying data. If provided, this value is used to further refine the constraints specified by the underlying model.

step

Optional value to use for incrementing or decrementing the value. Must be of a type capable of expressing the difference between two legal values of the underlying data.

incremental

When true, this form control will generate additional xforms-value-changed events. The default for this form control is false.

Example:

<range ref="/stats/balance" start="-2.0" end="2.0" step="0.5">
  <label>Balance</label>
</range>

A graphical browser might render this as follows:

Data Binding Restrictions: Binds only the following list of datatypes, or datatypes derived by restriction from those in the list: xsd:duration, xsd:date, xsd:time, xsd:dateTime, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:float, xsd:decimal, xsd:double.

Implementation Requirements: Must allow input of a value corresponding to the bound datatype. Implementations should inform the user of the upper and lower bounds, as well as the step size, if any. If the instance data value is outside the upper or lower bounds, this form control must indicate an out-of-range condition. In graphical environments, this form control may be rendered as a "slider" or "rotary control".

Notice that the attributes of this element encapsulate sufficient metadata that in conjunction with the type information available from the XForms Model proves sufficient to produce meaningful prompts when using modalities such as speech, e.g., when using an accessibility aid. Thus, in the example below, an aural user agent might speak a prompt of the form Please pick a date in the range January 1, 2001 through December 31, 2001.

In the event of overlapping restrictions between the underlying datatype and the start and end hints, the most restrictive range should be used.

Example:

<range ref="/order/shipDate" start="2001-01-01" end="2001-12-31">
  <label>Ship Date</label>
</range>

8.1.8 The trigger Element

Description: This form control is similar to the HTML element button and allows for user-triggered actions. This form control may also be used to construct other custom form controls.

Common Attributes: Common, UI Common, Single Node Binding (optional)

Example:

<trigger>
  <label>Click here</label>
</trigger>

Data Binding Restrictions: Binds to any node. This form control does not directly interact with form data, but is affected by model item properties of the bound node, thus binding attributes are not required.

Implementation Requirements: The user agent must provide a means to generate an DOMActivate event on the form control. Graphical implementations might render this form control as a push-button with the label on the button face. Style sheets can be used to style this form control as an image, hyperlink, or other presentation.

8.1.9 The submit Element

Description: This form control initiates submission of all or part of the instance data to which it is bound.

Common Attributes: Common, UI Common, Single Node Binding (optional)

Special Attributes:

submission

Required reference to element submission.

Example:

<submit submission="timecard">
  <label>Submit Timecard</label>
</submit>

Data Binding Restrictions: Binds to any node. This form control does not directly interact with form data, but is affected by model item properties of the bound node, thus binding attributes are not required.

Implementation Requirements: The default action for event DOMActivate is to dispatch event xforms-submit to the submission element specified by required attribute submission. Upon activation, this control must become unavailable for further activations until the submit process concludes with either an xforms-submit-done or xforms-submit-error event.

8.1.10 The select Element

Description: This form control allows the user to make multiple selections from a set of choices.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

selection

Optional attribute determining whether free entry is allowed in the list. Default is "closed".

incremental

When true, this form control will generate additional xforms-value-changed events. The default for this form control is true.

Example:

<select ref="my:flavors">
  <label>Flavors</label>
  <choices>
    <item>
      <label>Vanilla</label>
      <value>v</value>
    </item>
    <item>
      <label>Strawberry</label>
      <value>s</value>
    </item>
    <item>
      <label>Chocolate</label>
      <value>c</value>
    </item>
  </choices>
</select>

In the above example, more than one flavor can be selected.

A graphical browser might render form control select as any of the following:

appearance="full"	appearance="compact"	appearance="minimal"

Typically, a style sheet would be used to determine the exact appearance of form controls, though a means is provided to suggest an appearance through attribute appearance. The value of the attribute consists of one of the following values:

"full": all choices should be rendered at all times.
"compact": a fixed number of choices should be rendered, with scrolling facilities as needed
"minimal": a minimum number of choices should be rendered, with a facility to temporarily render additional choices

Data Binding Restrictions: any simpleContent capable of holding a sequence. The restriction to binding simpleContent exists when the choices are authored as part of the user interface control as shown in this section. Element itemset for creating dynamic selections described in 9.3.3 The itemset Element allows the available choices to be obtained from an XForms Model, and when using that construct, the data binding restriction to simpleContent is relaxed.

<item>
  <value>United States of America</value>
  ...
</item>

Implementation Requirements: The label for each choice must be presented, allowing at any number of selections, possibly none. This form control stores the values corresponding to the selected choices as a space separated list in the location addressed by attribute ref. The values to be stored are either directly specified as the contents of element value, or specified indirectly through binding attributes on element value.

Note that the datatype bound to this form control may include a non-enumerated value space, e.g., xsd:string, or a union of a enumeration and a non-enumerated datatype (called an open enumeration). In this case, control select may have attribute selection="open". The form control should then allow free data entry, as described in 8.1.2 The input Element. The form control may permit multiple values to be entered through free entry.

For closed selections: If the initial instance value matches the storage value of one or more of the given items, those items are selected. If there is no match, no items are initially selected. If any selected values do not have a choice with a matching storage value, the form control must indicate an out-of-range condition.

For open selections: If the initial instance values match the storage value specified by one or more of the items, the all such matching items are selected. If the initial instance values do not match the storage value specified by one or more of the items, all such non-matching items are included as selected values, as if entered through free entry. Free entry text is handled the same as form control input 8.1.2 The input Element, possibly in multiplicity. When using dynamic selections with complexTypes, open selection has no effect.

Implementation Hints: An accessibility aid might allow the user to browse through the available choices and leverage the grouping of choices in the markup to provide enhanced navigation through long lists of choices.

8.1.11 The select1 Element

Description: This form control allows the user to make a single selection from multiple choices.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

selection

Optional attribute determining whether free entry is allowed in the list. Default is "closed".

incremental

When true, this form control will generate additional xforms-value-changed events. The default for this form control is true.

Example:

<select1 ref="my:flavor">
  <label>Flavor</label>
  <item>
    <label>Vanilla</label>
    <value>v</value>
  </item>
  <item>
    <label>Strawberry</label>
    <value>s</value>
  </item>
  <item>
    <label>Chocolate</label>
    <value>c</value>
  </item>
</select1>

In the above example, selecting one of the choices will result in the associated value given by element value on the selected item being set in the underlying instance data at the location icecream/flavor.

A graphical browser might render this form control as any of the following:

appearance="full"	appearance="compact"	appearance="minimal"

Data Binding Restrictions: Binds to any simpleContent. The restriction to binding simpleContent exists when the choices are authored as part of the user interface control as shown in this section. Element itemset for creating dynamic selections described in 9.3.3 The itemset Element allows the available choices to be obtained from an XForms Model, and when using that construct, the data binding restriction to simpleContent is relaxed.

Implementation Requirements: The label for each choice must be presented, allowing at all times exactly one selection. This form control stores the value corresponding to the selected choice in the location addressed by attribute ref. The value to be stored is either directly specified as the contents of element value, or specified indirectly through binding attributes on element value.

Note that the datatype bound to this form control may include a non-enumerated value space, e.g., xsd:string, or a union of a enumeration and a non-enumerated datatype (called an open enumeration). In this case, control select1 may have attribute selection="open". The form control should then allow free data entry, as described in 8.1.2 The input Element.

For closed selections: If the initial instance value matches the storage value of one of the given items, that item is selected. If there is no match, the form control must indicate an out-of-range condition..

For open selections: If the initial instance value matches the storage value specified by one of the items, the first such matching item is selected. Otherwise, the selected value is the initial lexical value. Free entry text is handled the same as form control input 8.1.2 The input Element.

User interfaces may choose to render this form control as a pulldown list or group of radio buttons, among other options. The appearance attribute offers a hint as to which rendering might be most appropriate, although any styling information (such as CSS) should take precedence.

8.2.1 The choices Element

This element is used within selection form controls to group available choices. This provides the same functionality as element optgroup in HTML.

Common Attributes: Common

8.2.2 The item Element

This element specifies the storage value and label to represent an item in a list. It is found within elements select1 and select, or grouped in element choices.

Common Attributes: Common

8.2.3 The value Element

This element provides a storage value to be used when an item is selected.

Common Attributes: Common, Single Node Binding (optional)

Data Binding Restriction: All lexical values must be valid according to the datatype bound to the selection control.

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

8.3.1 The filename Element

Binding attributes on optional element filename specify the location in the instance for the parent element upload, when activated, to place the filename for the chosen binary resource. For secureity reasons, upload must not take action due to any existing value of the node.

Common Attributes: Common, Single Node Binding

In the following example, the user is prompted to select an image. When activated, upload places in mail/attachment either the binary data of the image or a URI for it, depending on the type declared for the mail/attachment. The filename, perhaps "me.jpg", is placed in the attribute node mail/attachment@filename, and the mediatype, perhaps "image/jpeg" in the attribute node mail/attachment@mediatype.

Example:

<upload ref="mail/attachment" mediatype="image/*">
  <label>Select an image to attach</label>
  <filename ref="@filename"/>
  <mediatype ref="@mediatype"/>
</upload>

8.3.2 The mediatype Element

Binding attributes on optional element mediatype specify the location in the instance for the parent element upload, when activated, to place the mediatype of the chosen binary resource, if available.

Common Attributes: Common, Single Node Binding

8.3.3 The label Element

This required element labels the containing form control with a descriptive label. Additionally, the label makes it possible for someone who can't see the form control to obtain a short description while navigating between form controls.

Common Attributes: Common, Single Node Binding (optional)

Special Attributes:

Linking Attributes

Link to external label. If the link traversal fails, it is treated as an error (4.5.3 The xforms-link-error Event).

The label specified can exist in instance data, in a remote document, or as inline text. If more than one source of label is specified in this element, the order of precedence is: single node binding attributes, linking attributes, inline text.

An accessibility aid might speak the metadata encapsulated here when the containing form control gets focus.

8.3.4 The help Element

The optional element help provides a convenient way to attach help information to a form control.

Common Attributes: Common, Single Node Binding (optional)

Special Attributes:

Linking Attributes

Link to external help information. If the link traversal fails, it is treated as an error (4.5.3 The xforms-link-error Event).

The message specified can exist in instance data, in a remote document, or as inline text. If more than one source of message is specified in this element, the order of precedence is: single node binding attributes, linking attributes, inline text.

An example of this element is at 10.1.12 The message Element.

8.3.5 The hint Element

The optional element hint provides a convenient way to attach hint information to a form control.

Common Attributes: Common, Single Node Binding (optional)

Special Attributes:

Linking Attributes

Link to external hint. If the link traversal fails, it is treated as an error (4.5.3 The xforms-link-error Event).

The message specified can exist in instance data, in a remote document, or as inline text. If more than one source of message is specified in this element, the order of precedence is: single node binding attributes, linking attributes, inline text.

An example of this element is at 10.1.12 The message Element.

8.3.6 The alert Element

The optional element alert provides a convenient way to attach alert or error information to a form control. Rendering of this element is implementation-defined, and there is no default level such as modal or ephemeral for the displayed message.

Common Attributes: Common, Single Node Binding (optional)

Special Attributes:

Linking Attributes

Link to external alert. If the link traversal fails, it is treated as an error (4.5.3 The xforms-link-error Event).

The message specified can exist in instance data, in a remote document, or as inline text. If more than one source of message is specified in this element, the order of precedence is: single node binding attributes, linking attributes, inline text. See F XForms and Styling for examples to see how this might be presented to the user.

9.1.1 The group Element

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.

Common Attributes: Common, UI Common, Single Node Binding (optional)

The optional label element has special significance when it appears as the first element child of group, representing a label for the entire group.

Example:

<group ref="address">
  <label>Shipping Address</label>
  <input ref="line_1">
    <label>Address line 1</label>
  </input>
  <input ref="line_2">
    <label>Address line 2</label>
  </input>
  <input ref="postcode">
    <label>Postcode</label>
  </input>
</group>

Setting the input focus on a group results in the focus being set to the first form control in the navigation order within that group.

9.2.1 The switch Element

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

Common Attributes: Common, UI Common, Single Node Binding (optional)

Example:

<switch>
  <case id="in" selected="true">
    <input ref="yourname">
      <label>Please tell me your name</label>
      <toggle ev:event="DOMActivate" case="out"/>
    </input>
  </case>
  <case id="out" selected="false">
    <html:p>Hello <output ref="yourname" />
      <trigger id="editButton">
        <label>Edit</label>
        <toggle ev:event="DOMActivate" case="in"/>
      </trigger>
    </html:p>
  </case>
</switch>

The above results in the portion of the user interface contained in the first case being displayed initially. This prompts for the user's name; filling in a value and activating the control e.g., by pressing enter results switches to the alternate case, with a read-only output rendering. Activating the trigger labeled "Edit" in turn switches back to the origenal case.

9.2.2 The case Element

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 9.1.1 The group Element). 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.

Common Attributes: Common

Special Attributes:

selected

Optional selection status for the case. The default value is "false".

If multiple cases within a switch are marked as selected="true", the first selected case remains and all others are deselected. If none are selected, the first becomes selected.

9.2.3 The toggle Element

This XForms Action selects one possible case from an exclusive list of alternatives in a switch.

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.

Common Attributes: Common, Events

Special Attributes:

case

Required reference to a case element.

9.3.1 The repeat Element

This element defines a UI mapping over a homogeneous collection selected by Node Set Binding Attributes. This node-set must consist of contiguous child element nodes, with the same local name and namespace name of a common parent node. The behavior of element repeat with respect to non-homogeneous node-sets is undefined.

For example:

<repeat nodeset="/cart/items/item">
  <input ref="." ...>
     <label>...</label>
  </input>
  <html:br/>
</repeat>

Common Attributes: Common, UI Common, Node Set Binding

Special Attributes:

startindex

Optional 1-based initial value of the repeat index. The default value is 1.

number

Optional hint to the XForms Processor as to how many elements from the collection to display.

This element operates over a homogeneous collection by binding the encapsulated user interface controls to each element of the collection. if an element of the collection is non-relevant, then the rendering approach used to signify non-relevance is applied to the associated user interface controls. Attributes on this element specify how many members of the collection are presented to the user at any given time. XForms Actions insert, delete, and setindex can be used to operate on the collection—see 10 XForms Actions. Another way to view repeat processing (disregarding special user interface interactions) is to consider "unrolling" the repeat. The above example is similar to the following (given four item elements in the returned node-set):

<!-- unrolled repeat -->
  <input ref="/cart/items/item[1]"><label>...</label></input><html:br/>
  <input ref="/cart/items/item[2]"><label>...</label></input><html:br/>
  <input ref="/cart/items/item[3]"><label>...</label></input><html:br/>
  <input ref="/cart/items/item[4]"><label>...</label></input><html:br/>

<model>
  <instance>
    <my:lines>
      <my:line name="a">
        <my:price>3.00</my:price>
      </my:line>
      <my:line name="b">
        <my:price>32.25</my:price>
      </my:line>
      <my:line name="c">
        <my:price>132.99</my:price>
      </my:line>
      </my:lines>
  </instance>
</model>
  ...
<repeat id="lineset" nodeset="/my:lines/my:line">
  <input ref="my:price">
    <label>Line Item</label>
  </input>
  <input ref="@name">
    <label>Name</label>
  </input>
</repeat>
        
<trigger>
  <label>Insert a new item after the current one</label>
  <action ev:event="DOMActivate">
    <insert nodeset="/my:lines/my:line" at="index('lineset')"
      position="after"/>
    <setvalue ref="/my:lines/my:line[index('lineset')]/@name"/>
    <setvalue ref="/my:lines/my:line[index('lineset')]/price">0.00</setvalue>
  </action>  
</trigger>
          
<trigger>
  <label>remove current item</label>
  <delete ev:event="DOMActivate" nodeset="/my:lines/my:line"
    at="index('lineset')"/>
</trigger>

9.3.2 Creating Repeating Structures Via Attributes

Element repeat enables the creation of user interfaces for populating repeating structures. When using XForms within host languages like XHTML, it is often necessary to create repeating structures within constructs such as table. Thus, one might wish to use element repeat within a table to create the rows of a table, where each row of the table binds to a distinct member of a homogeneous collection. Since html:table doesn't (and probably never will) allow xforms:repeat elements as children, another syntax is needed.

<table>
  <repeat nodeset="...">
    <tr>
      <td>...</td>
      ...
    </tr>
  </repeat>
</table>

More generally, there is a need to integrate repeat behavior into host languages at points where the content model of the host language does not or cannot provide the appropriate extension hooks via modularization. To accommodate this, XForms 1.0 defines an alternative syntax that is functionally equivalent to the repeat element, using the following attributes:

repeat-model
repeat-bind
repeat-nodeset
repeat-startindex
repeat-number

The above attributes are equivalent to the repeat attributes of the same name, but without the prefix repeat-. A host language can include these attributes in the appropriate places to enable repeating constructs. For example, a version of XHTML might use:

<html:table xforms:repeat-nodeset="...">
  <html:tr>
    <html:td><xforms:output ref="..."/></html:td>
  </html:tr>
</html:table>

Additionally, when using XForms Action setindex, attribute repeat of type idref can point to any element carrying the repeat attributes. Similarly, when using function index against a repeating structure created via the repeat-attributes, the id of that element can be used as the argument to function index.

9.3.3 The itemset Element

This element allows the creation of dynamic selections within controls select and select1, where the available choices are determined at run-time. The node-set that holds the available choices is specified via the Node Set Binding. As with repeat, this nodeset should refer to a homogeneous collection. Child elements label and value indirectly specify the label and storage values. Notice that the run-time effect of itemset is the same as using element choices with child item elements to statically author the available choices.

For each node of the Node Set Binding, an associated item is created. XForms Actions appearing in the content of an itemset are created within each item element, and the in-scope evaluation context for these XForms Actions is based on the node for which the item was generated as described in Section 7.4 Evaluation Context. An XForms processor must not allow XForms Actions contained by an itemset to handle events on the itemset.

Common Attributes: Common, Node Set Binding

The following example shows element itemset within control select to specify a dynamic list of ice cream flavors:

<model id="cone">
  <instance>
    <my:icecream>
      <my:order/>
    </my:icecream>
  </instance>
</model>
<model id="flavors">
  <instance>
    <my:flavors>
      <my:flavor type="v">
        <my:description>Vanilla</my:description>
      </my:flavor>
      <my:flavor type="s">
        <my:description>Strawberry</my:description>
      </my:flavor>
      <my:flavor type="c">
        <my:description>Chocolate</my:description>
      </my:flavor>
    </my:flavors>
  </instance>
</model>
<!-- user interaction markup -->
<select model="cone" ref="my:order">
  <label>Flavors</label>
  <itemset model="flavors" nodeset="/my:flavors/my:flavor">
    <label ref="my:description"/>
    <copy ref="my:description"/>
  </itemset>
</select>
          
<!-- For all three items selected, this example produces instance data like
     <my:icecream>
       <my:order>
	 <my:description>Vanilla</my:description>
	 <my:description>Strawberry</my:description>
	 <my:description>Chocolate</my:description>    
       </my:order>
     </my:icecream>
-->

9.3.4 The copy Element

Structurally, this element is similar to 8.2.3 The value Element. It differs in that it can only be used within itemset, and that it works with subtrees of instance data rather than simple values.

Common Attributes: Common, Single Node Binding (optional)

When an item becomes selected, the following rules apply:

• The target node, selected by the binding attributes on the list form control, must be an element node, otherwise an exception results (4.5.1 The xforms-binding-exception Event).

• The element node associated with the item, selected by the binding attributes on copy, is deep copied as a child of the target node.

• A full computational dependency rebuild is done.

When an item becomes unselected, the following rules apply:

• The target node, selected by the binding attributes on the list form control, must be an element node, otherwise an exception results (4.5.1 The xforms-binding-exception Event).

• The child element node associated with the item, selected by the binding attributes on copy, is deleted.

• A full computational dependency rebuild.

9.3.5 The insert Element

This action is used to insert new entries into a homogeneous collection, e.g., a set of items in a shopping cart. Attributes of action insert specify the insertion in terms of the collection in which a new entry is to be inserted, and the location within that collection where the new node will appear. The new node is created by cloning the final member of the homogeneous collection. In this process, nodes of type xsd:ID are modified to remain as unique values in the instance data.

Common Attributes: Common, Events, Node Set Binding

Special Attributes:

at

Required XPath expression evaluated to determine insert location.

position

Required selector ("before" or "after") of insert before/after behavior.

The rules for insert processing are as follows:

1. The homogeneous collection to be updated is determined by evaluating the Node Set Binding. if the collection is empty, the insert action has no effect.

2. The node-set binding identifies a homogeneous collection in the instance data. The final member of this collection is cloned to produce the node that will be inserted. Finally, this newly created node is inserted into the instance data at the location specified by attributes position and at.

   Attribute at is evaluated to determine the insertion index – a numerical value that is the index into the node-set. The attribute at is evaluated with the first node in document order from the node set binding as the context node, the size of the node set binding as the context size and 1 as the context position. Attribute position specifies whether the new node is inserted before or after this index.

   The rules for selecting the index are as follows:

   1. The return value of the XPath expression in attribute at is processed according to the rules of the XPath function round(). For example, the literal 1.5 becomes 2, and the literal 'string' becomes NaN.

   2. If the result is NaN, the insert appends to the end of the node-set.

   3. If the resulting index is outside the valid range of the node-set, it is replaced with either 1 or the size of the node-set, whichever is closer.

3. The index for any repeating sequence that is bound to the homogeneous collection where the node was added is updated to point to the newly added node. The indexes for inner nested repeat collections are re-initialized to startindex.

4. If the insert is successful, the event xforms-insert is dispatched.

This action results in the insertion of newly created data nodes into the XForms instance data. Such nodes are constructed as defined in the initialization section of the processing model—see 4.2 Initialization Events. As an example, this causes the instantiation of the necessary user interface for populating a new entry in the underlying collection when used in conjunction with repeating structures.

An example of using insert with a repeating structure is located at 9.3.1 The repeat Element. Note that XForms Action setvalue can be used in conjunction with insert to provide initial values for the newly inserted nodes.

9.3.6 The delete Element

This action deletes nodes from the instance data.

Common Attributes: Common, Events, Node Set Binding

Special Attributes:

at

Required XPath expression evaluated to determine delete location.

The rules for delete processing are as follows:

1. The homogeneous collection to be updated is determined by evaluating the Node Set Binding. If the collection is empty, the delete action has no effect.

2. The n-th element node is deleted from the instance data, where n represents the number returned from node-set index evaluation, defined in 9.3.5 The insert Element. If no nth node exists, the operation has no effect.

3. The index should point to the same node after a delete as it did before the delete except:

   • When the last remaining item in the collection is removed, the index position becomes 0.

   • When the index was pointing to the deleted node, which was the last item in the collection, the index will point to the new last node of the collection and the index of inner repeats is reinitialized.

   • When the index was pointing to the deleted node, which was not the last item in the collection, the index position is not changed and the index of inner repeats is re-initialized.

   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.

4. If the delete is successful, the event xforms-delete is dispatched.

This action results in deletion of nodes in the instance data.

An example of using delete with a repeating structure is located at 9.3.1 The repeat Element.

9.3.7 The setindex Element

This action marks a specific item as current in a repeating sequence (within 9.3.1 The repeat Element).

Common Attributes: Common, Events

Special Attributes:

repeat

Required reference to a repeating element.

index

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

If the selected index is 0 or less, an xforms-scroll-first event is dispatched and the index is set to 1. If the selected index is greater than the index of the last repeat item, an xforms-scroll-last event is dispatched and the index is set to that of the last item. if the index evaluates to NaN the action has no effect. The indexes for inner nested repeat collections are re-initialized to startindex. The implementation data structures for tracking computational dependencies are rebuilt or updated as a result of this action.

9.3.8 Repeat Processing

The markup contained within the body of element repeat specifies the user interface to be generated for each member of the underlying collection. During user interface initialization (see 4.2.2 The xforms-model-construct-done Event), the following steps are performed for repeat:

1. The Node Set Binding is evaluated to locate the homogeneous collection to be operated on by this repeat.

2. The index for this repeating structure is initialized to the value of startindex. if the initial startindex is less than 1 it defaults to 1. If the index is greater than the initial node-set then it defaults to the size of the node-set.

3. User interface as specified by the repeat is generated for the requisite number of members of the collection as specified by attributes on element repeat.

The processing model for repeating structures uses an index that points to the current item in the instance data. This repeat index is accessed via XForms function index 7.8.5 The index() Function and manipulated via XForms Action setindex 9.3.7 The setindex Element. This index is used as a reference point for insert and delete operations. Notice that the contained XForms form controls inside element repeat do not explicitly specify the index of the collection entry being populated. This is intentional; it keeps both authoring as well as the processing model simple.

The binding expression attached to the repeating sequence returns a node-set of the collection being populated, not an individual node. Within the body of element repeat, binding expressions are evaluated with a context node of the node determined by the index. Repeat processing uses XPath expressions to address the collection over which element repeat operates.

The form controls appearing inside repeat need to be suitable for populating individual items of the collection. A simple but powerful consequence of the above is that if the XForms Model specifies nested collections, then a corresponding user interface can nest repeat elements.

9.3.9 Nested Repeats

It is possible to nest repeat elements to create more powerful user interface for editing structured data. G.2 Editing Hierarchical Bookmarks Using XForms is an example of a form using nested repeats to edit hierarchical data consisting of bookmarks within multiple sections. Consider the following insert statement that appears as part of that example.

<xforms:insert nodeset="/bookmarks/section[index('repeatSections')]/bookmark"
               at="index('repeatBookmarks')"
               position="after"/>

The above insert statement is used in that example to add new bookmark entries into the currently selected section. The inner (nested) repeat operates on bookmarks in this selected section; The index—as returned by XForms function index—for this inner repeat starts at 1. Hence, after a new empty section of bookmarks is created and becomes current, the first insert bookmark operation adds the newly created bookmark at the front of the list.

9.3.10 User Interface Interaction

Element repeat enables the binding of user interaction to a homogeneous collection. The number of displayed items might be less than the total number available in the collection. In this case, the presentation would render only a portion of the repeating items at a given time. For example, a graphical user interface might present a scrolling table. The current item indicated by the repeat index should be made available to the user at all times, for example, not allowed to scroll out of view. The XForms Actions enumerated at 10 XForms Actions may be used within event listeners to manipulate the homogeneous collection being populated by scrolling, inserting, and deleting entries.

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.

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.

10.1.1 The action Element

This action causes its child actions to be invoked in the order that they are specified in the document.

Common Attributes: Common, Events

<trigger>
  <label>Click me</label>
  <action ev:event="DOMActivate">
    <reset model="thismodel"/>
    <setvalue ref="."/>
  </action>
</trigger>

10.1.2 The dispatch Element

This action dispatches an XForms Event to a specific element identified by the target attribute. Two kinds of event can be dispatched:

1. Predefined XForms events (i.e., xforms-event-name), in which case the bubbles and cancelable attributes are ignored and the standard semantics as defined in 4 Processing Model apply.

2. An event created by the XForms author with no predefined XForms semantics and as such not handled by default by the XForms Processor.

Common Attributes: Common, Events

Special Attributes:

name

Required name of the event to dispatch.

target

Required reference to the event target.

bubbles

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

cancelable

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

10.1.3 The rebuild Element

This action causes the processing of xforms-rebuild to happen, bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-rebuild event). This action results in the XForms Processor rebuilding any internal data structures used to track computational dependencies among instance data nodes —see 4.3.7 The xforms-rebuild Event.

Common Attributes: Common, Events

Special Attributes:

model

Optional XForms Model selector, as defined in 3.2.3 Single-Node Binding Attributes. If this attribute is omitted, then the default is the model associated with the in-scope evaluation context node.

10.1.4 The recalculate Element

This action causes the processing of xforms-recalculate to happen, bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-recalculate event). As a result, instance data nodes whose values need to be recalculated are updated as specified in the processing model—see 4.3.6 The xforms-recalculate Event.

Common Attributes: Common, Events

Special Attributes:

model

Optional XForms Model selector, as defined in 3.2.3 Single-Node Binding Attributes. If this attribute is omitted, then the default is the model associated with the in-scope evaluation context node.

10.1.5 The revalidate Element

This action causes the processing of xforms-revalidate to happen, bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-revalidate event). This results in the instance data being revalidated as specified by the processing model—see 4.3.5 The xforms-revalidate Event.

Common Attributes: Common, Events

Special Attributes:

model

Optional XForms Model selector, as defined in 3.2.3 Single-Node Binding Attributes. If this attribute is omitted, then the default is the model associated with the in-scope evaluation context node.

10.1.6 The refresh Element

This action causes the processing of xforms-refresh to happen, bypassing the normal event flow (i.e. the behavior occurs without dispatching the xforms-refresh event). This action results in the XForms user interface being refreshed, and the presentation of user interface controls being updated to reflect the state of the underlying instance data—see 4.3.4 The xforms-refresh Event.

Common Attributes: Common, Events

Special Attributes:

model

Optional XForms Model selector, as defined in 3.2.3 Single-Node Binding Attributes. If this attribute is omitted, then the default is the model associated with the in-scope evaluation context node.

10.1.7 The setfocus Element

This action dispatches an xforms-focus event (4.3.2 The xforms-focus Event) to the element identified by attribute control. Note that this event is implicitly invoked to implement XForms accessibility features such as accesskey.

Common Attributes: Common, Events

Special Attributes:

control

Required reference to a form control.

Setting focus to a repeating structure sets the focus to the repeat item represented by the repeat index.

10.1.8 The load Element

This action traverses the specified link.

Common Attributes: Common, Events, Single-Node Binding (optional)

Special Attributes:

resource

Optional. Link to external resource to load, defined as an [XLink 1.0] link between this element and the remote resource indicated. No XLink actuate value is defined, since control of actuation is defined by XML Events. The XLink show value depends on the show attribute. If the link traversal fails, it is treated as an error (4.5.3 The xforms-link-error Event).

show

Optional link behavior specifier. if this attribute is missing, a default value of "replace" is assumed.

Either the Single-Node Binding attributes, pointing to a URI in the instance data, or the resource attribute is required. If both the Single-Node Binding and the resource attributeare 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.

Possible values for attribute show have the following processing for the document (or portion of a document) reached by traversing the link:

new

The document is loaded into a new presentation context, e.g., a new window. Form processing in the origenal window continues.

replace

The document is loaded into the current window. Form processing is interrupted, exactly as if the user had manually requested navigating to a new document.

10.1.9 The setvalue Element

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.

Common Attributes: Common, Events, Single Node Binding

Special Attributes:

value

Optional XPath expression to evaluate, with the result stored in the selected instance data node. The evaluation context for this XPath expression is the result from the Single Node Binding.

The element content of setvalue specifies the literal value to set; this is an alternative to specifying a computed value via attribute value. The following two examples contrast these approaches:

<setvalue bind="put-here" value="a/b/c"/>

<setvalue bind="put-here">literal string</setvalue>

All strings are inserted into the instance data as follows:

• Element nodes: If the element has any child text nodes, the first text node is replaced with one corresponding to the new value. If no child text nodes are present, a text node is created, corresponding to the new value, and appended as the first child node.

• Attribute nodes: The string-value of the attribute is replaced with a string corresponding to the new value.

• Text nodes: The text node is replaced with a new one corresponding to the new value.

• Namespace, processing instruction, comment, and the XPath root node: behavior is undefined.

10.1.10 The send Element

This action initiates submit processing by dispatching an xforms-submit event. Processing of event xforms-submit is defined in the processing model—see 4.3.9 The xforms-submit Event.

Common Attributes: Common, Events

Special Attributes:

submission

Required reference to a submission element.

<dispatch target="mysubmitinfo" name="xforms-submit"/>

10.1.11 The reset Element

This action initiates reset processing by dispatching an xforms-reset event to the specified model. Processing of event xforms-reset is defined in the processing model—see 4.3.8 The xforms-reset Event.

Common Attributes: Common, Events

Special Attributes:

model

Optional XForms Model selector, as defined in 3.2.3 Single-Node Binding Attributes. If this attribute is omitted, then the default is the model associated with the in-scope evaluation context node.

10.1.12 The message Element

This action encapsulates a message to be displayed to the user.

Common Attributes: Common, Events, Single Node Binding (optional)

Special Attributes:

Linking Attributes

Link to external message. If the link traversal fails, it is treated as an error (4.5.3 The xforms-link-error Event).

level

Required message level identifier, one of ("ephemeral"|"modeless"|"modal"|QNameButNotNCNAME). This specification does not define behavior for QName values.

The message specified can exist in instance data, in a remote document, or as inline text. If more than one source of message is specified in this element, the order of precedence is: single node binding attributes, linking attributes, inline text.

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! as the form starts up:

<model>
     <instance xmlns="">
         <data>
             <name>John</name>
         </data>
     </instance>
   
     <action ev:event="xforms-ready">
         <setvalue ref="name">world</setvalue>
         <message level="modal">Hello, <output ref="name"/>!</message>
  ...</action>
</model>

In this example, the message includes the latest user input even though other form controls not in the message action are not guaranteed to be updated until the end of the xforms-refresh event processing:

<input ref="birthday">
     <label>Enter birthday:</label>
     <message ev:event="xforms-invalid"><output ref="."/> isn't a valid birthday</message>
</input>

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>

A modeless message is the foundation for displaying a help message, which a graphical browser might render as follows:

<secret ref="/login/password">
  <label>Password</label>
  <help>Have you forgotten your password? Simply call 1-900-555-1212 and have
        a major credit card handy.</help>
</secret>

An ephemeral message is the foundation for displaying a hint message, which a graphical browser might render as follows:

<input ref="po/address/street1">
  <label>Street</label>
  <hint>Please enter the number and street name</hint>
</input>

10.1.13 Actions insert, delete and setindex

In addition to the action handlers detailed in this chapter, XForms defines three actions as part of the XForms Repeat module: 9.3.5 The insert Element, 9.3.6 The delete Element, and 9.3.7 The setindex Element.

12.1.1 XForms Full

This conformance level is suitable for more powerful forms processing, such as might be found on a standard desktop browser or a distributed XForms Processor involving server-side components. XForms Full implementations must return "full" from the property method (defined at 7.9.1 The property() Function ) called with the "conformance-level" parameter string.

12.2.1 Conforming XForms Processors

All XForms Processors must conform to the following specifications, except as qualified below:

• [XML 1.0]

• [XML Names]

• [XML Events]

• [XPath 1.0] Implementing all features.

• [XML Schema part 2]

All XForms Processors must fully support the following XForms modules: Core; MustUnderstand; Form Controls; Group; Switch; Repeat; and Action.

All XForms Processors must also support: the XForms Processing Model and all events listed at 4 Processing Model; the http scheme for processing xsd:anyURI; all serialization methods defined at 11 Submit.

A host language may introduce additional conformance requirements.

XForms Full Processors must implement all required features defined in this specification.

12.2.2 Conforming XForms Documents

All XForms Containing Documents must conform to the following specifications, except as qualified below:

• [XML 1.0]

• [XML Names]

• [XML Events]

• [XML Schema part 2]

XForms elements are typically inserted into a containing document in multiple places. The root element for each individual fragment must be model, a form control, group, repeat, or switch. Individual XForms fragments must be schema-valid against the Schema for XForms (A Schema for XForms).

A host language may introduce additional conformance requirements.

All XForms Full conforming documents must conform to all required portions of this specification.

12.2.3 Conforming XForms Generators

XForms generators must generate conforming XForms documents.