HTML Forms are one of the more widely used features of HTML. In reviewing XML, XSL and related standards, there doesn't seem to be much specific XML support for forms. The XFDL (Extensible Forms Definition Language) proposal creates a specific XML-based language for defining forms, rather than providing generic XML form and signature features. Thus, it requires a XFDL-aware client application or plug-in at the browser to present, fill, sign and submit the XFDL forms.

This memo describes a possible approach to extending XML support for forms and for signing forms.

Figure 1 is a diagram of how forms might work with current XML specifications, depending on the degree of available browser support. The XML document arrives at the XML-enabled browser, it is parsed and validated against the DTD (Document Type Definition), and a DOM (Document Object Model) is created and made available to applications, such as JavaScript applets. An XSL (Extensible Style Language) style sheet can be used to convert the XML to HTML for display.

The incoming XML document does not have any formatting information, and in particular, it does not have the elements such as <FORM>, <INPUT>, <BUTTON>, <SELECT>, <TEXTAREA>, <FIELDSET> and <LABEL> that define the scope of an HTML form and the data entry widgets it contains. Neither does it define the special purpose buttons that "submit" or "reset" the values entered in the form.

However, the XSL (or CSS -Cascading Style Sheet) can contain those elements, and XSL can inset the HTML form "flow objects" at the designated places in the HTML output, in conjunction with element attributes and values from the original XML. Thus, the output of the style sheet processor is a standard HTML 4.0 form (along with any other non-form content from the XML document and the style sheet, e.g. titles, headings, XSL formatted paragraphs containing text from the XML document, etc.).

The HTML Form will be displayed by the browser, and the user can enter information. As data is entered or selections are made, the flow objects are updated with the current values.

Pressing the submit button will cause the normal posting of the form. The field names and current values are extracted for the form, formatted as a set of field-value pairs and POSTed using the URL in the action parameter of the <FORM> element (which could be something like http://www.company.com/cgi/process or mailto://process@company.com ).

Note that this:

• doesn't cryptographically sign anything, or
• return the information to the server or mailbox as an XML document.

Figure 2 shows a possible approach to signing and submitting XML documents. The first part, that produces an HTML Form proceeds as before with the exception that the HTML <BUTTON> now has two new standard types: "Sign" and "Verify". The sign buttons also contains a list of Xpointers which identify the elements in the input XML document and the XSL style sheet that are to be signed. These are hashed independently, and then their hashes signed using the FSML approach. The verify button contains an Xpointer to the <signature> element in the XML document which is to be verified.

Render, display and input proceed as before, except that the input information is used to update the XML DOM, instead of being put back in the HTML form. Display also should "gray" the previously signed parts of the form, and disallow data entry (this might be defined in the XSL style sheet used for processing this document by this person).

When the sign button is pressed, the "on sign" process creates a new <signature> element in the DOM, using the Xpointers in the XSL style sheet to locate the elements of the DOM to be signed. Xpointers may also specify that parts of the style sheet be signed as well, e.g. the style sheet may contain standard disclosure terms and conditions that are not sent with every XML document, but which must be signed to acknowledge agreement with them. Pressing the sign button would also spawn the addition displays to support the signing ceremony, including entry of PINs to unlock smart cards, etc.

Pressing the submit button should now result in creation of a new XML document from the signed XML DOM, and sending of the DOM back to the server or mailbox. It would be nice to have the addressing be more flexible than simply sending to a URI contained in the XSL style sheet. The XML Schema is used to validate the XML document before it is sent. To reduce data transmission, parts of the XML document and signed parts of the XSL style sheet may be sent by reference, rather than by value.

Support for forms by XML is minimal, although form entry of data and subsequent signing and submission of the data in an XML document would seem to be a general and very useful feature.

This note has described one approach to added XML support for forms, how to sign the form and its content, and how to submit the resulting XML document including the signatures.