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

Where the source document includes an
IDREFS
attribute, it is possible to locate all the referenced elements at once. For example, if the

element has an attribute
authors
which is an
IDREFS
attribute containing a whitespace-separated list of author ids, the relevant

elements can be retrieved and processed using a construct such as:

See Also

key()
on page 812

idref()
in the following section

idref

The
idref()
function performs the inverse operation to the
id()
function: it locates all the nodes in a document that contain
IDREF
or
IDREFS
values referencing a given
ID
value.

Signature

Effect

If the
idrefs
argument is supplied as a node, or a sequence of nodes, then the values of the nodes are automatically atomized by the function calling mechanism. The argument can thus be supplied as any of the following:

• A string containing an ID value
  
• A node containing an ID value
  
• A sequence of either of the above
  

The function locates element and attribute nodes that have the
is-idref
property and that contain an ID value equal to one of the supplied strings. Note that when an attribute node is matched, it is the attribute node that is returned by the function, not the containing element.

In a schema-aware processor, both elements and attributes can have the
is-idref
property: they will be given this property if they have a content type that is either
xs:IDREF
or
xs:IDREFS
, or a type derived from these types. In a non-schema-aware processor, only attribute values can be recognized as
IDREF
or
IDREFS
attributes, and they are recognized as a consequence of validation using a DTD.

It is not an error if there is no node that references one of the target
ID
values (or even if there is no node that has this
ID
value). In this situation, there will simply be no node in the resulting sequence corresponding to this value. In the simplest case, where there is only one candidate
ID
value supplied, the resulting sequence will be empty if the document contains no reference to this
ID
value.

If the second argument is supplied, the nodes that are returned will come from the same document as the node supplied in this argument. This must be a node in a tree whose root is a document node. The default for this argument is the context node: a runtime error is then reported if the context item is undefined or if it is not a node. The nodes in the supplied
target
argument will often come from the same document, but this is not required.

IDs and Validation

ID
and
IDREF
values only really work properly if the source document is valid (in the XML sense: meaning, loosely, that it obeys the rules in its own DTD or Schema). However, XPath is designed to allow invalid documents as well as valid ones to be processed. One possible kind of validity error is that an attribute of type
IDREF
or
IDREFS
may contain a value that is not a legal
ID
value. This situation is not an error as far as XPath is concerned; it just means that this function will never retrieve that node.

When no schema is used, a non-validating XML parser isn't required to read attribute definitions from an external DTD. In this situation the XSLT processor will assume there are no
IDREF
or
IDREFS
attributes present, and the
idref()
function will always return an empty result. If this appears to be happening, check what options are available for configuring the XML parser, or try a different parser. Most good parsers will report the attribute type, even though it isn't absolutely required by the XML standard.

Example

Consider the following data, representing part of a family tree (
idref/source.xml
):

Given a

element as the context node, and assuming that the
ref
attributes have type
xs:IDREF
, it is possible to find the children of a person as:

Note the need to check the names of the parent and grandparent elements. Without this check, one would find relatives other than the children, for example the spouse. This is because an
IDREF
in XML doesn't capture any information about which relationship is being modeled; that is implicit in the context in which the
IDREF
appears.

See Also

id()
on page 802

implicit-timezone

The
implicit-timezone()
function returns the value of the implicit timezone from the runtime context. The implicit timezone is used when comparing dates, times, and dateTimes that have no explicit timezone.

Signature

This function takes no arguments.

Effect

Timezones are represented as values of type
xs:dayTimeDuration
, in the range
-PT14H
to
+PT14H
. This function simply returns the value of the implicit timezone from the runtime XPath context. The way that the value is initialized is determined by the implementation; it might be set using an API, or it might simply be taken from the system clock. The idea is that the implicit timezone should be the timezone in which the user is located, but when users are scattered around the world it is not always possible to achieve this.

There are a number of operators and functions that make use of the implicit timezone. The most obvious is when comparing an
xs:dateTime
that has a timezone to one that does not; in this case, the
xs:dateTime
without an explicit timezone is assumed to represent a time in the implicit timezone. This means that an expression such as:

can be read as “if the current time in the user's timezone is after midday. …” (The result of the
current-time()
function will always be in the implicit timezone.)

Example

If the system is correctly configured for a user situated in New York, with no daylight savings time in operation, the function
implicit-timezone()
will return
–PT05:00
.

See Also

adjust-date/time/dateTime-to-timezone()
family of functions on page 715

current-date/time/dateTime()
family of functions on page 738

timezone-from-date/time/dateTime()
family of functions on page 893

index-of

The
index-of()
function returns a sequence of integers indicating the positions within a particular sequence where items equal to a specified value occur.

For example,
index-of((“a”,“b”,“c”), “b”)
returns 2.

Signature