This is a W3C Note for use by W3C members and other parties interested in using and implementing the XML Linking Language (XLink) and its related XML Pointer Language (XPointer). It reflects the consensus of the XML Working Group. This document may be updated, replaced, or obsoleted by other documents at any time, though it is expected to remain fairly stable.
The design principles described herein have been thoroughly reviewed, and are in part based on the principles that informed the design of XML. Thus, while comments are welcome and will be given due consideration, the principles are likely to be changed only after a very persuasive case is made, so that the design of XLink can proceed apace. Please send any comments to the editors of this Note.
For current status of the XML Activity, see http://www.w3.org/MarkUp/XML/Activity).
This document explicates the design principles behind the XLink language and its related XPointer language.
This implies the following:
XLink should not favor particular domains over others. For example, it should be usable in scholarly annotation, cross-referencing in technical publications, and other domains of link usage.
In addition, XLink should not favor (for example) traditional browsers over other kinds of application software, such as tree-walking navigational devices or editing systems.
XLink is an XML-based language; that is to say, individual XLink structures must be represented using XML element and attribute markup.
As a critical component for the success of the XML family of specifications, XLink must be developed as quickly as possible.
In particular, XLink characteristics should be explained in a fashion that does not confuse the link topology with the XML syntax used to express links. Such characteristics might include the required number of participating resources and inheritance of locator settings.
Although XLink structures may be compressed, encrypted, or otherwise put into binary/unreadable form for transmission or internal processing, they must be in clear-text form to be considered XLinks.
It is a requirement that XLink provide a means to do sophisticated out-of-line linking, in order for it to offer scalability and relief from HTML linking problems. This does not mean that all links must be out-of-line; on the contrary, the "Straightforwardly Usable Over the Internet" principle demands that simple in-line linking also be accounted for.
It is not a goal to provide the specification of precise link formatting and behavior because we don't want to encourage procedural markup. However, some small amount of "hinting" about basic link behavior is acceptable in order to accommodate frequently required functionality, particularly in the short term.
It is a nongoal for XLink to be easy to implement because we recognize that certain functionality, in particular out-of-line link handling with extended document groups, is inherently difficult. Our goal is to make implementation at least tractable; that is, we must consider implementability in our deliberations.
The XPointer language is for addressing into the structures of XML documents for the purpose of hyperlinking. While the XPointer syntax may be used to represent addressing into other well-defined structured data, its semantics are defined in terms of XML structures, and the XPointer specification cannot guarantee the interoperability of its use for other data types.
Further, because XPointer is intended to serve hyperlinking purposes, it does not attempt to define a query language such as would be used for structure-aware information retrieval on XML documents. There are some similarities because links must refer to specific locations by characterizing them in some way. However, with links the focus is on the desired locations, while with queries the focus is on the specification itself. Because of this and other practical differences, XPointer does not attempt to solve the many complex issues involved in designing a full-fledged query language for structured and semi-structured data (on which see, for example, [IJDLa] and [IJDLb]).
This implies the following:
Although XPointers can be used independently of XLinks, their primary use is expected to be with URIs provided as part of XLinks. Therefore, we should avoid creating confusion over separator characters and should avoid syntax that would require character-escaping inside a URI.
As a critical component for the success of the XML family of specifications, the XPointer language must be developed as quickly as possible.
XPointers should have a self-contained formal structure model that minimally expresses the addressibility of the various structures in an XML document (such as document, elements, attributes, and so on). This formal model must be supplemented with crisp prose.
There exist hypermedia addressing schemes that are very powerful but very verbose. We believe that XPointer, to be usable by its Web audience, must be expressible in a reasonably compact space; in particular, it needs to be able to fit into an XML attribute value. It should also be readily understandable in a single reading.
The XPointer language should reflect the ways people think naturally about
document structures and be mnemonic and intuitive to use. This may result
in multiple equivalent ways to point to the same data. For example, the
child and string keywords are probably sufficient to address
into any location, from a reductionist perspective, but providing only these
keywords would lead to awkward and unnatural XPointers in many cases.
It is a nongoal for the XPointer language to be easy to implement because we recognize that certain functionality is inherently difficult. Our goal is to make implementation at least tractable; that is, we must consider implementability in our deliberations.
For example, we are considering changing the "spanning" functionality so that lookahead isn't required.