XForms 1.0

1 About the XForms 1.0 Specification

1.1 Background

Forms are an important part of the Web, and they continue to be the primary means for enabling interactive Web applications. Web applications and electronic commerce solutions have sparked the demand for better Web forms with richer interactions. XForms 1.0 is the response to this demand, and provides a new platform-independent markup language for online interaction between a person (through an XForms Processor) and another, usually remote, agent. XForms are the successor to HTML forms, and benefit from the lessons learned from HTML forms.

Further background information on XForms can be found at http://www.w3.org/MarkUp/Forms/.

1.2 Reading the Specification

This specification has been written with various types of readers in mind—in particular XForms authors and XForms implementors. We hope the specification will provide authors with the tools they need to write efficient, attractive and accessible documents without overexposing them to the XForms implementation details. Implementors, however, should find all they need to build conforming XForms Processors. The specification begins with a general presentation of XForms before specifying the technical details of the various XForms components.

The specification has been written with various modes of presentation in mind. In case of a discrepancy, the online electronic version is considered the authoritative version of the document.

This document uses the terms may, must, and should in accord with [RFC 2119].

1.3 How the Specification is Organized

The specification is organized into the following chapters:

Chapters 1 and 2: An introduction to XForms. The introduction outlines the design principles and includes a brief tutorial on XForms.
Chapters 3 and up: XForms reference manual. The bulk of the reference manual consists of the specification of XForms. This reference defines XForms and how XForms Processors must interpret the various components in order to claim conformance.
Appendixes: Appendixes contain a normative description of XForms described in XML Schema, information on references, and other useful information.

1.4 Documentation Conventions

Throughout this document, the following namespace prefixes and corresponding namespace identifiers are used:

xforms: The XForms namespace 3.1 The XForms Namespace
html: The XHTML namespace [XHTML 1.0]
xsd: The XML Schema namespace [XML Schema part 1]
xsi: The XML Schema for instances namespace [XML Schema part 1]
ev: The XML Events namespace [XML Events]
my: Any user defined namespace

This is only a convention; any namespace prefix may be used in practice.

The following typographical conventions are used to present technical material in this document.

Official terms are defined in the following manner: [Definition: You can find most terms in chapter 13 Glossary Of Terms]. Links to terms may be specially highlighted where necessary.

The XML representations of various elements within XForms are presented using the syntax for Abstract Modules in XHTML Modularization [XHTML Modularization].

Examples are set off typographically:

Example: Example item

Example Item

References to external documents appear as follows: [Sample Reference] with links to the references section of this document.

Sample Reference: Reference - linked to from above.

The following typesetting convention is used for non-normative commentary:

Note:

A gentle explanation or admonition to readers.

Editorial note: Editorial Note Name
Editorial commentary, not intended for final publication.

Issue (sample-implementation-issue):

Issue-Name

A specific issue for which input from implementors is requested, as part of the Candidate Recommendation phase.

Resolution:

None recorded.

2 Introduction to XForms

XForms have been designed on the basis of several years' experience with HTML forms. HTML Forms have formed the backbone of the e-commerce revolution, and having shown their worth, have also indicated numerous ways they could be improved.

The primary difference when comparing XForms with HTML Forms, apart from XForms being in XML, is the separation of the data being collected from the markup of the controls collecting the individual values. By doing this, it not only makes XForms more tractable by making it clear what is being submitted where, it also eases reuse of forms, since the underlying essential part of a Form is no longer irretrievably bound to the page it is used in.

A second major difference is that XForms, while designed to be integrated into XHTML, is no longer restricted only to be a part of that language, but may be integrated into any suitable markup language.

XForms has striven to improve authoring, reuse, internationalization, accessibility, usability, and device independence. Here is a summary of the primary benefits of using XForms:

Strong typing: Submitted data is strongly typed and can be checked using off-the-shelf tools. This speeds up form filling since it reduces the need for round trips to the server for validation.
XML submission: This obviates the need for custom server-side logic to marshal the submitted data to the application back-end. The received XML instance document can be directly validated and processed by the application back-end.
Existing schema re-use: This obviates duplication, and ensures that updating the validation rules as a result of a change in the underlying business logic does not require re-authoring validation constraints within the XForms application.
External schema augmentation: This enables the XForms author to go beyond the basic set of constraints available from the back-end. Providing such additional constraints as part of the XForms Model enhances the overall usability of the resulting Web application.
Internationalization: Using XML 1.0 for instance data ensures that the submitted data is internationalization ready.
Enhanced accessibility: XForms separates content and presentation. User interface controls encapsulate all relevant metadata such as labels, thereby enhancing accessibility of the application when using different modalities. XForms user interface controls are generic and suited for device-independence.
Multiple device support: The high-level nature of the user interface controls, and the consequent intent-based authoring of the user interface makes it possible to re-target the user interaction to different devices.
Less use of scripting: By defining XML-based declarative event handlers that cover common use cases, the majority of XForms documents can be statically analyzed, reducing the need for imperative scripts for event handlers.

2.1 An Example

In the XForms approach, forms are comprised of a section that describes what the form does, called the XForms Model, and another section that describes how the form is to be presented.

Consider a simple electronic commerce form that might be rendered as follows:

It is clear that we are collecting a value that represents whether cash or credit card is being used, and if a credit card, its number and expiration date.

This can be represented in the XForms model element, which in XHTML would be contained within the head element:

<xforms:model>
  <xforms:instance>
    <root>
      <method/>
      <number/>
      <expiry/>
    </root>
  </xforms:instance>
  <xforms:submission action="http://example.com/submit" method="post" id="submit"/>
</xforms:model>

This simply says that we are collecting three pieces of information (note that we have as yet not said anything about their types), and that they will be submitted using the URL in the action attribute.

XForms 1.0 defines a device-neutral, platform-independent set of form controls suitable for general-purpose use. The controls are bound to the XForms model via the XForms binding mechanism, in this simple case using the ref attribute on the controls. This markup would appear within the body of an XHTML document (note that we have intentionally defaulted the XForms namespace prefix here):

<select1 ref="method">
  <label>Select Payment Method</label>
  <item>
    <label>Cash</label>
    <value>cash</value>
  </item>
  <item>
    <label>Credit</label>
    <value>cc</value>
  </item>
</select1>
<input ref="number">
  <label>Credit Card Number</label>
</input>
<input ref="expiry">
  <label>Expiration Date</label>
</input>
<submit submission="submit">
  <label>Submit</label>
</submit>

Notice the following features of this design:

The user interface is not hard-coded to use radio buttons. Different devices (such as voice browsers) can render the concept of "select one" as appropriate.
Form controls always have labels directly associated with them as child elements—this is a key feature designed to enhance accessibility.
There is no need for an enclosing form element, as in HTML. (See 2.4 Multiple Forms per Document for details on how to author multiple forms per document)
Markup for specifying form controls has been simplified in comparison with HTML forms.

The fact that you can bind form controls to the model like this simplifies integrating XForms into other host languages, since any form control markup may be used to bind to the model.

2.2 Providing XML Instance Data

The XForms Processor can directly submit the data collected as XML instance data. In the example, the submitted data would look like this:

Example: Submitted Data

<root>
  <method>cc</method>
  <number>1235467789012345</number>
  <expiry>2001-08</expiry>
</root>

XForms processing keeps track of the state of the partially filled form through this instance data. Initial values for the instance data may be provided or left empty as in the example. Element instance essentially holds a skeleton XML document that gets updated as the user fills out the form. It gives the author full control on the structure of the submitted XML data, including namespace information. When the form is submitted, the instance data is serialized as an XML document. Here is a fuller version of the above example:

Example: Model

<xforms:model>
  <xforms:instance>
    <payment method="cc" xmlns="http://commerce.example.com/payment">
      <number/>
      <expiry/>
    </payment>
  </xforms:instance>
  <xforms:submission action="http://example.com/submit" method="post"/>
</xforms:model>

In this case the submitted data would look like this:

Example: Submitted Data

<payment method="cc" xmlns="http://commerce.example.com/payment">
  <number>1235467789012345</number>
  <expiry>2001-08</expiry>
</payment>

This design has features worth calling out:

There is complete flexibility in the structure of the XML instance data, including the use of attributes. Notice that XML namespaces are used, and that a wrapper element of the author's choosing contains the instance data.
Empty elements number and expiry serve as place-holders in the XML structure, and will be filled in with form data provided by the user.
An initial value ("cc") for the form control is provided through the instance data, in this case an attribute method. In the submitted XML, this initial value will be replaced by the user input, if the user changes the form control displaying that data.

To connect this instance data with form controls, the ref attributes on the form controls need to be changed to point to the proper part of the instance data, using binding expressions:

Example: Binding Form Controls to Instance Nodes with ref

... xmlns:my="http://commerce.example.com/payment"
...
<xforms:select1 ref="@method">
...
<xforms:input ref="my:number">
...
<xforms:input ref="/my:payment/my:expires">

Binding expressions are based on XPath [XPath 1.0], including the use of the @ character to refer to attributes, as seen here. Note that for illustrative purposes, the first two expressions make use of the XPath context node, which defaults to the top-level element (here my:payment). The third expression shows an absolute path.

2.3 Constraining Values

XForms allows data to be checked for validity as the form is being filled. In the absence of specific information about the types of values being collected, all values are returned as strings, but it is possible to assign types to values in the instance. For instance in the example, number should accept digits only, and should have between 14 and 18 digits and expiry should accept only valid month/date combinations.

Furthermore, the credit card information form controls for number and expiry are only relevant if the "cc" option is chosen for method, but are required in that case.

By specifying an additional component, model item properties, authors can include rich declarative validation information in forms. Such information can be taken from XML Schemas as well as XForms-specific additions, such as relevant. Such properties appear on bind elements, while Schema constraints are expressed in an XML Schema fragment, either inline or external. For example:

Example: Declarative Validation with Model Item Properties

... xmlns:my="http://commerce.example.com/payment"...

<xforms:model>
    ...
  <xforms:bind ref="/my:payment/my:number"
      relevant="/my:payment/@as = 'cc'"
      required="true()"
      type="my:ccnumber"/>

  <xforms:bind ref="/my:payment/my:expiry"
      relevant="/my:payment/@as = 'cc'"
      required="true()"
      type="xsd:gYearMonth"/>

  <xsd:schema ...>
    ...
    <xsd:simpleType name="ccnumber">
      <xsd:restriction base="xsd:string">
        <xsd:pattern value="\d{14,18}"/>
      </xsd:restriction>
    </xsd:simpleType>
    ...
  </xsd:schema>
</xforms:model>

Note:

In the above example, the relevant expression uses absolute XPath notation (beginning with /) because the evaluation context nodes for computed expressions are determined by the bind ref binding expression (see 7.3 Evaluation Context), and so any relative node path in the first bind relevant above would be relative to /my:payment/my:number

2.4 Multiple Forms per Document

XForms processing places no limits on the number of individual forms that can be placed in a single containing document. When a single document contains multiple forms, each form needs a separate model element. The first model element may omit a unique id attribute (as have all the examples above), but subsequent model elements require an id attribute so that they can be referenced from elsewhere in the containing document.

In addition, form controls need to specify which model element contains the instance data to which they bind. This is accomplished through a model attribute alongside the ref attribute. The default for the model attribute is the first model element in document order.

The next example adds an opinion poll to our electronic commerce form.

Example: Adding a poll model

<xforms:model>
  <xforms:instance>
    ...payment instance data...
  </xforms:instance>
  <xforms:submission action="http://example.com/submit" method="post"/>
</xforms:model>

<xforms:model id="poll">
  <xforms:instance>
    <helpful/>
  </xforms:instance>
  <xforms:submission id="pollsubmit" .../>
</xforms:model>

Additionally, the following markup would appear in the body section of the document:

Example: Form Controls for poll model

<xforms:select1 ref="/helpful" model="poll">
  <xforms:label>How useful is this page to you?</xforms:label>
  <xforms:item>
    <xforms:label>Not at all helpful</xforms:label>
    <xforms:value>0</xforms:value>
  </xforms:item>
  <xforms:item>
    <xforms:label>Barely helpful</xforms:label>
    <xforms:value>1</xforms:value>
  </xforms:item>
  <xforms:item>
    <xforms:label>Somewhat helpful</xforms:label>
    <xforms:value>2</xforms:value>
  </xforms:item>
  <xforms:item>
    <xforms:label>Very helpful</xforms:label>
    <xforms:value>3</xforms:value>
  </xforms:item>
</xforms:select1>

<xforms:submit submission="pollsubmit">
  <xforms:label>Submit</xforms:label>
</xforms:submit>

The main difference here is the use of model="poll", which identifies the instance.

More XForms examples can be found in G Complete XForms Examples.

3 Document Structure

XForms 1.0 is an application of XML [XML 1.0] and has been designed for use within other XML vocabularies—in particular within a future version of XHTML [XHTML 1.0]. XForms always requires such a host language. This chapter discusses the structure of XForms that allow XForms to be used with other document types.

3.1 The XForms Namespace

The XForms namespace has the URI: http://www.w3.org/2002/08/xforms/cr. Any future Working Drafts are expected to use a different identifier, though a final identifier will be allocated before XForms becomes a W3C Recommendation.

XForms Processors must use the XML namespaces mechanism [XML Names] to recognize elements and attributes from this namespace.

3.2 XForms Core Attribute Collections

3.2.1 Common Attributes

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

anyAttribute: Foreign attributes are allowed on all XForms elements.

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

3.2.2 Linking Attributes

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

src: The src attribute assigns a URI to be automatically retrieved.

Note:

Since linking attribute URIs are defined in terms of the XML Schema datatype xsd:anyURI, the same internationalization benefits and whitespace cautions apply as discussed in [XML Schema part 2].

All linking attributes behave as an [XLink 1.0] link between the current document and the resource indicated, with an actuate value of "onLoad" and a show value of "embed". Behavior of relative URIs in links is determined by the host language, although [XML Base] processing is strongly recommended.

Note:

The XForms Working Group is tracking with the HTML Working Group on a method of describing link structures.

3.2.3 Single-Node Binding Attributes

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

ref: Binding expression. This attribute has no meaning when a bind attribute is present.
model: XForms Model selector. Optional when a containing document contains only one XForms Model, otherwise required, except when the bind attribute is present, in which case this attribute has no meaning.
bind: Reference to a bind element.

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

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

3.2.4 Node-Set Binding Attributes

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

nodeset: Binding expression. This attribute has no meaning when a bind attribute is present.
model: XForms Model selector. Optional when a containing document contains only one XForms Model, otherwise required, except when the bind attribute is present, in which case this attribute has no meaning.
bind: Reference to a bind element.

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

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.3 The XForms Core Module

The XForms Core Module defines the major structural elements of XForms, intended for inclusion in a containing document. The elements and attributes included in this module are:

Element	Attributes	Minimal Content Model
model	Common, functions (QNameList), schema (list of xsd:anyURI)	(instance\|xsd:schema\| submission\|bind\|Action)*
instance	Common, Linking	(ANY)
submission	Common, ref (binding-expression), action (xsd:anyURI), mediatype (xsd:string), method ("post"\|"get"\|"put"\|qname-but-not-ncname), version (xsd:NMTOKEN), indent (xsd:boolean), encoding (xsd:string), omit-xml-declaration (xsd:boolean), standalone (xsd:boolean), cdata-section-elements (QNameList), replace ("all"\|"instance"\|"none"\|qname-but-not-ncname), separator (';' \| '&')	Action*
bind	Common, nodeset (model-binding-expression), type (xsd:QName), readonly (xsd:string), required (xsd:string), relevant (xsd:string), constraint (xsd:string), calculate (xsd:string), minOccurs (xsd:nonNegativeInteger\|"unbounded"), maxOccurs (xsd:nonNegativeInteger)	(bind)*

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

Within the containing document, these structural elements are typically not rendered.

The XForms Processor must ignore any foreign-namespaced attributes that are unrecognized, and must process unrecognized foreign-namespaced elements according to the 3.4 The XForms MustUnderstand Module rules.

Note that the presence of foreign namespaced elements is subject to the definition of the containing document profile.

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

Special Attributes:

functions: Optional list of XPath extension functions used by this XForms Model. It is an error to use an undeclared extension function.
schema: Optional link to a list of XML Schema documents that should be processed along with this instance data. The XML Schemas may be a sibling element referenced by a URI fragment, such as "#myschema". The XForms Processor must process all Schemas listed on this attribute.

Issue (locating-schemas):

The Working Group requests implementation feedback on this technique of locating XML Schemas required for form processing.

Resolution:

None recorded.

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

Example: Model

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

The content of the instance element is arbitrary XML in any namespace. The content of this element is treated as opaque data, used to create an XPath data model consisting of various nodes. Authors must ensure that proper namespace declarations are used for content within the instance element.

3.3.3 The submission Element

This element encodes how, where, and what to submit.

XML Representation: <submission>

This element represents declarative instructions on what to submit, and how.

Common Attributes: Common

Special Attributes:

ref: Optional selector binding expression enabling submission of a portion of the instance data. The selected node, and all children, are selected for submission.
action: Required destination URI for submitting instance data.
mediatype: Optional attribute specifying, in the form of a media-type string, a serialization format for the instance data. The default value is "application/xml".
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 whitespace nodes for readability.
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 CDATAsections.
replace: Optional attribute specifying how the information returned after submit should be applied. In the absence of this attribute, "all" is assumed.
separator: Optional attribute specifying the separator character between name/value pairs in urlencoding. The default value is ';'.

The following attributes correspond to (in spelling, processing, and default values) 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

Note:

The following XSLT attributes have no counterpart in XForms:

doctype-system
doctype-public

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. If the bind has an attribute of type xsd:ID, the bind then associates that identifier with the selected node-set.

Common Attributes: Common

Special Attributes:

nodeset: A model binding expression that selects the set of nodes on which this bind operates, as defined in 7.4.1 Model Binding Expressions.
model item properties: One attribute for each model item property as defined in 6.1 Model Item Property Definitions.

