Liaison Statement - April 1999

Naked Fragment Identifiers, ID Attributes, and XML Hyperlinking

Editor: Tim Bray


It is desired that URI references of the form be usable with as many kinds of resources as possible, including at least HTML, XML, and XHTML, as well as other XML-based formats such as RDF, SMIL, and SVG. To the extent possible, they should have the same semantics across this range of media types.

Achieving these goals presents considerable challenges. This note outlines these challenges, and includes some concrete design proposals for the XML and HTML working groups. It includes considerable background material describing the historical and technical aspects of the existing syntactic apparatus in XML and HTML.

Status of This Document

This document is an informal communication designed to serve as a basis for dialogue within and among W3C activities that have an interest in the interpretation of URI references. It represents the consensus findings of the W3C XML Linking Working Group, following a lengthy and intense discussion.

1. Background

This section provides the technical and historical background as understood by the membership of the XML Hyperlinking WG. This understanding serves as the basis for the recommendations in the following sections.

1.1 URI References and Fragment Identifiers

In all versions of HTML ([3.2], [4], [XHTML]) and the current XML XPointer Working Draft, resources are identified in hyperlinks using URI References. A URI reference consists of a URI, optionally followed by the character #, and then by a "fragment identifier."

The interpretation of the fragment identifier is based on the type of the resource identified by the URI. Quoting from RFC 2396:

When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI....

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 [RFC2046] of the retrieval result.

1.2 XML ID Attributes

XML 1.0 has the notion that attributes can have a declared type. The declarations are in the Document Type Definition (DTD) and use the <!ATTLIST syntax. One of those types is called "ID", and attributes of this type are commonly referred to as "ID attributes". These may have any name and be attached to elements of any type, but each ID attribute in a document must have a unique value. Thus the value of an ID attribute can serve as a unique address for the element to which the attribute is attached. ID attributes, which XML inherited from SGML, have found wide and popular use in virtually every XML-based language.

XML also inherited from SGML two important limitations concerning ID attributes:

These limitations increase the difficulty of meeting the goals for fragment identifiers.

1.3 Fragment Identifiers, "name" Attributes, and IDs in HTML

In HTML, the fragment identifier is an unstructured string, which has historically had the semantic of pointing at the first <a> element with a name attribute whose value is the same as the fragment identifier.

In HTML, the name attribute of the <a> element has a declared type of "CDATA", which means it can contain essentially any character string. This attribute may be attached to any of the following elements: a, meta, object, param, map, input, select, textarea, button, frame, iframe. Note that one reason for name's CDATA type was preservation from case-folding; in the XML context, this is no longer a problem.

HTML also defines an attribute named id which is (not surprisingly) of type ID. It may be applied to a large number of HTML elements, and is used, among other things, to identify elements to be operated on through an API such as Dynamic HTML or the W3C Document Object Model.

1.4 Fragment Identifiers in XPointer

The W3C has the responsibility of specifying the interpretation of fragment identifiers for XML documents. This work has been done in the XML Linking Working Group, resulting in Working Drafts defining the XPointer language, which has syntax for identifying and pointing at the internal structures of XML documents.

A special case of a fragment identifier/XPointer is one which is "naked", i.e. is a simple identifier without internal structure. In the Working Drafts, a naked XPointer has been given the semantic of pointing at an element which has an XML "ID Attribute" whose value is the same as the fragment identifier.

The motivation for this is that it is highly desirable for hyperlinks to point at unique addresses provided by the creator of the resource being pointed into. Among other things, such pointers have higher likelihood of surviving updates to the target resource.

1.5 Problems With the Use of ID Attributes

The only way to establish whether an attribute is of type ID is to read the document's DTD looking for <!ATTLIST declarations. Unfortunately, according to the XML specification, not all classes of conforming software are required to read the DTD; the only documented way to ensure the reading of the DTD is to require the use of a validating processor. This is unsatisfactory because hyperlink traversal should not require validation.

