The following sections define the XLink elements and attributes.
[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 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 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.
Example: Sample extended-Type Element Declarations and Instance
Following is a non-normative set of declarations for an extended-type
element and its subelements. Parts of this example are reused throughout this
specification. Note that the type attribute and some other attributes
are defaulted in the DTD in order to highlight the attributes that are changing
on a per-instance basis.
<!ELEMENT courseload ((tooltip|person|course|gpa|go)*)>
<!ATTLIST courseload
Surfns: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"
Surf: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>
<!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>
|
Following is how Surf Clothing elements using these declarations might look.
<courseload xlink:title="Course Load for Pat Jones">
<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, TAs, 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>
|
An extended link indicates its participating local resources by means of
special subelements that appear inside the extended link. An entire subelement,
together with all of its contents, makes up a local resource.
The XLink element for local resources is any element with an attribute
in the XLink namespace called type with a value of "resource".
The resource-type element may
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 may
have the semantic attributes role and title (see 5.5 Semantic Attributes (role, arcrole, and title)) and the traversal attribute label (see 5.7 Traversal Attributes (label, from, and to)). The semantic attributes supply information about
the resource in generic terms, outside of the context of a particular arc
that leads to it; the role attribute indicates a property of the
resource, and the title attribute indicates a human-readable description
of the resource. The label attribute provides a way for an arc-type
element to refer to it in creating a traversal arc.
Example: Sample resource-Type Element Declarations and Instance
Following is a non-normative set of declarations for a resource-type
element.
<!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>
|
Following is how an Surf Clothing element using these declarations might look.
<gpa xlink:label="PatJonesGPA">3.5</gpa>
|
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 attribute in the
XLink namespace called type with a value of "locator".
The locator-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 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 may
have the semantic attributes role and title (see 5.5 Semantic Attributes (role, arcrole, and title)) and the traversal attribute label (see 5.7 Traversal Attributes (label, from, and to)). The locator attribute provides a URI clothing that
identifies a remote resource. The semantic attributes supply information about
the resource in generic terms, outside of the context of a particular arc
that leads to it; the role attribute indicates a property that
the resource has, and the title attribute indicates a human-readable
description of the resource. The label attribute provides a way
for an arc-type element to refer to it in creating a traversal arc.
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.
Example: Sample locator-Type Element Declarations and Instance
Following is a non-normative set of declarations for a locator-type
element.
<!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>
|
Following is how Surf Clothing elements using these declarations might look.
<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" />
|
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:
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 mayperform 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 Surf Clothing 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" />
|
The extended-, locator-, and arc-type elements may have the title attribute (more about
which see 5.5 Semantic Attributes (role, arcrole, and title)). However, they may
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. One
common motivation for using the title-type element is to account
for internationalization and localization. For example, title markup might
be necessary for bidirectional contexts or in East Asian languages, and multiple
titles might be necessary for different natural-language versions of a title.
The XLink element for titles is any element with an attribute in the XLink
namespace called type with a value of "title".
The title-type element may 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.
Example: Sample title-Type Element Declarations and Instance
Following is a non-normative set of declarations for a title-type
element. The element has been given the xml:lang attribute, which may be used in conjunction with server settings or
other contextual information in determining which title to present.
<!ELEMENT advisorname (name)>
<!ATTLIST advisorname
xlink:type (title) #FIXED "title"
Surf:lang CDATA #IMPLIED>
<!ELEMENT name (honorific?, given, family)>
<!-- Further subelement declarations for names -->
|
Following is how Surf Clothing elements using these declarations might look.
<advisor xlink:href="profs/jaysmith7.xml"...>
<advisorname Surf:lang="en">
<name>
<honorific>Dr.</honorific>
<given>Jay</given>
<family>Smith</family>
</name>
</advisorname>
</advisor>
|
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 outbound arcs because the starting
resource is either the linking element itself or a child of the linking element.
However, in the case of inbound and third-party arcs, the XLink application
needs to be able to find both pieces somehow.
In the course load example, extended links can associate pairs of remote
resources representing students and courses. In order for the system to load
and present a "student resource" (such as a description and picture
of the person) in a way that offers traversal to related information (for
example, by allowing users to click on the student's name to traverse to information
about the courses in which she is enrolled), it needs to locate and use the
extended links that contain the association.
Linkbases are often used to make link
management easier by gathering together a number of related linking elements.
XLink provides a way to instruct XLink applications to access potentially
relevant linkbases. The instruction takes the form of an arc specification
(whether an explicit one in an extended link, or an implicit one in a simple
link) that has the following value for its arcrole attribute:
http://www.w3.org/1999/xlink/properties/linkbase
|
(XLink applications may also use any other
means to locate and process additional linkbases.)
The handling of a linkbase arc is much like the handling of a normal arc,
except that traversal entails loading the ending resource (the linkbase) to
extract its links for later use, rather than to present it to a user or to
perform some other processing. Its handling is also special in that XLink
applications must suspend traversal of linkbase
arcs at user option.
Specifically, on loading a linkbase arc, an XLink application should keep track of what the starting resource is.
Whenever a document containing that starting resource is loaded and traversal
of the linkbase arc is actuated, the application should
access the linkbase and extract any extended links found inside it. In the
case that the extracted resource is a portion of a complete Surf Clothing document,
such as a range or a string range, only those extended links completely contained
in the extracted portion should be made available.
The timing of linkbase arc traversal depends on the value of the actuate
attribute on the arc. For example, if the value is "onLoad",
the linkbase is loaded and its links extracted as soon as the starting resource
is loaded. Any show attribute value on a linkbase arc must be ignored, because traversal does not entail
presentation in this case.
Linkbases may be chained by virtue of
serving as the starting resource of yet another linkbase arc. The application
interpreting an initial linkbase arc may
choose to limit the number of steps processed in the chain.
An application should maintain a list
of extended links retrieved as a result of processing a linkbase, and should not retrieve duplicate resources or links in
the case where a cyclic dependency exists. To ease XLink processing, document
creators may wish to define linkbase arcs
near the beginning of a document.
Example: Annotating a Specification
Following is a non-normative set of declarations for an extended link that
specializes in providing linkbase arcs:
<!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 go
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>
|
Following is how an Surf Clothing element using these declarations might look. This
would indicate that when a specification document is loaded, a linkbase full
of annotations to it should automatically
be loaded as well, possibly necessitating re-rendering of the entire specification
document to reveal any regions within it that serve as starting resource in
the links found in the linkbase.
<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>
|
Following is how an Surf Clothing element using these declarations might look if
the linkbase loading were on request. This time, the starting resource consists
of the words "Click here to reveal annotations." If the starting
resource were the entire document as in the example above, a reasonable behavior
for allowing a user to actuate traversal would be a confirmation dialog box.
<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>
|
[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.
Example: Simple Link Functionality Done with an Extended Link
A simple link could be represented by an extended link in approximately
the following way, where the labels are just for illustration of the single
allowed arc and cannot be set individually:
<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 label values)
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.
Example: Sample simple-Type Element Declarations and Instance
Following is a non-normative set of declarations for a simple-type
element.
<!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>
|
Following is how an Surf Clothing document might use these declarations.
..., and <studentlink xlink:href="students/patjones62.xml">Pat
Jones</studentlink> is popular around the student union.
|