W3C

XForms 1.0

W3C Working Draft 07 December 2001

This version:
http://www.w3.org/TR/2001/WD-xforms-20011207 (One big file, diff-marked HTML, Zip archive)
Latest version:
http://www.w3.org/TR/xforms/
Previous version:
http://www.w3.org/TR/2001/WD-xforms-20010828
Editors:
Micah Dubinko, Cardiff <mdubinko@Cardiff.com>
Josef Dietl, Mozquito Technologies <josef@mozquito.com>
Leigh L. Klotz, Jr., Xerox Corporation <Leigh.Klotz@pahv.xerox.com>
Roland Merrick, IBM <Roland_Merrick@uk.ibm.com>
T. V. Raman, IBM <tvraman@almaden.ibm.com>

Abstract

Forms were introduced into HTML in 1993. Since then they have become a critical part of the Web. The existing mechanisms in HTML for forms are now outdated, and the W3C started work on developing an effective replacement. This document defines "XForms", W3C's name for the next generation of web forms.

Status of this Document

Last Update: $Date: 2001/12/06 22:53:54 $

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is a Working Draft that incorporates new material agreed upon at the Mountain View face to face meeting and ongoing feedback from the general public. According to our current plan, the next Working Draft after this one will be a "Last Call" Working Draft. Interested parties are encouraged to provide additional feedback and comments.

This document is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current public W3C Working Drafts can be found at http://www.w3.org/TR.

This document has been produced as part of the W3C HTML Activity.

Please send detailed comments on this document to www-forms@w3.org, the public forum for discussion of the W3C's work on web forms. To subscribe, send an email to the above address with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible online.

Table of Contents

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 Purpose and Presentation
    2.2 Current Approach: HTML
    2.3 Transition to XForms
    2.4 Providing XML Instance Data
    2.5 Constraining Values
    2.6 Multiple Forms per Document
    2.7 Complete Document
3 Terminology
4 Document Structure
    4.1 The XForms Namespace
    4.2 Horizontally Applicable Markup
    4.3 XForms Head Elements
        4.3.1 model
        4.3.2 instance
        4.3.3 schema
        4.3.4 submitInfo
        4.3.5 bind
        4.3.6 privacy
        4.3.7 action
        4.3.8 extension
    4.4 XForms and XLink
        4.4.1 XLink Conformance and Examples
5 Datatypes
    5.1 XML Schema Built-in Datatypes
    5.2 XForms Datatypes
        5.2.1 listItem
        5.2.2 listItems
6 Constraints
    6.1 XForms Constraints
        6.1.1 type
        6.1.2 readOnly
        6.1.3 required
        6.1.4 relevant
        6.1.5 calculate
        6.1.6 isValid
        6.1.7 maxOccurs
        6.1.8 minOccurs
    6.2 Schema Constraints
        6.2.1 Atomic Datatype
    6.3 Additional Schema Examples
        6.3.1 Closed Enumeration
        6.3.2 Open Enumeration
        6.3.3 Union
        6.3.4 Lists
    6.4 Binding
        6.4.1 bind
        6.4.2 Binding Constraints
        6.4.3 Binding References
7 XPath Expressions in XForms
    7.1 Datatypes
    7.2 Instance Data
    7.3 Evaluation Context
    7.4 Forms Core Function Library
        7.4.1 Boolean Methods
            7.4.1.1 boolean-from-string()
            7.4.1.2 if()
        7.4.2 Number Methods
            7.4.2.1 avg()
            7.4.2.2 min()
            7.4.2.3 max()
            7.4.2.4 count-non-empty()
            7.4.2.5 cursor()
        7.4.3 String Methods
            7.4.3.1 property()
            7.4.3.2 now()
8 Form Controls
    8.1 input
    8.2 textarea
    8.3 secret
    8.4 output
    8.5 upload
    8.6 range
    8.7 button
    8.8 submit
    8.9 selectOne
    8.10 selectMany
    8.11 Common Markup for selection controls
        8.11.1 choices
        8.11.2 item
        8.11.3 itemset
        8.11.4 value
        8.11.5 itemref
    8.12 Common Markup
        8.12.1 Common Attributes
        8.12.2 Single Node Binding Attributes
        8.12.3 Nodeset Binding Attributes
        8.12.4 Common Child Elements
            8.12.4.1 caption
            8.12.4.2 help
            8.12.4.3 hint
            8.12.4.4 alert
            8.12.4.5 extension
9 XForms Actions
    9.1 dispatch
    9.2 refresh
    9.3 recalculate
    9.4 revalidate
    9.5 setFocus
    9.6 loadURI
    9.7 setValue
    9.8 submitInstance
    9.9 resetInstance
    9.10 setRepeatCursor
    9.11 insert
    9.12 delete
    9.13 toggle
    9.14 script
    9.15 message
    9.16 action
10 XForms User Interface
    10.1 Grouping Form Controls
    10.2 Conditional Constructs For Dynamic User Interfaces
    10.3 Repeating Structures
        10.3.1 Repeat Processing
        10.3.2 User Interface Interaction
11 Processing Model
    11.1 Events Overview
    11.2 Initialization Events
        11.2.1 xforms:modelConstruct
        11.2.2 xforms:modelInitialize
        11.2.3 xforms:initializeDone
        11.2.4 xforms:UIInitialize
        11.2.5 xforms:formControlInitialize
    11.3 Interaction Events
        11.3.1 DOM Mutation Events
        11.3.2 xforms:next and xforms:previous
        11.3.3 xforms:focus and xforms:blur
        11.3.4 xforms:activate
        11.3.5 xforms:valueChanging
        11.3.6 xforms:valueChanged
        11.3.7 xforms:scrollFirst
        11.3.8 xforms:scrollLast
        11.3.9 xforms:insert and xforms:delete
        11.3.10 xforms:select and xforms:deselect
        11.3.11 xforms:help and xforms:hint
        11.3.12 xforms:alert
        11.3.13 xforms:valid
        11.3.14 xforms:invalid
        11.3.15 xforms:refresh
        11.3.16 xforms:revalidate
        11.3.17 xforms:recalculate
        11.3.18 xforms:reset
    11.4 XForms Submit
        11.4.1 xforms:submit
        11.4.2 application/x-www-form-urlencoded
        11.4.3 multipart/form-data
        11.4.4 text/xml
            11.4.4.1 Binary Content
    11.5 Error Indications
        11.5.1 xforms:schemaConstraintsError
        11.5.2 xforms:traversalError
        11.5.3 xforms:invalidDatatypeError
12 Conformance
    12.1 Conformance Levels
        12.1.1 XForms Basic
        12.1.2 XForms Full
    12.2 Conformance Description
        12.2.1 Conforming XForms Processors
        12.2.2 Conforming XForms Containing Documents
        12.2.3 Conforming XForms Generators

Appendices

A Schema for XForms
    A.1 Schema for XLink
    A.2 Schema for XML Events
B Input Modes
    B.1 List of Possible Input Modes
        B.1.1 Questionable Values
        B.1.2 Excluded Values
C References
    C.1 Normative References
    C.2 Informative References
D Recalculation Sequence Algorithm (Non-Normative)
    D.1 Details on Creating the Master Dependency Directed Graph
    D.2 Details on Creating the Pertinent Dependency Subgraph
    D.3 Details on Computing Individual Vertices
    D.4 Example of Calculation Processing
E Changelog (Non-Normative)
    E.1 Changes to Chapter Document Structure
    E.2 Changes to Chapter Datatypes
    E.3 Changes to Chapter Constraints
    E.4 Changes to Chapter XPath Expressions in XForms
    E.5 Changes to Chapter Form Controls
    E.6 Changes to Chapter XForms Actions
    E.7 Changes to Chapter XForms User Interface
    E.8 Changes to Chapter Processing Model
    E.9 Changes to Chapter Conformance
    E.10 Changes to Appendix Schema for XForms
F Acknowledgments (Non-Normative)
G Production Notes (Non-Normative)


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 of interactivity used by many Web sites. Web applications and eCommerce solutions have sparked the demand for better web forms with richer interactions. XForms are the response to this demand—extended analysis, followed by the creation of a new platform-independent markup language for online interaction between an XForms Processor and a remote entity. XForms are the successor to HTML forms, and benefit from the lessons learned in the years of HTML forms implementation experience.

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 and becomes more and more technical and specific towards the end. For quick access to information, a general table of contents, specific tables of contents at the beginning of each section provide easy navigation.

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 includes a brief tutorial on XForms, and a discussion of design principles.

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.

Appendices

Appendixes contain a normative description of XForms described in XML Schema, information on references, and other useful information.

1.4 Documentation Conventions

The following highlighting and typography is used to present technical material in this document:

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

xforms: The XForms namespace 4.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]
xlink: The XLink namespace [XLink]
ev: The XML Events namespace [XML Events]
my: Any user defined namespace

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

Official terms are defined in the following manner: [Definition: You can find most terms in the chapter 3 Terminology]. Links to terms may be specially highlighted in the text, though typically only on introductory usage or when special attention needs to be directed toward the term.

The XML representations of various elements within XForms are presented as follows: Listed are the element name, names of all attributes, allowed values of attributes appearing after a "=" character, default values of attributes appearing after a ":" character, and allowed content. One or more headings below the table provide additional explanatory information.

Example: XML Syntax Representation <example>
<example
  count = xsd:integer
  size = (small | medium | large) : medium
>
  <!-- Content: (allowed-content) -->
</example>

count - description of this attribute
size - description of this attribute

Certain common attributes 4.2 Horizontally Applicable Markup are not shown in the syntax representations except when special attention needs to be called to their presence.

Non-normative short examples are set off typographically:

Example Item

or

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 highlighting is used for non-normative commentary:

Note:

A general admonition to readers.

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

Issue (issue-id):

Issue-Name

A specific issue to which input from readers is requested, not intended for final publication.

For diff-marked formatted text, note that newly added text appears like this, changed text appears like this, and deleted text appears like this.

2 Introduction to XForms

This informative chapter provides an easily approachable description of the design of XForms, describing the major components and how they relate. Not every feature of XForms is covered here. For a complete, normative description of XForms, refer to the remainder of this document.

2.1 Purpose and Presentation

For explanatory purposes, a form can be considered to consist of 'purpose', 'presentation', and 'data'. Some examples:

Purpose Presentation Data
Data collection Arrangement of form controls Registration information
Time card How dates are entered Days and hours worked
Order form How to render the form controls on small devices Order, shipping, and payment info
Information Please How the form integrates with a Web site User contact information

The design of HTML forms didn't separate the purpose of a form from its presentation; additionally, they only offered a restricted representation for data captured through the form.

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. Type validation rules help client-side validation.

Re-use existing schema.

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.

Annotate external schema

This enables the XForms author 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.

Submit XML.

This obviates the need for custom server-side logic to marshall the submitted data to the application back-end. The received XML instance document can be directly validated and processed by the application back-end.

Internationalization

Using XML 1.0 ensures that the submitted data is internationalized.

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.

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-purpose the user interaction to different devices.

Declarative event handlers.

By defining XML-based declarative event handlers such as setFocus, message, and setValue that cover common use cases, the majority of XForms documents remain statically analyzable as opposed to imperative program code.

2.2 Current Approach: HTML

Consider a simple eCommerce form authored in HTML:

<html>
  <head>
    <title>eCommerce Form</title>
  </head>
  <body>
    <form action="http://example.com/submit" method="post">
      <table summary="Payment method selector">
      <tr>
      <td><p>Select Payment Method:</p></td>
      <td><label><input type="radio" name="as" value="cash"/>Cash</label>
      <label><input type="radio" name="as" value="credit"/>Credit</label></td>
      </tr>
      <tr>
      <td><label for="cc">Credit Card Number:</label></td>
      <td><input type="text" name="cc" id="cc"/></td>
      </tr>
      <tr>
      <td><label for="exp">Expiration Date:</label></td>
      <td><input type="text" name="exp" id="exp"/></td>
      </tr>
      <tr>
      <td colspan="2"><input type="submit"/></td>
      </tr>
      </table>
    </form>
  </body>
</html>

A browser might render this form as follows:

screen shot of a graphic rendering

This form makes no effort to separate purpose (data collection semantics) from presentation (the input form controls), and offers no control over the basic name/value pair serialization of the resulting data. The XForms standard greatly improve the expressive capabilities of electronic forms.

2.3 Transition to XForms

Editorial note: T. V. Raman  
Note that xforms:xform from the previous draft is now renamed to xforms:model; the earlier xforms:model is now named xforms:schema

With 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. The only presentation option defined in the XForms 1.0 specification is the XForms User Interface, which is a device-independent, platform-neutral set of form controls suitable for general-purpose use. This flexible architecture, however, allows others to attach user interfaces to an XForms Model, as illustrated here:

puzzle pieces; 'XForms Model' on the left, on the right 'XForms User Interface', 'XHTML', 'WML', and a stack of 'proprietary' pieces

The simplest case involves authoring the new XForms form controls, leaving out the other sections of the form. To convert the previous form into XForms this way, a model element is needed in the head section of the document:

<xforms:model>
  <xforms:submitInfo action="http://examples.com/submit" id="submit"/>
</xforms:model>

With these changes to the containing document, the previous example could be rewritten like this (note that we have intentionally defaulted the XForms namespace prefix in this example):

<selectOne ref="as">
  <caption>Select Payment Method</caption>
  <choices>
    <item>
      <caption>Cash</caption>
      <value>cash</value>
    </item>
    <item>
      <caption>Credit</caption>
      <value>credit</value>
    </item>
  </choices>
</selectOne>

<input ref="cc">
  <caption>Credit Card Number</caption>
</input>

<input ref="exp">
  <caption>Expiration Date</caption>
</input>

<submit>
  <caption>Submit</caption>
</submit>

Notice the following features of this design:

  • The user interface is not hard-coded to use radio buttons. Different devices (such as a voice browser) can render the concept of "selectOne" as appropriate.

  • Form controls always have captions directly associated with them, as child elements—this is a key feature designed to enhance the accessibility of forms.

  • There is no need for an enclosing form element, as in HTML. See (See 2.6 Multiple Forms per Document for details on how to author multiple forms per page)

  • Markup for specifying form controls has been simplified

  • Data gets submitted as XML.

With these changes, the XForms Processor will be able to directly submit XML instance data. The XML is constructed by creating a root element with child elements reflecting the names specified in each form control via attribute ref. In this example, the submitted data would look like this:

<instanceData>
  <as>Credit</as>
  <cc>1235467789012345</cc>
  <exp>2001-08</exp>
</instanceData>

2.4 Providing XML Instance Data

Authors will often desire greater control over exact construction of the submitted instance data. XForms allows data to be checked for validity interactively as the form is being filled. One common case might be submitting XML data that is validated against a predefined DTD or XML Schema.

XForms processing keeps track of the state of the partially filled form through instance data, which provides an outline of the desired XML data in the form of a skeleton XML instance, including namespace information. The instance data starts off with any initial values for the form, is updated as the user fills the form, and eventually is serialized and submitted. The initial instance data is defined in the instance element inside the model element, as follows:

