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

Effect

If either the
sequence
or the
value
is supplied as a node, the nodes are atomized (to extract their values) as part of the function calling rules. This function therefore operates on a sequence of atomic values. It finds all the items in the atomized
sequence
that compare as equal to the supplied
value
under the rules of the
eq
operator, using the specified collation when comparing strings, or the default collation if none is specified. It then returns the positions of these items in ascending numeric order, using the usual convention of numbering positions starting at 1.

This means that if a sequence of nodes is supplied, and the nodes are list-valued (for example, a node whose type is
xs:NMTOKENS
), then the positions returned are the positions in the atomized sequence, which may not be the same as the positions of the nodes in the original sequence.

Untyped atomic values are compared as strings. Values that cannot be compared are treated as not equal. This means that if you search for an integer in a sequence of strings, the result is an empty sequence, not an error.

If no matching items are found, the result is an empty sequence.

Another way of writing this function, assuming that the default collation is used and that the values have already been atomized, would be:

Examples

Consider the source document:

and assume that this has been validated using a schema that defines the
colors
attribute as a sequence of strings.

You can take advantage of the fact that
index-of()
throws no error when comparing values that can never be equal. For example, if you have a list-of-union type that allows a sequence containing a mixture of strings and dates, testing
$sequence=current-date()
could throw an error if one of the items in the sequence is a string rather than a date. Rewriting the expression as
exists(index-of($sequence, current-date()))
solves the problem.

in-scope-prefixes

The
in-scope-prefixes()
function returns a sequence of strings, representing all the namespace prefixes that are in scope for a given element.

Changes in 2.0

This function is new in XPath 2.0. It is provided as a replacement for the namespace axis, which is now deprecated.

Signature

Effect

In the XPath data model, the namespaces that apply to a particular element are modeled as a set of namespace nodes: the name of the namespace node represents a namespace prefix, and the string value of the namespace node represents the namespace URI.

In XPath 1.0 it was possible to find the namespace nodes for a given element using the namespace axis. In XPath 2.0 the namespace axis has been deprecated. This was done because many implementations did not physically represent namespaces as nodes in memory, for efficiency reasons, and presenting the information as “virtual nodes” could be expensive, because of the overhead that nodes carry to maintain information about their identity, their parentage, their base URI, and so on. XPath 2.0 has therefore provided a new mechanism to allow applications to obtain the namespace information when it is needed.

The
in-scope-prefixes()
function returns all the prefixes of the in-scope namespaces for an element, or to express it in terms of the data model, the names of all the namespace nodes for that element. The order in which the names appear is unpredictable. The list will always include the name
xml
, since the XML namespace is in scope for every element. If there is a default namespace in force for the element, the list will also include the zero-length string to represent the default namespace. Any string in the result other than the zero-length string will be returned as an instance of
xs:NCName
.

The namespace URIs corresponding to each of these prefixes can be determined using the function
namespace-uri-for-prefix()
described on page 839.

Examples

Consider the source document below. Note that this includes a namespace undeclaration for the
soap
namespace, as permitted by XML Namespaces 1.1: