W3C home > Mailing lists > Public > public-forms@w3.org > May 2013

ACTION-1944 - Propose a solution to support submitting multipart-post messages

From: Erik Bruchez <erik@bruchez.org>
Date: Tue, 14 May 2013 17:50:08 -0700
Message-ID: <CAAc0PEXXHru-gk2wLgZO1j5TB6p3183f3zB4fxc6hRgL5MN5aQ@mail.gmail.com>
To: public-forms@w3.org, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
All,

This is in response to the action item in the title. See also the
original message from Alan [1].

XForms 1.1 already allows you to handle some multipart scenarios for
multipart/related [2] and multipart/form-data [3].

As things stand the XForms engine does most of the work automatically,
without configuration from the form author.

In particular, you cannot specify:

- the order of the parts
- the serialization for each part
- the content type for each part
- other headers, including content disposition (which controls also
form field name/filename)
- other types of multipart, including multipart/mixed

Any new feature we introduce must address all of the above.

The good news is that it doesn't seem very hard to allow more
flexibility. I suggest we introduce a new child element called
`<part>`.

Like the XForms 1.1 `<header>` child element:

- There can be one or more `<part>` elements.
- Each `<part>` element`
  - can produce zero or more parts, depending on whether its `ref`
returns zero or more items.
  - contains attributes specific to the part.

A `<part>` element` can contain a nested `<header>` element with
headers specific to the part.

In order for the parts to be used, the submission serialization must
start with `multipart/`.

I propose the following attributes on each part, with the same meaning
as the top-level attributes with the same names:

- `serialization`
- `mediatype`
- `encoding`
- `omit-xml-declaration`
- `standalone`
- `cdata-section-elements`
- `includenamespaceprefixes`

In addition, it would be good to provide a shortcut to specify the
Content-Disposition header when desired:

- `name`: to name a form field
- `filename`: to specify the name of a file part

If any of these two attributes is specified, the following
Content-Disposition header is generated, as applicable:

Content-Disposition: form-data; name="my-file-upload"; filename="my-picture.jpg"

Open questions:

- When applicable, should part-specific `validate` and `relevant`
attributes be supported per part as well?
- Should in any circumstance the name/filename/mediatype
parameters/headers be inferred from information available via
xf:upload, as is the case currently with multipart/form-data?
- Does this cause any problems for client-side implementations?

Feedback is welcome!

-Erik

[1] http://lists.w3.org/Archives/Public/www-forms-editor/2013Apr/0000.html
[2] http://www.w3.org/TR/xforms/#serialize-multipart
[3] http://www.w3.org/TR/xforms/#serialize-form-data
Received on Wednesday, 15 May 2013 00:51:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:08 UTC