When additional nodes are added through action insert, the newly added nodes are included in any node-sets matched by binding expressions—see action insert in 9.3.5 The insert Element.

See 7.3 Evaluation Context for details on how binding affects the evaluation context.

3.4 The XForms MustUnderstand Module

Certain elements, such as extension or foreign namespaced elements defined in a host language might be critical to the operation of a particular form. To indicate this, the MustUnderstand module defines a single attribute that can be used on any element.

Element	Attributes	Minimal Content Model
ANY	xforms:mustUnderstand (xsd:boolean)	n/a

It is a fatal error if an element is marked mustUnderstand="true", and the XForms processor does not have an implementation available for processing the element.

3.5 The XForms Extension Module

There are many different ways a host language might include XForms. One approach uses only well-formed processing, disregarding validation. Another case uses strict validation, for example XHTML 1.0, in which only predefined elements are allowed. Another common approach is to allow unregulated content in a few selected places. A host language that chooses this option can use the Extension module.

Element	Attributes	Minimal Content Model
extension	Common	ANY

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

This chapter defines the XForms Processing Model declaratively by enumerating the various states attained by an XForms Processor and the possible state transitions that exist in each of these states. The chapter enumerates the pre-conditions and post-conditions that must be satisfied in each of these states. XForms Processors may be implemented in any manner, so long as the end results are identical to that described in this chapter.

State transitions are in general initiated by sending events to parts of the XForms tree. The XForms Processing Model consists of events in the following categories:

Initialization
Interaction
Notification
Error Conditions

4.1 Events Overview

XForms processing is defined in terms of events, event handlers, and event responses. XForms uses the events system defined in [DOM2 Events][XML Events], with an event capture phase, arrival of the event at its Target, and finally the event bubbling phase.

Event name	Cancelable?	Bubbles?	Target element
4.2 Initialization Events
xforms-model-construct	No	No	`model`
xforms-model-initialize	No	No	`model`
xforms-initialize-done	No	No	`model`
xforms-ui-initialize	No	No	`model`
xforms-form-control-initialize	No	No	form control
xforms-model-destruct	No	No	`model`
4.3 Interaction Events
xforms-previous	Yes	No	form control
xforms-next	Yes	No	form control
xforms-focus	Yes	No	form control
xforms-help	Yes	Yes	form control
xforms-hint	Yes	Yes	form control
xforms-refresh	Yes	Yes	`model`
xforms-revalidate	Yes	Yes	`model`
xforms-recalculate	Yes	Yes	`model`
xforms-reset	Yes	Yes	`model`
xforms-submit	Yes	Yes	`submission`
4.4 Notification Events
xforms-activate	Yes	Yes	form control
xforms-value-changing	Yes	Yes	form control
xforms-value-changed	Yes	Yes	form control
xforms-select	Yes	Yes	`item` or `case`
xforms-deselect	Yes	Yes	`item` or `case`
xforms-scroll-first	Yes	Yes	`repeat`
xforms-scroll-last	Yes	Yes	`repeat`
xforms-insert	Yes	Yes	`instance`
xforms-delete	Yes	Yes	`instance`
xforms-valid	No	Yes	form control
xforms-invalid	No	Yes	form control
DOMFocusIn	No	No	form control
DOMFocusOut	No	No	form control
xforms-readonly	No	Yes	form control
xforms-readwrite	No	Yes	form control
xforms-required	No	Yes	form control
xforms-optional	No	Yes	form control
xforms-enabled	No	Yes	form control
xforms-disabled	No	Yes	form control
xforms-submit-done	No	Yes	`submission`
xforms-submit-error	No	Yes	`model`
4.5 Error Indications
xforms-bind-exception	No	Yes	`model`
xforms-link-exception	No	Yes	`model`
xforms-link-error	No	Yes	`model`
xforms-compute-exception	No	Yes	`model`

4.2 Initialization Events

This section defines the various stages of the initialization phase. The processor begins initialization by dispatching an event xforms-model-construct to each XForms Model in the containing document.

4.2.1 The xforms-model-construct Event

Dispatched by the containing document processor to bootstrap XForms Processor initialization.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

All XML Schemas loaded. If an error occurs while attempting to access a remote document, processing halts with an exception (4.5.2 The xforms-link-exception Event).
If an external source for the instance is given, an XPath data model [7 XPath Expressions in XForms] is constructed from it; otherwise if an inline instance is given, that is used instead. If neither are given, the data model is not constructed in this phase, but during user interface construction (4.2.5 The xforms-form-control-initialize Event).
Following this, an xforms-model-initialize event is dispatched to element model.

4.2.2 The xforms-model-initialize Event

Dispatched at the conclusion of xforms-model-construct processing.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

If applicable, P3P initialized. [P3P 1.0]
Instance data is constructed. All strings inserted into the instance data are subject to Unicode normalization. All model item properties are initialized by processing all bind elements in document order. For each bind:
1. The attribute nodeset attached to the bind is evaluated, resulting in a set of nodes selected.
2. For each node in the node-set, model item properties are applied according to the remaining attributes on bind: the string value of each attribute (with a name matching one of the properties defined in 6.1 Model Item Property Definitions) is copied as the local value of the model item property of the same name.
3. If the node already contains a model item property of the same name, XForms processing for this containing document halts with an exception (4.5.1 The xforms-binding-exception Event).
The xforms-initialize-done event is dispatched to the model element after initialization of that model element is completed but before rendering of the UI has started.
The events xforms-rebuild, xforms-recalculate, and xforms-revalidate are dispatched to the model element in sequence. (The xforms-refresh event is not dispatched since the user interface has not yet been initialized).
After all XForms Models are initialized, (which includes completely processing xforms-rebuild, xforms-recalculate, and xforms-revalidate) an xforms-ui-initialize event is dispatched to each model element.

4.2.3 The xforms-initialize-done Event

Dispatched as part of xforms-model-initialize processing.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following: None; notification event only.

4.2.4 The xforms-ui-initialize Event

Dispatched as part of xforms-model-initialize processing.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

The processor traverses the containing document, and for each form control, dispatches a xforms-form-control-initialize event to the form control.

4.2.5 The xforms-form-control-initialize Event

Dispatched as part of xforms-ui-initialize processing.

Target: form control

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

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

If the instance referenced on the form control existed when the first xforms-form-control-initialize event was processed:

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 xforms-form-control-initialize event for a form control that referenced the same instance was processed:

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

4.2.6 The xforms-model-destruct Event

Bubbles: No

Cancelable: Yes

Context Info: None

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

Default processing for this event results in the following: 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

Default processing for this event results in the following:

The default handling for this event must satisfy the following conditions:

All instance data nodes in all instance elements in the model are checked against any specified XML Schema.
All instance data nodes in all instance elements in the model are checked against any bound model item properties which define constraints on the value, i.e. required, constraint, minOccurs, maxOccurs (6 Model Item Properties).
The appropriate xforms-valid or xforms-invalid events are dispatched to all form controls that are bound to instance data nodes in the model. (See 4.4.7 The xforms-valid Event and 4.4.8 The xforms-invalid Event).

Note:

Prior to completion of the xforms-ui-initialize event handler, there are no form controls bound to instance data, so xforms-valid and xforms-invalid events are not dispatched.

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

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

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 compute, the XPath expression is evaluated in the context of the instance node whose value or model item property is associated with the compute. 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. Self-references 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 have been changed, e.g., by user input being propagated to the instance.

An XForms processor must not recalculate computes that are not computationally dependent on one or more of the elements in L.
An XForms processor must perform a single recalculation of each compute that is computationally dependent on one or more of the elements in L.
An XForms processor must recalculate a compute C after recalculating all computes of instance nodes on which C is computationally dependent. (Equivalently, an XForms Processor must recalculate a compute C before recalculating any compute that is computationally dependent on the instance node associated with C.)
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).

Issue (recalculation-strictness):

The Working Group requests implementation feedback on whether bullets 1 and 2 above, forbidding certain computational redundancies, are neccessary for conformance to XForms 1.0.

Resolution:

None recorded.

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

Default processing for this event results in the following:

The default processing for this event is that the computational dependency data structures are rebuilt, then the change list L is set to contain references to all instance nodes that have an associated computational expression such that a full recalculate is performed the next time the xforms-recalculate event is dispatched to the model.

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

Default processing 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-initialize-done 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 Notification Events

4.4.1 The xforms-activate 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

Default processing for this event results in the following: None; notification event only.

4.4.2 The xforms-value-changing Event

Dispatched in response to: an interactive change to an instance data node bound to a form control that has the attribute 'incremental' set to 'true'.

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for this event results in the following: None; notification event only.

Setting the value of attribute incremental to true on a form control enables interactive response without finalizing on a value. Examples of this include edit boxes (users can type various characters before navigating away) and slider controls (users can be continuously adjusting the value before releasing at a certain value).

Note:

This specification does not define how often XForms Processors fire these events. Implementations are expected to optimize processing (for instance not flashing the entire screen for each character entered, etc.).

Note:

The change to the instance data associated with this event happens before the event is dispatched.

4.4.3 The xforms-value-changed Event

Dispatched in response to: a confirmed change to an instance data node bound to a form control, such as when the user navigates away from the form control.

Target: form control

This chapter defines the datatypes used in defining an XForms model.

5.1 XML Schema Built-in Datatypes

XForms supports all XML Schema datatypes except for xsd:duration. Concepts value space, lexical space and constraining facets are as specified in [XML Schema part 2]. XML Schema features used in XForms are divided into two modules, called Basic and Full, which are used respectively by XForms Basic and XForms Full. Base types included in module Basic are marked with an asterisk *. Both modules support datatypes derived by restriction and derived by list from these base types.

Built-in primitive types:

dateTime *
time *
date *
gYearMonth *
gYear *
gMonthDay *
gDay *
gMonth *
string *
boolean *
base64Binary *
hexBinary
float
decimal *
double
anyURI *
QName
NOTATION

Note:

The built-in datatype xsd:duration is not supported at any conformance level, except as an abstract datatype. Instead, either xforms:dayTimeDuration or xforms:yearMonthDuration should be used.

Built-in derived types:

normalizedString
token
language
Name
NCName
ID
IDREF
IDREFS
ENTITY
ENTITIES
NMTOKEN
NMTOKENS
integer *
nonPositiveInteger *
negativeInteger *
long *
int *
short *
byte *
nonNegativeInteger *
unsignedLong *
unsignedInt *
unsignedShort *
unsignedByte *
positiveInteger *

5.2 XForms Datatypes

The Schema for XForms derives the following types to facilitate defining model in XForms. These types are included in XForms Basic as well as XForms Full.

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

Note:

In most cases, it is better to use markup to distinguish items in a list. See 9.3.3 The itemset Element.

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 Model Item Properties

This chapter defines infoset contributions that can be bound to instance data nodes with element bind (see 3.3.4 The bind Element). The combination of these contributions to an instance data node is called a model item. Taken together, these contributions are called model item properties, and are defined in the following section. In contrast, the term Schema constraint refers only to XML Schema constraints from the facets of a given datatype.

6.1 Model Item Property Definitions

Model item properties can be distinguished along various axes.

Computed expressions vs. fixed properties:

Fixed properties are static values that the XForms Processor evaluates only once. Such properties consist of literals, and are not subject to XPath evaluation.
Computed expressions are XPath expressions that provide a value to the XForms Processor. Such values are recalculated at certain times as specified by the XForms Processing Model (see 4 Processing Model). These expressions encode dynamic properties, often constraints, such as the dependency among various data items. Computed expressions are not restricted to examining the value of the instance data node to which they apply. XPath expressions provide the means to traverse the instance data; more complex computations may be encoded as call-outs to external scripts.

Inheritance rules:

Some model item properties define inheritance rules, in which case the XForms processor needs to keep track of two separate values: 1) the local value, which is applied from an attribute of element bind, and 2) the inherited value, which is determined by combining the evaluated local value with the evaluated values from ancestor nodes.

Note:

The sample recalculation algorithm defined in D Recalculation Sequence Algorithm is defined to operate only on the local values of a model item property. It assumes that an implementation propagates the combined values to a node's descendants.

Assigning local values:

Local values are assigned by processing all bind elements in an XForms Model in document order. It is an error to attempt to set a model item property twice on the same node. The details of this process are given at 4.2.2 The xforms-model-initialize Event.

The following sections list the model item properties available as part of all model items. For each, the following information is provided:

Description
Computed Expression (yes or no)
Legal Values
Default Value
Inheritance Rules

6.1.1 The type Property

Description: associates a Schema datatype.

Computed Expression: No.

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

Default Value: xsd:string.

Inheritance Rules: does not inherit.

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

Example: Attaching a XML Schema type constraint

<instance>
  <my:person-name>
    <my:first-name />
    <my:last-name xsi:type="nonEmptyString" />
  </my:person-name>
</instance>
<bind type="nonEmptyString" ref="/my:first-name" />

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

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

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

Note:

This is the equivalent of taking the logical OR of the evaluated readonly property on the local and every ancestor node.

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.

Example: Attaching a readonly property

<instance>
  <my:person-name>
    <my:first-name>Roland</my:first-name>
    <my:last-name xsi:type="nonEmptyString" />
  </my:person-name>
</instance>
<bind type="nonEmptyString" ref="/my:first-name" readonly="true()"/>

Here, we have associated a readonly property with an element.

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:

If the bound instance data node is an element, the element must not have the xsi:nil attribute set to true.
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.

Example: Attaching a required property

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

Here, we have associated a required property with element my:last-name to indicate that a value must be supplied.

Note:

XML Schema has a similarly named concept with use="required|optional|prohibited". This is different than the XForms model item property, in two ways: 1) use applies only to attributes, while XForms required applies to any node. 2) use is concerned with whether the entire attribute must be specified (without regard to value), while required determines whether a value is required of the node before submission.

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 ancestor node evaluates to XPath false, this value is treated as false. Otherwise, the local value is used.

Note:

This is the equivalent of taking the logical AND of the evaluated relevant property on the local and every ancestor node.

Many forms have data entry fields 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 hints to the XForms user interface regarding visibility, focus, and navigation order. In general, when true, associated form controls should be made visible. When false, associated form controls should be made unavailable, removed from the navigation order, and not allowed focus.

Example: Attaching a relevant property

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

Here, we have associated a relevant property with element my:discount to indicate a discount is relevant when the order amount is greater than 1000.

The following table shows the user interface interaction between required and relevant.

	`required="true()"`	`required="false()"`
`relevant="true()"`	The form control (and any children) must be visible or available to the user. The XForms user interface may indicate that a value is required.	The form control (and any children) must be visible or available to the user. The XForms user interface may indicate that a value is optional.
`relevant="false()"`	The form control (and any children) must be hidden or unavailable to the user. Entering a value or obtaining focus should not be allowed. The XForms user interface may indicate that should the form control become relevant, a value would be required.	The form control (and any children) must be hidden or unavailable to the user. Entering a value or obtaining focus should not be allowed.

6.1.5 The calculate Property

Description: supplies an expression used to calculate the value of 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 that 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 value can be expressed as a computed expression using the values of other model items. Chapter 4 Processing Model contains details of when and how the calculation is performed.

Example: Attaching a calculate property

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

Here, we have associated a relevant property with element my:discount to indicate a discount of 10% is relevant when the order amount is greater than 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.

Example: Attaching a constraint property

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

Here, we have associated a constraint property with element my:to to indicate that its value must be greater than that of element my:from.

6.1.7 The maxOccurs Property

Description: for repeating structures, indicates the maximum number of allowed child elements.

Computed Expression: Yes.

Legal Values: xsd:integer or "unbounded".

Default Value: "unbounded".

Inheritance Rules: does not inherit.

For model item elements that are repeated, this optional model item property specifies a maximum number of allowed child elements.

Example: Attaching a maxOccurs property

<instance>
  <my:order>
    <my:item>
      <my:amount />
      <my:discount />
    <my:item>
  </my:order>
</instance>
<bind ref="my:item" minOccurs="1" maxOccurs="4" />

Here, we have associated both minOccurs and maxOccurs properties with element my:item to indicate that there must be a minimum of one and a maximum four elements my:item for the instance to be considered valid.

6.1.8 The minOccurs Property

Description: for repeating structures, indicates the minimum number of allowed child elements.

Computed Expression: Yes.

Legal Values: xsd:integer.

Default Value: 0.

Inheritance Rules: does not inherit.

For model item elements that are repeated, this optional model item property specifies a minimum number of allowed child elements.

6.1.9 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 from a server.

Example: Attaching a type constraint using Binding

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

Here, we have attached both XML Schema and P3P type information to element first-name via element bind.

6.2 Schema Constraints

Chapter 5 Datatypes described how XForms uses the XML Schema datatype system to constrain the value space of data values collected by an XForms Model. Such datatype constraints can be provided via an XML Schema. Alternatively, this section lists various mechanisms for attaching type constraints to instance data. Attributes xsi:schemaLocation and xsi:noNamespaceSchemaLocation are ignored for purposes for locating a Schema. XForms Basic processors have restricted Schema processing requirements as defined in 12.1.2 XForms Basic.

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 may be associated with a model item in one of the following ways (only the first that applies is used, and if multiple type constraints apply to the same node, the first definition in document order is used).

An XML Schema associated with the instance data.
An XML Schema xsi:type attribute in the instance data.
An XForms type constraint associated with the instance data node using XForms binding.
If no type constraint is provided, the data instance node defaults to type="xsd:string" (default to string rule).

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

Example: Type Constraint Using XML Schema

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

This new datatype would then be associated with one or more model items through one of the methods outlined here.

Example: Attaching A Type Constraint

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

This defines element first-name to be of type nonEmptyString.

Example: Attaching Type Constraint Using XForms Binding

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

Here, we have attached type information to element first-name via element bind. Thus the XForms author can extend external schemas without having the ability to change them.

7 XPath Expressions in XForms

XForms uses XPath to address instance data nodes in binding expressions, to express constraints, and to specify calculations. XPath expressions other that are not syntactically valid, including attempted calls to undefined functions, result in an exception (4.5.4 The xforms-compute-exception Event), except for binding expressions, which produce a different exception (4.5.1 The xforms-binding-exception Event).

