John J. Barton John_Barton@hpl.hp.com
Hewlett Packard Labs
Copyright 2001 Hewlett Packard
The new XML Protocol effort supports the interaction of two computer programs via XML messages. Web fill-in forms have been used extensively to allow humans to interact with computer programs. This proposal explores the potential for web fill-in forms to use the new XML Protocol.
Allowing web clients to submit forms directly in XMLP format reduces the complexity of some kinds of applications. It allows XMLP service to be developed for both human and machine inputs without pointless reformatting front ends. It allows debugging of XMLP services directly with web browsers. Furthermore, a system of XMLP-based services could arise that users could compose by applying ad-hoc human intelligence rather than the planned intelligence of a developer.
The basis for this proposal is the XML-based Web fill-in form approach called XFORMs. The XFORMs Working Group documents have solicited an XML Protocol-based submission solution. Thus in part this proposal addresses that request.
The basic mechanism for integrating XML Protocol and XFORMs can be quite easily
described and seems likely to be quite powerful in its application. An XFORM
server simply places a complete XML Protocol message in the
element of the
xform descriptor in the web page header. The Web
browser then has a local copy of the XMLP message. Since the body of the XML
Protocol message is serialized XML data, the values in that data can be addressed
by XFORMs operators and presented to human users for modification. When the
submit button is pressed, the now-modified XMLP message is sent
to the server (or rather to the destination address supplied with the form).
The mechanism proposed here is might be adaptable to XHTML web browsers that do not support the complete XFORMs solution. This proposal discusses one approach to XHTML.
The submission of an XMLP message using the XFORMs
will not be quite adequate unless the XFORMs Working Group changes
Therefore this proposal is write as a prototype specification for a form submission
postXMLP to parallel the
in XFORMs. The primary additional specification we add here concerns submission
of binary data.
(I will switch between XMLP and SOAP, using XMLP when I talk about abstractions or W3C and SOAP when I talk about specific protocols. This is an expression of the obvious: SOAP is concrete prototype for a potential W3C standard called XMLP.)
The XForms project  defines a layered, XML based approach for defining interactive
forms. The existing documents refer to a
postXML submission method
and the submission of XML-encoded data. We propose an additional submission
method based on XMLP.
Form submission is a component in an overall messaging model. A messaging model defines how messages are packaged and transmitted for a given service. For XForms, this primarily relates to how forms are transmitted to the user and submitted by the user. The model defines what data to send, in what format, and what results to expect; for the user, it also defines the actions taken to submit a form.
The recently proposed XML Protocol (XMLP)  is uniquely suited for XForms transmission because it is also XML based and it is specifically designed to address the complete range of issues associated with XML communications. As we will describe below, the integration of XMLP into the current XForms proposal would require only minor changes to the current proposal and the addition of some specifications relating to the XMLP protocol itself.
XMLP is the current W3C proposal for a standardized message format, designed for data encapsulation and data serialization, and based on non-exclusive transport mechanisms . The W3C working group has taken Simple Object Access Protocol , as its starting point for discussions.These attributes of XMLP recommend it for form submission:
Integrating XMLP and XForms would only require the addition of a submission method using XMLP. Existing submission methods need not be effected by this proposal.
To the extent that web services become formulated in terms of XMLP messages, the ability to edit these messages within a web browser allows human interaction into a system designed for machine-to-machine operation. Unless we expect web services to be significantly more reliable and adaptable than other kinds of software, this direct interaction capability seems valuable and important all by itself.
Beyond desktop browsers, XFORMs seeks to address digital "appliances",
small handheld special purpose devices. Therefore consider a user intent on
adding photos to their online album, a wireless digital camera with a TCP/IP
stack and a photo album service. An application can be built to acheive this
that would have parts in the camera and parts in the service. If the camera
could interpret simple XFORMs and allow images to be attached to
type=binary on the form, then form submission would
accomplish image upload. The service could be programmed to accepted these forms
and add the image to the album.
If the form client submitted XMLP messages and the service were programmed to accept XMLP messages, then that service could also be used by desk top computer file upload applications, both controlled by a program or by a human operating through a web browser. Other clients like scanners can upload to the service using the same form submission mechanism. A scanner that created an incompatible image format for the photo album could be accomodated by simply inserting a tranformation service in the pipeline between the client and the photo album service. In these cases we can switch between a human filling in a form and a programming sending a message since the form client sends messages in the same format as program would.
It is the case that this mechanism only applies when the service is designed within the limitations of the content types that a form-fill-in client can offer. The spectrum of applications on the World-Wide Web testify to the efficacy of working within such limitations. In addition we envision a greater breadth of content types arising from web browsers extended with sensors.
(This section is intended to give you something to complain about...)
All aspects of the form specification for
method=postXMLP except for the format of the data posted by
the client. Specifically the user of the form should not be able to detect a
difference except by reading the source for the page.
Within the header of a page with a form to be sent via
there must be an
xform element with an
The child of this
instance element must have the format of a valid
SOAP 1.1 message. The values of elements in this message represent the initial
state for form fill in. The form fill in operation may change the values of
elements. When the form is submitted, the content within the
element, with modified values, is submitted. In other words, the form filling
operation edits the orginal SOAP 1.1 proto-message.
Consequently the XFORMs schema may have to be adapted to allow the SOAP overhead elements (envelop, header, body and others) to appear without XFORMs failure.
The data stream sent under
method=postXMLP will be a SOAP 1.1
message. The SOAP body of this message will contain well-formed XML consisting
of the form instance data serialized according to SOAP 1.1 rules. Since every
form instance datatype is derived from an XML Schema datatype [XSchema-2]
and every XML Schema datatype can be serialized using SOAP 1.1 rules, then every
instance datatype has a SOAP 1.1 serialization. Generally the SOAP serialization
is a natural one for XML. Informally one can say that the SOAP 1.1 serialization
is character equivalent to the XML instance data representation discussed in
the XFORMs documentation. The formal connection is given by these rules:
|XFORMs datatype||SOAP Serialization|
|atomic (5.3.1)||simple value|
|enumerations (5.3.2)||enumerations (section 5.2.2 in SOAP 1.1)|
|groups (5.3.3) and switches (5.3.6)||compound values with the XFORMs
|unions (5.3.4)||polymorphic accessors, (section 5.3 in SOAP 1.1)|
Note that all of the XFORMs datatype can be serialized; there maybe SOAP serializations that cannot be put into forms. (like...)
The remaining XFORMs datatype is
binary. SOAP 1.1 is strictly
an XML protocol: it does not have a mechanism for sending non-XML data. Consequently
binary data can be sent only if it is either encoded or attached to the SOAP
message. SOAP Messages with Attachments [Attachments]
provides an attachment mechanism quite similar to the
submisssion mechanism in XFORMs. We adapt this mechanism here.
If a form contains any
binary data items, then the submitted form
will have MIME structure
Multipart/related. The first or root part
will be a SOAP 1.1 message formatted as described above. For each
data item in a form, the submitted SOAP message will have a MIME part whose
type matches one of the
mediaType values given in the form model.
Content-Location value (a URI) in the MIME header for that
MIME part will be referenced by an
href attribute of the corresponding
form instance data element in the SOAP body.
If relative URI addressing is used as described in SOAP Messages with Attachments
[Attachments], the XFORMs binding
expression for the
binary element can be used as the URI in
the instance data href and the corresponding MIME type
header. The binding expression looks like an XPATH through the form instance
Here is an example of a form with a string and a binary element:
<xform xmlns="http://www.w3.org/2000/xforms" id="photo_upload" action="http://myphotoservice.com/addphoto.asp", method="postXMLP"> <model> <string name="album_id" /> <binary name="photo"> <mediaType>image/jpeg</mediaType> <mediaType>image/png</mediaType> </binary> </model> <instance> <xmlp:Envelope xmlns:xmlp="http://schemas.xmlsoap.org/soap/envelope/"> <xmlp:Body> <album_id>John's Great Adventure</album_id> <photo></photo> </SOAP-ENV:Body> </SOAP-ENV:Envelope> </instance> </xform> </head> <body> <xform:input ref="photo_upload/xmlp:Envelope/xmlp:Body/photo">Select Photo </input> <xform:submit xform="photo_upload"> Add to <output ref="photo_upload/xmlp:Envelope/xmlp:Body/album_id"> photo album</submit> </body>
(The current XFORMs proposal does not have the
for a binary input shown above. A separate
proposal describes it). When the submit button is pushed, submitted data
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<email@example.com/s445>" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <firstname.lastname@example.org/s445> Content-Location: addphoto.xml <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <xform:instance> <album_id>John's Great Adventure</album_id> <photo href="photo_upload/photo"/> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <email@example.com/s445> Content-Location: "photo_upload/photo" ...binary JPEG image... --MIME_boundary-
Note that the value for the album_id came out of the instance data downloaded from the server and the image was added at the client.
The above discussion was focused on the new XForms proposal. We could also
integrate XMLP submission into the XHTML forms model. For this case we propose
the addition of a new
enctype=multipart/related. This acts like
a third component to section 17.13.4
Form content types of the HTML 4.0.1 specfication. It resembles the second
form conten type,
enctype=multipart/related the submitted data has MIME type
multipart/related. The first MIME part will be a MIME type
part that contains a SOAP 1.1 message. The body of that SOAP message consists
XML elements cooresponding to each form control in the same order they apper
in the form. The elements are named according to the HTML 4.0.1 naming convention
multipart/form-data MIME parts. HTML 4.0.1 uses the following
definition for a MIME part name:
a name attribute specifying the control name of the corresponding control. Control names originally encoded in non-ASCII character sets may be encoded using the method outlined in [RFC2045].
A control name is defined as:
A control's "control name" is given by its name attribute. The scope of the name attribute for a control within a FORM element is the FORM element
enctype=multipart/related these control names are
used as element names. The control name may be namespace qualified; that qualification
must be maintained when the form data is submitted.
For element values we have two cases: text-entry controls and file input controls.
input type=filecontrol results in an attachment. The corresponding XML element appears in the SOAP message as above, but no element value appears. Rather an
hrefattribute is included that references to the MIME attachment as specified in SOAP Message with Attachments. User agents may use the control name as the attachment's
Content-locationvalue or the file name on the local operating system encoded for use as a URI.
The following example illustrates "multipart/related" encoding. Suppose we have the following form:
<FORM action="http://server.com/cgi/handle" enctype="multipart/form-data" method="post"> <P> What is your name? <INPUT type="text" name="submit-name"><BR> What files are you sending? <INPUT type="file" name="files"><BR> <INPUT type="submit" value="Send"> <INPUT type="reset"> </FORM>
If the user enters "Larry" in the text input, and selects the text file "file1.txt", the user agent might send back the following data:
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<firstname.lastname@example.org/s445>" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <email@example.com/s445> Content-Location: s13rr5.xml <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <submit-name>Larry</submit-name> <file href="file1.txt" /> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
--MIME_boundary Content-Type: text/plain Content-ID: <firstname.lastname@example.org/s445> Content-Location: = file1.txt
... contents of file1.txt ... --MIME_boundary-
XMLP provides a standard mechanism for intermediation in the form of XML co-messages
packaged in "headers" with the primary XML message (the "body").
For forms to be complete XMLP senders we need a mechanism to specify these headers.
Essentially these headers are data from the source of the form (server) to the
target of the submission. They have a role similar to the "
type=hidden" fields in HTML forms.
For XFORMs, the headers can simply be placed in the instance data. Here is an example:
<head> <xform xmlns="http://www.w3.org/2000/xforms" id="photo_upload" action="http://myphotoservice.com/addphoto.asp", method="postXMLP"> <model> <string name="album_id" /> <binary name="photo"> <mediaType>image/jpeg</mediaType> <mediaType>image/png</mediaType> </binary> </model> <instance> <xmlp:Envelope xmlns:xmlp="http://schemas.xmlsoap.org/soap/envelope/"> <xmlp:Header> <ads:bundle-id xmlns:ads="a_uri">http://example.com/cookie/53A6C2209</ads:bundle-id> </xmlp:Header> <xmlp:Body> <album_id>John's Great Adventure</album_id> <photo></photo> </SOAP-ENV:Body> </SOAP-ENV:Envelope> </instance> </xform> </head> <body> <xform:input ref="photo_upload/xmlp:Envelope/xmlp:Body/photo">Select Photo </input> <xform:submit xform="photo_upload"> Add to <output ref="photo_upload/xmlp:Envelope/xmlp:Body/album_id"> photo album</submit> </body>
Since the header elements of the eventual SOAP message appear in the instance they can be copied to submission. Moreover values in the headers can be edited (filled-in) by users or by the user agent on the user's behalf. For example, the user agent could fill in the digest value and signature value in a Digital Signature [SOAP-dsig].
Adding hidden XMLP header content to XHTML forms cannot use the XHTML
type=hidden solution now used in XHTML forms. Under
the value field of such an input field is written into the form body. To parallel
the proposal for XFORMs, we need to provide a prototype for the XMLP message
that can be modified by the client.
For this purpose servers would place
xform:instance content in
head section of web pages. Within the body of the web page,
HTML 4.0.1 form elements would have one additional attribute named
whose value would be an XPATH to the XML data within the XMLP body of the
A typical value would be "
This attribute gives the browser's submission logic a means for locating the
data within prototype message. Within the form,
control name would appended to the instance attribute value to locate the the
slot in the message that their data is designed to fill. (Incidently this provides
an intermediate point for the XHTML to XFORMs transition).
Two cases have to be satisifed in the XHTML case. First we need to show that recently developed existing browsers would not be broken by XMLP-related content. Second we need to show that new browsers would be able perform as XMLP senders similar to a full XFORMs client.
Existing browsers, under their usual approach of ignoring content the cannot
understand, may accept an XMLP message prototype in the
of downloaded pages:
User agents do not generally render elements that appear in the HEAD as content.
Similarly, the proposed form
instance attributes should be transparent:
If a user agent encounters an attribute it does not recognize, it should ignore the entire attribute specification (i.e., the attribute and its value). [HTMLExtension]
Thus it seems that existing browsers, to the extent that the follow the HTML 4.0.1 standard, will ignore the added text needed to support XMLP submission. Furthermore they should operate correctly as forms under HTML 4.0.1. They won't of course send XMLP messages on submission.
Future browsers with minor extension could submit XMLP messages. At submission,
the values of form input elements would simply be placed in the appropriates
slots as identified above and the entire message posted to the address given
In reality, since there is no open XHTML follow-on other than XFORMs, the acceptance of this aspect of our proposal depends on the interests of users and browser implementors.
 XML Protocol Activity
 XForms - the next generation of Web forms
 XForms 1.0: Data Model
