Re: Serialization as multipart/related

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

<part/> with parameters

  ref/bind
  serialization
  mediatype
  encoding
  omit-xml-declaration
  standalone
  cdata-section-elements
  includenamespaceprefixes

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.

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