Abstract

One of the most important aspects of publishing is the relationship of content parts. The Web has popularized the concept of hypermedia, but HTML supports only a very simple concept of linking. The XML Linking Language (XLink) has been specified to provide a linking language for XML, and it supports a much richer concept of linking than HTML. One of the most important aspects of XLink is its ability to separate content and links, so that links can be regarded as being separate from a document's contents, making it possible to create flexible combinations of content and links.

HTML Linking Elements

• HTML has a number of elements representing links
  • the majority of these elements have very specialized semantics
• a: activate on click, replace current page (mostly), media type unconstrained
  • another usage is to specify a target name, but this is better done using ids
• img: activate on load, embed into current page, media type must be image
• map: specifies the areas of an image which serve as links
  • very specialized semantics, always used as img … usemap="#somemap"/
• script: activate on load, no rendering, media type must be executable code
• link: activation, processing, and media type depend on relation
• frame: activate on load, load into frame, media type unconstrained
• iframe: activate on load, embed into current page, media type unconstrained
• object: activate on load, embed into current page, media type must be supported
  • if the media type is unsupported, the object's contents are rendered

1:1 Links

• Web links (and in particular a links) connect two resources
  • as an exception, img … longdesc="…"/ can point to an image description:
  • the other conceptual exception are nested objects which implement fallback links
• 1:1 links have advantages
  • the relationship is easy to understand and easy to implement in an interface
  • people are used to the 1:1 links of the Web, anything else is confusing
• 1:1 links also have disadvantages
  • more complex relationships between artifacts must be mapped to 1:1 topologies
  • power users working with complex data models can benefit from more flexible linking models
• The most important question is about the underlying model
  • if content and associations are modeled as 1:1, HTML links are appropriate
  • if more complex associations are required, they should be represented in the data

Untyped Links

• Web links (and in particular a links) are mostly untyped
  • links are typed, but only a tiny subset of the links used on the Web
• Typing requires a type system (a set of allowed values)
  • it is unlikely that there is a link type system which works for the whole Web
  • on the other hand, tagging has become popular and also creates value
  • in closed environments, a strictly defined type system is applicable
• Typed links are essential for more complex linking models
  • for 1:1 links, typed links can be used to visually classify links (on-site vs. off-site is popular)
  • for 1:n links, typed endpoints allow much better representations
• The most important question is about the underlying model
  • if links are always untyped associations, HTML links are appropriate
  • if link types are relevant for the content, they should be represented in the data

Embedded Links

• Web links are part of the resources they are linking
  • link can have a rev attribute (indicating the endpoint of a link)
  • apart from that, all links in HTML are unidirectional and thus embedded in the source document
• Embedded links avoid a huge number of problems in hypermedia design
  • if links are directional, then all relevant information can be found in the document
  • any other scenario requires a complex infrastructure for discovering relevant links
  • closed hypermedia systems can solve this problem with a rigid system design
  • an open hypermedia system like the Web should not define very rigid rules
• Embedded links prohibit some of the most interesting features of hypermedia
  • the ability to author links from content to which there is no write access
  • the ability to have links which are traversable in more than one direction
  • the ability to share links by creating linkbases as separate resources

Links in XML

• XML elements have no predefined semantics
  • vocabulary designers can choose any name they like
  • vocabulary designers can choose any namespace they like
  • any semantics have to be defined in the vocabulary
  • the only exceptions are xml:lang, xml:space, xml:base, and xml:id
• Reusable semantics can be defined by reusable vocabularies
  • this is the same approach as for microformats (which usually are embedded in HTML)
• XML was intended to be delivered to browsers
  • XML's real success as a B2B language was an unforeseen development
  • browsers are all about displaying hyperdocuments, which always need links
• XLink was started to provide a link microformat for XML
  • and while we're at it, we might as well turn the Web into a proper hypermedia system!
  • XLink blissfully ignored numerous Web issues (and thereby created various problems)

