W3C home > Mailing lists > Public > public-forms@w3.org > March 2008

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

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 19 Mar 2008 10:23:40 -0700
Message-Id: <9AF1F7A9-5C7F-4737-8D80-29FBA352BE80@orbeon.com>
To: "Forms WG (new)" <public-forms@w3.org>


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


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


[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
Received on Wednesday, 19 March 2008 17:24:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:56 UTC