Re: [xsl] NCName, QName and colons

Subject: Re: [xsl] NCName, QName and colons
From: Justin Johansson <procode@xxxxxxxxxxx>
Date: Tue, 23 Feb 2010 09:07:33 +1030
Okay, Michael, thanks for all of that and especially the test
outcome using Xerces.

>Direct your complaints to the vendor of the XML parser you are using!
I have no reason to complain to Java parser vendor though since I'm not
using Java for production use per se; just investigating what other
processors do to help validate & sanity check my own development (in C++).

Obviously the best source to rely on for checking is the spec :-)
so, FWIW, you gave me a clue where to look in the specs.

Investigating further to see what the XSLT 2 spec says about this,
it's handy to note section 4.1 XML Versions.  (Extract below.)

Accordingly it appears perfectly valid for an XSLT 2 processor to
both process as a source and serialize out the same by way of an
identity transform the following document which seems to me to
be valid XML 1.0 though not valid XML 1.0 + XML NS 1.0.


Justin Johansson


4.1 XML Versions

The XDM data model defined in [Data Model] is capable of representing either
an XML 1.0 document (conforming to [XML 1.0] and [Namespaces in XML 1.0])
or an XML 1.1 document (conforming to [XML 1.1] and [Namespaces in XML 1.1]),
and it makes no distinction between the two. In principle, therefore,
XSLT 2.0 can be used with either of these XML versions.

Construction of the XDM tree is outside the scope of this specification,
so XSLT 2.0 places no formal requirements on an XSLT processor to accept
input from either XML 1.0 documents or XML 1.1 documents or both.

This specification does define a serialization capability (see 20 Serialization),
though from a conformance point of view it is an optional feature. Although
facilities are described for serializing the XDM tree as either XML 1.0 or
XML 1.1 (and controlling the choice), there is again no formal requirement
on an XSLT processor to support either or both of these XML versions as
serialization targets.

Because the XDM tree is the same whether the original document was XML 1.0
or XML 1.1, the semantics of XSLT processing do not depend on the version of
XML used by the original document. There is no reason in principle why all
the input and output documents used in a single transformation must conform
to the same version of XML.

Michael Kay wrote:
Michael Kay wrote:
"XML documents operated on by XPath must conform to the XML
Recommendation [XML Names]."
Is this rule binding on an XSLT 2 processor as well (by virtue of its association with XPath 2)?

I was quoting from XPath 1.0; the rule is binding on an XSLT 1.0 processor by virtue of section 3 of XSLT 1.0 which says "The data model used by XSLT is the same as that used by XPath with the additions described in this section."

Source document:



<xsl:stylesheet xmlns:xsl=""; version="2.0">

<xsl:output method="xml" omit-xml-declaration="yes"/>

    <xsl:template match="node()|@*">
            <xsl:apply-templates select="node()|@*"/>




It seems the XML parser built in to JDK 1.6 isn't reporting an error for this source document. Really, no-one should be using this parser - it's thoroughly buggy. (I keep saying that, but I keep finding that despite my best intentions, I *do* use it, because it's so convenient.) The "real" Xerces from Apache throws this document out with an error, albeit not-all-that-helpful:

Error on line 1 column 2 of test.xml:
  SXXP0003: Error reported by XML parser: Element type "null" must be
followed by either
  attribute specifications, ">" or "/>".

The error messages that I posted when initiating this thread a few weeks ago gave me a forensic clue that the above might work (i.e. without an error occurring).

Justin Johansson

<original message> This seems rather odd.

Running an XSLT identity transform over the following source document with Saxon 9b produces the error underneath:

<?xml version="1.0" encoding="UTF-8" ?>

<:a:apple xmlns:a="foo">

Error on line 3 column 25 of foo.xml:
SXXP0003: Error reported by XML parser: The prefix ":a" for element ":a:apple" is not bound.TransformerException: net.sf.saxon.trans.XPathException: org.xml.sax.SAXParseException: The prefix ":a" for element ":a:apple" is not bound.

Obviously the source document is not valid XML but the error message is confusing.

Direct your complaints to the vendor of the XML parser you are using!

Apache Xerces again reports

"Element type "null" must be followed by either
attribute specifications, ">" or "/>"

for this one. In this case the Sun parser's error message is probably
better, though neither is wonderful.


Michael Kay

Current Thread