Shorthand Syntax

• Support HTML's simple linking using a simplified syntax
  • simple links are nothing but a shorthand syntax for 1:1, unidirectional, inline links
  • Behavior Attributes and Semantic Attributes can be added to the link
• Being a true XML vocabulary, XLink employs XML Namespaces
  • in theory this is good, because this is what namespaces have been designed for
  • in practice, it introduces problems because of the dreaded namespaces syntax
• When re-creating HTML links, the behavior should be as in HTML

  <a xlink:href="…" [ xlink:actuate="onRequest" xlink:show="replace" ] xlink:type="simple" > … </a>

• Additional semantics can be specified using Semantic Attributes

  <a xlink:href="…" [ xlink:role="…" xlink:arcrole="…"  xlink:title="…" ] xlink:type="simple" > … </a>

Behavior Attributes

• Links are hypermedia structures which are traversed when navigating contents
  • a and img are good example for different link behaviors
• XLink introduces two attributes for controlling link behavior
• actuate controls when a link should be traversed
  • onLoad instructs to traverse the link as soon as the starting resource is displayed
  • onRequest waits for link traversal until a user has initiated link traversal
  • other allows markup extensions, none specifies that there is no additional information
• show controls what to do after link traversal
  • new specifies that a new presentation context is be created (e.g., a new window)
  • replace specifies that the target resource replaces the current resource
  • embed specifies that the target resource replaces the starting resource fragment
  • other allows markup extensions, none specifies that there is no additional information

Semantic Attributes

• Links often server a special purpose which should be specified
  • resources are connected by links and play a certain role in that relationship
  • arcs connect the resources of a link and play roles as typed connectors
• XLink introduces three attributes for describing link semantics
• title can be used in many places and adds descriptive (human-readable) text
• role can be used on locators or resources and describes the role in the context of the link
• arcrole can be used on arcs and describes the arc's role in the context of the link
• role and arcrole use URIs, but there is no definition for the resource format

XLink Structure

• Simple Links use a small set of attributes (and nothing but attributes)
• Extended Links are based various XLink element types being used together
• XLink element types are identified by the type attribute
• Extended Links can have a number of children
  • resources contain a resource as inline information (like the source of a)
  • locators identify a resource through a URI (like the target of a)
  • arcs carry Behavior Attributes and connect resources through Traversal Attributes
  • titles carry title information (and are repeatable and thus can be used for internationalization)
• locator and arc also can have title children
• Linkbases are pointed to by an arc with an arcrole of http://www.w3.org/1999/xlink/properties/linkbase
  • applications are free to use other methods to locate linkbases

Traversal Attributes

• Link traversal involves resources and arcs
  • resources can be labeled and traversal is based on labels
  • arcs specify which labels they connect
• XLink introduces three attributes for describing link traversal
• label is used for resources and locators (i.e., for resources)
• from and to specify for an arc which resources it connects
• A link with no arcs connects all participating resources

Attributes Only

• XLink is defined as a vocabulary of attributes
  • there are no predefined XLink elements
  • if elements carry XLink attributes, they have XLink semantics
  • vocabulary designers can choose the element names as they like

<environment xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended">
 <artist xlink:type="locator" xlink:role="artist" xlink:href="modigliani.xml"/>
 <influence xlink:type="locator" xlink:label="inspiration" xlink:href="cezanne.xml"/>
 <influence xlink:type="locator" xlink:label="inspiration" xlink:href="lautrec.xml"/>
 <influence xlink:type="locator" xlink:label="inspiration" xlink:href="rouault.xml"/>
 <history xlink:type="locator" xlink:label="period" xlink:href="paris.xml"/>
 <history xlink:type="locator" xlink:label="period" xlink:href="kisling.xml"/>
 <bind xlink:type="arc" xlink:from="artist" xlink:to="inspiration"/>
 <bind xlink:type="arc" xlink:from="artist" xlink:to="period"/>
