Re: [xsl] question about XSLT namespace
There have been strong arguments against this, see for example
Suppose I have defined a template rule in an XSLT 2 stylesheet (a XSLT
software library if you will), and Ibve been importing this stylesheet
from other stylesheets for some time.
Suppose there are different namespace URIs for XSLT 2 and 3, with
prefixes xsl2 and xsl3.
The importing stylesheet did something along the lines
<xsl2:when test="@bar = 'baz'">
delegating to a template rule of the imported stylesheet for the
Then the need arises to do trigonometric computations in the imported
library. Therefore I switch it to XSLT 3.0 and change the namespace
prefix to xsl3 accordingly. Do I need to change all XSLT 2 stylesheets
that import it so that their rules are in the xsl3 namespace?
Either the XSLT processor must raise an error if an xsl3 stylesheet is
imported from an XSLT 2 stylesheet, or it needs to extend its template
matching rules that templates in any of the namespaces that pertain to
the prefixes xsl, xsl2, and xsl3 will be treated as being equivalent.
Then someone might ask on xsl list (or on xsl3 list?) whether it
wouldnbt simplify things if the different versions of the language were
denoted by a version attribute but otherwise the namespace was the same.
There is great value in being able to seamlessly combine code that is
written in different versions of the language, provided that the
processor supports all of them.
If thatbs an issue, if your XSLT 2 stylesheet should still run (without
the new feature that depends on trigonometry) on processors that donbt
support XSLT 3, you can maintain a fallback version of the library and
do something like this:
use-when="xs:decimal(system-property('xsl:version')) ge 3.0"/>
use-when="xs:decimal(system-property('xsl:version')) lt 3.0"/>
Both libraries will probably import a third stylesheet into which you
put the common functionality.
How would you do this importing in the alternative universe with
different namespaces and no 'xsl:version' system property?
An XSLT 2 processor might be required to ignore any xsl3:import, but an
XSLT 3 processor will import both and overwrite all the rules,
functions, variables, keys, etc. of mylib.xsl with those found in
mylib_xslt3.xsl, by means of their higher import precedence. This is
inefficient. You will get a warning that the common library stylesheet
is imported more than once.
This is just one aspect. Ibm sure youbll find other replies in the
archives, and, as Geert just pointed out and Ibm proving right now,
youbll get more replies like this.
On 15.06.2018 07:30, Mukul Gandhi gandhi.mukul@xxxxxxxxx wrote:
B B We all know that, the XSLT namespace is
http://www.w3.org/1999/XSL/Transform. This has remained same, for 1.0,
2.0 & 3.0 versions of the XSLT language. My feeling is, that every major
XSLT language version should have a different language namespace URI
(maybe, we could make the year different for different XSLT language
versions). Keeping the language namespace same, gives me a feeling that
XSLT 3.0 specific language elements can be used in XSLT 1.0 & 2.0
I know that, specifyingB xsl:stylesheet version="1.0" or version="2.0" or
version="3.0" might disambiguate the XSLT language namespace concern.
But it would be great, to know the arguments in favor of keeping the
XSLT namespace same across different versions of the language.
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
(by email <>)
GeschC$ftsfC<hrer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930
GeschC$ftsfC<hrer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt