Open Hypermedia Systems Working Group

Brief description of the OHSWG

Purpose of the OHSWG

Previously, systems work in hypermedia tended to be directed toward the traditional application domain of navigation (i.e., the authoring and browsing of structure over data), as inspired by Bush's seminal article, As we may think [1945]. However, hypermedia structuring principles have been applied to a wide variety of domains, including hyperliterature and hypermedia art [Bernstein et al. 1991; Bolter and Joyce 1987; Bolter 1991; Kaplan 1994; Kinsella 1996; Landow and Kahn 1992; Leistøl 1994; Michalak and Coney 1993; Moulthrop 1989; Sawhney 1996], argumentation systems [Conklin and Begeman 1987; Fischer et al. 1989; McCall et al. 1990; Schuler and Smith 1990; Smolensky et al. 1988], spatial hypertext [Marshall and Shipman 1995], and systems for taxonomic work [Nürnberg et al. 1996, 1997; Parunak 1991, 1993].

Much systems work intended for supporting navigation is applicable to supporting these other domains as well. In order to deliver functionality to this broader class of clients, however, it was necessary to consider opening the set of structural abstractions supported by an OHS. A natural way in which to accomplish this is to generalize the link server of contemporary OHS's, replacing this single entity with an open set of link server peers (or simply, structure servers).

Considering an open set of structure servers, however, led to the separation of much of the component infrastructure from the definition of the structure server interfaces themselves. The definition and standardization of these component interfaces and the infrastructure that supports client/server interactions in this environment is the new focus of the group.

The basic purpose of the OHSWG is to standardize these aspects of OHS's. Currently, each OHS implements slightly different interfaces on different infrastructure, making applications integrated into one OHS unable to use the services of other OHS's. Standardization of these aspects of systems will allow clients to operate over all compliant OHS's. Since application integration is an open-ended task, such standardization saves effort on the most costly aspect of OHS implementation. Standardization also allows third parties to build naturally compliant application, bypassing the extra integration step completely.

Philosophy of the OHSWG

Scenario-based specification. All functionality proposed to be part of a given architectural component should be justified through one or more scenarios of OHS use. That is, when proposing that some given functionality should be added to the OHS specifications, a scenario based on actual or foreseen use of an OHS should be submitted to the group for discussion. The group should reach a consensus on whether or not the scenario demonstrates the need for added OHS functionality before discussing how best to specify such functionality.

Component-based specification. Specifications should fall into one of three categories: infrastructure, domain, or framework. Infrastructure specifications address the functionality (interface and operational semantics) of OHS backends on which OHS middleware should be built. Domain specifications address the functionality of OHS middleware on which OHS clients can be built. Framework specifications address how components should request and deliver functionality they provide.

Open specification. The set of domain specifications is open, since the set of potentially useful structure models is open. Additionally, each domain specification should allow for extensibility and tailorability of the core abstractions defined by the specification.