7.1 XPath Datatypes

XPath data types are used only in binding expressions and computed expressions. XForms uses XPath datatypes boolean, string, number, and node-set. A future version of XForms is expected to use XPath 2.0, which includes support for XML Schema datatypes.

7.2 Instance Data

For each model element, the XForms Processor maintains the state in an internal structure called instance data that conforms to the XPath Data Model [XPath 1.0]. XForms Processors that implement DOM must provide DOM access to this instance data via the interface defined below.

Note:

Instance data always has a single root element, and thus corresponds to a DOM Document.

interface XFormsModelElement : org.w3c.dom.Element

The method getInstanceDocument returns a DOM Document that corresponds to the instance data associated with this XForms Model.

This parameter specifies the ID of an instance element.

Return value: org.w3c.dom.Document

raises (DOMException); if there is no model with the specified instance-id.

Note:

Script invocation of recalculate() is not necessarily equivalent to performing the recalculate action handler. Though the script is assumed to have modified instance data prior to invoking recalculate(), the DOM mutations are not cached. Thus, a full recalculation is necessary to ensure the proper changes are effected throughout the XForms model.

7.3 Evaluation Context

Within XForms, XPath expressions reference abstract instance data (using the "path" portion of XPath), instead of a concrete XML document. This reference is called a binding expression in this specification. Every XPath expression requires an evaluation context. The following rules are used in determining evaluation context when evaluating elements containing binding expressions in XForms:

