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 elements,
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 entirely separately from the resources
they associate (for example, in a 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 the linking element itself, 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 is a description of the student, another
is a description of the student's academic advisor, two resources represent
courses that the student is attending, and the last resource represents 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 participating 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 extended linking element is called extended, or
alternatively is an element in an arbitrary namespace 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.
Note:
The attributes showdefault and actuatedefault
have been removed from this draft. The rationale was that creating an attribute
whose value gets inherited by the link's locators requires a level of processing
that the Working Group did not feel comfortable specifying.
A sample set of declarations for an element called extended
might look as follows:
<!-- Content model ensures at least one locator -->
<!ELEMENT xlink:extended
(xlink:title*, xlink:arc*, xlink:locator,
(xlink:arc|xlink:locator)*, xlink:resource*)>
<!ATTLIST xlink:extended
role NMTOKEN #IMPLIED
title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<xlink:extended
role="courseload"
title="Course Load for Pat Jones">
<xlink:locator ... />
<xlink:locator ... />
<xlink:arc ... />
</xlink:extended>
|
A sample set of declarations for an element that uses the type
attribute might look as follows:
<!-- 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">
<student ... />
<course ... />
<course ... />
<audit ... />
<advisor ... />
<gpa>...</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 local resource element is called resource, or alternatively
is an element in an arbitrary namespace 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 an element called resource
might look as follows:
<!ELEMENT xlink:resource ANY>
<!ATTLIST xlink:resource
role NMTOKEN #IMPLIED
title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<xlink:resource>
...
</xlink:resource>
|
A sample set of declarations for an element that uses the type
attribute might look as follows:
<!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 locator elements.
The XLink locator element is called locator, or alternatively
is an element in an arbitrary namespace 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 an element called locator
might look as follows:
<!ELEMENT xlink:locator ANY>
<!ATTLIST xlink:locator
href CDATA #REQUIRED
role NMTOKEN #IMPLIED
title CDATA #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<xlink:locator
href="/students/sophomores/patjones.xml"
role="student"
title="Pat Jones" />
<xlink:locator
href="/courses/cs101.xml"
role="course"
title="CompSci 101" />
<xlink:locator
href="/profs/jaysmith.xml"
role="advisor"
title="Dr. Jay Smith" />
|
A sample set of declarations for a series of elements that use the type
attribute might look as follows:
<!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:role NMTOKEN #FIXED "course"
...
>
<!ELEMENT audit EMPTY>
<!ATTLIST audit
xlink:type (locator) #FIXED "locator"
xlink:role NMTOKEN #FIXED "audit"
...
>
<!ELEMENT advisor EMPTY>
<!ATTLIST advisor
xlink:type (locator) #FIXED "locator"
xlink:role NMTOKEN #FIXED "advisor"
...
>
|
The following example shows how an XML document using these declarations
might look:
<student
href="/students/patjones.xml"
title="Pat Jones" />
<course
href="/courses/cs101.xml"
title="CompSci 101" />
<advisor
href="/profs/jaysmith.xml"
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, in the case where it is useful to put human-readable label information
in an element (for example, so it can be further marked up), or where multiple
titles are necessary (for example, for internationalization purposes).
The XLink title element is called locator, or alternatively
is an element in an arbitrary namespace 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 an element called title might
look as follows:
<!ELEMENT xlink:title ANY>
<!ATTLIST xlink: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):
<xlink:locator role="advisor" href="/profs/jaysmith.xml">
<xlink:title xml:lang="en">
<name>
<honorific>Dr.</honorific>
<given>Jay</given>
<family>Smith</family>
</name>
</xlink:title>
</xlink:locator>
|
A sample set of declarations for an element that uses the type
attribute might look as follows:
<!ELEMENT advisorname EMPTY>
<!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 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 indicates the rules for traversing among its participating
resources by means of a series of optional arc elements.
The XLink arc element is called arc, or alternatively is an
element in an arbitrary namespace 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) and the behavior attributes (see Behavior Attributes (show and actuate) ).
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, while the to
attribute defines resources that can be traversed to. The behavior attributes
specify the desired behavior for XLink implementations to use when traversing
to the indicated to resource.
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:
This diagram shows directional traversal arcs reflecting the following
settings, where both As and Cs are allowed to initiatve traversal to all Bs:
<xlink:arc from="A" to="B" />
<xlink:arc from="C" 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):
<xlink:extended>
<xlink:locator href="..." role="parent" title="p1" />
<xlink:locator href="..." role="parent" title="p2" />
<xlink:locator href="..." role="child" title="c1" />
<xlink:locator href="..." role="child" title="c2" />
<xlink:locator href="..." role="child" title="c3" />
... <!-- arc elements would go here -->
</xlink:extended>
|
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:
<xlink:arc from="parent" 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:
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:
In both of the examples above, note that 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 an "aggregate resource";
the traversal behavior of such a link with is 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.
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 element called arc might
look as follows:
<!ELEMENT xlink:arc ANY>
<!ATTLIST xlink:arc
from NMTOKEN #IMPLIED
to NMTOKEN #IMPLIED
show (embed|new|replace) #IMPLIED
actuate (onLoad|onRequest) #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<xlink:arc
from="student"
to="essay"
show="embed"
actuate="onLoad" />
|
A sample set of declarations for an element that uses the type
attribute might look as follows:
<!ELEMENT go ANY>
<!ATTLIST go
xlink:type (arc) #FIXED "arc"
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED
xlink:show (embed|new|replace) #IMPLIED
xlink:actuate (onLoad|onRequest) #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" />
|
Issue (arc-semantics):
There are no role or title attributes on arc
elements because we felt that the role of any arc is the concatenation of
the two end roles, and if you're going to display title text for an end, there's
no sensible place to display the title text for an arc in addition. However,
in cases where the relationship between two elements has a role, then this
mechanism does not hold. For example, a family may have many members, and
the arc between a one person and another person could have a daughter role,
whereas the arc in the opposite direction could have a mother role. Should
we allow arc elements to have roles and titles?
3.1.5 External Linksets for Resources Participating in Extended Links
In order for an XLink implementation to initiate traversal from a remote
resource identified in an extended link, it 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. However, the extended link may be stored
in a different document from the one containing the "starting point."
For example, if you have an out-of-line extended link that associates words
in text with their definitions, in order for the document containing the word
usages to offer the ability to traverse to the definitions (for example, by
underlining the words and making them "clickable"), 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 the remote resource (the document containing the word usages, in
our example) to avoid dependencies on the location of any linkbases that point
into it, there will be an out-of-band way to inform a system how to locate
relevant linkbases for any resource. However, in cases where this is not possible,
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 "traversal initiation points" within the resource
may be found. [Definition: ] A description
of linkbases relevant to a particular resource is called an external
linkset.
An external linkset is encoded as an extended-type element
that has a role attribute with a 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:
<xlink:extended
xmlns:xlink="http://www.w3.org/1999/xlink/namespace/"
role="xlink:external-linkset">
<xlink:locator ... />
</xlink:extended>
|
Following is the expected normal behavior of an XLink implementation in
processing specifications of external linksets. It is not intended to constrain
XLink processing in XML editors or other applications where a user may need
to suspend such processing. Nor is it intended to prevent the processing of
additional external linksets under user control. For this reason, all of the
processing-related text in this section reads should.
On finding an extended link with role xxx:external-linkset,
an 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 "extraction resource" is a sub-resource of
a complete document, only those extended links completely contained
in the sub-resource should be made available. If any external linksets are
made available to an application by out-of-band means, it should perform its
typical external linkset processing on them as well.
Issue (require-xls-to-be-xml):
Is it possible, given the expectations of Web architecture, for us to make
a conformance constraint requiring that resources identified as external linksets
be of Internet media type */xml or some derivative?
The application interpreting the extended link may choose, in the case
of [Definition: ] nested
external linksets (that is, external linksets that refer to linkbases
that themselves contain further linksets), to limit the number of
steps processed down the nesting.
Issue (step-control):
From Ben: Should control over accessing nested external linksets be brought
up a level, so that the "XLink processor" (whether that's a UA or a server-side
application, or perhaps has no interaction with the end user at all) rather
than the application is the place where steps may be limited? In what sense
is the "processor" different from the "application"?
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 that uses an element
called extended might look as follows:
<!ELEMENT xlink:extended (xlink:locator+)>
<!ATTLIST xlink:extended
role NMTOKEN "xlink:extended-linkset"
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 linkset defined
by the extended links contained in the document mylinkset.xml,
as well as including any other external linksets referenced from mylinkset.xml:
<xlink:extended>
<xlink:locator href="mylinkset.xml" />
</xlink:extended>
|
A sample set of declarations for an external linkset that uses the type
attribute (the typical case for this special use of extended links) might
look as follows:
<!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:
<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 functions of a
linking element, a locator element, and an arc element together.
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 that is linked 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, not as a rigorous definition):
<!ELEMENT xlink:extended
(xlink:locator, xlink:resource, xlink:arc)>
<!ELEMENT xlink:locator EMPTY>
<!ATTLIST xlink:locator
href CDATA #REQUIRED
role (remote) #FIXED "remote"
title CDATA #IMPLIED
<!ELEMENT xlink:resource ANY>
<!ATTLIST xlink:resource
role (local) #FIXED "local"
>
<!ELEMENT xlink:arc EMPTY>
<!ATTLIST xlink:arc
from (local) #FIXED "local"
to (remote) #FIXED "remote"
show (embed|new|replace) #IMPLIED
actuate (onLoad|onRequest) #IMPLIED
>
|
Instead, the XLink simple linking element can be used, where all these
elements and their attributes are combined into a single element. The element
is called simple, or alternatively is an element in an arbitrary
namespace with an XLink-namespace attribute called type with
a value of "simple".
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," an application
will typically generate some content in order to give the user (or other agent)
a way to initiate the traversal.
The simple-type element combines the functions 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 implementations 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 an element called simple
might look as follows:
<!ELEMENT xlink:simple ANY>
<!ATTLIST xlink:simple
href CDATA #REQUIRED
role NMTOKEN #IMPLIED
title CDATA #IMPLIED
show (embed|new|replace) #IMPLIED
actuate (onLoad|onRequest) #IMPLIED
>
|
The following example shows how an XML document using these declarations
might look:
<xlink:simple
href="/students/patjones.xml"
role="student"
title="Info about Pat Jones"
show="replace"
actuate="onRequest">Pat</xlink:simple> is popular around
the student union.
|
A sample set of declarations for an element that uses the type
attribute might look as follows:
<!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 (embed|new|replace) #FIXED "replace"
xlink:actuate (onLoad|onRequest) #FIXED "onRequest"
>
|
The following example shows how an XML document using these declarations
might look:
<studentlink
href="/students/patjones.xml"
title="Info about Pat Jones">Pat</studentlink> is popular around
the student union.
|
3.3 Type Attribute
The attribute that identifies non-XLink elements that should receive XLink
treatment is type. It must be used on every element that does
not have an XLink element type (simple, extended, locator, arc, resource,
or title), but is intended to conform to the constraints imposed
by these element types.
Constraint: type Attribute vs. Element Type
The type attribute cannot be used on an XLink simple, extended, locator, arc, resource, or title element. It can be used only on non-XLink
elements.
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,
or title.
A sample attribute-list declaration for type on an XLink simple
element might look as follows:
<!ATTLIST xlink:simple
type (simple) #FIXED "simple"
>
|
For an element that serves as an XLink element only under certain circumstances,
one declaration might be as follows:
<!ATTLIST commandname
xlink:type (simple) #IMPLIED
>
|
Issue (not-an-xlink):
Would it be good practice to dictate an explicit value to use to indicate
that the element is not an XLink element, e.g., “none” or something?
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 arbitrary-element
xlink:type (simple
|extended
|locator
|arc) #IMPLIED
>
|
3.5 Semantic Attributes (role and title)
The attributes that describe the function of resources within the context
of a link are role and title. They can be used on simple-, locator,
and resource-type elements.
Constraint: role Value
If a value is supplied for a role attribute, it must be a QName (qualified
name) as defined in the Namespaces Recommendation [XNAME]. The
namespace associated with a given link's role prefix must be declared on some
element in whose scope the role value appears.
Issue (resource-media-specification):
Should XLink develop its own an extensible repertoire of role types, with
common semantics so that they can be recognized and acted upon appropriately
by a variety of user agents? HTML 4.0 LINK, for instance, suggests a simple
set of pre-defined names for PREV NEXT, TOC, etc. XLink could go beyond these
simple conventions and provide a more formal set and mechanism. We are inclined,
in general, to leave this to higher-level languages based on XLink.
The role attribute is used to describe the function of a link's
remote resource in a machine-readable fashion, and, in the case of extended-type
elements, to serve as a "resource category label" for traversal
rules in arc-type elements. The role attribute is
not required to have a value; however, if a value is absent, traversal intentions
cannot be supplied for its resource using arc-type elements.
When no role value is supplied, no particular role value is to
be inferred.
The following example shows role values and their corresponding namespace
declarations in an extended element:
<xlink:extended
xmlns:bib="http://www.somewhere.org">
<xlink:locator
role="bib:author"
href="http://www.w3.org/works.xml" />
<xlink:locator
role="bib:publisher"
href="http://www.w3.org/or.xml" />
<xlink:locator
role="n"
href="http://www.w3.org/else.xml" />
<xlink:locator
xmlns:bib2="http://www.nowhere.org"
role="bib2:docname"
href="http://www.w3.org/crash.xml" />
</xlink:extended>
|
Issue (role-ns):
Does the Namespaces specification allow our creation of roles as a new
“symbol space”? At the very least, does it not disallow it?
The title attribute is used to describe the function of a
link's remote resource in a human-readable fashion. (However, see also Titles for an Extended Link and its Locators.) It is not required, but if it is used, 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 can be used, for example,
to make titles available to applications used by visually impaired users,
or to create a table of links.
A sample attribute-list declaration for role and title
on an XLink simple element might look as follows:
<!ATTLIST simple
role NMTOKEN #IMPLIED
title CDATA #IMPLIED
>
|
3.6 Behavior Attributes (show and actuate)
The behavior attributes are show and actuate.
They can be used on the simple- and arc-type elements.
Issue (display-centric):
The behavior attributes are clearly quite display-centric, despite our
attempts to describe them as being more generic. Can we motivate them in a
less display-centric way?
Constraint: show Value
If a value is supplied for a show attribute, it must be one
of embed, new, or replace.
Constraint: actuate Value
If a value is supplied for an actuate attribute, it must be
one of onLoad or onRequest.
The show and actuate attributes are not required.
When they are used, they signal only intentions of the link creator, rather
than instructions that XLink implementations are required to act on. Further,
the behavior they describe is a simple and limited "starter set";
it is expected that applications layered on XLink will specify their own behavioral
treatments and constraints, and in particular, if a layered application depends
on XLink behavior attribute settings, it should explicitly define its processing
model for these settings.
The show attribute is used to communicate the intention of
the link's creator as to the context in which link traversal should be performed.
The interpretation of this intention is highly dependent on the type of processing
being done. The allowed attribute values signal the following intentions:
-
embed
-
The target of the link should be displayed if possible, in a fashion appropriate
to its media type, between the display of the end of the resource where traversal
was initiated and the display of the first content (if any) following the
linking element, in a fashion similar to that typically used in processing
the HTML IMG element.
Issue (embed-where):
From Steve: The instructions for where to embed a resource are not perfectly
accurate -- there may be no next content; more important, there may be element
and other boundaries in between, and this definition leaves it ambiguous on
which side of them embed happens. We should explain that the scope of the
source anchor matters: if you linked to a SEC, the embed happens at the Point
(as defined now in XPointer) immediately following the SEC; if you linked
to the range consisting of all the children of the SEC, you'd get the embed
just inside the end of the SEC after the last child (you could also get that
by XPointing [a new verb!] to that point explicitly). This would matter, for
example, if elements were generating text before or after themselves for display,
or leading/trailing vertical space, or if the user is supposed to follow the
link and then be able to edit, or.... How can this description be made unambiguous?
-
new
-
The traversal should occur without affecting the resource from which traversal
was initiated. For example, in a display environment, this could be implemented
by displaying the targeted resource in a new window; this is similar to the
effect achieved by the following HTML fragment:
<A HREF="http://www.w3.org" target="_new">...</A>
|
-
replace
-
The presentation of the resource containing the linking element should
be entirely replaced by a presentation of the one being linked to. In a display
environment, this could be implemented in a fashion similar to that typically
used in processing HTML A elements, involving a complete re-write
of the display. The replace option is the one most commonly seen
on the World Wide Web, where the presentation of the document being linked
from is entirely replaced by the presentation of the object being linked to.
Issue (what-to-replace):
From Steve: A real issue we never resolved is the distinction in embed/new/replace
semantics; we've left the intermediate case unnamed, where you want the destination
anchor to replace the source *anchor*, not the source *document*; this makes
a smooth sequence of 'what to replace': nothing (embed), the anchor (currently
unnamed), the subresource (replace), or the window (new). Some might want
to add something for panes, but that seems overkill (and hard to define consistently).
Should the intermediate case be named and defined?
The actuate attribute is used to communicate the intention
of the link's creator as to when traversal of that link should occur. The
allowed attribute values signal the following intentions:
-
onLoad
-
The link may be traversed when its existence is recognized by the XLink
implementation.
Note:
This value was previously called "auto". It was changed to
be more consistent with "onRequest".
-
onRequest
-
The link should not be traversed until such traversal is explicitly requested.
When the show and actuate attributes are used
on a simple-type element, they signal behavior intentions for
traversal to that link's single remote resource. When they are used on an arc-type
element, they signal behavior intentions for traversal to the resources indicated
by the to value (or its absence).
Useful analogy to behavior in HTML user agents can be made to illustrate
the traversal behavior desired. For example, the following combination on
a simple-type element in the HTML A style signals
the intention that traversal behavior be initiated by user action (perhaps
clicking on the element content) and that the target resource replace the
resource containing the link in the display window:
<a
xlink:type="simple"
xlink:href="..."
xlink:show="replace"
xlink:actuate="onRequest">click here</a>
|
The following combination on a simple-type element in the
HTML IMG style signals the intention that traversal behavior
be initiated as soon as the link is recognized by an XLink implementation
and that the target resource be embedded in the resource containing the link
in the display window:
<img
xlink:type="simple"
xlink:href="..."
xlink:show="embed"
xlink:actuate="onLoad" />
|
A sample attribute-list declaration for show and actuate
on an XLink simple element might look as follows:
<!ATTLIST simple
show (embed|new|replace) #IMPLIED
actuate (onLoad|onRequest) #IMPLIED
>
|
