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


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

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!



Received on Wednesday, 15 May 2013 00:50:58 UTC