W3C

XML XLink Requirements
Version 1.0

W3C Note 24-Feb-1999

This version: http://www.w3.org/TR/1999/NOTE-xlink-req-19990224
Latest version: http://www.w3.org/TR/NOTE-xlink-req
Editors: Steven J. DeRose (Inso Corp. & Brown Univ.) <[email protected]>
The editor gratefully acknowledges the work of Paula Angerstein (invited expert) <[email protected]>, who prepared the first draft of this document.

Copyright ©1999 W3C (MIT, INRIA, Keio) , All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


Status of this document

This is a W3C Note produced as a deliverable of the XML Linking WG according to its charter. A list of current W3C working drafts and notes can be found at http://www.w3.org/TR .

This document is a work in progress representing the current consensus of the W3C XML Linking Working Group. This version of the XML Link Requirements document has been approved by the XML Linking working group and the XML Plenary to be posted for review by W3C members and other interested parties. Publication as a Note does not imply endorsement by the W3C membership. Comments should be sent to [email protected], which is an automatically and publicly archived email list.

This document is being processed according to the following review schedule:

Review Schedule
ProcessClosing dateStatusContact
XML Linking WG signoff1999/01/21doneXML Linking WG
XML Plenary signoff1999/02/03done [email protected],[email protected]
Publish as W3C Note1999/02/23accepting comments [email protected]
Checkpoint of comments1999/03/23   

Comments about this document should be submitted to the "contact" listed above for each process.

Abstract

This document specifies requirements for the XLink specification. Xlink defines XML-conforming syntax for expressing links among XML documents and other Internet resources, and defines some of the behavior of applications that support it.

Related documents

XML Linking Working Group Page [member only], for general information about the activities of the WG.

XPointer Requirements, produced by the XML Linking Working Group. This document provides requirements governing the work of this WG on the XPointer specification.

XML Pointer Language (XPointer) Working Draft, prior WDs produced by the former XML Working Group, and now under the XML Linking WG. Provides a simple yet powerful mechanism for addressing data portions in XML documents.

XPointer-Information Set Liaison Statement, produced by the XML Linking Working Group. This document enumerates perceived constraints that work on the XPointer specification has indicated may affect the XML Information Set Working Group, since it is those information structures that XPointer provides access to.

XML Linking Language (XLink) Working Draft, the companion specification to this document. Prior WDs produced by the former XML Working Group, and now under the XML Linking WG.

XML Linking Language (XLink) Design Principles, produced by the former XML Working Group, and now under the XML Linking WG. This document provides general design principles governing the work of this WG, involving both the XLink and XPointer specifications.

Table of Contents

1. Overview

This document specifies the requirements for linking among XML documents and other Internet resources. An XML link, as the term is used here, is the specification of an explicit relationship between resources or portions of resources, as well as XLink-defined descriptive information. The specific identification methods that locate various types of data (such as URIs, XPointers, and graphical co-ordinates) are outside the scope of XLink.

2. Design Principles

The following general design principles, adapted from those of XML, underly the XLink design. The XML design principles are described in the W3C Note XML Linking Language (XLink) Design Principles.

  1. XLink must be straightforwardly usable over the Internet.

  2. XLink must be usable by a wide variety of link usage domains and classes of linking application software.

  3. XLink must support HTML 4.0 linking constructs.

  4. The XLink expression language must be XML.

  5. The XLink design must be prepared quickly.

  6. The XLink design must be formal, concise, and illustrative.

  7. XLinks must be human-readable and human-writable.

  8. XLinks may reside within or outside the documents in which the participating resources reside.

  9. XLink must represent the abstract structure and significance of links.

  10. XLink must be feasible to implement.

  11. XLink must be informed by knowledge of established hypermedia systems and standards.

    These include, but are not limited to, Augment, Dexter, FRESS, HTML, Hyper-G, HyTime, InterMedia, MicroCosm, OHS, and the Text Encoding Initiative (see Bibliography).

3. Terminology

While it is not the purpose of this document to establish or constrain the terminology XLink must use, some terminology is defined here for the purpose of clarity in the remainder of this requirements specification.

link

The concrete description of one or more data resources or sub-resource portions, and the nature of their relationship for some given purpose.

end or link end

One of the resources or data resources described and connected by a link.

locator

A specification that identifies a particular link end's location, such as a URI.

role

The semantic function that a given end plays in a link, such as being the thing commented upon, the comment, or a referenced authority. A role is part of the descriptive aspect of linking, and is not itself considered a link end.