One possible solution is to place the <!ATTLIST declarations in the "internal subset" of the DTD, i.e. that portion which is transmitted with the document. This almost but not quite works, since while non-validating processors are required to read the internal subset and process attribute and entity declarations, there is no normative text requiring that ID attribute declarations be processed or reported to application software (although doing so is not difficult).

This problem with ID attributes has affected not only the design of XPointer, but the work of (at least) the XSL and SVG Working Groups. It would be advantageous to all these groups if there were a mechanism for identifying, without requiring DTD processing, which attributes in a document are of type ID. The XML Syntax Working Group has considered this issue, but declined to create an interim solution on the grounds that this is a known requirement being addressed by the XML Schema Working Group.

1.6 Addressing in RDF

RDF makes heavy use of an attribute named ID to provide unique object identifiers. While RDF does not provide DTD-style declarations, this attribute is, in XML terms, effectively of type ID.

RDF also has another attribute named BagID, used also to provide a unique identifier in certain contexts for different classes of objects. Note that since it is possible for ID and BagID can appear on the same element, it is not technically possible for both of them to be XML ID attributes.

2. Fragment Identifiers and Media Types

There is a shared goal that URI references of the form have the same interpretation across as broad a family of Web Markup Languages as possible. In this section we consider the interaction of fragment identifiers and media types in XML, RDF, and XHTML.

2.1 XML

It is to be expected that XML documents will be served up with a wide variety of media types, and strictly speaking, the XPointer rules only apply to text/xml and application/xml. However, it is possible that other XML-based languages will specify XPointer semantics for fragment identifiers.

To deal with naked fragment identifiers, implementers will have to solve the problem of identifying ID attributes. In some cases, this will be a non-issue, since the receiving application will, using namespaces or some other mechanism, have built-in knowledge of the markup declarations, including which elements are ID elements.

For interoperability in the general case where the receiving application neither knows which attributes are of type ID nor wishes to read and process the whole DTD, a general solution is to be expected from the XML Schema Working Group.

It is still conceivable that the W3C may decide to sanction the development of some interim syntax to identify ID elements. Finally, should the W3C charter a next-generation XML Working Group in advance of the completion of the schema work, one of the design goals might be to require even non-validating processors to read and process ID attribute declarations in the internal subset.

2.2 RDF

An RDF resource might potentially be served up with the media type text/rdf, in which case the interpretation of a fragment identifier is whatever RDF specifies; a reasonable reading of the current specification suggests that this would address an RDF object with an attribute named ID whose value matches the fragment identifier.

Were the same resource served with the media type text/xml, there is a slight problem since RDF does not have a DTD and does not declare any ID attributes. However, a reasonable reading of the RDF specification suggests that the ID attribute is clearly of type ID, and thus the expected behavior would be the same. (Note that this relies on relies on correct namespace processing; but RDF is anyhow unusable without namespaces.)


XHTML is "a reformulation of HTML 4.0 as an XML 1.0 application." It is reasonable to expect that XHTML documents may be served with either the text/html or text/xml media type. In the first case, the fragment identifier would be clearly be interpreted as with any other HTML document, as described above, i.e. as a reference to the first <a> element with a name attribute matching the fragment identifier.

When an XHTML document is served as XML, unless the current interpretation is changed, the effect would be different; the fragment identifier would select an element with an ID attribute with matching value; in the current specification of XHTML, this would effectively match on the id rather than the name attribute.

This behavior (hyperlink addressing depending on media type) is undesirable; it is the goal of this document to explore alternative approaches to fixing it.

3. One Problem With HTML's "name" Attribute

The fact that XHTML's name attribute is of type CDATA presents an apparently insurmountable problem for interoperation with XML. XPointer distinguishes between "naked" and structured fragment identifiers based on simple syntactic rules, easily illustrated by example:

