|A Vision for Open Hypermedia Systems||Nürnberg and Leggett|
All OHS's represented in the OHSWG have at least one Sproc that serves navigational hypertext abstractions such as link and/or anchor. We claim that several OHS's conceptually provide more than one Sproc to their users, even if these different Sprocs are implemented as one process in these systems. HOSS provides an explicit open Sproc layer in its architecture, so it is clear that it provides multiple Sprocs, both conceptually and in implementation. OHS's with a notion of composite object (e.g., DHM, HyperDisco) might be thought of as having a conceptual "composition" Sproc. Systems with information retrieval facilities (e.g., Microcosm) might be thought of as having a conceptual "IR" Sproc. When non-OHS hypertext systems (VIKI [Marshall and Shipman 1995], StorySpace [Joyce 1991]) are considered, more examples of conceptual Sprocs can be found.
What is the benefit of an open Sproc layer? If the set of structural abstractions served by a system is open, the set of entities serving them should be as well. The case for an open set of abstractions was made in Section 3.2.1. One could argue that even if an open set of abstractions were to be served, one could accomplish this with a closed set of servers if these servers could be modified or extended over time. We feel this is an argument grounded in implementation. Whether or not the addition of new abstractions is effected through the addition of new servers or the modifications of existing ones does not change the fact that the reference architecture should provide a way to express this addition at a conceptual level.
What is the benefit of identifying multiple Sprocs in systems such as DHM or Microcosm when this obviously does not mirror the implementations of these systems? Why shouldn't the DHM hypermedia server or the Microcosm filter manager be seen as one Sproc? Clearly, they can be so conceptualized. In one sense, this is an issue that does not affect the argument for an open Sproc layer. However, something on this point clearly must be said if the architecture is to be in any way descriptive. This question is simply a particular instantiation of the issue of what constitutes a Sproc.
Above, we stated that a Sproc serves a set of structural abstractions. More descriptively (but correspondingly less precisely), a Sproc serves a coherent set of structural abstractions. Coherence of a set of abstractions does not seem amenable to definition, but informally, we can understand it to mean that a Sproc's set of abstractions is coherent if its members constitute a particular structure model. For example, at a basic level, navigational hypertext has a model with links connecting anchors that are themselves "connected" to (or associated with) locations in nodes or nodes themselves. (Whether or not this is anyone's exact model of navigational hypertext is for the moment not relevant to the discussion at hand. It will be addressed below in more detail.) All OHS's have a similar model of navigational hypertext, and so we can, as a group, decide that anchor, link, node and other related abstractions can be coherently grouped into a set served by one Sproc. Furthermore, we believe that few people would naturally group the abstractions of spatial hypertext into such a Sproc, since they seem to be of a fundamentally different variety. Composition, IR, taxonomic, and other structures might also be agreed by the group to constitute individual Sprocs.
One could raise an objection to the notion that there should (or could) be only one model of navigational or any other kind of hypertext. There are two answers to this objection. Firstly, the reference architecture certainly admits cases in which systems provide many largely similar but slightly different Sprocs. That is, this objections does not apply to the reference architecture, but to a particular application of it, that being the application of standardizing the meaning of certain hypertext models. This leads to the second answer to this objection. At a fundamental level, the OHSWG is concerned precisely with the task of standardizing the notions of what constitutes hypertext. If we as a group decide that a link server (navigational Sproc) must understand a message such as GetAnchorTable in the current protocol proposal, we as a group have (partially) standardized the notion of (navigational) hypertext. To do so does not in any way speak to specific implementations of such an abstraction, but it does speak to what the client can reasonably expect the interface to any implementation to look like. This is the definition of standardization. Furthermore, to say that we have standardized the notion of hypertext does not speak to the target audience of such standardization. That is, we do not claim that our work need be adopted by anyone outside the group to call this work "standardization". Particular efforts directed toward the consideration and/or adoption of our standards by the W3C, IETF, or other bodies is not discussed here.
In Section 2.1, we said that the group must (at least implicitly) define the notion of hypermedia. We now would like to rephrase this requirement in terms of the discussion here on open structural abstractions. The group must define both the list of types of hypermedia (or structural computing [Nürnberg et al. 1997]) in which it is interested, and what abstractions constitute these types. Our perspective is that abstractions served by the current OHS's (excepting HOSS for the moment) essentially fall into three categories: navigational (served by all), compositional (DHM, HyperDisco), and IR (Microcosm). We feel that these three types of structural computing constitute a good starting point for the group. Different types of structural computing can be addressed at a later time.
One benefit of this division of abstractions into three sets is that each OHS can subscribe to the OHSWG standards in terms of which of these sets it supports. All OHS's support a form of navigation (although the exact definition of navigational hypertext is not provided here). Some systems currently support composition or IR, while others do not. We have taken a view in this group to this point that one way for systems lacking certain functionality to be OHSWG compliant is simply to ignore (gracefully) service requests concerning this functionality. This is a result of a too coarse-grained approach to service definition. With the finer-grained Sproc approach to service definition, clients wishing to use, for example, composition services need not poll OHSWG servers until they find a composition-aware server. They simply locate (through a SIM) a composition server. This server may in fact be the same process as that which is serving navigational abstractions to this same client, but conceptually, these services should remain separated.
2. Scope of the OHSWG...
4. An OHS Reference Architecture Proposal
4.1 Architecture Entities
5. An OHP Proposal...
4.2 Architecture Protocols...
Appendix A. Generic Encoding Layer Rules
Appendix B. Sproc Generic Layer Rules
Appendix C. Sproc Specific Layer Rules
Appendix D. Sproc Interface Format
Appendix E. Current Protocol Proposal in Sproc Interface Format
Peter J. Nürnberg, John J. Leggett