The design of XLink has been informed by knowledge of established hypermedia systems and standards. The following standards have been especially influential:

Many other linking systems have also informed the design of XLink, especially , , , , and .

See the XLink Requirements Document for a thorough explanation of requirements for the design of XLink.

An XLink link is an explicit relationship between resources or portions of resources. It is made explicit by an XLink linking element, which is an XLink-conforming XML element that asserts the existence of a link. There are six XLink elements; only two of them are considered linking elements. The others provide various pieces of information that describe the characteristics of a link. (The term link as used in this specification refers only to an XLink link, though nothing prevents non-XLink constructs from serving as links.)

The notion of resources is universal to the World Wide Web. As discussed in , a resource is any addressable unit of information or service. Examples include files, images, documents, programs, and query results. The means used for addressing a resource is a IRI (Internationalized Resource Identifier) reference (described more in ). It is possible to address a portion of a resource. For example, if the whole resource is an XML document, a useful portion of that resource might be a particular element inside the document. Following a link to it might result, for example, in highlighting that element or scrolling to that point in the document.

When a link associates a set of resources, those resources are said to participate in the link. Even though XLink links must appear in XML documents, they are able to associate all kinds of resources, not just XML-encoded ones.

One of the common uses of XLink is to create hyperlinks. A hyperlink is a link that is intended primarily for presentation to a human user. Nothing in XLink's design, however, prevents it from being used with links that are intended solely for consumption by computers.

Using or following a link for any purpose is called traversal. Even though some kinds of link can associate arbitrary numbers of resources, traversal always involves a pair of resources (or portions of them); the source from which traversal is begun is the starting resource and the destination is the ending resource. Note that the term resource used in this fashion may at times apply to a resource portion, not a whole resource.

Information about how to traverse a pair of resources, including the direction of traversal and possibly application behavior information as well, is called an arc. If two arcs in a link specify the same pair of resources, but they switch places as starting and ending resources, then the link is multidirectional, which is not the same as merely going back after traversing a link.

A local resource is an XML element that participates in a link by virtue of having as its parent, or being itself, a linking element. Any resource or resource portion that participates in a link by virtue of being addressed with an IRI reference is considered a remote resource, even if it is in the same XML document as the link, or even inside the same linking element. Put another way, a local resource is specified by value, and a remote resource is specified by reference.

An arc that has a local starting resource and a remote ending resource goes outbound, that is, away from the linking element. (Examples of links with such an arc are the HTML A element, HyTime clinks, and Text Encoding Initiative XREF elements.) If an arc's ending resource is local but its starting resource is remote, then the arc goes inbound. If neither the starting resource nor the ending resource is local, then the arc is a third-party arc. Though it is not required, any one link typically specifies only one kind of arc throughout, and thus might be referred to as an inbound, outbound, or third-party link.

To create a link that emanates from a resource to which you do not have (or choose not to exercise) write access, or from a resource that offers no way to embed linking constructs, it is necessary to use an inbound or third-party arc. When such arcs are used, the requirements for discovery of the link are greater than for outbound arcs. Documents containing collections of inbound and third-party links are called link databases, or linkbases.

XLink processing depends on , , , , and .

An XML element conforms to XLink if:

This specification imposes no particular constraints on schemas; conformance applies only to elements and attributes.

An XLink application is any software module that interprets well-formed XML documents containing XLink elements and attributes, or XML information sets containing information items and properties corresponding to XLink elements and attributes. (This document refers to elements and attributes, but all specifications herein apply to their information set equivalents as well.)

XLink defines two conformance levels for an XLink application, simple and full.

While the XLink attributes are considered global by virtue of their use of the namespace mechanism, their allowed combinations on any one XLink element type depend greatly on the value of the special type attribute (see for more information) for the element on which they appear. The conformance constraint notes in this specification detail their allowed usage patterns. Following is a summary of the element types (columns) on which the global attributes (rows) are allowed, with an indication of whether a value is required (R) or optional (O):

(See also , , and for examples of non-normative schemas that illustrate the allowed patterns of attributes.)

This specification uses the convention xxx-type element to refer to elements that must adhere to a named set of constraints associated with an XLink element type, no matter what name the element actually has. For example, locator-type element would refer to all of the following elements:

Various XLink element types have special meanings dictated by this specification when they appear as direct children of other XLink element types. Following is a summary of the child element types that play a significant role in particular parent element types. (Other combinations are not conformant.)

Using XLink potentially involves using a large number of attributes for supplying important link information. In cases where the values of the desired XLink attributes are unchanging across individual instances in all the documents of a certain type, attribute value defaults (fixed or not) may be added to a DTD or schema so that the attributes do not have to appear physically on element start-tags. For example, if attribute defaults were provided for the xmlns:xlink, xmlns:my, type, show, and actuate attributes in the example in the introduction to , the example would look as follows:

Information sets that have been created under the control of a DTD have all attribute values filled in. Note, however, that parsers are not required to process the external subset. Applications, such as web browsers, that do not process the external subset will not be aware of any default values identified therein.

Note also that using the attribute value default technique to specify the XLink namespace declaration has no equivalent in , , or other modern schema languages. While it can be used when DTD-informed parsing is performed, it poses an interoperability risk and should be used with care.