The context node for outermost binding elements is the top level element node, or the single node returned by /*. A binding element is any element that is explicitly allowed to have a binding expression attribute. A binding element is "outermost" when the node-set returned by the XPath expression ancestor::* includes no binding element nodes.
The context node for non-outermost binding elements is the first node of the binding expression of the immediately enclosing element. An element is "immediately enclosing" when it is the first binding element node in the node-set returned by the XPath expression ancestor::*. This is also referred to as "scoped resolution".
The context node for computed expressions (occurring on element bind) is the first node of the node-set returned from the binding expression in the sibling ref attribute.
The context size and position are both exactly 1.
No variable bindings are in place.
The available function library is defined below, plus any functions supplied by the implementation. Extension functions required for operation of the form should be declared, as described at 7.10 Extension Functions.
Any namespace declarations in scope for the attribute that defines the expression are applied to the expression.

Example: Binding Expression Context Nodes

<group ref="level2/level3">
  <select1 ref="@attr" ... />
</group>

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

Example: Sample Instance

<level1>
  <level2>
    <level3 attr="xyz"/>
  </level2>
</level1>

7.4 Binding Expressions

A binding expression is an XPath LocationPath expression used in binding a model item property to one or more instance nodes, or to bind a form control to the instance, or to specify the a node or node set for operation by an action.

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

Any XPath predicate expression (in square brackets) is a dynamic dependency unless both sides of the comparison are "fixed", where fixed means either a constant, or a value that will not change between operations explicitly defined as rebuilding computational dependencies.

Note:

A dynamic dependency does not result if either side of the predicate is one of the following: position(), last(), count(), or index(); the specification mandates a dependency rebuild after any event that could change the values returned by these functions. Note also that property() is also permitted, since it always returns the same values for the duration of form processing.

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.4.1 Model Binding Expressions

A model binding expression is a kind of binding expression used in bind that can be used to declare model item properties.

No dynamic dependencies are allowed in model binding expressions. Upon detecting a dynamic dependency in a model binding expression, form processing terminates with an exception (4.5.1 The xforms-binding-exception Event).

7.4.2 UI Binding Expressions

Binding references can be used to bind form controls to the underlying data instance 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.4.3 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 legacy HTML user interface controls as shown below. See 3.2.3 Single-Node Binding Attributes and 3.2.4 Node-Set Binding Attributes.

Example: XForms Binding In Legacy HTML User Interface Controls

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

7.4.4 Binding Examples

Consider a document with the following 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.

Example: UI Binding Using Attribute ref

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

Example: UI Binding Using Attribute bind

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

Example: Specifies Model Containing The Instance Explicitly

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

7.5 XForms Core Function Library

The XForms Core Function Library includes the entire [XPath 1.0] Core Function Library, including operations on node-sets, strings, numbers, and booleans.

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

7.6 Boolean Methods

7.6.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, processing stops with an exception (4.5.4 The xforms-compute-exception Event).

7.6.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.7 Number Methods

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

7.7.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, the return value is NaN.

7.7.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, the return value is NaN.

7.7.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.7.5 The index() Function

number index(string)

Function index takes a string argument that is the idref of a repeat and returns the current 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, processing stops with an exception (4.5.4 The xforms-compute-exception Event).

Example: index

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

7.8 String Methods

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

Example: property

<xforms:instance>
  ...
  <xforms:bind ref="info/xforms-version"
      calculate="property('version')"/> ...
</xforms:instance>

7.9 Date and Time Functions

Note:

The following XML Schema datatypes do not have specific functions for manipulation within XForms expressions: xsd:time, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth. Extension functions (7.10 Extension Functions) may be used to perform needed operations on these datatypes.

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

Note:

Attaching a calculation of "now()" to an instance data node would not result in a stream of continuous recalculations of the XForms Model.

7.9.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 and 1970-01-01. Hour, minute, and second components are ignored. 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.9.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 and 1970-01-01T00:00:00Z. If no time zone is specified, an implementation default is used. Any other input string parameter causes a return value of NaN.

7.9.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. If no time zone is specified, an implementation default is used. 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

Note:

Even though this function is defined based on a lexical xsd:duration, it is intended for use only with derived-from-xsd:duration datatypes, specifically xforms:dayTimeDuration.

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

Note:

Even though this function is defined based on a lexical xsd:duration, it is intended for use only with derived-from-xsd:duration datatypes, specifically xforms:yearMonthDuration.

7.10 Extension Functions

XForms documents may use additional XPath extension functions beyond those described here. The names of any such extension functions must be declared in attribute functions on element model. Such declarations are used by the XForms Processor to check against available extension functions. XForms Processors perform this check at the time the document is loaded, and stop processing by signaling an exception (4.5.4 The xforms-compute-exception Event) if the XForms document declares an extension function for which the processor does not have an implementation.

Note:

Explicitly declaring extension functions enables XForms Processors to detect the use of unimplemented extension functions at document load-time, rather than throwing a fatal error during user interaction. Failure by authors to declare extension functions will result in an XForms Processor potentially halting processing during user interaction with a fatal error.

8 Form Controls

8.1 The XForms Form Controls Module

Form controls are declared using markup elements, and their behavior refined via markup attributes.

Element	Attributes	Minimal Content Model
input	Common, UI Common, Single Node Binding, inputmode (xsd:string), incremental (xsd:boolean)	label, (UI Common)*
secret	Common, UI Common, Single Node Binding, inputmode (xsd:string), incremental (xsd:boolean)	label, (UI Common)*
textarea	Common, UI Common, Single Node Binding, inputmode (xsd:string), incremental (xsd:boolean)	label, (UI Common)*
output	Common, Single Node Binding, appearance ("full"\|"compact"\|"minimal"\|xforms:QNameButNotNCNAME)	label?
upload	Common, UI Common, Single Node Binding, mediatype (xsd:string), incremental (xsd:boolean)	label, filename?, mediatype?, (UI Common)*
range	Common, UI Common, Single Node Binding, start (xsd:string), end (xsd:string), step (xsd:string), incremental (xsd:boolean)	label, (UI Common)*
trigger	Common, UI Common, Single Node Binding	label, (UI Common)*
submit	Common, UI Common, Single Node Binding, submission (xsd:IDREF)	label, (UI Common)*
select	Common, UI Common, Single Node Binding, incremental (xsd:boolean)	label, (List UI Common)+, (UI Common)*
select1	Common, UI Common, Single Node Binding, selection ("open" \| "closed"), incremental (xsd:boolean)	label, (List UI Common)+, (UI Common)*
choices	Common	label?, (List UI Common)+
item	Common	label, value, (UI Common)*
filename	Common, Single Node Binding	EMPTY
mediatype	Common, Single Node Binding	EMPTY
value	Common, Single Node Binding	(PCDATA\|ANY)*
label	Common, Single Node Binding, Linking	(PCDATA\|(UI Inline))*
help	Common, Single Node Binding, Linking	(PCDATA\|(UI Inline))*
hint	Common, Single Node Binding, Linking	(PCDATA\|(UI Inline))*
alert	Common, Single Node Binding, Linking	(PCDATA\|(UI Inline))*

Note:

Unless bound to form controls, instance data nodes are not presented to the user; consequently, there is no need for a form control corresponding to HTML input type="hidden".

The following attributes are common to many user-interface related XForms elements, here called the UI Common attribute group.

Element	Attributes
(various)	navindex (xsd:nonNegativeInteger)
(various)	accesskey (xsd:token)
(various)	appearance ("full"\|"compact"\|"minimal"\|QName-but-not-NCName)

navindex: Optional attribute is a non-negative integer in the range of 0-32767 used to define the navigation sequence. This gives the author control over the sequence in which form controls are traversed. The default navigation order is specified in the chapter 4 Processing Model.
accesskey: Optional attribute defines a shortcut for moving the input focus directly to a particular form control. The value of this is typically a single character which when pressed together with a platform specific modifier key (e.g., the alt key) results in the focus being set to this form control.
appearance: Optional attribute to define an appearance hint.

Note:

A host language is expected to add attributes such as xml:lang as well as an attribute, typically named class, that holds a list of strings that can be matched by CSS class selectors.

Additionally, this module defines the following content sets:

Content Set	Minimal Content Model
UI Common	(help\|hint\|alert\|Action)*
List UI Common	(choices\|item\|itemset)+
Form Controls	(input\|secret\|textarea\|output\|upload\|range\|trigger\|submit\|select\|select1)*
UI Inline	(output)*

As shown above, the XML Events module adds the Actions content set into the UI Common content set. A host language should add inline markup to the Inline content set.

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, form controls select and select1 enable the user select one or more 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:

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

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

Special Attributes:

inputmode: This form control accepts an input mode hint. E Input Modes.
incremental: when true, this form control will generate xforms-value-changing 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:

An average-looking text entry form control. The title, 'street' has been automatically aligned to the left

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 data instance of type boolean might be rendered as a checkbox.

<input ref="order/shipDate">
    <label>Ship By</label>
    <hint>Please specify the date 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 field in the box, or press the button to open a calendar:

8.1.3 The secret Element

Description: This form control is used for entering information that is considered sensitive, and thus not echoed to a visual or aural display as it is being entered, e.g., password entry.

Common Attributes: Common, UI Common, Single Node Binding

Special Attributes:

inputmode: This form control accepts an input mode hint. E Input Modes.
incremental: when true, this form control will generate xforms-value-changing events. The default value for this attribute is false.

Example:

Example: Password Entry

<secret ref="/login/password">
  <label>Password</label>
  <hint>Please enter your password --it will not
    be visible as you type.</hint>
</secret>

A graphical browser might render this form control as follows:

An average-looking text entry form control, with '*' characters where the text would be expected

Data Binding Restrictions: Identical to input.

Implementation Requirements: In general, implementations, including accessibility aids, must render a "*" or similar character instead of the actual characters entered, and thus must not render the entered value of this form control. Note that this provides only a casual level of security; truly sensitive information will require additional security 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: This form control accepts an input mode hint. E Input Modes.
incremental: when true, this form control will generate xforms-value-changing events. The default value for this attribute is false.

Example:

Example: Email Message Body

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

A graphical browser might render the above example as follows:

A larger-than-average text entry form control. The title, 'Message Body:' provides an additional hint that large amounts of text are allowed here.

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 typically used to display values from the instance, and is treated as display:inline for purposes of layout.

Common Attributes: Common, Single Node Binding

Special Attributes:

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

Example:

Example: Explanatory Message

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

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

Average-looking text, reading 'I charged you 100.0 - and here is why:'

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: List of suggested media types, used by the XForms Processor to determine which input methods apply.
incremental: When true, this form control will generate xforms-value-changing events. The default for this form control is false.

Example:

Example: Uploading An Image

<upload ref="mail/attach1" mediatype="image/*">
  <label>Select image:</label>
</upload>

A graphical browser might render this form control as follows:

A drop-down box; main display reads 'Select Image:' with a cute icon. The drop-down itself has three items: (icon)-From Scanner or Camera...; (icon)-Scribble...; Browse...

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

Implementation Requirements: For suitable mediatypes:

Implementations with a file system should support file upload—selecting a specific file. The types of files presented by default must reflect the mediatype specified in the XForms Model, for example defaulting to only audio file types in the file dialog when the mediatype is "audio/*". In XForms 1.0, there is a 1:1 binding between a upload form control and one of the binary datatypes, although that single file may be compound (e.g. application/zip).
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.

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.
end: Optional hint for the ending bound for the range—a legal value for the underlying data.
step: Optional hint to use for incrementing or decrementing the value. Should 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 xforms-value-changing events. The default for this form control is false.

Example:

Example: Picking From A Range

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

A graphical browser might render this as follows:

a slider control, from -2 to +2

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

Example:

Example: Picking a date from a range

<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

Example:

Example: Simple Trigger

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

Implementation Requirements: The user agent must provide a means to generate an xforms-activate event on the form control. Graphical implementations would typically 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

Special Attributes:

submission: Required reference to element submission.

Example:

Example: Submit

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

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

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:

incremental: When true, this form control will generate xforms-value-changing events. The default for this form control is true.

Example:

Example: Selecting Ice Cream Flavor

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

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

Note:

A limitation of the XML Schema list datatypes is that whitespace characters in the storage values (the value="..." attribute of the item element) are always interpreted as separators between individual data values. Therefore, authors should avoid using whitespace characters within storage values with list simpleContent.

Example: Incorrect Type Declaration

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

When selected, this item would introduce not one but four additional selection values: "America", "of", "States", and "United".

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.
incremental: When true, this form control will generate xforms-value-changing events. The default for this form control is true.

Example:

Example: Pick A Flavor

<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 data instance 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 8.2.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 attribute ref 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 first item is initially selected.

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 Common Markup for Selection Controls

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

This element provides repeat-like functionality for lists, and is defined at 9.3.3 The itemset Element.

8.2.4 The value Element

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

Common Attributes: Common, Single Node Binding

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

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

8.3 Additional Elements

The child elements detailed below provide the ability to attach metadata to form controls.

Instead of supplying such metadata e.g., the label for a form control as inline content of the contained element label, the metadata can be pointed to by using a simple linking attribute href on these elements. Notice that systematic use of this feature can be exploited in internationalizing XForms user interfaces by:

Factoring all human readable messages to a separate resource XML file.
Using URIs into this XML resource bundle within individual label elements
Finally, an XForms implementation could use content negotiation to obtain the appropriate XML resource bundle, e.g., based on the accept-language headers from the client, to serve up the user interface with messages localized to the client's locale.

8.3.1 The filename Element

This optional element provides a way for the upload form control to insert a filename, when available, that represents the chosen binary resource.

Common Attributes: Common, Single Node Binding

This specification does not define the format of a filename.

Example:

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

In this example, the user is prompted to select an image of some sort. The binary data of the image is placed under the element node selected by "mail/attachment". The filename, perhaps " /home/mdubinko/data/pictures/me.jpg", is placed under the element node selected by "mail/filename", and the mediatype, perhaps "image/jpeg" is placed under the attribute node at "mail/attachment/@type".

8.3.2 The mediatype Element

This optional element provides a way for the upload form control to insert a mediatype, when available, that represents the chosen binary resource.

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

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 would typically 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. This is equivalent to a xforms:help event handler that responds with a <message type="modeless">.

Common Attributes: Common, Single Node Binding

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. This is equivalent to a xforms:hint event handler that responds with a <message type="ephemeral">.

Common Attributes: Common, Single Node Binding

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

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.

Common Attributes: Common, Single Node Binding

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

9 XForms User Interface

This chapter covers XForms features for combining form controls into user interfaces.

9.1 The XForms Group Module

All form controls defined in 8 Form Controls are treated as individual units for purposes of visual layout e.g., in XHTML processing. Aggregation of form controls with markup defined in this chapter provides semantics about the relationship among user interface controls; such knowledge can be useful in delivering a coherent UI to small devices. For example, if the user interface needs to be split up over several screens, controls appearing inside the same aggregation would typically be rendered on the same screen or page. The elements and attributes included in this module are:

Element	Attributes	Minimal Content Model
group	Common, Single Node Binding	label?, ((Form Controls)\|group\|switch\|repeat)*

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.

Common Attributes: Common, Single Node Binding

Note:

The binding expression is solely for the purpose of authoring convenience; it allows controls appearing within element group to use relative XPath expressions. Model item properties such as relevant on the bound instance node have no special effect on the group.

Issue (group-appearance):

The Working Group requests implementation feedback on whether an appearance attribute is necessary on group, to serve a similar purpose as fieldset in HTML.

Resolution:

None recorded.

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

Example:

Example: Grouping Related Controls

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

The hierarchy defined by nested group elements is used to determine the traversal order specified by attribute navindex on form controls. 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 The XForms Switch Module

This section defines a switch construct that allows the creation of user interfaces where the user interface can be varied based on user actions and events. The elements and attributes included in this module are:

Element	Attributes	Minimal Content Model
switch	Common	case+
case	Common, selected (xsd:boolean)	label?, ((Form Controls)\|group\|switch\|repeat)*
toggle	Common, case (xsd:IDREF)	EMPTY

9.2.1 The switch Element

This element contains one or more case elements, any one of which is rendered at a given time.

Note:

This is separate from XForms relevant processing (see 6.1.4 The relevant Property), which is based on the current state of the XForms Model. As an example, portions of a questionnaire pertaining to the user's automobile may become relevant only if the user has answered in the affirmative to the question 'Do you own a car?'.

Common Attributes: Common

Example:

Example: switch

<switch>
  <case id="in" selected="true">
    <input ref="yourname">
      <label>Please tell me your name</label>
      <toggle ev:event="xforms-activate" case="out"/>
    </input>
  </case>
  <case id="out" selected="false">
    <html:p>Hello <output ref="yourname" />.
      <trigger id="editButton">
        <label>Edit</label>>
        <toggle ev:event="xforms-activate" 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 original case.

9.2.2 The case Element

This element encloses markup to be conditionally rendered. The attribute selected determines the selected state and can be manipulated programmatically via the DOM, or declaratively via XForms action toggle.

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 adjusts all selected attributes on the affected cases to reflect the new state, and then performs the following:

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

Common Attributes: Common, Events

Special Attributes:

case: Required reference to a case section inside the conditional construct.

9.3 The XForms Repeat Module

The XForms Specification allows the definition of repeating structures such as multiple items within a purchase order. When defining the XForms Model, such higher-level collections are constructed out of basic building blocks; similarly, this section defines user interface construct repeat that can bind to data structures such as lists and collections. The elements and attributes included in this module are:

Element	Attributes	Minimal Content Model
repeat	Common, Node Set Binding, startindex (xsd:positiveInteger), number (xsd:nonNegativeInteger)	((Form Controls)\|group\|repeat)*
itemset	Common, Node Set Binding	label, (value\|copy), (UI Common)*
copy	Common, Single Node Binding	EMPTY
insert	Common, Node Set Binding, at (xsd:string), position ("before"\|"after")	EMPTY
delete	Common, Node Set Binding, at (xsd:string)	EMPTY
setindex	Common, repeat (xsd:IDREF), index (xsd:string)	EMPTY
(various)	[repeat-nodeset, repeat-bind, repeat-model, repeat-startindex] (Node Set Binding attributes), repeat-startindex (xsd:positiveInteger), repeat-number (xsd:nonNegativeInteger)	N/A

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:

Example: Shopping Cart

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

Common Attributes: Common, Node Set Binding

Special Attributes:

startindex: Optional 1-based hint to the XForms Processor as to which starting element from the collection to display. The default value is 1.
number: Optional hint to the XForms Processor as to how many elements from the collection to display. In the absence of this attribute, all elements of the collection are displayed.

This element operates over a homogeneous collection by binding the encapsulated user interface controls to each element of the collection. 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):

Example: Repeat Unrolled

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

Notice that the element node for the collection being populated would typically have defined model item properties minOccurs and maxOccurs; these values may in turn determine if the user agent displays appropriate UI controls for the user to add or delete entries in the collection.

Example: Homogeneous Collection

<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="xforms-activate">
    <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="activate" 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.

Example: Tables And Repeating Structures

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

Example: Tables And Repeating Structures

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

Which could be validated against an appropriately configured XHTML Schema that includes the XForms Repeat module. Note that what gets repeated is the child elements of the element with the repeat- attributes.

This should be thought purely as a syntactic transformation, i.e., there is no change to repeat processing semantics. Further, for purposes of understanding the above as a pure syntactic transformation, element repeat can be viewed as containing an anonymous group that wraps the contents of element repeat. Thus, consider the following:

<repeat ...>
...
</repeat>

is equivalent to

<repeat ...>
  <group>...</group>
</repeat>

Which is equivalent to

<group repeat-...>
  ...
</group>

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 attribute nodeset. As with repeat, this nodeset should refer to a homogeneous collection. Child elements label and value indirectly specify the label and storage values. Notice that the run-time effect of itemset is the same as using element choices to statically author the available choices.

Common Attributes: Common, Node Set Binding

Note:

Whenever a refresh event is dispatched the nodeset is re-evaluated to update the list of available choices.

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

Example: Dynamic Choice Of Ice Cream Flavors

<model id="cone">
  <instance>
    <my:icecream>
      <my:flavors/>
    </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:flavors">
  <label>Flavors</label>
  <itemset model="flavors" nodeset="/my:flavors/my:flavor">
    <label ref="my:description"/>
    <copy ref="my:description"/>
  </itemset>
</select>

<!-- this example produces instance data similar to
<my:icecream>
  <my:flavors>
    <my:description>Vanilla</my:description>
    <my:description>Strawberry</my:description>
    <my:description>Chocolate</my:description>    
  </my:flavors>
</my:icecream>
-->

9.3.4 The copy Element

Structurally, this element is similar to 8.2.4 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

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 node selected by the binding attributes on copy is deep copied as a child of the target node.
A full computational dependency rebuild.

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 node 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 position within that collection where the new node will appear. The new node is created by cloning the final member of the homogeneous collection specified by the initialization instance data. In this process, nodes of type xsd:ID are not copied.

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:

The homogeneous collection to be updated is determined by evaluating binding attribute nodeset.
The corresponding node-set of the initial instance data is located to determine the prototypical member of the collection. 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 position 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. 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.
Finally, the cursor 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.

This action results in the insertion of newly created data nodes into the XForms data instance. 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.

Note:

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

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

The rules for delete processing are as follows:

The homogeneous collection to be updated is determined by evaluating binding attribute nodeset. If the collection is empty, the delete action has no effect.
The n-th 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.
If the last remaining item in the collection is removed, the cursor position becomes 0. Otherwise, the cursor will point to the new n-th item.

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

Note:

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

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 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.4 The xforms-ui-initialize Event), the following steps are performed for repeat:

Attribute nodeset is evaluated to locate the homogeneous collection to be operated on by this repeat.
The corresponding nodes in element instance in the source document are located—these nodes provide initial values and also serve as a prototypical instance for constructing members of the repeating collection.
The index for this repeating structure is initialized to point at the head of the collection.
The user interface template specified within element repeat is bound to this prototypical instance. If there is a type mismatch between the prototypical instance and the binding restrictions for the user interface controls, an error is signaled and processing stops.
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, and model item constraints minOccurs and maxOccurs.

The processing model for repeating structures uses a index that points to the current item in the data instance. This repeat index is accessed via XForms functions index 7.7.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 initial instance data supplies the prototypical member of the homogeneous collection, and this is used during UI initialization—4.2.4 The xforms-ui-initialize Event—to construct the members of the homogeneous collection. This prototypical instance is also used by action insert when creating new members of the collection. To create homogeneous collections, the initial instance data must specify at least one member of the collection; this requirement is similar to requiring instance data in addition to a schema, and the same justification applies.

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. Notice that an inner repeat's index always starts from 1. Consider the following insert statement that appears as part of that example.

Example: Repeat Index and Nested Repeats

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

10 XForms Actions

This chapter defines an XML Events-based [XML Events] common set of actions that can be invoked in response to events.

Note:

XForms itself defines no method for script-based event handling. The definition of such facilities is a responsibility of the hosting language.

10.1 The XForms Action Module

All form controls defined in this specification have a set of common behaviors that encourage consistent authoring and look and feel for XForms-based applications. This consistency comes from attaching a common set of behaviors to the various form controls. In conjunction with the event binding mechanism provided by XML Events, these handlers provide a flexible means for forms authors to specify event processing at appropriate points within the XForms user interface. XForms actions are declarative XML event handlers that capture high-level semantics. As a consequence, they significantly enhance the accessibility of XForms-based applications in comparison to previous Web technologies that relied exclusively on scripting.

The elements and attributes included in this module are:

Element	Attributes	Minimal Content Model
action	Common, Events	(Action)+
dispatch	Common, Events, name (xsd:NMTOKEN), target (xsd:IDREF), bubbles (xsd:boolean), cancelable (xsd:boolean)	EMPTY
rebuild	Common, Events, model (xsd:IDREF)	EMPTY
recalculate	Common, Events, model (xsd:IDREF)	EMPTY
revalidate	Common, Events, model (xsd:IDREF)	EMPTY
refresh	Common, Events, model (xsd:IDREF)	EMPTY
setfocus	Common, Events, control (xsd:IDREF)	EMPTY
load	Common, Events, Single Node Binding, Linking, show ("new" \| "replace" \| "embed" \| "other" \| "none")	EMPTY
setvalue	Common, Events, Single Node Binding, value (xsd:string)	PCDATA
send	Common, Events, submission (xsd:IDREF)	EMPTY
reset	Common, Events, model (xsd:IDREF)	EMPTY
message	Common, Events, Single Node Binding, Linking, level ("ephemeral" \| "modeless" \| "modal")	(PCDATA\|ANY)*

This module also defines the content set "Action", which includes the following elements (of these, toggle comes from the XForms Switch module, and insert, delete, and setindex come from the XForms Repeat module):

(action|dispatch|rebuild|refresh|recalculate|revalidate|setfocus
load|setvalue|send|reset|toggle|insert|delete|setindex)*

Additionally, this module defines the attribute group "XML Events", which includes all of the "global" attributes defined in that specification ([XML Events]).

The following example shows how events can be used:

Example: Action Syntax

<xforms:trigger>
  <xforms:label>Reset</xforms:label>
  <xforms:reset ev:event="xforms-activate" model="thismodel"/>
</xforms:trigger>

This example recreates the behavior of the HTML reset control, which this specification does not define as an independent form control.

For each built-in XForms action, this chapter lists the following:

Name
Common Attributes
Special Attributes
Description of behavior

All elements defined in this chapter explicitly allow global attributes from the XML Events namespace, and apply the processing defined in that specification in section 2.3 [XML Events].

10.1.1 The action Element

Action action is used to group multiple actions.

When using element action to group actions, care should be taken to list the event on element action, rather than on the contained actions.

Common Attributes: Common, Events

Example: Grouping Actions

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

Notice that in the above example, ev:event="xforms-activate" occurs on element action. Placing ev:event="xforms-activate" on either or both of the contained actions will have no effect. This is because the above example relies on the defaulting of [XML Events] attributes observer and handler. As defined in the XML Events specification, if both observer and handler attributes are omitted, then the parent is the observer. Placing ev:event="xforms-activate" on the children of element action therefore causes element action to become the observer for the individual actions. Consequently, these actions will never be triggered since events arrive at element trigger, not element action.

Deferred Updates: Many XForms Actions have a deferred effect on the instance data when specified as a descendant of an action element.

Implementations are free to use any strategy to accomplish deferred updates, but the end result must be as follows: Instance data changes performed by a set of actions do not result in immediate computation dependency rebuilding, recalculation, revalidate and form control refreshing until the termination of the outermost action handler, as described here. Each outermost action handler can be thought of as having a set of Boolean flags, initially false, to indicate whether each of the actions rebuild, recalculate, revalidate, and refresh are required upon termination of the outer action handler.

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

rebuild
recalculate
revalidate
refresh

XForms Actions that change the tree structure of instance data result in setting all four flags to true. The XForms Actions in this category are:

insert
delete

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

setvalue

Finally, the reset action takes effect immediately and clears all of the flags.

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:

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.
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.
cancelable: Optional boolean indicating if this event is cancelable—as defined in DOM2 events.

10.1.3 The rebuild Element

This action dispatches an xforms-rebuild event to a specific XForms Model. 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

Note:

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

10.1.4 The recalculate Element

This action dispatches an xforms-recalculate event to a specific XForms Model. 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

Note:

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

10.1.5 The revalidate Element

This action dispatches an xforms-revalidate event to a specific XForms Model. 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

Note:

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

10.1.6 The refresh Element

This action dispatches an xforms-refresh event to a specific XForms Model. 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

Note:

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

10.1.7 The setfocus Element

This action sets focus to the form control referenced by the idref attribute by dispatching an xforms-focus event (4.3.2 The xforms-focus Event). 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

Special Attributes:

Linking Attributes: Link to external resource to load. If the link traversal fails, it is treated as an error (4.5.3 The xforms-link-error Event).
show: Optional link behavior specifier.

Either the single node binding attributes, pointing to a URI in the instance data, or the linking attributes are required. If both are present, the action has no effect.

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 window (or other presentation context). Form processing in the original 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.

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

Example: setvalue with Expression

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

This causes the string value at a/b/c in the instance data to be placed on the single node selected by the bind element with id="put-here".

Example: setvalue with Literal

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

This causes the value "literal string" to be placed on the single node selected by the bind element with id="put-here".

If neither a value attribute nor text content are present, the effect is to set the value of the selected node to the empty string (""). If both are present, the value attribute is used.

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.

Note:

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

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.

Note:

This XForms Action is a convenient way of expressing the following:

<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: Required selection of instance data for reset, defined in 3.2.3 Single-Node Binding Attributes.

Note:

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

10.1.12 The message Element

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

Common Attributes: Common, Events, Single Node Binding

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.

A graphical browser might render a modal message as follows:

<model>
  <message ev:event="xforms-model-initialize">This is not a drill!</message>
  ...
</model>

An alert popup, with a helpful error message.

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

<secret ref="users/currentuser/password">
  <label>Please enter your password --it will not be visible as you type.</label>
  <help>Have you forgotten your password? Simply call 1-900-555-1212 and have
    a major credit card handy.</help>
</secret>

A password entry form control, with a popup window below, displaying instructions for retrieving a forgotten password

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>

An average-looking text entry form control, with a mouse pointer visible and a tooltip below, reading 'Please enter the number and street name'

11 Submit

XForms is designed to gather instance data, serialize it into an external representation, and submit it with a protocol. XForms defines a set of options for serialization and submission. The following sections define the processing of instance data for submission, and the behavior for the serialization and submission options.

Issue (multipart-submit-options):

The Working Group is soliciting implementation and deployment experience to determine to what degree form submission as multipart/form-data should be backward compatible with deployed RFC 2388 servers and whether a separate method based on multipart/related should be provided.

Resolution:

None recorded.

11.1 The xforms-submit Event

Submission begins with the default processing for a xforms-submit event.

Target: submission

Bubbles: Yes

Cancelable: Yes

Context Info: None

Under no circumstances may more than a single concurrent submit process be under way for a particular XForms Model. From the start of the default processing of xforms-submit, until the completion of default processing for xforms-submit-done or xforms-submit-error, the default processing for event xforms-submit is to terminate immediately.

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

A node from the instance data is selected, based on the attribute ref on element submission. This node and all relevant child nodes are considered for the remainder of the submit process.
All selected instance data is revalidated, according to the rules at 4.3.5 The xforms-revalidate Event. Any invalid instance data stops submit processing after dispatching event xforms-submit-error.
Selected instance data is serialized according to the rules stated at 11.2 Submission Options.
Serialized instance data is submitted using the protocol indicated by the rules stated at 11.2 Submission Options.
The response returned from the submission is applied as follows:
- For a success response including a body, when the value of the replace attribute on element submission is "all", the entire containing document is replaced with the returned body, and submit processing concludes after dispatching xforms-submit-done.
- For a success response including a body of an XML media type, when the value of the replace attribute on element submission is "instance", the response is parsed as XML and the internal instance data is replaced with the result, using the same processing as remote instance data retrieved through src, and the xforms-initialize event is dispatched to element model. Submit processing then concludes after dispatching xforms-submit-done.
- For a success response including a body of a non-XML media type, when the value of the replace attribute on element submission is "instance", nothing in the document is replaced and submit processing concludes after dispatching xforms-submit-error.
- For a success response including a body, when the value of the replace attribute on element submission is "none", submit processing concludes after dispatching xforms-submit-done.
- For a success response not including a body, submit processing concludes after dispatching xforms-submit-done.
- Behaviors of other possible values for attribute replace are not defined in this specification.
- For an error response nothing in the document is replaced, and submit processing concludes after dispatching xforms-submit-error.

11.2 Submission Options

The XForms Model specifies a submission element containing the following attributes that affect serialization and submission. This section summarizes the behaviors for the allowable values of these attributes, and introduces the following sections that define the behavior for serialization and submission.

action (xsd:anyURI)
method (xsd:string, enumerated below)

For the URI scheme of action, XForms normatively defines a binding to HTTP/1.1 [RFC 2616].

Note:

Other bindings, in particular to the URI scheme "mailto:" may, and the schemes "https:" and "file:" should, be supported. Bindings to these schemes are not nomatively defined in XForms. Implementations that choose to provide a binding to these schemes should pay particular attention to privacy and security concerns. Within the "http:" and "https:" schemes, form creators are encouraged to follow the finding of the W3C Technical Architechture Group on when to use the GET method: [TAG Finding 7]

The method attribute determines the serialization format, and the URI scheme used in the action attribute determines the submit protocol, according to the following table:

URI scheme	`method`	Serialization	Submission
http https mailto	"post"	`application/xml`	HTTP POST or equivalent
http https	"get"	`application/x-www-form-urlencoded`	HTTP GET or equivalent
http https file	"put"	`application/xml`	HTTP PUT or equivalent
http https mailto	"form-data-post"	`multipart/form-data`	HTTP POST or equivalent
http https mailto	"urlencoded-post" (Deprecated)	`application/x-www-form-urlencoded`	HTTP POST or equivalent
(any)	any other QNAME with no prefix	N/A	N/A
(any)	any QNAME with a prefix	implementation-defined	implementation-defined

Note:

Foreign-namespaced attributes are allowed on element submission, but no behavior is defined by XForms 1.0.

11.3 Serialization as application/xml

This format permits the expression of the instance data as XML that is straightforward to process with off-the-shelf XML processing tools. In addition, this format is capable of submission of binary content.

The steps for serialization are as follows:

An XML document is produced following the rules of the XML output method defined in [XSLT 1.0] section 16 and 16.1, using the values supplied as attributes of the submission element.

Note that the 8.1.6 The upload Element upload element can bind to instance data nodes with the datatypes xsd:base64Binary, xsd:hexBinary, or xsd:anyURI (or datatypes derived from these). Such nodes are included in the serialized data according to the rules defined in [XML Schema part 2].

11.4 Serialization as multipart/form-data

This format is intended to facilitate the integration of XForms into environments that involve large amounts of binary data, and represents an extension of the [XHTML 1.0] form content type multipart/form-data. This format is especially suitable for the persistence of binary content.

This format follows the rules of all multipart MIME data streams for form data as outlined in [RFC 2388], as follows:

The first part is XML, serialized by the rules at 11.3 Serialization as application/xml, with the contents of any nodes of datatypes xsd:base64binary or xsd:hexBinary (or any datatype derived from those) replaced with an implementation-defined URI.
- A Content-Disposition header of "form-data", with a name parameter of "instanceData"
- A Content-Type header of "application/xml", with an optional charset parameter
One subsequent part for each node associated with a datatype of xsd:base64Binary or xsd:hexBinary (or derived datatype) with:
- A Content-Disposition header of "form-data", with an implementation-defined name parameter and a filename parameter storing the local file name, if available
- A Content-Type header that represents the media type of the attachment if known, otherwise application/octet-stream
- A Content-Transfer-Encoding header of "binary"
- A Content-ID header with an implementation-defined value matching the URI in the associated instance data node.

Example:

Example: multipart/form-data

MIME-Version: 1.0
Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition: form-data; name="instanceData"
Content-Type: application/xml; charset=UTF-8

<?xml version="1.0?>
<root>
  <text>text</text>
  <binary>cid:attachment1@example.com</binary>
</root>

--AaB03x
  Content-Disposition: form-data; name="attachment1"; filename=image.png
  Content-Type: image/png
  Content-Transfer-Encoding: binary
  Content-ID: <attachment1@example.com>

...Binary data here...
--AaB03x-

11.5 Serialization as application/x-www-form-urlencoded

This serialization format is designed to allow the use of a form to gather the data necessary to produce a URI that names a resource and for accessing that resource with an HTTP GET operation.

This format represents an extension of the [XHTML 1.0] form content type application/x-www-form-urlencoded with specific rules for encoding non-ASCII and reserved characters.

This format is not suitable for the persistence of binary content. Therefore, it is recommended that forms capable of containing binary content use another serialization method.

The steps for serialization are as follows:

Each element node is visited in document order. Each element that has one text node child is selected for inclusion. Note that attribute information is not preserved.
Element nodes selected for inclusion are encoded as EltName=value{sep}, where = is a literal character,{sep} is the separator character from the separator attribute on submission, EltName represents the element local name, and value represents the contents of the text node. Note that contextual path information is not preserved, nor are namespaces or namespace prefixes. As a result, different elements might serialize to the same name.
- The encoding of EltName and value are as follows: space characters are replaced by +, and then non-ASCII and reserved characters (as defined by [RFC 2396] as amended by subsequent documents in the IETF track) are escaped by replacing the character with one or more octets of the UTF-8 representation of the character, with each octet in turn replaced by %HH, where HH represents the hexadecimal notation for the octet value and % is a literal character. Line breaks are represented as "CR LF" pairs (i.e., %0D%0A).
All such encodings are concatenated, maintaining document order.

Example:

Example: application/x-www-form-urlencoded

GivenName=Ren%c3%a9;

This format consists of simple name-value pairs.

<PersonName title="Mr">
  <GivenName>René</GivenName>
</PersonName>

Here is the instance data for the above example. Note that very little of the data is preserved. Authors desiring greater data integrity should select a different serialization format.

11.6 The post, form-data-post, and urlencoded-post Submit Methods

These submit methods represent HTTP POST or the equivalent concept (such as a mail message). The serialized form data is delivered as the message body.

11.7 The put Submit Method

This submit method represents HTTP PUT or the equivalent concept (such as writing to a local file). The serialized form data is delivered as the message body.

11.8 The get Submit Method

This submit method represents HTTP GET or the equivalent concept. The serialized form data is delivered as part of the URI that is requested during the submit process.

This method is not suitable for submission of forms that are intended to change state or cause other actions to take place at the server. See [RFC 2616] for recommended uses of HTTP GET.

The URI is constructed as follows:

The submit URI from the action attribute is examined. If it does not already contain a ? (question mark) character, one is appended. If it does already contain a question mark character, then a separator character from the attribute separator is appended.
The serialized form data is appended to the URI.

No message body is sent with the request.

12 Conformance

12.1 Conformance Levels

The XForms specification is designed for implementation on hardware platforms of all sizes, from tiny hand-held devices to high-powered servers. For this reason, there are two conformance levels for XForms Processors, documents, and generators (such as authoring tools): XForms Full and XForms Basic.

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 server. XForms Full implementations must return "full" from the property method (defined at 7.8.1 The property() Function ) called with the "conformance-level" parameter string.

12.1.2 XForms Basic

This conformance level is suitable for devices with limited computing power, such as mobile phones, hand-held computers, and appliances. This conformance level uses a subset of XML Schema and does not include any resource-intensive features. XForms Basic implementations must return "basic" from the property method (defined at 7.8.1 The property() Function ) called with the "conformance-level" parameter string.

12.2 Conformance Description

12.2.1 Conforming XForms Processors

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

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.

XForms Basic Processors must implement all required features defined in this specification, with the following exceptions:

XForms Basic Processors have undefined processing for XML Schema structures, other than the processing of the attribute xsi:type on instance data for simpleTypes only
XForms Basic Processors support only the XML Schema datatypes identified as Basic in 5 Datatypes; processing of all other XML Schema built-in datatypes is undefined
XForms Basic Processors may trigger an exception (4.5.1 The xforms-binding-exception Event) upon the use of any dynamic dependency in a UI binding expression.
XForms Basic Processors have undefined processing for the following XPath axes: following, following-sibling, preceding, preceding-sibling
XForms Basic Processors need not support IEEE floating point (as defined by the XPath datatype number), but must provide the same results in all mathematical operations to 14 decimal places of accuracy
XForms Basic Processors may define an implementation-defined limit to the size of a node-set processed in XPath expressions
XForms Basic Processors have undefined behavior for the | (node-set union) operator in XPath
XForms Basic Processors need not implement the dispatch XForms Action
XForms Basic Processors may use only XML Events Basic ([XML Events])

Issue (xpath-predicate-conformance):

The Working Group reqests feedback on whether the 'no dynamic predicates' restriction sufficiently restricts XPath to make implementation feasable on limited devices.

Resolution:

None recorded.

12.2.2 Conforming XForms Documents

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

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.

All XForms Basic conforming documents must conform to all required portions of this specification, with the following restrictions:

XForms Basic documents must not use any processing from XML Schema structures (other than xsi:type used with simpleTypes)
XForms Basic documents must not use any XML Schema datatypes not identified as Basic in 5 Datatypes (This restriction also applies to datatypes derived from unsupported datatypes)
XForms Basic documents must not use any dynamic dependency in UI binding expressions.
XForms Basic documents must not use any of the following XPath axes: following, following-sibling, preceding, preceding-sibling
XForms Basic documents must not use the | (node-set union) operator in XPath
XForms Basic documents must not use the dispatch XForms Action
XForms Basic documents must conform to XML Events Basic ([XML Events])

12.2.3 Conforming XForms Generators

XForms Full generators must generate conforming XForms Basic and XForms Full documents, depending on the author's choice.

XForms Basic generators must generate only conforming XForms Basic documents.

13 Glossary Of Terms

Binding: [Definition: A "binding" connects an instance data node to a form control or to a model item constraint by using a binding expression as a locator. ]
Binding expression: [Definition: An XPath LocationPath expression used in a binding. ]
Model Binding expression: [Definition: An XPath LocationPath expression used in a binding that declares a model item property. ]
UI or Action Binding expression: [Definition: An XPath LocationPath expression used in binding a form control to the instance, or to specify the a node or node set for operation by an action. ]
Computed expression: [Definition: An XPath expression used by model item properties such as relevant and calculate to include dynamic functionality in XForms.]
Containing document: [Definition: A specific document, for example an XHTML document, in which one or more <model> elements are found.]
Datatype: [Definition: From XML Schema [XML Schema part 2]: A 3-tuple, consisting of a) a set of distinct values, called its value space, b) a set of lexical representations, called its lexical space, and c) a set of facets that characterize properties of the value space, individual values or lexical items.]
Facet: [Definition: From XML Schema [XML Schema part 2]: A single defining aspect of a value space. Generally speaking, each facet characterizes a value space along independent axes or dimensions.]
First node rule: [Definition: When a UI Single-Node Binding attribute selects a node-set of size > 1, the first node in the node-set is used.]
Form control: [Definition: An XForms user interface control that serves as a point of user interaction.]
Host language: [Definition: An XML vocabulary, such as XHTML, into which XForms is embedded.]
Instance data: [Definition: An internal tree representation of the values and state of all the instance data nodes associated with a particular form.]
Instance data node: [Definition: An XPath node from the instance data.]
Lexical space: [Definition: From XML Schema [XML Schema part 2]: A lexical space is the set of valid literals for a datatype.]
Model item: [Definition: An instance data node with associated constraints. ]
Model item property: [Definition: An XForms-specific annotation to an instance data node.]
Schema constraint: [Definition: A restriction, applied to form data, based on XML Schema datatypes. ]
Value space: [Definition: From XML Schema [XML Schema part 2]: A set of values for a given datatype. Each value in the value space of a datatype is denoted by one or more literals in its lexical space.]
XForms Model: [Definition: The non-visible definition of an XML form as specified by XForms. The XForms Model defines the individual model items and constraints and other run-time aspects of XForms.]
XForms Processor: [Definition: A software application or program that implements and conforms to the XForms specification.]

A Schema for XForms

<xsd:schema xmlns:xforms="http://www.w3.org/2002/08/xforms/cr" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ev="http://www.w3.org/2001/xml-events" targetNamespace="http://www.w3.org/2002/08/xforms/cr" elementFormDefault="qualified">
   
   
   <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd">
     <xsd:annotation>
       <xsd:documentation>Get access to xml:lang and friends</xsd:documentation>
     </xsd:annotation>
   </xsd:import>
   <xsd:import namespace="http://www.w3.org/2001/xml-events" schemaLocation="XML-Events-Schema.xsd" />
   <xsd:import namespace="http://www.w3.org/2001/XMLSchema" schemaLocation="http://www.w3.org/2001/XMLSchema.xsd" />
   
   <xsd:attributeGroup name="commonAttrs">
     <xsd:annotation>
       <xsd:documentation>Attributes for _every_ element in XForms</xsd:documentation>
     </xsd:annotation>
     <xsd:anyAttribute namespace="##other" />
   </xsd:attributeGroup>
   <xsd:element name="model">
     <xsd:complexType>
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:choice>
           <xsd:element ref="xforms:instance" />
           <xsd:element ref="xsd:schema" />
           <xsd:element ref="xforms:submission" />
           <xsd:element ref="xforms:bind" />
           <xsd:group ref="xforms:actionGroup" />
           <xsd:element ref="xforms:extension" />
         </xsd:choice>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="functions" type="xforms:QNameList" use="optional" />
       <xsd:attribute name="schema" type="xforms:anyURIList" use="optional" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="instance">
     <xsd:annotation>
       <xsd:documentation>instance container.</xsd:documentation>
     </xsd:annotation>
     <xsd:complexType>
       <xsd:sequence>
         <xsd:any namespace="##any" processContents="skip" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:linkingAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="submission">
     <xsd:annotation>
       <xsd:documentation>submit info container.</xsd:documentation>
     </xsd:annotation>
     <xsd:complexType>
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:group ref="xforms:actionGroup" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="action" type="xsd:anyURI" use="optional" />
       <xsd:attribute name="method" use="required">
         <xsd:simpleType>
           <xsd:union memberTypes="xforms:QNameButNotNCNAME">
             <xsd:simpleType>
               <xsd:restriction base="xsd:string">
                 <xsd:enumeration value="post" />
                 <xsd:enumeration value="put" />
                 <xsd:enumeration value="get" />
                 <xsd:enumeration value="form-data-post" />
                 <xsd:enumeration value="urlencoded-post" />
               </xsd:restriction>
             </xsd:simpleType>
           </xsd:union>
         </xsd:simpleType>
       </xsd:attribute>
       <xsd:attribute name="version" type="xsd:NMTOKEN" use="optional" />
       <xsd:attribute name="indent" type="xsd:boolean" use="optional" />
       <xsd:attribute name="encoding" type="xsd:string" use="optional" />
       <xsd:attribute name="mediatype" type="xsd:string" use="optional" />
       <xsd:attribute name="omit-xml-declaration" type="xsd:boolean" use="optional" />
       <xsd:attribute name="standalone" type="xsd:boolean" use="optional" />
       <xsd:attribute name="cdata-section-elements" type="xforms:QNameList" use="optional" />
       <xsd:attribute name="replace" use="optional" default="all">
         <xsd:simpleType>
           <xsd:union memberTypes="xforms:QNameButNotNCNAME">
             <xsd:simpleType>
               <xsd:restriction base="xsd:string">
                 <xsd:enumeration value="all" />
                 <xsd:enumeration value="instance" />
                 <xsd:enumeration value="none" />
               </xsd:restriction>
             </xsd:simpleType>
           </xsd:union>
         </xsd:simpleType>
       </xsd:attribute>
       <xsd:attribute name="separator" use="optional" default=";">
         <xsd:simpleType>
           <xsd:restriction base="xsd:string">
             <xsd:enumeration value=";" />
             <xsd:enumeration value="&" />
           </xsd:restriction>
         </xsd:simpleType>
       </xsd:attribute>
     </xsd:complexType>
   </xsd:element>
   <xsd:attributeGroup name="linkingAttributes">
     <xsd:attribute name="src" type="xsd:anyURI" />
   </xsd:attributeGroup>
   <xsd:element name="bind">
     <xsd:annotation>
       <xsd:documentation>Definition of bind container.</xsd:documentation>
     </xsd:annotation>
     <xsd:complexType>
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:element ref="xforms:bind" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="nodeset" type="xsd:string" use="optional" />
       <xsd:attribute name="type" type="xsd:QName" use="optional" />
       <xsd:attribute name="readonly" type="xsd:string" use="optional" />
       <xsd:attribute name="required" type="xsd:string" use="optional" />
       <xsd:attribute name="relevant" type="xsd:string" use="optional" />
       <xsd:attribute name="constraint" type="xsd:string" use="optional" />
       <xsd:attribute name="calculate" type="xsd:string" use="optional" />
       <xsd:attribute name="maxOccurs" use="optional">
         <xsd:simpleType>
           <xsd:union memberTypes="xsd:nonNegativeInteger">
             <xsd:simpleType>
               <xsd:restriction base="xsd:string">
                 <xsd:enumeration value="unbounded" />
               </xsd:restriction>
             </xsd:simpleType>
           </xsd:union>
         </xsd:simpleType>
       </xsd:attribute>
       <xsd:attribute name="minOccurs" type="xsd:nonNegativeInteger" use="optional" />
       <xsd:attribute name="p3ptype" type="xsd:string" use="optional" />
     </xsd:complexType>
   </xsd:element>
   
   <xsd:group name="formControls">
     <xsd:choice>
       <xsd:element ref="xforms:input" />
       <xsd:element ref="xforms:textarea" />
       <xsd:element ref="xforms:secret" />
       <xsd:element ref="xforms:output" />
       <xsd:element ref="xforms:upload" />
       <xsd:element ref="xforms:select1" />
       <xsd:element ref="xforms:select" />
       <xsd:element ref="xforms:range" />
       <xsd:element ref="xforms:submit" />
       <xsd:element ref="xforms:trigger" />
     </xsd:choice>
   </xsd:group>
   <xsd:attributeGroup name="bindFirstAttributes">
     <xsd:attribute name="model" type="xsd:IDREF" use="optional" />
     <xsd:attribute name="ref" type="xsd:string" use="optional" />
     <xsd:attribute name="bind" type="xsd:IDREF" use="optional" />
   </xsd:attributeGroup>
   <xsd:attributeGroup name="bindAllAttributes">
     <xsd:attribute name="model" type="xsd:IDREF" use="optional" />
     <xsd:attribute name="nodeset" type="xsd:string" use="optional" />
     <xsd:attribute name="bind" type="xsd:IDREF" use="optional" />
   </xsd:attributeGroup>
   <xsd:attributeGroup name="commonUIAttributes">
     <xsd:attribute name="accesskey" type="xsd:string" use="optional" />
     <xsd:attribute name="navindex" type="xsd:nonNegativeInteger" use="optional" />
     <xsd:attribute name="appearance" type="xforms:appearanceType" use="optional" />
   </xsd:attributeGroup>
   <xsd:element name="label">
     <xsd:complexType mixed="true">
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:choice>
           <xsd:element ref="xforms:output" />
           
         </xsd:choice>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attributeGroup ref="xforms:linkingAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="hint">
     <xsd:complexType mixed="true">
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:choice>
           <xsd:element ref="xforms:output" />
           
         </xsd:choice>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attributeGroup ref="xforms:linkingAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="help">
     <xsd:complexType mixed="true">
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:choice>
           <xsd:element ref="xforms:output" />
           
         </xsd:choice>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attributeGroup ref="xforms:linkingAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="alert">
     <xsd:complexType mixed="true">
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:choice>
           <xsd:element ref="xforms:output" />
           
         </xsd:choice>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attributeGroup ref="xforms:linkingAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="extension">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:any namespace="##other" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="choices">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" minOccurs="0" />
         <xsd:sequence maxOccurs="unbounded">
           <xsd:choice>
             <xsd:element ref="xforms:choices" />
             <xsd:element ref="xforms:item" />
             <xsd:element ref="xforms:itemset" />
           </xsd:choice>
         </xsd:sequence>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="value">
     <xsd:complexType mixed="true">
       <xsd:sequence>
         <xsd:any namespace="##any" processContents="skip" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="item">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:element ref="xforms:value" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="itemset">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:choice>
           <xsd:element ref="xforms:value" />
           <xsd:element ref="xforms:copy" />
         </xsd:choice>
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindAllAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="copy">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="filename">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="mediatype">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:group name="optionalUIChildren">
     <xsd:sequence>
       <xsd:choice minOccurs="0" maxOccurs="unbounded">
         <xsd:element ref="xforms:help" />
         <xsd:element ref="xforms:hint" />
         <xsd:element ref="xforms:alert" />
         <xsd:group ref="xforms:actionGroup" />
         <xsd:element ref="xforms:extension" />
       </xsd:choice>
     </xsd:sequence>
   </xsd:group>
   <xsd:element name="input">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attribute name="inputmode" type="xsd:string" use="optional" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="incremental" type="xsd:boolean" use="optional" default="false" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="textarea">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attribute name="inputmode" type="xsd:string" use="optional" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="incremental" type="xsd:boolean" use="optional" default="false" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="secret">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attribute name="inputmode" type="xsd:string" use="optional" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="incremental" type="xsd:boolean" use="optional" default="false" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="upload">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:element ref="xforms:filename" minOccurs="0" />
         <xsd:element ref="xforms:mediatype" minOccurs="0" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="mediatype" type="xsd:string" use="optional" />
       <xsd:attribute name="incremental" type="xsd:boolean" use="optional" default="false" />
     </xsd:complexType>
   </xsd:element>
   <xsd:group name="listChoices">
     <xsd:sequence>
       <xsd:choice>
         <xsd:element ref="xforms:item" />
         <xsd:element ref="xforms:itemset" />
         <xsd:element ref="xforms:choices" />
       </xsd:choice>
     </xsd:sequence>
   </xsd:group>
   <xsd:element name="select1">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:listChoices" maxOccurs="unbounded" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="selection" use="optional" default="closed">
         <xsd:simpleType>
           <xsd:restriction base="xsd:string">
             <xsd:enumeration value="open" />
             <xsd:enumeration value="closed" />
           </xsd:restriction>
         </xsd:simpleType>
       </xsd:attribute>
       <xsd:attribute name="incremental" type="xsd:boolean" use="optional" default="true" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="select">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:listChoices" maxOccurs="unbounded" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="selection" use="optional" default="closed">
         <xsd:simpleType>
           <xsd:restriction base="xsd:string">
             <xsd:enumeration value="open" />
             <xsd:enumeration value="closed" />
           </xsd:restriction>
         </xsd:simpleType>
       </xsd:attribute>
       <xsd:attribute name="incremental" type="xsd:boolean" use="optional" default="true" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="range">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="start" type="xsd:string" use="optional" />
       <xsd:attribute name="end" type="xsd:string" use="optional" />
       <xsd:attribute name="step" type="xsd:string" use="optional" />
       <xsd:attribute name="incremental" type="xsd:boolean" use="optional" default="false" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="trigger">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="output">
     <xsd:complexType>
       <xsd:sequence minOccurs="0">
         <xsd:element ref="xforms:label" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="ref" type="xsd:string" use="optional" />
       <xsd:attribute name="model" type="xsd:string" use="optional" />
       <xsd:attribute name="format" type="xsd:string" use="optional" />
       <xsd:attribute name="appearance" type="xforms:appearanceType" use="optional" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="submit">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" />
         <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="submission" type="xsd:IDREF" use="required" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
     </xsd:complexType>
   </xsd:element>
   
   <xsd:attributeGroup name="XMLEvents">
     <xsd:attribute ref="ev:event" />
     <xsd:attribute ref="ev:observer" />
     <xsd:attribute ref="ev:target" />
     <xsd:attribute ref="ev:handler" />
     <xsd:attribute ref="ev:phase" />
     <xsd:attribute ref="ev:propagate" />
     <xsd:attribute ref="ev:defaultAction" />
   </xsd:attributeGroup>
   <xsd:group name="actionGroup">
     <xsd:choice>
       <xsd:element ref="xforms:action" />
       <xsd:group ref="xforms:actions" />
     </xsd:choice>
   </xsd:group>
   <xsd:element name="action">
     <xsd:complexType>
       <xsd:sequence maxOccurs="unbounded">
         <xsd:group ref="xforms:actions" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:group name="actions">
     <xsd:choice>
       <xsd:element ref="xforms:dispatch" />
       <xsd:element ref="xforms:rebuild" />
       <xsd:element ref="xforms:recalculate" />
       <xsd:element ref="xforms:revalidate" />
       <xsd:element ref="xforms:refresh" />
       <xsd:element ref="xforms:setfocus" />
       <xsd:element ref="xforms:load" />
       <xsd:element ref="xforms:setvalue" />
       <xsd:element ref="xforms:send" />
       <xsd:element ref="xforms:reset" />
       <xsd:element ref="xforms:insert" />
       <xsd:element ref="xforms:delete" />
       <xsd:element ref="xforms:setindex" />
       <xsd:element ref="xforms:toggle" />
       <xsd:element ref="xforms:message" />
     </xsd:choice>
   </xsd:group>
   <xsd:element name="dispatch">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="name" type="xsd:NMTOKEN" use="required" />
       <xsd:attribute name="target" type="xsd:IDREF" use="required" />
       <xsd:attribute name="bubbles" type="xsd:boolean" use="optional" default="true" />
       <xsd:attribute name="cancelable" type="xsd:boolean" use="optional" default="true" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="rebuild">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="model" type="xsd:IDREF" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="revalidate">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="model" type="xsd:IDREF" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="recalculate">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="model" type="xsd:IDREF" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="refresh">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="model" type="xsd:IDREF" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="setfocus">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="control" type="xsd:IDREF" use="required" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="load">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attribute name="src" type="xsd:anyURI" use="required" />
       <xsd:attribute name="show" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="setvalue">
     <xsd:complexType>
       <xsd:simpleContent>
         <xsd:extension base="xsd:string">
           <xsd:attributeGroup ref="xforms:commonAttrs" />
           <xsd:attribute name="id" type="xsd:ID" use="optional" />
           <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
           <xsd:attribute name="value" type="xsd:string" />
           <xsd:attributeGroup ref="xforms:XMLEvents" />
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="send">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="submission" type="xsd:IDREF" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="reset">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
       <xsd:attribute name="model" type="xsd:IDREF" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="insert">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindAllAttributes" />
       <xsd:attribute name="at" type="xsd:string" use="required" />
       <xsd:attribute name="position" use="required">
         <xsd:simpleType>
           <xsd:restriction base="xsd:string">
             <xsd:enumeration value="before" />
             <xsd:enumeration value="after" />
           </xsd:restriction>
         </xsd:simpleType>
       </xsd:attribute>
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="delete">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindAllAttributes" />
       <xsd:attribute name="at" type="xsd:string" use="required" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="setindex">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="repeat" type="xsd:IDREF" use="required" />
       <xsd:attribute name="index" type="xsd:string" use="required" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="toggle">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attribute name="case" type="xsd:IDREF" use="required" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="message">
     <xsd:complexType>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attribute name="level" type="xsd:string" use="required" />
       <xsd:attributeGroup ref="xforms:XMLEvents" />
     </xsd:complexType>
   </xsd:element>
   
   <xsd:attribute name="repeat-nodeset" type="xsd:string" />
   <xsd:attribute name="repeat-model" type="xsd:IDREF" />
   <xsd:attribute name="repeat-bind" type="xsd:IDREF" />
   <xsd:attribute name="repeat-startindex" type="xsd:positiveInteger" />
   <xsd:attribute name="repeat-number" type="xsd:nonNegativeInteger" />
   <xsd:element name="repeat">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:sequence minOccurs="0" maxOccurs="unbounded">
           <xsd:choice>
             <xsd:group ref="xforms:formControls" />
             <xsd:element ref="xforms:group" />
             <xsd:element ref="xforms:repeat" />
             
           </xsd:choice>
         </xsd:sequence>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindAllAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
       <xsd:attribute name="startindex" type="xsd:positiveInteger" />
       <xsd:attribute name="number" type="xsd:nonNegativeInteger" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="group">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" minOccurs="0" />
         <xsd:sequence minOccurs="0" maxOccurs="unbounded">
           <xsd:choice>
             <xsd:group ref="xforms:formControls" />
             <xsd:element ref="xforms:group" />
             <xsd:element ref="xforms:switch" />
             <xsd:element ref="xforms:repeat" />
             
           </xsd:choice>
         </xsd:sequence>
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="optional" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="switch">
     <xsd:complexType>
       <xsd:sequence maxOccurs="unbounded">
         <xsd:element ref="xforms:case" />
       </xsd:sequence>
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" />
       <xsd:attributeGroup ref="xforms:bindFirstAttributes" />
       <xsd:attributeGroup ref="xforms:commonUIAttributes" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="case">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element ref="xforms:label" minOccurs="0" />
         <xsd:sequence maxOccurs="unbounded">
           <xsd:choice>
             <xsd:group ref="xforms:formControls" />
             <xsd:element ref="xforms:group" />
             <xsd:element ref="xforms:switch" />
             <xsd:element ref="xforms:repeat" />
             
           </xsd:choice>
         </xsd:sequence>
       </xsd:sequence>
       <xsd:attribute name="selected" type="xsd:boolean" use="optional" />
       <xsd:attributeGroup ref="xforms:commonAttrs" />
       <xsd:attribute name="id" type="xsd:ID" use="required" />
     </xsd:complexType>
   </xsd:element>
   
   <xsd:simpleType name="QNameList">
     <xsd:list itemType="xsd:QName" />
   </xsd:simpleType>
   <xsd:simpleType name="anyURIList">
     <xsd:list itemType="xsd:anyURI" />
   </xsd:simpleType>
   <xsd:simpleType name="QNameButNotNCNAME">
     <xsd:restriction base="xsd:QName">
       <xsd:pattern value="[^:]+:[^:]+" />
     </xsd:restriction>
   </xsd:simpleType>
   <xsd:simpleType name="appearanceType">
     <xsd:union memberTypes="xforms:QNameButNotNCNAME">
       <xsd:simpleType>
         <xsd:restriction base="xsd:string">
           <xsd:enumeration value="full" />
           <xsd:enumeration value="compact" />
           <xsd:enumeration value="minimal" />
         </xsd:restriction>
       </xsd:simpleType>
     </xsd:union>
   </xsd:simpleType>
   <xsd:simpleType name="listItem">
     <xsd:restriction base="xsd:string">
       <xsd:pattern value="\S+" />
     </xsd:restriction>
   </xsd:simpleType>
   <xsd:simpleType name="listItems">
     <xsd:list itemType="xforms:listItem" />
   </xsd:simpleType>
   <xsd:simpleType name="dayTimeDuration">
     <xsd:restriction base="xsd:duration">
       <xsd:pattern value="[-]?P((\p{Nd}D(T\p{Nd}+(H(\p{Nd}+M(\p{Nd}+([.]\p{Nd}+)?S)?)?|M(\p{Nd}+([.]\p{Nd}+)?S)?|(([.]\p{Nd}+)?S)))?)|T\p{Nd}+(H(\p{Nd}+M(\p{Nd}+([.]\p{Nd}+)?S)?)?|M(\p{Nd}+([.]\p{Nd}+)?S)?|(([.]\p{Nd}+)?S)))" />
     </xsd:restriction>
   </xsd:simpleType>
   <xsd:simpleType name="yearMonthDuration">
     <xsd:restriction base="xsd:duration">
       <xsd:pattern value="[-]?P\p{Nd}+(Y(\p{Nd}+M)?|M)" />
     </xsd:restriction>
   </xsd:simpleType>
</xsd:schema>

A.1 Schema for XML Events

This schema is not normative with respect to XML Events, although it is considered a normative part of the XForms definition.

<xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ev="http://www.w3.org/2001/xml-events" targetNamespace="http://www.w3.org/2001/xml-events" elementFormDefault="unqualified" attributeFormDefault="unqualified" blockDefault="#all" finalDefault="#all" version="1.1" xsi:schemaLocation="http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema.xsd">
   
   <xs:annotation>
     <xs:documentation>
This is the XML Schema for XML Events global attributes
      $Id: index-all.html,v 1.3 2002/08/21 14:00:56 henri Exp $
     </xs:documentation>
     <xs:documentation source="xml-events-copyright-1.xsd" />
   </xs:annotation>
   
   <xs:annotation>
     <xs:documentation>
XML Event Attributes

            These "global" event attributes are defined in "Attaching
            Attributes Directly to the Observer Element" of the XML
            Events specification.
         </xs:documentation>
   </xs:annotation>
   
   <xs:attribute name="event" type="xs:NMTOKEN" />
   <xs:attribute name="observer" type="xs:IDREF" />
   <xs:attribute name="target" type="xs:IDREF" />
   <xs:attribute name="handler" type="xs:anyURI" />
   <xs:attribute name="phase" default="default">
     <xs:simpleType>
       <xs:restriction base="xs:NMTOKEN">
         <xs:enumeration value="capture" />
         <xs:enumeration value="default" />
       </xs:restriction>
     </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="propagate" default="continue">
     <xs:simpleType>
       <xs:restriction base="xs:NMTOKEN">
         <xs:enumeration value="stop" />
         <xs:enumeration value="continue" />
       </xs:restriction>
     </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="defaultAction" default="perform">
     <xs:simpleType>
       <xs:restriction base="xs:NMTOKEN">
         <xs:enumeration value="cancel" />
         <xs:enumeration value="perform" />
       </xs:restriction>
     </xs:simpleType>
   </xs:attribute>
   
   <xs:attributeGroup name="XmlEvents.attlist">
     <xs:attribute ref="ev:event" />
     <xs:attribute ref="ev:observer" />
     <xs:attribute ref="ev:target" />
     <xs:attribute ref="ev:handler" />
     <xs:attribute ref="ev:phase" />
     <xs:attribute ref="ev:propagate" />
     <xs:attribute ref="ev:defaultAction" />
   </xs:attributeGroup>
</xs:schema>

B References

B.1 Normative References

XHTML Modularization: Modularization of XHTML, M. Altheim, et. al., 2001. W3C Recommendation available at http://www.w3.org/TR/xhtml-modularization/.
RFC 2119: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels , S. Bradner, 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
RFC 2388: RFC 2388: Returning Values from Forms: multipart/form-data, L. Masinter, 1998. Available at: http://www.ietf.org/rfc/rfc2388.txt.
RFC 2396: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, 1998. Available at: http://www.ietf.org/rfc/rfc2396.txt.
RFC 2616: RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,1999. Available at: http://www.ietf.org/rfc/rfc2616.txt.
XForms Req: XForms Requirements, Micah Dubinko, Dave Raggett, Sebastian Schnitzenbaumer, Malte Wedel, 2001. W3C Working Draft: available at: http://www.w3.org/TR/xhtml-forms-req.
XML Base: XML Base, Jonathan Marsh, 2001. W3C Recommendation available at: http://www.w3.org/TR/xmlbase/.
XML Events: XML Events - An events syntax for XML, Steven Pemberton, T. V. Raman, Shane P. McCarron, 2002. W3C Working Draft available at: http://www.w3.org/TR/xml-events/.
XML 1.0: Extensible Markup Language (XML) 1.0 (Second Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 2000. W3C Recommendation: available at: http://www.w3.org/TR/REC-xml
XML Names: Namespaces in XML, Tim Bray, Dave Hollander, Andrew Layman, 1999. W3C Recommendation available at: http://www.w3.org/TR/REC-xml-names.
XPath 1.0: XML Path Language (XPath) Version 1.0, James Clark, Steve DeRose, 1999. W3C Recommendation available at: http://www.w3.org/TR/xpath.
XML Schema part 1: XML Schema Part 1: Structures, Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2001. W3C Recommendation available at: http://www.w3.org/TR/xmlschema-1/.
XML Schema part 2: XML Schema Part 2: Datatypes, Paul V. Biron, Ashok Malhotra, 2001. W3C Recommendation available at: http://www.w3.org/TR/xmlschema-2/.
XSLT 1.0: XSL Transformations (XSLT) Version 1.0, James Clark, 1999. W3C Recommendation available at: http://www.w3.org/TR/xslt.

B.2 Informative References

Algorithms: The Art of Computer Programming: Volume 1 Fundamental Algorithms, D. E. Knuth, Addison-Wesley, Reading, MA. 1968. Third edition, 1997. ISBN:0-2018-9683-4.
AUI97: Auditory User Interfaces--Toward The Speaking Computer, T. V. Raman, Kluwer Academic Publishers, 1997. ISBN:0-7923-9984-6.
CSS2: Cascading Style Sheets, level 2 (CSS2) Specification, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, 1998. W3C Recommendation available at: http://www.w3.org/TR/REC-CSS2.
DOM2 Events: Document Object Model (DOM) Level 2 Events Specification, Tom Pixley, 2000. W3C Recommendation available at: http://www.w3.org/TR/DOM-Level-2-Events/.
DDJ-ArrayDoubling: Resizable Arrays, Heaps and Hash Tables, John Boyer, Doctor Dobb's Journal, CMP Media LLC, January 1998 Issue.
Java Unicode Blocks: Java 2 Platform, Standard Edition, v 1.4.0 API Specification; Class Character.UnicodeBlock, Sun Microsystems, Inc, 2002. Available at http://java.sun.com/j2se/1.4/docs/api/java/lang/Character.UnicodeBlock.html.
P3P 1.0: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, Lorrie Cranor, Marc Langheinrich, Massimo Marchiori, Martin Presler-Marshall, Joseph Reagle, 2001. W3C Last Call Working Draft available at: http://www.w3.org/TR/P3P/.
TAG Finding 7: TAG Finding: URIs, Addressability, and the use of HTTP GET, Dan Connolly, 2002. Available at: http://www.w3.org/2001/tag/doc/get7
Unicode Scripts: Script Names, Mark Davis, 2001. Unicode Technical Report #24 available at http://www.unicode.org/unicode/reports/tr24/.
XLink 1.0: XML Linking Language (XLink) Version 1.0 , Steve DeRose, Eve Maler, David Orchard, 2001. W3C Recommendation available at: http://www.w3.org/TR/xlink.
XHTML 1.0: XHTML 1.0: The Extensible HyperText Markup Language - A Reformulation of HTML 4 in XML 1.0, Steven Pemberton, et al., 2000. W3C Recommendation available at: http://www.w3.org/TR/xhtml1.
XML Schema part 0: XML Schema Part 0: Primer, David C. Fallside, 2001. W3C Recommendation available at: http://www.w3.org/TR/xmlschema-0/.

C Privacy Considerations

C.1 Using P3P with XForms

P3P privacy policies may be associated with any forms transmitted over HTTP that have URIs associated with them. In the future, mechanisms may be specified for associating P3P policies with content transmitted over other protocols.

P3P allows for policies to be associated with an individual URI or a set of URIs. By associating a separate policy with each URI a site can declare a very precise policy that addresses exactly what data is collected with a particular HTTP request and how that data will be used. However, site management is substantially easier for many sites if they declare a single policy that covers many URIs, or even their entire web presence.

The P3P specification specifies several methods for referencing a P3P policy reference file, which in turn associates P3P policies with URIs and cookies. XForms can be P3P enabled using any of the methods that are appropriate for the web site in which they are embedded. Some special considerations regarding forms are addressed in the P3P Specification. [P3P 1.0]

Different P3P policies may be applied to the representation of a form embedded in a containing document to that which is associated with the data submitted via that form. If the form representation is served from a different server than the form is submitted to, it is likely that separate P3P policy reference files and policies will be needed. Typically the form representation causes only clickstream data (as defined in [P3P 1.0] section 5.6.4) to be transferred, while a form submission causes much more data to be transferred.

D Recalculation Sequence Algorithm

XForms Processors are free (and encouraged) to skip or optimize any steps in this algorithm, as long as the end result is the same. The XForms recalculation algorithm considers model items and model item properties to be vertices in a directed graph. Edges between the vertices represent computational dependencies between vertices.

Following is the default handling for a recalculate action. Action recalculate is defined in 10.1.4 The recalculate Element.

A master dependency directed graph is created as detailed in D.1 Details on Creating the Master Dependency Directed Graph.
To provide consistent behavior, implementations must reduce the number of vertices to be processed by computing a pertinent dependency subgraph consisting only of vertices and edges that are reachable from nodes that require recomputation. This is detailed in D.2 Details on Creating the Pertinent Dependency Subgraph. Note that on a first recomputation (such as on form load), the pertinent dependency subgraph will be the same as the master dependency directed graph.
A topological sort is performed on the vertices of the pertinent dependency subgraph, resulting in an order of evaluation in which each vertex is evaluated only after those vertices on which it depends and before all vertices which depend on it. The topological sort algorithm is discussed at [Algorithms].
The recalculate process completes.

D.1 Details on Creating the Master Dependency Directed Graph

The master dependency directed graph can be considered an array with one record for each vertex, each having the following fields:

InstanceNode: a reference to the associated instance data node
type: indicates the aspect of the instance node represented by the vertex (the text content or a model item property such as readOnly or required)
depList: a list of vertices that refer to this vertex
inDegree: the number of vertices on which this vertex depends
visited: a flag used to ensure vertices are not added to a subgraph multiple times
index: an association between vertices in the master dependency directed graph and a subgraph

The depList for each vertex is assigned to be the referenced XML nodes of a given instance node, which are obtained by parsing the computed expression in the node (e.g., the calculate, relevant, readonly, or required property). Any expression violating any Binding Expression Constraint causes an exception (4.5.4 The xforms-compute-exception Event), terminating the recalculate process.

The depList for a vertex v is assigned to be the vertices other than v whose computational expressions reference v (described below). Vertex v is excluded from its own depList to allow self-references to occur without causing a circular reference exception.

A computational expression appearing in a calculate attribute controls the text content (value) of one or more instance nodes. A vertex exists for each instance node to represent the expression in the context of the node. Likewise, computational expressions for model item properties such as readOnly and required are applied to one or more instance nodes, and vertices are created to represent such expressions in the context of each applicable node. The computational expression of each vertex must be examined to determine the XML nodes to which it refers. Any expression violating any Binding Expression Constraint causes an exception (4.5.4 The xforms-compute-exception Event), terminating the recalculate process. A computation expression refers to a vertex v if a subexpression indicates the InstanceNode for v and v represents the instance node text content (its value). In this version of XForms, model item properties such as readOnly and required cannot be referenced in an expression.

D.2 Details on Creating the Pertinent Dependency Subgraph

If all calculations must be performed, which is the case on form load, then the pertinent dependency subgraph is simply a duplicate of the master dependency directed graph. If the recalculation algorithm is invoked with a list of changed instance data nodes since the last recalculation, then the pertinent dependency subgraph is obtained by exploring the paths of edges and vertices in the computational dependency directed graph that are reachable from each vertex in the change list. The method of path exploration can be depth first search, a suitable version of which appears in the pseudo-code below.

Example: Sample Algorithm to Create the Pertinent Dependency Subgraph

This algorithm creates a pertinent dependency subgraph S from a list of changed instance data nodes L<sub>c</sub>. Variables such as v and w represent vertices in the master dependency directed graph. The same variables ending with S indicate vertices in the pertinent dependency subgraph S.

// Use depth-first search to explore master digraph subtrees rooted at
// each changed vertex. A 'visited' flag is used to stop exploration
// at the boundaries of previously explored subtrees (because subtrees
// can overlap in directed graphs).
for each vertex r in Lc
  if r is not visited
  {
    Push the pair (NIL, r) onto a stack
    while the stack is not empty
    {
      (v, w) = pop dependency pair from stack
      if w is not visited
      {
         Set the visited flag of w to true
         Create a vertex wS in S to represent w
         Set the index of w equal to the array location of wS
         Set the index of wS equal to the array location of w
         Set the InstanceNode of wS equal to the InstanceNode of w
         Set the type of wS equal to the type of w
         For each dependency node x of w
             Push the pair (w, x) onto the stack
      }
      else Obtain wS from index of w
      if v is not NIL
      {
         Obtain vS from index of v
         Add dependency node for wS to vS
         Increment inDegree of wS
      }
    }
  }

// Now clear the visited flags set in the loop above

for each vertex vS in S
{
    Obtain v from index of vS
    Assign false to the visited flag of v
}

Note that the number of vertices and dependency nodes in the pertinent dependency subgraph is not known beforehand, but a method such as array doubling (see [DDJ-ArrayDoubling]) can be used to ensure that building the subgraph is performed in time linear in the size of S.

D.3 Details on Computing Individual Vertices

The following steps process vertices, resulting in a recalculated form:

A vertex with inDegree of 0 is selected for evaluation and removed from the pertinent dependency subgraph. In the case where more than one vertex has inDegree zero, no particular ordering is specified. If the pertinent dependency subgraph contains vertices, but none have an inDegree of 0, then the calculation structure of the form has a loop, and an exception (4.5.4 The xforms-compute-exception Event) must be thrown, terminating processing.
If the vertex corresponds to a computed item, computed expressions are evaluated as follows:
1. calculate: If the value of the model item changes, the corresponding instance data is updated and the dirty flag is set.
2. relevant, readOnly, required, isValid: If any or all of these computed properties change, the new settings are immediately placed into effect for associated form controls.
For each vertex in the depList of the removed vertex, decrement the inDegree by 1.
If no vertices remain in the pertinent dependency subgraph, then the calculation has successfully completed. Otherwise, repeat this sequence from step 1.

D.4 Example of Calculation Processing

For example, consider six vertices a, b, v, w, x, and y. Let a and b represent the text content of instance nodes that will be set by a binding from user input controls. Let v and w be vertices representing the calculated value and the validity property of a third instance node c. These vertices would result from a bind element B with calculate and isValid attributes and a ref attribute that indicates c. Suppose that the value of c is the product of a and b and that the value is only valid if it does not exceed 100. Likewise, suppose x and y are vertices representing the calculated value and the validity property of a fourth instance node d. Let the value of d be the sum of a and b, and let d be valid if the value does not exceed 20. The figure below depicts the dependency digraph for this example.

Dependency graph

Vertices a and b have edges leading to v and x because these vertices represent the calculate expressions of c and d, which reference a and b to compute their product and sum, respectively. Similarly, v and x have directed edges to w and y, respectively, because w and y represent the isValid expressions of c and d, which reference the values of c and d to compare them with boundary values.

If a and b are initially equal to 10, and the user changes a to 11, then it is necessary to first recalculate v (the value of c) then recalculate w (the validity property of the value of c). Likewise, x (the value of d) must be recalculated before recalculating y (the validity property of the value of d). In both cases, the validity of the value does not change to false until after the new product and sum are computed based on the change to a. However, there are no interdependencies between v and x, so the product and sum could be computed in either order.

The pertinent subgraph excludes b and only vertex a has in-degree of zero. The vertex a is processed first. It is not a computed vertex, so no recalculation occurs on a, but its removal causes v and x to have in-degree zero. Vertex v is processed second. Its value changes to 121, and its removal drops the in-degree of vertex w to zero. Vertex x is processed next, changing value to 21. When x is removed, its neighbor y drops to in-degree zero. The fourth and fifth iterations of this process recalculate the validity of w and y, both of which change to false.

E Input Modes

The attribute inputmode provides a hint to the user agent to select an appropriate input mode for the text input expected in an associated form control. The input mode may be a keyboard configuration, an input method editor (also called front end processor) or any other setting affecting input on the device(s) used.

Using inputmode, the author can give hints to the agent that make form input easier for the user. Authors should provide inputmode attributes wherever possible, making sure that the values used cover a wide range of devices.

E.1 `inputmode` Attribute Value Syntax

The value of the inputmode attribute is a white space separated list of tokens. Tokens are either sequences of alphabetic letters or absolute URIs. The later can be distinguished from the former by noting that absolute URIs contain a ':'. Tokens are case-sensitive. All the tokens consisting of alphabetic letters only are defined in this specification, in E.3 List of Tokens (or a successor of this specification).

This specification does not define any URIs for use as tokens, but allows others to define such URIs for extensibility. This may become necessary for devices with input modes that cannot be covered by the tokens provided here. The URI should dereference to a human-readable description of the input mode associated with the use of the URI as a token. This description should describe the input mode indicated by this token, and whether and how this token modifies other tokens or is modified by other tokens.

E.2 User Agent Behavior

Upon entering an empty form control with an inputmode attribute, the user agent should select the input mode indicated by the inputmode attribute value. User agents should not use the inputmode attribute to set the input mode when entering a form control with text already present. To set the appropriate input mode when entering a form control that already contains text, user agents should rely on platform-specific conventions.

User agents should make available all the input modes which are supported by the (operating) system/device(s) they run on/have access to, and which are installed for regular use by the user. This is typically only a small subset of the input modes that can be described with the tokens defined here.

The following simple algorithm is used to define how user agents match the values of an inputmode attribute to the input modes they can provide. This algorithm does not have to be implemented directly; user agents just have to behave as if they used it. The algorithm is not designed to produce "obvious" or "desirable" results for every possible combination of tokens, but to produce correct behavior for frequent token combinations and predictable behavior in all cases.

First, each of the input modes available is represented by one or more lists of tokens. An input mode may correspond to more than one list of tokens; as an example, on a system set up for a Greek user, both "greek upperCase" and "user upperCase" would correspond to the same input mode. No two lists will be the same.

Second, the inputmode attribute is scanned from front to back. For each token t in the inputmode attribute, if in the remaining list of tokens representing available input modes there is any list of tokens that contains t, then all lists of tokens representing available input modes that do not contain t are removed. If there is no remaining list of tokens that contains t, then t is ignored.

Third, if one or more lists of tokens are left, and they all correspond to the same input mode, then this input mode is chosen. If no list is left (meaning that there was none at the start) or if the remaining lists correspond to more than one input mode, then no input mode is chosen.

Example: Assume the list of lists of tokens representing the available input modes is: {"cyrillic upperCase", "cyrillic lowerCase", "cyrillic", "latin", "user upperCase", "user lowerCase"}, then the following inputmode values select the following input modes: "cyrillic title" selects "cyrillic", "cyrillic lowerCase" selects "cyrillic lowerCase", "lowerCase cyrillic" selects "cyrillic lowerCase", "latin upperCase" selects "latin", but "upperCase latin" does select "cyrillic upperCase" or "user upperCase" if they correspond to the same input mode, and does not select any input mode if "cyrillic upperCase" and "user upperCase" do not correspond to the same input mode.

E.3 List of Tokens

Tokens defined in this specification are separated into two categories: Script tokens and modifiers. In inputmode attributes, script tokens should always be listed before modifiers.

E.3.1 Script Tokens

Script tokens provide a general indication the set of characters that is covered by an input mode. In most cases, script tokens correspond directly to [Unicode Scripts]. Some tokens correspond to the block names in Java class java.lang.Character.UnicodeBlock ([Java Unicode Blocks]) or Unicode Block names. However, this neither means that an input mode has to allow input for all the characters in the script or block, nor that an input mode is limited to only characters from that specific script. As an example, a "latin" keyboard doesn't cover all the characters in the Latin script, and includes punctuation which is not assigned to the Latin script. The version of the Unicode Standards that these script names are taken from is 3.2.

Input Mode Token	Comments
arabic	Unicode script name
armenian	Unicode script name
bengali	Unicode script name
bopomofo	Unicode script name
braille	used to input braille patterns (not to indicate a braille input device)
buhid	Unicode script name
canadianAboriginal	Unicode script name
cherokee	Unicode script name
cyrillic	Unicode script name
deseret	Unicode script name
devanagari	Unicode script name
ethiopic	Unicode script name
georgian	Unicode script name
greek	Unicode script name
gothic	Unicode script name
gujarati	Unicode script name
gurmukhi	Unicode script name
han	Unicode script name
hangul	Unicode script name
hanja	Subset of 'han' used in writing Korean
hanunoo	Unicode script name
hebrew	Unicode script name
hiragana	Unicode script name (may include other Japanese scripts produced by conversion from hiragana)
ipa	International Phonetic Alphabet
kanji	Subset of 'han' used in writing Japanese
kannada	Unicode script name
katakana	Unicode script name (full-width, not half-width)
khmer	Unicode script name
lao	Unicode script name
latin	Unicode script name
malayalam	Unicode script name
math	mathematical symbols and related characters
mongolian	Unicode script name
myanmar	Unicode script name
ogham	Unicode script name
oldItalic	Unicode script name
oriya	Unicode script name
runic	Unicode script name
simplifiedHanzi	Subset of 'han' used in writing Simplified Chinese
sinhala	Unicode script name
syriac	Unicode script name
tagalog	Unicode script name
tagbanwa	Unicode script name
tamil	Unicode script name
telugu	Unicode script name
thaana	Unicode script name
thai	Unicode script name
tibetan	Unicode script name
traditionalHanzi	Subset of 'han' used in writing Traditional Chinese
user	Special value denoting the 'native' input of the user (e.g. to input her name or text in her native language).
yi	Unicode script name

E.3.2 Modifier Tokens

Modifier tokens can be added to the scripts they apply in order to more closely specify the kind of characters expected in the form field. Traditional PC keyboards do not need most modifier tokens (indeed, users on such devices would be quite confused if the software decided to change case on its own; CAPS lock for upperCase may be an exception). However, modifier tokens can be very helpful to set input modes for small devices.

Input Mode Token	Comments
lowerCase	lower case (for bicameral scripts)
upperCase	upper case (for bicameral scripts)
titleCase	title case (for bicameral scripts): words start with an upper case letter
startUpper	start input with one upper case letter, then continue with lower case letters
digits	digits of a particular script (e.g. inputmode='thai digits')
symbols	symbols, punctuation (suitable for a particular script)
predictOn	text prediction switched on (e.g. for running text)
predictOff	text prediction switched off (e.g. for passwords)
halfWidth	half-width compatibility forms (e.g. Katakana; deprecated)

E.4 Relationship to XML Schema pattern facets

User agents may use information available in an XML Schema pattern facet to set the input mode. Note that a pattern facet is a hard restriction on the lexical value of an instance data node, and can specify different restrictions for different parts of the data item. Attribute inputmode is a soft hint about the kinds of characters that the user may most probably start to input into the form control. Attribute inputmode is provided in addition to pattern facets for the following reasons:

The set of allowable characters specified in a pattern may be so wide that it is not possible to deduce a reasonable input mode setting. Nevertheless, there frequently is a kind of characters that will be input by the user with high probability. In such a case, inputmode allows to set the input mode for the user's convenience.
In some cases, it would be possible to derive the input mode setting from the pattern because the set of characters allowed in the pattern closely corresponds to a set of characters covered by an inputmode attribute value. However, such a derivation would require a lot of data and calculations on the user agent.
Small devices may leave the checking of patterns to the server, but will easily be able to switch to those input modes that they support. Being able to make data entry for the user easier is of particular importance on small devices.

E.5 Examples

This is an example of a form for Japanese address input. It is shown in table form; it will be replaced by actual syntax in a later version of this specification.

Caption:	`inputmode`
Family name	hiragana
(in kana)	katakana
Given name	hiragana
(in kana)	katakana
Zip code	latin digits
Address	hiragana
(in kana)	katakana
Email	latin lowerCase
Telephone	latin digits
Comments	user predict

F XForms and Styling (Non-Normative)

This informative section provides a broad outline of new and existing CSS features needed to style XForms content. A future Recommendation from the CSS Working Group will fully develop the specification of these features.

F.1 Pseudo-classes

A CSS pseudo-class is used to select elements for styling based on information that lies outside of the document tree or that cannot be expressed using the other selectors.

Name	Defined in:	Relationship to XForms
`:enabled` & `:disabled`	[CSS3]	Selects any form control bound to a node with the model item property `relevant` evaluating to true or false (respectively).
`:forms-required` & `:forms-optional`	TBD	Selects any form control bound to a node with the model item property `required` evaluating to true or false (respectively).
`:forms-valid` & `:forms-invalid`	TBD	Selects any form control bound to a node that is currently valid or invalid (respectively), as defined by XForms 1.0.

This list is not exhaustive; other pseudo-classes may be defined.

F.2 Pseudo-elements

Pseudo-elements are abstractions about the document tree beyond those specified by the document language. Pseudo-elements do not appear in the DOM; they are used only for purposes of styling.

Name	Defined in:	Relationship to XForms
`::control`	TBD	Represents the "active" area of a form control excluding the label; this corresponds in HTML to `input` and other form control elements. This pseudo-element is a child of the form control element, and appears immediately after the required `label` element.
`::repeat-item`	TBD	Represents a single item from a repeating sequence. Its position is as a parent to all the elements in a single repeating item. Each `::repeat-item` is associated with a particular instance data node, and is affected by the model item properties (e.g. '`relevant`') found there, as the related style properties will cascade to the child elements.
`::repeat-index`	TBD	Represents the current item of a repeating sequence. Its position is as a parent of all the elements in the index repeating item (and as a child to the `::repeat-item` pseudo-element), thus any style declarations applying to this pseudo-element override those on the parent `::repeat-item`.

This list is not exhaustive; other pseudo-elements may be defined.

F.3 Examples

The following examples show how basic styling can be accomplished on form controls and repeating structures.

@namespace xforms url(http://www.w3.org/2002/08/xforms/cr);

/* Display a red background on all invalid form controls */
*:forms-invalid { background-color:red; }

