Network Working GroupS. St.Laurent
Internet-DraftO'Reilly & Associates
Expires: April 29, 2003October 29, 2002

The XPointer pipeline1() Scheme

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."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on April 29, 2003.

Copyright Notice

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


This document specifies an pipeline1() scheme for use in XPointer-based fragment identifiers. This scheme, like other XPointer Framework[14] 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 pipeline1() scheme notifies an XPointer processor whether the creator of the XPointer intended for XML Pipeline Definition Language[7] processing to take place.


Table of Contents


1. Introduction

The XML Pipeline Definition Language 1.0-based pipeline1() scheme is intended to be used within the XPointer Framework[14] to support the addressing of nodes within XML documents. Pointer parts using the pipeline1() scheme will always fail, as they do not identify portions of an XML document, but they can communicate (though not enforce) expectations for processing of later parts of an XPointer.


2. Justification

There are a large number of cases where multiple stages of processing must be performed on an XML document to create a final document. As noted in Section 4.1 of XML Linking and Style[13], "displaying the styled result is a complex problem because links are between source documents, not between their styled results."

While the notion of links pointing to abstract resources and subresources which are then followed through any transformation sequence may be attractive, Section 4.1 of RFC 2396[3] already ties the fragment identifier to the representation:

| The semantics of a fragment identifier is a property 
| of the data resulting from a retrieval action, 
| regardless of the type of URI used in the reference.  
| Therefore, the format and interpretation of fragment 
| identifiers is dependent on the media type  
| of the retrieval result.

The pipeline1() scheme begins with the retrieval result and permits the specification of styling and other processing before the other parts of the XPointer attempt to locate content inside of those results. While this may bind content even more tightly to a given representation, it may in fact be simpler to work backwards from that tightly-bound representation to a more abstract description (if one is needed) than to work forward from an abstract description of a location in an original document to a location in the result of processing that document.


3. Syntax

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

pipeline1() Scheme Syntax:

  ptrpart             ::=    pipeline1( pipeline1schemedata )
  pipeline1schemedata ::=    URIref

The URIref in the pipeline1schemedata must be resolvable and must point to a document conforming to the XML Pipeline Definition Language 1.0[7].


4. Processing

The XPointer Framework provides limited support for specifying XML processing context. The xmlns()[15] scheme provides support for identifying mappings between prefixes used in pointer parts and namespace URIs, changing the processing context of later pointer parts. By definition, the xmlns() scheme "never identifies a subresource and thus always fails". The pipeline1() scheme relies on a similar mechanism, but because of the XPointer framework's consumption of failures inside an XPointer expression, there is no way for pipeline1() generally to signal an error.

In the event that an XPointer processor provides explicit support for the pipeline1() scheme, it should do its best to provide the context requested by each pipeline1() part. If a representation of the URIref cannot be retrieved or if the representation retrieved does not conform to the XML Pipeline Definition Language 1.0, this pointer part fails and has no impact on the context for later processing parts. For example, if an XPointer using pipeline1() looked like:

#pipeline1( element(/1/7) pipeline1( element(/1/4)

then the processor should first attempt to process the original document returned as a representation according to the pipeline specified at, then find the seventh child of the first element in the document. If that didn't return a node, it would process the original document returned as a representation according to the pipeline specified at, then find the fourth child of the first element in the document.


5. Relation to MIME Media Types

MIME Media type registrations should indicate whether or not the pipeline1() 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. XML Pipeline Definition Language Versions

At the time of writing, XML Pipeline Definition Language 1.0[7] is available only as a W3C Note, with no clear path forward for development. Pipelines appear to be a field where there are many ideas and few conclusions. While there is no clear path beyond version 1.0, this draft has opted to include the version number in the scheme name in the event of substantial future change.


7. Considerations for Streaming Processing

XPointers that include more than one pipline1() part may require multiple parses of the original document, which may make it incompatible with some streaming processing approaches.


8. Conformance

This specification normatively depends on the XPointer Framework[14], except insofar as it rejects the claim in Section 3.3 that "this specification reserves all scheme names for definition in additional W3C XPointer scheme specifications".

While XPointer processors may conceivably ignore pipeline1() pointer parts with little damage, those explicitly claiming support for the pipeline1() scheme should support XML Pipeline Definition Language processing and attempt to supply the context requested by the pipeline1() pointer part. The more substantial the changes specified by the pipeline, the greater the risk of a broken XPointer in environments which do not understand the pipeline1() scheme.


9. Security Considerations

Pipeline processing by its very nature relies on the inclusion and processing of foreign content and its mechanisms provide an opportunity for servers to learn of processing capabilities on clients. To the extent that XML Pipeline Definition Language processing itself may be a security risk, use of and support for the pipeline() scheme may heighten that risk.


10. IANA Considerations




[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[5] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", World Wide Web Consortium Recommendation REC-xml, February 1998.
[7] Maler, E. and N. Walsh, "XML Pipeline Definition Language Version 1.0", World Wide Web Consortium Note NOTE-xml-pipeline-20020228/, February 2002.
[8] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999.
[9] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J. and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium Working Draft WD-xpath20-20020816, November 1999.
[10] Marsh, J. and D. Orchard, "XML Inclusions (XInclude) Version 1.0", World Wide Web Consortium Candidate Recommendation CR-xinclude-20020221/, September 2002.
[11] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml-names, January 1999.
[12] DeRose, S., Maler, E. and D. Orchard, "XML Linking Language (XLink)", World Wide Web Consortium Recommendation XLink, June 2001.
[13] Walsh, N., "XML Linking and Style", World Wide Web Consortium Note NOTE-xml-pipeline-20020228/, June 2001.
[14] Grosso, P., Maler, E., Marsh, J. and N. Walsh, "XPointer Framework", World Wide Web Consortium Working Draft XPointer Framework, July 2002.
[15] DeRose, S., Daniel Jr., R. and E. Maler, "XPointer xmlns() Scheme", World Wide Web Consortium Working Draft XPointer xmlns() Scheme, July 2002.
[16] Grosso, P., Maler, E., Marsh, J. and N. Walsh, "XPointer element() Scheme", World Wide Web Consortium Working Draft XPointer element() Scheme, July 2002.
[17] DeRose, S., Daniel Jr., R. and E. Maler, "XPointer xpointer() Scheme", World Wide Web Consortium Working Draft XPointer xpointer() Scheme, July 2002.
[18] St.Laurent, S., "The XPointer xpath1() Scheme", I-D draft-stlaurent-xpath-frag-00.txt, October 2002.
[19] St.Laurent, S., "The XPointer xinclude1() Scheme", I-D draft-stlaurent-xinclude-frag-00.txt, October 2002.


Author's Address

  Simon St.Laurent
  O'Reilly & Associates
  1259 Dryden Road
  Ithaca, New York 14850


Appendix A. Acknowledgements

Thanks to discussion on xml-dev for inspiration.


Appendix B. Revision History

00 - First version.

[To be deleted before publication.]


Full Copyright Statement