W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 2003

RE: un-parsed....function limitation...

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Thu, 2 Oct 2003 12:00:08 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD17D@daemsg02.software-ag.de>
To: Rajasekhar Cherukuri <rcheruku@genesyslab.com>, public-qt-comments@w3.org
Cc: xsl-editors@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:56 GMT