Abstract

Even though XLink is an interesting and sufficient foundation for the project of this course, it does have some problems for the AJAXLink application. The most important observation is that XLink is underspecified and missing important complementary specifications in various areas. The two most important areas are linkbase access (how to selectively retrieve XLinks) and link visualization (how to render a link once it has been retrieved). This lecture proposes a simple XLink visualization algorithm.

XLink Fundamental Problems

• No concept of link visualization
  • HTML initially was a mix of content and presentation
• No access protocol for linkbases
  • REST and APP are promising candidates, but need some additional work
• Embedded resources are untyped (no MIME type identification)
  • the type of locator-identified resources is given by HTTP
• Maybe Semantic Attributes should use QNames rather than URIs
• The specification defines a syntax rather than a model (the model is implicit)
  • a fundamentally wrong way of defining a data format and creating many problems

XLink Navigational Problems

• Pairwise connection between resources can only use one arc
  • the label/from/to way of connection resources probably is not the best solution
• Behavior Attributes are underspecified and should cover the most important media types
  • what does it mean to embed HTML into a GIF fragment onRequest?
• No support for ordering of arcs and resources
  • arcs and resources are sets, but for rendering, ordering in most cases is very important

What is an XLink?

1. An XLink may play a role (the Semantic Attribute role)
2. An XLink may have a title (as simple attribute or using title children)
3. XLinks contain sets of resources (identified by locator or embedded as resource)
4. External resources may use Fragment Identifiers
5. Each resource may play a role (the Semantic Attribute role)
6. Each resource may have a title (as simple attribute or using title children)
7. Arcs connect resources based on label/from/to
8. Arcs may play a role (the Semantic Attribute arcrole)
9. Each arc may have a title (as simple attribute or using title children)
10. Arc behavior can be controlled by Behavior Attributes (show and actuate)
11. The resulting structure has to be made navigable from the current resource

Abstract Navigation

• XLink's model is not directly usable for navigation
  • it defines the abstract relationships between resources
  • concrete navigational tasks may use only a subset of these relationships
  • navigation always starts from one of the resources (the current resource)
  • different environments may require very different rendering (e.g., visual vs. aural)
• XLink rendering should be based on a common model
  1. one XLink specifies a set of resources (and some linking metadata)
  2. additional XLink data can be supplied by the linkbase (e.g., a set of linkbase-wide arcs)
  3. the rendering environment might filter out some resources and/or arcs
  4. the remaining structure and the current resource define the effective navigational structure
• The effective navigational structure should be the starting point for rendering

XLink Interaction and Interface

XLink Rendering Algorithm

1. Compute the effective navigational structure and start from the current resource
2. If any onLoad is found, no interactive navigation is required
   • the exact same actions should be carried out as in the case of interactive navigation
   • multiple onLoad arcs probably should be considered an error
3. Collect all outgoing arcs (where the from is equal to label)
   • sorting them is not possible using standard XLink attributes (no sort order information)
4. For each arc, create a first-level navigation structure
   • use the title as text for the entry
   • if present, use the arcrole as additional information (maybe used for styling)
5. For each arc, create a second-level navigation structure for each target resource (label=to)
   • use the title as text for the entry
   • if present, use the role as additional information (maybe used for styling)

Link Interaction Language (LIL)

• Interaction design should be independent from interface design
  • one interaction instance can be rendered in different interfaces (e.g., HTML and XUL)
• A simple interaction language allowing two-step navigation
  • the first level provides information about the interaction path (i.e., the XLink arc)
  • the second level provides information about the endpoint (i.e., the XLink resource)
• Additional information for better rendering may be available
  • the link itself may have a title and/or a role
  • the first level (arc) may have a title and/or a role (title is heavily recommended)
  • the second level (resource) may have a title and/or a role (title is heavily recommended)
• Second level information may be a pointer or a resource
  • depends on whether the XLink contains a locator or a resource

Blinkbase LIL

• Doc or Die interaction for Pluto permalink URI (created with xlink2lil.xsl)