/* Display a red asterisk after all required form controls */
*:forms-required::after { content: "*"; color:red; }

/* Do not render non-relevant form controls */
*:disabled { visibility :hidden; }


/* The following declarations cause form controls and their labels
to align neatly, as if a two-column table were used */
xforms|group { display: table; }
xforms|input { display: table-row; }
xforms|input > xforms|label { display: table-cell; }
xforms|input::control { border: thin black solid; display: table-cell; }

/* Display repeat-items with a dashed border */
*::repeat-item { border: dashed; }

/* Display a teal highlight behind the current repeat item */
*::repeat-index { background-color: teal; }

/* Display non-relevant repeat items in the system GrayText color */
*::repeat-item:disabled { visibility: visible; color: GrayText; }

G Complete XForms Examples (Non-Normative)

This section presents complete XForms examples.

G.1 XForms In XHTML

<html xmlns="http://www.w3.org/2002/06/xhtml2" xmlns:xforms="http://www.w3.org/2002/08/xforms/cr" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:my="http://commerce.example.com/payment">
   <head>
     <title xml:lang="fr">XForms en XHTML</title>

     <xforms:model schema="payschema.xsd">
       <xforms:instance>
         <my:payment as="credit">
           <my:cc />
           <my:exp />
         </my:payment>
       </xforms:instance>
       <xforms:submission action="http://www.example.com/buy.rb" method="post" id="s00" />
       <xforms:bind nodeset="my:cc" relevant="../@as='credit'" required="true()" />
       <xforms:bind nodeset="my:exp" relevant="../@as='credit'" required="true()" />
     </xforms:model>
   </head>
   <body>
    ...
     <group xmlns="http://www.w3.org/2002/08/xforms/cr">
       <trigger>
         <label>Français</label>
         <toggle case="fr" ev:event="xforms-activate" />
       </trigger>
       <trigger>
         <label>English</label>
         <toggle case="en" ev:event="xforms-activate" />
       </trigger>
     </group>

     <switch xmlns="http://www.w3.org/2002/08/xforms/cr">
       <case id="fr">
         <select1 ref="@as">
           <label xml:lang="fr">Choisissez la méthode de paiement</label>
           <choices>
             <item>
               <label xml:lang="fr">Cash</label>
               <value>cash</value>
                 <alert xml:lang="fr">Veuillez ne pas expédier l'argent comptant.</alert>
             </item>
             <item>
               <label xml:lang="fr">Carte bancaire</label>
               <value>credit</value>
             </item>
           </choices>
         </select1>

         <input ref="my:cc">
           <label xml:lang="fr">Nombre de Carte de Banque</label>
         </input>

         <input ref="my:exp">
           <label xml:lang="fr">Date d'échéance.</label>
         </input>

         <submit submission="s00">
           <label xml:lang="fr">Achat</label>
         </submit>
       </case>
       <case id="en">
         <select1 ref="@as">
           <label xml:lang="en">Select Payment Method</label>
           <choices>
             <item>
               <label xml:lang="en">Cash</label>
               <value>cash</value>
               <alert xml:lang="en">Please do not mail cash.</alert>
             </item>
             <item>
               <label xml:lang="en">Credit</label>
               <value>credit</value>
             </item>
           </choices>
         </select1>

         <input ref="my:cc">
           <label xml:lang="en">Credit Card Number</label>
         </input>

         <input ref="my:exp">
           <label xml:lang="en">Expiration Date</label>
         </input>

         <submit submission="s00">
           <label xml:lang="en">Buy</label>
         </submit>
       </case>
     </switch>
    ...
   </body>
