Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] [XSL] xi:include coded in XSL
![[XSL] xi:include coded in XSL](/images/get_stylus.gif) 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
