Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
To reduce the problems associated with
xs:QName
, the XPath type differs from the XML Schema definition by maintaining the namespace prefix as part of the value. The prefix plays no part in comparisons, but it is used when converting the value to a string. This means that
xs:QName
values, like all other atomic values, can always be converted to a string, which greatly reduces the number of special rules needed to handle tree construction and serialization.
One of the ideas behind defining
xs:QName
as a primitive type in XML Schema was so that the XML infrastructure would know which parts of the document have dependencies on namespace declarations, and would therefore be able to ensure that the relevant namespace declarations are kept around when data is copied. Unfortunately this doesn't work, because you can have namespace-sensitive data in a document without declaring it as an
xs:QName
. For example, if your document contains XPath expressions (which it will do if it happens to be a stylesheet, but it's not uncommon to find them in other kinds of document as well), then it will necessarily contain namespace-sensitive content that isn't flagged as such, because an XPath expression is more complex than a simple
xs:QName
.
What operations does XPath support on
xs:QName
values?
node-name(.) = QName(“http://www.mfg.org/ns”, “product”)
is comparing two
xs:QName
values. This is much more reliable than the test:
name(.) = “mfg:product”
which could go wrong for two reasons: it's dependent on the choice of namespace prefix, and it's doing a string comparison using the default collation, which might compare strings such as
product
and
Product
as equal if that's the way it's been set up. There's more detail on collations in the next section, which discusses the
xs:string
type.
You can convert a string to a QName, but only if you write it as a string literal. For example, you can write
xs:QName(“mfg:product”)
, which will produce the expanded QName whose local-name is
product
, and whose namespace URI is the namespace URI corresponding to the
mfg
prefix. The reason for this restriction is to ensure that the conversion can be done at compile time, when the namespace context is known. In XSLT there are plenty of other places where the namespace context has to be retained at runtime, so it would have been no great hardship for implementors to avoid limiting it this way; but the restriction isn't a great hardship for users either because the
QName()
function provides the ability to construct any QName dynamically knowing the namespace and local name.
xs:string
A string value in XPath is any sequence of zero or more characters, where the alphabet of possible characters is the same as in XML: essentially the characters defined in Unicode.
String values can be written in XPath expressions in the form of a literal, using either single quotes or double quotes, for example
‘John’
or
“Mary”
. In theory, the string literal can contain the opposite quote character as part of the value, for example
“John's”
. In practice, certainly in XSLT, XPath expressions are written within XML attributes, so the opposite quote character will generally already be in use for the attribute delimiters. For more details, see the section
StringLiteral
in Chapter 7, page 532.