traversal

The act of navigating from one end of a link to some other end of the same link. This is commonly accomplished in browsers by clicking on the data at one link end, but other kinds of traversal are also possible and useful. XLink may provide means for controlling which ends of a link can be reached from which other ends; such constraints are commonly called "traversal rules", and serve to make some ends "available" and others "unavailable" from a given starting point.

target or destination

The resource or sub-resource to be reached via a traversal.

trail

An ordered list of sub-resources, each linked to the next. This construct is typically used to create a path or guided tour through some data collection.

available end

An end that can be directly reached from the "current" location (in applications where that is a meaningful notion), is said to be available (or sometimes, "active"). Rules of some kind may dictate that not all ends are available at a given time or from a given starting end.

aggregate

A single end may, in some systems, include multiple discontiguous data objects, that are to be treated together as a single end of the link. Such an end is called an "aggregate", and the resources that are part of it are called its "members". Typically an aggregate has a unified role and other descriptive information in the link, while the members have their own relationships involving how they are assembled or treated as a unit (say, ordering, transformation, selection, and so on).

inline/out of line

In order to make it possible to express links all of whose ends are read-only, many hypermedia systems provide a way to encode links in some place external to the document(s) containing any of their ends. A link that makes use of this capability is said to be stored "out of line", while one whose own location is one of its ends is "inline".

Note: The HTML <A> element is strictly inline; ISMAP files for graphics contain entries that are somewhat analogous to out-of-line links, since they link graphic regions to other resources without being embedded in either the graphic or the other resource.
transclusion

A specific kind of linking in which access of one end automatically causes another end(s) to be retrieved and embedded, appearing much as if their data had occurred at the same place as the initial end that triggered its inclusion. The original definition also requires that systems provide direct access to the originating document as a whole, in its original document context (including, for example, its copyright notice).

The following diagram shows a 3-ended link such as might be used in an editing or review application. The three ends are

Diagram of link with 3 locator arcs, each with a role, and each
pointing to an end in some data

The link accomplishes several things:

A link may also express much other data about itself or its ends; XLink may define some such data, and may permit link creators to add their own as well. An XLink may also place constraints or tests on its ends, such as requiring that certain ends be in certain data formats, or providing ways to detect when a locator has failed. But the functions of identifying ends, describing them and their relationship, and grouping them into an explicit link, are the basic desiderata of XLink.

4. Requirements

A: General user requirements

1: An XML link must be able to describe and relate one or more Internet resources and/or data portions within resources. This implies the following:

  1. addressing complete resources

  2. addressing specific portions of resources (this is largely accomplished via related specifications such as for URLs and XPointers).

  3. expressing links having multiple ends

Note: Links themselves are also resources, and resources to be used with XLink must be expressible via URIs (including fragment identifiers).

2: It must be possible for an XML link itself to serve as one of the resources pointed to by the link. That is, the link construct itself may serve to mark up one of the endpoints of the link.

3: It must be possible for an XML link to address into a resource without requiring modification of that resource. Thus, a link need not physically occur within any of the resources it points to.

4: An XML link, as an abstract datatype, must make at least the following information available to an application:

5: Each end of a link, as an abstract datatype, must make at least the following information available to an application:

6: It must be possible to specify the types of destinations a link's ends can point to. In particular, a resource may be restricted to a specified set of content-types, XML element types, namespaces, and so on.

Note: For example, an application might wish to ensure that for links of type "review-comment", the "topic" end must point to part of an XML document from the DocBook schema, while the "comment" end must point to an entire HTML document.

7: XLink should be able to express limited claims about the legal status of the linked data, particularly in the case of transclusion. For example, a way for a link creator to assert that they have the right to copy the data at some link end(s).

Note: Some users have noted that support of transparent inclusion (transclusion) could conceivably be misconstrued as facilitating plagiarism. One possible option is to provide a way on transclusion links, to express a claim about rights. Browsers, for example, could then mark or prevent transclusions that do not explicitly claim rights. Making it possible for link creators to be clear seems to be about the best one can hope for in addressing this question.

8: It must be possible to control the directions of traversal available among a link's ends.

Note: In HTML the <A> link always has exactly two ends, and traversal is normally available only from one of them (the one where the <A HREF...> is). Out of line and multi-ended links enable a wider variety of potential traversals. The WG is considering what degree of control is desirable, and whether it shall be specified per link type, whether it can depend on environmental factors, and so on.

