| 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 December 12, 2001.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Generally fragment identifiers have been specified as unique identifiers for parts of a document. Such identifiers have been specified as SGML/XML IDs e.g. in HTML. This usage is identical to the XPointer[2] "raw name" form. Specifications constraining the behavior of user agents such as SMIL[6], XHTML[13], and SVG[8] have all supported that basic usage, though some extend it.
| TOC |
| TOC |
Frequently URI references[1], which may contain a fragment identifier, are used independent of their resolution into a particular document, or document fragment, at a particular point in time.
A notable example is use of a URI reference as an XML Namespace[4] name. In the current situation a the syntax of the fragment identifier part of a URI reference is defined by the MIME media type of the referenced document as in an HTTP transaction. This media type is not fixed, and may change from time to time and from reference to reference, or according to request headers such as with content negotiation.
It turns out that the fragment identifier syntax is often constant from media type to media type. In order to enable robust use of fragment identifiers, particularly outside a particular HTTP transaction, we propose a generic, media type independent, fragment identifier syntax. This fragment identifier syntax is compatible with current usage of fragment identifiers, and is generally compatible with future proposed syntaxes such as XPointer[2].
This specification does not itself specify how user agents are to process or interpret fragment identifiers, such as may be specified with individual MIME media type registrations, rather provides a consistent syntax for fragment identifiers and a registration mechanism for schemes associated with fragment identifier syntaxes.
| TOC |
The short form of a fragment identifier is a Name. A Name is used as the fragment identifier for HTML, and is equivalent to the Bare Name form of XPointer[2] except that the Name need not be an SGML/XML ID, rather the mechanism for locating document fragments by name is determined by the application.
| TOC |
A numeric fragment is of the form: ('/' Number)+ e.g. #/10/24 This conforms to the XPointer[2] child sequence syntax, however may be used by non-XML media types. For example a particular frame of a video clip might be represented as: #/100025 ranges are expressed as /1-10 and lists as /1,2,5,20
| TOC |
The full form of a fragment identifier uses the Scheme '(' string ')' Form. This form is consistent with the XPointer[2] full xpointer form, hence this valid full XPointers conform to this proposed syntax. This specification defines the following scheme names:
- xpath:
- the content is a valid XPath
- xmlns:
- the content defines a namespace prefix mapping
- xpointer:
- the content is a valid XPointer
| TOC |
A namespace may declare support for a particular scheme or set of schemes via a RDDL[5] description. The id of a RDDL resource describing a scheme should be the same as the name of the scheme. The RDDL nature or the resource should be URI reference identifying the scheme. The RDDL purpose of the scheme should be the URI: http://www.rddl.org/fragment-syntax#scheme. For example:
<div id="xpointer"> <rddl:resource xlink:arcrole="http://www.rddl.org/fragment-syntax#scheme" xlink:href="http://www.w3.org/TR/xptr" /> </div>
| TOC |
FragmentId ::= Name | NumberPart | (FragmentPart (S? FragmentPart))
NumberPart ::= ('/' , Number,(('-'|','),Number))*)+
FragmentPart ::= Scheme '(' SchemeSpecificExpr? ')'
SchemeSpecificExpr ::= StringWithBalancedParens
StringWithBalancedParens ::= [^()^^|^^^^|^^)|^^(]* ('(' StringWithBalancedParens
')' [^()^^|^^^^|^^)|^^(]*)*
'^^' escapes '^', '^)' escapes ')' and '^(' escapes '('
| TOC |
| [1] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. |
| [2] | DeRose, S., Daniel Jr., R. and E. Maler, "XML Pointer Language (XPointer)", World Wide Web Consortium Working Draft xptr, July 1999. |
| [3] | Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", World Wide Web Consortium Recommendation REC-xml, February 1998. |
| [4] | Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml-names, January 1999. |
| [5] | Borden, J. and T. Bray, "Resource Directory Description Language (RDDL)", June 2001. |
| [6] | Ayars, J., Bulterman, D., Cohen, A., Day, K., Hodge, E., Hoschka, P., Hyche, E., Jourdan, M., Kim, M., Kubota, K., Lanphier, R., Layaida, N., Michel, T., Newman, D., van Ossenbruggen, J., Rutledge, L., Saccocio, B., Schmitz, P. and W. ten Kate, "Synchronized Multimedia Integration Language (SMIL 2.0) Specification", World Wide Web Consortium Proposed Recommendation PR-smil20, June 2001. |
| [7] | Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [8] | Ferraiolo, J., "Scalable Vector Graphics (SVG)", World Wide Web Consortium Working Draft SVG, August 1999. |
| [9] | Marsh, J., "XML Base (XBase)", World Wide Web Consortium Working Draft xmlbase, February 2000. |
| [10] | DeRose, S., Maler, E., Orchard, D. and B. Trafford, "XML Linking Language (XLink)", World Wide Web Consortium Working Draft xlink, July 1999. |
| [11] | Clark , J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation xslt, November 1999. |
| [12] | Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. |
| [13] | Pemberton, S. and . et al, "XHTML 1.0: The Extensible HyperText Markup Language", World Wide Web Consortium Recommendation REC-xhtml1, January 2000. |
| TOC |
| Jonathan Borden | |
| The Open Healthcare Group | |
| 114 Merriam Street | |
| Weston, MA 02493 | |
| US | |
| EMail: | jborden@mediaone.net |
| URI: | http://openhealth.org |
| Simon St.Laurent | |
| 1259 Dryden Road | |
| Ithaca, New York 14850 | |
| USA | |
| EMail: | simonstl@simonstl.com |
| URI: | http://www.simonstl.com/ |
| TOC |
| TOC |
[To be deleted before publication.]
| TOC |
Copyright (C) The Internet Society (2001). 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.