Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

This document specifies an xpath1() scheme for use in XPointer-based fragment identifiers. This scheme, like other XPointer Framework[11] schemes, is designed primarily for use with the XML Media Types defined in RFC 3023[5], to
identify locations within a given XML representation of a resource. The xpath1() scheme uses XPath 1.0 syntax

1. Introduction

The XPath 1.0-based xpath1() scheme is intended to be used within the XPointer Framework[11] to support the addressing of nodes within XML documents. Like the xpointer() scheme, the xpath() scheme supports addressing into the internal structures of XML documents and external parsed entities, supporting addressing 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. Unlike the xpointer() scheme[14], the xpath1() scheme only identifies complete nodes and has no support for character-based ranges.

2. Justification

As the W3C's xpointer() scheme[14] already provides a superset of the functionality provided by the xpath1() scheme, some consideration of why the xpath1() scheme is useful seems worthwhile.

The xpointer() scheme, designed to support the out-of-line linking capabilities of XLink[10], provides support for character ranges which may arbitrarily cross node boundaries. While this is extremely useful for many hypertext applications, it is unnecessary for a wide variety of simpler projects, and XPath 1.0 is generally far more widely supported than the xpointer() scheme.

While the XPointer Framework explicitly supports multiple levels of conformance, the xpointer() scheme states that "Conforming XPointer processors claiming to support the xpointer() scheme must conform to the behavior defined in this specification and may conform to additional XPointer scheme specifications." Conforming xpointer() processors must implement both XPath and the xpointer() scheme's own extensions, and while applications might use only the subset of xpointer() that is pure XPath, processors built for that approach are non-conformant.

The XPointer set of specifications also includes shorthand pointers (based on ID values with their own complications) and support for an element()[13] scheme that is effectively a subset of XPath, but these offer considerably less functionality than XPath.

The xpath1() scheme strikes a balance between the simple implementation but limited functionality of shorthand pointers and the element() scheme, and the complex implementation but great capabilities of the xpointer() scheme. Perhaps more importantly, it strikes that balance using processing capabilities that are already widely deployed.

3. Syntax

The scheme name is "xpath1". The scheme data syntax is as follows; if scheme data in a pointer part with the xpath1() scheme does not conform to the syntax defined in this section, it is an error and the pointer part fails.

xpath1() Scheme Syntax:

ptrpart ::= xpath1( xpath1schemedata )
xpath1schemedata ::= Expr

Expr is as defined in the XPath 1.0 Recommendation[7]. To suport identifiers operating on external parsed entities with multiple root elements or text nodes, the xpath1() scheme extends the XPath data model to permit the root node to contain any sequence of nodes that an element node may contain. (XSLT provides the same extension.)

4. Processing

The XML namespace[9] context for the XPath should be set by previous XPointer parts using the XPointer xmlns() scheme[12], and the document context is set by the URI containing the XPointer expression.

Evaluating the expression contained in xpath1schemedata in that namespace and document context returns a location-set or an error. If the XPath expression identifies a single node, then the location-set contains a single location corresponding to that node. If the XPath expression identifies a node-set, this XPointer identifies a location-set corresponding to the node-set. If the result of the XPath expression is something other than a node or node-set, the XPointer result is an error.

5. Relation to MIME Media Types

MIME Media type registrations should indicate whether or not the xpath1() scheme is applicable to their contents. While this scheme is obviously most directly connected to XML registrations made in accordance with RFC 3023[5], it could conceivably be used with any registration made in accordance with RFC 2046[1] and RFC 2048[2], provided that the registration provides an explicit mapping between an XML structure and the contents of the type.

6. XPath Versions

At the time of writing, the W3C is developing Version 2.0 of XPath[8]. While this version has many more features, it also has many more dependencies and will require a much more sophisticated processor. Developers who want to use XPath 2.0 for fragment identifiers should define a new XPointer scheme (perhaps xpath2()). All xpath1() scheme processors must reject expressions which do not conform to the syntax and feature set of XPath 1.0[7].

7. Considerations for Streaming Processing

Current versions of XPath provide support for navigation from the later points in a document to prior points, a useful set of tools but only in contexts where the complete document (or substantial portions of it) remain available throughout expression processing. The xpath1() scheme supports that functionality and therefore makes a purely streaming processor difficult to write. Developers who need to be able to support streaming processing of fragment identifiers should consider or create other schemes.

8. Conformance

This specification normatively depends on the XPointer Framework[11] and XPath 1.0[7]. It also normatively depends on the XPointer xmlns() scheme[12]. XPointer processors claiming to conform to this specification must also conform to the xmlns() specification.

The scheme data for the xpath1() scheme conforms to this specification if it is processable using XPath 1.0[7], with support for multi-rooted external parsed entities if applied in that context.

Conforming XPointer processors claiming to support the xpath1() scheme must conform to the behavior defined in this specification and may conform to additional XPointer scheme specifications, including in particular the xpointer() scheme[14] which is a superset of the xpath1() scheme.

9. Security Considerations

While it is conceivable that faulty XPath expressions could be used to overflow or overload XPath processors used in processing of the xpath1() scheme data, the author is not aware of any such assaults having taken place. XPath processors should be robust enough to handle or reject XPaths of all kinds in order to process this scheme.

Appendix A. Acknowledgements

Appendix B. Revision History

Full Copyright Statement

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.