9 [non-mandatory goal]: It must be possible to detect when a resource a link points to is invalidated or modified.

10: XLink should be expressable in terms of RDF.

B. Mechanical and syntactic requirements

1: A link must be specified using XML.

2: It must be possible to apply XML link semantics to existing documents by modifying the documents' DTDs only, requiring no modification to the document instances themselves.

For example by supplying appropriate information in an element's definition (in the DTD), such as a default ROLE attribute. This provides for layering of XML link semantics onto large bodies of XML documents without requiring modification of those documents.

3: Link markup must be unambiguously recognizable within a standalone XML instance in which it occurs.

4: Specification of a link must be independent of the specification of the address(es) of the resource(s) the link connects and describes.

5: It must be possible to assert the existence of a link from a DTD.

[There is not consensus on whether it is enough to be able to locate link ends that reside in a DTD, or whether there must be a way to put the physical representation of a link actually within a DTD (which imposes greater syntactic challenges).

C: Compatibility requirements

1: An XML link must use a URI to address a resource as defined in IETF RFC 1738: Uniform Resource Locators.

2: An XML link must require using the XPointer specification to identify specific link end locations in an XML resource.

3: An XML link must provide a straightforward way of representing an HTML <A> or <IMG> link. Automated translation of HTML links to XML links must be possible.

4: XLink must liaise with other WGs as appropriate, including RDF and SYMM.

Bibliography

Note: This bibliography only lists works that are readily accessible, either online or in widely-available print publications. A wealth of information on major systems and projects is available on the Memex and Beyond Web site.

Systems

Akscyn, Robert, Donald McCracken, and Elise Yoder. 1987. "KMS: A Distributed Hypermedia System for Managing Knowledge in Organizations." In Proceedings of Hypertext '87, Chapel Hill, NC. November 13-15, 1987. NY: Association for Computing Machinery Press, pp. 1-20.

DeRose, Steven J. and Andries van Dam. 1999. "Document Structure and Markup in the FRESS hypertext system." In Markup Languages 1(1), Winter 1999, pp. 7-46.

Furuta, Richard, Frank M. Shipmann III, Catherine C. Marshall, Donald Brenner, and Hao-wei Hsieh. 1997. "Hypertext paths and the World-Wide Web: Experiences with Walden's Paths." In Proceedings of Hypertext '97. NY: Association for Computing Machinery Press.

Garret, L. Nancy, Karen E. Smith, and Norman Meyrowitz. 1986. "Intermedia: Issues, Strategies, and Tactics in the Design of a Hypermedia System." In Proceedings of the Conference on Computer-Supported Cooperative Work.

Hall, Wendy, Hugh Davis, and Gerard Hutchings. 1996. Rethinking Hypermedia: The Microcosm Approach. Boston: Kluwer Academic Publishers. ISBN 0-7923-9679-0.

Marshall, Catherine C., Frank M. Shipman, III, and James H. Coombs. 1994. "VIKI: Spatial Hypertext Supporting Emergent Structure". In Proceedings of the 1994 European Conference on Hypertext. NY: Association for Computing Machinery Press.

Yankelovich, Nicole, Bernard J. Haan, Norman K. Meyrowitz, and Steven M. Drucker. 1988. "Intermedia: The Concept and the Construction of a Seamless Information Environment." IEEE Computer (January, 1988): 81-96.

Standards

Berners-Lee, T. and L. Masinter, editors. December 1994. "Uniform Resource Locators (URL)". IETF document RFC 17338.

DeRose Steven J. and David G. Durand. 1994. Making HyperMedia Work: A User's Guide to HyTime. Boston: Kluwer Academic Publishers. ISBN 0-7923-9432-1.

DeRose, Steven J. and David G. Durand. 1 995. "The TEI Hypertext Guidelines." In Text Encoding Initiative: Background and Context. Boston: Kluwer Academic Publishers. ISBN 0-7923-3689-5.

DeRose, Steven and Eve Maler (eds). 1998. "XML Linking Language (XLink)." World Wide Web Consortium Working Draft. March 1998.

DeRose, Steven and Eve Maler (eds). 1998. "XML Pointer Language (XPointer)." World Wide Web Consortium Working Draft. March 1998.

Grønbæk, Kaj and Randall H. Trigg. 1996. "Toward a Dexter-based model for open hypermedia: Unifying embedded references and link objects." In Proceedings of Hypertext '96. NY: Association for Computing Machinery Press. Also available online.

Halasz, Frank. 1994. "The Dexter Hypertext Reference Model." In Communications of the Association for Computing Machinery 37 (2), February 1994: 30-39.

Hardman, Lynda, Dick C. A. Bulterman, and Guido van Rossum. 1994. "The Amsterdam Hypermedia Model: Adding Time and Context to the Dexter Model." In Communications of the Association for Computing Machinery 37.2 (February 1994): 50-63.

International Organization for Standardization. 1992. ISO/IEC 10744. "Information technology - Hypermedia/Time-based Structuring Language (HyTime)." Also available online.

Moline, Judi, Dan Denigni, and Jean Baronas (eds.). 1990. Proceedings of the Hypertext Standardization Workshop, January 16-18, 1990, National Institute of Standards and Technology. Washington: U.S. Government Printing Office. Available from the National Technical Information Service as Publication PB90215864. (ordering information)

Nürnberg, Peter J. Home page of the Open Hypermedia Systems Working Group.

Sperberg-McQueen, C. Michael and Lou Burnard (eds). 1994. Guidelines for Electronic Text Encoding and Interchange. Chicago, Oxford: Text Encoding Initiative. Also available online. See especially the section on extended pointer syntax. Also available for ftp.

General Hypertext

Agosti, Maristelle and Alan Smeaton. 1996. Information Retrieval and Hypertext. Boston: Kluwer Academic Publishers. ISBN 0-7923-9710-X.

Bush, Vannevar. 1945. "As We May Think." Atlantic Monthly 176 (July): 101-108. Links to many of Bush's works are collected here.

Catano, James V. 1979. "Poetry and Computers: Experimenting with the Communal Text." In Computers and the Humanities 13 (9): 269-275.

Conklin, Jeff. 1987. "Hypertext: An Introduction and Survey." IEEE Computer 20 (9): 17-41.

DeRose, Steven J. 1989. "Expanding the Notion of Links." In Proceedings of Hypertext '89, Pittsburgh, PA. NY: Association for Computing Machinery Press.

Engelbart, Douglas C. 1963. "A Conceptual Framework for the Augmentation of Man's Intellect". In Vistas in Information Handling, Vol. 1 (P. Howerton, ed.). Washington, DC: Spartan Books: 1-29. Reprinted in Greif, Irene (ed.), 1988. Computer-Supported Cooperative Work: A Book of Readings. San Mateo, California: Morgan Kaufmann Publishers, pp. 35-65. ISBN 0934613575.

Gibson, David, Jon Kleinberg, and Prabhakar Raghavan. 1998. "Inferring Web Communities from Link Topology." In Proceedings of Hypertext '98, Pittsburgh, PA. NY: Association for Computing Machinery Press.

Halasz, Frank. 1987. "Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems." Address presented at Hypertext '87, November 13-15, 1987. Reprinted in Communications of the Association for Computing Machinery 31 (7), July 1988: 836-855.

Kahn, Paul. 1991. "Linking Together Books: Experiments in Adapting Published Material into Intermedia Documents." In Paul Delany and George P. Landow (eds), Hypermedia and Literary Studies. Cambridge: MIT Press.

Landow, George P. 1987. "Relationally Encoded Links and the Rhetoric of Hypertext." In Proceedings of Hypertext '87, Chapel Hill, NC, November 13-15, 1987. NY: Association for Computing Machinery Press: 331-344.

Meyrowitz, Norman. 1986. "Intermedia: the Architecture and Construction of an Object-Oriented Hypermedia system and Applications Framework." In Proceedings of OOPSLA. Portland, OR.

Nelson, Theodore H. 1987. Literary Machines. (available in multiple editions).

Trigg, Randall H. 1988. "Guided Tours and Tabletops: Tools for Communicating in a Hypertext Environment." In ACM Transactions on Office Information Systems, 6.4 (October 1988): 398-414.

Trigg, Randall H. 1991. "From Trailblazing to Guided Tours: The Legacy of Vannevar Bush's Vision of Hypertext Use." In Nyce, James M. and Paul Kahn, eds, 1991, From Memex to Hypertext: Vannevar Bush and the Mind's Machine. San Diego: Academic Press, pp. 353-367. A thorough review.

Yankelovich, Nicole, Norman Meyrowitz, and Andries van Dam. 1985. "Reading and Writing the Electronic Book." IEEE Computer 18 (October, 1985): 16-30.

Zellweger, Polle T. 1989. "Scripted Documents: A Hypermedia Path Mechanism." In Proceedings of Hypertext '89. NY: Association for Computing Machinery Press.