Re: Advanced File IO

Hi Rand,

You may have written to the wrong W3C working group, as we define XForms, 
not XSLT.  There is another working group for that.

However, the XForms submission element is roughly modelled on XSLT output. 
 When an XForms-bearing document arrives in a client processor, it allows 
the user to interact with some XML data, and when the user is done filling 
in the data, the user may activate a user interface control that invokes 
an XForms submission to serialize the resulting XML data and send it to 
the server-side for processing.

An ODF document is one such document format that may contain XForms.  The 
IBM Forms products are based on an XML format called XFDL (extensible 
forms description language), which is another document format that 
includes XForms.  The XFDL document can be serialized as XML, or as a 
base64-gzip encoded content that can be recognized by an XML parser once 
base64 decoding and gzip decompression are performed.

To allow an XForms submission to return the entire containing document, 
such as an ODF or an XFDL document, there is a particular event called 
xforms-submit-serialize [1] that host document processors (or form 
authors) MAY hook in order to provide content to return to the server in 
lieu of the normal XForms submission serialization content.

[1] http://www.w3.org/TR/xforms11/#submit-evt-submit-serialize

Host document processors MAY set up the event listener that provides this 
alternative content in response to the use of a recognized content type in 
the mediatype attribute.  For example, 

<xforms:submission ... mediatype="application/vnd.xfdl" ...

or

<xforms:submission ... mediatype="application/vnd.xfdl; 
encoding='base64-gzip'" ...


In the case of ODF, the document format itself is already based on 
compression, but compression alone conflicts with an unavoidable aspect of 
the design of the xforms-submit-serialize event.  It must be possible to 
provide the submission-body as a "string" content, so binary content is 
not allowed.  So, for ODF, the mediatype should still carry an encoding 
parameter, such as base64, so that the resulting payload is not strictly 
binary.

Note that document processors, such as ODF, are not required to do this. 
We're only saying that XForms has been designed to allow host document 
processors to support this feature.

Finally, it should be clear that this solution is about serializing a 
particular given host document, which is quite different from a 
requirement on XSLT to produce multiple documents zipped together into a 
single output bundle, so a solution to that separate problem is XSLT is 
not going to be as simple as setting a mediatype attribute value to the 
desired output type.

Best regards,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
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





From:   Rand McRanderson <therandshow@gmail.com>
To:     public-forms@w3.org
Date:   09/26/2011 12:05 AM
Subject:        Advanced File IO
Sent by:        public-forms-request@w3.org



Hi,

I was wondering if there were any plans for advanced file output
options for XSLT. My use case in particular is producing an ODF
document (here I'm assuming you know that ODF is a zipped collection
of files, the sum of which is mostly xml) from an xml base (or
possibly some other base given the abilities of analyze-string). It
would be cool if the stylesheet could make not only the main content
file for the ODF package, but also create the folder structure, all
the accessory files and zip the whole thing up. It would be specially
useful if you could also take image urls given within the xml base
document and use that to copy and place the files within the
appropriate locations so that the images show up in the ODF.

Now I use ODF as a sample use-case, but there area a number of other
formats which have a similar design (ie, zipped collection of files).
Moreover, I think there are plenty of use cases beyond compound
formats as well.

Sincerely,
John Thomas