Abstract

AJAXLink and XLink offer a lot of opportunities and also a lot of places where design decisions need to be made. In this lecture, some of these design decisions are discussed, so that the design process and the implementation decisions can start with less uncertainties. While in some cases it simply is necessary to decide whether a certain feature should be supported or not, in other cases different strategies can be chosen to implement a feature.

Option Paralysis

• The course project setup is an experiment
  • may succeed because it is challenging and interesting
  • may fail because there is too little guidance and/or pressure

Option Paralysis: The tendency, when given unlimited choices, to make none.

Douglas Coupland, Generation X: Tales for an Accelerated Culture, St. Martin's Press, 1991

XLink Design Space

Traversal Attributes

• Traversal Attributes define the possible traversals of a link
  • labels are assigned to locators or resources
  • from and to on arcs specify how a link can be traversed
• If there is no from and/or to, all resources are affected
  • this allows very questionable semantics (e.g., onLoad replace for all link targets)
• AJAXLink should only support a subset of behavior/traversal combinations
  • use cases also depend on the number of associated resources
  • the most important thing is a well-defined set of links and the expected results

Behavior Attributes

• Behavior Attributes are defined for arcs only
  • without arcs, XLink does not allow any link behavior control
  • but the specification does not limit application to use default behaviors
• HTML's built-in behavior is a mix of XLink's options
  • img is onLoad embed
  • a is onRequest replace
  • XSLidy's listing simulates text-oriented onLoad embed
  • onLoad replace probably is not very useful (redirect?)
  • onRequest embed is an unusual interface idea for the Web (not stateless)
• Use cases are the best way to think about interesting features
  • XSLidy's listing combines onLoad embed with support for text fragments
  • for the exploration of the design space, use cases help to identify good candidates

Semantic Attributes

• Behavior Attributes and Traversal Attributes define link interactions
  • which link target connections are traversable
  • how link connections should be traversed when the link is actuated
• Semantic Attributes describe the semantics of resources and arcs
  • role on locator/resource describes the role of the resource in the link
  • arcrole on arc describes the role of the arc in the link
  • titles provide human-readable semantics
• XLink visualizations need these semantics for formatting (e.g., grouping)
  • the first-level ordering should be according to arcroles
  • the second-level ordering (or icons) should use the arc's end point's semantics
  • XLink's assumption of heavily structured links may not always be true
  • linklets should be written based on role/arcrole and use title

Supported Media Types

• XLinks can link any resources
  • the media type is only determined when a resource is retrieved
  • the link may specify a fragment identifier for the resource
  • fragment identifiers are always used on the client-side only
• AJAXLink must define two levels of media type capabilities
  • which media types can be handled as resources
  • for each of those media types, which fragment identifiers can be handled
• Media type support depends on the expected behavior
  • for onRequest replace the browser will take over completely
  • embed is more demanding because it requires DHTML programming
  • embed with image fragments would even require image cropping

HTML Fragments

• Most XLinks connect (X)HTML resources
  • embedded XLinks contain HTML as a resource
  • internal out-of-line XLinks are a different encoding of embedded XLinks
  • external out-of-line XLinks by definition cannot be embedded
• Out-of-line XLinks must identify the part of the HTML they are linking
• HTML fragment identifiers (.html#id) can only identify elements
  • if it is an HTML element (such as a li) it can be identified
  • if it is part of a text, it must be made identifiable with a span id="…"
  • if there is no element-based anchor, the text cannot be linked
• This has implications for Creating XLinks

Yahoo! UI Library

                oMenu.addItems([
                        { text:"Homepage", url:"http://dret.net/netdret" },
                        { text:"CV", url:"http://dret.net/netdret/cv" }
                    ]);

  <p>This is a paragraph with <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended"><home xlink:type="locator" xlink:label="Homepage" xlink:href="http://dret.net/netdret"/><cv xlink:type="locator" xlink:label="CV" xlink:href="http://dret.net/netdret/cv"/><resource xlink:type="resource" xlink:label="period" xlink:href="kisling.xml"><span id="menutoggle" style="background : #F6F7EE">an XLink pointing to both</span></resource></link>.</p>

Menus vs. HTML

• Default display can be mapped to menus
  • simple list of linked resources
  • if there are Semantic Attributes, they can be grouped (nested menus)
• Linklets require a more flexible way of rendering links
  • menus should be the default rendering (the default linklet)
  • linkbase- or user-supplied linklets can be used to customize the rendering
  • linklets could be used to generate any kind of HTML popup
• HTML popups are more flexible than text-based menus
  • AJAXLink should adapt to various visualizations and styles
  • XSLT and HTML are the most versatile tools for this

Creating XLinks

• Server-based creation
  1. generate HTML forms (or XForms) for acquiring data
  2. use form data to assemble XLink on the server side
  3. submit to linkbase using the REST protocol
• Client-based creation
  1. use DHTML code for acquiring data
  2. assemble XLink on the client side
  3. submit to linkbase using the REST protocol
• Extension-based creation
  1. create browser interface for acquiring data
  2. this would be the ideal choice for collecting many links (using drag and drop)
  3. use extension to assemble XLink on the client side
  4. submit to linkbase using the REST protocol

Two Local Anchors

• One link can connect two local resources
  • no problem in principle
  • test cases and code must take special cases into account

  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended">
   <desc xlink:type="locator" xlink:href="#little-bear"/>
   <img xlink:type="locator" xlink:href="../img/south-hall-portal.jpg#rect=(178,117,20,20)"/>
  </link>

  <img src="../img/south-hall-portal.jpg" alt="South Hall Portal"/>

  <p>Finally, South Hall is the home of <span id="little-bear">the smallest bear on the UCB campus</span>, which often causes flocks of tourists to stare at the building, led by eager blue-yellow clad tourist guides.</p>

Design Work

• AJAXLink is an idea, not a complete project
• Communications usually help to solve (or even avoid) problems
• Work on your part until 03-06
• On 03-06, clearly communicate what you need
• On 03-20, some of that should actually be there
• On 04-03, the different parts should work together