Jacco van Ossenbruggen, Lynda Hardman, Lloyd Rutledge
CWI Amsterdam
In open hypermedia systems, a common scenario is to have a broad range of desktop applications that share hyperlinks and other structures by making use of one or more distributed hypermedia servers. In contrast, on the Web the typical scenario is to have a single client application on the user's desktop, that communicates with the (typically many) servers that store the documents that are relevant to the user.
Currently, the Web is evolving towards an environment which supports many alternative scenarios, in which the browser plays a less dominant role. These alternatives raise new requirements that will necessitate modification of the current Web protocols, as well as the development of entire new ones. The objective of this paper is to inform the OHS community of the current efforts of W3C to move in this new direction, and the possible relationship these efforts have with the current OHS activities.
One of the initial objectives of the Web was to provide a single, uniform interface for users that needed access to information on different platforms, using different information services and different document formats. The fact that Web browsers indeed meet this objective has made a major contribution to the success of the Web. Browsers are available for multiple platforms (e.g. Windows, Unix and Mac), can access information using different protocols (e.g. HTTP, FTP and RTSP), and display information in different document types (using built-in rendering software, plug-ins, applets or helper applications). For several years, this single, uniform user interface was a leading design principle underlying the development of the basic Web-protocols.
In the following sections, we describe why the browser-centered scenario is no longer sufficient. We discuss some requirements of alternative scenarios, the impact these requirements have on the current Web protocols and their underlying models, and the efforts of W3C to modify these protocols accordingly.
The single uniform interface has proven to be very useful, and we certainly do not foresee the end of the central role of the Web browser. However, we do see a number of application areas in which the browser plays a less important role, while these applications can still benefit from the Web's infrastructure.
First of all, we want to make the observation that from the beginning, the ideal of the single uniform interface was never met completely. Browsers from different vendors, and subsequent versions of browsers from a single vendor differed significantly (as illustrated by the infamous "This page is best viewed by browser X" claims). Additionally, even with the help of plug-ins and helper-applications, it proved practically impossible to support every media type found on the Web in a single browser. Since more and more users with alternative platforms are starting to make use of the Web (e.g. users accessing documents by mobile phones or television set-top boxes) the capabilities of browsers will further differentiate. To take these differences into account, browsers need standardized mechanisms of defining their capabilities which go beyond the current schemes based on MIME types. For example, a browser running on a mobile phone could indicate that while it does implement HTML 4.0, it does not support tables and frames.
Second, XML [XML] has accelerated the development of a number of new document formats which can be used on the Web as an alternative for HTML. It is expected that many XML document types can be displayed in the standard browser, using CSS or XSL style sheets. Some application areas, however, need presentation functionality which goes beyond the rendering capabilities of an ordinary browser. Examples of such application areas include multimedia, mathematical and chemical markup and high-resolution graphics. Such applications will often use special-purpose client applications, and the way these clients interoperate with a ordinary Web-browser needs to be defined. Electronic data interchange (EDI) forms another example of a domain in which the role of the browser is less significant, and the requirements differ from the more usual Web-applications. In EDI, interchange of machine-readable data among (database) applications is of more importance than direct presentation of these data to a human user.
Third, many applications need facilities which can only be provided by combining (parts of) different document formats. For example, Powerpoint-like applications might want to be able to combine HTML markup with SMIL timing [HTML+TIME]. While XML provides Web applications a means to define the syntax of their own, domain-specific document models, it does not (yet) provide solutions for combining the document semantics underlying these different syntaxes.
Above, we identified three types of applications:
These applications make the requirements for the Web's infrastructure significantly more complex than the current, browser and HTML-centered situation. We discuss these requirements below.
The requirements of the first type of applications can be addressed by developing mechanisms by which documents can declare the browsers features which are required to process that document, and by which browsers can declare the features they support. This involves two steps: a common mechanism to declare these features (along with the algorithms and protocols needed to negotiate between client and server) and a way to unambiguously define subsets of the large amount of features required by the current Web specifications. These two steps are commonly referred to as profiling and modularization.
Different client applications need to be able to describe their capabilities in a machine-readable way. Such descriptions are typically called profiles. Currently, HTTP provides some ways to indicate the browser's capabilities, for instance by listing the MIME types it support. The scenarios sketched above, however, require a more fine-tuned mechanism for defining profiles. The W3C working draft "Reformulating HTML in XML" defines such a mechanism [Voyager]. An import aspect of profiles is the ability to indicate the support for well-defined subsets of a certain specification. Such subsets are often called modules.
Splitting a specification up into modules helps applications in defining what part of the specification they support unambiguously. An obvious candidate for modularization is HTML [Voyager]. which is expected to be redefined into several, relatively independent, XML tag sets. Other Web specifications are We expect other Web specifications to adopt a similar, modularized, approach in the near future.
Just splitting a specification up into modules is not sufficient for supporting the two other types of applications. The second type of applications require mechanisms to develop new applications that, while they are not based on HTML, can still fully benefit from the Web's infrastructure. The third type of applications requires the ability to mix and match modules from various Web specifications. From a software architecture perspective, supporting this level of integration is difficult to realize because -- especially in an open environment like the Web -- it will require standardization of a plethora of APIs. From a syntax perspective, mixing modules is partly addressed by the XML Namespaces draft, but on a semantic level, many integration issues are still open. Below, we summarize some of these semantical problems. While most of these are based on our experiences with SMIL [SMIL], most of them are more generally applicable.
The three types of client applications sketched above are more in line with the way open hypermedia systems are currently used, and it is to be expected that the new and adopted Web-protocols will better facilitate interoperation between open hypermedia systems and the Web, and on the long term support the evolution of the Web into a open system itself. The new requirements of these applications, however, will raise new problems for the Web community. Some of these problems have already been solved by the OHS community, because they touch the very core of the expertise within the OHS community, not only on a theoretical level, but also on the level of implementation experience. We feel that the OHS community should be aware of these new efforts within W3C, and be actively involved in the development and implementation of the relevant protocols.