<a href='res.xhtml#Sec27'>         <!-- Naked fragment identifier -->
<a href='res.xhtml#child(27,Sec)'> <!-- Structured identifier -->

This works reliably since an XML ID attribute's value must be a Name, which can never take a value like child(27,Sec).

According to the semantic now associated with text/html, though, the first of these points would address an element of the form <a name="Sec27">, and the second an element of the form <a name="child(27,Sec)">. In effect, there is no way to bring the XPointer machinery into play without changing (at least slightly) the semantics of fragment identifiers in HTML. One way to deal with this would be to change the declaration of the XHTML name attribute from CDATA to NMTOKEN - this would at least make it impossible for authors of valid HTML documents to use child(27,Sec) as the value of a name attribute.

The cost of this change would be nontrivial - the task of conversion from legacy HTML to XHTML would be increased by the cost of normalizing the values of name attributes that do not match the production for Name. Perhaps more seriously, this would break external hyperlinks pointing into such documents that contained fragment identifiers using the now-illegal syntax.

The cost could be reduced by relaxing the XML 1.0 requirement that ID attribute values match Name; it could instead be required to match Nmtoken. This would allow values such as 2.3.1 and -adobe-helvetica- to be used for ID attributes, which would probably considerably reduce the scale of the legacy HTML conversion problem.

4. Strawman Proposal 1

One way forward would be to rewrite the XPointer rules so that a naked fragment identifier shares HTML's syntax: it selects an <a> element with a name attribute with matching value. This is unlikely to be well-received in the XML community, which has a basic expectation that they should be able to invent their own element names and assign their own semantics to them.

A variation on this would be to use the namespace machinery to qualify the <a>; for example, #fragment would match the first occurrence of <html:a name="fragment">, where the html prefix is mapped to the XHTML namespace. A further variation would be to apply the namespace machinery at the attribute level, in which case #fragment would match the first occurrence of <any-ns:any-tag html:name="fragment">.

These proposals share the following disadvantages:

5. Strawman Proposal 2

  1. XHTML could plan on turning the name attribute into an ID attribute. This could not be done legally in the XML 1.0 context, because the id attribute applies to the same elements, and there can be only one ID attribute per element.
  2. There is currently discussion of chartering a Working Group to produce another revision of XML. This working group could be tasked with one or more of the following changes to XML 1.0 (which all represent relaxations of syntactic restrictions and would invalidate no existing data):
  3. As an interim measure until XML 1.0 is revised, XHTML could, for the a element only, declare the name attribute to be of type ID, and the id attribute to be of some other type (probably NMTOKEN). It is hard to see this causing any operational problems beyond those mentioned above in section 3.

This proposal would have the virtue of causing uniform behavior in XML, HTML, XHTML, and RDF documents, regardless of which media type they are served with. Furthermore, it would preserve the expressive power of XML's ID attributes and not require applying any namespace machinery.

6. Conclusions

The first conclusion is clearly that this problem is multi-dimensional and difficult. There is no design choice that will simultaneously lead to consistent media-type-independent behavior, preserve all the existing HTML semantics, and avoid seriously weakening the design of XML hyperlinking.

The Strawman 1 proposal requires less work, requiring only an adjustment to a single Working Draft (XPointer). However, it represents a sacrifice of simplicity and consistency in the general case in order to address a very specific problem. This is serious, since XML is simple and flexible enough that there is a real possibility of it serving as the basis for distributed hypertext for a very long time indeed.

Strawman 2 requires co-ordinated updates to XHTML and to XML 1.0, and increases the conversion cost for those who want to serve legacy HTML as XML. However, it preserves the simplicity of the general case, and better meets the goal of "leading the Web to its full potential."

It is the finding of the XML Linking Working Group that the W3C ought to pursue a course along the lines of Strawman 2. Specifically, those of us who are engaged with the core XML work are willing to commit serious effort to the consensus-building and editorial work required to accomplish the necessary revisions to XML.