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

Unlike all the other types that I classify as major types,
xs:integer
is not a primitive type but a derived type. It is derived by restriction from
xs:decimal
. This means that every valid
xs:integer
is also a valid
xs:decimal
, and anywhere that an
xs:decimal
can be used, an
xs:integer
can be substituted. The actual nature of the restriction is that the
xs:integer
type contains all
xs:decimal
values that have no significant digits after the decimal point.

The
xs:integer
type follows the pattern of the other numeric types, in that all the arithmetic operators and functions, when applied to an
xs:integer
argument (or to two
xs:integer
operands) produce an
xs:integer
as their result.

The main exception to this is division. XPath 2.0 provides two division operators. The
div
operator treats integer operands as
xs:decimals
, and produces an
xs:decimal
result (so
5 div 2
is
2.5
). The
idiv
operator (for integer division) produces an
xs:integer
result, so
5 idiv 2
is
2
. Closely related to this is the
avg()
function: the average of a sequence of
xs:integer
values is an
xs:decimal
.

xs:QName

The
xs:QName
type is a rather specialized type whose values hold XML qualified names.

An
xs:QName
has two forms. In its lexical form, it consists of either a simple local name (such as
product
) or a local name qualified by a namespace prefix (such as
mfg:product
). In its expanded form, it holds two significant components: a namespace URI (possibly null) and a local name, but it also retains the prefix so that the original lexical representation can be reconstituted on output.

There is no direct string representation of the expanded value, though in some interfaces (for example in the Java JAXP interface) expanded QNames are represented in a notation devised by James Clark, of the form
{namespace-uri}local-name
; for example,
{http://www.mfg.org/ns}product
.

This type is unusual (and, one might add, a great nuisance) because it is not possible to translate between the lexical form and the internal value space without having additional context information. A schema validator gets this context information from the namespace declarations that surround the element or attribute where the QName appears. For XSLT processors, which have the job of extracting parts of a document and copying them into different places, this dependency on context information causes no end of hassle: it isn't safe to copy a QName to a new location unless you also copy its context information. This is why the spec devotes so much attention to the arcane matter of namespace nodes. It's also for this reason that there are restrictions on what you can do with an
xs:QName
—for example, you can't have a parentless attribute node of type
xs:QName
because there would be nowhere to put the namespace bindings.