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

Usage and Examples

Because the XPath data model is defined in terms of sequences rather than sets, the ordering of the results of an expression is usually well defined. For example, the results of a path expression are always in document order, and the results of the
index-of()
function are defined to be in ascending numeric order. By enclosing such expressions in a call of
unordered()
, you can tell the system that you don't care about the order. For example,
unordered(preceding-sibling::*)
returns the preceding siblings of the context node in an arbitrary order, rather than in document order as usual. In the current version of Saxon, the preceding siblings will be returned in reverse document order, because that is the fastest way of finding them, but you should not rely on this behavior as it may vary from one product to another and might depend on other circumstances.

Some functions take a sequence as an argument and produce a result that doesn't depend on the order of the items in the sequence. Obvious examples are
count()
and
sum()
. In such cases, it's reasonable to assume that the optimizer will insert a call on
unordered()
automatically, and that you don't need to do it yourself:
count(unordered(X))
gives the same result as
count(X)
, and removes the need to sort the items in X into the right order.

The place where the
unordered()
function really comes into its own is in handling joins, for example:

or equivalently:

There are many different ways of writing join expressions in XPath, just as there are in SQL, and it's often the case that you are only interested in knowing which elements are selected, not in getting them back in a particular order. If you make it clear that you don't care about the order, by wrapping the join expression in a call on the
unordered()
function, then the system can select from a wider choice of possible access paths to retrieve the data. This is particularly true if there are indexes to the data, which is likely if it is stored in an XML database.

unparsed-entity-public-id, unparsed-entity-uri

These two functions are available in XSLT only
.

These functions give access to the public identifier and system identifier of unparsed entities declared in the DTD of the source document.

Changes in 2.0

The
unparsed-entity-public-id()
function is new in XSLT 2.0.

Signatures

The unparsed-entity-public-id() function

The unparsed-entity-uri() function

Effect

These two functions operate on the document containing the context node. An error is reported if the context item is undefined, or if it is not a node, or if it is a node in a tree whose root is not a document node.

If the document containing the context node includes an unparsed entity whose name is equal to the supplied string, then the
unparsed-entity-public-id()
function will return the public identifier of the entity if it has one (signaled by the
PUBLIC
keyword in XML), while the
unparsed-entity-uri()
function will return its system identifier. In all other cases, the functions return a zero-length string.

If the system identifier is given in the source XML as a relative URI reference, the XSLT processor should expand it into an absolute URI before returning it.

Usage

An unparsed entity is an entity defined in the DTD using a declaration of the form:

It's the
NDATA
(meaning “not XML data”) that makes it an unparsed entity; and because it is an unparsed entity, it can't be referenced using a normal entity reference of the form
&weather-map;
but must instead be referenced by name in an attribute of type
ENTITY
or
ENTITIES
; for example,

.

If you're using a schema-aware XSLT processor, and the document has been validated against a schema that defines the
map
attribute as being of type
xs:ENTITY
, then you can process the attribute using a rule such as: