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

Hi John,

Not requiring a type on the data may be reasonable, but I think that  
your current proposal does not quite address that.

Let's assume PUT here. There are two sides to the equation:

1. The format of the source data in the instance data
2. The format of the data on the wire

It seems to me that in order to ensure reasonable flexibility, we need  
a mechanism to specify both sides.

My use of the type tries to handle #1. Your use of content-encoding  
addresses #2, but not #1.

If you are using GET to retrieve the data from a server, there is an  
assumption with HTTP that the data will be decoded before being made  
available to the client, so even if the server uses a content- 
encoding, the data will be decoded before being stored in the instance  
data. So you still need a way of specifying that you want the data in  
the instance stored as base64 gzip.

In addition, I am a little wary of the "base64-gzip" content-encoding  
as I only found references to this on IBM web sites ;-) HTTP 1.1  
specifies [1] only the following content codings:

   gzip, compress, deflate, identity

HTTP 1.1 further specifies that IANA is the official repository for  
content codings. The current list [2] just adds pack200-gzip to HTTP  
1.1 and does not include base64-gzip.

-Erik

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5
[2] http://www.iana.org/assignments/http-parameters

On Mar 19, 2008, at 11:39 AM, John Boyer wrote:

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

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

Received on Tuesday, 25 March 2008 18:33:57 UTC