Hello list,
as I tried running my XSL transformations with my fresh new Ubuntu 7.10
install, I got the error :
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>
</xsl:variable>
<xsl:apply-templates select="$pass1"/>
</xsl:template>
<!-- *******************
xi:include rewritten in XSL
********************-->
<!-- This is identity transformation for nodes not in the xi: namespace -->
<xsl:template match="@* | node()" mode="XInclude">
<xsl:copy>
<xsl:apply-templates select="@* | node()" mode="XInclude"/>
</xsl:copy>
</xsl:template>
<!-- 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"/>
</xsl:apply-templates>
</xsl:template>
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.