A Vision for Open Hypermedia Systems Nürnberg and Leggett

2.2 Minimal Requirements

Even after the group decides what hypermedia and system mean, there still remains the question of how ambitious to be when designing the architecture and especially the protocol. There are conflicting goals involved in this matter. Less ambitious plans are likely to be implemented more quickly and easily, while more ambitious plans are likely to be more broadly applicable and useful. This has recently been a topic of some debate on the OHS mailing list, with various positions from less (as per Whitehead's 10 June 1997 post) to somewhat more (as per Grønbæk's 10 June 1997 post) ambitious.

Clearly, as a minimal requirement, the OHSWG must have a product with functionality either difficult or impossible to duplicate with other systems. This is hardly likely to be a source of much debate, since not to do so would result in a late solution to a non-problem. It also seems relatively uncontroversial to propose that our product be able to be implemented or adopted in stages, with an easy entry level and progressively more interesting levels to be added "later." There seem to be three questions that must be answered taking this as a starting point.

  1. What should the final functionality be? That is, what functionality do we see in our "final" level of development?

  2. What is the starting level? That is, what functionality do we see in our initial level of development?

  3. How many levels should there be? This can be thought of as describing the "deltas" between levels.

Final functionality. Before we spend a great deal of time answering this question, we should decide if we even need an answer right now, or if one can even ever be given. It is a good thing to have an endpoint in mind when starting a task. However, we should consider the possibility that our final product contains some open sets of entities that prevent us from truly talking about the functionality of the "final" version. In this paper, we take the view that this is indeed the case, and as such, have no proposal for a "final" level specification. The arguments for this view and the implications of it are discussed below.

Starting functionality. This is a considerably more difficult issue than final functionality, mostly because it must be resolved quickly. Less ambitious starting points are easy to implement. However, realistically, they may fail to capture the imagination of the group members and the larger hypertext research community. The fact of the matter is that, as of the OHS 3 meeting (April 1997), no group has OHSWG work as its top priority and it may be that none ever will. Without a tangible "value-added" to subscribing to and implementing OHSWG standards, they may languish unobserved. In any event, there is clearly a fine line between specifying too much work and generating insufficient interest. Although these concerns must be balanced, we favor a more ambitious startpoint specification, in the hope that its potential rewards for compliant systems will be sufficient motivation. We provide more specifics below.

Number of levels. Although this seems like a reasonable question to ask, it may in fact be somewhat misguided. Several posts in previous discussions have been made about "levels" of protocol compliance, but a looser (and more useful) interpretation of the underlying concept at work here is some set of "components," the members of which either may or may not be supported by a particular system. With a notion of levels comes the implication that a system supporting some level must support all "lower" levels as well. We should avoid making compliant systems support functionality that the designers of those systems do not see as necessary for their goals. We believe, in fact, that the notion of an open set of components provides a flexible model that system designers can use to their advantage. With respect to the issue of "delta" between levels (or its component analog) it should be the case that modifications to a system to adopt/integrate a new component should be well encapsulated. More details are given below.

Contents

Peter J. Nürnberg, John J. Leggett
HRL, CSDL, Texas A&M
original page URL: http://jodi.ecs.soton.ac.uk/Articles/v01/i02/Nurnberg/scope_ohs.html