[xslt] Bug, top-level elements outside the XSLT namespace must be ignored
- From: "Karl O. Pinc" <kop meme com>
- To: xslt gnome org
- Subject: [xslt] Bug, top-level elements outside the XSLT namespace must be ignored
- Date: Tue, 01 Apr 2008 23:37:18 -0500
I believe I've found a bug. Please enlighten me if I'm wrong, I'm not
yet steeped in xml/xslt/etc.
Top-level elements not in the XSLT namespace must be ignored, but
$ ./xsltproc/xsltproc --version
Using libxml 20631, libxslt 10122 and libexslt 813
xsltproc was compiled against libxml 20631, libxslt 10122 and libexslt
libxslt 10122 was compiled against libxml 20631
libexslt 813 was compiled against libxml 20631
./xsltproc/xsltproc - <<EOF
<!--this better not be here!-->
compilation error: file - line 14 element template
element template only allowed as child of stylesheet
I would expect the above to produce "Hello ", ignoring the <x:ignore>
element because XSL Transformations (XSLT) Version 1.0
(http://www.w3.org/TR/1999/REC-xslt-19991116), Section 2.2, says: 'In
addition, the xsl:stylesheet element may contain any element not from
the XSLT namespace, provided that the expanded-name of the element has
a non-null namespace URI. ... Thus, an XSLT processor is always free
to ignore such top-level elements, and must ignore a top-level element
without giving an error if it does not recognize the namespace URI.'
Seems to me that ignoring the element means ignoring all it's children
The impact is that I cannot comment out sections of my xslt code.
This makes development and in-code documentation annoying. The
problem also, potentially, impacts cool xslt documentation tools like:
Note regarding the history of the bug.
The bug occurs in (where I first noticed it):
$ xsltproc --version
Using libxml 20627, libxslt 10119 and libexslt 813
xsltproc was compiled against libxml 20627, libxslt 10119 and libexslt
libxslt 10119 was compiled against libxml 20627
libexslt 813 was compiled against libxml 20627
but does not occur in:
$ xsltproc --version
Using libxml 20616, libxslt 10111 and libexslt 809
xsltproc was compiled against libxml 20616, libxslt 10111 and libexslt
libxslt 10111 was compiled against libxml 20616
libexslt 809 was compiled against libxml 20616
Karl <kop meme com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Technically, in the xmnls:x="x", the "x" is not an absolute URI
(RFC3986, section 3, 'the scheme and path components are
required, though the path may be empty', see also section 4.3).
According to http://www.w3.org/TR/2006/REC-xml-names-20060816
Namespaces in XML 1.0 (Second Edition), Section 2.2: 'The use of
relative URI references, including same-document references, in
namespace declarations is deprecated. Note: This deprecation of
relative URI references was decided on by a W3C XML Plenary Ballot
[Relative URI deprecation]. It also declares that "later
specifications such as DOM, XPath, etc. will define no interpretation
So, for the example to be valid, the attribute declaring the default
namespace should be written: xmnls:x="x:".
If I write the example that way it doesn't work either so the point is
moot, but I mention it anyway because I've gone to the trouble to
research it and it might someday be useful to someone.
This problem also (probably) breaks commenting things by adding
namespace extensions that do nothing into the xslt document. A
technique which may or may not also require using <xsl:fallback/>. I'm
not conversant enough in xml/xslt/etc to be sure I know what I'm doing
with this technique so I mention it here as an addendum.
There, that set it up so we can have comments. Like this one.
The above site is not on-line as I write this. IIRC it remarks
on how to interpret the xslt specifications regarding this technique
and further comments on when and when not <xsl:fallback/> is
If this were not "top level" we'd have to also have
somewhere in here.
[Date Prev][Date Next
] [Thread Prev][Thread Next