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.
Regards, Justin Johansson
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.
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. </XSLT2-spec-snippet>
Michael Kay wrote:
"XML documents operated on by XPath must conform to the XMLNamespacesRecommendation [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."
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:output method="xml" omit-xml-declaration="yes"/>
<xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:template>
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).
Cheers 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"> <banana/> </:a:apple>
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.