<xforms:model>
  <xforms:instance>
    <payment as="credit" xmlns="http://commerce.example.com/payment">
      <cc/>
      <exp/>
    </payment>
  </xforms:instance>
  <xforms:submitInfo action="http://example.com/submit" method="post"/>
</xforms:model>

This design has features worth calling out:

  • There is complete flexibility in the structure of the XML. Notice that XML namespaces are now used, and that a wrapper element of the author's choosing wraps the instance data.

  • Empty elements cc and exp serve as placeholders in the XML structure, and will be filled in with form data provided by the user.

  • An initial value ("credit") for the form control is provided through the instance data, in this case an attribute as. In the submitted XML, this initial value will be replaced by the user input, if any.

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

.. xmlns:my="http://commerce.example.com/payment"...
  <xforms:selectOne ref="my:payment/@as">
    ...
  <xforms:input ref="my:payment/my:cc">
    ...
  <xforms:input ref="my:payment/my:exp">

Binding expressions are based on XPath [XPath 1.0], including the use of the @ character to refer to attributes, as seen here.

2.5 Constraining Values

Referring to the earlier HTML form in 2.2 Current Approach: HTML, there are several aspects that would be desirable to express, but would only be possible through the addition of unstructured script code:

  • The credit card information form controls cc and exp are only relevant if the "credit" option is chosen in the as form control.

  • The credit card information form controls cc and exp should be required when the "credit" option is chosen in the as form control.

  • The form control cc should accept digits only, and should have between 14 and 18 digits.

  • The form control exp should accept only valid month/date combinations.

By specifying an additional component, model item constraints, authors can include rich declarative datatype and validation information in forms, taken from XML Schema datatypes and also XForms-specific constraints, such as relevant.

XForms constraints appear on bind elements, while Schema constraints are expressed in an XML Schema fragment, either inline or external. For example:

... xmlns:my="http://commerce.example.com/payment"...
<xforms:bind ref="my:payment/my:cc"
    relevant="my:payment/[@as == 'credit']"
    required="true"
    type="my:cc"/>

<xforms:bind ref="my:payment/my:exp"
    relevant="my:payment/[@as == 'credit']"
    required="true"
    type="xsd:gYearMonth"/>

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

2.6 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 multiple forms share the same containing document, multiple model elements are needed. The first model element may omit a unique id attribute (as have all the examples above), but subsequent model elements require an id so that they can be referenced from elsewhere in the containing document.

The other side of the equation is that form controls throughout the document 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. this. The default for the model attribute is to refer to the first model element in document order.

To add a second form, an opinion poll, to our commerce example, the following would be authored in the head section of the document:

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

<xforms:model id="poll">
  <xforms:submitInfo .../>
</xforms:model>

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

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

<xforms:submit submitInfo="poll">
  <xforms:caption>Submit</xforms:caption>
</xforms:submit>

The main difference to note here is the use of model="poll", which identifies which form the form control binds to.

2.7 Complete Document

This chapter has presented various bits and pieces of XForms as a tool to help readers understand the design. For convenience, the entire document is given here in one piece..

Note:

The DOCTYPE declaration below is technically not valid, since XHTML 1.1 does not include XForms elements in any content models. The Working Group is developing a DOCTYPE declaration for the combination of XHTML and XForms.

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xforms="http://www.w3.org/2001/12/xforms"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns:my="http://commerce.example.com/payment"
      xml:lang="en">
<head>
<title>XForms in XHTML</title>

<xforms:model>
  <xforms:instance>
    <payment as="credit" xmlns="http://commerce.example.com/payment">
      <cc/>
      <exp/>
    </payment>
  </xforms:instance>
  <xforms:schema xlink:href="payschema.xsd"/>
  <xforms:submitInfo action="http://example.com/submit" method="post"/>
  <xforms:bind ref="my:payment/my:cc"
      relevant="my:payment/@as == 'credit'"
      required="true" type="my:cc"/>
  <xforms:bind ref="my:payment/my:exp"
      relevant="my:payment/@as == 'credit'"
      required="true" type="xsd:gYearMonth"/>
</xforms:model>
</head>
<body>
...
<group xmlns="http://www.w3.org/2001/12/xforms" ref="my:payment">
  <selectOne ref="@as">
    <caption>Select Payment Method</caption>
    <choices>
      <item>
        <caption>Cash</caption>
        <value>cash</value>
      </item>
      <item>
        <caption>Credit</caption>
        <value>credit</value>
      </item>
    </choices>
  </selectOne>

  <input ref="my:cc">
    <caption>Credit Card Number</caption>
  </input>

  <input ref="my:exp">
    <caption>Expiration Date</caption>
  </input>

  <submit>
    <caption>Submit Form</caption>
  </submit>
</group>
...
</body>
</html>

3 Terminology

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

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

form control

[Definition: An XForms user interface control that serves as a point of user interaction.]

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 constraint

[Definition: Either a Schema constraint or an XForms constraint. ]

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 constraint

[Definition: A restriction, applied to form data, based on XForms-specific expressions. ]

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

4 Document Structure

The XForms specification is an application of XML [XML 1.0], and has been designed for use within other XML vocabularies, in particular XHTML [XHTML 1.0]. This chapter discusses the structure and high-level features of XForms that allow this specification to be used with other document types.

4.1 The XForms Namespace

The XForms namespace has the URI: http://www.w3.org/2001/12/xforms. 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.

4.2 Horizontally Applicable Markup

For cases when a particular element needs to be referred to from another context, every element in the XForms namespace has declared an attribute id of type xsd:ID in the Schema for XForms.

Foreign-namespaced attributes are allowed on any XForms element. The XForms Processor must ignore any foreign-namespaced elements or attributes that are unrecognized.

Except where specifically allowed by the Schema for XForms, foreign-namespaced elements are not allowed as content of elements in the XForms namespace.

4.3 XForms Head Elements

4.3.1 model

Element model is used as a container for other XForms elements, and can serve as the root element of a standalone document or be embedded in the head section of other document types such as XHTML. A single containing document may contain any number of model elements.

Editorial note  
under discussion are XLink attributes on the model element. These are: xlink:type="extended" and xlink:role="http://www.w3.org/2001/12/xforms" - and they should be defaulted or even fixed in the Schema/DTD.
Example: XML Representation: <model>
<model
  id = xsd:ID
>
  <!-- Content: instance?, schema?, (privacy|submitInfo|bind|action|extension)* -->
</model>

id = xsd:ID - Optional unique identifier used to refer to this particular model element.

For example:

<model xmlns="http://www.w3.org/2001/12/xforms" id="Person">
   <instance xlink:href="http://example.com/cgi-bin/get-instance" /> 
   <schema xlink:href="Schema-Questionnaire.xsd" />
   ...
</model>

4.3.2 instance

Element instance is used to define initial instance data. The instance data may be defined inline or obtained from a external URI.

Example: XML Representation: <instance>
<instance
  xlink:href = xsd:anyURI
>
  <!-- Content: (##other) -->
</instance>

xlink:href = xsd:anyURI - Optional link to externally defined instance data

The content of the instance element is arbitrary XML in any namespace other than the XForms namespace. Authors must ensure that proper namespace declarations are used for content within the instance element.

Editorial note  
As above, we need to find a place to discuss the defaulted attributes. Here they are xlink:role="http://www.w3.org/2001/12/xforms-instance" xlink:type="locator"

Issue (issue-schemalocation):

Should a schemaLocation attribute, linking the instance data with a schema definition, be present here?

4.3.3 schema

Element schema is used to define the schema portion of the XForms Model. The schema information may be defined inline or obtained from an external URI.

Example: XML Representation: <schema>
<schema
  xlink:href = xsd:anyURI
>
  <!-- Content: ##other (though typically <xsd:schema>) -->
</schema>

xlink:href = xsd:anyURI - Optional link to an externally defined XForms Model.

Editorial note  
As above, we need to find a place to discuss the defaulted attributes. Here they are xlink:role="http://www.w3.org/2001/12/xforms-model" xlink:type="locator"

4.3.4 submitInfo

Element submitInfo provides information on how, where and what to submit .

Example: XML Representation: <submitInfo>
<submitInfo
  (single node binding attributes)
  action = xsd:anyURI
  mediaTypeExtension = "none" | qname-but-not-ncname : "none"
  method = "post" | "get" | qname-but-not-ncname : "post"
  version = xsd:NMTOKEN
  indent = xsd:boolean
  encoding = xsd:string
  mediaType = xsd:string
  omitXMLDeclaration = xsd:boolean
  standalone = xsd:boolean
  CDATASectionElements = list of xsd:QName
  replace = "all" | "instance" | "none" | qname-but-not-ncname : "all"
>
  <!-- Content: (##empty) -->
</submitInfo>

single node binding attributes - optional selector enabling submission of a portion of the instance data
action - Required destination for submitted instance data.

mediaTypeExtension
- Optional information, additional to the mediaType, describing the serialization format.
method - Optional indicator as to the protocol to be used to deliver the serialized instance data.
version - corresponds to the version attribute of xsl:output
indent - corresponds to the indent attribute of xsl:output
encoding - corresponds to the encoding attribute of xsl:output
mediaType - corresponds to the media-type attribute of xsl:output
omitXMLDeclaration - corresponds to the omit-xml-declaration attribute of xsl:output
standalone - corresponds to the standalone attribute of xsl:output
CDATASectionElements - corresponds to the cdata-section-elements attribute of xsl:output
replace
- specifier for how the information returned after submit should be applied.

Note:

Many of these attributes correspond to XSLT attributes [XSLT]. Note that the XSLT attributes doctype-system and doctype-public are not supported in XForms processing.

Note:

Note also that attribute mediaTypeExtension is useful in cases where a media type alone is not sufficiently precise. For instance, a SOAP envelope would not be adequately described simply by "text/xml", additional information would be required.

4.3.5 bind

Element bind is defined at 6 Constraints.

The bindings element is a container for bind elements.

Example: XML Representation: <bindings>
<bindings
>
  <!-- Content: (bind+) -->
</bindings>

Additional details, including the definition of the <bind> element are found in the chapter .

Editorial note  
As above, we need to find a place to discuss the defaulted XLink attributes.

4.3.6 privacy

Element privacy is used to associate a P3P [P3P 1.0] policy reference with a particular form.

Example: XML Representation: <privacy>
<privacy
  xlink:href = xsd:anyURI
>
  <!-- Content: (##empty) -->
</privacy>

xlink:href = xsd:anyURI - Optional link to an externally defined P3P policyref file (not an actual policy).

Editorial note  
As above, we need to find a place to discuss the defaulted XLink attributes.

4.3.7 action

Defined at 9.16 action.

4.3.8 extension

Defined at 8.12.4.5 extension.

4.4 XForms and XLink

XForms use XLink [XLink] features for linking, or defining an explicit relationship between resources (or portions of resources), which may be either local or remote.

To that end, the XForms schema references the XLink namespace with the majority of the sensible defaults., including those based on XLink roles defined later. Other than xlink:href attributes, form authors in most cases will not be required to explicitly write XLink-specific elements or attributes. To emphasize this design, the unprefixed attribute href is explicitly prohibited.

All XLinks in XForms are simple links. For further details, see 4.4.1 XLink Conformance and Examples.

XLink allows users to provide arc-type elements to specify traversal rules. The integration of arc-type elements in XForms would require additional elements in the model element that are otherwise not necessary. Hence, for children of the model element, the traversal rule is to traverse xlink:from the current document xlink:to the document pointed to by the external resource. The processor should behave as if xlink:actuate="onLoad" was specified. The xlink:show attribute is meaningless in this context, anyway.

4.4.1 XLink Conformance and Examples

An XForms processor is not required to implement full XLink—correct behavior of the xlink:href attribute (as defined in this chapter) is sufficient. For example, an XForms Processor must accept and correctly process the schema in both of the following:

Example: External schema constraints
<xforms:model>
  <xforms:schema xlink:href="URI-to-remote-schema.xsd" />
</xforms:model>
Example: Inline schema constraints
<xforms:model>
  <xforms:schema>
    <xsd:schema ...>
      <!-- Content: ... -->
    </xsd:schema>
  </xforms:schema>
</xforms:model>

This second example is unusual in that the xforms:schema element defaults an attribute xlink:type="simple" but lacks an xlink:href attribute to make the link meaningful. In this situation, the XForms Processor should switch from simple mode to none mode for the element lacking attribute xlink:href. For compatibility with XLink, the second example should be explicitly authored as follows:

Example: Inline schema constraints, with explicit xlink:type
<xforms:model>
  <xforms:schema xlink:type="none">
    <xsd:schema...>
      <!-- Content: ... -->
    </xsd:schema>
  </xforms:schema>
</xforms:model>

Manual override of the xlink:type attribute.

It is permissible to construct the additional information from the semantics of the elements. An XForms Processor can not be XForms compliant, however, if it attempts to implement XLink and the implementation does not conform to XLink specification with respect to the attributes used by XForms.

Note that the XLink support uses a well-defined XLink failure mode: If an XLink attribute is not provided, the element looses its XLink specific meaning. We use this feature in order to allow application developers to either provide the model and instance via an external reference (via an xlink:href attribute) or to provide the data inline without the attribute. In the latter case, the XLink-specific meaning of the element is lost and the inline content used. If both inline content and external reference is provided, a processor must use the external reference and ignore the inline content.

For the purposes of XForms, we suggest that XLink aware processors switch from the xlink:type="locator" mode to the xlink:type="resource" mode. This should be specified in the document by setting xlink:type="resource", though a processing agent may not depend on it. In other words, the first two of the following examples must be treated identically:

5 Datatypes

This chapter defines the datatypes used in XForms, both built-in and defined for XForms.

5.1 XML Schema Built-in Datatypes

XForms includes all XML Schema datatypes, including the concepts of value space and lexical space, and all constraining facets, as specified in [XML Schema part 2]. These are further divided into two modules, called Basic and Full, and are as follows. Base types included in module basic are marked with an asterisk *. Datatypes derived by restriction and derived by list from these base types are included in both Basic and Full modules.

Built-in primitive types:

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

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 *

Issue (datatype-identifiers):

One requirement is for XForms to include unique identifiers for each datatype listed here. We believe the facilities in XML Schema are sufficient for this, but welcome feedback on this issue.

Issue (now-facet):

Previous Working Drafts of XForms specified "dynamic facets" that could be re-evaluated at arbitrary times. One benefit of that approach was that a now() expression could be used as a constraining facet on date/time datatypes. What are our options for including similar functionality within the framework of XML Schema datatypes?

5.2 XForms Datatypes

The Schema for XForms derives the following types for use within forms:

5.2.1 listItem

This datatype serves as a base for the listItems datatype. The value space for listItem permits one or more characters valid for xsd:string, except whitespace characters. This datatype is suitable for XForms Basic or XForms Full.

Examples:

x
vanilla
grün

5.2.2 listItems

XForms includes form controls that produce simpleType list content. To prevent the need of authors to continuously redefine a derived-by-list datatype suitable for this case, one is included here. The value space for listItems is defined by list-derivation from listItem. This datatype is suitable for XForms Basic or XForms Full.

Example:

x vanilla grün

Note:

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

6 Constraints

This chapter discusses constraints that can be bound to form data. The combination of these constraints with an instance data node is called a model item. Overall, the constraints are called model item constraints. The term Schema constraint refers only to XML Schema datatype constraints, while the term XForms constraint refers to XForms-specific constraints defined in the following section.

6.1 XForms Constraints

XForms constraints, which occur as attributes on element bind in XForms 1.0, fall into two categories:

  • Computed expressions are XPath expressions that provide a value to the XForms Processor. The value is recomputed at certain times, according to the XForms Processing Model (see 11 Processing Model).

  • All other constraints are fixed, static values that the XForms Processor evaluates only once.

The following constraints are available for all model items, using syntax explained throughout this section. For each constraint the following information is provided:

Description
Computed Expression (yes or no)
Applies to children (instance data child elements and attributes)
Legal Values
Default Value
Additional descriptive text

6.1.1 type

Description: associates a Schema datatype.

Computed Expression: No

Applies to children: No

Legal Values: Any xsd:QName representing an in-scope datatype.

Default Value: xsd:string

The concept of typed data is important to forms. The assignment of a particular datatype to a model item affects validation of the data it can accept, as well as affecting which form controls to which it can bind.

The meaning of this constraint is the same as placing an xsi:type attribute on the instance data.

6.1.2 readOnly

Description: describes whether the value is restricted from changing. The ability of form controls to have focus and appear in the navigation order is unaffected by this constraint.

Computed Expression: Yes

Applies to children: Yes

Legal Values: Any expression that is convertible to boolean

Default Value: false

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

In addition to restricting value changes, the readOnly constraint provides a hint to the XForms User Interface. Form controls bound to instance data with the readOnly constraint should indicate that entering or changing the value is not allowed. This specification does not define any effect on visibility, focus, or navigation order.

6.1.3 required

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

Computed Expression: Yes

Applies to children: Yes

Legal Values: Any expression that is convertible to boolean

Default Value: false

Often forms require certain values to be entered. This may be a static requirement, or may only be the case if some condition is satisfied. When evaluating to true, this constraint indicates that a non-empty instance data node is required before a submission of instance data can occur. Non-empty is defined as:

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

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

Except as noted below, the required constraint 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 a unique indication that a form control is required, and may provide immediate feedback, including limiting navigation.

The chapter 11 Processing Model contains details on how the XForms Processor enforces required values.

6.1.4 relevant

Description: indicates whether the model item is currently relevant to the rest of the XForms Model. Instance data nodes with relevant=false, are not serialized for submission.

Computed Expression: Yes

Applies to children: Yes

Legal Values: Any expression that is convertible to boolean

Default Value: true

Many forms have data entry dependent 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.

When evaluating to true, this constraint indicates that the XForms Processor should render a form control, and conversely, when evaluating to false, indicates that the form control should be rendered specially (grayed out, hidden, etc.).

The relevant constraint 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.

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

required="true" required="false"
relevant="true" The form control (and any children) should be visible or available to the user. The XForms User Interface may indicate that a value is required. The form control (and any children) should 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) should 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) should be hidden or unavailable to the user. Entering a value or obtaining focus should not be allowed.

6.1.5 calculate

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

Computed Expression: Yes

Applies to children: No

Legal Values: Any XPath expression that is convertible to an XPath datatype compatible with the associated XML Schema datatype

Default Value: none

An XForms Model may include model items that are computed from the other values elsewhere. For example, the sum over line items for quantity times unit price, or the amount of tax to be paid on an order. The computed value can be represented as a computed expression using the values of other model items. The XForms Processing Model indicates how and when the calculation is recomputed.

6.1.6 isValid

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

Computed Expression: Yes

Applies to children: No

Legal Values: Any expression that is convertible to boolean

Default Value: true

An XForms Model may include model items that need to be revalidated. When evaluating to false, the associated model item is not valid; the converse is not necessarily true. Chapter 11 Processing Model describes details such as immediate validation versus validation upon submit.

Computed expressions used here are not restricted to examining the instance data node they are invoked on. XPath, plus the extensions in this specification, provide the means to traverse the instance data, as well as call-outs to external script, enabling potentially complex validations.

The XForms User Interface may indicate whether a form control is currently valid or invalid.

Issue (issue-cascade):

Will the isValid constraint be evaluated on all the parent or child model items whenever a value changes? We need to make sure that inter-model item constraints will get evaluated.MJD - Is this still an issue?

6.1.7 maxOccurs

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

Computed Expression: No

Applies to children: No

Legal Values: xsd:integer or "unbounded"

Default Value: "unbounded"

For model item elements that are repeated, this optional constraint specifies a maximum number of allowed child elements. This only applies to element nodes selected as part of a repeat sequence (10.3 Repeating Structures).

6.1.8 minOccurs

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

Computed Expression: No

Applies to children: No

Legal Values: xsd:integer

Default Value: 0.

For model item elements that are repeated, this optional constraint specifies a minimum number of allowed child elements. This only applies to element nodes selected as part of a repeat sequence (10.3 Repeating Structures).

6.2 Schema Constraints

Chapter 5 Datatypes described how XForms adopts the XML Schema datatyping system, which can constrain the value space of datatypes that can be used in data collection. This section draws the connection between Schema features and Schema Constraints, which can occur directly via a schema or indirectly by annotating an instance with instance-specific type constraints.

Datatypes used in XForms are either those predefined in chapter 5 Datatypes, or simpleTypes defined in a Schema.

Attributes xsi:schemaLocation and xsi:noNamespaceSchemaLocation are ignored for purposes for locating a Schema.

XForms Basic processors have restricted Schema processing requirements; full details are at 12.1.1 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 a 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 datatypes apply to the same node, the first definition in document order is used):

  1. An XML Schema xsi:type attribute (restricted to simpleTypes in XForms Basic) in the instance data.

  2. (XForms Full only) An XML Schema associated with the instance data.

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

  4. Otherwise, the datatype is treated as xsd:string (default to string rule).

