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

The XPointer content-type() 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 28, 2003.

Copyright Notice

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


This document specifies a content-type() scheme for use in XPointer-based fragment identifiers. This scheme, like other XPointer Framework[12] 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, though it may potentially be used to mix schemes for XML and non-XML representations. The content-type() scheme notifies an XPointer processor whether the creator of the XPointer intended for a particular pointer part to apply to a resource representation which uses a particular MIME content type identifier.


Table of Contents


1. Introduction

The content-type() scheme is intended to be used within the XPointer Framework[12] to support the addressing of nodes within XML (and potentially other) documents. Pointer parts using the content-type() 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

Even if all of the possible representations of a resource are themselves XML, they may contain very different structures and labels. The impact of that variability will vary with the nature of the representations, but it may cause various schemes used within the XPointer Framework[12] (including xpointer()[15], element()[14], and xpath1()[16]) to return different answers if the representation of the resource is of an unexpected type.

While content-type() pointer parts can never provide more than a suggestion, they may be helpful in coordinating program behavior or at least giving a human reader a clue as to why fragment identifiers are behaving differently than expected.


3. Syntax

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

content-type() Scheme Syntax:

  ptrpart                 ::=    content-type( content-typeschemedata )
  content-typeschemedata  ::=    type

type must be a MIME Content-Type identifier conforming to RFC 2046[1], and should preferably be a registered type, as registration provides a medium in which to describe the different kinds of fragment identifiers which may apply to a particular type.


4. Processing

The XPointer Framework provides limited support for specifying XML processing context. The xmlns()[13] 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 content-type() 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 content-type() generally to signal an error.

A typical use for content-type would just signal to which representation a given XPointer is likely to apply:

#content-type(application/xhtml+xml) element(framework/1/7)

In this case, the XPointer may fail if fed the wrong representation, but at least a developer might have a chance of figuring out why the failure is taking place.

In the event that an XPointer processor provides explicit support for the content-type() scheme, it should do its best to find a representation specified by each content-type() part, conceivably making multiple attempts to retrieve an acceptable representation. For example, if an XPointer using content-type() looked like:

#content-type(application/xhtml+xml) element(/1/7) content-type(image/svg+xml) element(/1/4) content-type(application/mathml+xml) element(/1/3)

then the processor should first attempt to retrieve an XHTML representation of the resource, then find the seventh child of the first element in the document. If that didn't return a node, it would attempt to retrieve an SVG representation, then find the fourth child of the first element in the document. If that didn't return a node, it would attempt to retrieve a MathML representation, and return the the third child of the first element in the document.

This will not likely work in most XPointer processors, as the representation of the resource will likely have been set at some point earlier in the process without fragment identifier consultation, and the XPointer processor will likely grab the seventh child element of the first element in the document regardless of whether it was represented as XHTML, SVG, or MathML. It does, however, raise the question of how XPointer and content-negotiation interact (or don't.)


5. Relation to MIME Media Types

This scheme is somewhat separate from association with any particular MIME type, but it could conceivably be used with any registration made in accordance with RFC 2046[1] and RFC 2048[2].


6. Other MIME issues

There may be other aspects of MIME content-negotiation worth considering in this context. Content-features, charset, and other parameters may in some circumstances affect XPointer processing. Consideration of those issues is left for other drafts.


7. Conformance

This specification normatively depends on the XPointer Framework[12], 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 simply ignore content-type() pointer parts with only occasional damage, those explicitly claiming support for the content-type() scheme should support content-negotiation and attempt to supply the context requested by the content-type() pointer part or parts.


8. Security Considerations

There may be security considerations involved in content-negotiation, but they are outside of the scope of this document.


9. 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] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999.
[8] 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.
[9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml-names, January 1999.
[10] DeRose, S., Maler, E. and D. Orchard, "XML Linking Language (XLink)", World Wide Web Consortium Recommendation XLink, June 2001.
[11] Marsh, J. and D. Orchard, "XML Inclusions (XInclude) Version 1.0", World Wide Web Consortium Candidate Recommendation CR-xinclude-20020221/, September 2002.
[12] Grosso, P., Maler, E., Marsh, J. and N. Walsh, "XPointer Framework", World Wide Web Consortium Working Draft XPointer Framework, July 2002.
[13] DeRose, S., Daniel Jr., R. and E. Maler, "XPointer xmlns() Scheme", World Wide Web Consortium Working Draft XPointer xmlns() Scheme, July 2002.
[14] Grosso, P., Maler, E., Marsh, J. and N. Walsh, "XPointer element() Scheme", World Wide Web Consortium Working Draft XPointer element() Scheme, July 2002.
[15] DeRose, S., Daniel Jr., R. and E. Maler, "XPointer xpointer() Scheme", World Wide Web Consortium Working Draft XPointer xpointer() Scheme, July 2002.
[16] St.Laurent, S., "The XPointer xpath1() Scheme", I-D draft-stlaurent-xpath-frag-00.txt, October 2002.
[17] 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 Uche Ogbuji and Eric van der Vlist for inspiration.


Appendix B. Revision History

00 - First version.

[To be deleted before publication.]


Full Copyright Statement