</html>

Schema file payschema.xsd:

<xsd:schema xmlns:my="http://commerce.example.com/payment" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://commerce.example.com/payment" elementFormDefault="qualified">

   <xsd:element name="payment">
     <xsd:complexType name="payment">
       <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:choice>
           <xsd:element ref="my:cc" />
           <xsd:element ref="my:exp" />
         </xsd:choice>
       </xsd:sequence>
       <xsd:attribute name="as" type="my:paymentAs" />
     </xsd:complexType>
   </xsd:element>
   <xsd:element name="cc" type="my:cc" />
   <xsd:element name="exp" type="xsd:gYearMonth" />

   <xsd:simpleType name="cc">
     <xsd:restriction base="xsd:string">
       <xsd:pattern value="\s*((\d+)[-\s])+([\d]+)\s*" />
     </xsd:restriction>
   </xsd:simpleType>

   <xsd:simpleType name="paymentAs">
     <xsd:restriction base="xsd:string">
       <xsd:enumeration value="cash" />
       <xsd:enumeration value="credit" />
     </xsd:restriction>
   </xsd:simpleType>
</xsd:schema>

G.2 Editing Hierarchical Bookmarks Using XForms

<html xmlns="http://www.w3.org/2002/06/xhtml2" xmlns:xforms="http://www.w3.org/2002/08/xforms/cr" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:my="http://commerce.example.com/payment" xmlns:ev="http://www.w3.org/2001/xml-events" xml:lang="en">
   <head>