<?xml version="1.0" encoding="UTF-8"?>
<links>
 <link start="http://docordie.blogspot.com/2006/08/sorry-pluto-and-some-thoughts-about.html" title="Sorry Pluto… And Some Thoughts About Categorization">
  <first title="Post Time">
   <second>2006-08-27</second>
  </first>
  <first title="Post Author">
   <second title="Bob Glushko" href="http://www.ischool.berkeley.edu/~glushko/" />
  </first>
  <first title="Blog Home">
   <second title="Doc Or Die" href="http://docordie.blogspot.com/" />
  </first>
 </link>
 <link start="http://docordie.blogspot.com/2006/08/sorry-pluto-and-some-thoughts-about.html" title="Category Craziness in &#34;Decapod Duels&#34;">
  <first title="Related Post">
   <second title="Category Craziness in &#34;Decapod Duels&#34;" href="http://docordie.blogspot.com/2006/12/category-craziness-in-decapod-duels.html" />
  </first>
 </link>
</links>

Interaction to Interface

• LIL documents are not directly usable as an interface
  • they can be used as input for any interface-specific rendering
  • the mapping must map LIL concepts onto interface concepts
• lil2html.xsl transforms LIL into YUI HTML
  • the menu structure is built according to the functionality of YUI
  • for a YUI-capable environment, the interaction is implemented correctly
• lil2html.xsl is only a rough sketch and not complete
  • it does not position menus in the right location
  • it does not work very well with embedded resources
  • it does not take role information into account
• cosmos2blink.xsl → xlink2lil.xsl → lil2html.xsl goes all the way
  • each of these XSLTs is pretty far from being perfect

Controlling XLinks

• What is it that link authors/publishers may want to control?
  1. the mapping of context to XLink controls the exposed information
  2. the linkbase controls the link schema (labels, arcs, and roles)
  3. there might be a way to control the interaction (styling for xlink2lil)
  4. there might be a way to control the visualization (styling for lil2html/lil2xul)
• Content publishing has very similar questions
  1. how to map available information to HTML for publishing
  2. which HTML schema to use (what semantics are reflected in the HTML)
  3. Web Design Patterns specify how the structure is made navigable
  4. visual (and a bit of layout) styling using CSS
• Content and context publishing and presentation have a lot in common
  • currently, context is treated as content and context publishing is not well supported
  • this can be changed with a more context-oriented publication chain

Interaction Styling

• Interaction styling takes the link and turns it into a navigable structure
  • the default should be to implement the XLink specification
  • a special style might remove or add navigable structures
• Removing structures for less cluttered interfaces
  • it might make sense to filter out arc and/or resources on a per-linkbase basis
  • if a linkbase exposes its link schema, this can serve as a foundation for an interaction style
• Adding structures can add navigation options
  • an alternative debugging mode could always make all resources navigable
• In a distant future, interaction styling could even produce synthetic links
  • interaction structures are composed from various sources (link mashups)
  • new arcs in synthetic links connect previously unrelated resources across links

Interface Styling

• Interface styling depends on the interface technology
  • for HTML presentation, it should be CSS-based (maybe with additional features)
  • for XUL presentation, it should make a selection of XUL styling options
• Each interface mapping should have some definition for a default style
  • for HTML, this probably means taking CSS properties from the DOM environment
  • for XUL, this might mean to use browser defaults for interface settings
• Interface styles must be based on LIL and link schema information
  • the role information could be used to set a color scheme
  • if the interface allows, text titles could be replaced with graphics

Declarativity Needs Configurability

• Declarative Web 2.0 is useful for better context publishing
• Declarative technologies always have limitations
  • CSS is a very good example of how a declarative language can evolve
  • finding the sweet spot of expressiveness vs. complexity is a hard task
• Interaction and interface specifications should be configurable
  • there should be a default presentation if no styles are specified
  • link styling should be possible using styles for interaction and/or interface design
• XLink interaction and interface design and styling need work
  • xlink2lil.xsl & lil2html.xsl are good enough for our purposes