[xsl] [XSL] xi:include coded in XSL

Subject: [xsl] [XSL] xi:include coded in XSL
From: Alain <alainb06@xxxxxxx>
Date: Tue, 01 Apr 2008 00:41:42 +0200
Hello list,

as I tried running my XSL transformations with my fresh new Ubuntu 7.10 install, I got the error :

Selected XML parser gnu.xml.stream.SAXParser does not support XInclude processing

Failed to compile stylesheet. 1 error detected.

The error message is quite clear, and I can't blame Saxon (which I'm using) for that.
So I had the idea to remove the -xi option for XInclude processing, and do it in XSL instead, of course without modifying the XML files, where xi:include would still remain coded. Sticking to the norm is easier for maintenance I think.

So what I did basically is add a few templates to my existing code :

<xsl:template match="/" mode="XInclude">
 <xsl:variable name="pass1">
   <xsl:apply-templates select="/" mode="XInclude">
     <xsl:with-param name="XML-uri" select="document-uri(/)" tunnel="yes"/>

 <xsl:apply-templates select="$pass1"/>

<!-- *******************

xi:include rewritten in XSL

<!-- This is identity transformation for nodes not in the xi: namespace -->

<xsl:template match="@* | node()" mode="XInclude">
       <xsl:apply-templates select="@* | node()" mode="XInclude"/>

<!-- Template for @parse='xml' of no @parse, xml being the default parsing mode -->
<!-- Note we have to pass the document-uri, otherwise if the URI in @href is relative, it would resolve against base-uri which is the path for xsl stylesheet, potentially different from the path where the xml document is -->

<xsl:template match="xi:include[not(exists(@parse)) or lower-case(@parse)='xml']" mode="XInclude">
<xsl:param name="XML-uri" tunnel="yes"/>

<xsl:apply-templates select="document(resolve-uri(@href,$XML-uri))" mode="XInclude">
<xsl:with-param name="XML-uri" select="document(resolve-uri(@href,$XML-uri))" tunnel="yes"/>

So it works, giving saxon an initial mode with im:XInclude... but my questions are:

Apart from the ERR XTDE1480 which could occur adding the above templates, this method looks safe to me.
/Don't complain about XTDE1480. I already did and Michael admitted in a other post that it *IS* a side-effect in XSL which is supposed not to bring side-effects, but explained the reason of this trade-off choice... and it is perfectly understandable, although for what I have to code, and the above templates are yet another example, I regret the choice made by the WG!/

Question 1: am I missing some other things, and would I bump into future problems for maintenance, with this substitute of the ill supported xi:include?

Question 2: did someone already wrote "xi:include in XSL" (or part of it)? I would rather xsl:import existing templates if enough debugged... and if it was made open source!
/Feel free to copy my templates if needed, but be warned they are not so well tested, and do a very small part of XInclude!/

Because of course, I coded only what I needed.
We could
- add a template to handle parse='text' with its @encoding attribute
- add a test if document is unavailable to render the xi:fallback
- add a template/test to complain about Xpointer being a nightmare to do in XSL and so not supported! (it would mean at least "dynamic XPATH" through some kind of 'eval' extension to do... and a lot of aspirin because it looks even more complicated than Xpath)
- try to test infinite recursion (xi:include including itself directly or not)... not so obvious... or do nothing and let the Java heap explode if infinite recursion done.
- file a request at W3C - XSLT WG so that we can have the 'accept' headers arguments when relevant on document() and unparsed-text() for XSLT3.0 and so be able to render the xi:include @accept and @accept-language (although we can "filter" language on the machine running XSL, it could be a good think to be able to do so on the "server" for bandwith sake... don't forget there are already huge XML/XSL sites -more than 0,5MB of XSL files on my Firefox cache-, such as https://www.wow-europe.com/fr/index.xml where XSL runs on your PC's browser)
- etc...

Or maybe you would have a sounder advise such as: "why not install Xerces on your Ubuntu and make it work with Saxon?" (answer is, I'm being lazy finding and reading the documentation for that difficult task ;-) )

Best regards.

Current Thread