W3C home > Mailing lists > Public > www-forms-editor@w3.org > February 2002

Proposal to allow xsd:anyURI as allowable type for upload

From: Klotz, Leigh <Leigh.Klotz@pahv.xerox.com>
Date: Wed, 13 Feb 2002 17:07:01 -0800
Message-ID: <51B8ABCE456FD111899900805F6FD6EE0E80E84D@mercury.ADOC.xerox.com>
To: "'www-forms-editor@w3c.org'" <www-forms-editor@w3c.org>
The XForms 1.0 last-call draft requires that the binary data be transmitted
in, at best, base64, and that it be inside the XML instance.  

One of my proposed applications of XForms requires the transmission of XML
instance data and large amounts of binary data gathered by an <upload>
The data in my application, and I suspect in other voice, video, and image
applications as well, will be tens of megabytes, whereas the remainder of
the instance data will be small (a few thousand bytes at most).  

Having the binary data embedded in the XML instance data makes the data
harder to process and validate, because of the storage requirements, and
restricts the range of XML processing packages I can use to implement my

The XForms 1.0 last-call draft allows the legacy POST of multipart/form data
as in XHTML 4.01 and XHTML 1.1 forms with <input type="file"... >. Although
this meets requirement to move binary data out of the XML instance, the
mechanism is deprecated in XForms 1.0 last call, and furthermore does not
provide XML instance data.

Therefore, I propose a mechanism for allowing the separation of the large
binary data from the XML instance, namely allowing XForms model to specify
by type that the XForms Processor refer to the <upload> data by URI instead
of base64 or hex encoding.

An XForms Processor may choose to provide this URI by generating it locally
and offering a service such as HTTP to serve up the content, or it may
choose to use <submitInfo mediaType="multipart/related"> and send the
content along with the text/xml instance data according to RFCS 2387, 2111,
and 2557 ([1] [2] [3] [4] [5]) or it may choose some other method of
generating the URI.  

This proposal does not encompass such methods; it proposes changes to the
XForms specification so that an interoperable implementation of large binary
data form submission can be developed, and is independent of any
implementation of generation or interpretation of the URI.

I note that the xsd:base64Binary and xsd:hexBinary restriction on upload is
not enforced in the XForms Schema, so no changes are necessary in the XForms

Proposed Changes
1. Section 8.5 "upload"
I propose that section 8.5 be changed to say the following:
     Data Binding Restrictions: This form control can only be bound to
datatypes xsd:base64Binary, xsd:hexBinary, 
     or xsd:anyURI, or types derived by restriction from these.

2. Section "Binary Content" 
I propose that section 4.4.1 be changed to add the following:
    Instance data nodes with values of the type xsd:anyURI are allowed, but
the mapping of URI to binary content resource
    is not specified here.  



With Mikko Honkala's proposed modifications for additional binding to
mediaType and fileName[6], the current specification would define the
following XForms fragment

   <upload ref="document">
    <mimeType ref="@mimetype"/>
    <fileName ref="@fileName"/>
   <input ref="budgetCenter">
   <input ref="docket">

resulting in the following instance

    <document mimetype="image/tiff"
    ... and so on for 38 more megabytes...

With my proposed changes 1 and 2, the following would be allowed:

   <upload ref="document">
    <mimeType ref="@mimetype"/>
    <fileName ref="@fileName"/>
   <input ref="budgetCenter">
   <input ref="docket">

This could result in the following instance, where the URI is determined by
the XForms processor:

    <document mimetype="image/tiff"

[1] Methods For Sending Out of Band Binary with XForms
[2] SOAP Messages with Attachments
[3] The MIME Multipart/Related Content-type
[4] Content-ID and Message-ID Uniform Resource Locators
[5] MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
[6] Files sent with <upload> do not include mime type or file name
Received on Wednesday, 13 February 2002 20:07:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:03 UTC