Fabio Vitali
University of Bologna
In [1], a list of 9 fundamental (according to the authors' opinions) hypermedia functionalities were proposed and discussed, with the understanding that few of them, if any at all, were either available on the World Wide Web or exploited to their full potential:
These items were selected from a longer list of 25 items assembled at the 2nd HTF workshop in conjunction with the Hypertext '96 conference [2].
It is my understanding that all of these functionalities could be now easily implemented on the WWW. Server-side CGI, servlet or DBMS applications, as well as client-side plug-ins, Java and Javascript programs allow now a degree of freedom in customizing the WWW unprecedented in any other hypermedia system (even those that did implement some of these functionalities). The research and commercial communities have in fact already explored some of these functionalities in the last few years (there are examples of backtracking, external link bases, link attributes, etc.). Yet, none of them has really caught on with the larger WWW community, or even found a small visibility stand-point through the available commercial applications.
It is indeed my opinion that no Java applet, CGI application or other custom concoction can possibly produce any relevant change in the way the WWW is used. The reason for this is that these would all be added functionalities to the core server and browser sets. And, unfortunately, the WWW in neither the set of server functionalities, nor the set of browser functionalities.
The fact that the WWW is not a system, or a set of interdependent systems, but a set of protocol and languages, is obvious yet not sufficiently understood. No single system can provide added value to the WWW as a whole. Almost no-one (in many cases not even Microsoft or Netscape) can introduce a new functionality in their products and find out that the WWW as a whole catches on. The WWW must not be improved in the systems, but in the way it actually works: by changing the underlying languages and protocols (HTML, HTTP, CGI, etc.).
We can group the above-mentioned functionalities in two larger families: those that add to the active participation of the users in the production of information, and those that add to the exploration of the available information. On the one hand, annotations, private links and computed personalized links (that require external link bases and link update mechanisms to work on a large scale) allow for the active participation of readers to the nodes they read. On the other hand, overviews, trails, guided tours and sophisticated backtracking patterns (that require richer node and link types and attributes) enhance the navigation and the access to the information of the hyperbase. Finally transclusions and links of various temperature provide both a richer expressive means for authors, and a richer exploration means for readers.
Both families share the same problem: they are not functionalities that can be experienced by the single user, i.e., that one enlightened user can adopt for his/her own purposes and be enriched by using them: they are functionalities that have to be shared by a large community in order for them to fully provide their benefits: there is little point in using an external link database, if I can't share my links with my colleagues; there is little point in annotating or transcluding, if I can't publish my notes and transclusions; there is little point in being able to create overviews and guided tours on some collection of documents, if I can't publish it for my readers.
My point therefore is simple: by providing a new functionality by means of a special applet, CGI application or plug-in, one does not enhance the WWW, because the diffusion of the functionality is defined as the diffusion of the applet, application or plug-in. On the other hand, if one manages to extend the languages of the WWW, if one manages to extend the feature set of the protocols that define and compose the WWW, then one can reasonably believe that at least in part the desired functionality will appear in the relevant systems.
For instance, unless we extend the limiting linking possibilities of HTML, there is little possibility of having external links, and therefore private links, computed links and external linkbases: the link model proposed for XML [3] derives directly from the HyTime linking model, which explicitly allows for external links. Just as well, unless we extend the WWW markup language to specify the data that compose a guided tour or a local map, there is little hope to see it widespread thorugh an applet: while XSL, the stylesheet language for XML, only provides support for text-based objects such as blocks, paragraph or inline styles, simple extensions such as those proposed in [4] and [5] may provide the markup-based extensions for arbitrary graphic objects, including graphs. Finally, unless we extend HTTP to allow for authors and linkers to work within the WWW environment, there is little hope to see external linkbases work properly: the WebDAV working group [6] is in fact extending HTTP to allow distributed authoring and versioning, and hypertext-aware researchers are needed to provide input on the sophisticated interactions required by that functionality.
To summarize, It is not providing a proof-of-concept of the functionalities, but extending the feature set of the languages and protocols of the WWW, that we can reasonably see our pet operations available on this hypertext system.