Example Schema Syntax: declaring a datatype based on an xsd:string plus an additional constraining facet would be accomplished by the following in a 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:

<!-- Datatype through Schema xsi:type -->
<my:first-name xsi:type="nonEmptyString"/>

The above shows element <first-name> annotated with type xsi:type="nonEmptyString"—this specifies that the element first-name is of type nonEmptyString.

<!-- Datatype through XForms constraint -->
<instance>
  <my:first-name />
</instance>

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

Here, element first-name has attached type information via element bind. This enables the XForms author annotate and extend external Schemas that she does not have the ability to change.

6.3 Additional Schema Examples

The following non-normative sections illustrate mapping between Schema concepts and data structures commonly used in form authoring.

6.3.1 Closed Enumeration

Often it is necessary to restrict the allowable values of the associated instance data node to a closed list of alternatives.

Declaring a datatype allowing enumerated values of an xsd:string would be accomplished with the following in an external Schema:

<xsd:simpleType>
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="Mustercard"/>
    <xsd:enumeration value="Donor's Club"/>
    <xsd:enumeration value="World Express"/>
  </xsd:restriction>
</xsd:simpleType>

6.3.2 Open Enumeration

A special case of enumerated datatypes is the common form design pattern of a list, with an 'other, please specify' choice. This is referred to as an open enumeration.

Declaring an open enumeration is possible through a combination of union and enumeration features, with the following in an external Schema:

<xsd:simpleType>
  <xsd:union memberTypes="xsd:string">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="Mustercard"/>
        <xsd:enumeration value="Donor's Club"/>
        <xsd:enumeration value="World Express"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:union>
</xsd:simpleType>

6.3.3 Union

It may be desirable for data collection purposes to allow an instance data item to be a valid lexical value of one among several datatypes. Unions are defined in XML Schema.

Example Schema Syntax: declaring a datatype allowing either a creditCardType or bonusProgramType value would be accomplished with the following in a Schema:

<xsd:simpleType>
  <xsd:union memberTypes="creditCardType bonusProgramType"/>
</xsd:simpleType>

6.3.4 Lists

Some form controls, such as selectMany, have the notion of collecting more than one value at any given time. This corresponds to Schema list datatypes.

Declaring a list-derived datatype would be accomplished with the following in a Schema:

<xsd:simpleType name="listOfMyIntType">
  <xsd:list itemType="xsd:int"/>
</xsd:simpleType>

Note:

The pre-defined datatype xforms:listItems can also be used.

6.4 Binding

Binding is the glue that connects the separate pieces of XForms—directly associating nodes in the instance data with model item constraints.

Binding is specified via binding expressions, which select nodes from the instance data. The syntax and details of binding expressions are based on XPath, and defined in the chapter 7 XPath Expressions in XForms. This section describes the wider topic of how binding expressions are used within XForms.

6.4.1 bind

The bind element represents a node-set selected from the instance data. A series of attributes on the element correspond to individual XForms constraints to be applied to each node in the node-set.

Example: XML Representation: <bind>
<bind
  ref = binding-expression
  type = xsd:QName
  readOnly = model-item-constraint
  required = model-item-constraint
  relevant = model-item-constraint
  isValid = model-item-constraint
  calculate = model-item-constraint
  maxOccurs = xsd:nonNegativeInteger or "unbounded"
  minOccurs = xsd:nonNegativeInteger
>
  <!-- Content: (##empty) -->
</bind>

ref - A binding expression that selects which node or nodes have the associated constraints applied
type - reference to an in-scope Schema simpleType
readOnly - model item constraint
required - model item constraint
relevant - model item constraint
isValid - model item constraint
calculate - model item constraint
maxOccurs - model item constraint
minOccurs - model item constraint

Each bind element selects a node-set from the instance data, and applies the specified constraints. When additional nodes are added through the insert action, the newly added nodes are included in any node-sets matched by binding expressions.

6.4.2 Binding Constraints

Not every possible XPath expression is acceptable as a binding expression. The following constraints are placed upon binding expressions:

  1. No dynamic predicates. Predicates are permitted, but any predicates used must not alter the returned node-set based on other form settings. For example:

    permitted: elem
    permitted: elem[1]
    permitted: elem[last()]
    permitted: elem[@id="zip"]  if @id is not bound to a form control
    forbidden: elem[@attr="xy"]  if @attr is bound to a form control
    
  2. No dynamic variables. The XForms specification does not provide any variables.

  3. No invocation of any function that returns a node-set. Function calls are permitted, but not any that return a node-set.

  4. No invocation of any function with side-effects. All functions defined in the XForms specification are side-effect-free. Any extension functions should also be side-effect-free.

Upon detecting a binding expression that violates any of the above constraints, an form processing terminates with a fatal error.

6.4.3 Binding References

References to node-sets are attached to form controls through binding references, described in 8.12.2 Single Node Binding Attributes and 8.12.3 Nodeset Binding Attributes. Different attribute names, ref vs. nodeset, distinguish between a single node and a node-set respectively.

First node rule: When a single-node binding expression selects a node-set of size > 1, the first node in the node-set is used. This has no effect on the individual nodes nor the set of nodes selected by any particular bind element.

Consider a document with the following XForms declarations:

<xforms:model id="orders">
  <xforms:instance xmlns="">
    <orderForm>
      <shipTo>
        <firstName>John</firstName>
      </shipTo>
    </orderForm>
  </xforms:instance>
 <xforms:bind ref="/orderForm/shipTo/firstName"
          id="fn" type="xsd:string"
          required="true"/>
</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: UI Binding Using Explicit Model
<xforms:input model="orders" ref="/orderForm/shipTo/firstName">...

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.

Example: XForms Binding In Legacy HTML User Interface Controls
<html:input type="text" name="..." xforms:bind="fn"/>

7 XPath Expressions in XForms

XForms uses XPath to address instance data nodes in binding expressions, to express constraints, and to specify calculations.

7.1 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]. Elements and attributes in the instance data may have namespace information associated with them, as defined in the XPath Data Model. Unless otherwise specified, all instance data elements and attributes are unqualified. In addition, XForms processors must provide DOM access to this instance data via the interface defined below.

interface XFormsModelElement : org.w3c.dom.Element

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

Return value: org.w3c.dom.Document

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

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 binding expressions in XForms:

  1. The context node for outermost form control elements (such as XForms UI elements) is the XPath root (/). A " form control element" is any element other than bind that is explicitly allowed to have a binding expression attribute. A form control element is "outermost" when the node-set returned by the XPath expression ancestor::* includes no form control element nodes.

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

  3. The context node for the ref attribute on bind is the XPath root. The context node for other attributes of bind is the first node of the node-set returned from the binding expression in the sibling ref attribute.

  4. The context size and position are both exactly 1.

  5. No variable bindings are in place.

  6. The available function library is defined below.

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

Example: Binding Expression Context Nodes
<group ref="level1/level2/level3">
  <selectOne ref="elem" ... />
  <selectOne ref="@attr" ... />
</group>

In this example, the group has a binding expression of level1/level2/level3. According to the rules above, this outermost element would have a context node of /, which is the root of the instance data, or the parent to the elem element. Both of the selectOnes then inherit a context node from their parent, the context node being /level1/level2/level3. Based on this, the selectOne binding expressions evaluate respectively to /level1/level2/level3/elem and /level1/level2/level3/@attr. Matching instance data follows:

Example: Sample Instance
<level1>
  <level2>
    <level3 attr="xyz">
      <elem>xyz</elem>
    </level3>
  </level2>
</level1>

7.4 Forms 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 section defines a set of required functions for use within XForms.

7.4.1 Boolean Methods

7.4.1.1 boolean-from-string()

boolean boolean-from-string(string)

Function boolean-from-string returns true if the required parameter string is "true", or false if parameter string is "false". This is useful when referencing a Schema xsd:boolean datatype in an XPath expression. If the parameter string matches neither "true" nor "false", according to a case-insensitive comparison, processing stops with a fatal error.

7.4.1.2 if()

string if(boolean, string, string)

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

7.4.2 Number Methods

Note:

The XPath number datatype and associated methods and operators use IEEE specified representations. XForms Basic Processors are not required to use IEEE, and thus might yield slightly different results.

7.4.2.1 avg()

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

number min(node-set)

Function min returns the minimum value of the result of converting the string-values of 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.4.2.3 max()

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.4.2.4 count-non-empty()

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

number cursor( string )

Function cursor takes a string argument that is the idref of a repeat and returns the current position of the repeat cursor for the identified repeat—see 10.3 Repeating Structures for details on repeat and its associated repeat cursor. If the specified argument does not identify a repeat, this function throws an error.

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

7.4.3 String Methods

7.4.3.1 property()

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

string now()

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

8 Form Controls

XForms User Interface controls, also called form controls, are declared using markup elements, and their behavior refined via markup attributes. This markup may be further decorated with class attributes that can be used in CSS stylesheets to deliver a customized look and feel. XForms user interface controls are bound to the underlying instance data using binding attributes as defined in the chapter 6 Constraints.

Form controls enable accessibility by taking a uniform approach to such features as captions, help text, tabbing and keyboard shortcuts. Internationalization issues are addressed in conjunction with the Internationalization Working Group and are addressed by following the same design principles as in XHTML. All form controls are suitable for styling using Aural CSS (ACSS) style properties.

