10 Processing Model and Conformance

Contents

• 10.1 Introduction
• 10.2 Components
• 10.3 Processing Stages
• 10.4 Events
• 10.5 XForms Submit Protocol
• 10.6 Conformance

This chapter is normative.

10.1 Introduction

This chapter is currently under development and discussion in the XForms Working Group, and does not yet represent consensus.

The XForms Reference Processing Model is intended as a normative explanation of the components, predictive behavior, and mechanisms for interacting with XForms Processors. It is not intended to constrain implementations; any implementation that produces the specified results and meets conformance guidelines can be considered conforming.

Design Rationale

The processing model set out in this chapter will:

• Identify components and stages of the processing model
• Define predictive behavior for XForms Processors
• Define device independent mechanisms for user interaction
• Provide compatibility with existing form processing

10.2 Components

An XForms Processor can be considered as having the following components. Not every component is necessary in every case:

• Containing document(s), for instance XHTML
• XForms Model (specification)
• Instance data - (specification)
• XForms User Interface (specification) or other UI
• Implementation-specific Presentation
• Binding - (specification)

Note that XForms User Interface and Presentation are treated as separate by the processing model. XForms User Interface refers to the markup (specification) that defines form controls, while presentation here refers to the implementation-specific presentation controls, for instance a Macintosh edit box control. As defined below, there is not necessarily a one to one correspondence; for instance the XForms Specific Property relevant might dynamically determine whether a form control is available in the presentation.

For ease of authoring, certain XForms elements may be omitted in common cases. Under discussion are:

• <instance> may be optional when the initial state for every <model> is empty.
• <model> may be optional when a simple, flat XForms Model can be inferred from the XForms User Interface.
• Binding may be optional when only a single <model>, <submit>, <instance> and UI are specified.
• <submit> is required whenever a submit action is defined.

10.3 Processing Stages

An XForms Processor can be considered as performing the following processing steps, in no particular order. Not every step will be performed in every case:

• Initialization
• Deinitialization
• User interaction
• Mapping from XForms User Interface to presentation
• Validation
• Suspension of user interaction
• Resumption of user interaction
• Instance data submission

Future revisions of this document will define the processing steps for each of the above cases.

10.4 Events

XForms will use the DOM Level 2 and XHTML events syntax. Under discussion are the following events:

• xforms-construct
• xforms-destruct
• xforms-interactive-value-changing
• xforms-value-changing
• xforms-notify-value-changed
• xforms-submit
• xforms-reset
• xforms-suspend
• xforms-resume
• xforms-refresh
• xforms-exception

DOM Level 2 events require a target node. The definition of the target node for each event is under discussion. Future revisions of this document will provide descriptions and semantics for each of the above event types.

10.5 XForms Submit Protocol

The XForms processing model provides three different formats for persisting instance data.

• application/x-www-form-urlencoded
• multipart/form-data
• text/xml

The following sections describe how to instance data is prepared for submission.

10.5.1 application/x-www-form-urlencoded

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 XForms state information.

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 or text/xml formats.

The XForms Working Group would appreciate feedback on whether application/x-www-form-urlencoded is necessary.

Note: Also under discussion is the intent to have the data be UTF8 encoded; however, this is dependent upon IETF developments.

The steps for building this persistence format is as follows:

1. Prepare a new UTF-8 encoded string buffer to hold the persisted XForms state information
2. Beginning with the root element of the instance data, iterate over the content of the instance in document order and build an ordered set of strings by performing the following steps:
   1. For each element with an attribute :
      • Append, to the set, a string of the format "path=value" where path is the [XPath] AbsoluteLocationPath that refers to each attribute, and value is the character content of each attribute (urlencoded if necessary)
   2. For each element enclosing character content:
      • Append, to the set, a string of the format "path=value" where path is the [XPath] AbsoluteLocationPath that refers to the element, and value is the character content of the element (urlencoded if necessary)
   3. For each element enclosing element content:
      • Continue the iteration
3. Append the strings from the ordered set together, delimiting the strings with an ampersand (&) character, and place the result of the append into the UTF-8 encoded string buffer of step #1

Example:

application/x-www-form-urlencoded

/PersonName/PersonTitle=Mr&/PersonName/FirstName=Roland

This format consists of sets of an AbsoluteLocationPath paired with a value.

Corresponding Instance Data

<PersonName> <PersonTitle>Mr</PersonTitle> <FirstName>Roland</FirstName> </PersonName>

Here is the instance data for the above example.

10.5.2 multipart/form-data

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 XForms state information. Unlike the 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 as outlined in [RFC 2045]. Each part is expected to contain:

1. A "Content-Disposition" header whose value is "form-data"
2. A name attribute specifying the [XPath] AbsoluteLocationPath of the corresponding value from the instance data. Names originally encoded in non-ASCII character sets may be encoded using the method outlined in .

Example:

multipart/form-data

Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="/PersonName/PersonTitle" Mr --AaB03x Content-Disposition: form-data; name="/PersonName/FirstName" Roland --AaB03x ...possibly more data... --AaB03x-

This format consists of sets of an AbsoluteLocationPath paired with a value.

Corresponding Instance Data

<PersonName> <PersonTitle>Mr</PersonTitle> <FirstName>Roland</FirstName> </PersonName>

Here is the instance data for the above example.

Binary Content

Each part may be encoded and the "Content-Transfer-Encoding" header supplied if the value of that part does not conform to the default (7 bit) encoding.

Where a value within the instance data represents binary content, the value should be identified by the appropriate content type (e.g., "application/octet-stream"). If multiple values of binary content are to be returned as the result of a single model item, they should be returned as "multipart/mixed" embedded within the "multipart/form-data".

The XForms Processor may wish to supply a file name for each value of binary content. The file name may be specified with the "filename" parameter of the 'Content-Disposition: form-data' header, or in the case of multiple values of binary content, in a 'Content-Disposition: file' header of the subpart. If the file name of the client's operating system is not in US-ASCII, the file name might be approximated or encoded using the method of [RFC 2045]. This is convenient for those cases where, for example, the uploaded files might contain references to each other (e.g., a TeX file and its ".sty" auxiliary style description).

10.5.3 text/xml

This format permits the expression of the XForms state information as an XML-based format 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. Prepare a new empty XML document to hold the persisted XForms state information
2. If there is one child element of the <instance> node:
   1. Serialize, into the XML document of step #1, the entire content of the <instance> node
3. If there are multiple child elements of the <instance> node:
   1. Create a root element of <xfm:instance> in the XML document of step #1. Note that a prefix and namespace declaration will be needed. Any prefix may be used, not just xfm.
   2. Serialize, into the root element, the entire content of the <instance> node

Binary Content

Handling of binary content will likely be based on the ongoing work in the XML Protocol Working Group.

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

10.6 Conformance

XForms have been designed for use among a wide variety of XForms Processors, of varying size and resource constraints. Because of this, multiple conformance levels are being discussed. This chapter will be updated in the future with more details.