Re: Serialization as multipart/related

On reflection, I like the <part/> suggestion more and more.

<part/> with parameters


and optional <header/> children, so that <part/> becomes just a mini  
<submission/> as it indeed is.

The linked mail suggests disposition name and filename attributes as well.


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 Wednesday, 29 March 2017 12:08:15 UTC