- From: Volker Renneberg <volker.renneberg@unibw-muenchen.de>
- Date: Tue, 25 Mar 2003 16:18:30 +0100
- To: public-qt-comments@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! During developing a stylesheet which heavily relies on file inclusion (document()-function) I came across some problems in the XSL specification. Assume not all files are at the same location but spread over different directories. During transformation the stylesheet loads these documents and applies its templates to the content (and during this process again files may have to be imported and evaluated). The problem addressed here is how to find those files. The names of the files to be loaded are inside the XML documents (relative names!!!). May problem arises when recursively importing documents from different directories. Three examples will follow which actually should result in the same behaviour but do not. Let's use three simple files: a.xml: <import file="lib/b.xml"/> lib/b.xml: <import file="c.xml"/> lib/c.xml: Text: nothingblalblabla Stylesheet A processing file a.xml: <xsl:template match="import"> <xsl:variable name="x" select="document(@file, .)"/> <xsl:apply-templates select="$x"> ...parameters... </xsl:apply-templates> </xsl:template> This example works as expected: During transformation of document "a.xml" file "lib/b.xml" has to be imported and from there "c.xml". "b.xml" only knows the relative position of "c.xml" relative to its own position. Thus the base URI of the lib/b.xml/import-node has to be used. Using stylesheet A this works fine. (Yes I could move the document() call to the apply-templates node. However in my stylesheet case I have to do it that way as the actual loading and composition process is a little bit more complicated. The files presented here are just simplified examples showing the problem) The following is a slightly changed version of A. Now variable "x" will be constructed by content constructors and not via the select attribute. Now the transformation fails because the transformer forgets the base URI of the imported document. Thus while transforming "lib/b.xml" the file "c.xml" will be searched relative to the stylesheet URI (which may be somewhere but not "lib/") and not relative to "lib/b.xml". This is due to XSLT 2.0: 9.1 Variables and 9.4 Temporary Trees. Stylesheet B processing file "a.xml": <xsl:template match="import"> <xsl:variable name="x" /> <xsl:copy-of select="document(@file , .)"/> </xsl:variable> <xsl:apply-templates select="$x"> ..parameters... </xsl:apply-templates> <xsl:template> Now one may argue that <xsl:copy-of/> only copies elements and it is not supposed to copy the base URI. But as stated above I try do do all IO in a callable template. This leads to a the third possible stylesheet. Stylesheet C processing file "a.xml": <xsl:template match="import"> <xsl:variable name="x" /> <xsl:call-template name="load-file"> <xsl:with-param name="filename" select="@file"/> <xsl:call-template name="load-file"> </xsl:variable> <xsl:apply-templates select="$x"> ...parameters... </xsl:apply-templates> </xsl:template> In this example no node will be copied (in template "import") while calling the template but still the transformer will forget the base URI which gets returned correctly by the called tempalte "load-file". Ok "load-file" again works via <xsl:copy-of/> - to my knowledge there is no other way! To my mind there seem to be two problems: 1) XSLT 2.0 Spec, 9.1 Variables: Constructing a variable as it has been done in the second and third stylesheet results in an temporary tree which (XSLT 2.0 Spec, 9.4 Temporary Trees) does not copy the base URI of the original elements but changes it to the base URI of the variable binding element (which if understand it correctly is the base URI of the stylesheet). 2) I cannot check with Saxon because there is no way to generate the base-uri from the result of <xsl:copy-of/> without binding the result to a variable (which ignores the base URI). So I just assume that <xsl:copy-of/> forgets the base URI, too. Thus the current WD of XSLT 2.0 does not support an implicit way of propagating the base URI via variables or using <xsl:call-template/>. Doing more complicated things in XSL in conjunction with the document()-function leads to forgetting the base URI. Thinking of named templates as procedure like mechanisms returning data (maybe read from a file) this data will NEVER be correct according to the original one (i. e. missing base URI). The data has to be processed in the called template as far as the base URI-stuff is concerned. Please rethink the design of the XSLT 2.0 Specification in the eras touched by <xsl:variables/>/Temporary trees and named templates. To my mind <xsl:copy-of/> should copy the base use and temporary trees should not be assigned a common, data unrelated base URI. In case the data bound to a variable has it's own base URI this should be adopted. ciao Volker - -- Dipl.-Inform. Volker Renneberg University of the Federal Armed Forces, Munich 85577 Neubiberg, Werner-Heisenberg-Weg 36 Tel.: +49-89-60042253 - Fax.: +49-89-60044447 http://hypsipyle.informatik.unibw-muenchen.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+gHNGyX+5eQvzMeoRAhIRAKCwdfU+Mc2zKRomQYNd+Jrpx4A80wCgmAc3 qnWrXSXCCaNl4SXGws9Ziko= =hO13 -----END PGP SIGNATURE-----
Received on Tuesday, 25 March 2003 10:23:16 UTC