[This local archive copy mirrored from the canonical site: http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303; links may not have complete integrity, so use the canonical document at this URL if possible.]

W3CNOTE-xlink-principles-19980303


XML Linking Language (XLink) Design Principles

World Wide Web Consortium Note 3-March-1998

This version:
http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303
Latest version:
http://www.w3.org/TR/NOTE-xlink-principles
Editors:
Eve Maler (ArborText) <elm@arbortext.com>
Steve DeRose (Inso Corp. and Brown University ) <sderose@eps.inso.com>

Status of this document

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).

Abstract

This document explicates the design principles behind the XLink language and its related XPointer language.

XML Linking Language (XLink) Design Principles

Version 1.0

Table of Contents

1. XLink Design Principles
    1.1 XLink Shall Be Straightforwardly Usable Over the Internet
    1.2 XLink Shall Be Usable by a Wide Variety of Link Usage Domains and of Classes of Linking Application Software
    1.3 The XLink Expression Language Shall Be XML
    1.4 The XLink Design Shall Be Prepared Quickly
    1.5 The XLink Design Shall Be Formal and Concise
    1.6 XLinks Shall Be Human-Readable
    1.7 XLinks May Reside Outside the Documents in Which the Participating Resources Reside
    1.8 XLink Shall Represent the Abstract Structure and Significance of Links
    1.9 XLink Must Be Feasible to Implement
2. XPointer Design Principles
    2.1 XPointers Shall Address into XML Documents
    2.2 XPointers Shall Be Straightforwardly Usable Over the Internet
    2.3 XPointers Shall Be Straightforwardly Usable in URIs
    2.4 The XPointer Design Shall be Prepared Quickly
    2.5 The XPointer Design Shall Be Formal and Concise
    2.6 The XPointer Syntax Shall Be Reasonably Compact and Human Readable
    2.7 XPointers Shall Be Usable
    2.8 XPointers Must Be Feasible to Implement
3. References

1. XLink Design Principles

1.1 XLink Shall Be Straightforwardly Usable Over the Internet

This implies the following:

1.2 XLink Shall Be Usable by a Wide Variety of Link Usage Domains and of Classes of Linking Application Software

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.

1.3 The XLink Expression Language Shall Be XML

XLink is an XML-based language; that is to say, individual XLink structures must be represented using XML element and attribute markup.

1.4 The XLink Design Shall Be Prepared Quickly

As a critical component for the success of the XML family of specifications, XLink must be developed as quickly as possible.

1.5 The XLink Design Shall Be Formal and Concise

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.

1.6 XLinks Shall Be Human-Readable

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.

1.7 XLinks May Reside Outside the Documents in Which the Participating Resources Reside

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.

1.8 XLink Shall Represent the Abstract Structure and Significance of Links

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.

1.9 XLink Must Be Feasible to Implement

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.

2. XPointer Design Principles

2.1 XPointers Shall Address into XML Documents

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]).

2.2 XPointers Shall Be Straightforwardly Usable Over the Internet

This implies the following:

2.3 XPointers Shall Be Straightforwardly Usable in URIs

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.

2.4 The XPointer Design Shall be Prepared Quickly

As a critical component for the success of the XML family of specifications, the XPointer language must be developed as quickly as possible.

2.5 The XPointer Design Shall Be Formal and Concise

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.

2.6 The XPointer Syntax Shall Be Reasonably Compact and Human Readable

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.

2.7 XPointers Shall Be Optimized for Usability

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.

2.8 XPointers Must Be Feasible to Implement

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.

3. References

IJDLa
Abiteboul, S., S. Cluet, V. Christophides, T. Milo, G. Moerkotte, and J. Simeon. 1997. "Querying documents in object databases." In International Journal on Digital Libraries 1(1). Springer-Verlag.
IJDLb
Abiteboul, S., D. Quass, J. McHugh, J. Widom, J. L. Wiener. 1997. "The Lorel query language for semi-structured data." In International Journal on Digital Libraries 1(1). Springer-Verlag.