(11) 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 [Behavior Attributes (1)] and Semantic Attributes [Semantic Attributes (1)] can be added to the link
• Being a true XML vocabulary, XLink employs XML Namespaces [../xml-fall06/xmlns]
  • 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 [The Namespace Problem (1)]
• 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 [Semantic Attributes (1)]

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

(13) 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

(14) Semantic Attributes

• Links often serve 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

(15) XLink Structure

• Simple Links [Simple Links (1)] use a small set of attributes (and nothing but attributes)
• Extended Links [Extended Links (1)] are based various XLink element types being used together
• XLink element types are identified by the type attribute
• Extended Links [Extended Links (1)] 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 [Behavior Attributes (1)] and connect resources through Traversal Attributes [Traversal Attributes (1)]
  • 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

(16) 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

(17) 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>

(18) Inline Link

(19) Inline Link with Arcs

(20) Out-of-Line Link

(21) Out-of-Line with Arcs

(22) Element Type Relationships

• The XLink element type is determined by the type attribute

(23) Attribute Usage Patterns

(25) 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 [http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hyperAttributes.html#s_hyperAttributesmodule] called HLink [http://www.w3.org/TR/hlink/]
  • then the W3C TAG decided that XLink must be used for XML linking [http://lists.w3.org/Archives/Public/www-tag/2002Sep/0183.html]
  • currently, XHTML 2.0 has invented its own and even bigger set of hypermedia attributes [http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#s_hyperAttributesmodule]
• Some W3C recommendations use XLink for linking
  • Scalable Vector Graphics (SVG) uses XLink but supports simple links only [http://www.w3.org/TR/SVG11/linking.html]
  • MathML uses XLink but supports simple links only [http://www.w3.org/TR/MathML2/chapter5.html#id.5.3.4]

(26) 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 [http://www.xanadu.com/] 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

(27) 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 [http://www.w3.org/TR/xptr/], 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