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.
All of its participating resources
may be remote, in which case the
link is out of line, or some of the
link's own content can serve optionally as local
resources, in which case 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.
Notice that the lines that associate the resources do not have directionality.
Without traversal rules being provided, the five 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's content). This could represent the same sort of course-load
example as described above, with the addition of the student's grade point
average stored as a local resource.
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
If an extended-type element directly or indirectly
contains nested simple- or extended-type elements,
or indirectly contains locator-, arc-,
or resource-type elements, such contained elements have no XLink-specified
relationship to the parent link.
Constraint: Locators in Extended Link Elements
The content of an extended-type element must contain at least
one locator-type element.
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.
A sample set of declarations for an extended-type element
might look as follows:
<!-- courseload = extended-type
tooltip = title-type
go = arc-type
student, course, audit, advisor = locator-type
gpa = resource-type
-->
<!-- Content model ensures at least one locator -->
<!ELEMENT courseload
(tooltip*, go*, (student|course|audit|advisor),
(go|student|course|audit|advisor)*, 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" />
<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
If an extended link contains one or more local resources, then by definition
the link is inline.
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.
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.
A sample set of declarations for a resource-type element might
look as follows:
<!-- 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 the remote resources that participate in it
by means of a series of one or more 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; whatever content
is present has no XLink-specified relationship to the link. If a locator-type
element directly or indirectly 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
A locator attribute value must be provided for a locator-type
element.
A sample set of declarations for a locator-type element might
look as follows:
<!-- 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 Titles for an Extended Link and its Locators
Both extended- and locator-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 directly or indirectly 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-
or locator-type element for a parent, the title-type
element has no XLink-specified meaning.
A sample set of declarations for a title-type element might
look as follows:
<!-- 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 (when used within a locator-type element):
<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.4 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; whatever content
is present has no XLink-specified relationship to the link. If an arc-type
element directly or indirectly contains nested XLink elements, such contained
elements have no XLink-specified relationship to the parent 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 value of some role attribute on a locator-type
element that appears directly 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 initiatve 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, the traversal rules include arcs from some resources to themselves.
Even if traversal rules are not explicitly provided for this situation, an
arc from a resource to itself is always implicitly defined.
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
identical from and to values.
A sample set of declarations for an arc-type element might
look as follows:
<!-- 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
>
|
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.5 External Linksets for Resources Participating in Extended Links
In order for an XLink application to initiate traversal from a starting
resource that is remote (that is, specified by a locator-type
element), the application needs to be informed of the link's existence; otherwise
the resource would just appear to be ordinary content that needs no link-related
treatment. If the extended link is stored in the same XML document as the
one containing the starting resource, the application has an easy way to find
relevant links. Howeiver, if the extended link is stored separately from the
starting resource, the application must be directed to find the link information
somehow.
For example, if you have an out-of-line extended link that associates words
in text (one remote resource) with their definitions (another remote resource),
in order for the document containing the words in text to offer traversal
to the definitions (for example, by allowing users to click on them to bring
up the definition), the system must somehow be able to locate and use the
extended links that contain the association.
[Definition: ] Out-of-line links are commonly
collected together into linkbases, XML documents whose primary
purpose is to contain XLink extended link elements. Ideally, in
order for a remote resource (the document containing the words in text, in
our example) 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 for any resource. 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 and other XML documents whose extended link locators
point into it, so that starting resources within the current document may
be found.
[Definition: ] A description of linkbases
relevant to a particular resource is called an external linkset.
XLink in-band 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/namespace/"
xlink:role="xlink:external-linkset">
<xlink:loc ... />
</extendedlink>
|
Constraint: External Linksets Must Be XML
Any resource identified as 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.
A sample set of declarations for an external linkset might look as follows:
<!-- 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 (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 #REQUIRED
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; all its content
together is the local resource of the link, as if the content were inside
a resource-type element. If a simple-type element
directly or indirectly 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 the attributes of the 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.
Constraint: Attributes on Simple Link Element
A locator attribute value must be provided for a simple-type
element.
A sample set of declarations for a simple-type element might
look as follows:
<!-- studentlink = simple-type -->
<!ELEMENT studentlink ANY>
<!ATTLIST studentlink
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #REQUIRED
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.
...
|
3.3 Type Attribute
The attribute that identifies XLink element types is type.
The value of the type attribute can be inferred by applications,
rather than be present directly in an XML document. This allows XLink-using
languages to define element types that act as XLink linking elements in some
circumstances (for example, only when some non-XLink attribute on the same
element has a specific value filled in) and as non-XLink-related elements
in others.
Constraint: type Value
The value of the type attribute, if supplied, must be one
of "simple", "extended", "locator", "arc", "resource", "title",
or "none".
When the value of the type attribute is none,
the element is not an XLink element; any XLink-related attributes or content
has no XLink-specified relationship to the element.
A sample attribute-list declaration for type on an element
intended to be simple-type might look as follows:
<!ATTLIST xlink:simple
xlink:type (simple) #FIXED "simple"
...
>
|
For an element that serves as an XLink element only on some occasions,
one declaration might be as follows, where the value is inferred to be simple
in some circumstances and none in others:
<!ATTLIST commandname
xlink:type (simple|none) #IMPLIED
xlink:href CDATA #IMPLIED
>
|
Whenever it is desired to make commandname a simple link,
the application could use the presence of a value on the href
attribute to infer that the value of type is simple.
In all other circumstances, the value could be inferred to be none.
It would also be possible (if not advisable) to declare an element so broadly
that it could serve as any kind of XLink element, depending on its contents
and attribute settings. For example:
<!ATTLIST arbitraryElement
xlink:type (simple
|extended
|locator
|arc
|resource
|title
|none) #IMPLIED
...
>
|
