Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
XLink promises an enormous leap forward for hypertext on the
Internet, while providing only a taste of what more
hypertext-focused systems have attempted to deliver. As a
former chair of the XLink working group put it, "XLink is hypertext
for the 1970s." That marks a significant advance in
manageability and flexibility over the kinds of hypertext linking
we have today in HTML - an advance, even by the high standards of
the hypertext community.
XLink lets you define links that establish connections that are
multi-directional and multi-dimensional. Links may point
forward or backward only, or they may point forward and backward,
and they may do this for multiple resources. HTML links
define a path moving forward from a particular portion of a
document, with very little flexibility regarding how that link
should be actuated. Hyperlinks in HTML are about users
clicking, while images are about applications loading and embedding
images (should they choose to do so) without user
intervention. Hyperlinks in XLink are about a much wider
variety of possible interactions of users, applications, and
resources.
XLink lets you define sets of resources - not just points within
documents - and define connections between those resources.
XLink applications need more than a Back button; they need to
remember which links came from where, adding links as appropriate
that might point back to the previous document or to other
documents entirely. Applications supporting XLink need to be
capable of keeping track of links and apply them in ways that allow
users to establish links from documents they don't control.
(A second standard, XPointer, makes it possible to precisely
identify link locations without controlling the original
documents.)
Why is this useful? It means developers can spend a lot
less time managing hundreds of thousands of links spread across
thousands of documents. It means that core linking
functionality, like menus, can be defined in one place, and
distributed to many many clients. It means that people
organizations can link to and from documents they don't control -
subject, of course, to the application knowing of the links.
It also means that developers can build new kinds of user
interfaces that provide different connections to users with
different needs within the same application.
All of XLink is built using attributes identified with the XLink
namespace (http://www.w3.org/1999/xlink). While this gives
developers one less thing to manage in their own vocabularies, it
also means that XLink can't be easily blended into
vocabularies. Earlier drafts allowed for remapping of
attributes, but more recent drafts have demanded explicit use of
XLink's chose namespace. (This may make things difficult for
XHTML, among other specifications.)
XLink doesn't require applications and developers to change the
entire way they do things all at once. Instead, it provides
some options that let you get started with XLink syntax but work
pretty much the same way you did in HTML. You have a little
more control over how interactions work, but there's only one href
at a time, the connections only go from the point of the link to
the resource identified by the href attribute, and implementation
is much, much simpler.
(XLink doesn't define conformance at all at present. Some
applications, notably Mozilla, only implement simple links.
Microsoft's browsers don't yet implement any XLink processing
unless you create stylesheets, applets, or ActiveX controls to do
so.)
Simple Links
Simple links are very much like the a and img elements in HTML,
though they include both kinds of behavior in the same
construct. Simple links connect the element in which they are
declared to the resource identified by their xlink:href
attribute. All of a simple link's behavior is defined through
attributes, shown in the table below:
Attribute
Notes
xlink:type
When assigned the value 'simple', identifies the link as a
'simple' link. The link is inline and unidirectional and contains a
single target destination in an href attribute.
xlink:href
Contains the URI that represents the target of this link.
xlink:role
Provides a "description of the link's content". For simple
links, could be used to style different kinds of links differently.
Value must be a URI.
xlink:arcrole
Describes the resource at the end of the xlink:href URI. For
simple links, could be used to style different targets of links
differently. Value must be a URI.
xlink:title
Provides a human-readable title for the link, pretty much like
the popup text that appears now in some browsers.
xlink:show
Provides the options new (appear in new window), embed (included
in text), and replace (appears in the current window) for the link
content, as well as other and none.
xlink:actuate
Offers the choices onRequest (wait for user activation) and
onLoad (process automatically) to indicate when link processing
should happen. other and none provide additional
application-dependent options.
A simple link that recreated the behavior of the HTML a element
might look like:
A simple link that recreated the behavior of the HTML img
element would use some of the same values, but a different URI and
different values for xlink:show and xlink:actuate:
An XLink-aware application should treat the first example as a
clickable link that replaces the current page with the content of http://www.simonstl.com, while it should treat the second link as a
request to embed the image at http://www.simonstl.com/smallcrane.gif in the document without
waiting for the user to click on it.
Extended Links and Arcs
Extended links use many of the same attributes as simple links,
and some of the attributes used in simple links take on more
meaning in contexts where extended links are in use, but the two
types of links are kept fairly separate by the specification.
Extended links provide most of the real power of XLink, and require
a significant shift in perspective from simple links.
While simple links represent one way connections from the
element describing them to another point, extended links represent
sets of resources, which may or may not include the element
describing them. Those resources come with identifiers and
descriptions, but the actual 'paths' between them, if any, are
defined by subcomponents called 'arcs'. (The terminology
comes from directed graph theory.)
This means that an extended link includes a container element
(the link as a whole), components identifying resources (called
locators if local to the element, or resources if remote), and
possibly components identifying and describing connections between
those resources.
The container itself is defined with only three attributes:
Name
Notes
xlink:type
Elements containing the attribute xlink:type with the value
'extended' should be treated as extended links by XLink
processors.
xlink:role
Provides a "description of the link's content". For extended
links, might be used to specify different kinds of processing for
different types of locator sets. The role must be a URI.
xlink:title
Provides a human-readable title for the link, pretty much like
the popup text that appears now in some browsers. Child elements
with an xlink:type attribute set to title may also be used in cases
where multiple titles are needed, perhaps for multi-language
scenarios.
Similarly, resources and locators only need a small set of
identifying features:
Name
Notes
xlink:type
Elements containing the attribute xlink:type with the value
'locator' should be treated as locator elements by XLink
processors, while a value of 'resource' indicates a resource
element.
xlink:href
Contains the URI, the target of this link. (Resource elements
only.)
xlink:role
Provides an identifier describing the locator's content. Must be
a URI.
xlink:label
Provides an identifier that can be used to identify how
different types of resources and locators are connected (by arcs)
within a link.
xlink:title
Provides a human-readable title for the locator, pretty much
like the popup text that appears now in some browsers.
With these two parts, we can define a simple extended link,
describing a set of wedding photos and some associated address
information:
The pictures element provides a container, while the photo and
address elements provide locators connecting to other
documents.
So far, we have a set containing resources. We know that
there is some relationship between these items, but a processor may
still need assistance in figuring out how to connect these
items. Arcs, which use the values of xlink:label attributes
to connect them, fill this gap. Like simple links, arcs use
the xlink:show and xlink:actuate attributes to define behavior for
the link.
Name
Notes
xlink:type
Elements containing the attribute xlink:type and the value 'arc'
should also be treated as arcs by XLink processors.
xlink:from
Identifies the origin, using a label value from one of the
locator or resource elements in the extended link. (If no value
appears, defaults to all locators and resources.)
xlink:to
Identifies the destination, using a label value from one of the
locator or resource elements in the extended link. (If no value
appears, defaults to all locators and resources.)
xlink:arcrole
Provides an identifier describing the arc. Must be a URI.
xlink:title
Provides a human-readable title for the arc, pretty much like
the popup text that appears now in some browsers.
xlink:show
Provides the options new (appear in new window), embed (included
in text), and replace (appears in the current window) for the link
content, as well as other and none.
xlink:actuate
Offers the choices onRequest (wait for user activation) and
onLoad (process automatically) to indicate when link processing
should happen. other and none provide additional
application-dependent options.
Now that we have arcs, we can specify more precisely how we want
to connect those wedding photos:
It turns out that the only connections in this case go from the
pictures of Charlie to Charlie's address. There may be other
links that describe connections from these pictures to other
pictures, but these links only go to the address. (They don't
come back from the address, either.)
XLink also provides a mechanism for identifying 'linkbases',
documents that only contain other links. The idea behind
linkbases is that sites can centralize all of their linking
information into a much smaller set of files, and connect all of
their files through those concentrated collections of linking
information. The only links that need to be distributed are
the connections to the linkbase itself. Sites could share
linkbases, and linkbases are very easy to process and analyze
automatically. Since an XLink processor will only show the
links appropriate to a given document, some of the information
might be wasted, but sites where users circle through multiple
pages looking for information should find efficiency gains as well
as management convenience.
While XLink offers an incredible amount of functionality, it has
opened nearly as many questions as it has answered. Some of
those questions are technical, and, while difficult, will probably
find answers in implementation. Others are political, and
make the 'deep linking' issues already created by the Web look
downright easy.
The technical questions come from a number of fronts. Some
developers are deeply irritated that the xlink:show and
xlink:actuate information is communicated through XLink, rather
than specified in style sheets. Others have pointed out that
the controversies surrounding the use of URIs as identifiers (for
xlink:role and xlink:arcrole) has been unending with regard to
Namespaces, so why go that route for XLink?
The most severe technical problem XLink faces is probably not
within the specification itself, however. It simply isn't
clear how style sheet processing should be integrated with
XLink. The problems are easier with Cascading Style Sheets,
though no explicit support for XLink is yet available in CSS,
because the document trees don't change. Links pointing to or
from a given location can be expected to continue to point to or
from that location. When using Extensible Stylesheet Language
Transformations, however, the entire document is in flux.
Locations and links can move, repeat, or even disappear. It isn't
clear how links should work in such an environment, and the W3C has
yet to work out the details.
Perhaps more complicating are the political issues.
Opening up linking so that anyone can annotate anyone's documents
is more or less an invitation to graffiti. (You'll have to at
least visit the graffiti perpetrator's site for this to work, of
course.) Defining multi-directional links also opens new
opportunities for creating collisions between opposing viewpoints,
making it possible to associate organizations that don't normally
get along. Ownership of linkbases promises to create new
precedents in intellectual property law, and it may be a long while
before all of these issues are sorted out.
