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.

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

Review Schedule
Process	Closing date	Status	Contact
XML Linking WG signoff	1999/01/21	done	XML Linking WG
XML Plenary signoff	1999/02/03	done	[email protected],[email protected]
Publish as W3C Note	1999/02/23	accepting comments	[email protected]
Checkpoint of comments	1999/03/23

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

Topic: the document portion (commonly a small part of a larger document), on which the reviewer is making a suggestion;
Comment: the comment itself, saying what the reviewer feels is wrong (or perhaps right) with the topic data;
Suggestion: the reviewer's suggested change.

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:

Identifies the location of the data that makes up each of its ends;
States what role each end plays in the link as a whole;
Explicitly groups the ends.

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:

addressing complete resources
addressing specific portions of resources (this is largely accomplished via related specifications such as for URLs and XPointers).
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:

A specification of each of its ends (as described below).
An indication of whether or not the link's location is itself an end of the link.

Note: Making the link's own location an end is a distinct and common special case, probably worthy of special syntax (even though, of course, one could always add an explicit end that pointed to the link's location using generic mechanisms). Supporting links whose own location is not one of their link ends, is critical so that links can be created to connect and describe resources without modifying those resources themselves. In such cases the actual location of the link is generally insignificant to the application.
An optional order in which the link's ends are accessed or made available. The link processor must be able to access each resource that serves as a link endpoint in an order specified by the link author.

Note: This order might, for example, be used in a menu of available destination ends when the user clicks on the data at one end of a link. [there is not consensus on the need for ordering ends, or how it relates to ordering of members within ends, if those are to be supported].
A required link type that may have meaning to specific applications (if not specified, the type is specifically "undefined"). This can indicate the link's purpose so that application-specific processing can be applied.

For compatibility with HTML, it appears necessary to leave the type implicit in some cases; such a link is considered to have a type, specifically "undefined".
Some human-readable identifying text, or title. This can be displayed or otherwise used as a description of the link as supplied by the link author.

Note: Link titles raise issues of internationalization. They must be able to include text not just in English. They are also very important as a means of addressing Accessibility concerns for the print-disabled user.

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

A role, to specify the end's particular function in relation to the link and/or the other ends. A rolemay have meaning to specific applications.
A title, some human-readable identifying text for the particular end. This can be displayed or otherwise used as a description of the link as supplied by the link author.

Note: Link titles raise issues of internationalization; it is required that they be able to include text not just in English. They are also very important as a means of addressing Accessibility concerns for the print-disabled user.
Some behavior hints that may suggest certain treatment on the part of link processors.

For example, simple indications of when to access a resource, where to display it, or what to do with the originating end. The link processor can pass on hints as how to display and process the link to the application; a simple example is that a stylesheet in a browsing application could access them to condition its display or interaction behavior. In some applications such hints may have no meaning, and are therefore not required.
A locator that identifies the specific destination constituting the particular link end. (see also the Note on the next item)
A context locator that identifies the corresponding containing scope that should be displayed, indexed, or otherwise used to provide contextual meaning for the resource identified by the locator.

Note: The distinction between this and the last item is similar to what underlies the typical treatment of fragment identifiers in HTML <A> links: The client retrieves a context which is typically a whole document, but then somehow identifies the particular target portion within it. Another example could be a link in a review or annotation application: it may point to a particular mis-spelled word, even though a later user is unlikely to desire retrieval of merely the one word without its document context.

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.

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.

XML XLink Requirements
Version 1.0

W3C Note 24-Feb-1999

Status of this document

Abstract

Related documents

Table of Contents

1. Overview

2. Design Principles

3. Terminology

4. Requirements

A: General user requirements

B. Mechanical and syntactic requirements

C: Compatibility requirements

Bibliography

Systems

Standards

General Hypertext

XML XLink RequirementsVersion 1.0

W3C Note 24-Feb-1999

Abstract

Related documents

Table of Contents

Systems

Standards

General Hypertext

XML XLink Requirements
Version 1.0