If an XPointer begins with root(), the location source is the root element of the containing resource. If an XPointer omits any leading absolute location term (that is, it consists only of OtherTerms), it is assumed to have a leading root() absolute location term.

The origin keyword produces a meaningful location source for any following location terms only if the XPointer is being processed by application software in response to a request for traversal such as defined in the XLink specification. If an XPointer begins with origin(), the location source is the sub-resource from which the user initiated traversal rather than the default root element. This allows XPointers to select abstract items such as "the next chapter".

It is an error to use origin() in a locator where a URI is also provided and identifies a containing resource different from the resource from which traversal was initiated.

If an XPointer begins with id(Name), the location source is the element in the containing resource with an attribute having a declared type of ID and a value matching the given Name.

For example, the location term id(a27) chooses the necessarily unique element of the containing resource which has an attribute declared to be of type ID whose value is a27.

Note that if an XML document does not declare all attributes whose values are intended to serve as unique IDs, application software cannot reliably distinguish ID attributes from others with the same string value. Application software processing an XPointer must first attempt to locate an element with a declared ID attribute whose value matches that Name argument. If unable to do so, at user option the application software may locate any element having an attribute with the desired value.

If an XPointer begins with html(NAMEVALUE), the location source is the first element whose type is A and which has an attribute called NAME whose value is the same as the supplied NAMEVALUE . This is exactly the function performed by the "#" fragment identifier in the context of an HTML document.

All relative location terms operate using the same set of potential arguments: Relative location term arguments Arguments'(' InstanceOrAll (',' NodeType (',' Attr ',' Val)*)? ')'

Elements and other node types can be selected by occurrence number: Instance InstanceOrAll'all' | Instance Instance('+' | '-')? [1-9] Digit*

For a positive instance number n, the nth of the candidate locations is identified. For a negative instance number, the candidate locations are counted from last to first (in a manner that is specific to each keyword). If the instance value all is given, then all the candidate locations are selected. Numbers that are out of range cause the XPointer to fail.

XML sub-resources can be selected by specific node type as well as number: Node type NodeTypeName | '#element' | '#pi' | '#comment' | '#text' | '#cdata' | '#all'

The node type may be specified by one of the following values: Name

Selects a particular XML element type; only elements of the specified type will count as candidates. For example, the following identifies the 29th paragraph of the fourth sub-division of the third major division of the location source:child(3,DIV1).child(4,DIV2).child(29,P)

The following XPointer selects the last EXAMPLE element in the document:descendant(-1,EXAMPLE)

Among the node types, elements can contain other types, but no other types can contain anything but strings. Thus, for example, ancestor location terms locate only element node types, and descendant location terms navigate downward through elements (not other node types) to reach the desired element or non-element node type.

Selection by a named element type when possible is strongly recommended; see for more information.

