6. Metacommentary

Scenarios. Certainly, in this paper, we found that grounding our reasoning in concrete examples of use of systems (strictly hypertext systems or not) led to the identification of major issues for the consideration of the group. Even the few implications we derived from the analysis of the four scenarios discussed played a major role in our proposals. In short, we found the scenario-based approach helpful in organizing our thinking.

The scenarios play another role in this paper as well. They help provide motivation for the implications we drew. Thus not only were they helpful to us, but hopefully are helpful to others who consider the implications we identified. Whether or not a particular person finds the conclusions justified, the scenarios provide a basis for discussion that is easier to understand than abstract discussion on the issues of naming, open structural abstractions, etc.

The group so far has been only partially committed to carrying out requirements analyses based on these scenarios. Several position papers at the last two group meetings described or at least summarized scenarios for the purposes of defending a particular feature of a proposal or identifying important issues. However, other discussions, especially on the OHS mailing list, have tended to shy away from using scenarios to discuss issues. Informally, we have noted that those issues raised in position papers with scenarios have either led to useful discussions or have been generally accepted by the group as being important. Conversely, similar issues raised on the mailing list have resulted in exchanges of assertions that do not seem well-supported and do not lead to productive discussion. It is not entirely clear that the scenarios comprise the whole difference between such discussions, but we suspect that the usefulness of a discussion and its basis in practice are causally related.

Architecture. The issue of how helpful the architecture work has been in considering the protocol requirements is more difficult to answer. It seems that in large part, the architecture work is being pursued because people find it interesting in its own right, rather than for purposes of protocol design. There is nothing wrong with this pursuit - on the contrary, it will undoubtedly heighten the group's collective understanding of OHS's. However, we should consider decoupling these two efforts, at least partially.

Most of the architecture is not relevant for designing a protocol that allows application interoperability. In our protocol proposal, we considered only the link server (Sproc) layer and those entities that communicate with it. Clearly, many of the entities can be further described. They may in fact be quite complex. Consider that clients and storage engines may be wrapped or not, there may be collaboration support, tool integrators, session managers, notification control systems, and a host of other functionality in an OHS environment. Nonetheless, from the point of view of the protocol, only those entities that communicate with the server(s) are relevant, and then only to some degree.

We believe that the architecture work should continue, but that protocol design should be decoupled from it. Scenarios can inform both the protocol and architecture efforts, and the architecture work can suggest future protocols that the group may want to standardize. "Radical" architecture proposals such as those discussed at OHS 3 (e.g., combining the client and storage engine entities) might impact the way in which protocol work is carried out, but arguments over the details can probably be safely ignored by the protocol designers.

Current Implementations. Unfortunately, the group to date has few real success stories. No fully-compliant implementations of the current OHP have been announced on the OHS mailing list. As of OHS 3, no systems were interoperating using OHP. If the group is to remain viable and vibrant, this must change soon. The main problems to date have seemed to be that the level of uncertainty in the specification and the lack of available effort on behalf of the group members.

Until the group endorses a preliminary draft of the protocol, it is unlikely that group members will implement any proposal. However, the group is hesitant to endorse any particular proposal until it feels comfortable that no major problems exist with the proposal. Obviously, these are conflicting interests. In our experience, people in general and academics especially err on the side of wanting a "perfect" solution. As a group, we should try to resist this urge to make the protocol specification perfect before releasing it. We believe that it is imperative that the group fully endorse a proposal and a method for modifying the proposal by the end of 1997. The method for modifying the standard should require widespread consent of the group membership before changes are endorsed and take place within a framework that ensures a high degree of backward compatibility.

Contents

Top
1. Introduction
2. Scope of the OHSWG...
3. Scenarios...
4. An OHS Reference Architecture Proposal...
5. An OHP Proposal...
6. Metacommentary
7. Conclusions
References
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