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

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