<style type="text/css">
xforms:input.editField {
font-weight:bold; font-size:20px; width:500px
}
xforms:label.sectionLabel {
  font-weight:bold; color:white; background-color:blue
}
xforms:submit {
  font-family: Arial; font-size: 20px; font-style: bold; color: red
}
</style>
     <title>Editing Hierarchical Bookmarks In X-Smiles </title>
     <xforms:model id="bookmarks">
       <xforms:instance src="bookmarks.xml" />
       <xforms:submission id="s01" method="post" action="http://examples.com/" />
     </xforms:model>
   </head>
   <body>
     <xforms:repeat nodeset="section" id="repeatSections">
       <xforms:input ref="@name" class="editField">
         <xforms:label class="sectionLabel">Section</xforms:label>
       </xforms:input>

       <xforms:repeat nodeset="bookmark" id="repeatBookmarks">
         <xforms:input ref="@name">
           <xforms:label>Bookmark name</xforms:label>
         </xforms:input>
         <xforms:input ref="@href">
           <xforms:label>URL</xforms:label>
         </xforms:input>
       </xforms:repeat>
     </xforms:repeat>
     <p>

       <xforms:trigger id="insertbutton">
         <xforms:label>Insert bookmark</xforms:label>
         <xforms:insert nodeset="section[index('repeatSections')]/bookmark" at="index('repeatBookmarks')" position="after" ev:event="xforms-activate" />
       </xforms:trigger>

       <xforms:trigger id="delete">
         <xforms:label>Delete bookmark</xforms:label>
         <xforms:delete nodeset="section[index('repeatSections')]/bookmark" at="index('repeatBookmarks')" ev:event="xforms-activate" />
       </xforms:trigger>
     </p>
     <p>

       <xforms:trigger id="insertsectionbutton">
         <xforms:label>Insert section</xforms:label>
         <xforms:insert nodeset="section" at="index('repeatSections')" position="after" ev:event="xforms-activate" />
       </xforms:trigger>

       <xforms:trigger id="deletesectionbutton">
         <xforms:label>Delete section</xforms:label>
         <xforms:delete nodeset="section" at="index('repeatSections')" ev:event="xforms-activate" />
       </xforms:trigger>
     </p>

     <xforms:submit submission="s01">
       <xforms:label>Save</xforms:label>
       <xforms:hint>Click to submit</xforms:hint>
     </xforms:submit>
   </body>