Form controls are as general and high-level as possible without sacrificing the ability to deliver real implementations. For instance, to select one or more items from a set, form controls selectOne and selectMany, are provided. Form controls distinguish the functional aspects of the underlying control, from the presentational aspects (through class attributes) and behavior (through XForms Action elements). 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.

For each form control, the following sections describe:

Description
Examples
Data Binding Restrictions


Implementation Requirements

XML Representation

XForms user interface controls use common attributes and elements that are defined later in this chapter (8.12 Common Markup ).

8.1 input

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

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

In the above, the class attribute (which are not defined in XForms but come from an external document type) can be used by a stylesheet 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 those).

Implementation Requirements: Must allow entry of a lexical value for the bound datatype. Implementations should provide the most convenient means possible 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 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 simple checkbox.

Example: XML Representation: <input>
<input
  (single node binding attributes)
  (common attributes)
  inputMode = xsd:string
>
  <!-- caption, (help|hint|alert|action|extension)* -->
</input>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
common attributes defined in 8.12.1 Common Attributes
inputMode - this form control accepts an input mode hint. B Input Modes

8.2 textarea

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.

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

In the above, the class attribute can be used by a stylesheet 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:

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.

Example: XML Representation: <textarea>
<textarea
  (single node binding attributes)
  (common attributes)
  inputMode = xsd:string
>
  <!-- caption, (help|hint|alert|action|extension)* -->
</textarea>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
common attributes defined in 8.12.1 Common Attributes
inputMode - this form control accepts an input mode hint. B Input Modes

8.3 secret

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.

Example: Password Entry
<secret ref="/login/password">
  <caption>Password</caption>
  <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.

Example: XML Representation <secret>
<secret
  (single node binding attributes)
  (common attributes)
  inputMode = xsd:string
>
  <!-- caption, (help|hint|alert|action|extension)* -->
</secret>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
common attributes defined in 8.12.1 Common Attributes
inputMode - this form control accepts an input mode hint. B Input Modes

8.4 output

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.

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 the most convenient means possible for display of datatypes and take into account localization and internationalization issues such as representation of numbers.

Example: XML Representation: <output>
<output
  (single node binding attributes)
>
  <!-- empty content -->
</output>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes

8.5 upload

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.

Example: Uploading An Image
<upload ref="mail/attach1" mediaType="image/*">
  <caption>Select image:</caption>
