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?

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