Consider the following example: <!DOCTYPE SPEECH [ <!ELEMENT SPEECH (#PCDATA|SPEAKER|DIRECTION)*> <!ATTLIST SPEECH ID ID #IMPLIED> <!ELEMENT SPEAKER (#PCDATA)> <!ELEMENT DIRECTION (#PCDATA)> ]> <SPEECH ID="a27"><SPEAKER>Polonius</SPEAKER> <DIRECTION>crossing downstage</DIRECTION>Fare you well, my lord. <DIRECTION>To Ros.</DIRECTION> You go to seek Lord Hamlet? There he is.</SPEECH>

The following XPointers select various sub-resources within this resource: id(a27).child(2,DIRECTION)

Selects the second "DIRECTION" element (whose content is " To Ros.").

Candidate elements can be selected based on their attribute names and values. Note that non-element node types have no attributes, and so can never satisfy selection criteria that include attribute name or value specifications. Attribute Attr'*'any attribute name | Name Val'#IMPLIED'no value specified, no default | '*'any value, even defaulted | Name | SkipLitexact match

The Attr and Val arguments are used to provide attribute names and values to use in selecting among candidate elements.

If specified within quotation marks, the attribute-value argument is case-sensitive; otherwise not.

Attribute names may be specified as "*" in location terms in the (unlikely) event that an attribute value constitutes a constraint regardless of what attribute name it is a value for.

For example, the following location term selects the first child of the location source for which the attribute TARGET has a value: child(1,#element,TARGET,*)

The following XPointer chooses an element using the N attribute: child(1,#element,N,2).(1,#element,N,1)

Beginning at the location source, the first child (whatever element type it is) with an N attribute having the value 2 is chosen; then that element's first child element having the value 1 for the same attribute is chosen. Non-element node types cannot be chosen because they cannot have an N attribute.

The following example selects the first child of the location source that is an FS element for which the RESP attribute has been left unspecified:child(1,FS,RESP,#IMPLIED)

Note that the html keyword is a synonym for a very specific instance of attribute-based addressing such that the following two XPointers are equivalent: html(Sec3.2)root().descendant(1,A,NAME,"Sec3.2")

The descendant keyword selects a node of the specified type anywhere inside the location source, either directly or indirectly nested.

The descendant location term looks down through trees of subelements in order to end at the node type requested, not down through nested levels of intermediate PIs, comments, or text regions. The search for matching node types occurs in the same order that the start-tags of elements occur in the XML data stream: The first child of the location source is tested first, then (if it is an element) that element's first child, and so on. In formal terms, this is a depth-first traversal.

For example, the following XPointer selects the second TERM element with a LANG attribute whose value is DE, occurring within the element with an ID attribute whose value is A23:id(a23).descendant(2,TERM,LANG,DE)

If an instance number is positive, the search is depth-first and left-to-right. If an instance number is negative, the search is depth-first but right-to-left, in which the right-most, deepest matching element is numbered -1, etc. The order in which elements are examined corresponds to the ordering of the first tag encountered. Thus, the following example chooses the last NOTE element in the document, that is, the one with the rightmost end-tag: root().descendant(-1,NOTE)

If the last NOTE happens to be within another NOTE, the containing one is chosen, not the subelement, because it extends to a later point in the document.

The ancestor keyword selects an element from among the direct ancestors of the location source. For positive instance numbers, it counts upwards from the parent of the location source to the root of the containing resource. For negative instance numbers, it counts downwards from the root to the direct parent. Note that ancestor can never select the location source itself.

For example, the following XPointer first chooses the innermost element (nearest ancestor) properly containing the location source and having attribute N with value 1, and then the smallest DIV element properly containing that ancestor:ancestor(1,#element,N,1).(1,DIV)

The node type parameter for ancestor, if supplied, must be either #element or a particular element type name. If the current location source is an attribute, the element on which that attribute occurs is considered the first ancestor.

The preceding keyword selects a node of the specified type from among those which precede the location source. The set of nodes which may be selected is the set of all those in the entire document that occur or begin before the location source. For a positive instance number, it counts left from the location source; for a negative instance number, it counts right from the root element of the containing resource. The first delimiter or tag encountered, starting or ending, counts as an occurrence of that node.

For example, the following XPointer designates the fifth element that occurs or starts before the element that has an ID of a23: id(a23).preceding(5,#element)

Because all ancestors of the location source contain it and potentially other content, ancestors both "precede" and "follow" their descendants. Therefore, the following example selects the root element (probably among other nodes): id(a23).preceding(all)

The following keyword selects a node of the specified type from among those which follow the location source. The set of nodes which may be selected is the set of all those in the entire document that occur or end after the location source. For a positive instance number, it counts right from the location source; for a negative instance number, it counts left from the end-tag of the root element of the containing resource. The first delimiter or tag encountered, starting or ending, counts as an occurrence of that node.

For example, the following XPointer designates the second PI that occurs after the element that has an ID of a23:id(a23).following(2,#pi)

Because all ancestors of the location source contain it and potentially other content, ancestors both "precede" and "follow" their descendants. Therefore, the following example selects the root element (probably among other nodes): id(a23).following(all)

The psibling keyword selects a node of the specified type from among those which precede the location source within the same parent element. The nodes immediately contained by the same parent element are siblings; those siblings which precede the location source are its elder siblings, and those which follow it are its younger siblings.

For a positive instance number, psibling counts left from the most recent elder sibling to the eldest sibling. For a negative instance number, it counts right from the eldest sibling. The location term fails if the location source does not have at least as many elder siblings as the absolute value of the instance number.

For example, this XPointer designates the element immediately preceding the element with an ID of a23, as long as they share the same parent:id(a23).psibling(1,#element)

If the location source has at least one elder sibling, then the following location term designates the very eldest sibling:psibling(-1,#element)

This location term is synonymous with the following XPointer:ancestor(1,#element).child(1,#element)

The value all may be used to select the entire range of elder siblings of an element. For example, the following XPointer designates the set of elements preceding the element that has an ID of a23 and are contained by the same parent:id(a23).psibling(all,#element)

The fsibling keyword selects a node of the specified type from among those which follow the location source within the same parent element. The nodes immediately contained by the same parent element are siblings; those siblings which precede the location source are its elder siblings, and those which follow it are its younger siblings.

For a positive instance number, fsibling counts right from the most recent younger sibling to the youngest sibling. For a negative instance number, it counts left from the youngest sibling. The location term fails if the location source does not have at least as many younger siblings as the absolute value of the instance number.

For example, this XPointer designates the element immediately following the element with an ID of a23, as long as they share the same parent:id(a23).fsibling(1,#element)

If the location source has at least one younger sibling, then the following location term designates the very youngest sibling:fsibling(-1,#element)

This location term is synonymous with the following XPointer:ancestor(1,#element).child(-1,#element)

The value all may be used to select the entire range of younger siblings of an element. For example, the following XPointer designates the set of elements followed the element that has an ID of a23 and are contained by the same parent:id(a23).fsibling(all,#element)

A string location term may return parts of several elements. For example, a string that specified the 12 characters beginning at the "c" below would return the entire text content of the EMPH element, plus the text region that follows the EMPH inside the P:<P>Hello, <EMPH>cruel</EMPH> world.</P>

The XPointers shown below specify ordered lists of elements. The elements may or may not be contiguous; in the first case they probably are; in the second, they probably are not:id(sec2.1).child(1,list).child(all,list) id(div1).descendant(all,h3)

Note that a discontiguous series of elements such as this may be usefully implemented using the same underlying abstract type that would represent the results of a query in certain processing scenarios.

The following spanning XPointer selects everything from the last P element in one section through the first P in another:

Span locations are not subtrees of XML documents, nor are they mere content data strings. Thus, the result of a spanning selection cannot generally be expressed as a well-formed XML document, nor as a node or list of nodes from an element tree. This is because in general, some elements are neither "in" nor "out of" the span, but in fact are partly in it. For example, the example above includes the end of the element with id sec2.1, but not its start. Because of this, implementations that support spans cannot represent them merely as single nodes or as well-formed XML documents; instead they must represent them as pairs of locations or by some other means that can express their greater generality.

Some processing semantics that make sense for nodes or vectors of nodes may not make sense for spans. A browser could easily highlight just the character content of a span, but there may be no appropriate semantics to apply in an outliner or tree-oriented display.