</environment>

Inline Link

Inline Link with Arcs

Out-of-Line Link

Out-of-Line with Arcs

Element Type Relationships

• The XLink element type is determined by the type attribute

Attribute Usage Patterns

Linkbase Interface

H. Weinreich, H. Obendorf, W. Lamersdorf, The Look of the Link — Concepts for the User Interface of Extended Hyperlinks, Proceedings of HT'01, August 2001

Control Freak Interface

D. Stanyer, R. Procter, Improving Web Usability with the Link Lens, Proceedings of WWW8, May 1999

The Namespace Problem

• XLinks are identified through their namespace
  • technically correct, because namespaces have been created for exactly this purpose
  • problematic in practice, because users are exposed to a lot of namespace code
• Because of the way namespaces work, prefixes must always be used
  • XML Namespaces allows default namespaces, but these do not apply to attributes
  • it is not possible to legally circumvent the necessity to always use prefixes
• HTML++ was supposed to use XLink as the linking vocabulary
  • the majority decided that the namespace problem was too big to ignore
  • for a while, XHTML 2.0 used a homegrown XLink replacement called HLink
  • then the W3C TAG decided that XLink must be used for XML linking
  • currently, XHTML 2.0 has invented its own and even bigger set of hypermedia attributes
• Some W3C recommendations use XLink for linking
  • Scalable Vector Graphics (SVG) uses XLink but supports simple links only
  • MathML uses XLink but supports simple links only

The Stability Problem

• Extended XLinks link several resources
  • in the most interesting case, the link and the participating resources are all independent
  • like everything on the Web, any resource can change (or disappear) at any time
• Transclusion was invented based on a system of stable resources
  • Xanadu never removes resources (built-in versioning)
  • designing for a infrastructure with stable resources is much easier (and unrealistic …)
• Robustness can be built in as additional semantics
  • in a closed system, central control can ensure link integrity
  • in an open system, redundant information can detect integrity problems
  • designing an open system with stable third-party links is a very tough challenge

The Presentation Problem

• XLink does not constrain media types in any way
  • XLink is an XML format for links, but it can link resources other than XML
  • as a general model for linking, this is a good foundation
  • as something that should be implemented in browsers, this is not sufficient
• Resources and resource fragments can have very different properties
  • when embedding a fragment of another HTML page, which stylesheets apply?
  • if a link embeds a non-contiguous fragment, how should that be processed?
  • XPointer, the ugly little brother of XLink, never made it to the finish line
• Implementations will always be limited in their functionality
  • only a specific set of access protocols is supported
  • only a specific set of media types is supported
  • only a specific set of fragment identifiers is supported
• XLink has no concepts of conformance or profiles

XLink 1.0

• XLink 1.0 was finished in June 2001
• Adoption (even by W3C specs) has been disappointing
  • most XLink users (SVG, MathML) only use Simple Links
• Implementations are almost non-existent
  • most of the existing implementations are not fully implementing XLink

XLink 1.1

• XLink's failure prompted the question: Can XLink be fixed?
• Minor versions always are small changes only
  1. Make simple XLinks an application-level default
  2. Reserve all attributes in the XLink namespace
  3. Allow IRIs
  4. Provide sample XML Schema and RELAX NG grammars
• It is unlikely that XLink 1.* will be successful as a built-in technology
• This does not mean that AJAXLink cannot be interesting
  • instead of hardcoding XLink, it is the service's data format
  • one could think of value-added services using extensions (of semantics and/or behavior)
  • XLink in this case is a standard format for exchanging information about resource associations

Better Linking

• XLink introduces a powerful linking model
• XPointer's failure severely limits full-scale linking
• Linkbases introduce new possibilities, but also integrity problems
• Think of AJAXLink as an effort for standardized link exchange
  • with basic AJAXLink, links can be extracted and added on demand
  • with extended AJAXLink, additional functionality can be added
  • be creative and try to think in terms of links, not resources