This specification defines only attributes and attribute values in the XLink namespace. There is no restriction on using non-XLink attributes alongside XLink attributes. In addition, most XLink attributes are optional and the choice of simple or extended link is up to the markup designer or document creator, so a DTD or other schema that uses XLink features need not use or declare the entire set of XLink's attributes. Finally, while this specification identifies the minimum constraints on XLink markup, schemas that use XLink are free to tighten these constraints. The use of XLink does not absolve a valid document from conforming to the constraints expressed in its governing schema.

Following is an example of a crossReference element with both XLink and non-XLink attributes:

Because XLink's global attributes require the use of namespace prefixes, non-XLink-based links in legacy documents generally do not serve as conforming XLink constructs as they stand, even if attribute value defaulting is used. For example, XHTML 1.0 has an a element with an href attribute, but because the attribute is a local one attached to the a element in the XHTML namespace, it is not the same as an xlink:href global attribute in the XLink namespace.

This specification defines XLink markup, that is, what combinations XLink attributes and what arrangements of elements with XLink attributes are conformant. It also defines the XLink semantics of such conformant markup. When XLink is used on elements that have other attributes or related elements with linking semantics, XLink can not and does not attempt to define the semantics of such combinations.

If an element allows such possibly conflicting markup to occur, it should specify the semantics of the result.

An extended link is a link that associates an arbitrary number of resources. The participating resources may be any combination of remote and local.

The only kind of link that is able to have inbound and third-party arcs is an extended link. Typically, extended linking elements are stored separately from the resources they associate (for example, in entirely different documents). Thus, extended links are important for situations where the participating resources are read-only, or where it is expensive to modify and update them but inexpensive to modify and update a separate linking element, or where the resources are in formats with no native support for embedded links (such as many multimedia formats).

The following diagram shows an extended link that associates five remote resources. This could represent, for example, information about a student's course load: one resource being a description of the student, another being a description of the student's academic advisor, two resources representing courses that the student is attending, and the last resource representing a course that the student is auditing.

A simple link is a link that associates exactly two resources, one local and one remote, with an arc going from the former to the latter. Thus, a simple link is always an outbound link.

The purpose of a simple link is to be a convenient shorthand for the equivalent extended link. A single simple linking element combines the basic functions of an extended-type element, a locator-type element, an arc-type element, and a resource-type element.

The following diagram shows the characteristics of a simple link; it associates one local and one remote resource, and implicitly provides a single traversal arc from the local resource to the remote one. This could represent, for example, the name of a student appearing in text which, when clicked, leads to information about the student.

The attribute that identifies XLink element types is type.

When the value of the type attribute is none, the element has no XLink-specified meaning, and any XLink-related content or attributes have no XLink-specified relationship to the element.

The attribute that supplies the data that allows an XLink application to find a remote resource (or resource fragment) is href. It may be used on simple-type elements, and must be used on locator-type elements.

The value of the href attribute is a (LEIRI). Processing a relative identifier against a base is handled straightforwardly; the algorithms of can be applied directly, treating the characters additionally allowed in LEIRIs in the same way that unreserved characters are in URI references.

If the value of the href attribute is a relative reference (as defined in , also known as "relative URI" in earlier RFCs), or results in a relative reference after escaping, its absolute version must be computed by the method of before use.

If a locator includes a fragment identifer, the syntax of the fragment identifier is defined by the media type of the representation returned when the locator is dereferenced. For locators into XML resources (that is, resources with the media type "application/xml" or media types that defer to the fragment identifier syntax of "application/xml" media), the syntax of the fragment identifier is expected to be defined by the successor to . Technically, there is no fragment identifier syntax for XML resources at the time of this writing, though the and are explicitly supported by several XML vocabularies.

The attributes that describe the meaning of resources within the context of a link are role, arcrole, and title. The role attribute may be used on extended-, simple-, locator-, and resource-type elements. The arcrole attribute may be used on arc- and simple-type elements. The title attribute may be used on all of these types of elements.

The value of the role or arcrole attribute is a . The identifier must not be relative.

The title attribute is used to describe the meaning of a link or resource in a human-readable fashion, along the same lines as the role or arcrole attribute. (However, see also .) A value is optional; if a value is supplied, it should contain a string that describes the resource. The use of this information is highly dependent on the type of processing being done. It may be used, for example, to make titles available to applications used by visually impaired users, or to create a table of links, or to present help text that appears when a user lets a mouse pointer hover over a starting resource.

The behavior attributes are show and actuate. They may be used on the simple- and arc-type elements. When used on a simple-type element, they signal behavior intentions for traversal to that link's single remote ending resource. When they are used on an arc-type element, they signal behavior intentions for traversal to whatever ending resources (local or remote) are specified by that arc.

The show and actuate attributes are not required.

Applications encountering arc-type elements in linkbase lists must treat the behavior attributes as if they were specified as show="none" and actuate="onLoad", even if other values were specified.

The traversal attributes are label, from, and to. The label attribute may be used on the resource- and locator-type elements. The from and to attributes may be used on the arc-type element.