- From: Erik Bruchez <erik@bruchez.org>
- Date: Tue, 14 May 2013 17:50:08 -0700
- 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:50:58 UTC