1.1 Origin and Goals

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

• HTML [HTML]: Defines several element types that represent links.

• HyTime [ISO/IEC 10744]: Defines inline and inbound and third-party link structures and some semantic features, including traversal control and presentation of objects.

• Text Encoding Initiative Guidelines [TEI]: Provides structures for creating links, aggregate objects, and link collections.

Many other linking systems have also informed the design of XLink, especially [Dexter], [FRESS], [OHS], [MicroCosm], and [Intermedia].

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

2.1 Links and Resources

[Definition: An XLink link is an explicit relationship between resources or portions of resources.] [Definition: 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. [Definition: As discussed in [IETF RFC 2396], 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 URI (Uniform Resource Identifier) reference (described more in 5.4 Locator Attribute (href)). 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.

[Definition: 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. [Definition: 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.

2.2 Arcs, Traversal, and Behavior

[Definition: 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); [Definition: the source from which traversal is begun is the starting resource] and [Definition: 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.

[Definition: 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.

2.3 Resources in Relation to the Physical Location of a Linking Element

[Definition: 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]. [Definition: Any resource or resource portion that participates in a link by virtue of being addressed with a URI 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."

[Definition: 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.) [Definition: If an arc's ending resource is local but its starting resource is remote, then the arc goes inbound.] [Definition: 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. [Definition: Documents containing collections of inbound and third-party links are called link databases, or linkbases.]

3.1 Processing Dependencies

XLink processing depends on [XML], [XML Names], [XML Base], and [IETF RFC 2396] (as updated by [IETF RFC 2732]).

3.2 Markup Conformance

An XML element conforms to XLink if:

1. it has a type attribute from the XLink namespace whose value is one of "simple", "extended", "locator", "arc", "resource", "title", or "none", and

2. it adheres to the conformance constraints imposed by the chosen XLink element type, as prescribed in this specification.

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

3.3 Application Conformance

An XLink application is any software module that interprets well-formed XML documents containing XLink elements and attributes, or XML information sets [XIS] 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.) Such an application is conforming if:

1. it observes the mandatory conditions for applications ("must") set forth in this specification, and

2. for any optional conditions ("should" and "may") it chooses to observe, it observes them in the way prescribed, and

3. it performs markup conformance testing according to all the conformance constraints appearing in this specification.

4.1 XLink Attribute Usage Patterns

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 5.3 XLink Element Type Attribute (type) 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 B Sample DTD for a non-normative DTD that illustrates 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:

<locator xlink:type="locator" ... />
<loc xlink:type="locator" ... />
<my:pointer xlink:type="locator" ... />

4.2 XLink Element Type Relationships

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 have no XLink-dictated significance.)

4.3 Attribute Value Defaulting

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 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 4 XLink Markup Design, the example would look as follows:

<my:crossReference
xlink:href="students.xml"
xlink:role="http://www.example.com/linkprops/studentlist"
xlink:title="Student List">
Current List of Students
</my:crossReference>

Information sets that have been created under the control of a DTD have all attribute values filled in.

4.4 Integrating XLink Usage with Other Markup

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 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, DTDs 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 DTD.

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

<my:crossReference
xmlns:my="http://example.com/"
my:lastEdited="2000-06-10"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:type="simple"
xlink:href="students.xml">
Current List of Students
</my:crossReference>

4.5 Using XLink with Legacy Markup

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.

5.1 Extended Links (extended-Type Element)

[Definition: 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.

Without the extended link, the resources might be entirely unrelated; for example, they might be in five separate documents. The lines emanating from the extended link represent the association it creates among the resources. However, notice that the lines do not have directionality. Directionality is expressed with traversal rules; without such rules being provided, the resources are associated in no particular order, with no implication as to whether and how individual resources are accessed.

The following diagram shows an extended link that associates five remote resources and one local resource (a special element inside the extended link element). This could represent the same sort of course-load example as described above, with the addition of the student's grade point average stored locally. Again, the lines represent mere association of the six resources, without traversal directions or behaviors implied.

The XLink element type for extended links is any element with an attribute in the XLink namespace called type with a value of "extended".

The extended-type element may contain a mixture of the following elements in any order, possibly along with other content and markup:

• locator-type elements that address the remote resources participating in the link

• arc-type elements that provide traversal rules among the link's participating resources

• title-type elements that provide human-readable labels for the link

• resource-type elements that supply local resources that participate in the link

It is not an error for an extended-type element to associate fewer than two resources. If the link has only one participating resource, or none at all, it is simply untraversable. Such a link may still be useful, for example, to associate properties with a single resource by means of XLink attributes, or to provide a placeholder for link information that will be populated eventually.

Subelements of the simple or extended type anywhere inside a parent extended-type element have no XLink-specified meaning. Subelements of the locator, arc, or resource type that are not direct children of an extended-type element have no XLink-specified meaning.

The extended-type element may have the semantic attributes role and title (see 5.5 Semantic Attributes (role, arcrole, and title)). They supply semantic information about the link as a whole; the role attribute indicates a property that the entire link has, and the title attribute indicates a human-readable description of the entire link. If other XLink attributes are present on the element, they have no XLink-specified relationship to the link. If both a title attribute and one or more title-type elements are present, they have no XLink-specified relationship; a higher-level application built on XLink will likely want to specify appropriate treatment (for example, precedence) in this case.

<!ELEMENT courseload ((tooltip|person|course|gpa|go)*)>
<!ATTLIST courseload
xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED>
<!ELEMENT tooltip ANY>
<!ATTLIST tooltip
xlink:type (title) #FIXED "title"
xml:lang CDATA #IMPLIED>
<!ELEMENT person EMPTY>
<!ATTLIST person
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT course EMPTY>
<!ATTLIST course
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #FIXED "http://www.example.com/linkprops/course"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!-- GPA = "grade point average" -->
<!ELEMENT gpa ANY>
<!ATTLIST gpa
xlink:type (resource) #FIXED "resource"
xlink:role CDATA #FIXED "http://www.example.com/linkprops/gpa"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT go EMPTY>
<!ATTLIST go
xlink:type (arc) #FIXED "arc"
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED>

<courseload>
<tooltip>Course Load for Pat Jones</tooltip>
<person
xlink:href="students/patjones62.xml"
xlink:label="student62"
xlink:role="http://www.example.com/linkprops/student"
xlink:title="Pat Jones" />
<person
xlink:href="profs/jaysmith7.xml"
xlink:label="prof7"
xlink:role="http://www.example.com/linkprops/professor"
xlink:title="Dr. Jay Smith" />
<!-- more remote resources for professors, teaching assistants, etc. -->
<course
xlink:href="courses/cs101.xml"
xlink:label="CS-101"
xlink:title="Computer Science 101" />
<!-- more remote resources for courses, seminars, etc. -->
<gpa xlink:label="PatJonesGPA">3.5</gpa>
<go
xlink:from="student62"
xlink:to="PatJonesGPA"
xlink:show="new"
xlink:actuate="onRequest"
xlink:title="Pat Jones's GPA" />
<go
xlink:from="CS-101"
xlink:arcrole="http://www.example.com/linkprops/auditor"
xlink:to="student62"
xlink:show="replace"
xlink:actuate="onRequest"
xlink:title="Pat Jones, auditing the course" />
<go
xlink:from="student62"
xlink:arcrole="http://www.example.com/linkprops/advisor"
xlink:to="prof7"
xlink:show="replace"
xlink:actuate="onRequest"
xlink:title="Dr. Jay Smith, advisor" />
</courseload>

<!ELEMENT gpa ANY>
<!ATTLIST gpa
xlink:type (resource) #FIXED "resource"
xlink:role CDATA #FIXED "http://www.example.com/linkprops/gpa"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>

 <gpa xlink:label="PatJonesGPA">3.5</gpa>

<!ELEMENT person EMPTY>
<!ATTLIST person
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT course EMPTY>
<!ATTLIST course
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #FIXED "http://www.example.com/linkprops/course"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>

<person
xlink:href="students/patjones62.xml"
xlink:label="student62"
xlink:role="http://www.example.com/linkprops/student"
xlink:title="Pat Jones" />
<person
xlink:href="profs/jaysmith7.xml"
xlink:label="prof7"
xlink:role="http://www.example.com/linkprops/professor"
xlink:title="Dr. Jay Smith" />
<course
xlink:href="courses/cs101.xml"
xlink:label="CS-101"
xlink:title="Computer Science 101" />

5.1.3 Traversal Rules for an Extended Link (arc-Type Element)

An extended link may indicate rules for traversing among its participating resources by means of a series of optional arc elements.

The XLink element for arcs is any element with an attribute in the XLink namespace called type with a value of "arc".

The arc-type element may have any content. Other than title-type elements that are direct children (see 5.1.4 Titles for Extended Links, Locators, and Arcs (title-Type Element)), whatever content is present has no XLink-specified relationship to the link. If an arc-type element has anything other than an extended-type element for its parent, the arc-type element has no XLink-specified meaning.

The arc-type element may have the traversal attributes from and to (see 5.7 Traversal Attributes (label, from, and to)), the behavior attributes show and actuate (see 5.6 Behavior Attributes (show and actuate) ) and the semantic attributes arcrole and title (see 5.5 Semantic Attributes (role, arcrole, and title)).

The traversal attributes define the desired traversal between pairs of resources that participate in the same link, where the resources are identified by their label attribute values. The from attribute defines resources from which traversal may be initiated, that is, starting resources, while the to attribute defines resources that may be traversed to, that is, ending resources. The behavior attributes specify the desired behavior for XLink applications to use when traversing to the ending resource.

The semantic attributes describe the meaning of the arc's ending resource relative to its starting resource. The arcrole attribute corresponds to the [RDF] notion of a property, where the role can be interpreted as stating that "starting-resource HAS arc-role ending-resource." This contextual role can differ from the meaning of an ending resource when taken outside the context of this particular arc. For example, a resource might generically represent a "person," but in the context of a particular arc it might have the role of "mother" and in the context of a different arc it might have the role of "daughter."

When the same resource serves as a starting resource in several arcs (whether in a single link or across many links), traversal-request behavior is unconstrained by this specification, but one possibility for interactive applications is a pop-up menu that lists the relevant arc or link titles.

The following diagram shows an extended link that associates five remote resources and provides rules for traversal among them. All of the arcs specified are third-party arcs; that is, the arcs go exclusively between remote resources. The nondirectional solid lines indicate, as before, that the link is associating the five resources; the new dotted arrows indicate the traversal rules that the link provides. Notice that some resources share the same label value.

This diagram reflects directional traversal arcs created by the following settings, where both As and Cs are allowed to initiate traversal to all Bs. Because some labels appear on several resources, each arc specification potentially creates several traversal arcs at once:

<go xlink:type="arc" xlink:from="A" xlink:to="B" /> <go xlink:type="arc" xlink:from="C" xlink:to="B" />

As another example, assume an extended link that contains five locators, two with label values of "parent" and three with label values of "child":

<extendedlink xlink:type="extended"> <loc xlink:type="locator" xlink:href="..." xlink:label="parent" xlink:title="p1" /> <loc xlink:type="locator" xlink:href="..." xlink:label="parent" xlink:title="p2" /> <loc xlink:type="locator" xlink:href="..." xlink:label="child" xlink:title="c1" /> <loc xlink:type="locator" xlink:href="..." xlink:label="child" xlink:title="c2" /> <loc xlink:type="locator" xlink:href="..." xlink:label="child" xlink:title="c3" /> ... <!-- arc-type elements would go here --> </extendedlink>

The following specifies traversal from parent resources to child resources, which includes all of p1-c1, p1-c2, p1-c3, p2-c1, p2-c2, and p2-c3:

<go xlink:type="arc" xlink:from="parent" xlink:to="child" />

If no value is supplied for a from or to attribute, the missing value is interpreted as standing for all the labels supplied on locator-type elements in that extended-type element. For example, the following specifies traversal from parents to children and also from children to children, which includes all of p1-c1, p1-c2, p1-c3, p2-c1, p2-c2, p2-c3, c1-c1, c1-c2, c1-c3, c2-c1, c2-c2, c2-c3, c3-c1, c3-c2, and c3-c3:

<go xlink:type="arc" xlink:to="child" />

In this case, note that the traversal rules include arcs from some resources to other resources with the same label (from children to other children), as well as from some resources to themselves (from a child to itself); this is not an error.

If no arc-type elements are provided in an extended link, then by extension the missing from and to values are interpreted as standing for all the labels in that link. This would be equivalent to the following traversal specification:

<go xlink:type="arc" />

When more than one locator has the same label, the set of locators with the same label are to be understood as individual locators, rather than as referring to an aggregate resource; the traversal behavior of such a link might be the same as for a link where all the locators have different roles and the appropriate arcs are specified to produce the identical traversal pairs.

If the arc traversal rules for an extended link leave out any possible traversal pairs, XLink defines no traversal for these pairs. A higher-level application may perform non-XLink-directed traversals; for example, a link-checking process might traverse all available pairs of resources.

Constraint: No Arc Duplication

Each arc-type element must have a pair of from and to values that does not repeat the from and to values (respectively) for any other arc-type element in the same extended link; that is, each pair in a link must be unique.

Example: Sample arc-Type Element Declarations and Instance

Following is a non-normative set of declarations for an arc-type element.

<!ELEMENT go EMPTY> <!ATTLIST go xlink:type (arc) #FIXED "arc" xlink:arcrole CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show (new |replace |embed |other |none) #IMPLIED xlink:actuate (onLoad |onRequest |other |none) #IMPLIED xlink:from NMTOKEN #IMPLIED xlink:to NMTOKEN #IMPLIED>

Following is how XML elements using these declarations might look.

<go xlink:from="student62" xlink:to="PatJonesGPA" xlink:show="new" xlink:actuate="onRequest" xlink:title="Pat Jones's GPA" /> <go xlink:from="CS-101" xlink:arcrole="http://www.example.com/linkprops/auditor" xlink:to="student62" xlink:show="replace" xlink:actuate="onRequest" xlink:title="Pat Jones, auditing the course" /> <go xlink:from="student62" xlink:arcrole="http://www.example.com/linkprops/advisor" xlink:to="prof7" xlink:show="replace" xlink:actuate="onRequest" xlink:title="Dr. Jay Smith, advisor" />

<!ELEMENT advisorname (name)>
<!ATTLIST advisorname
xlink:type (title) #FIXED "title"
xml:lang CDATA #IMPLIED>
<!ELEMENT name (honorific?, given, family)>
<!-- Further subelement declarations for names -->

<advisor xlink:href="profs/jaysmith7.xml" ...>
<advisorname xml:lang="en">
<name>
<honorific>Dr.</honorific>
<given>Jay</given>
<family>Smith</family>
</name>
</advisorname>
</advisor>

http://www.w3.org/1999/xlink/properties/linkbase

<!ELEMENT basesloaded ((startrsrc|linkbase|load)*)>
<!ATTLIST basesloaded
xlink:type (extended) #FIXED "extended">
<!ELEMENT startrsrc EMPTY>
<!ATTLIST startrsrc
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT linkbase EMPTY>
<!ATTLIST linkbase
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT load EMPTY>
<!ATTLIST load
xlink:type (arc) #FIXED "arc"
xlink:arcrole CDATA #FIXED "http://www.w3.org/1999/xlink/properties/linkbase"
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED>

<basesloaded>
<startrsrc xlink:label="spec" xlink:href="spec.xml" />
<linkbase xlink:label="linkbase" xlink:href="linkbase.xml" />
<load xlink:from="spec" xlink:to="linkbase" actuate="onLoad" />
</basesloaded>

<basesloaded>
<startrsrc
xlink:label="spec"
xlink:href="spec.xml#string-range(//*,'Click here to reveal annotations.')" />
<linkbase xlink:label="linkbase" xlink:href="linkbase.xml" />
<load xlink:from="spec" xlink:to="linkbase" actuate="onRequest" />
</basesloaded>

5.2 Simple Links (simple-Type Element)

[Definition: 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.

<studentlink xlink:type="extended">
<resource
xlink:type="resource"
xlink:label="local">Pat Jones</resource>
<locator
xlink:type="locator"
xlink:href="..."
xlink:label="remote"
xlink:role="..."
xlink:title="..." />
<go
xlink:type="arc"
xlink:from="local"
xlink:to="remote"
xlink:arcrole="..."
xlink:show="..."
xlink:actuate="..." />
</studentlink>

A simple link combines all the features above (except for the types and labels) into a single element. In cases where only this subset of features is required, the XLink simple linking element is available as an alternative to the extended linking element. The features missing from simple links are as follows:

• Supplying arbitrary numbers of local and remote resources

• Specifying an arc from its remote resource to its local resource

• Associating a title with the single hardwired arc

• Associating a role or title with the local resource

• Associating a role or title with the link as a whole

The XLink element for simple links is any element with an attribute in the XLink namespace called type with a value of "simple". The simple equivalent of the above extended link would be as follows:

<studentlink xlink:href="...">Pat Jones</studentlink>

The simple-type element may have any content. The simple-type element itself, together with all of its content, is the local resource of the link, as if the element were a resource-type element. If a simple-type element contains nested XLink elements, such contained elements have no XLink-specified relationship to the parent link. It is possible for a simple-type element to have no content; in cases where the link is expected to be traversed on request, interactive XLink applications will typically generate some content in order to give the user a way to initiate the traversal.

The simple-type element effectively takes the locator attribute href and the semantic attributes role and title from the locator-type element, and the behavior attributes show and actuate and the single semantic attribute arcrole from the arc-type element.

It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes.

<!ELEMENT studentlink ANY>
<!ATTLIST studentlink
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #IMPLIED
xlink:role NMTOKEN #FIXED "http://www.example.com/linkprops/student"
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED>

..., and <studentlink xlink:href="students/patjones62.xml">Pat
Jones</studentlink> is popular around the student union.

5.3 XLink Element Type Attribute (type)

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.

<!ATTLIST xlink:simple
xlink:type (simple) #FIXED "simple"
...>

<!ATTLIST commandname
xlink:type (simple|none) #REQUIRED
xlink:href CDATA #IMPLIED>

5.4 Locator Attribute (href)

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 must be a URI reference as defined in [IETF RFC 2396], or must result in a URI reference after the escaping procedure described below is applied. The procedure is applied when passing the URI reference to a URI resolver.

Some characters are disallowed in URI references, even if they are allowed in XML; the disallowed characters include all non-ASCII characters, plus the excluded characters listed in Section 2.4 of [IETF RFC 2396], except for the number sign (#) and percent sign (%) and the square bracket characters re-allowed in [IETF RFC 2732]. Disallowed characters must be escaped as follows:

1. Each disallowed character is converted to UTF-8 [IETF RFC 2279] as one or more bytes.

2. Any bytes corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the byte value).

3. The original character is replaced by the resulting character sequence.

Because it is impractical for any application to check that a value is a URI reference, this specification follows the lead of [IETF RFC 2396] in this matter and imposes no such conformance testing requirement on XLink applications.

If the URI reference is relative, its absolute version must be computed by the method of [XML Base] before use.

For locators into XML resources, the format of the fragment identifier (if any) used within the URI reference is specified by the XPointer specification [XPTR].

<!ATTLIST simplelink
xlink:href CDATA #REQUIRED
...>

5.5 Semantic Attributes (role, arcrole, and title)

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 must be a URI reference as defined in [IETF RFC 2396], except that if the URI scheme used is allowed to have absolute and relative forms, the URI portion must be absolute. The URI reference identifies some resource that describes the intended property. When no value is supplied, no particular role value is to be inferred. Disallowed URI reference characters in these attribute values must be specially encoded as described in 5.4 Locator Attribute (href).

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 5.1.4 Titles for Extended Links, Locators, and Arcs (title-Type Element).) 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.

<!ATTLIST simplelink
...
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
...>

<!ATTLIST go
...
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
...>

5.6 Behavior Attributes (show and actuate)

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. When they are used, conforming XLink applications should give them the treatment specified in this section. There is no hard requirement ("must") for this treatment because what makes sense for an interactive application, such as a browser, is unlikely to make sense for a noninteractive application, such as a robot. However, all applications should take into account the full implications of ignoring the specified behavior before choosing a different course.

<!ATTLIST simplelink
xlink:type (simple) #FIXED "simple"
...
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
...>

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.

5.7 Traversal Attributes (label, from, and to)

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.