Re: Serialization as multipart/related

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?


On Wed, 21 Dec 2016 06:05:27 +0100, Erik Bruchez <>  

> All,
> Following-up on this, I found this message from 2013 which I write in  
> response to an action item:
> 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 <>  
> 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:
>>> See also this clarification:
>> 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  
>> <> wrote:
>>> "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:
>>> "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

Received on Tuesday, 14 February 2017 20:28:14 UTC