W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2003

xsl:variable, content-constructor, baseURI

From: Volker Renneberg <volker.renneberg@unibw-muenchen.de>
Date: Tue, 25 Mar 2003 16:18:30 +0100
To: public-qt-comments@w3.org
Message-Id: <200303251618.30216.volker.renneberg@unibw-muenchen.de>

Hash: SHA1


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:

<import file="lib/b.xml"/>

<import file="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">

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 

(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:apply-templates select="$x">

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:apply-templates select="$x">

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 

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.


- --
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
Version: GnuPG v1.0.7 (GNU/Linux)

Received on Tuesday, 25 March 2003 10:23:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:24 GMT