5.2 Structural Elements
| The XForms Model is made up of a number of different elements, outlined here.
This element is the local root of the definition of the XForms Model. It is typically found in a non-rendered area of the containing document. In the following example, the head section in XHTML can contain an XForms Model. <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xforms="http://www.w3.org/ 2002/xforms"> <head> <title>A sample XHTML+XForms document</title> <xforms:model> ...more XForms elements... </xforms:model> </head> <body> ... The attribute functions declares any extension functions, as covered in Chapter 11, that are absolutely necessary for the form to function. The attribute schema includes a space-separated list of external XML Schema documents to be retrieved and included in the definition of the XForms Model. Additionally, XML Schema definitions may occur inline, with one or more xs:schema elements appearing as children of the model element. As Chapter 6 will describe, the datatype associated with a node can have an effect on the user interface presented to the user for populating the node with data. Since the model element is a target of several kinds of events (see Chapter 7), XML Events attributes are also permitted in this element.
This element serves as a container for initial instance data. The instance element has a unique restriction on the single allowed child element: absolutely anything, in any namespace, is allowed, as long as it would make a well-formed XML document if it existed in a separate file. The content is treated as "opaque," which means that even if the child element (or any descendants) contain elements that would normally affect the operation of the document (including nested XForms elements), the elements don't invoke any special processing. The contents of this element are simply data that will be both read and written during form interaction, nothing more. Instead of inline content, instance may use Linking Attributes (that is to say, src) to point to external instance data. Other than requiring an extra network fetch operation, behavior in this case is exactly the same.
This element establishes conditions that are continuously applied to the instance data. With instance data defined neatly by the instance element, the question remains of how to annotate instance data nodes with properties necessary for forms. Chapter 5 describes these model item properties but, for now, it is sufficient to know that each model item property is represented by an attribute on this element.
The properties are applied through an additional attribute, nodeset, which, not surprisingly, selects a node-set. For each node in the selected node-set, model item properties are initialized according to the corresponding attribute value. If two separate bind elements are configured to set conflicting model item properties on the same node, an error condition will result, preventing the form from operating.
This will be covered in Chapter 8. |
