This document specifies constructs that may be inserted into XML resources to describe links between objects. A link, as the term is used here, is an explicit relationship between two or more data objects or portions of data objects. This specification is concerned with the syntax used to assert link existence and describe link characteristics. Implicit (unasserted) relationships, for example that of one word to the next or that of a word in a text to its entry in an on-line dictionary are obviously important, but outside its scope.

Links are asserted by elements contained in XML documents. The simplest case is very like an HTML A link, and has these characteristics:

The link is expressed at one of its ends (similar to the A element in some document)

While this set of characteristics is already very powerful and obviously has proven itself highly useful and effective, each of these assumptions also limits the range of hypertext functionality. The linking model defined here provides ways to create links that go beyond each of these specific characteristics, thus providing features previously available mostly in dedicated hypermedia systems.

The locator for a resource is typically provided by means of a Uniform Resource Identifier, or URI. XPointers can be used in conjunction with the URI structure, as fragment identifiers or queries, to specify a more precise sub-resource. XPointers can be used in conjunction with URIs to specify a more precise sub-resource.

A locator generally contains a URI, as described in IETF RFCs and . As these RFCs state, the URI may include a trailing query (marked by a leading "?"), and be followed by a "#" and a fragment identifier, with the query interpreted by the host providing the indicated resource, and the interpretation of the fragment identifier dependent on the data type of the indicated resource.

In order to locate XML documents and portions of documents, a locator value may contain either a URI or a fragment identifier, or both. Any fragment identifier for pointing into XML must be an XPointer.

Special syntax may be used to request the use of particular processing models in accessing the locator's resource. This is designed to reflect the realities of network operation, where it may or may not be desirable to exercise fine control over the distribution of work between local and remote processors. Locator LocatorURI | Connector ( XPointer | Name) | URI Connector (XPointer | Name) Connector'#' | '|' URIURIchar*

In this discussion, the term designated resource refers to the resource which an entire locator serves to locate. The following rules apply:

The URI, if provided, locates a resource called the containing resource .

Note that by definition, a URI includes an optional query component.

In the case where the URI contains a query (to be interpreted by the server), information providers and authors of server software are urged to use queries as follows: Query Query'XML-XPTR=' ( XPointer | Name)

The existence of a link is asserted by a linking element. Linking elements must be recognized reliably by application software in order to provide appropriate display and behavior. There are several ways link recognition could be accomplished: for example, reserving element type names, reserving attributes, or leaving the matter of recognition entirely up to stylesheets and application software. Reserving attributes provides a balance between giving users control of their own markup language design and keeping the important structural fact "is a link" explicit within documents. Therefore, XLink linking-related elements are recognized based on the use of a designated attribute named xml:link. Possible values are simple and extended (which identify linking elements), as well as locator, group, and document (which identify other related types of elements). An element in whose start-tag such an attribute appears is to be treated as an element of the indicated XLink type as dictated by this specification. For example:<A xml:link="simple" href="http://www.w3.org/">The W3C</A>

Note: Subject to definitions to be developed in related standards, the methods described in may be used to rename the reserved attribute.

There are two mechanisms that may be used to associate the xml:link and xml:attributes attributes with a linking element. The simplest is to provide the attribute explicitly in a start-tag. A less verbose method is to use XML's facilities for declaring default attribute values. For example, the following attribute-list declaration would indicate that all instances of the A element in the current document are XLink simple links:<!ATTLIST A xml:link CDATA #FIXED "simple">

XLink defines two types of linking element:

A simple link, which is usually inline and always one-directional

Both kinds of links can have various types of information associated with them.

Hyperlinked documents are often best processed in groups rather than one at a time. If it is desired to highlight resources to advertise that traversal can be initiated, and if at the same time out-of-line links are being used, it may be an absolute requirement to read other documents to find these links and discover where the resources are.

In these cases, an extended link group element, a special kind of extended link, may be used to store a list of links to other documents that together constitute an interlinked group. Each such document is identified by means of an extended link document element, a special kind of locator element.