</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. , for all mediaTypes 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. when the mediaType is "image/*. Other mediaTypes besides image/png may share this input method.

    Note:

    Commonly, people have trouble drawing recognizable figures or signatures with a conventional pointing device like a mouse or track ball. Hence, a reasonable implementation of XForms might not want this feature, hence the "may" here for generic pointing devices

  • Implementations with specific audio recording capabilities should support record audio—in-place recording of an audio clip. when the mediaType is "audio/*" or "audio/basic" . Other mediaTypes besides "audio/basic" may share this input method.

  • Implementations with a digital camera/scanner interface or screen capture should support acquire image—in-place upload of images from an attached device. when the mediaType is "image/*" or "image/jpeg". Other mediaTypes besides "image/jpeg" may share this input method.

  • Implementations with video recording capability should provide a record video option. for video/* mediaTypes.

  • Implementations with 3d capabilities should provide a 3d interface option for model/* mediaTypes.

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

Example: XML Representation: <upload>
<upload
  (single node binding attributes)
  (common attributes)
  mediaType = list of content types
>
  <!-- caption, (help|hint|alert|action|extension)* -->
</upload>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
common attributes defined in 8.12.1 Common Attributes
mediaType - list of suggested media types, used by the XForms Processor to determine which input methods apply.

8.6 range

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

Example: Picking From A Range
<range ref="/stats/balance" start="-2.0" end="2.0" stepSize="0.5">
  <caption>Balance</caption>
</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.

Issue (enum-range):

Should an enumeration be allowed to bind to this form control? If yes, how should it be ordered?

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, when using an accessibility aid. Thus, 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: XML Representation: <range>
<range
  (single node binding attributes)
  (common attributes)
  start = datavalue
  end = datavalue
  stepSize = datavalue-difference
>
  <!-- caption, (help|hint|alert|action|extension)* -->
</range>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
common attributes defined in 8.12.1 Common Attributes
start - optional hint for the lexical starting bound for the range, of the same datatype bound to the form control
end - optional hint for the ending bound for the range, of the same datatype bound to the form control
stepSize - optional hint to use for incrementing or decrementing the value within the form control, of a datatype that can express the difference between two values of the datatype bound to the form control

8.7 button

Description: This form control is similar to the HTML element of the same name and allows for user-triggered actions. This form control may also be used to advantage in realizing other custom form controls.

Example:

Example: Simple Button
<button>
  <caption>Click here</caption>
</button>

Data Binding Restrictions: Binding not possible for this form control.

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 caption on the button face. Stylesheets can be used to style the button as an image.

Example: XML Representation: <button>
<button
  (common attributes)
>
  <!-- caption, (help|hint|alert|action|extension)* -->
</button>

common attributes defined in 8.12.1 Common Attributes

8.8 submit

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

Example:

Example: Submit
<submit submitInfo="timecard">
  <caption>Submit Timecard</caption>
</submit>

Data Binding Restrictions: Binding not possible for this form control.

Implementation Requirements: Upon receiving event xforms:activate, this form control dispatches an xforms:submit event to the indicated element submitInfo. If no attribute submitInfo is specified, the first element submitInfo, in document order, is used.

Example: XML Representation: <submit>
<submit
  (common attributes)
  submitInfo = xsd:IDREF
>
  <!-- caption, (help|hint|alert|action|extension)* -->
</submit>

submitInfo
- Required reference to element submitInfo
common attributes defined in 8.12.1 Common Attributes

8.9 selectOne

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

Example: Pick A Flavor
<selectOne ref="my:icecream/my:flavor">
  <caption>Flavour</caption>
  <item>
    <caption>Vanilla</caption>
    <value>v</value>
  </item>
  <item>
    <caption>Strawberry</caption>
    <value>s</value>
  </item>
  <item>
    <caption>Chocolate</caption>
    <value>c</value>
  </item>
</selectOne>

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. The value given in the user interface shown above may be used in constructing a default schema for the data item being populated if no schema is provided by the XForms author.

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

listbox checkbox radio menu
a list control, Vanilla, Strawberry, and Chocolate visible; Strawberry selected checkboxes, Vanilla, Strawberry, Chocolate; Chocolate is selected radio buttons, Vanilla, Strawberry, Chocolate; Strawberry is selected a collapsed pull-down list; Vanilla is selected

Data Binding Restrictions: Binds to any simpleContent.

Implementation Requirements: The caption 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. In this case, control selectOne may have attribute selection="open". The form control should then allow free data entry, as described in 8.1 input.

If the initial instance value matches none of the possible storage values of given items, and selection is set to closed, the first item is selected. Otherwise, the first matching item is selected.

For open selections: If the initial instance value matches none of the possible storage values of given items, the selected value is the initial lexical value. Otherwise, the first matching item is selected. Free entry text is handled the same as form control input 8.1 input.

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

Typically, a stylesheet would be used to determine the exact appearance of form controls, though a means is provided to suggest an appearance through an attribute. The value of the attribute consists of one of the following values, each of which may have a platform-specific look and feel.

radio
checkbox
menu
listbox

Example: XML Representation: <selectOne>
<selectOne
  (single node binding attributes)
  (common attributes)
  selectUI = ("radio" | "checkbox" | "menu" | "listbox" )
  selection = "open" | "closed" : "closed"
> 
  <!-- caption, (choices|item|itemset)+, (help|hint|alert|action|extension)* -->
</selectOne>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
common attributes defined in 8.12.1 Common Attributes
selectUI - appearance override

selection
- optional attribute determining whether free entry is allowed in the list.

8.10 selectMany

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

Example: Selecting Ice Cream Flavor
<selectMany ref="my:icecream/my:flavors">
  <caption>Flavours</caption>
  <choices>
    <item>
      <caption>Vanilla</caption>
      <value>v</value>
    </item>
    <item>
      <caption>Strawberry</caption>
      <value>s</value>
    </item>
    <item>
      <caption>Chocolate</caption>
      <value>c</value>
    </item>
  </choices>
</selectMany>

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

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

listbox checkbox radio menu
list-box; Vanilla, Strawberry, and Chocolate visible; Strawberry and Chocolate selected checkboxes, Vanilla, Strawberry, and Chocolate; Strawberry and Chocolate selected This configuration is not recommended. A popup menu with three choices, 'Strawberry', 'Vanilla', and 'Chocolate'. The last two are checked.

Data Binding Restrictions: any simpleContent capable of holding a sequence.

Note:

A limitation of the 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.

Example: XML Representation: <selectMany>
<selectMany
  (single node binding attributes)
  (common attributes)
  selectUI = ("radio" | "checkbox" | "menu" | "listbox")
>
  <!-- caption, (choices|item|itemset)+, (help|hint|alert|action|extension)* -->
</selectMany>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
common attributes defined in 8.12.1 Common Attributes
selectUI - appearance override

8.11 Common Markup for selection controls

8.11.1 choices

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

Example: XML Representation: <choices>
<choices>
  <!-- caption?, (choices|item)+ --> 
</choices>

8.11.2 item

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

Example: XML Representation: <item>
<item> 
  <!-- caption, value, (help|hint|alert|action|extension)* -->
</item>

id = xsd:ID - optional unique identifier.


value = lexical-representation - the "storage value" for the item, to be placed in the instance data when this item is chosen.


8.11.3 itemset

Element itemset allows the creation of dynamic selections within controls selectOne and selectMany, where the available choices are determined at run-time. The node-set that holds the available choices is specified via attribute nodeset. Child elements caption and value indirectly specify the caption and storage values. Notice that the run-time effect of itemset is the same as using element choices to statically author the available choices.

Example: XML Representation: <itemset>
<itemset
  (node-set binding attributes)
> 
  <!-- caption, value, (help|hint|alert|action|extension)* -->
</itemset>

node-set binding attributes - required node-set selector that specifies the node-set holding the available choices.

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

Example: Dynamic Choice Of Ice Cream Flavors
<model id="cone">
  <instance>
    <my:icecream>
      <my:flavours/>
    </my:icecream>
  </instance>
</model>
<model id="flavours">
  <instance>
    <my:flavours>
      <my:flavour type="v">
        <my:description>Vanilla</my:description>
      </my:flavour>
      <my:flavour type="s">
        <my:description>Strawberry</my:description>
      </my:flavour>
      <my:flavour type="c">
        <my:description>Chocolate</my:description>
      </my:flavour>
    </my:flavours>
  </instance>
</model>
<!-- user interaction markup -->
<selectMany model="cone" ref="my:icecream/my:flavours">
  <caption>Flavors</caption>
  <itemset model="flavours" nodeset="my:flavours/my:flavour">
    <caption ref="my:description"/>
    <value ref="@type"/>
  </itemset>
</selectMany>

8.11.4 value

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

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

Example: XML Representation: <value>
<value
  (single node binding attributes)
>
  <!-- ##any -->
</value>

single node binding attributes - optional binding selector that specifies a location from where the storage value is to be fetched.

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

8.11.5 itemref

This element is used within the selection form controls to represent a single item of the list, where the following conditions apply:

There is an XForms Model available
And the author wishes to point at a node in an instance tree where the choice is stored. This element is also used when authoring forms where the available choices are only known at runtime.

Notice that in the case where element itemref is used, the storage value does not have the limitations that exist when using element item.

Note:

Form authors should be aware that instance data selected by is directly placed into the instance data. For example selecting an element node with /node makes the entire node element the storage value, while an expression such as /node/text() selects just the text content. Combinations that produce mixed content in the instance data are forbidden.

Example: XML Representation: <itemref>
          
<itemref id = xsd:ID
         ref = xpath-expression > 
  <!-- unordered: (caption, help?, hint?, alert?, action?) -->
</itemref>

id = xsd:ID - optional unique identifier.
ref = xpath-expression - XPath locator of the the "storage value" for the item, to be placed in the instance data when this item is chosen.

8.12 Common Markup

The preceding form control definitions make reference to child elements and attributes that are common to several of the form controls. This section defines these common markup components.

8.12.1 Common Attributes

The following attributes are common to many user-interface related XForms elements.

Example: XML Representation: Common Attributes
xml:lang = xsd:language
class = space separated list of classes
navIndex = xsd:nonNegativeInteger : 0
accessKey = xsd:token

xml:lang - Optional standard XML attribute to specify a human language for this element.
class - Optional selector for a style rule.
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 11 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.

CSS properties for controlling the look and feel of XForms user interface controls are being defined in conjunction with the CSS Working Group. The CSS Working Group has agreed to help us develop a default CSS stylesheet capable of producing the sample default renderings illustrated in this working draft. The results of the above will be used to document the use of CSS properties within XForms user interface elements for the final version of the XForms specification.

8.12.2 Single Node Binding Attributes

The following attributes define a binding between a form control and an instance data node.

Example: XML Representation: Single Node Binding Attributes
ref = binding-expression
model = xsd:IDREF
bind = xsd:IDREF

ref - Binding expression. Details in the chapter 6 Constraints. The first-node rule applies to the nodeset selected here.

model
- Optional instance data selector. Details in the section 6.4.3 Binding References.
bind - Optional reference to a bind element

It is an error if the model idref value refers to an id not on a model element, or if the bind idref value refers to an id not on a bind element.

8.12.3 Nodeset Binding Attributes

The following attributes define a binding between a form control and a node-set returned by the XPath expression.

Example: XML Representation: Nodeset Binding Attributes
nodeset = binding-expression
model = xsd:IDREF
bind = xsd:IDREF

nodeset - Binding expression. Details in the chapter 6 Constraints.

model
- Optional instance data selector. Details in the chapter 6 Constraints.
bind - Optional reference to a bind element

It is an error if the model idref value refers to an id not on a model element, or if the bind idref value refers to an id not on a bind element.

8.12.4 Common Child 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 caption, the metadata can be pointed to by using a simple XLink attribute xlink: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 caption elements

  • Finally, an XForms processor can 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.12.4.1 caption

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

Example: XML Representation: <caption>
<caption
  (common attributes)
  (single node binding attributes)
  xlink:href = xsd:anyURI
>
  <!-- ##any -->
</caption>

common attributes - defined in 8.12.1 Common Attributes
single node binding attributes - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
xlink:href = xsd:anyURI - link to external caption

The caption specified can exist in instance data, in a remote document, or as inline text. If multiple captions are specified in this element, the order of preference is: ref, xlink:href, inline.

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

8.12.4.2 help

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

Example: XML Representation: <help>
<help
  (common attributes)
  (single node binding attributes)
  xlink:href = xsd:anyURI
>
  <!-- ##any -->
</help>

(common attributes) - defined in 8.12.1 Common Attributes
single node binding attributes - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
xlink:href = xsd:anyURI - link to external help

The message specified can exist in instance data, in a remote document, or as inline text. If multiple captions are specified in this element, the order of precedence is: ref, xlink:href, inline.

8.12.4.3 hint

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

Example: XML Representation: <hint>
<hint 
  (common attributes)
  (single node binding attributes)
  xlink:href = xsd:anyURI
>
  <!-- ##any -->
</hint>

(common attributes) - defined in 8.12.1 Common Attributes
single node binding attributes - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
xlink:href = xsd:anyURI - link to external hint

The message specified can exist in instance data, in a remote document, or as inline text. If multiple captions are specified in this element, the order of precedence is: ref, xlink:href, inline.

8.12.4.4 alert

The optional element alert provides a convenient way to attach alert or error information to a form control. This is equivalent to a xforms:alert event handler that responds with a <message type="modal">.

Example: XML Representation: <alert>
<alert
  (common attributes)
  (single node binding attributes)
  xlink:href = xsd:anyURI
>
  <!-- ##any -->
</alert>

(common attributes) - defined in 8.12.1 Common Attributes
single node binding attributes - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
xlink:href = xsd:anyURI - link to external alert

The message specified can exist at in instance data, in a remote document, or as inline text. If multiple captions are specified in this element, the order of precedence is: ref, xlink:href, inline.

8.12.4.5 extension
Example: XML Representation: <extension>

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

<extension>
  <!-- ##other -->
</extension>

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

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

9 XForms Actions

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.

NOTE: This example is based on the XML Events specification [XML Events], which is proceeding independently from XForms, and thus might be slightly incorrect.

Example: Action Syntax
<xforms:button>
  <xforms:caption>Reset</xforms:caption>
  <xforms:resetInstance ev:event="xforms:activate"/>
</xforms:button>

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

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

Name
Description of behavior
XML Representation
Sample usage

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

9.1 dispatch

This action explicitly dispatches an XForms Event to a specific element identified by the target attribute.

Example: XML Representation: <dispatch>
<dispatch
  name = xsd:NMTOKEN
  target = xsd:IDREF
  bubbles = xsd:boolean : true
  cancelable = xsd:boolean : true
/>

name = xsd:NMTOKEN
- required name of the event\ to dispatch.
target = xsd:IDREF - required reference to the event target.
bubbles = xsd:boolean : true
- boolean indicating if this event bubbles—as defined in DOM2 events.
cancelable = xsd:boolean : true
- boolean indicating if this event is cancelable—as defined in DOM2 events.

For events defined in the XForms specification, attributes bubbles and cancelable have no effect, since these event properties are defined in chapter 11 Processing Model.

9.2 refresh

This action dispatches an xforms:refresh event.

Example: XML Representation: <refresh>
<refresh/>

9.3 recalculate

This action dispatches an xforms:recalculate event.

Example: XML Representation: <recalculate>
<recalculate/>

9.4 revalidate

This action dispatches an xforms:revalidate event.

Example: XML Representation: <revalidate>
<revalidate/>

9.5 setFocus

This action explicitly sets focus to the form control referenced by the idref attribute by dispatching an xforms:focus event. Note that this event is implicitly invoked to implement XForms accessibility features such as accessKey.

Example: XML Representation: <setFocus>
<setFocus
  idref = xsd:IDREF
/>

idref = xsd:IDREF - required reference to a form control

Setting focus to a repeating structure sets the focus to the member represented by the repeat cursor.

9.6 loadURI

This action performs an XLink traversal.

Example: XML Representation: <loadURI>
<loadURI
  (single node binding attributes)
  xlink:href = xsd:anyURI
  xlink:show = ("new" | "replace" | "embed" | "other" | "none")
/>

(single node binding attributes) - Selects the instance data node containing the URI.
xlink:href - optional URI to load.
xlink:show - optional link behavior specifier.

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

Possible values for attribute xlink: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.

embed

The document is incorporated into the current window in an application-specific manner. Form processing continues.

other

The document is loaded in an application-specific manner. The application should look for other markup present in the link to determine the appropriate behavior.

none

The document is loaded in an application-specific manner. The application should not look for other markup present in the link to determine the appropriate behavior.

9.7 setValue

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

Example: XML Representation: <setValue>
<setValue
  (single node binding attributes)
  value = XPath expression
>
  <!-- literal value -->
</setValue>

(single node binding attributes) - Selects the instance data node where the value is to be stored.
value = XPath expression - 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 ("").

9.8 submitInstance

This action explicitly initiates submit processing by dispatching an xforms:submit event.

Example: XML Representation: <submitInstance>
<submitInstance
  submitInfo = xsd:IDREF
/>

id = xsd:ID - optional unique identifier.


submitInfo = xsd:IDREF - optional reference to a submitInfo element.


Note:

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

<dispatch target="mysubmitinfo" name="submitInstance"/>

9.9 resetInstance

This action explicitly initiates reset processing by dispatching an xforms:reset event.

Example: XML Representation: <resetInstance>
<resetInstance
  model = xsd:IDREF
/>

model = xsd:IDREF
- Selection of instance data for reset,defined at 8.12.3 Nodeset Binding Attributes

9.10 setRepeatCursor

This action marks a specific item as current in a repeating sequence (within 10.3 Repeating Structures).

Example: XML Representation:Action <setRepeatCursor>
<setRepeatCursor
  repeat = xsd:IDREF
  cursor = XPath expression that evaluates to number
/>

repeat = xsd:IDREF - required reference to a repeat

cursor = XPath expression that evaluates to number
- required 1-based offset into the sequence.

Platform-specific user actions for selecting e.g., mouse focus, implicitly invoke handler setRepeatCursor on the item that got the selection.

9.11 insert

This action copies nodes from the containing document into the instance data. Any nodes of type xsd:ID are not copied.

The rules for insert processing are as follows:

  1. A new node-set is created by evaluating the node-set binding attributes against the containing document child nodes of instance.

  2. The last node of this node-set is deep copied into the instance data, such that the inserted node appears immediately before or after (depending on the value of attribute position) the n-th node in the node-set returned by evaluating the node-set binding attributes against the instance data, where n represents the number returned from node-set index evaluation, below.

Note:

The XForms Action setValue can be used in conjunction with insert to provide specific initial values for the newly inserted nodes.

The rules for selecting a node-set 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 operation has no effect.

  3. If the result is not a valid index for the node-set, it is clipped to the either 1 or the size of the node-set, whichever is closer.

This action results in the insertion of model items to the XForms Model. These model items should be constructed by re-evaluating any necessary bindings and applying the XForms Constraints in scope for each node. When used with repeating structures 10.3 Repeating Structures, this causes the instantiation of the necessary user interface for populating a new entry in the underlying collection.

Example: XML Representation:Action <insert>
<insert
  (node-set binding attributes)
  at = XPath expression
  position = "before" | "after"
/>

(nodeset binding attributes)
- Selection of instance data nodes, defined at 8.12.3 Nodeset Binding Attributes
at
- required XPath expression evaluated to determine insert location.
position
- required selector if insert before/after behavior.

An example of using insert with a repeating structure is located at 10.3 Repeating Structures.

9.12 delete

This action deletes nodes from the instance data.

The rules for delete processing are as follows:

  1. A node-set is produced by evaluating the node-set binding attributes against the instance data.

  2. The n-th node is deleted from the instance data, where n represents the number returned from node-set index evaluation, defined in 9.11 insert.

This action results in the deletion of model items to the XForms Model. These model items should be deleted by re-evaluating any bindings that refer to the nodes being deleted. When used with repeating structures, this causes the destruction of the necessary user interface for populating the entry at the current cursor position in the underlying collection.

Example: XML Representation:Action <delete>
<delete
  (node-set binding attributes)
  at = XPath expression
/>

(nodeset binding attributes)
- Selection of instance data nodes, defined at 8.12.3 Nodeset Binding Attributes
at
- XPath expression evaluated to determine insert location.

An example of using delete with a repeating structure is located at 10.3 Repeating Structures.

9.13 toggle

This action selects one possible choice from an exclusive list e.g., within 10.2 Conditional Constructs For Dynamic User Interfaces, by dispatching an xforms:toggle event.

Example: XML Representation: Action <toggle>
<toggle
  case = xsd:IDREF
/>

case = xsd:IDREF - required reference to a case section inside the conditional construct

The toggle action adjusts all selected attributes on the affected cases to reflect the new state.

9.14 script

This action executes script.

Example: XML Representation: Action <script>
<script
  type = xsd:string
>
  <!-- #CDATA -->
</script>

type = xsd:string
- required mime-type identifier of scripting language used


9.15 message

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

Example: XML Representation: <message>
<message
  (single node binding attributes)
  xlink:href = xsd:anyURI
  level = "ephemeral" | "modeless" | "modal"
>
  <!-- mixed content -->
</message>

(single node binding attributes) - optional attributes that point to the instance data for a string message.
xlink:href = xsd:anyURI - optional specifier of an external resource for the message.
level - required message level identifier.

The message specified can exist in instance data, in a remote document, or as inline text. If multiple captions are specified in this element, the order of preference is: ref, xlink:href, inline.

A graphical browser might render an ephemeral message as follows:

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

A graphical browser might render a modeless message as follows:

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

A graphical browser might render a modal message as follows:

an alert popup , with a helpful error message.

9.16 action

This element can be used to bind XForms Actions to form controls and group them around a common event handler.

Example: XML Representation: <action>
<action
>
  <!-- Action handlers -->
</action>

10 XForms User Interface

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

All form controls defined in 8 Form Controls are treated as individual inline 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.

10.1 Grouping Form Controls

The group element is used as a container for defining a hierarchy of form controls. Groups can be nested to create complex hierarchies.

Example: XML Representation: <group>
<group
  (single node binding attributes)
  (common attributes)
>
  <!-- caption?, ##all -->
</group>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
(common attributes) - defined in 8.12.1 Common Attributes

In CSS-based layout systems, groups lay out their children using a constraint-based system that supports both relative flexible sizing and intrinsic sizing. Through CSS, an inline box can be specified using the display property with a value of inline. A block-level group can be specified with a value of block, which is the default.

Example: Grouping Related Controls
<group ref="address">
  <caption>Shipping Address</caption>
  <input ref="line_1" >
    <caption>Address line 1</caption>
  </input>
  <input ref="line_2" >
    <caption>Address line 2</caption>
  </input>
  <input ref="postcode">
    <caption>Postcode</caption>
  </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 tabbing order within that group.

10.2 Conditional Constructs For Dynamic User Interfaces

The XForms User Interface allows the authoring of dynamic user interfaces, i.e., user interfaces that vary based on the current state of the instance data being populated. 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?'. Another use case for such dynamic user interfaces is when the underlying XForms Model contains conditional structures.

This element contains one or more case elements. Each case has an id attribute that is used within event handlers appearing within form controls to activate or deactivate that portion of the user interface created by the markup contained within that case element.The attribute selected provides an initial selected case, as well as provides access to the currently selected case, through live updates to the attribute values in the containing document. This example shows how to provide a conditional user interface.

Example: switch
<switch id="sw">
  <case id="in" selected="true">
    <input ref="yourname">
      <caption>Please tell me your name</caption>
    </input>
  </case>
  <case id="out" selected="false">
    <html:p>Hello <output ref="yourname" />.</html:p>
  </case>
</switch>

The above results in the portion of the user interface contained in the first the case being initially displayed. The XForms Action toggle activates and deactivates different portions of this conditional construct.

Example: XML Representation: <switch>
<switch
  (single node binding attributes)
  (common attributes)
>
  <!-- case+ -->
</switch>

(single node binding attributes) - Selection of instance data node, defined at 8.12.2 Single Node Binding Attributes
(common attributes) - defined in 8.12.1 Common Attributes

default = xsd:IDREF
- optional selector for initial case.

Example: XML Representation: <case>
<case
  selected = xsd:boolean
>
  <!-- ##any -->
</case>

selected = xsd:boolean
- optional selection status for the case.

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.

Issue (issue-switch-scroll):

In addition to toggle, the XForms Action scroll might be used within switch to cycle through the various contained case clauses.

10.3 Repeating Structures

The XForms Model allows the definition of repeating structures such as multiple items being purchased within a purchase order. When defining the XForms Model, such higher-level aggregations are constructed out of basic building blocks; similarly, this section defines higher-level user interface constructs that build on the form controls defined previously that can bind to data structures such as lists and collections. Element repeat encapsulates a UI mapping over a homogeneous collection, in other words, a collection consisting of data items having the same type and structure.

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

Note that controls for adding or removing repeating entries may appear within the repeat, (causing the add/remove controls themselves to repeat), or may appear outside the repeat.

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 (assuming four item elements in the returned node-set):

<!-- 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 model item for the collection being populated would typically have defined attributes 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. Event listeners separately control UI aspects such as scrolling and insertion. This specification does not specify normative means for displaying such add and delete controls; as with the rest of the XForms User Interface design, these are left to be flexible while showing a default presentation.

<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">
    <caption>Line Item</caption>
  </input>
  <input ref="@name">
    <caption>Name</caption>
  </input>
</repeat>

<button>
  <caption>Insert a new item after the current one</caption>
  <action ev:event="ev:activate">
    <insert nodeset="my:lines/my:line"
            at="cursor('lineset')"
            position="after"/>
    <setValue ref="my:lines/my:line[cursor('lineset')]/@name"/>
    <setValue ref="my:lines/my:line[cursor('lineset')]/price">0.00</setValue>
  </action>  
</button>

<button>
  <caption>remove current item</caption>
  <delete ev:event="ev:activate" nodeset="my:lines/my:line"
          at="cursor('lineset')"/>
</button>
Example: XML Representation: <repeat>
<repeat
  (node-set binding attributes)
  (common attributes)
  startIndex = xsd:positiveInteger : 1
  number = xsd:nonNegativeInteger
>
  <!-- ##any -->
</repeat>

(nodeset binding attributes) - Selection of context node-set, defined at 8.12.3 Nodeset Binding Attributes
(common attributes) - defined in 8.12.1 Common Attributes
startIndex - 1-based hint to the XForms Processor as to which starting element from the collection to display.
number - hint to the XForms Processor as to how many elements from the collection to display.

10.3.1 Repeat Processing

The user interface markup for repeating structures adds encapsulation metadata about the collection being populated. Processing for repeating structures takes into account a cursor that points to a current item in the data instance. This cursor is used as a reference point for insert and delete XForms Actions. These, along with cursor, can be thought of as the markup equivalent of limited DOM access to the XML instance being populated.

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. But as a consequence, the user interface cannot bind to an element from the underlying collection out of sequence except by using an absolute XPath expression.

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

Repeat processing uses XPath expressions to address the collection over which element repeat operates. The XPath expression used as the value of attribute nodeset must select a node-set 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 other XPath node-sets is undefined.

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. The form controls appearing inside repeat need to be suitable for populating individual items of the collection.

The XForms Actions enumerated at 9 XForms Actions may be used within event listeners attached to button elements placed inside the body of construct repeat. In combination with the facilities provided by element group and CSS layout, this allows document authors to customize the positioning of controls for standard actions such as insert or delete.

10.3.2 User Interface Interaction

As specified, element repeat allows us to bind a user interface to a dynamic homogeneous collection.

The number of displayed items might be less than the total number available. In such a case, the presentation would only render a portion of the repeating items at a given time. For example, a graphical user interface might present a scrolling table. The attributes startIndex and number provide hints to the user interface as to which elements should be displayed initially. The current item indicated by the repeat cursor should be presented at all times, for example, not allowed to scroll out of view.

11 Processing Model

Note:

This chapter has undergone significant revision since last publication. The diff-marked version of this chapter does not include indications of changes, due to the large amount of new material.

This chapter defines the XForms processing model declaratively, i.e., describing the various states attained by an XForms processor, and the possible state transitions that exist with respect to each of these states. In defining these states and state transitions, this 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.

The XForms processing model consists of the following three phases:

Each of these phases is further subdivided as explained in detail in subsequent sections of this chapter. State transitions in the processing model occur when specific events are received, and the event handler that processes the event determines the new state.

11.1 Events Overview

Thus, XForms processing is defined in terms of events, event handlers, and event responses. XForms uses the events system defined in [DOM2 Events], with a event Capture phase, arrival of the event at its Target, and finally the event Bubbling Phase.

Event name Cancelable? Bubbles? Target element
11.2 Initialization Events
modelConstruct No No model
modelInitialize No No model
initializeDone No No model
UIInitialize No No model
formControlInitialize No No model
11.3 Interaction Events
previous Yes Yes form control
next Yes Yes form control
focus Yes Yes form control
blur Yes Yes form control
activate Yes Yes form control
valueChanging Yes Yes form control
valueChanged Yes Yes form control
scrollFirst Yes Yes repeat
scrollLast Yes Yes repeat
insert No Yes instance
delete Yes Yes instance
select Yes Yes form control or switch
deselect Yes Yes form control or switch
help Yes Yes form control
hint Yes Yes form control
alert Yes Yes form control
valid No Yes form control
invalid No Yes form control
refresh Yes Yes model
revalidate Yes Yes form control or model
recalculate Yes Yes model
reset Yes Yes model
11.4 XForms Submit
submit Yes Yes submitInfo
11.5 Error Indications
schemaConstraintsError No Yes model
traversalError No Yes model
invalidDatatypeError No Yes model

Note:

Events editorial whiteboard:

If the submit event targets submitInfo (which seems reasonable), we should allow XForms Actions as children of <submitInfo>.

Did we get rid of destruct? I couldn't find a reference either way.

11.2 Initialization Events

This section defines the various stages of the initialization phase.The processing application begins initialization by dispatching an event xforms:modelConstruct to each XForms Model in the containing document.

11.2.1 xforms:modelConstruct

Dispatched in response to: XForms Processor initialization.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

  1. Schema is loaded, if any.

  2. An XPath data model is constructed from the instance data, according to the following rules:

    1. From an external source

    2. If there is no reference to an external instance, from an inline instance

    Note:

    If neither of these are supplied, the instance is constructed from the user interface, during user interface construction.

  3. Following this, an xforms:modelInitialize event is dispatched to element model.

11.2.2 xforms:modelInitialize

Dispatched in response to: completion of xforms:modelConstruct processing.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

  1. The instance data has been structurally validated against the Schema, if any. If structural validation fails, all XForms processing for this containing document halts.

  2. If applicable, P3P has been initialized. [P3P 1.0]

  3. The instance data has been constructed.

  4. The xforms:initializeDone event is dispatched to the model element after initialization of that model element is completed but before rendering of the UI has started.

  5. After all XForms Models are initialized, the host must dispatch an xforms:UIInitialize event to each model element.

11.2.3 xforms:initializeDone

Dispatched in response to: xforms:modelInitialize processing.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

11.2.4 xforms:UIInitialize

Dispatched in response to: XForms Processor user interface initialization.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

The host processor traverses the containing document, and for each form control, dispatches a xforms:formControlInitialize event to the form control.

11.2.5 xforms:formControlInitialize

Dispatched in response to: xforms:UIInitialize processing.

Target: model

Bubbles: No

Cancelable: No

Context Info: None

Default processing for this event results in the following:

If the referenced model contains doesn't have instance data, it is created by following the rules for default instance data.

@@@text here on default XForms Model construction.

11.3 Interaction Events

11.3.1 DOM Mutation Events

Dispatched in response to: any change in the instance data.

Target: instance data node

Bubbles: Yes

Cancelable: No

Context Info: varies

In implementations that support the DOM, standard DOM mutation events should be dispatched to the changing target nodes whenever the instance data changes. Note that script, using the method getInstanceDocument() and a tree-walk, is required to associate event handlers with the instance data.

11.3.2 xforms:next and xforms:previous

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

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

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

Navigation is determined on a containing document-wide basis. The basic unit of navigation is the form control. The <group>, <repeat>, and <switch> structures also serve as navigation units, but instead of providing a single navigation point, they create a local navigation context for child form controls (and possibly other substructures). The navigation sequence is determined as follows:

  1. Those navigation units that support navIndex and assign a positive value to it are navigated first.

    1. Outermost navigation units are navigated in increasing order of the navIndex value. Values need not be sequential nor must they begin with any particular value. Navigation units that have identical navIndex values are be navigated in document order.

    2. Ancestor navigation units establish a local navigation sequence. All navigation units within a local sequence are navigated, in increasing order of the navIndex value, before any outside the local sequence are navigated. Navigation units that have identical navIndex values are navigated in document order.

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

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

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

11.3.3 xforms:focus and xforms:blur

Dispatched in response to: a form control gaining or losing focus through any means.

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for these events results in the following: None; notification events only.

Editorial note  
Do these events apply also to group, switch, and repeat?

11.3.4 xforms:activate

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.

11.3.5 xforms:valueChanging

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

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

Certain form controls allow 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). Interactive temporary values such as this are expressly allowed to be "invalid", that is outside the permissible value space. This is because incomplete data may be present while the user is entering transitional values.

Example: A partially entered credit card value of "3" is not valid because it doesn't (yet) have enough characters. This is permitted temporarily, as long as the user remains on the form control. XForms Full Processors would update/refresh on every character. XForms Basic Processors would typically only update/refresh on the final value.

Default processing for this event results in the following:

  1. If the partial value meets all validity constraints, it is reflected in the instance data. If not, the instance data remains as it was before processing this event.

  2. Event recalculate has been dispatched to element model.

  3. Event refresh has been dispatched to element model.

Implementations that choose to implement valueChanging are expected optimize processing (for instance not flashing the entire screen for each character entered, etc.).

Note:

XForms Basic processors are not required to generate or respond to these events.

11.3.6 xforms:valueChanged

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

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for this event results in the following:

  1. The value from the form control is reflected in the instance data.

  2. Event revalidate has been dispatched to element model.

  3. Event recalculate has been dispatched to element model.

  4. Event refresh has been dispatched to element model.

11.3.7 xforms:scrollFirst

Dispatched in response to: a repeat view is scrolled past the beginning of the repeat items.

Target: repeat

Bubbles: Yes

Cancelable: Yes

Context Info: None

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

11.3.8 xforms:scrollLast

Dispatched in response to: a repeat view is scrolled past the end of the repeat items.

Target: repeat

Bubbles: Yes

Cancelable: Yes

Context Info: None

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

11.3.9 xforms:insert and xforms:delete

Dispatched in response to: A event handler invoking an XForms Action insert or delete.

Target: instance

Bubbles: Yes

Cancelable: No

Context Info: Path expression used for insert/delete.

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

11.3.10 xforms:select and xforms:deselect

Dispatched in response to: an item in a selectOne, selectMany, or switch becoming selected or deselected.

Target: form control or switch

Bubbles: Yes

Cancelable: Yes

Context Info: None

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

11.3.11 xforms:help and xforms:hint

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

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for these events results in the following: None; notification event only. User agents may provide default help or hint messages.

11.3.12 xforms:alert

Dispatched in response to: a form control failing validation.

Target: form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for this event results in the following: An error message displayed, informing the user of the action needed to make the form control valid.

11.3.13 xforms:valid

Dispatched in response to: a form control becoming valid with respect to the bound instance data.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

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

11.3.14 xforms:invalid

Dispatched in response to: a form control becoming invalid with respect to the bound instance data.

Target: form control

Bubbles: Yes

Cancelable: No

Context Info: None

Default processing for this event results in the following:

  • Event alert is dispatched to the the form control.

11.3.15 xforms:refresh

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 will reflect the state of the model. This means:

  • All form controls show the current value corresponding to the bound instance data.

  • All form controls show the validity state of the corresponding bound instance data.

  • Any form control associated with a model item property relevant evaluating to false is disabled/hidden/etc.

11.3.16 xforms:revalidate

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

Target: model or a form control

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for this event results in the following:

Revalidation may occur targeted to a context form control. The default handling for this event must satisfy the following conditions:

  1. The bound instance data node is checked against any bound Schema Constraints. If any fail, the context form control is considered invalid.

  2. The bound instance data node is checked against any bound XForms Constraints. If any fail, the context form control is considered invalid.

  3. If the context form control is invalid, the XForms Processor must dispatch event invalid to the context form control. Otherwise, event valid must be dispatched to the form control.

When element model is targeted by this event, the above is applied to every form control in document order.

11.3.17 xforms:recalculate

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:

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.

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

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

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

  4. Finally, if a compute is part of a circular dependency and also computationally dependent on an element in L, then an XForms processor MUST report an exception.

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

11.3.18 xforms:reset

Dispatched in response to: a user request to reset the instance data.

Target: model

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for this event results in the following:

  1. All of the instance data is selected for resetting.

  2. New instance data for the selected instance data is prepared, based on the instance element associated with the current model element, according to the rules for initialization above.

  3. The selected instance data is replaced with the new instance data.

11.4 XForms Submit

Form filling experience ends with submitting the form, or perhaps starting over. The XForms processing for these events are covered here. The following sections describe how the instance data is prepared for submission.

11.4.1 xforms:submit

Dispatched in response to: a user request to submit the instance data.

Target: submitInfo

Bubbles: Yes

Cancelable: Yes

Context Info: None

Default processing for this event results in the following:

  1. A node from the instance data is selected, based on the attribute ref on element submitInfo. This node and all child nodes, are considered for the remainder of the submit process.

  2. All selected instance data is revalidated. Any invalid instance data stops submit processing.

  3. Selected instance data is serialized according to one of the processes defined below, as indicated by element submitInfo attributes mediaType and mediaTypeExtension. Nodes that have an associated relevant constraints that evaluates to false are not serialized.

  4. Instance data is delivered over the network using the network protocol indicated by element submitInfo attribute method.

    Note:

    The HTTP "get" protocol is deprecated for use in form submission. Form authors should use "post" for greater compatibility.

  5. The response returned from the submission is applied as follows: if element submitInfo attribute replace has the value of "all", the entire containing document is replaced. If the attribute value 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 xlink:href, and the xforms:initialize event is dispatched to element model. Behaviors of other possible values for attribute replace are not defined in this specification.

    Under no circumstances may more than a single concurrent submit process be under way for a particular XForms Model.

11.4.2 application/x-www-form-urlencoded

This format is selected by the string application/x-www-form-urlencoded in element submitInfo attribute mediaType.

Note:

This serialization format is deprecated, and will be removed in a future version of the XForms specification. For greater compatibility with XML and non-western characters, form authors should choose a different serialization format.

This format is intended to facilitate the integration of XForms into HTML forms processing environments, and represents an extension of the [XHTML 1.0] form content type of the same name with extensions to expresses the hierarchical nature of instance data.

This format is not suitable for the persistence of binary content. Therefore, it is recommended that XForms capable of containing binary content use either the multipart/form-data (11.4.3 multipart/form-data) or text/xml (11.4.4 text/xml) formats.

Issue (issue-urlencoding-mods):

Modifications to urlencoding process

The urlencoding technique given here does not exactly match how legacy implementations produce urlencoded data. (In particular, we are adding contextual information with slashes and multiple location-steps) Will this approach interfere with legacy implementations?

Issue (issue-utf8-encoding):

Under discussion is the intent to have the data be UTF8 encoded; however, this is dependent upon IETF developments. Would UTF8 meet the needs of the forms community?

Instance data is urlencoded with the following rules:

  1. Each element node is visited in document order. If the element contains only a single node, it is selected for inclusion. Note that attribute information is not preserved.

  2. Elements selected for inclusion are encoded as "EltName=value;", where "=" and ";" are literal characters, "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 namespace prefixes, and multiple elements might have the same name.

  3. All such encodings are concatenated, maintaining document order. The resulting string is urlencoded, as in HTML processing.

Example:

Example: application/x-www-form-urlencoded
FirstName=Roland;

This format consists of simple name-value pairs.

<PersonName title="Mr">
  <FirstName>Roland</FirstName>
</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.4.3 multipart/form-data

This format is selected by the string multipart/form-data in element submitInfo attribute mediaType.

This format is intended to facilitate the integration of XForms into HTML forms processing environments, and represents an extension of the [XHTML 1.0] form content type of the same name that expresses the hierarchical nature of instance data. Unlike the application/x-www-form-urlencoded (11.4.2 application/x-www-form-urlencoded) format, this format is 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], with the "name" of each part being the canonical binding expression that references the selected instance data node.

Example:

Example: multipart/form-data
Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
  Content-Disposition: form-data; name="/PersonName/@title"

Mr
--AaB03x
  Content-Disposition: form-data; name="/PersonName/FirstName"

Roland
--AaB03x

...Possibly more data...

--AaB03x-

This format consists of sets of a canonical binding expression paired with a value.

<PersonName title="Mr">
  <FirstName>Roland</FirstName>
</PersonName>

Here is the instance data for the above example.

11.4.4 text/xml

This format is selected by the string text/xml in element submitInfo attribute mediaType.

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 suitable for the persistence of binary content.

The steps for building this persistence format is as follows:

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

    • If the selected content of the instance data corresponds to a multiply-rooted data structure (such as a general parsed entity), an the above serialization takes place, after which the serialized instance data is inserted as child elements of the unqualified element <Body>, which is in turn inserted as a child of the unqualified element <Envelope>.

11.4.4.1 Binary Content

Instance data nodes with values of the types xsd:base64Binary and xsd:hexBinary are specifically allowed, and are included in the serialized data according to the rules defined in [XML Schema part 2]

Issue (issue-instance-metadata):

Where a value within the instance data represents binary content, can we store meta-information with an xform:mediaType attribute reflecting the appropriate content type (e.g., "image/jpg")?

11.5 Error Indications

11.5.1 xforms:schemaConstraintsError

Dispatched in response to: instance data becoming schema-invalid.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: None

Default processing for this event results in the following: None; notification event only. Default error handling may be used.

11.5.2 xforms:traversalError

Dispatched in response to: a failure in link traversal of an xlink:href attribute value.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: The URI that failed to load.

Default processing for this event results in the following: None; notification event only. Default error handling may be used.

11.5.3 xforms:invalidDatatypeError

Dispatched in response to: an invalid parameter passed to an XForms function.

Target: model

Bubbles: Yes

Cancelable: No

Context Info: None

Default processing for this event results in the following: None; notification event only. Default error handling may be used.

12 Conformance

12.1 Conformance Levels

The XForms specification is designed for implementation on hardware platforms of all sizes, from tiny handheld devices to high-powered servers. Clearly, a one-size-fits-all approach has its drawbacks. For this reason, there are two conformance levels for XForms Processors, documents, and authoring tools.

12.1.1 XForms Basic

This conformance level will be suitable for devices with limited computing power, such as mobile phones, handheld computers, and appliances. This conformance level will depend on a subset of XML Schema, and will not include any resource-intensive features. Implementations of XForms Basic should return "basic" for the conformance-level property.

Resource-limited XForms Processors may define implementation limits on the maximum size of a node-set returned by XPath expressions.

12.1.2 XForms Full

This conformance level will be suitable for more powerful forms processing, such as might be found on a standard desktop browser or a server. Implementations of XForms Full should return "full" for the conformance-level property.

12.2 Conformance Description

12.2.1 Conforming XForms Processors

All XForms Processors must support the required portions of the specifications normatively listed as references (C References).

XForms Basic Processors must implement all required features labeled as Basic.

XForms Full Processors must implement all required features.

12.2.2 Conforming XForms Containing Documents

All XForms Containing Documents must conform to the required portions of the specifications normatively listed as references (C References). 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, or one of group, switch, repeat. Individual XForms fragments must be schema-valid against the Schema for XForms (A Schema for XForms).

All XForms Basic Containing Documents must conform to all required portions of this specification marked as Basic, and additionally not include any features not specifically marked as Basic.

All XForms Full Containing Documents must conform to all required portions of this specification.

12.2.3 Conforming XForms Generators

XForms Basic Generators must create conforming XForms Basic documents.

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

A Schema for XForms

<?xml version="1.0"?>
<!-- edited with XML Spy v4.0.1 U (http://www.xmlspy.com) by Micah Dubinko (XForms WG) -->
<xsd:schema targetNamespace="http://www.w3.org/2001/12/xforms"
      xmlns:ev="http://www.w3.org/2001/xml-events"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xforms="http://www.w3.org/2001/12/xforms"
        elementFormDefault="qualified">
  <!--
Open Issues
Need a datatype for "QName-but-not-NCName"; currently using xsd:string
Need a datatype for 'list of mediaTypes' on mediaType of <upload>
-->
  <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/1999/xlink" schemaLocation="XLink-Schema.xsd"/>
  <xsd:import namespace="http://www.w3.org/2001/xml-events" schemaLocation="XML-Events-Schema.xsd"/>
  <!-- 
structural elements
-->
  <xsd:attributeGroup name="horzAttrs">
    <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>
        <xsd:element ref="xforms:instance" minOccurs="0"/>
        <xsd:element ref="xforms:schema" minOccurs="0"/>
        <xsd:sequence minOccurs="0" maxOccurs="unbounded">
          <xsd:choice>
            <xsd:element ref="xforms:submitInfo"/>
            <xsd:element ref="xforms:privacy"/>
            <xsd:element ref="xforms:bind"/>
            <xsd:element ref="xforms:action"/>
            <xsd:element ref="xforms:extension"/>
          </xsd:choice>
        </xsd:sequence>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="schema">
    <xsd:annotation>
      <xsd:documentation>schema container.</xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:any namespace="##other"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:linkingAttributes"/>
    </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" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:linkingAttributes"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="privacy">
    <xsd:annotation>
      <xsd:documentation>privacy reference.</xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:linkingAttributes"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="submitInfo">
    <xsd:annotation>
      <xsd:documentation>submit info container.</xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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="mediaTypeExtension" type="xsd:string" use="optional" default="none"/>
      <xsd:attribute name="method" type="xsd:string" use="optional"/>
      <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="omitXMLDeclaration" type="xsd:boolean" use="optional"/>
      <xsd:attribute name="standalone" type="xsd:boolean" use="optional"/>
      <xsd:attribute name="CDATASectionElements" type="xforms:QNameList" use="optional"/>
      <xsd:attribute name="replace" type="xsd:string" use="optional" default='"all"'/>
    </xsd:complexType>
  </xsd:element>
  <xsd:attributeGroup name="linkingAttributes">
    <xsd:attribute ref="xlink:type" default="simple"/>
    <xsd:attribute ref="xlink:href"/>
    <xsd:attribute name="href" type="xsd:anyURI" use="prohibited"/>
  </xsd:attributeGroup>
  <xsd:element name="bind">
    <xsd:annotation>
      <xsd:documentation>Definition of bind container.</xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attribute name="ref" 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="isValid" type="xsd:string" use="optional"/>
      <xsd:attribute name="calculate" type="xsd:string" use="optional"/>
      <xsd:attribute name="maxOccurs" type="xforms:numberOrUnbounded" use="optional"/>
      <xsd:attribute name="minOccurs" type="xsd:nonNegativeInteger" use="optional"/>
    </xsd:complexType>
  </xsd:element>
  <!--
User Interface form controls
-->
  <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:selectOne"/>
      <xsd:element ref="xforms:selectMany"/>
      <xsd:element ref="xforms:range"/>
      <xsd:element ref="xforms:submit"/>
      <xsd:element ref="xforms:button"/>
    </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 ref="xml:lang" type="xsd:language" use="optional"/>
    <xsd:attribute name="class" type="xsd:string" use="optional"/>
    <xsd:attribute name="accessKey" type="xsd:string" use="optional"/>
    <xsd:attribute name="navIndex" type="xsd:nonNegativeInteger" use="optional"/>
  </xsd:attributeGroup>
  <xsd:element name="caption">
    <xsd:complexType mixed="true">
      <xsd:sequence>
        <xsd:any namespace="##any"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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>
        <xsd:any namespace="##any"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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>
        <xsd:any namespace="##any"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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="false">
      <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:horzAttrs"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="choices">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption" minOccurs="0"/>
        <xsd:sequence maxOccurs="unbounded">
          <xsd:choice>
            <xsd:element ref="xforms:choices"/>
            <xsd:element ref="xforms:item"/>
          </xsd:choice>
        </xsd:sequence>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="item">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:element ref="xforms:value"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="itemset">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:element ref="xforms:value"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:bindAllAttributes"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:group name="optionalUIChildren">
    <xsd:sequence>
      <xsd:choice>
        <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:caption"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:complexType>
  </xsd:element>
  <xsd:element name="textarea">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:complexType>
  </xsd:element>
  <xsd:element name="secret">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:complexType>
  </xsd:element>
  <xsd:element name="upload">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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: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="selectOne">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:listChoices" maxOccurs="unbounded"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
      <xsd:attributeGroup ref="xforms:commonUIAttributes"/>
      <xsd:attribute name="selectUI" type="xforms:selectUIType" use="optional"/>
      <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:complexType>
  </xsd:element>
  <xsd:element name="selectMany">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:listChoices" maxOccurs="unbounded"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
      <xsd:attributeGroup ref="xforms:commonUIAttributes"/>
      <xsd:attribute name="selectUI" type="xforms:selectUIType" use="optional"/>
      <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:complexType>
  </xsd:element>
  <xsd:element name="range">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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="stepSize" type="xsd:string" use="optional"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="button">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:commonUIAttributes"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="output">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:complexType>
  </xsd:element>
  <xsd:element name="submit">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="xforms:caption"/>
        <xsd:group ref="xforms:optionalUIChildren" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attribute name="submitInfo" type="xsd:IDREF" use="optional"/>
    </xsd:complexType>
  </xsd:element>
  <!--
XForms Actions
-->
  <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:horzAttrs"/>
      <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:refresh"/>
      <xsd:element ref="xforms:revalidate"/>
      <xsd:element ref="xforms:recalculate"/>
      <xsd:element ref="xforms:setFocus"/>
      <xsd:element ref="xforms:loadURI"/>
      <xsd:element ref="xforms:setValue"/>
      <xsd:element ref="xforms:submitInstance"/>
      <xsd:element ref="xforms:resetInstance"/>
      <xsd:element ref="xforms:insert"/>
      <xsd:element ref="xforms:delete"/>
      <xsd:element ref="xforms:setRepeatCursor"/>
      <xsd:element ref="xforms:toggle"/>
      <xsd:element ref="xforms:script"/>
      <xsd:element ref="xforms:message"/>
    </xsd:choice>
  </xsd:group>
  <xsd:element name="dispatch">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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="refresh">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:horzAttrs"/>
      <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:horzAttrs"/>
      <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:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attribute name="idref" type="xsd:IDREF" use="required"/>
      <xsd:attributeGroup ref="xforms:XMLEvents"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="loadURI">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
      <xsd:attribute ref="xlink:href" use="required"/>
      <xsd:attribute ref="xlink: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:horzAttrs"/>
          <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="submitInstance">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attribute name="submitInfo" type="xsd:IDREF" use="optional"/>
      <xsd:attributeGroup ref="xforms:XMLEvents"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="resetInstance">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attributeGroup ref="xforms:XMLEvents"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="insert">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:horzAttrs"/>
      <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="setRepeatCursor">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="optional"/>
      <xsd:attribute name="repeat" type="xsd:IDREF" use="required"/>
      <xsd:attribute name="cursor" type="xsd:string" use="required"/>
      <xsd:attributeGroup ref="xforms:XMLEvents"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="toggle">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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="script">
    <xsd:complexType>
      <xsd:simpleContent>
        <xsd:extension base="xsd:string">
          <xsd:attributeGroup ref="xforms:horzAttrs"/>
          <xsd:attribute name="id" type="xsd:ID" use="optional"/>
          <xsd:attribute name="type" type="xsd:string" use="required"/>
          <xsd:attributeGroup ref="xforms:XMLEvents"/>
        </xsd:extension>
      </xsd:simpleContent>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="message">
    <xsd:complexType>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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>
  <!--
Advanced User Interface
-->
  <xsd:element name="group">
    <xsd:complexType>
      <xsd:sequence maxOccurs="unbounded">
        <xsd:element ref="xforms:caption" minOccurs="0"/>
        <xsd:any namespace="##any"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="required"/>
      <xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
      <xsd:attributeGroup ref="xforms:commonUIAttributes"/>
      <xsd:attribute name="default" type="xsd:IDREF" use="optional"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="case">
    <xsd:complexType>
      <xsd:sequence maxOccurs="unbounded">
        <xsd:any namespace="##any"/>
      </xsd:sequence>
      <xsd:attribute name="selected" type="xsd:boolean" use="optional"/>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <xsd:attribute name="id" type="xsd:ID" use="required"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="repeat">
    <xsd:complexType>
      <xsd:sequence maxOccurs="unbounded">
        <xsd:any namespace="##any"/>
      </xsd:sequence>
      <xsd:attributeGroup ref="xforms:horzAttrs"/>
      <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" use="optional"/>
      <xsd:attribute name="number" type="xsd:nonNegativeInteger" use="optional"/>
    </xsd:complexType>
  </xsd:element>
  <!--
New simpleTypes
-->
  <xsd:simpleType name="QNameList">
    <xsd:list itemType="xsd:QName"/>
  </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="selectUIType">
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="radio"/>
      <xsd:enumeration value="checkbox"/>
      <xsd:enumeration value="menu"/>
      <xsd:enumeration value="listbox"/>
      <xsd:enumeration value="combo"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="numberOrUnbounded">
    <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:schema>

A.1 Schema for XLink

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

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.w3.org/1999/xlink"
      xmlns:xl="http://www.w3.org/1999/xlink"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
  <!--
  This schema is in no way normative for XLink; it functions only as a part of the
  Schema for XForms to allow proper assesment of XForms documents and fragments.
  
  See the XForms specification for details.
-->
  <xsd:attribute name="href" type="xsd:anyURI"/>
  <xsd:attribute name="type" type="xsd:string"/>
  <xsd:attribute name="role" type="xsd:anyURI"/>
  <xsd:attribute name="arcrole" type="xsd:anyURI"/>
  <xsd:attribute name="title" type="xsd:string"/>
  <xsd:attribute name="actuate">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="onLoad"/>
        <xsd:enumeration value="onRequest"/>
        <xsd:enumeration value="other"/>
        <xsd:enumeration value="none"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name="show">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="new"/>
        <xsd:enumeration value="replace"/>
        <xsd:enumeration value="embed"/>
        <xsd:enumeration value="other"/>
        <xsd:enumeration value="none"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name="label" type="xsd:NCName"/>
  <xsd:attribute name="from" type="xsd:NCName"/>
  <xsd:attribute name="to" type="xsd:NCName"/>
</xsd:schema>

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

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.0.1 U (http://www.xmlspy.com) by Micah Dubinko (XForms WG) -->
<xsd:schema targetNamespace="http://www.w3.org/2001/xml-events"
     xmlns:ev="http://www.w3.org/2001/xml-events"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      attributeFormDefault="unqualified">
  <!--
  This schema is in no way normative for XML Events; it functions only as a part of the
  Schema for XForms to allow proper assesment of XForms documents and fragments.
  
  See the XForms specification for details.
-->
  <xsd:attribute name="event" type="xsd:NMTOKEN"/>
  <xsd:attribute name="observer" type="xsd:IDREF"/>
  <xsd:attribute name="target" type="xsd:IDREF"/>
  <xsd:attribute name="handler" type="xsd:anyURI"/>
  <xsd:attribute name="phase">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="capture"/>
        <xsd:enumeration value="default"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name="propagate">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="stop"/>
        <xsd:enumeration value="continue"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name="defaultAction">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="cancel"/>
        <xsd:enumeration value="perform"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
</xsd:schema>

B Input Modes

Editorial note  
The XForms Working Group invites feedback and comments on the open issues in this section.

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.

Upon entering an empty form control with an inputMode attribute, the user agent should set the configuration so that the characters indicated by the attribute value can be input easily. User agents may use information about the text already present to set the appropriate input mode when entering a form control that already contains text, or when moving around in such a form control.

User agents should not use the inputMode attribute to set the input mode when entering a form control with text already present. User agents should, however, recognize 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. User agents are not required to recognize all of the attribute values--only those that they support. Unrecognized attribute values should be treated the same way as if the attribute were not present. Unrecognized attribute values must not result in an user agent error. Future versions of this specification may add new attribute values.

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 contents of a data item, and can specify different restrictions for different parts of the data item. inputMode is a soft hint about the kinds of characters that the user may most probably (start to) input into the form control. inputMode is provided in addition to pattern facets for the following reasons:

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

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

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

B.1 List of Possible Input Modes

The list of allowed attribute values is divided into three sections: 1) included values, 2) questionable values, and 3) excluded values. The XForms Working Group invites feedback on narrowing down the final choices.

Where there are no comments, the values are the Unicode Block names (see http://www.unicode.org/Public/UNIDATA/Blocks.txt). The block names are upper-cased, and use underlines for spaces, so that they correspond to the values in the Java java.lang.Character.UnicodeBlock class (see http://java.sun.com/j2se/1.4/docs/api/java/lang/Character.UnicodeBlock.html). The version of The Unicode Standards that these block names are taken from is 3.1.

Editorial note  
Do we say anything about future Unicode versions?

Most block names selected as attribute values are equivalent to script names. Please also see UnicodeScripts (http://www.unicode.org/Public/UNIDATA/Scripts.txt) for further information. The block names have been chosen because they are more formally defined.

Block names containing words such as 'extended' or 'supplement' have not been included in the list of attribute values; The characters these blocks include are covered by the (non-'extended') attribute value with the same script name. [a list of excluded block names can be found below]

Block names from JavaUnicodeBlocks, corresponding to UnicodeBlocks. With the exception of 'UNIFIED_CANADIAN_ABORIGINAL_SYLLABICS' (with the script name CANADIAN-ABORIGINAL), these names all also appear in UnicodeScripts:

Input Mode Comments
ARABIC
ARMENIAN
BENGALI
BOPOMOFO
CHEROKEE
CYRILLIC
DEVANAGARI
ETHIOPIC
GEORGIAN
GREEK
GUJARATI
GURMUKHI
HEBREW
HIRAGANA
KANNADA
KATAKANA
KHMER
LAO
MALAYALAM
MONGOLIAN
MYANMAR
OGHAM
ORIYA
RUNIC
SINHALA
SYRIAC
TAMIL
TELUGU
THAANA
THAI
TIBETAN
CANADIAN_ABORIGINAL
OLD_ITALIC Additional block names not in JavaUnicodeBlocks (added to UnicodeBlocks for Unicode 3.1). These are identical to the names in UnicodeScripts (with the change of '-' to '_')
GOTHIC
DESERET
FULLWIDTH_DIGITS Constant for the fullwidth digits included in the Unicode halfwidth and fullwidth forms character block.
FULLWIDTH_LATIN Constant for the fullwidth ASCII variants subset of the Unicode halfwidth and fullwidth forms character block.
HALFWIDTH_KATAKANA Constant for the halfwidth katakana subset of the Unicode halfwidth and fullwidth forms character block.
HANJA Constant for all Han characters used in writing Korean, including a subset of the CJK unified ideographs as well as Korean Han characters defined in higher planes.
KANJI Constant for all Han characters used in writing Japanese, including a subset of the CJK unified ideographs as well as Japanese Han characters defined in higher planes.
LATIN Constant for all Latin characters, including the characters in the BASIC_LATIN, LATIN_1_SUPPLEMENT, LATIN_EXTENDED_A, LATIN_EXTENDED_B Unicode character blocks.
LATIN_DIGITS Constant for the digits included in the BASIC_LATIN Unicode character block.
SIMPLIFIED_HANZI Constant for all Han characters used in writing Simplified Chinese, including a subset of the CJK unified ideographs as well as Simplified Chinese Han characters defined in higher planes.
TRADITIONAL_HANZI Constant for all Han characters used in writing Traditional Chinese, including a subset of the CJK unified ideographs as well as Traditional Chinese Han characters defined in higher planes.

B.1.1 Questionable Values

Block names for which inclusion is *unclear* (with questions):

Input Mode Comments
BRAILLE_PATTERNS
Editorial note  
Are there devices/forms where it is useful to indicate that actual braille patterns are requested (in contrast to braille device input that is immediately converted to other characters)?
GENERAL_PUNCTUATION
Editorial note  
We probably need something to stand for symbol input modes on handhelds and mobiles. But this may not be the right name. Also, even if there is such an input mode, do we expect data entry to begin with one of these?
CJK_SYMBOLS_AND_PUNCTUATION
Editorial note  
Are there devices (e.g. mobiles) with separate input modes for punctuation in different scripts? Would such punctuation occur at the start of data entry? Should we use a modifier rather than a separate list of values for such punctuation modes?
CJK_UNIFIED_IDEOGRAPHS
Editorial note  
We have values for Kanji, Hanja, and simplified/traditional Hanzi (i.e. for ideograph input optimized for Japanese, Korean, and simplified/traditional Chinese). Do we need another value that encompasses all CJK ideographs?
HANGUL_JAMO
Editorial note  
We need something for Hangul, but neither of these seems appropriate. Maybe just HANGUL.
HANGUL_SYLLABLES
IPA_EXTENSIONS
Editorial note  
Are there ipa keyboard layouts or input devices?
MATHEMATICAL_OPERATORS
Editorial note  
Are there math-specific keyboard layouts or input devices?
YI_SYLLABLES
Editorial note  
We need something for Yi. Is this the right name?
Musical Symbols and Byzantine Musical Symbols
Editorial note  
Do they need support? Are there input devices?
Editorial note  
Script names not yet covered (see comments above): HAN, HANGUL, YI.
Editorial note  
Additional questions below:

- Do we need other attribute values for digits (e.g. Devanagari, Thai,...) or a modifier value for digits?
- Do we need values for upper-case/lower-case, mixed-case (i.e. starting with upper-case letter, e.g. on PalmPilot), or modifier values?
- What is the value for mixed Kanji/Kana?
- Do we need other values for compatibility, e.g. half-width hangul?

B.1.2 Excluded Values

Values found in JavaUnicodeBlocks that have been excluded:

Input Mode
ALPHABETIC_PRESENTATION_FORMS
ARABIC_PRESENTATION_FORMS_A
ARABIC_PRESENTATION_FORMS_B
ARROWS
BASIC_LATIN BLOCK_ELEMENTS
BOPOMOFO_EXTENDED
BOX_DRAWING
CJK_COMPATIBILIT
CJK_COMPATIBILITY_FORMS
CJK_COMPATIBILITY_IDEOGRAPHS
CJK_RADICALS_SUPPLEMENT
CJK_UNIFIED_IDEOGRAPHS_EXTENSION_A
COMBINING_DIACRITICAL_MARKS
COMBINING_HALF_MARKS
COMBINING_MARKS_FOR_SYMBOLS
CONTROL_PICTURES
CURRENCY_SYMBOLS
DINGBATS
ENCLOSED_ALPHANUMERICS
ENCLOSED_CJK_LETTERS_AND_MONTHS
GEOMETRIC_SHAPES
GREEK_EXTENDED
HALFWIDTH_AND_FULLWIDTH_FORMS
HANGUL_COMPATIBILITY_JAMO
IDEOGRAPHIC_DESCRIPTION_CHARACTERS
KANBUN
KANGXI_RADICALS
LATIN_1_SUPPLEMENT
LATIN_EXTENDED_A
LATIN_EXTENDED_ADDITIONAL
LATIN_EXTENDED_B
LETTERLIKE_SYMBOLS
MISCELLANEOUS_SYMBOLS
MISCELLANEOUS_TECHNICAL
NUMBER_FORMS
OPTICAL_CHARACTER_RECOGNITION
PRIVATE_USE_AREA
SMALL_FORM_VARIANTS
SPACING_MODIFIER_LETTERS
SPECIALS
SUPERSCRIPTS_AND_SUBSCRIPTS
SURROGATES_AREA
YI_RADICALS

And additionally, excluded from UnicodeBlocks and not in JavaUnicodeBlocks:

High Private Use Surrogates
High Surrogates
Low Surrogates
Mathematical Alphanumeric Symbols
CJK Unified Ideographs Extension B
CJK Compatibility Ideographs Supplement
Tags
Private Use

C References

C.1 Normative References

RFC 2388
RFC 2388: Returning Values from Forms: multipart/form-data, L. Masinter, 1998. Available at: http://www.ietf.org/rfc/rfc2388.txt.
XForms Req
XForms Reqirements, Micah Dubinko, Dave Raggett, Sebastian Schnitzenbaumer, Malte Wedel, 2001. W3C Working Draft: available at: http://www.w3.org/TR/xhtml-forms-req.
XML Events
XML Events - An events syntax for XML, Steven Pemberton, T. V. Raman, Shane P. McCarron, 2001. W3C Last Call Working Draft available at: http://www.w3.org/TR/xml-events/.
XLink
XML Linking Language (XLink) Version 1.0, Steve DeRose, Eve Maler, David Orchard, 2001. W3C Recommendation available at: http://www.w3.org/TR/xlink/.
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
XSL Transformations (XSLT) Version 1.0, James Clark, 1999. W3C Recommendation available at: http://www.w3.org/TR/xslt.

C.2 Informative References

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.
FIMS
Form Interface Management System, ISO/IEC DIS 11730, 1992. available at: http://gatekeeper.research.compaq.com/pub/standards/sql/fims.txt
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/.
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/.

D Recalculation Sequence Algorithm (Non-Normative)

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

  1. A master dependency directed graph is created as detailed in D.1 Details on Creating the Master Dependency Directed Graph.

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

  3. 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. This is detailed in D.3 Details on Computing Individual Vertices.

  4. 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 a fatal exception, 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 a fatal exception, 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:

  1. 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 a fatal exception must be thrown, terminating the recalculate event.

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

  3. For each vertex in the depList of the removed vertex, decrement the inDegree by 1.

  4. 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 Changelog (Non-Normative)

This appendix lists substantive changes since the last publication of XForms 1.0. For greater detail on changes to the specification, consult the diff-marked HTML version.

E.1 Changes to Chapter Document Structure

This chapter previously occurred later in the specification. New WD namespace for XForms. New section on horizontally applicable markup. Elements previously named xform and model now named model and schema, respectively. Element submitInfo now contains a mediaTypeExtension and replace attributes. New content model for element model. Removed element bindings. All XLink usage now consists of simple links, and unqualified href attributes are explicitly prohibited.

E.2 Changes to Chapter Datatypes

New datatypes listitem and listitems, replacing datatype tokenList.

E.3 Changes to Chapter Constraints

This chapter was previously named "The XForms Model". Model item properties are now called XForms Constraints. All XForms Constraints now specify whether they apply to child nodes or not. Clarified relationship of Schema Constraints and attribute xsi:type.

E.4 Changes to Chapter XPath Expressions in XForms

New IDL method getInstanceData to allow script access to the instance data. Clarified the context in which XPath expressions are evaluated. Removed discussion on canonical binding expressions. New functions: if(), cursor(). Function average() is now avg(); xforms-property() is now property(). Clarification to the behavior of several functions. The section on extensibility has been removed, along with function function-available().

E.5 Changes to Chapter Form Controls

Added implementation requirements and data binding restrictions for all form controls. Removed form control selectBoolean. Updated content model of remaining list selection form controls. Removed element itemref; new content model for element item and element choices.

E.6 Changes to Chapter XForms Actions

All XForms Actions now bear XML Events attributes. Updated example of XForms Action usage. New actions: loadURI, message. Removed action scroll. Element action is now defined as a grouping for child actions. Re-wrote the processing for actions insert and delete. Numerous clarifications.

E.7 Changes to Chapter XForms User Interface

Added attribute selected to element case. New extended example of repeat. Clarification on permissible selection of nodes for repeat processing. Removed section on reusable form controls, including element component, defComponent, param, and valueOf.

E.8 Changes to Chapter Processing Model

This chapter has undergone significant revision since last publication. The diff-marked version of this chapter does not include indications of changes, due to the large amount of new material.

E.9 Changes to Chapter Conformance

This is a new chapter, with material formerly located in the Processing Model chapter.

E.10 Changes to Appendix Schema for XForms

19-Oct MJD <xforms:xform> (outermost in head) renamed to
       <xforms:model>
19-Oct MJD <xforms:model> (schema container) renamed to <xforms:schema>
19-Oct MJD 'xform' attribute renamed to 'model' throughout
19-Oct MJD new content model for <xforms:model> : (instance)?, (schema)?, ( privacy | submitInfo | bind | action | extension )*
(note that <bindings> went away with this change)
19-Oct MJD added content model for <xforms:schema> : #other (though typically, it will be <xsd:schema>)
19-Oct MJD import (unofficial) XLink schema, add attribute 'xlink:href'
19-Oct MJD numerous defaulted XLink attributes; new xlink roles
19-Oct MJD make unqualified 'href' attribute prohibited
22-Oct MJD removed <itemref>, new content model for <item> ( <caption> and <value> ); no 'value' attribute
(note that this also removed choiceItemGroup)
22-Oct MJD mediaType attribute now is of type xsd:NMTOKENS
22-Oct MJD removed orphaned xforms:tokenList datatype
22-Oct MJD added xforms:listItem and xforms:listItems datatypes
23-Oct MJD removed linking attributes from <textarea> (typo fix)
23-Oct MJD changed content model of commonUIChildren: caption, ( help | hint | alert | action | extension )*
23-Oct MJD applied horzAttrs across all elements
23-Oct MJD made <caption>, <help>, <hint>, and <alert> simple XLinks
23-Oct MJD <submitInfo> encType attribute changed to mediaTypeExtension (takes qname-but-not-ncname, or default "none")
25-Oct MJD removed xlink:href attribute from <model> (this is a complex link; child elements have the hrefs)
27-Oct MJD added <true> and <false> elements; in content model of <selectBoolean> (instead of <choices>) xsd:all
27-Oct MJD changed commonUIChildren to optionalUIChildren; adjusted content models of form controls
01-Nov MJD removed attribute 'withResponse' from <submitInstance>
01-Nov MJD added attribute 'replace' to <submitInfo>
01-Nov MJD changed prefix from "xform" to "xforms"
02-Nov MJD added @submitInfo to <submitInstance> and form control <submit>
03-Nov MJD added bindFirstAttributes to <value> (typo fix)
03-Nov MJD changed content model of <choices> to (choices|item)+ (typo fix)
03-Nov MJD made the content model of <script> non-empty (typo fix)
13-Nov MJD made start and end on <range> optional
13-Nov MJD removed binding attributes from <button> and <submit>
13-Nov MJD added selection attribute to <selectOne> and <selectMany>
13-Nov MJD changed strings on selectUI
14-Nov MJD removed XForms Action <scroll>
14-Nov MJD added XForms Actions <loadURI> and <message>
14-Nov MJD added XForms Events attributes to all XForms Actions
14-Nov MJD adjusted the content model of all form controls with new XForms Actions
14-Nov MJD removed <component>, <defComponent>, <param>, and <valueOf>
14-Nov MJD removed <selectBoolean>, <true>, and <false>
15-Nov MJD Now using XML-Events-Schema.xsd
15-Nov MJD New element <itemset> (<repeat> for <item>s); adjusted content model of <selectOne>, <selectMany>
15-Nov MJD added "combo" to the possible choices for selectUI (typo fix)
16-Nov MJD added optional <caption> as first child of <group> and <choices>
16-Nov MJD XForms Action <dispatch> changed attribute 'event' to 'name', added attributes 'cancelable' and 'bubbles'
16-Nov MJD attribute 'idref' on <setFocus> now required (typo fix)
16-Nov MJD removed binding attributes from <submitinstance> and <resetInsetance>, added to <submitInfo>
16-Nov MJD changed attributes on <insert> and <delete>; node-set binding+'at' (& 'position' for<insert>)
16-Nov MJD removed 'switch' attribute from <toggle>
16-Nov MJD added horz attributes (typo) to <script>; and attribute 'type'
17-Nov MJD XLink simplification; no roles, all simple links
19-Nov MJD Simpler content model for <group>; optional <caption> followed by anything
20-Nov MJD Added attribute 'inputMode' to <input>, <secret>, and <textarea>
04-Dec MJD Added bindFirst attributes to <loadURI>
06-Dec MJD Changed type of mediaType on <upload> to xsd:string, added issue
06-Dec MJD Added bindFirst attributes to <caption>, <help>, <hint>, <alert>
06-Dec MJD Added attribute selected to <case>
06-Dec MJD <setValue> accepts simpleContent of xsd:string

F Acknowledgments (Non-Normative)

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

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

Note:

Editor Acknowledgments: Previous versions of this document were edited with assistance from Dave Raggett (until December 2000) and Linda Bucsay Welsh (until April 2001).

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.

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.

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