XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

The Return of XML Hypertext

The Return of XML Hypertext

January 22, 2003

It is a commonplace to observe that one's dominant sense of what XML is and is best for is shaped in large measure by one's technological background knowledge. After one has toiled in the distributed computing fields, XML will seem like a welcome plain text protocol stratum; after working with Oracle for a few years, XML seems a vendor-neutral data exchange mechanism; after manipulating s-expressions as a Lisp programmer, XML will seem -- or so the most outspoken members of that community keep assuring the rest of us -- like an annoying, tedious reinvention; and after building sleek and sexy dot-com sites, XML will seem like many things, perhaps most of all like a trial, a test, something one hopes simply to survive.

XML is all of these things at once, which explains its popularity, if not its success. But what if your background is hypertext, and you spent idle days dreaming of Xanadu? What is XML, and what is it best for, if you've spent long hours popping and pushing HyperCard stacks? Among the places one might go for an answer to these questions, consider the newly minted xml-hypertext mailing list.

Hypertext and XML

The first thing one might say about xml-hypertext is that its credentials suggest that it is a trustworthy source. A brief glance through its archive is like a glance through the Who's Who of the XML community. Not only is the roster of participants a good indication of the quality of conversation, but it also suggests that the list's motivating idea is not the product of a single person, but reflects broader community interests.

In announcing the xml-hypertext list, Simon St. Laurent suggested a basic agenda for the conversation; "appropriate subjects include," St. Laurent said, "technologies for linking and pointing, hypertext-oriented transformations, and interactions between XML and Web infrastructure". Among the technologies which fit that bill, St. Laurent mentioned XLink, XPointer, HLink, SkunkLink, VELLUM (one of St. Laurent's own proposed linking technologies), XHTML, RDF and Topic Maps, SMIL.

It makes sense that a mailing list about XML and hypertext will focus on linking technologies, since linking is essential to every robust hypertext proposal -- computing technology has long tempted very smart people as a way to overcome what is seen to be the static nature of old-fashioned, that is, printed books. But there is, of course, another reason linking technologies should be at the fore: of the constituent parts of the original XML vision, linking technologies have lagged the farthest behind. In fact, XLink is far and away -- as Bob DuCharme pointed out in his XML.com article, "XLink: Who Cares?" -- the least implemented, least influential of the core XML technologies.

That has to bother hypertextual XML technologists. As must the fact that HTML, which is the most widespread hypertext project ever, is also nearer to the sparse than the rich end of the hypertext spectrum. One of the limiting factors, then, on the growth of XML linking technologies is HTML's impoverished, simplistic linking model. Since HTML remains the main way of rendering hypertext for end users, it has often been a drag on efforts to implement richer, more complex link types. St. Laurent expressed the same basic point by saying that "HTML's decision to go with purely in-line linking was a brilliant simplification, but it did shock and disappoint a lot of old-school hypertext folks, even markup hypertext folks. It also had some serious implications, limitations, for data modeling".

While technologies have been catching up, creating new, more complex linking facilities doesn't seem to be a high priority among the corporations and communities which build browsers. One of the neatest things to appear on xml-hypertext so far is Bob DuCharme's demonstration of one-to-many links, which works in most browsers. Clicking the link pops up a menu from which one can choose from among the various link destinations. DuCharme's demonstration uses "nested a elements to implement one-to-many links in HTML. Except for those links, this document is regular XHTML. The referenced XSLT script, 1toM.xml, copies everything verbatim but converts nested a elements to JavaScript menu generation code..." In other words, the one-to-many markup is an elegant extension of what most people already know how to do:

<a>W3C Schemas
  <a href="http://www.w3.org/TR/xmlschema-0/">Part 0: Primer</a>
  <a href="http://www.w3.org/TR/xmlschema-1/">Part 1: Structures</a>
  <a href="http://www.w3.org/TR/xmlschema-2/">Part 2: Datatypes</a>
</a>

It would seem, then, that more complex link models are expressible with existing technologies, though the messiness of doing anything with JavaScript across all browsers is legendary. It suggests that browser makers are the ultimate target audience for demonstrations like DuCharme's.

The Semantics of Linking

In what remains of this column, I want to review some of the interesting early threads of discussion on the xml-hypertext list. Norm Walsh initiated conversation by asking whether links should, across a set of schemas, be expressed as a uniform element construct -- <a href="">, for example -- or whether various element types within the set of schemas should be treated as links via means of some annotation or transformation. In other words, is a link a first-class entity itself, or is linking a property that can be applied to a document?

As Norm said, "I think my mind is still open on this issue, but I tend pretty strongly towards the former camp, I think. Links are semantic and belong in the markup in a first-class way that I don't think style deserves".

The issue of link typing has also come up on the list. Bob DuCharme wants to be able to type links at the schema level (this is what XLink calls link roles, as John Cowan pointed out). "The document designer should be able", DuCharme argues, "to pick types appropriate to the domain, and then use that typing information as part of link processing". What sorts of link processing does he have in mind?

A type could provide a hook to pre-traversal presentation as an aid to navigation. A user who knows that text in blue is a link anchor leading to a primary source and text in red is a link anchor leading to commentary on a primary source can use the results of the link typing to get to the appropriate material more quickly. Or it can indicate a different kind of typing more related to presentation: perhaps blue text leads to a single document but red text is a multi-ended link that, on one platform, displays a menu of those potential traversals.

But what is the best way to express the type of a link within a document? Should it be an attribute -- DuCharme's example: <link type="bibref" ID="br1234"/> -- or should the kind of element used to represent the link imply its type? In other words, as DuCharme says, "The big (and vague) question is, if typing lets you specify processing for a class of links, how do people want to classify links?"

Conclusion

While it's still early, the xml-hypertext list may turn out to be an important new chorus of voices for XML technologists to pay attention to. Going forward, its two primary technical subjects of interest are likely to be new ways of rejuvenating linking in XML applications, including the end-user Web, and (though this is more a prediction than a promise) the issue of linkbases, that is, collections of out-of-band links or relations between resources. At the very least, as Michael Hahn put it, the conversations likely to occur on the list may be a welcome change from other, more frequent topics of XML talk: "I'm just here for the 'text' part of hypertext -- it's certainly a welcome break from 'object serialization' and 'Web Services'". And so it is.