| TOC |
|
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 http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2003.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document specifies an xmlns-local() scheme for use in XPointer-based fragment identifiers. This scheme, like other XPointer Framework[13] 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 xmlns-local() scheme notifies an XPointer processor that it should include all of the namespace binding context defined for the element containing the XPointer in the namespace binding context for the XPointer.
| TOC |
| TOC |
The xmlns-local() scheme is intended to be used within the XPointer Framework[13] to reduce the need for incredibly redundant namespace declarations in the course of XPointer usage. By permitting XPointers to be aware of the existing namespace context in a document, this scheme can substantially reduce the length of XPointers and improve their readability. There are some costs to the independence of the XPointer, and some serious questions about how closely a fragment identifier should be tied to local context, but these issues are at least worth further exploration.
| TOC |
The XPointer Framework[13] permits the creation of namespace binding contexts to be used with later parts of the XPointer, but the xmlns()[14] scheme used to support those contexts combines some pointer part overhead with already verbose URIs to create fragment identifiers that can easily be longer than the rest of the URI reference. In situations where multiple namespaces are needed to identify components in an XPointer, the result can be grotesque if not simply unreadable.
This specification allows XPointer to take advantage of a feature (some would say mistake) of the Namespaces in XML[10] specification: an understanding of an inherited namespace context. A set of bindings between namespace URIs and prefixes can be defined for any given element in a document, using the namespace declarations in that element and in all of its parents. By reusing the existing namespace context, XPointers can be much smaller than is currently possible.
There are many risks to the creation of context-sensitive identifiers, as the many debates over the use of relative URIs demonstrate. In this case the closest parallel appears to be XSLT's use of the document namespace context for XPath processing. As the xmlns-local() scheme has the additional property of making its context-sensitivity explicit, this approach may strike a balance between the verbosity of namespace declarations inside of attribute values and the scattering of qualified names (QNames) common to other XML specificiations.
| TOC |
The scheme name is "xmlns-local". The scheme data syntax is as follows; if scheme data in a pointer part with the xmlns-local() scheme does not conform to the syntax defined in this section, it is an error and the pointer part fails.
xmlns-local() Scheme Syntax:
ptrpart ::= xmlns-local()
A pointer part that uses the xmlns-local() scheme never identifies a subresource and always fails. However, the evaluation of this pointer has a potential effect on pointer parts to its right. The presence of the xmlns-local() part signals to the processor that it should include all of the bindings between namespace URIs and prefixes which apply to the element containing the XPointer in the namespace binding context for pointer parts to the right of the part using the xmlns-local() scheme. While this scheme may be used multiple times in a single XPointer, it always adds the same set of namespace bindings to the namespace binding context.
If schemedata is provided inside the parentheses of a pointer part using the xmlns-local() scheme, the part fails and no contribution to the namespace binding context is made.
| TOC |
The XPointer Framework provides limited support for specifying XML processing context. The xmlns()[14] 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 xmlns-local() scheme relies on a similar mechanism.
The xmlns-local() scheme makes all of the namespace bindings presently available in the document available to subsequent pointer parts in the XPointer containing the xmlns-local() part. The example below demonstrates simple usage.
Simple xmlns-local() usage
<x:document x:xmlns="http://example.com/doc" y:xmlns="http://example.com/target"> <x:link href="http://target.com/#xmlns-local() xpath1(//y:name)" >Click to see all the names<x:link> </x:document>
More complex usage might include multiple namespaces in the XPointer part or parts to the right of the xmlns-local() part, or combination with the xmlns() scheme to create more complex contexts.
Using multiple namespaces from xmlns-local()
<x:document x:xmlns="http://example.com/doc" y:xmlns="http://example.com/target"> <x:link href="http://target.com/#xmlns-local() xpath1(//y:name/x:first)" >Click to see all the first names<x:link> </x:document>
Combining xmlns-local() with xmlns()
<x:document x:xmlns="http://example.com/doc" y:xmlns="http://example.com/target"> <x:link href="http://target.com/#xmlns-local() xmlns(z=http://example.com/monkeys) xpath1(//y:identity/z:description)" >Click to see the descriptions of the monkeys.<x:link> </x:document>
| TOC |
MIME Media type registrations should indicate whether or not the xmlns-local() 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 (complete with a namespace context determination process) and the contents of the type.
| TOC |
The introduction of Namespaces in XML 1.1[11] may lead some processors to support a different set of rules for defining the namespace context of any given element. The xmlns-local() scheme is agnostic about how the namespace context is defined, and leaves such possibilities explicitly open.
| TOC |
The current draft includes providing support for the default namespace in the XPointer namespace binding context. This can be removed, but needs consideration.
| TOC |
This specification normatively depends on the XPointer Framework[13], 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".
Conforming processors of the xmlns-local() scheme must provide a consistent mechanism of determining the namespace context of the element containing the XPointer. This may be achieved through Namespaces in XML 1.0[10], Namespaces in XML 1.1[11], or another mechanism. (Synthesized documents may conceivably use this scheme and derive their context through other mechanisms, though that clearly comes with its own risks.)
| TOC |
The creation of XPointers which are dependent on context for their namespaces should not raise any security problems beyond failures brought on by moving pointers from one context to another.
| TOC |
None.
| TOC |
| [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] | Marsh, J. and D. Orchard, "XML Inclusions (XInclude) Version 1.0", World Wide Web Consortium Candidate Recommendation CR-xinclude-20020221/, September 2002. |
| [10] | Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml-names, January 1999. |
| [11] | Cowan, J., "Namespaces in XML 1.1", World Wide Web Consortium Candidate Recommendation CR-xml11-20021015, October 2002. |
| [12] | DeRose, S., Maler, E. and D. Orchard, "XML Linking Language (XLink)", World Wide Web Consortium Recommendation XLink, June 2001. |
| [13] | Grosso, P., Maler, E., Marsh, J. and N. Walsh, "XPointer Framework", World Wide Web Consortium Working Draft XPointer Framework, July 2002. |
| [14] | DeRose, S., Daniel Jr., R. and E. Maler, "XPointer xmlns() Scheme", World Wide Web Consortium Working Draft XPointer xmlns() Scheme, July 2002. |
| [15] | Grosso, P., Maler, E., Marsh, J. and N. Walsh, "XPointer element() Scheme", World Wide Web Consortium Working Draft XPointer element() Scheme, July 2002. |
| [16] | DeRose, S., Daniel Jr., R. and E. Maler, "XPointer xpointer() Scheme", World Wide Web Consortium Working Draft XPointer xpointer() Scheme, July 2002. |
| [17] | St.Laurent, S., "The XPointer xpath1() Scheme", I-D draft-stlaurent-xpath-frag-00.txt, October 2002. |
| TOC |
| Simon St.Laurent | |
| O'Reilly & Associates | |
| 1259 Dryden Road | |
| Ithaca, New York 14850 | |
| USA | |
| EMail: | simonstl@simonstl.com |
| URI: | http://www.simonstl.com/ |
| TOC |
Thanks to discussion on xml-dev for inspiration.
| TOC |
00 - First version.
[To be deleted before publication.]
| TOC |
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.
Funding for the RFC Editor function is currently provided by the Internet Society.