Re: Serialization as multipart/related

We discussed in the call this bit of the spec:

    "A Content-Type header that represents the type of the attachment if
known, otherwise application/octet-stream."

There is vagueness in the use of "if known" here. What does it mean for the
type to be known? Where does it come from?

I think it would satisfy the intent of the multipart/related submission to
say that, at the time an upload control populates instance data with a URI
(or binary type, see below) corresponding to the file's content, it also
somehow associates with that instance data the file's content type *as
known by the upload control*. The upload control may or may know the exact
content type, but that is a separate question.

In practice, there are at least a couple of ways to do this, and we can
leave this implementation-dependent. For example:

- If your URI is a URL pointing to a local file, you could store the
content type as a URL parameter.
- You could have, out of band, a hashmap mapping from the URI to its
content type.
- You could store it as a custom property on the DOM node containing the
URI or binary type.

Interestingly, I just noticed that the spec doesn't say that the
multipart/related submission should work for xs:base64Binary or
xs:hexBinary content populated by upload, while  "11.5.7.3 Serialization as
multipart/form-data" does support that. That seems to be an oversight.

-Erik



On Tue, Feb 14, 2017 at 12:27 PM, Steven Pemberton <steven.pemberton@cwi.nl>
wrote:

> How about a different type xf:uploadURI (or something) that textually
> contains a URI, but that <submission/> knows to treat as a pointer to
> binary context that must be submitted instead of the URI?
>
> Steven
>
>
> On Wed, 21 Dec 2016 06:05:27 +0100, Erik Bruchez <ebruchez@orbeon.com>
> wrote:
>
> All,
>
> Following-up on this, I found this message from 2013 which I write in
> response to an action item:
>
>     https://lists.w3.org/Archives/Public/public-forms/2013May/0014.html
>
> I don't know if we want to do any of this at this point, but I thought I
> would point out to that email as it provides a solution to help with
> creating multipart submissions.
>
> -Erik
>
> On Wed, Dec 7, 2016 at 10:22 AM, Erik Bruchez <ebruchez@orbeon.com> wrote:
>
>> Ok, so the first thing is that our implementation doesn't yet support
>> `multipart/related`.
>>
>> However the same issue arises with `multipart/form-data`, as the spec
>> says:
>>
>>     "Element nodes of any datatype populated by upload […]"
>>
>> We have some notes in our code which say:
>>
>> > See this WG action item (which was decided but not carried out):
>> "Clarify that upload activation produces
>> > content and possibly filename and mediatype info as metadata. If
>> available, filename and mediatype are copied
>> > to instance data if upload filename and mediatype elements are
>> specified. At serialization, filename and
>> > mediatype from instance data are used if upload filename and mediatype
>> are specified; otherwise, filename and
>> > mediatype are drawn from upload metadata, if they were available at
>> time of upload activation"
>> >
>> > See:
>> > http://lists.w3.org/Archives/Public/public-forms/2009May/0052.html
>> > http://lists.w3.org/Archives/Public/public-forms/2009Apr/
>> att-0010/2009-04-22.html#ACTION2
>> >
>> > See also this clarification:
>> > http://lists.w3.org/Archives/Public/public-forms/2009May/0053.html
>> > http://lists.w3.org/Archives/Public/public-forms/2009Apr/
>> att-0003/2009-04-01.html#ACTION1
>>
>> I think that John argued at the time that it wasn't necessary and/or was
>> too late to clarify the spec. But I have always felt that the spec was not
>> clear enough for implementers in this respect, which is confirmed by
>> Steven's raising of this issue.
>>
>> In our implementation, we also have these notes:
>>
>> > The bottom line is that if we can find the xf:upload control bound to a
>> node to submit, we try to get
>> > metadata from that control. If that fails (which can be because the
>> control is non-relevant, bound to another
>> > control, or never had nested xf:filename/xf:mediatype elements), we try
>> URL metadata. URL metadata is only
>> > present on nodes written by xf:upload as temporary file: URLs. It is
>> not present if the data is stored as
>> > xs:base64Binary. In any case, metadata can be absent.
>> >
>> > If an xf:upload control saved data to a node as xs:anyURI, has
>> xf:filename/xf:mediatype elements, is still
>> > relevant and bound to the original node (as well as its children
>> elements), and if the nodes pointed to by
>> > the children elements have not been modified (e.g. by xf:setvalue),
>> then retrieving the metadata via
>> > xf:upload should be equivalent to retrieving it via the URL metadata.
>>
>> So we use two ways to implement the "magic":
>>
>> - we store metadata (mediatype, filename, size) as URL parameters when
>> using xs:anyURI
>> - we look for `xf:upload` controls bound to instance data at submit time
>> (and they hold metadata as well)
>>
>> There might be other ways to achieve this (such as associating metadata
>> to instance data nodes). The bottom line is that is is out-of-band
>> information and the spec would benefit by being clearer on this point.
>>
>> -Erik
>>
>> On Thu, Dec 1, 2016 at 9:53 AM, Steven Pemberton <steven.pemberton@cwi.nl
>> > wrote:
>>
>>> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#
>>> Serialization_as_multipart.2Frelated
>>>
>>> "Binary content from xs:anyURI instance nodes populated by the upload
>>> (see The upload Element) control is serialized in separate parts of the
>>> [RFC 2387] multipart/related message."
>>>
>>> Upload says:
>>> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#
>>> The_upload_Element
>>> "When bound to an instance data node of type xs:anyURI (or a type
>>> derived by restriction thereof), a URI is placed in the content of the
>>> node."
>>>
>>> So how is the serializer meant to know if an anyURI is one from upload
>>> or not?
>>>
>>> Steven
>>>
>>>
>>
>
>
>
>