Re: Serialization as multipart/related

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
>
>