</html>

Initial instance file bookmarks.xml:

<bookmarks>
   <section name="main">
     <bookmark href="http://www.example.com/xforms.xml" name="Main page" />
   </section>
   <section name="demos">
     <bookmark href="http://www.example.com/demo/images.fo" name="images" />
     <bookmark href="http://www.example.com/demo/xf-ecma.xml" name="ecma" />
     <bookmark href="http://www.example.com/demo/sip.fo" name="sip" />
   </section>
   <section name="XForms">
     <bookmark href="file:///C/source/xmlevents.xml" name="XML events" />
     <bookmark href="file:///C/source/model3.xml" name="model3" />
     <bookmark href="file:///C/source/repeat.fo" name="repeat" />
   </section>
</bookmarks>

H Changelog (Non-Normative)

This section summarizes substantive changes since the January Last Call version of the XForms 1.0 specification. See the diff-marked version for detailed individual changes.

The Schema for XForms A Schema for XForms also contains a separate change log of Schema changes.

H.1 Structural

The syntax and content model descriptions of elements are now categorized and described as in [XHTML Modularization]. The informative tutorial chapter has been rewritten. All instance data must have a single element root, and multiple instances are allowed per model, as are multiple XML Schemas. For consistency with XHTML, many elements and attributes have been renamed, and the Working Group has decided to share the W3C linking solution under development. The 'privacy' element has been removed, so as to not conflict with predefined methods of locating P3P documents; a privacy appendix has been added. Requests for implementation feedback have been added throughout the document. XForms now normatively references XML Base, though it is a host language responsibility to define processing. Tightened up conformance section, now listing specific, testable, conformance criteria. A new appendix provides a direction for future styling work related to XForms.

H.2 Form Controls

The 'appearance' hint has been significantly generalized and made less visual-centric, as well as open-ended. The upload control can now populate a filename and media type. Half-width modes have been reinstated for input modes. An 'incremental' attribute allows for form immediate data propagation. Description of how form data is applied to the instance data has been clarified and stated in terms of XForms Actions. In the case of lists that have complexType interactions with instance data, a new element "copy" has been introduced, including explicit rules for data interaction. Attributes 'class' and 'xml:lang' have been removed as common attributes, leaving this to the host language to provide. An alternative, attribute-based syntax for repeat allows more options in document integration. 'trigger' (formerly 'button') is permitted binding attributes, for the purpose of associating mode item properties.

H.3 Processing

Incorporated numerous comments on submit processing: we don't deprecate GET, we provide stronger legacy support for urlencoding (including UTF8), and we offer better multipart serialization. Besides http, we indicate how https, file, and mailto interact with XForms. Removed section on DOM mutation events. All defined mutation events now specify transactional behavior for propagating changes throughout the form. Error conditions have been thoroughly defined.

H.4 XPath

Four new functions provide date/time operations, based on a subclassed xsd:duration datatype. The rules for context nodes have been simplified, and are now the same for normal and 'lazy author' processing.

H.5 Model

Now consistently using the terms "model item" and "model item property". Added a 'p3ptype' property to express fine-grained P3P datatypes. Overall, model item properties have been clarified as to how they work with inheritance. minOccurs and maxOccurs are now computed properties. If more than one bind attempts to set a model item property on a node, it is now considered a fatal error.

H.6 Actions and Events

A number of new events describe state changes at form controls. The 'script' action has been removed (to be defined by the host language). Added XForms event for rebuild; added IDL functions for rebuild, recalculate, revalidate, refresh.

I Acknowledgments (Non-Normative)

This document was produced with the participation of the XForms Working Group:

Steven Pemberton, CWI (Chair)
Sebastian Schnitzenbaumer, Mozquito Technologies (Chair)
Micah Dubinko, Cardiff (Editor)
Peter Stark, Ericsson
Mikko Honkala, Helsinki University Of Technology
Roland Merrick, IBM (Editor)
T. V. Raman, IBM (Editor)
Ray Waldin, Lexica, LLC
Tantek Çelik, Microsoft
Dave Hyatt, Netscape/AOL
Eric Pollmann, Netscape/AOL
Tom Butcher, OpenDesign
Doug Dominiak, Openwave
Ted Wugofski, Openwave
David Cleary, Progress Software
K. P. Lee, Philips
Roli Wendorf, Philips
John Boyer, PureEdge Solutions Inc
Zoe Lacroix, SurroMed, Inc.
Dave Navarro, WebGeek Inc.
Thierry Michel, W3C (W3C Team Contact)
Leigh Klotz, Xerox (Editor)
Frank Boumphrey, HTML Writer's Guild (Until November 2000)
Josef Dietl, Mozquito Technologies (Until October 2001)
Linda Bucsay Welsh, Intel (Until April 2001)
Gavin McKenzie, JetForm Corporation (Until January 2001)
Rob McDougall, JetForm Corporation (Until January 2001)
John McCarthy, Lawrence Berkeley National Laboratory (Until November 2000)
Frank Olken, Lawrence Berkeley National Laboratory (Until November 2000)
Panagiotis Reveliotis, Philips (Until December 2000)
Mike Mansell, PureEdge Solutions Inc (Until March 2001)
Michael Fergusson, SoftQuad (Until January 2001)
Dave Raggett, W3C/Openwave (Team Contact until December 2000)
Masayasu Ishikawa, W3C (Team Contact until September 2001)
Larry Masinter, Xerox (Until December 1999)

The XForms Working Group has benefitted in its work from the participation of Invited Experts:

Tom Schnetlage, University of Berkeley
Dan Gillman, Federal Bureau of Labor Statistics
Eliot Christian, U.S. Geological Survey

Note:

Editor Acknowledgments: Previous versions of this document were edited with assistance from Dave Raggett (until December 2000), Linda Bucsay Welsh (until April 2001), and Josef Dietl (until October 2001). Martin Dürst edited the section on input modes.

Note:

Additional Acknowledgments: The editors would like to thank Kai Scheppe, Malte Wedel, and Götz Bock for constructive criticism on early versions of the binding discussion and their contributions to its present content. We thank John Boyer for authoring the sections on the recalculation sequence algorithm—see D Recalculation Sequence Algorithm. Finally, we would like to thank members of the public www-forms@w3.org mailing list for their careful reading of draft versions of this specification and providing constructive suggestions and criticisms.

Note:

Additional Acknowledgments: The Working Group would like to thank the following members of the XML Schema-XForms joint task force: Daniel Austin (chair), David Cleary, Micah Dubinko, Martin Dürst, David Ezell, Leigh Klotz, Noah Mendelsohn, Roland Merrick, and Peter Stark for their assistance in identifying a subset of XML Schema for use in XForms.

J Production Notes (Non-Normative)

This document was encoded in the XMLspec DTD (which has documentation available). The XML sources were transformed using xmlspec.xsl style sheet. The Schema appendixes were rendered into HTML with the xmlverbatim XSLT stylesheet (used with permission). The primary tools used for editing were SoftQuad XMetaL and EMACS with psgml and XAE. The XML was validated using XMLLint (part of the GNOME libxml package) and transformed using XSLTProc—part of the GNOME libxsl package). The multi-file HTML version was produced using the Xalan processor. The HTML versions were also produced at times with the Saxon engine. The editors used the W3C CVS repository and the W3C IRC server for collaborative authoring.

XForms 1.0

W3C Working Draft 21 August 2002

Abstract

Status of this Document

Table of Contents

Appendices

1 About the XForms 1.0 Specification

1.1 Background

1.2 Reading the Specification

1.3 How the Specification is Organized

1.4 Documentation Conventions

2 Introduction to XForms

2.1 An Example

2.2 Providing XML Instance Data

2.3 Constraining Values

2.4 Multiple Forms per Document

3 Document Structure

3.1 The XForms Namespace

3.2 XForms Core Attribute Collections

3.2.1 Common Attributes

3.2.2 Linking Attributes

3.2.3 Single-Node Binding Attributes

3.2.4 Node-Set Binding Attributes

3.3 The XForms Core Module

3.3.1 The model Element

3.3.2 The instance Element

3.3.3 The submission Element

3.3.4 The bind Element

3.4 The XForms MustUnderstand Module

3.5 The XForms Extension Module

3.5.1 The extension Element

4 Processing Model

4.1 Events Overview

4.2 Initialization Events

4.2.1 The xforms-model-construct Event

4.2.2 The xforms-model-initialize Event

4.2.3 The xforms-initialize-done Event

4.2.4 The xforms-ui-initialize Event

4.2.5 The xforms-form-control-initialize Event

4.2.6 The xforms-model-destruct Event

4.3 Interaction Events

4.3.1 The xforms-next and xforms-previous Events

4.3.2 The xforms-focus Event

4.3.3 The xforms-help and xforms-hint Events

4.3.4 The xforms-refresh Event

4.3.5 The xforms-revalidate Event

4.3.6 The xforms-recalculate Event

4.3.7 The xforms-rebuild Event

4.3.8 The xforms-reset Event

4.3.9 The xforms-submit Event

4.4 Notification Events

4.4.1 The xforms-activate Event

4.4.2 The xforms-value-changing Event

4.4.3 The xforms-value-changed Event

4.4.4 The xforms-select and xforms-deselect Events

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

4.4.6 The xforms-insert and xforms-delete Events

4.4.7 The xforms-valid Event

4.4.8 The xforms-invalid Event

4.4.9 The DOMFocusIn Event

4.4.10 The DOMFocusOut Event

4.4.11 The xforms-readonly Event

4.4.12 The xforms-readwrite Event

4.4.13 The xforms-required Event

4.4.14 The xforms-optional Event

4.4.15 The xforms-enabled Event

4.4.16 The xforms-disabled Event

4.4.17 The xforms-submit-done Event

4.4.18 The xforms-submit-error Event

4.5 Error Indications

4.5.1 The xforms-binding-exception Event

4.5.2 The xforms-link-exception Event

4.5.3 The xforms-link-error Event

4.5.4 The xforms-compute-exception Event

5 Datatypes

5.1 XML Schema Built-in Datatypes

5.2 XForms Datatypes

5.2.1 xforms:listItem

5.2.2 xforms:listItems

5.2.3 xforms:dayTimeDuration

7.8.1 `The property() Function`