- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Thu, 2 Oct 2003 12:00:08 +0200
- To: Rajasekhar Cherukuri <rcheruku@genesyslab.com>, public-qt-comments@w3.org
- Cc: xsl-editors@w3.org
- Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD17D@daemsg02.software-ag.de>
The XSLT unparsed-text() function returns a string, so it is clearly not suitable for this purpose; similarly the <xsl:result-document> instruction produces a document represented in the data model, and optionally serializes it, so this doesn't naturally meet your requirement either. If we wanted to provide something like this it would have to be done within the XPath data model and type system. The appropriate types for representing binary data are xs:binHex and xs:base64. This would suggest a function such as unparsed-binary() which loads a binary file and returns an xs:binHex value, and perhaps an instruction <xsl:output-binary-file> which writes an xs:binHex value as a binary file. I think the right thing to do with requirements such as this is to pioneer them as user-written extension functions (or instructions). If they prove useful and popular they will start to become standardized within libraries such as EXSLT (www.exslt.org <http://www.exslt.org> ). Only if there is real evidence that the requirement is a general one should we consider adding the functions to the core library. At present there are very many functions that some people might like and that we have chosen not to provide (for example, trigonometry functions), and I don't think we should add a function just because one user has a need for it. I would question whether there is really any value in XSLT being able to read and write binary files when it provides no functions or operators to actually manipulate their content. Michael Kay -----Original Message----- From: Rajasekhar Cherukuri [mailto:rcheruku@genesyslab.com] Sent: 01 October 2003 19:31 To: public-qt-comments@w3.org Cc: xsl-editors@w3.org Subject: un-parsed....function limitation... There is one particular usage quite useful while transforming files. What if the file need not be transformed but be preserved and transported. Use case: A binary image file that needs to be transported to another location as one of the multiple <xsl:result-document/> calls done within an XSLT. The XSLT could be picking up different/necessary images and sending across to another location based on the original XML transformations. Currently I did not come across a suitable way to do this in XSLT. One way to do this is doing the following: <xsl:result-document format="binary-output"XXXX/myimage.gif"><xsl:value-of select="unparsed-text('ZZZ/myimage.gif','binary')"/></xsl:result-document> But note that the encoding type I specificed is "binary" which is not part of the spec. Is there any other way to do this in XSLT or can the committee consider: a) either a new function "unparsed-binary(...)" or b) give "binary" option for the "unparsed-text(...)" function or c) give "binary" option and re-name "unparsed-text(...)" function to "unparsed-document(...)" Thank You Raja Thank you Raja
Received on Thursday, 2 October 2003 06:00:25 UTC