W3C Working Draft, 6 April 2000
 XForms Requirements
W3C Working Draft, 21 August 2000
 SOAP - Simple Object Update Protocol
 SOAP Messages with Attachments
Paul V. Biron and Ashok Malhotra. Candidate Recommendation: XML Schema Part 2: Datatypes. Available at: http://www.w3.org/TR/xmlschema-2. 2000.
Form content types of the HTML 4.0.1 specfication.
Soap Security Extensions: Digital Signature
HTML 4.01 Specification B.1 Notes on invalid documents
Within the XFORMs proposal, the XMLP headers naturally fit in to the
child element of the
xform element. The XFORMs approach
uses a template for the form in the header for the web page containing the form.
This template specifies the form datatypes and initial values for form entries.
Also specfied is the submission protocol under the
This element includes a
submissionExtension child that can carry
the XMLP headers. The simple procedure of placing the XMLP headers to be sent
with the message verbatim within a submissionExtension element will suffice
for headers with XML content. The XMLP headers must not be immediately enclosed
in a XMLP envelope; this will insure that the headers are not intended for the
forms client. The XMLP headers, as an extracted string, must be well-formed.
method=postXMLP The forms client will copy the characters
submissionExtension into the XMLP message envelop just
above the XMLP body.
Here is an example:
<xform xmlns="http://www.w3.org/2001/02/xforms" id="poll"> <submit> <target>"http://example.com/app1"<target/> <submitExtension> <SOAP:Header> <bundle-id>http://example.com/cookie/53A6C2209</bundle-id> </SOAP:Header> </submitExtension> </submit> <model> <simple> <number name="choiceCode" enum="closed"> <value>-1</value> <value>10</value> <value>20</value> <value>30</value> </number> </simple> </model> </xform>