XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (101 page)

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?

• You can compare two QNames for equality. This sounds trivial, but it is probably the most important reason for using them. The comparison checks both the namespace URI and the local name, and it ignores the prefix. Moreover, the proper rules are used for this comparison; it's not subject to the uncertainties that arise when comparing strings; for example, whether accents are significant and whether lower case compares equal to upper case. For example, the test:
  

• You can convert a QName to a string. This uses the prefix held as part of the value, if there is one, or returns an unprefixed name otherwise.
  
• You can construct an expanded QName from the namespace URI and local-name using the
  QName()
  function shown above, and you can extract these two components using the rather clumsily named functions
  local-name-from-QName()
  and
  namespace-uri-from-QName()
  .
  

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.