Following are sample declarations for extended link group and extended link document elements, showing all the possible XLink-related attributes they may have (using the parameter entities provided in ). The xml:link attribute value for an extended link group element must be group, and the value for an extended link document element must be document.<!ELEMENT group (document*)> <!ATTLIST group xml:link CDATA #FIXED "group" steps CDATA #IMPLIED > <!ELEMENT document EMPTY> <!ATTLIST document xml:link CDATA #FIXED "document" %locator.att; >

The steps attribute may be used by an author to help deal with the situation where an extended link group directs application software to locate another document, which proves to contain an extended link group of its own. There is a potential for infinite regress, and yet there are situations where processing several levels of extended link groups is useful. The steps attribute should have a numeric value that serves as a hint from the author to any link processor as to how many steps of extended link group processing should be undertaken. It does not have any normative effect.

For example, should a group of documents be organized with a single "hub" document containing all the out-of-line links, it might make sense for each non-hub document to contain an extended link group containing only one reference to the hub document. In this case, the best value for steps would be 2.

Link formatting and link behavior are inextricably connected. In general, formatting involves the appearance or treatment of the link prior to any user action, such as choice of font, color, icons, and other devices to show that a link is present. Behavior focuses on what happens when the link is traversed, such as opening, closing, or scrolling windows or panes; displaying the data from various resources in various ways; testing, authenticating, or logging user and context information; or executing various programs.

XLink does not provide mechanisms for controlling link formatting because it is considered to fall into the domain of stylesheets. Link behavior should ideally also be determined by rules based on link types, resource roles, user circumstances, and other factors. However, XLink does provide a few very general behavior mechanisms because they are commonly considered to reflect major or invariant semantics of link types.

The mechanism that XLink provides allows link authors to signal certain intentions as to the timing and effects of traversal. Such intentions can be expressed along two axes, labeled show and actuate. These are used to express policies rather than mechanisms ; any link-processing application software is free to devise its own mechanisms, best suited to the user environment and processing mode, to implement the requested policies.

In many cases, much finer control over the details of traversal behavior, of the type that existing hypertext software typically provides, will be desired. Such fine control of link behavior is outside the scope of this specification. However, the behavior attribute is provided as a standard place for authors to provide, and in which application software may look, for detailed behavioral instructions.

XLink provides many attributes that can be attached to linking elements to describe various aspects of links, and each has a default name. It may be desired to use existing elements in XML documents as linking elements, but such elements might already have attributes whose names conflict with those described in this document. To avoid collisions, user-chosen attribute names can be mapped to the default names using the xml:attributes attribute.

This attribute must contain an even number of white-space-separated names, which are treated as pairs. In each pair, the first name must be one of the default XLink names (role, href, title, show, inline, content-role, content-title , actuate, behavior, steps). The second name, when recognized in the document, will be treated as though it were playing the role assigned to the first. For example, consider a DTD with the following declaration: <!ELEMENT TEXT-BOOK ANY> <!ATTLIST TEXT-BOOK title CDATA #IMPLIED role (PRIMARY|SUPPORTING) #IMPLIED >

If it were desired to use this as a simple link, it would be necessary to remap a couple of attributes. This could be accomplished in the internal subset: <!ATTLIST TEXT-BOOK xml:link CDATA #FIXED "simple" xml:attributes CDATA #FIXED "title xl-title role xl-role" >

Then in the document, the following would be recognized as a simple link: <TEXT-BOOK title="Compilers: Principles, Techniques, and Tools" role="PRIMARY" xl-title="Primary Textbook for the Course" xl-role="ONLINE-PURCHASE" href="/cgi/auth-search?q="+Aho+Sethi+Ullman"/>

An element conforms to XLink if:

The element has an xml:link attribute whose value is one of the attribute values prescribed by this specification, and

Note that conformance is assessed at the level of individual elements, rather than whole XML documents, because XLink and non-XLink linking mechanisms may be used side by side in any one document.

An application conforms to XLink if it interprets XLink-conforming elements according to all required semantics prescribed by this specification and, for any optional semantics it chooses to support, supports them in the way prescribed.