CARVIEW |
application/xml
,
text/xml-external-parsed-entity
,
or application/xml-external-parsed-entity
">
]>
This specification defines the XML Pointer Language (XPointer), the language to be used as the basis for a fragment identifier for any URI reference that locates a resource whose Internet media type is &media-types;.
XPointer, which is based on the XML Path Language (XPath), supports addressing into the internal structures of XML documents and external parsed entities. It allows for examination of a hierarchical document structure and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position.
This document is a Candidate Recommendation of the World Wide Web
Consortium. (For background on this work, please see the
The Working Group invites implementation feedback on this
specification. We expect that sufficient feedback to determine its
future will have been received by 4 March 2002. Comments on
this document should be sent to the public mailing list
This document is intended to be taken in conjunction with the IETF
XML Media Types Internet Draft
It is possible that XPointer might proceed to Recommendation status,
for use in sophisticated high-end pointing applications, without
being incorporated into
In the course of implementing the XPointer design as presented herein, were any aspects or subparts encountered which caused significant implementation difficulty?
If so, would eliminating some or all of the difficult-to-implement aspects or subparts leave a coherent design still useful for your needs?
Does your implementation experience suggest reasons why the
XPointer language as defined herein should not be recommended to the
IETF as the fragment identifier language for resources of type
text/xml
etc.?
In addition to the specific points above, any feedback on patterns of implementation and use of this specification would be very welcome.
For information about the XLink language with which
XPointer
For information about the requirements that informed development of
this specification,
see
A list of current W3C Recommendations and other technical documents can be
found at work in progress
.
Cambridge, MA: World-Wide Web Consortium, XML Linking Working Group, 1998-2001. Previous Working Drafts were developed by the XML Working Group.
Created in electronic form.
This specification defines the XML Pointer Language (XPointer), the language
defined to express fragment identifiers for any URI reference that
locates a resource
whose Internet media type is &media-types;
XPointer supports addressing into the internal structures of XML documents and external parsed entities. It allows for examination of a document's hierarchical structure and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position. In particular, it provides for specific reference to elements, character strings, and other XML information, whether or not they bear an explicit ID attribute.
The structures located with XPointer can be used as link targets or for
any other application-specific purpose. This specification does not constrain
what uses an application traversal
is the purpose of an XPointer at all is application-dependent. A formatted-text
browser traversal might scroll to and highlight the designated location; a
structure-oriented graphical viewer or a document-relationship display might
do traversal in quite a different way; and a search application,
parser, archival
system, or expert agent might use XPointers for other purposes entirely. (The
construction of linking elements in XML documents that associate arbitrary
resources, including XML documents and portions thereof, is defined
in a related
specification,
XPointer is built on top of the XML Path Language
Be used in URI references to address into resources
Address points and ranges as well as whole nodes
Locate information by string matching
Addressing into the internal structures of DTDs and the XML declaration is outside the scope of this specification.
XPointer is defined to be the fragment identifier language only
for resources
whose media type is &media-types;. However, it is expected that many
applications of
XML will define their own media types in order to indicate the particular
usage of XML they define. (Note that
In addition to XPath, the following standards have been especially influential in the development of this specification:
extended pointers,
locators for structured markup that underlie the initial design for
XPointer.
The addressing components of many other hypertext systems have also informed
the design of XPointer, especially
See the XPointer Requirements Document
The formal grammar for XPointer is given using a simple Extended Backus-Naur
Form (EBNF) notation, as described in the XML Recommendation ^
) metacharacter used in this notation (to denote
the complement of a set of characters) is not to be confused with the
circumflex
used to escape parenthesis characters in an XPointer.
The prototypes for XPointer functions are given using the same notation
used in the
This specification contains some explanatory text on the XPath language;
however, such text is non-normative. In the case of conflicts,
Some special terms are defined here in order to clarify their relationship
to similar terms used in the technologies on which XPointer is based.
Additional
XPointer-specific terms are defined in the flow of the text. Refer to
A position in XML information. This notion is defined fully later
(see point
to avoid confusion with
XPath positions.
An identification of all the XML information between a pair of points.
This notion is defined fully later (see
A generalization of XPath's
An unordered list of locations, such as produced by an XPointer expression.
This corresponds to the
The portion of an XML resource that is identified by an XPointer. For example, the whole resource being referred to is an XML document or external parsed entity, but a sub-resource might be a particular element or other location inside the document or entity. Following a link to such a sub-resource might result, for example, in highlighting or scrolling to that location in the document.
This section details processing and conformance requirements on XPointers, the fragment identifiers that are based on them, and the applications that create and process them.
Should need arise to refer to the namespace for objects defined by this specification, the normative namespace URI is https://www.w3.org/2001/05/XPointer
XPointer processing depends on
A string conforms to the XPointer specification if it adheres to
the syntactic
requirements and validity constraints imposed by this specification
(including
xpointer
and
xmlns
schemes, as prescribed by this specification.
For applications that recognize and interpret XPointers in URI references
that locate resources whose Internet media type is &media-types;,
full conformance
is required. The minimal conformance level is defined for the convenience
of XML-based Internet media types
The use of XPointers can give rise to several kinds of errors:
This specification does not constrain how applications deal with resource errors and sub-resource errors.
XPath expressions work with a data set that is derived from the elements and other markup constructs of an XML document. The XPointer model augments this data set. Both XPointers and XPath expressions operate by selecting portions of such data sets, often by their structural relationship to other parts (for example, the parent of a node with a certain ID value). XPointers use iterative selections, each operating on what is found by the prior one.
Selection of portions of the information hierarchy is done through axes,
predicates, and functions. An axis defines a sequence of candidates that might
be located; predicates then test for various criteria relative to
such portions;
and functions generate new candidates or perform various other tasks. For
example, one can select certain elements from among the siblings of
some previously
located element, based on whether those sibling elements have an attribute
with a certain value, or are of a certain type such as footnote
;
or select the point location immediately preceding a certain
para
.
The XPointer language is designed to be used in the context of URI references, which require encoding and escaping of certain characters. XPointers (in URI references) also often appear in XML documents and external parsed entities, which impose some escaping requirements of their own when the encoding limits the repertoire that can be used directly. Also, because some characters are significant to XPointer processing, escaping is needed to use these characters in their ordinary sense. The following sections describe the escaping necessary for these contexts.
The following contexts require various types of escaping to be applied to XPointers.
An XPointer might need to
contain characters that are significant in the XPointer syntax
itself. Parentheses
are significant to the XPointer language, so unbalanced parentheses ^
)
is used to escape such parentheses, literal circumflexes
%
)
escaped because it is the character used for escaping in URIs and IURIs. Thus,
when an XPointer is inserted into a URI reference or IURI reference,
any occurrences
of percent signs (%
) are replaced with %25
.
When an IURI reference containing an XPointer (perhaps in an
XML document) is ultimately converted to a fully escaped URI reference that
is suitable for resolution, any remaining characters not allowed in
URI references
Square brackets ([
and ]
) %5B
and %5D
respectively,
for compatibility
with applications that have not implemented the
If an XPointer appears in a URI reference or IURI reference in an
XML document
or external parsed entity,
any characters not expressible in the encoding used
The XPointer-processor handles undoing A. All other escaping is
undone (in reverse order of application) outside the processor. If the
result passed to the processor does not conform
to the syntactic rules for XPointers in this
specification, a
The set of characters for XPointers is necessarily the same as for XML,
namely
The disallowed characters include all non-ASCII characters, plus
the excluded
characters listed in Section 2.4 of
Each disallowed character is converted to UTF-8
Any bytes corresponding to a disallowed character are escaped with
the URI escaping mechanism (that is, converted to %
HH,
where HH is the hexadecimal notation of the byte value).
The original character is replaced by the resulting character sequence.
The following table shows the progressive escaping of an XPointer containing circumflexes, double quotation marks, and spaces so that it can appear in an XML document.
Context | Notation |
---|---|
Initial | The desired XPointer as it was
initially created: |
A. XPointer | With the circumflex escaped, as required
by this specification: |
B. IURI reference | Same as A (no percent sign found that
needs escaping): |
C. XML document | Double quotation marks escaped using
XML's predefined " entity reference (assuming that the
XPointer appears in an attribute value delimited by double quotation
marks): |
D. URI reference | With occurrences of the double
quotatation marks (%22 ), spaces (%20 ), and
circumflexes
(%5E )
escaped: |
The following table shows the progressive escaping of an XPointer containing
accented characters. The XPointer is intended to appear in an XML document
encoded in US-ASCII
, which does not allow the letter
é
to appear directly.
Context | Notation |
---|---|
Initial | The desired XPointer as it was
initially created: |
A. XPointer | Same (no circumflex or unbalanced parenthesis found that needs
escaping): |
B. IURI reference | Same as A (no percent sign found that
needs escaping): |
C. XML document | Represented in the US-ASCII
encoding; accented
letters are escaped with XML character
references: |
D. URI reference | With occurrences of the letter
é( %C3%A9 )
escaped: |
This specification defines one full form of XPointer addressing and two shorthand forms. The shorthand forms are defined as abbreviations of the full form, although applications need not convert an abbreviated form into the full form before evaluation. All error conditions apply as if the full form of the XPointer were specified.
The full form is described in
The internal structure of an XPointer is as follows.
The end of an
XPointer part is signaled by the right parenthesis
character that is balanced with the left parenthesis
)
character that began the part. Although the production disallows unbalanced
parenthesis characters, they (
^
) character preceding it. If the
expression contains any literal occurrences of the circumflex, each ^^
). Any other use of a circumflex results in a
The value
of an
The full form of addressing consists of one or more xpointer
(see
A bare name stands for the same name provided as the argument of
id()
. For example, the first XPointer
below is the bare-name equivalent of the second, which uses the full XPointer
form:
The bare-name shorthand is provided for two reasons:
To encourage use of IDs, which are the form of addressing most likely
to survive document change. (See
To provide an analog of the HTML fragment identifier behavior for
resources with XML media types. (Note that the XHTML specification
A child sequence locates an element by stepwise navigation using a sequence
of integers separated by slashes (/). Each integer n
locates the nth
child element of the previously located element, equivalent to an
XPath location
step of the form *[
n]
. If the
resource passed to the Xpointer-processor is a document, the
first integer in the sequence will be 1, and it locates the document
element; if the resource is an external parsed entity, the first
integer locates one of the top-level elements.
A child sequence can optionally begin with a name before the integers;
the name locates an element as described for bare names in intro
is the ID attribute value of the element that
is the fifth child of the second child of the document element:
Each xpointer
and xmlns
.
When an XPointer is the fragment identifier of an IURI and the scheme
name for an
XPointer part is not recognized, that XPointer part fails and
processing continues with
the next XPointer part (if any).
The scheme mechanism provides a general framework for extensibility
that can be used for future versions of XPointer, or for other media types
that wish to adopt all or part of this specification in defining their own
fragment identifier languages. It is xpointer
and xmlns
be avoided until they can be formally reserved.
For example, an XML-based vocabulary that is registered to have
the image/4Dgrafix+xml
media type might choose to adopt the XPointer scheme mechanism and define
its own 4Dgrafix-xml
scheme instead of, or in addition
to, the xpointer
scheme. It is particularly useful for XML-based media types to incorporate
XPointer by reference so that, in the case of content negotiation, a client
that does not support the specific XML-based media type can fall back
on the xpointer
scheme if one is provided. The provision for xpointer
or xmlns
scheme.
Minimal conformance requires the following handling. When multiple
An unknown scheme.
A scheme that is not applicable to the media type of the resource.
A n XPointer part that does not locate any sub-resource present in the resource (such as an XPtrPart that returns an empty location set).
Note that an XPointer part that uses xmlns
scheme never returns
a sub-resource and thus always fails. However, its evaluation has a potential
effect on XPointer parts to its right; see
The XPointer application
For example, the following XPointer locates the element with an ID attribute
whose value is chap1
:
However, in the absence of the DTD, it is not typically possible
to determine
if an attribute is of type id
; note that the intent of the second XPointer part is just
an approximation of the first.
XPointer extends XPath by adding the following:
Two new location types, point
and range
,
corresponding to DOM positions and ranges, that can appear in location-set
results; also tests (akin to node tests) for these location types.
A generalization of the XPath concepts of nodes, node types, and
node-sets to the XPointer concepts of
Rules for establishing the XPath evaluation context.
The functions
The functions
The functions
Allowance (as in
The functions
XPath provides for locating any subset of the
XPointer has a requirement to identify document and entity portions that are not nodes in this sense. One example of such a non-node region is an arbitrary user selection indicated by a drag between two points in a document. The two points might have different sets of ancestors in the hierarchy, or the region might form only a small part of a node. For example, a range could be a single letter or could extend from the middle of one paragraph to the middle of the next, thus containing only part of the relevant paragraphs and text nodes. Even though such locations are not nodes, XPointer needs to be able to apply XPath operations to them as well as to nodes.
To accomplish this, XPointer defines
The order of characters displayed on a computer screen might not reflect their order in the underlying XML document, for example, when a portion of a right-to-left language such as Arabic is embedded in a left-to-right language such as French. For XPointers that identify ranges of strings, the document order is used, not the display order. Thus, an XPointer for a single range might be displayed non-contiguously, and conversely a user selection of an apparent single range might correspond to multiple non-contiguous XPointer ranges in the underlying document.
An XPointer is evaluated to yield an object of type location-set. This
evaluation is carried out within a context identical to the XPath evaluation
context, except for the generalization of nodes to locations.
XPointer applications
An XPointer evaluation context contains the following information:
A location (the
A non-zero context position, initialized to 1.
A non-zero context size, initialized to 1. (At the start, the only location in the current location list is the context location.)
A set of variable bindings. No means for initializing these is defined
for XPointer applications. Thus, the set of variable bindings used
when evaluating
an XPointer is empty, and use of a variable reference in an XPointer results
in a
A library of functions. Only functions defined in XPath or XPointer
can be used in XPointers. An XPointer that uses other functions results in
a
A set of namespace declarations, described in
When applicable, properties for the locations that the
For any XPointer part that uses the xpointer
scheme,
the evaluation
context of that part xml
prefix, bound to the URI http:/www.w3.org/XML/1998/namespace
,
plus any namespace declarations specified by xmlns
XPointer parts
appearing to its left. Each xmlns
part defines a
namespace declaration
as a prefix (xmlns
parts specify the same prefix, the rightmost one is used. Any
xmlns
parts attempting to override the xml
prefix
As an example, assume the following target XML resource:
Evaluation of the following XPointer
will fail; it cannot be known which
The following avoids this evaluation failure and ensures that the
outer
The following (printed on two lines for convenience) allows for accurate
addressing of the inner
point
and range
Location Types
To address non-node locations, XPointer defines two new location
types, point
and range
, that can appear in location-sets and can be operated
on by XPath node tests and predicates. Locations of the point
and range
type represent positions and ranges as in DOM Level
2 point
and range
types and their characteristics required for XPath interoperability.
Unlike DOM Level 2, which is based on UTF-16 units, XPath and XPointer are based on UCS characters. So while the concepts of points and ranges are based on the DOM 2 notions of positions and ranges, there are differences in detail. For example, a sequence which in DOM counts as two characters might count in XPointer as one character.
Points and ranges can be used as XPointer context locations. This allows
the XPointer []
operator to be used to select from sets of ranges.
Also, a point as a context location, when followed by a
This specification does not constrain the implementation of points; applications need not actually represent points using data structures consisting of a node and an index.
Also note that, while some nodes containing points have explicit boundaries (such as element start-tags and end-tags), the boundaries of text nodes are implicit. Applications that present a graphical user interface for the selection or rendering of points and ranges need to take into consideration the fact that some seemingly identical points, such as the points just inside and just outside the closing boundary of a text node inside an element, are in fact distinguished.
The zero-based counting of node-points differs from the one-based counting
of
A point location does not have an expanded-name.
The
The axes of a point location are defined as follows:
The
The
The
The
The
The
A location of type
If the container node of one point of a range is a node of a type other
than element, text, or root, the container node of the other point of the
range
A range location does not have an expanded-name.
The
The axes of a range location are identical to the axes of its start point.
For example, the
The
For a range location, the covering range is identical to the range.
For a point location, the start and end points of the covering range are the point itself.
For an attribute or namespace location, the container node of the start point and end point of the covering range is the attribute or namespace location; the index of the start point of the covering range is 0; and the index of the end point of the covering range is the length of the string-value of the attribute or namespace location.
For the root location, the container node of the start point and end point of the covering range is the root node; the index of the start point of the covering range is 0; and the index of the end point of the covering range is the number of children of the root location.
For any other kind of location, the container node of the start point and end point of the covering range is the parent of the location; the index of the start point of the covering range is the number of preceding sibling nodes of the location; and the index of the end point is one greater than the index of the start point.
point
and range
Locations
XPointer extends the XPath production for point
and range
location
types. The production (number 38 in XPath) becomes as follows:
This definition allows point
and range
from
a location-set that might include locations of many types.
XPointer extends XPath's concept of
A point can be either a node point or a character point. Conceptually, node points label gaps between nodes, while character points occur within a node, between the node points to the right and left of the node.
Thus, an element P has a node point before and after it. If the P element contains sub-elements and/or text nodes, there are node points for the gap before the first child node, between each successive pair of child nodes, and after the last child node; they are numbered in order from 0.
WIthin any text node, there are character points preceding the first character of the text, between each successive pair of characters, as well as after the last character; they are numbered in order from 0.
For any point, there is an
For a
For a node-point with a zero index, the immediately preceding node
is the
For a
The following diagram illustrates the relation between
The document order of locations is specified here according to the location types to be compared:
As defined by XPath.
A node and point can never be equal in document order. A node is before a point if the node is before or equal in document order to the immediately preceding node of the point; otherwise, the node is after the point.
A node and range can never be equal in document order. A node is before a range if the node is before the start point of the range; otherwise the node is after the range.
Two points P1 and P2 are equal if their immediately preceding nodes are equal and the indexes of the points are equal. P1 is before P2 if P1's immediately preceding node is before P2's, or if their immediately preceding nodes are equal and P1's index is less than P2's. Otherwise P2 is after P1.
A point P is equal to a range R if R's start and end points are both equal to P; otherwise P is before R if P is before or equal to the start point of R; otherwise P is after R.
Two ranges R1 and R2 are equal in document order if their start points are equal and their end points are equal. R1 is before R2 if R1's start point is before R2's start point or if R1's start point is equal to R2's and R1's end point is before R2's; otherwise R2 is after R1.
Note that one consequence of these rules is that a point can be treated the same as the equivalent collapsed range.
XPointer adds the following functions to those in XPath; these
functions
For each location in the context,
The change made to the XPath syntax to support the
The XPointer version is as follows:
This change is a single exception for the
As an example of using the chap1
to the end point of the element with ID
chap2
.
As another example, imagine a document that uses empty elements
(such as <REVST/>
for revision start and <REVEND/>
for revision end) to mark
the boundaries of edits. The following XPointer would select, for
each revision,
a range starting at the beginning of the REVST
element and ending
at the end of the next REVEND
element:
For each location in the location-set argument,
The third argument gives the position of the first character
to be in the resulting range, relative to the start of the match. The default
value is 1, which makes the range start immediately before the first character
of the matched string. The fourth argument gives the number of characters
in the range; the default is that the range extends to the end of the matched
string. Thus, both the start point and end point of each range returned by the
Element boundaries, as well as entire embedded nodes such as processing
instructions and comments, are ignored as specified by the definition
of
For any particular match, if the string argument is not found in the string-value of the location, or if the third and fourth argument indicates a range that is wholly beyond the beginning or end of the document or entity, then no range is added to the result for that match.
The start and end points of the range-locations in the returned location-set will all be character points.
For example, the following expression returns a range that selects the
17th occurrence of the string Thomas Pynchon
occurring
in a title
element:
As another example, the following expression returns a collapsed range
whose points immediately precede the letter P
(8 from the start
of the string) in the third occurrence of the string Thomas
Pynchon
in a P
element:
Alternatively this could be specified as follows:
String-values are views
into only the string content of
a document or entity; they do not retain the structural context of
any non-text nodes
interspersed with the text. Because the Thomas Pynchon
had some
inline markup in it as follows, it would not change the string returned by
the XPointer application:
The following expression selects the fifth exclamation mark in any text node in the document and the character immediately following it:
Although these examples locate ranges via text in the string-values of
elements,
The following functions are related to ranges.
The
The
For each location
If
If
If
If
For each location x in the argument location-set,
If x is of type point, the resulting point is x.
If x is of type range, the resulting point is the end point of x.
If x is of type root or element, the container node of the resulting point is x and the index is the number of children of x.
If x is of type text, comment, or processing instruction, the container node of the resulting point is x and the index is the length of the string-value of x.
If
The
If the XPointer being evaluated appears in a text node inside an element node, the location returned is the element node.
Otherwise, the location returned is the node that directly contains the XPointer being evaluated.
In the following example, the
The type of the node in which the text
, attribute
, or
processing-instruction
.
The returned location for an XPointer appearing in element content does not
have a node type of element
because the XPointer is in a text
node that is itself inside an element.
The origin()
function is meaningful only when the XPointer is being
processed in response to traversal of a link expressed in an XML document.
The
It is a
The TEI Hypertext Guidelines.In
The Dexter Hypertext Reference Model.In
Document structure in the FRESS Hypertext System.
Intermedia: The Concept and the Construction of a Seamless Information Environment.
The Role of XML in Open Hypermedia Systems.Position paper for the 4th Workshop on Open Hypermedia Systems, ACM Hypertext '98.
The first working drafts of this specification were developed in the XML
Working Group, whose members are listed in
The editors wish to acknowledge substantial contributions from Tim Bray, who previously served as co-editor and co-chair. We would also like to acknowledge substantial contributions from James Clark, especially on the integration with XPath. We would like to thank Gavin Nicol and Martin Dürst for help with passages related to internationalization. Finally, we would like to thank the XML Linking Interest Group and Working Group for their support and input.