10 Document Structure

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

10.1 The XForms Namespace

The XForms namespace has the URI: http://www.w3.org/2001/06/xforms. Future revisions are expected to use a different identifier. This document uses the convention of an xform: prefix to represent elements and attributes that are part of the XForms Namespace.

XForms Processors must use the XML namespaces mechanism [XML Names] to recognize elements and attributes from this namespace. Except where specifically allowed by the Schema for XForms, foreign-namespaced elements are not allowed as content of elements in the XForms namespace. Foreign-namespaced attributes are, however, allowed on any XForms element. The XForms Processor must ignore any foreign-namespaced elements or attributes that are unrecognized.

10.2 XForms Elements

10.2.1 xform

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

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

xmlns = namespace-identifier - Optional standard XML attribute for identifying an XML namespace. It is often useful to include this standard attribute at this point.
id = xsd:ID - Optional unique identifier used to refer to this particular xform element.

For example:

<xform xmlns="http://www.w3.org/2001/06/xforms" id="Person">
   <model xlink:href="Schema-Questionnaire.xform" />
   <instance xlink:href="URL-to-retrieve-defaults" /> 
   ...
</xform>

10.2.2 model

The model element is used to define the XForms Model. The content of the XForms Model may be defined inline or obtained from a external URI.

Example: XML Representation: <model>
<model
  id = xsd:ID
  xlink:href = xsd:anyURI
>
  <!-- Content: ( schema subset syntax ) -->
</model>

id = xsd:ID - Optional unique identifier.
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/06/xforms-model" xlink:type="locator"

10.2.3 instance

The instance element 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
  id = xsd:ID
  xlink:href = xsd:anyURI
>
  <!-- Content: (##other) -->
</instance>

id = xsd:ID - Optional unique identifier.
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/06/xforms-instance" xlink:type="locator"

Issue (issue-schemalocation):

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

10.2.4 submitInfo

The submitInfo element provides information on how and where to submit the instance data.

Example: XML Representation: <submitInfo>
<submitInfo
  id = xsd:ID
  xlink:href = xsd:anyURI
  method = xsd:string
>
  <!-- Content: (##empty) -->
</submitInfo>

id = xsd:ID - Optional unique identifier.
xlink:href = xsd:anyURI - Required destination for submitted instance data.
method = xsd:string - Optional indicator to provide details on the submit protocol. With HTTP, the default is "POST".

Issue (submit-method-values):

The possible values for method, and their respective meanings, still need to be defined.

10.2.5 bind

The bind element represents a connection between the different parts of XForms.

Example: XML Representation: <bind>
<bind
  id = xsd:ID
  ref = XForms binding expression
>
  <!-- Content: (##empty) -->
</bind>

id = xsd:ID - Required unique identifier.
ref = XForms binding expression - A link to an externally defined XForms Model.

Additional details are found in the chapter 9 Binding.

10.3 Integration with XLink

XForms make good use of XLink [XLink] features. To that end, the XLink namespace is integrated in the DTD/Schema, the majority of the attributes have sensible defaults, including those based on XLink roles defined below.

This document uses the convention of an xlink: prefix for the XLink namespace (informationally: as of this writing, the XLink namespace identifier is http://www.w3.org/1999/xlink - this may change when XLink reaches W3C Recommendation state. Please verify at [XLink])

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:

Example: Inline XForms Model, without explicit change to the xlink:type
<model>
  <!-- Content: ( schema subset syntax ) -->
</model>
Example: Inline XForms Model, with explicit change to the xlink:type
<model xlink:type="resource">
  <!-- Content: ( schema subset syntax ) -->
</model>
Example: External XForms Model
<model xlink:href="URI" />

XLink as originally specified 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 xform element that are otherwise not necessary for XForms. Hence, for children of the xform 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.

An XForms processor is not required to implement full XLink--correct behavior of the xlink:href attribute (as defined above) is sufficient. 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.

The following definition of the XLink roles defines the relationship between the various resources participating in a XForms-based form, not properties that are inherent to the resources. It is perfectly permissible for the same resource to participate in various XForms-based forms in different roles.

10.3.1 XLink role for XForms

The xlink-role for XForms Models is http://www.w3.org/2001/06/xforms. This means that XLink processors encountering a link with a xlink:role="http://www.w3.org/2001/06/xforms" must assume that the arcs associated with the other XLink roles for XForms (see below) behave as above. In other words, this XLink role is an additional hint beyond the element names for an XLink processor to identify the arcs. For all roles, if element names and XLink behavior conflict, XLink role behavior prevails.

10.3.2 XLink role for the XForms Model

The xlink-role for XForms Models is http://www.w3.org/2001/06/xforms-model. This means that XLink processors encountering a link with a xlink:role="http://www.w3.org/2001/06/xforms-model" must assume that the referenced resource relates to the other resources as XForms Model as defined in 5 The XForms Model.

10.3.3 XLink role for the Instance Data

The xlink-role for XForms Instances is http://www.w3.org/2001/06/xforms-instance. This means that XLink processors encountering a link with a xlink:role="http://www.w3.org/2001/06/xforms-instance" must assume that the referenced resource is the initialization data of a form.

10.3.4 XLink role for the XForms User Interface

The xlink-role for XForms User Interfaces is http://www.w3.org/2001/06/xforms-ui. This means that XLink processors encountering a link with a xlink:role="http://www.w3.org/2001/06/xforms-ui" must assume that the referenced resource is the user interface of a form. Note that this role does not make an assertion about the content type of the referenced resource other than that it is an XML format. For example, it can be XHTML+XForms, pure XForms, SVG+XForms or pure SVG any other combination. This role does not correspond to any element defined in XForms; it is defined so that XLink linkbases [XLink] can be established containing all the information about a XForms document.