Re: XForms 1.1: Behavior of replace=text for submissions that retrieve non-text

Hi Erik,

I quite like your suggestion to use a new attribute value for 
serialization: application/octet-stream .  I *think* it may allow us to 
replace my 'decode' MIME parameter.

I understand you want to use the data type of the referenced node, and 
that is of course a good way to eliminate the decode MIME parameter. 
However, I'd like to also be able to trigger this capability entirely with 
submission without using a type MIP or schema, for the sake of modularity 
and also because nothing about the data type implies compression.  So, I 
think the data type should be used if available and if no MIME parameter 
is specified, but the following should work:

<submission ref="some/node" serialization="application/octet-stream; 
content-encoding='base64-gzip'" method="put" resource="file:MyWord.doc" 
...

Notice that I switched from using 'decode' to 'content-encoding' as the 
MIME parameter.  I'm trying to say that you should serialize as a binary 
octet stream, but the bytes coming over the wire will be base64-gzip 
encoded.

Then, if the resource indicates an http server, it would be the receiving 
code's responsibility to base64 decode and gzip decode.  But for file:, 
XForms processor code itself gets to define what happens, and the default 
is to decode down to binary.  This seems very natural.

Now, coming back around to how I got into all of this was on the "get" 
side of the equation.  The easiest get actually comes from the upload 
control, like this:

<upload ref="some/node" mediatype="some/type; 
content-encoding='base64-gzip'" ...>

That would get an image, transform it into base64-gzip as the content 
encoding and put it into some/node.

Then, getting it back out of data and onto the wire is done by the above 
submission with the matching content-encoding MIME parameter, and getting 
it back out of data and onto the screen is done by the following output 
(assuming a rendering plugin for some/type):

<output ref="some/node" mediatype="some/type; 
content-encoding='base64-gzip'" ...>

Finally, suppose you want to do a "get", but rather than getting the 
binary resource from the local machine via an upload, you want to get it 
from either a server or from the local machine without using a form 
control?  This seems to be the domain of a submission like this:

<submission target="some/node" replace="text" method="get" resource="
file:MyWord.doc" ...>

In this case, the file system is used, and the result of the get is not an 
XML or text mediatype, so the submission will fail unless we define an 
encoding method.  The right one seems to be base64-gzip encoding as a 
default, but I can see where it would be nice to control this too.  How 
important is that to solve right away?  If it is important, I wonder if 
the right answer is something like this:

<submission target="some/node" replace="text/xml; 
content-encoding='base64-gzip'" method="get" resource="file:MyWord.doc" 
...>

What do you think?

Thanks,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
03/19/2008 10:23 AM

To
"Forms WG (new)" <public-forms@w3.org>
cc

Subject
Re: XForms 1.1: Behavior of replace=text for submissions that retrieve 
non-text







John,

Here are some further thoughts on binary serializations.

It is funny that you are mentioning this right now because just last 
week we implemented binary PUT and POST submissions in Orbeon Forms 
[1]. Our idea, though, was to use the "serialization" attribute on 
xforms:submission in a different way, in conjunction with the type of 
the source:

<bind nodeset="some/node" type="xs:base64Binary"/>
<submission ref="some/node" serialization="application/octet-stream" 
method="put" ...

or:

<bind nodeset="some/node" type="xs:anyURI"/>
<submission ref="some/node" serialization="application/octet-stream" 
method="put" ...

The "application/octet-stream" guarantees that the content is 
serialized as binary (you could imagine using other binary mediatypes, 
like image/png). The type of the source data specifies how it is 
extracted from the instance and converted to an actual stream of bytes.

Of course you can still use a mediatype attribute on the submission to 
set the actual type sent on the wire.

Being able to read binary data, then, would be a natural thing to 
support as well. How binary data is stored into the instance could 
also be done depending on the type associated with the destination node.

-Erik

[1] http://www.orbeon.com/ops/doc/reference-xforms-2#submission-binary

On Mar 18, 2008, at 5:19 PM, John Boyer wrote:

>
> See http://www.w3.org/TR/xforms11/#submit-evt-submit
>
> Fourth bullet of submission response handling says:
>
> For a success response including a body that is both a non-XML media 
> type (i.e. with a content type not matching any of the specifiers in 
> [RFC 3023]) and a non-text type (i.e. with a content type not 
> matching text/*), when the value of the replace attribute on element 
> submission is "text", nothing in the document is replaced and 
> submission processing concludes after dispatching xforms-submit- 
> error with appropriate context information, including an error-type 
> of resource-error.
>
>
> Why should this fail?  It seems natural to apply gzip compression 
> then base 64 encoding and then succeed at replacing the text instead 
> of failing.
> We could quibble about when to apply gzip (e.g. not images) or 
> whether to use hexBinary instead (e.g. when a datatype calls for 
> it), and these could even be configurable.
>
> But surely I should be able to obtain web resources with
>
> <submission method="get" ref="some/node" replace="text" 
> resource="some/image.png" ...
>
> and then show it with
>
> <output ref="some/node" mediatype="image/png; content- 
> encoding='base64-gzip'"/>
>
> And I should be able to do the same thing with non-image binary 
> files *if* I have a plugin for output that supports the mediatype.
>
> Frankly, the file: version of this submission should make the upload 
> control somewhat redundant, but we already seem to be able to get 
> such resources into the instance from the local file system using an 
> upload control:
>
> <upload ref="some/node" mediatype="image/*; content-encoding='base64- 
> gzip'"> ...
>
> Hmm. Wonder if we have a test for base64-gzip encoding behavior of 
> upload?
>
> Anyway, once we have a method="get" submission that can accept 
> binary data results, surely it should be possible for submission to 
> push binary data (to the web or to the file system) using something 
> like this:
>
> <submission ref="some/node/text()" serialization="application/xml; 
> decode='base64-gzip'" ...
>
> This would mean I could read a word processing document from the 
> file system, put it into XML in a compressed format, then I could 
> put the document back out to the file system in its original form. 
> Doesn't seem like a lot to ask.
>
> Cheers,
> John M. Boyer, Ph.D.
> Senior Technical Staff Member
> Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com
>
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/