Re: Serialization as multipart/related

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#Ser
>> ialization_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
>>
>>
>