XLink offers two kinds of links.
The following sections define the XLink elements and attributes. Where
an attribute or a group of related attributes can appear on multiple element
types, it is described in its own section.
3.1 Extended Links
[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. If all the resources
are remote, the link is out of line.
If any of the resources are local, then the link is inline.
The only kind of XLink that can be out of line is an extended link. Typically,
extended linking elements are stored separately from the resources they associate
(for example, in an entirely different document). Thus, the out-of-line characteristic
is useful 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 most multimedia formats).
The following diagram shows an out-of-line 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 have nothing to do with
each other; 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.
Without traversal 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 inline 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 XLink-namespace
attribute called type with a value of "extended".
The extended-type element contains 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 contain
fewer than two locator- and/or resource-type elements.
If the link has only one participating resource, or none at all, it is simply
untraversable.
Subelements of the simple or extended type anywhere
inside a parent extended-type element have no XLink-specified
relationship to the parent link. Subelements of the locator, arc,
or resource type that are not direct children of an extended-type
element have no XLink-specified relationship to the parent link.
The extended-type element can have the semantic attributes
(see Semantic Attributes (role and title)). If present, they supply semantic information
about the link as a whole. 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 in this case.
If the extended-type element directly contains one or more resource-type
elements, the link is inline. If it does not, the link is out of line.
Following is a sample (non-normative) set of declarations for an extended-type
element.
Note:
In this example, and in most of the examples of declarations in this specification,
the role values have been defaulted in the DTD to be the same as the element
names. This is done only to simplify presentation of the example. There is
no constraint that this must be the case; the element name might differ from
the role value, for example, when the name needs to be translated to a different
language, or when the most convenient machine-readable role value is not suitable
for use by human authors.
<!-- courseload = extended-type
tooltip = title-type
go = arc-type
student, course, audit, advisor = locator-type
gpa = resource-type
-->
<!ELEMENT courseload
(tooltip*, (student|course|audit|advisor|go*), gpa)>
<!ATTLIST courseload
xlink:type (extended) #FIXED "extended"
xlink:role NMTOKEN #FIXED "courseload"
xlink:title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<courseload
xlink:title="Course Load for Pat Jones">
<go xlink:from="gpa" xlink:to="course" />
<go xlink:from="student" xlink:to="course" />
<go xlink:from="student" xlink:to="audit" />
<go xlink:from="student" xlink:to="advisor" />
<student xlink:href="..." />
<course xlink:href="..." />
<course xlink:href="..." />
<audit xlink:href="..." />
<advisor xlink:href="..." />
<gpa>3.5</gpa>
</courseload>
|
3.1.1 Local Resources for an Extended Link
An extended link indicates local resources that participate in it by means
of special subelements that appear inside the extended link. If an extended
link contains one or more local resources, then by definition the link is
inline. An element is used to supply such a local resource; the entire element,
together with all of its contents, makes up the resource.
The XLink element for local resources is any element with an XLink-namespace
attribute called type with a value of "resource".
The resource-type element can have any content; whatever content
is present has no XLink-specified relationship to the link. It is possible
for a resource-type element to have no content; in cases where
it serves as a starting resource 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 resource-type element has the semantic attributes (see Semantic Attributes (role and title)). The semantic attributes describe the meaning of that
resource in the context of the link.
Following is a sample (non-normative) set of declarations for a resource-type
element:
<!-- gpa = resource-type -->
<!ELEMENT gpa ANY>
<!ATTLIST gpa
xlink:type (resource) #FIXED "resource"
xlink:role NMTOKEN #FIXED "gpa"
xlink:title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
3.1.2 Remote Resources for an Extended Link
An extended link indicates remote resources that participate in it by means
of locator elements.
The XLink element for locators is any element with an XLink-namespace attribute
called type with a value of "locator".
The locator-type element can have any content; other than title-type
elements that are direct children (see Titles for Extended Links, Locators, and Arcs), whatever
content is present has no XLink-specified relationship to the link. If a locator-type
element contains nested XLink elements, such contained elements have no XLink-specified
relationship to the parent link. If a locator-type element has
anything other than an extended-type element for a parent, the locator-type
element has no XLink-specified meaning.
The locator-type element has the locator attribute (see Locator Attribute (href)) and the semantic attributes (see Semantic Attributes (role and title)).
The locator attribute provides a URI-reference that identifies a remote resource
(or sub-resource), and the semantic attributes describe the meaning of that
resource in the context of the link.
Constraint: Attributes on Locator Element
On a locator-type element, the locator attribute (href)
must have a value supplied.
Note:
A locator-type element, by itself, does not constitute a link
just because it has a locator (href) attribute; unlike a simple-type
element, it does not create an XLink-governed association between itself and
the referenced resource.
Following is a sample (non-normative) set of declarations for a locator-type
element:
<!-- student, course, audit, advisor = locator-type -->
<!ELEMENT student EMPTY>
<!ATTLIST student
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role NMTOKEN #FIXED "student"
xlink:title CDATA #IMPLIED
>
<!ELEMENT course EMPTY>
<!ATTLIST course
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role NMTOKEN #FIXED "course"
xlink:title CDATA #IMPLIED
>
<!ELEMENT audit EMPTY>
<!ATTLIST audit
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role NMTOKEN #FIXED "audit"
xlink:title CDATA #IMPLIED
>
<!ELEMENT advisor EMPTY>
<!ATTLIST advisor
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role NMTOKEN #FIXED "advisor"
xlink:title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<student
xlink:href="/students/patjones.xml"
xlink:title="Pat Jones" />
<course
xlink:href="/courses/cs101.xml"
xlink:title="CompSci 101" />
<advisor
xlink:href="/profs/jaysmith.xml"
xlink:title="Dr. Jay Smith" />
|
3.1.3 Traversal Rules for an Extended Link
An extended link can indicate normative 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 XLink-namespace attribute
called type with a value of "arc".
The arc-type element can have any content; other than title-type
elements that are direct children (see Titles for Extended Links, Locators, and Arcs), 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
a parent, the arc-type element has no XLink-specified meaning.
The arc-type element has the traversal attributes (from
and to), the behavior attributes (see Behavior Attributes (show and actuate) ),
and the semantic attributes (see Semantic Attributes (role and title)).
The traversal attributes define the traversal semantics between pairs of
resources, where the resources are identified by role value: The from
attribute defines resources from which traversal can be initiated, that is, starting resources, while the to
attribute defines resources that can 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 resource being traversed
to in the context of that arc. This may differ from the meaning of a resource
when taken outside the context of the arc. For example, five resources may
each represent a "person," but in the context of a particular
arc direction, the target resource may be a "mother," and in
the opposite direction, the target resource may be a "daughter."
When a single starting resource leads to several ending resources, traversal-request
behavior is unconstrained by this specification, but one possibility for interactive
applications could be a pop-up menu that displays the relevant arc or locator
titles.
Constraint: from and to Values
If a value is supplied for a from or to attribute,
it must correspond to the same namespace URI (if any) and local part of some role
attribute on a locator- or resource-type element
that appears as a direct child inside the same extended-type
element as does the arc-type element.
The following diagram shows an out-of-line extended link that associates
five remote resources and provides rules for traversal among them:
The diagram shows directional traversal arcs reflecting the following settings,
where both As and Cs are allowed to initiate traversal to all Bs:
<!-- go = arc-type -->
<go xlink:from="A" xlink:to="B" />
<go xlink:from="C" xlink:to="B" />
|
As another example, assume an extended link that contains five locators,
two with role values of "parent" and three with
role values of "child" (titles are provided for convenience of
reference):
<!-- extendedlink = extended-type
loc = locator-type
-->
<extendedlink>
<loc xlink:href="..." xlink:role="parent" xlink:title="p1" />
<loc xlink:href="..." xlink:role="parent" xlink:title="p2" />
<loc xlink:href="..." xlink:role="child" xlink:title="c1" />
<loc xlink:href="..." xlink:role="child" xlink:title="c2" />
<loc xlink:href="..." xlink:role="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 = arc-type -->
<go 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 roles 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 = arc-type -->
<go xlink:to="child" />
|
In this case, note that the traversal rules include arcs from some resources
to other resources with the same role (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 roles in that link. This would be
equivalent to the following traversal specification:
<!-- go = arc-type -->
<go />
|
In the parent-child example, more than one locator has the same role. In
such cases, the set of locators with the same role 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, these pairs must not be traversed.
Constraint: No Arc Duplication
In any one extended link, no two arc-type elements may have from
and to values that have identical namespace URIs (if any) and
local parts.
Following is a sample (non-normative) set of declarations for an arc-type
element:
<!-- go = arc-type -->
<!ELEMENT go ANY>
<!ATTLIST go
xlink:type (arc) #FIXED "arc"
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED
xlink:show (new
|replace
|embed
|undefined) #IMPLIED
xlink:actuate (onLoad
|onRequest
|undefined) #IMPLIED
xlink:role NMTOKEN #IMPLIED
xlink:title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<go
xlink:from="student"
xlink:to="advisor"
xlink:show="new"
xlink:actuate="onRequest" />
|
3.1.4 Titles for Extended Links, Locators, and Arcs
The extended-, locator-, and arc-type
elements can have the title attribute (more about which see Semantic Attributes (role and title)). However, they can also have a series of one or more title-type
elements. Such elements are useful, for example, for cases where human-readable
label information needs further element markup, or where multiple titles are
necessary for internationalization purposes.
The XLink element for titles is any element with an XLink-namespace attribute
called type with a value of "title".
The title-type element can have any content. If a title-type
element contains nested XLink elements, such contained elements have no XLink-specified
relationship to the parent link containing the title. If a title-type
element has anything other than an extended-, locator-,
or arc-type element for a parent, the title-type
element has no XLink-specified meaning.
Following is a sample (non-normative) set of declarations for a title-type
element:
<!-- advisorname = title-type -->
<!ELEMENT advisorname (name)>
<!ATTLIST advisorname
xlink:type (title) #FIXED "title"
xml:lang CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<!-- advisor = locator-type
advisorname = title-type
-->
<advisor xlink:href="profs/jaysmith.xml">
<advisorname xml:lang="en">
<name>
<honorific>Dr.</honorific>
<given>Jay</given>
<family>Smith</family>
</name>
</advisorname>
</advisor>
|
3.1.5 External Linksets for Resources Participating in Extended Links
For an XLink application to traverse from a starting resource to an ending
resource, it needs to locate both the starting resource and the link. Locating
the two pieces is not a problem in the case of simple links, because the starting
resource is the linking element itself; similarly for extended links whose
starting resource of interest is local and thus contained inside the linking
element. However, when a starting resource in an extended link is remote,
the XLink application needs to be able to find both pieces somehow.
An example is a set of extended links that associate words in text (one
remote resource) with their definitions (another remote resource). In order
for the system to load and display the document containing the special words
in a way that offers traversal to the definitions (for example, by allowing
users to click on an underlined word to pop up its definition), it needs to
locate and use the extended links that contain the association.
[Definition: ] XML documents whose purpose is
to contain extended links are called linkbases; they
are often used to make link management easier. Ideally, in order for a remote
starting resource to avoid dependencies on the location of any linkbases that
point into it, there will be an out-of-band method of informing a system how
to locate relevant linkbases. Such
methods are outside the scope of this specification. However, in cases where
an out-of-band method is not available, XLink provides an in-band way for
a resource to identify the likely locations of linkbases whose extended link
locators point into it, so that starting resources within the current document
may be found.
[Definition: ] A list of references to potentially
relevant linkbases is called an external linkset. The
presence of an XLink-encoded external linkset anywhere inside an XML document
alerts XLink applications that some of the document's content may serve as
a starting resource according to extended links found in the referenced linkbases.
XLink external linksets are encoded as extended-type elements
with a role attribute that has a special value of "prefix:external-linkset".
The element must be in the scope of a namespace declaration that associates
the chosen prefix with the XLink namespace. For example:
<!-- extendedlink = extended-type
loc = locator-type
-->
<extendedlink
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:role="xlink:external-linkset">
<loc ... />
</extendedlink>
|
Constraint: Linkbases Must Be XML
Any linkbase identified in an external linkset must be an XML document.
XLink applications should process XLink-specified external linksets as
follows (though, in some cases, users may need to suspend such processing).
XLink applications may also use any other means to locate and process additional
external linksets.
On finding an extended link with a role of prefix:external-linkset,
the XLink application should access the link's participating resources and
extract any extended links found inside them, for use in constructing traversal
paths that involve the resource in which the external linkset was found. In
the case that the extracted resource is a sub-resource of a complete XML document,
only those extended links completely contained in the extracted
portion should be made available.
The application interpreting the extended link may choose, in the case
of [Definition: ] chained
external linksets (that is, external linksets that refer to linkbases
that themselves contain further linksets), to limit the number of
steps processed in the chain.
An application should maintain a list of extended links retrieved as a
result of external linkset processing, and should not retrieve duplicate resources
or links in the case where a cyclic dependency exists between external linksets.
Following is a sample (non-normative) set of declarations for an external
linkset:
<!-- xls = extended-type
linkbase = locator-type
-->
<!ELEMENT xls (linkbase+)>
<!ATTLIST xls
xlink:type (extended) #FIXED "extended"
xlink:role NMTOKEN #FIXED "xlink:extended-linkset"
xlink:title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look; this would have the effect of including the external linksets
defined by the extended links contained in the documents linkset1.xml, linkset2.xml,
and linkset3.xml, as well as potentially including any other
external linksets referenced from these documents:
<xls>
<linkbase xlink:href="linkset1.xml" />
<linkbase xlink:href="linkset2.xml" />
<linkbase xlink:href="linkset3.xml" />
</xls>
|
3.2 Simple Links
[Definition: ] A simple link
is a link that associates exactly two resources,
one local and one remote.
Because it involves a local resource, a simple link is always inline.
The purpose of a simple link is to be a convenient shorthand for the equivalent
extended link. Because simple links have only one remote resource and hardwired
traversal rules, a single simple link element combines the basic functions
of a linking element, a locator element, and an arc 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.
Conceptually, a simple link could be represented by an extended link defined
in approximately the following way; however, note that this set of declarations
is only for illustration, and is not meant as a rigorous definition.
<!-- extendedlink = extended-type
loc = locator-type
res = resource=type
go = arc-type
-->
<!ELEMENT extendedlink (loc, go, res)>
<!ATTLIST extendedlink
xlink:type (extended) #FIXED "extended"
>
<!ELEMENT loc EMPTY>
<!ATTLIST loc
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #IMPLIED
xlink:role (remote) #FIXED "remote"
xlink:title CDATA #IMPLIED
<!ELEMENT go EMPTY>
<!ATTLIST go
xlink:from (local) #FIXED "local"
xlink:to (remote) #FIXED "remote"
xlink:show (new
|replace
|embed
|undefined) #IMPLIED
xlink:actuate (onLoad
|onRequest
|undefined) #IMPLIED
>
<!ELEMENT res ANY>
<!ATTLIST res
xlink:role (local) #FIXED "local"
>
...
<extendedlink>
<loc xlink:href="..." />
<go />
<res>click here</res>
</extendedlink>
|
Instead, the XLink simple linking element can be used, where all these
elements, their attributes, and their fixed attribute value settings are conceptually
combined into a single element. The XLink element for simple links is any
element with an XLink-namespace attribute called type with a
value of "simple". The simple equivalent of the above extended
link would be as follows:
<simplelink xlink:href="...">click here</simplelink>
|
The simple-type element can 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 combines attributes from other XLink
elements in the following way: It takes the locator attribute (see Locator Attribute (href)) and the semantic attributes (see Semantic Attributes (role and title))
from the locator-type element, and the behavior attributes (see Behavior Attributes (show and actuate) ) from the arc-type element. Thus, the
semantic attributes describe the function of the single remote resource in
the context of the link, and the behavior attributes specify the desired behavior
for XLink applications to use when traversing from the local resource to the
remote resource. Simple links do not have the ability to specify semantic
attributes for the link itself, for the local resource, or for the single
arc.
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.
Following is a sample (non-normative) set of declarations for a simple-type
element:
<!-- studentlink = simple-type -->
<!ELEMENT studentlink ANY>
<!ATTLIST studentlink
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #IMPLIED
xlink:role NMTOKEN #FIXED "student"
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|undefined) #FIXED "replace"
xlink:actuate (onLoad
|onRequest
|undefined) #FIXED "onRequest"
>
|
The following example shows how an XML document using these declarations
might look:
...
<studentlink
xlink:href="/students/patjones.xml"
xlink:title="Info about Pat Jones">Pat</studentlink> is popular around
the student union.
...
|