1 Introduction
The Open Hypermedia Systems community has recently focused on the issue of interoperability. The impetus for this work is the current state of affairs within the community. Multiple open hypermedia systems (OHSs) exist, but clients integrated with one system cannot make use of the others. This situation results from each system implementing a unique hypermedia protocol, providing similar functionality but with a non-interoperable set of requests, responses, and events. In addition, these protocols make use of a diverse set of communication mechanisms, e.g. sockets, dynamic data exchange (DDE), and AppleEvents, which are often platform-specific and unable to interoperate. The OHS community is in the process of developing a standard hypermedia protocol to address this inability to reuse clients across open hypermedia systems. The first draft of the specification [4] defines both the Open Hypermedia Protocol (OHP 1.2) and the run-time architectural elements required to handle a diverse set of communication mechanisms. The latter is required to keep the set of clients which can make use of OHP 1.2 as open as possible. For instance, restricting the standard to TCP sockets may prohibit clients which only have access to DDE or AppleEvents.
This paper focuses its analysis and discussion on the first version of the OHP specification [4]. This specification was first presented to the OHS community at the Second International Workshop on Open Hypermedia Systems (OHS 2.0). The protocol was discussed and the second author presented an invited talk [29] on various aspects of the protocol including success/failure criteria, separation of concerns, and opportunities for leverage. In December of 1996, the Open Hypermedia Working Group met in Southampton, UK to discuss the protocol again (OHS 2.5). It was at this meeting that the need for an open hypermedia reference architecture was raised. The participants of this meeting felt that OHP 1.2 could not exist without a context to better define its purpose and boundaries. This conclusion resulted in a number of papers [10, 13, 31] proposing candidate reference architectures at the Third International Workshop on Open Hypermedia Systems (OHS 3.0), which was held in April of 1997. In addition to these papers, OHP 1.2 [1, 24, 26] and open hypermedia scenarios (for instance, [14]) were also discussed. The idea behind the scenarios is to produce requirements on the protocol and reference architecture designs which are based on the needs of real-world activities.
At OHS 3.0, it was discovered that, in each reference architecture, OHP 1.2 essentially occupied the same niche. Thus, it was felt that work could progress on OHP 1.2 in parallel to the work on the scenarios and the reference architectures. In September of 1997, the Open Hypermedia Working Group met at the University of Aarhus in Aarhus Denmark (OHS 3.5) to continue work on the OHP. At this meeting, a new version of the Open Hypermedia Protocol (OHP 2.0) was presented to the working group by Hugh Davis. OHP 2.0 addresses many of the concerns raised in this paper and the first author's OHS 3.0 workshop paper [1]. These resolved issues will be noted as appropriate below. However OHS 3.5 marks a major departure to the approach used to discuss and improve the OHP in the previous meetings. Researchers representing the DHM [12], HOSS [22], and HyperDisco [32] systems suggested that a component-based approach to designing the OHP would prove more productive than arguing about low-level protocol issues. In particular, a component technology, such as CORBA [23], enables the specification of a component's services in an implementation-independent fashion. At the same time, a component framework implements low-level protocol issues automatically once implementations are supplied for the specified interfaces.
This change in design approach was readily accepted by the members of the OHS 3.5 working group meeting and enabled discussion about the components necessary to provide the interoperability services envisioned for the original OHP. As an outcome of the OHS 3.5 meeting, several components were designed and CORBA's Interface Definition Language (IDL) was used to specify the operations exported by these components. In addition, working groups were formed to look at specific sub-issues relevant to the open hypermedia domain. A subgroup is tasked with identifying the services necessary for a particular domain (such as navigational hypermedia) and providing IDL specifications (and possibly implementations) of the relevant components. The work performed by these subgroups is being archived at the OHS working group website. Relevant to this paper, the OHS component framework subgroup is tasked with examining the feasibility of continuing the low-level protocol work as defined in the OHP 1.2 and OHP 2.0 documents. The purpose of this task is to produce a low-entry barrier implementation of the protocol for developers reluctant to adopt the considerable infrastructure of a component framework. The framework subgroup is also responsible for evaluating existing component technologies for their use in specifying and implementing the OHP.
This paper is essentially an evolution of the first author's OHS 3.0 workshop paper [1], and now contains coverage of additional concerns, incorporates the outcomes of community discussion on various issues, and features a new section on the scope of the OHP. In light of the changes to the essence of the OHP work which occurred at OHS 3.5, this paper's primary purpose is to serve as an archival reference to the evolution of the original OHP protocol after it was first presented to the community and to capture the design rationale behind certain changes which occurred in OHP 2.0. The discussion at OHS 3.5 enabled insights into certain issues (especially Section 3.2.1) raised by this paper and these insights will be articulated where appropriate. Finally, certain issues raised in this paper were not addressed by OHP 2.0 and thus are still relevant to the component-based design of the OHP as well as to the low-level protocol implementation of the OHP (if such work occurs).
The rest of this paper is organized as follows. First, OHP 1.2 is described at a high level of detail. (OHP 2.0 is so recent a development that a full analysis of its design is outside of the scope of this paper. However, when OHP 2.0 resolves issues raised with OHP 1.2, the resolution will be described in context.) The protocol description serves as a basis for the resulting analysis of the protocol. The analysis is divided up into syntactic and semantic issues relevant to the OHP. Each issue describes the problem, reports on community discussions if applicable, and provides recommendations to the community on how to address the issue. The paper concludes with a discussion on the scope of the protocol and an appeal to the community for its help in evolving the OHP.
2 OHP description
The Open Hypermedia Protocol (version 1.2) assumes the following world view. Users invoke applications (such as word processors, spreadsheets, and databases) to browse and edit information. These applications can provide hypermedia functionality over their managed information by becoming clients of an open hypermedia system. In the current state of affairs, clients written to use the services of one OHS cannot (easily) use the services of another OHS. The OHP's primary goal is to change this situation and enable client interoperability across all OHSs. Rather than utilizing the native hypermedia protocol of a particular OHS, the client instead implements the OHP and can then access the services of all OHP-compliant OHSs.
The OHP consists of a set of messages, a set of data types, a specification of the legal message format, and two types of protocol shims. A description of the first version of the OHP appears in the OHP 1.2 specification [4]. The principle data type is called a LocSpec . It is used to store a description of the location of an anchor. The set of messages defines the legal requests and replies that a client or OHS can generate. An OHS can request a client to LaunchDocument, DisplayAnchor, DisplayLocSpec, Interpret, and CloseNode. A client can request an OHS to GetNode, GetServices, GetAnchorTable, CreateNode, UpdateAnchors, UpdateNode, Closing, and RequestService. An OHS can make the following replies to a client: HeresServices, HeresDocument, HeresAnchorTable, HeresNewAnchor, and HeresNewChannel. In OHP 1.2, no replies have been defined for clients; however, the protocol takes a layered approach to compliance and it is possible that client replies will be defined in future layers. Finally, two all purpose messages (Error and Other) have been defined and they can be sent by either the OHS or the client. The set of OHP messages is summarized in Table 1.
| Table 1: OHP Messages | |||
|---|---|---|---|
| Client Requests | Server Requests | Server Replies | General |
|
GetNode |
LaunchDocument |
HeresServices |
Error |
Currently, only two levels of compliance have been defined. Level 0, the base level of the OHP, defines operations to launch OHP-compliant applications and direct them to display specified documents. Level 1 adds additional operations to implement simple hypermedia services, enable client-side scripting, and define a prototyping mechanism for new OHP operations. Subsequent levels can be used, for instance, to increase the interaction of the end-user with the target OHS, provide more flexible scripting support, and add standard operations for services such as search-and-query.
The base level of the OHP states that only LaunchDocument and CloseNode requests can be sent to the client. No hypermedia services are provided. The idea behind this level of the protocol is to enable what is termed in the literature as a launch-only viewer [3, 30]. While launch-only viewers provide no hypermedia services to the end-user, a launch-only integration enables access to the data managed by these applications from other more highly-integrated applications. Thus the base level of the OHP is designed, at the very least, to encourage developers to integrate their applications such that they can be invoked by the OHP. The small effort associated with implementing two protocol messages presents a low-entry barrier to use and should increase the number of applications which are OHP-compliant. Once the benefits of being able to link to an application's information (even at a launch-only level of integration) is clear to end-users, developers may feel increased demand to implement additional levels of the OHP thus providing more hypermedia services to their end-users (all of whom may be using a different target OHS).
Level 1 of the OHP requires a client to implement all of the messages listed in Table 1. These messages enable a client to discover the services of an OHS, request services of an OHS, and store and retrieve the anchors associated with a particular document. In addition, link traversal is enabled since the OHS can request a client to display a particular anchor of a specified document (via DisplayLocSpec). A placeholder for scripting was included in this level in that the Interpret request can pass a script to a client for execution. The OHP 1.2 specification discusses the issue of server-side scripting but no operations were included in level 1 to enable it. The Error operation was included to signal a wide range of errors including network-, application-, and user-related errors. Finally, the Other operation/tag can be sent as a stand-alone message or appended to an existing message to provide the OHP with an extensibility mechanism. New messages for future levels of the OHP can be prototyped using the Other tag.
The final portion of the protocol defined by the OHP 1.2 specification is the client- and server-side shims.
A client-side shim is used to translate the communication protocol used to transmit messages over the network from the OHS into the communication protocols used by target applications. For instance, sockets might be used to communicate between the server-side shim and the client-side shim, but AppleEvents might be used to deliver the OHP messages from the client-side shim to the application itself. In addition to converting communication protocols, the client-side shim will have some additional functionality built into it including the ability to track the level of protocol conformance for each running application, to invoke applications that are required as the result of a link traversal, and to manage the network connection to the OHS.
A server-side shim is used to convert the native hypermedia protocol of the OHS into the appropriate messages of the OHP and vice-versa. The advantage to this shim is that it need only be written once for the OHS's native platform and it then enables interoperability with OHP-compliant applications on any platform (since it communicates with the client-side shims written for those platforms). Figure 1 displays the proposed shim architecture.
At OHS 2.5, it was noted that some of the proposed functionality of the shims fall outside of the domain of "hypermedia" and that what really is being discussed are run-time services. The entire issue of client and server-side shims led to the discussion of an open hypermedia reference architecture and several papers on this subject were presented at OHS 3.0.
| Figure 1: Shim Architecture Diagram | |
|---|---|
|
Architecture Notes 1. The top and middle protocol streams send and receive OHP messages. The only difference between them is the associated communications protocol or transport mechanism. The bottom stream sends and receives messages in the native protocol stream of the open hypermedia system using the OHS's preferred communications protocol. 2. The client-side shim provides additional services besides its primary capability of protocol conversion. It can invoke applications required by the LaunchDocument request. It also tracks the level of protocol conformance of each connected application. The scenarios of the OHP 1.2 specification provide examples of additional client-side shim functionality. 3. The client-side shim may speak multiple communication protocols or there may be multiple shims in the user's environment one for each communications protocol employed by the user's applications. Neither of these aspects are shown in the diagram. 4. The server-side shim and the client-side shim may each support multiple network protocols. This is also not shown in the diagram. |
3 OHP analysis
The analysis of OHP 1.2 will take place on several levels. A few syntactic issues are considered first. The bulk of the analysis, presented next, is centered around semantic concerns. Finally, a few issues concerning the scope of the protocol are discussed. For each issue, a recommendation will be made. The purpose of these recommendations is to help evolve the standard to a point where it can be implemented by outsiders of the open hypermedia systems community. The idea behind this goal is that such a standard would be fairly complete and not leave major issues unspecified or open to interpretation (which would lead to incompatible implementations). In addition, if a resolution has been reached on an issue, the resolution will be described at the end of the discussion. Resolutions are the result of community discussions held on the community's mailing list or at one of the open hypermedia workshops (OHS 2.0-3.5).
3.1 Syntactic issues
There are several syntactic features of the protocol which are internally inconsistent. While these issues may seem unimportant when compared to the semantic issues discussed below, the inconsistency caused by these syntactic concerns can lead to confusion and difficulty in learning and understanding the standard. In addition, syntactic problems can hide or disguise deeper semantic problems (as is the case with the OHP). Fortunately, in most instances, these problems can be easily corrected.
3.1.1 Inconsistent format for message names
For the most part, all OHP requests follow the format Verb-Noun, e.g., LaunchDocument or CreateNode. There are two exceptions to this rule: Interpret and Closing. Since the former is a request by an OHS for a client to execute a script, it should be renamed InterpretScript. The latter is sent by a client to the OHS to indicate that it is about to cease execution and thus its associated channel is no longer valid. This message should be renamed CloseChannel.
With respect to replies, the format for message names is Heres-Noun. Thus when an OHS delivers a table of anchors to the client, it sends the table with a HeresAnchorTable reply. Translating this message name into a proper English sentence produces "Here is the AnchorTable" or "Here's the AnchorTable". Since this contraction may be confusing to non-native English speakers (and in fact at OHS 3.0 several participants confirmed this intuition), it could needlessly hinder the understanding of the protocol. At OHS 3.0, the community agreed to drop the Heres prefix in future versions of the OHP specification. Thus HeresAnchorTable becomes AnchorTable.
Resolution. In OHP 2.0, these recommendations were followed with only a slight modification. The prefix "Heres" was dropped and the suffix "Def" was added. Thus HeresAnchorTable is now AnchorTableDef. In addition, the Verb-Noun format for OHP requests was adopted.
3.1.2 Inconsistent terminology within message names
There is an inconsistency in the use of the terms document and node within the message names. For instance, all OHP applications must support the base level of compliance with the protocol. With respect to this level of the protocol, an OHS may request an application to launch a document (via the LaunchDocument request) but at a later time close a node (via the CloseNode request). Is there a semantic difference between the two terms? In the OHP 1.2 specification, the terms appear to be used interchangeably. For instance, in Section 5.6.1 of the OHP 1.2 specification, the following sentence appears:
The linkserver has requested that a particular document of a particular type is opened, but at present the viewer for this data type is not running [4].
A few paragraphs later, the following sentence appears:
In this case the [application] will be expected to handle messages to open the node (LaunchDocument) and close the node (CloseNode) [4].
These sentences demonstrate that the terms are used interchangeably and are sometimes described as being datatypes. In the original OHS 3.0 workshop paper [1], a recommendation was made to pick one of the two terms and to use it consistently throughout the OHP specification and within the set of OHP message names. However during discussion at OHS 3.0, and subsequently on the OHS mailing list, additional issues have come to light revealing deeper semantic problems behind a seemingly simple syntactic concern. We address these semantic issues, and their OHP 2.0 resolution, in Section 3.2.6.
3.1.3 Encoding issues
Within OHP 1.2, there is no separation between the definition of interfaces for OHP functions (i.e., the client or server request messages) and the transfer encoding of the parameters in those interfaces. For example, the DisplayAnchor message specifies that the interface for this request contains the AnchorID, and the presentation color, style, and display, while also specifying how this message should appear when it is transported from server to client. This co-specification of interface and transfer encoding is similar to the HTTP protocol [6], where each method is a separate function, and the parameters for each function are encoded in HTTP headers which have hand-tailored encodings, and in HTTP bodies, which are MIME-encoded data. However, protocols such as Sun ONC Remote Procedure Call (RPC) [27] combined with the External Data Representation (XDR) [28], and Inter-Language Unification (ILU) [20] provide a strong separation between specification of interface and specification of transfer encoding. Providing a related distinction, the Abstract Syntax Notation One (ASN.1) [17] combined with the Basic Encoding Rules (BER) [18], separates abstract type descriptions from their transfer encodings.
The lack of a clear separation between definition of interface and transfer encoding led to the transfer encoding within OHP 1.2 to be under specified, since it is difficult to focus solely on either transfer encoding or interface definition issues when they are combined together. While the transfer encoding of basic types (integers, characters, etc.) has been specified by stating that all such types be encoded as ASCII strings (an inefficient encoding), other basic encoding issues are murky.
For example, the specification is silent on the topic of whether 8 bit octets or 7 bit octets are transmitted, yet this affects many other decisions within the protocol. One area it affects is the encoding of binary data. In the UpdateNode and HeresDocument messages there is a field for "Mime Encoded Data." However, as defined by RFC 2045 [7] and registered by IANA [15], there are at present five possible MIME encodings, known as "7bit", "8bit", "binary", "quoted-printable", and "base64". Each of these transfer encodings has their strengths, and hence the OHP working group will need to decide on which encoding type or types to use. All encodings could be supported, at the expense of larger OHP implementations, or a small subset could be chosen, with a correspondingly smaller implementation. Another issue requiring action is to decide which MIME headers are allowable in an OHP protocol stream. It seems prudent for future expansion to allow at minimum the MIME-Version header, and also the Content-Encoding header.
Another encoding issue is white space: what white space is required by the protocol, and which are the allowable white space characters. While the specification does appear to use at least a single space as a separator between field titles and field data in messages, the specification does not state whether this space is mandatory, or whether more than one space could legally be present. We recommend that the space and tab characters be allowed as white space, and that any number (greater than zero) of white space characters be allowable where white space is present in the specification. Where only one space character is explicitly desired, this should be explicitly noted by placing a space character into the message definitions.
The specification is also silent on the case sensitivity of field titles within OHP messages. Since the field titles always begin with a slash, it would make sense to make field titles non-case sensitive, since this would increase the robustness of OHP implementations.
On the topic of line feeds, the specification is not silent, requiring that each OHP message must only have a line break at the end of a message. While this provides an easily recognizable end of message indication, it has many undesirable consequences. One of the attributes of the OHP is that it is a non-tokenized protocol, with command and field names spelled out rather than represented by a shorter token. Though this results in longer messages, an advantage of this encoding is the messages are human-readable. However, by specifying that the entire contents of a message must be concatenated together without using line breaks for formatting, the messages become much less human readable. The specification for line breaks is also inconsistent with the quoted-printable and base64 MIME encoding schemes, which both specify that their lines cannot be longer than 76 characters. We recommend that the restriction on line breaks be dropped, and a new convention be adopted for specifying the end of an OHP message. Perhaps one of the MIME multipart media types [8], could be used for this purpose. The first part of such a multipart message could contain the OHP message, while other parts could contain encoded message bodies, if required by the particular message.
There are also some basic interface specification omissions for OHP functions. Many non-terminal productions in the BNF descriptions of messages are not defined, for example the AnchorID production, which is used in many messages. This leaves open the issue of whether the AnchorID is an integer, or some other form of identifier. The specification is also silent on the specification of the important fields DocName and Channel, along with numerous others. Some of these issues may be addressed by the work [24, 26] performed on LocSpecs (which examines how the HyTime standard [16] can beneficially influence the design of OHP LocSpecs). If so, this work must be integrated into a future version of the OHP specification, and any remaining non-terminal productions must be fully specified.
Resolution. The OHP 2.0 specification has started to address some but not all of these concerns. In addition, the component-based approach to proceeding with work on the OHP adopted at OHS 3.5 alleviates the need to specify these details. The reason for this is that distributed component architectures such as JavaBeans and CORBA hide the details of protocols used to establish and maintain communication between distributed objects.
3.1.4 Syntactic issues wrap-up
The goal of this section has been to provide recommendations that lead to an internally consistent set of OHP message names, in which requests follow a verb-noun format and replies declare the type of information being sent. In the future, care must be taken to maintain this consistency as new messages are added to the protocol. This effort should lower the learning curve associated with the protocol, since confusion over minor syntactic concerns will be eliminated or greatly reduced. The encoding issues of the protocol and our recommendations should be considered in order to achieve the goal of having a specification that can be consistently implemented by community outsiders.
3.2 Semantic issues
The syntactic issues raised in the previous section are minor or highlight areas of the protocol which need to be specified in order to produce consistent implementations. In this section, more serious issues are raised. These issues will require community effort to solve since the unifying underlying problem which causes them is the different styles and techniques employed across open hypermedia systems. OHP 1.2 already attempts to account for some of the differences which exist between open hypermedia systems, for instance, the different approaches to store and reference anchors. These mediators are a good start but further work needs to be done. This issue is revisited in the conclusions.
3.2.1 OHS services
The main semantic issue with OHP 1.2 lies in how an OHS specifies its services to client applications. Currently, after a client is initialized, it will make a GetServices request on the OHS. The OHS will respond with a HeresServices reply. This reply is defined as a list of Menu items and the names of the services these items invoke. The expectation is that an OHP client will create a menu within its user-interface that provides the user access to OHP services. When a user selects one of the menu items, the client will make a RequestService request on the OHS sending the relevant service name. There are several problems with this scenario.
User Interface. The user-interface of the viewer is predefined by the protocol. In particular, it assumes that each client will present a menu through which hypermedia services are accessed. While this assumption does not prevent alternative user-interfaces (since clients can either ignore the supplied menu names, or choose to present them in a different manner), it seems strange that a client's user-interface would fall within the domain of the protocol in the first place. This is not the only case in which the protocol deals with the client's user-interface. Further discussion of this issue appears below in Section 3.2.2 and Section 3.3.
Service Semantics. The semantics of the services are unspecified. The client is presented with a list of service names but is given no information with respect to the parameters a service requires or the protocol messages to expect in response to a service request. This is especially critical, as pointed out by the HOSS [22] developers at OHS 3.0, when the client accessing these services is a program, such as an automatic link generator, and has no user to interpret or guess the meaning of an operation. For instance, what information should be sent for the service END.LINK that is used as an example service in the OHP 1.2 specification [4]? There is no way for the client to discover what is expected. In addition, the protocol defines a reply called HeresNewAnchor but nowhere is it specified what service or request generates this reply.
Parameters and Results. The protocol provides no mechanisms for an OHS to define the number and format of parameters for each of its services or the format of the results of a particular service. For instance, the Chimera API [2], which enables communication between the Chimera server and its clients, has over eighty different operations that conceivably could be returned in response to a GetServices request. Some operations require two parameters, some require one, others require four. Some operations take strings as parameters, others take integers, and some take a list of attribute-value pairs (which themselves consist of two strings). Since there is no way to communicate any of this information via the protocol, a client developer would have to place that knowledge into the client in order to access Chimera via the OHP. In the same manner, there are no mechanisms to specify the format for the result of an operation. This particular issue is relevant to all API-based hypermedia systems, such as DHM [12], HOSS [22], and HyperDisco [32].
RequestService format. The format of the RequestService request allows three types of parameters to be passed: an anchor ID, a LocSpec, and a Presentation specification. The standard states that for some services these parameters might be null, but it does not discuss how a client discovers when or when not to supply these parameters. In addition, as mentioned above in Section 3.1.3 and below in Section 3.2.2, the format for some of these parameters have not been specified.
The result of these problems is that, in actuality, the clients of the OHP protocol have to meet two different types of OHP compliance. The first type of compliance (i.e. OHP Levels 0 and 1) was discussed in Section 2 and it indicates the set of OHP messages a client implements. The second type of compliance is service-list compliance. Presumably, each OHS will present a different set of service names in response to the GetServices request. From the discussion above, the knowledge of each of these lists must be programmed into the client by its developer or it will not know how to appropriately interact with the OHS.
Despite these problems, the authors of the OHP 1.2 specification further support their use of the service-list mechanism by stating [ 4]:
The set of services which a link service can respond to is not defined by the protocol. It might be possible to identify a set of services that is a superset of all known systems. It is not clear, however that there is much benefit in this exercise.
Based on the analysis above, however, it seems clear that the OHP in fact does need to define these services. Without clearly specified services, no OHP client can be considered fully compliant since there will doubtless be some service offered by an OHS not included in the client's implementation. As new services are made available by OHSs, OHP clients will have to be upgraded in order to take advantage of them. The scope of the OHP also becomes unbounded since any service, not just hypermedia services, can be accessed via this mechanism. Issues associated with scope are discussed below in Section 3.3. If this problem with the OHP is not addressed then OHP clients will be forced to comply not only with the OHP but also with each, potentially different, service-list generated by OHP-compliant open hypermedia systems.
Instead, a recommendation made by the original OHS 3.0 workshop paper [1], is to agree on a set of hypermedia services for the OHP and to specify the syntax and semantics of the requests and replies needed to implement these services. The alternative to bringing specific services into the standard is to add mechanisms which allow clients to discover the semantics of OHS services at run-time. This heavyweight solution is similar to the technique of providing run-time information about class methods and their parameters available for some object-oriented languages (e.g., the reflection mechanism of Java or the interface repository of CORBA). It is our recommendation to avoid such a solution and to replace the service-list mechanism as described in the OHP 1.2 specification with specific OHP messages that implement a core set of hypermedia services.
This issue was not resolved at OHS 3.0 and, in fact, a subset of the original authors of the OHP 1.2 specification confirmed their support of the service-list mechanism in [10]. They state:
We argue that this solution [defining a core set of services] lacks sufficient versatility for the provision of future services, and for the incorporation of the large variety of existing services. In defining the set of standard services, we would be faced with a dilemma. Either every different service type imaginable should be provided for - an impractical solution at best - or a smaller rigid set of services should be defined outside of which OHP will be unable to step. Instead, the authors advocate the dynamic provision of services that was proposed and discussed at the November workshop. [Note: OHS 2.5.] With this approach the service types are not hard-coded into the viewers, but are instead offered by the link servers. For each service, the link service could specify the type, an optional name that can be used in the user interface, the service category, and details of how the service is to be used.
Our disagreement with these arguments lies primarily from a difference in point-of-view. The driving motivation for the creation of the OHP is interoperability. Without standardization, interoperability will never be achieved. An open set of services will cause the creation of OHP clients which cannot work with all OHP-compliant OHSs (since the client may depend on a service not implemented by all OHSs), and thus are not interoperable. In addition, an OHP client and an OHP OHS may choose to implement the semantics of an operation, for example GetWriteLock, differently (What gets locked? The entire document? A subsection of the document? Is the write lock exclusive or can their be simultaneous read locks as well?). Semantic mismatches can then cause confusion in users expecting a different behavior.
A standard set of hypermedia operations does indeed impose a rigid boundary on the OHP but interoperability is the result. While it is true that WWW browsers hard-code the implementation of the HTTP GET operation, without it they would not be HTTP [6] compliant, and would be unable to retrieve resources from WWW servers. Thus, the hypermedia services of the OHP should be defined and the syntax and semantics of the associated OHP messages should be specified in detail. This enables the creation of independent and consistent implementations of the protocol. In addition, compliance with the protocol is easily checked. Either the operations defined for a particular level of the protocol are implemented within a client or they are not. With the current status of the OHP specification (version 1.2), service-list compliance is open-ended, non-interoperable, and never attainable.
Resolution. The service-list issue was finally resolved at OHS 3.5. First, in the new draft of the OHP (version 2.0), one of our recommendations was followed with respect to adding more OHP messages to implement core hypermedia services. However, the service-list mechanism is still present. At OHS 3.5, it was decided to adopt a component-based approach to specifying OHP services. This new approach satisfies all of the concerns raised in this subsection about the service-list mechanism. First, in order to add a new set of services to the OHP, a new component must be defined which has its interface (i.e. a set of operations and events) fully defined. A client and server specify their support of this a service by implementing the interface specified by the new component. In this way, the client and server are declaring their knowledge of the associated semantics of the interface and, using the component framework's services, it is easy to determine what subset of OHP services is understood by both clients and servers.
At OHS 3.5, the original purpose behind the service-list mechanism also became clear. The purpose was not to provide a mechanism to squeeze in services from a domain outside of hypermedia, but rather to enable an open hypermedia system to declare the set of link traversal algorithms it supports. Since the input of a link traversal algorithm can be standardized, the knowledge associated with invoking a link traversal algorithm can adequately be covered by the original GetServices and RequestService messages in OHP 1.2. Once this discrepancy was determined at OHS 3.5, it was decided to utilize OHP's notion of scripts to fulfill this original purpose of the service-list mechanism. A subgroup was formed at OHS 3.5 to examine link traversal issues in depth and to recommend the appropriate operations to be included in the navigation component of the OHP.
3.2.2 User-interface issues
As mentioned above, OHP 1.2 contains placeholders for handling user-interface
issues. In particular, it defines a tag called Presentation whose
format is client-specific. These presentation tags are associated with anchors and allow clients to store
user-interface style information for later use in displaying the anchor. The stated
goals for this placeholder is (1) an author may desire an anchor to appear in a
specific format overriding any format information specified by the end-user, and (2)
the OHS may wish to change the format of anchors within a viewer as the result of a
change in state or the computation of a server-side script. The OHP 1.2
specification argues that in order for goal 2 to be enabled, presentation
information must be part of the protocol. However, the issue is side-stepped in OHP
1.2 with the decision to make the presentation information client-specific. It is
then recommended that the presentation information be specified in later versions of
the protocol. An example format is given: (color, style, visibility). This
format is then used whenever the presentation tag appears in the protocol despite
the decision to make the format opaque in the first version of the protocol.
Despite the stated goals, including presentation information in a hypermedia protocol weakens the standard. In fact, objections to the presentation specification were raised by members of the OHS community as early as OHS 2.0. The suggested format included in the OHP 1.2 specification is an example of why this mechanism will never be fully satisfactory. At any point that a specific format becomes part of the standard, entire classes of clients will be excluded from using the presentation mechanism. For instance, suppose a client uses animation to indicate anchors in its display. The example format would be inadequate for it to specify animation parameters such as the images to use, the speed of the animation, etc. There is simply too much diversity between clients to have a "one-size-fits-all" presentation format.
This analysis suggests the following recommendation. Avoid any solution which requires a specific presentation format to be defined. Instead, provide a mechanism for clients to define named styles. The styles themselves would be opaque to OHSs and clients would have the option of storing these styles separately from the OHS. The presentation tag would then be defined as a list of style names. The stated goals of the presentation tag can still be met: authors can supply a list of styles to override any local definitions set by an end-user, and scripts can be changed to compute style names rather than specific presentation details. This latter solution operates under the assumption that it is the client itself which supplies these scripts to the OHS for execution on the server-side. Thus, it already knows about its style names and can write the script to compute the correct style names. If these scripts are not supplied by the client, then a mechanism must be supplied for script writers to discover the meanings associated with style names. Clearly this is not the only solution to this problem, however it illustrates a technique for supporting the stated goals of the presentation tag without resorting to defining a specific presentation format. At OHS 3.0, this recommendation was well received, but no official decision was made to adopt it. At OHS 3.5, the presentation issues have still not been addressed. Instead, the group has decided to encapsulate the notion of presentation specifics in an opaque object called the PSpec, and to form a subgroup to explicitly define the format and uses of this object.
3.2.3 Shim issues
The shim architecture as defined in the OHP 1.2 specification turned out to be a point of major contention at OHS 3.0. In the original OHS 3.0 workshop paper [1], the most serious issue raised with respect to the shim architecture was that a lot of information was left unspecified (Several OHS 3.0 participants who had attempted preliminary implementations of OHP 1.2 confirmed that leaving this information unspecified forced the implementors to interpret and implement these details in their own way. These implementations are highly likely to be incompatible). For instance, the OHP 1.2 specification does not specify how a client contacts a client-side shim, nor does it specify how a client-side shim discovers and contacts OHP server-side shims. In addition, despite the presence of the Error tag, the behavior of the protocol in response to network errors was left unspecified. The Error tag was designed to be used to convey error messages to the user, so the OHP 1.2 specification needs to define when socket-level or protocol-level errors get promoted to user-level errors and when they are handled automatically by the shims.
The most serious issue raised at OHS 3.0 with respect to shims was whether they were needed at all. In particular, most OHS developers are planning to implement native support for the OHP within their systems directly. This eliminates the need for a server-side shim to translate between the OHP and the OHS's native protocol. One recommendation to make in response to this argument is that if there are parts of the protocol which are difficult to implement, e.g. parsing a LocSpec, the community can benefit from a freely available reference implementation of a server-side shim which could serve as a starting point for OHS developers.
It also seems that the need for client-side shims, or some form of run-time on the client side, cannot be eliminated. The reason for this goes back to the communications protocol issue. For each communications protocol utilized by an OHP client, a client-side shim for that protocol is necessary to translate between it and the network protocol that is used between shims. In Section 4 of OHP 1.2 specification, it is indicated that there might be multiple network protocols supported by the client-side and server-side shims. We recommend, for the sake of simplicity, that only one "on-the-wire" network protocol, such as sockets, be chosen by the OHP. This would ease the OHS developer's task of implementing native OHP support for their OHS, and would also reduce the effort for implementing a new client-side shim for a particular communications protocol. This is because a reference implementation of the network protocol for the client side could be built and delivered as a library with an associated API for each of the major platforms (e.g. Win95/WinNT, MacOS, and Solaris). This reference implementation could take care of implementing the run-time capabilities defined for client-side shims such as launching required applications and tracking the protocol level of invoked clients. The task of producing a client-side shim would then be implementing a module to send and receive messages via the desired communications protocol, such as AppleEvents, and invoking the relevant operations on the API to translate the messages into the OHP network protocol.
In the original OHS 3.0 workshop paper [1], a recommendation was made to form a sub-group of researchers to produce reference implementations of the shims. Since the server-side shims are no longer considered necessary, this group would no longer have to focus its efforts on producing code for this component, however utility code to ease the task of producing a native implementation would still be useful. Now the group should focus its efforts on producing the reference implementation of the OHP network protocol once it has been fully specified. We recommend producing, at the very least, an implementation written in the Java and C programming languages. At OHS 3.0, while various participants announced that they are working on implementations, there was no interest to form the recommended sub-group.
Resolution. The decision to adopt a component technology at OHS 3.5 has essentially eliminated the need for any work to occur on the client- and server-side shims. The component technology will now handle these low-level issues automatically. However, there was a call to still have a non-component-based implementation of the OHP in order to present a low-entry barrier to use. The reason for this is that all existing component technologies require a developer to buy into a large set of infrastructure. A subgroup was formed at OHS 3.5 to evaluate the existing component technologies and to examine the feasibility of producing a non-component-based implementation. In addition, members of the open hypermedia community continue to work on defining the components necessary for a general open hypermedia reference architecture.
3.2.4 Channel issues
The OHP 1.2 specification proposed the notion of a communications channel. This opaque data structure contains the routing information necessary for an OHS to send requests and replies to an OHP client. The channel also contains the information necessary for the client to send requests back to the OHS. (The exact format of channel information has recently been discussed on the community's mailing list.) OHP 1.2 indicates that a channel will be created by an OHS for each document being viewed or accessed by the OHS's set of users. This is an instance of a document-related issue of the OHP assuming that a client can have only one document active at a time. We discuss the problems with this assumption in Section 3.2.6.
The OHP 1.2 specification also indicates that the OHP is a stateless protocol. In a stateless protocol, a client establishes a connection to a server, sends one message, optionally receives a reply, and disconnects. Sending two or more messages requires establishing a separate connection with the server for each message. When an interaction between client and server requires a large number of messages to be sent, the overhead associated with creating a connection for each message can be significant. However, the benefit of a stateless protocol is that servers are easier to implement since mechanisms to track state information can be eliminated. An additional approach, employed by HTTP/1.1 [6], is the use of a stateless protocol over a persistent connection. This maintains the principle benefit of stateless protocols (less complex servers) while eliminating the principle disadvantage (the significant overhead associated with sending a large number of messages).
Because the OHP 1.2 specification states that the OHP is a stateless protocol, it also specifies that the routing information stored in channels must be included in each OHP message. This allows a server that has received a request from a client to reply to that request at a later time by using the connection information stored in the channel. An issue which arises from this discussion is the lifetime of channel information. How long is a channel's information valid, how are channels distinguished from one another. Are unique identifiers required? If so, unique over what conceptual space? This type of information needs to be specified in the OHP specification. A related issue that needs to be specified in the protocol is a mechanism that enables OHP clients to discover the connection information for an OHP-compliant OHS. This allows a client to locate all available OHSs and connect to a server which implements the version of the OHP required by the client.
An alternative to the stateless approach is to maintain the connection between client and server, setting it up only once, and then sending all messages between client and server through it. This stateful protocol allows the removal of routing information from messages since the information is implicit in the established connection (thus reducing message size when compared to the stateless approach). In addition, the overhead for sending a large number of messages is reduced since the connection is maintained. The only drawback to the stateful approach is the slight increase in complexity of the associated specification which must take into consideration the behavior of client and server in the face of an unexpected termination of the network connection. In addition, stateful protocols may encounter scalability constraints in the presence of a large number of simultaneous users.
As can be seen from this discussion, a variety of choices exist for the nature of OHP. The community must carefully consider the pros and cons of the alternatives and choose an approach that best fits the OHP's requirements. We have had good experience with stateful protocols in the Chimera open hypermedia system [2]. The hypermedia protocols for both Chimera 1.0 and Chimera 2.0 have been stateful protocols which have been easily implemented as self-contained APIs. This approach allows a client to be completely ignorant of protocol details except during initialization in which a target OHS must be specified. However, due to the evolving nature of the requirements for the OHP, we cannot make a recommendation without further community discussion.
Resolution. The adoption of a component-based approach to specifying and implementing the OHP once again resolves many of the issues raised in this section. As mentioned above, these protocol-level issues are handled automatically by the distribution services of the adopted component framework. The OHS component framework subgroup will have to tackle these issues separately if it decides to implement a non-component-based version of the OHP.
3.2.5 Security
One area which has not been addressed at all by the OHP specification is the subject of security. Currently, messages within the OHP protocol allow a server to launch a program on a remote machine (LaunchDocument) and send a client an arbitrary script for execution (Interpret). A client may read (GetNode), create (CreateNode), and overwrite (UpdateNode) arbitrary files on the server's disk. Clearly there are significant security risks inherent in these commands.
The degree of seriousness of the security risk can only be assessed by first determining the expected use environment of the protocol. If OHP is only expected to be used behind a firewall, among a group of trusted users, then security concerns do not need to be addressed within the OHP protocol. Even though many features of the protocol could be misused, the atmosphere of trust will ensure that they are not.
However, once an OHP server is accessible from any machine on the Internet, or can be accessed by a machine outside the local firewall, security issues must be addressed because it is more difficult to establish trust between a client-server pair. This situation occurs if collaborators using OHP are located at different organizations, such as different companies, where they are not located behind the same firewall.
Once the OHP is transmitted across a firewall boundary, or out on the Internet, the following security issues need to be addressed:
- Authentication. The first step to establishing trust between a client and a server is for each side of the communication to authoritatively identify itself. The principal operating a client identifies themselves to the server, so the server trusts the operator is who they claim to be. In some cases, the server must also identify itself to the client, so the operator of the client can trust their information isn't being intercepted. Many technologies exist to perform authentication, including X.509 [19] certificates and MD-5 hashed passwords [25].
- Virus Protection. The Interpret command of OHP 1.2 allows scripts to be sent from the server to the client for execution, yet the specification does not state which are the allowable scripting languages. We envision a range of possibilities, from a limited scripting language which controls only display characteristics, to the sending of Java, Windows DNA (formerly ActiveX), or VisualBasic executables. For limited scripting languages which have no means for creating persistent state or affecting the persistent state of the executable image of the OHP client, the security issues are minor, but for transmission of more general executable scripts, greater security precautions should be taken. When executable content is transmitted, there must be some means to determine whether it can be trusted. Recent efforts on code signing, where the contents of the executable content are validated by a hash or checksum calculated by a trusted third party offer some hope in this area [21].
- Privacy. One pitfall of sending information across the Internet is the lack of privacy of the information. While a packet of information is being routed across the net, any computer attached to a network can read the information which is flowing across that network. The risk to OHP is that sensitive node information might be intercepted. While this is often not a concern, it does limit the use of OHP by collaborators working on sensitive data (e.g., a sales spreadsheet) across the Internet. One solution to this problem is to encrypt the node information before transmission.
- Access Control. OHP 1.2 allows an arbitrary file pathname to be given when reading or writing a file. If an OHP server were running on an operating system without a strong access control system (e.g., Windows), then there is a possibility for rewriting key files, reading documents, and accessing personal information. We recommend that the OHP protocol give recommendations for server implementors to restrict the namespace accessible via OHP operations, and to develop an access control scheme for future revisions of OHP.
While it may seem appealing to initially ignore these security issues, we feel this would be a mistake. There are already examples of hypermedia transfer protocols which address many or all of these issues, such as the HyperWave protocol and HTTP. If the OHP is not to be viewed as naive compared to these other protocols, then it must be robust enough to handle the network environment encountered on the Internet. OHP doesn't necessarily have to handle these issues by itself. Existing protocols, such as the Secure Sockets Layer (SSL) [9] (upon which the Transport Layer Security (TLS) [5] protocol is based), can be used to establish a secure Internet connection, and then OHP can be transmitted over the secure connection. A significant drawback to SSL support is that it would increase the difficulty of making third-party clients OHP compliant, and requires a certificate infrastructure.
3.2.6 Document issues
The original OHS 3.0 workshop paper had very little to say about document issues. It noted that the definition of the LaunchDocument request [4] goes into great detail about the steps that need to be taken when the destination client is not running. It fails, however, to specify the behavior of the protocol when the client is indeed running! Although the intended behavior is obvious, it needs to be specified. In fact, given that the former case may occur less frequently than the latter, it seems OpenDocument might be a more appropriate name for this request. In addition, it would be more in balance with its counterpart request: CloseNode. With respect to CloseNode, the original OHS 3.0 workshop paper noted that its definition seems to imply that the client application is expected to terminate execution. This behavior would clearly be surprising to most users and should be modified to close only the relevant document and not the application.
At OHS 3.0, an additional issue with respect to documents came to light. In particular, some participants questioned whether the terms document and node should be interchangeable. For instance, if a particular document is compound, consisting of two or more components, then it could be modeled as a single document with multiple nodes. This is similar to the notion of composites which are discussed in detail in [11]. This semantic distinction points to the need for OHP 1.2 to contain messages such as OpenDocument, GetNode, SaveNode, and CloseDocument. These proposed messages are just examples and this paper will make no attempt at defining the syntax or semantics of these operations. However, the OHS community must seriously consider how it wants to address the notion of composites and whether or not the terms document and node should be considered separate entities. If so, their meanings with respect to OHP 1.2 should be defined along with their associated operations, and the use of these terms should be used consistently throughout the OHP specification.
Resolution. In the new draft of the OHP (OHP 2.0), the terms document and node were given specific definitions. These definitions are the following:
For the purpose of this paper we shall distinguish between nodes and documents. A node is a wrapper object which holds the meta-data about some document (including the information about where to find the file or files which make up that document). A document is that content data which actually appears on the screen in the application program which the user is viewing.
With respect to the operations associated with these concepts, OHP 2.0 defines operations for nodes, not documents, since the management of documents is considered outside the scope of OHP. At OHS 3.5, the interfaces defined for the component-based form of the OHP followed a similar path defining operations for nodes and defining an abstraction called Refs to enable the mapping between nodes and content (with one possible form of content being documents).
Finally in the OHP mailing list, it was recently noted that OHP 1.2 has buried within it the implicit notion of an active document. The article appeared in a thread discussing the use of the GetAnchorTable request. In particular, one implementor stated that the request seemed to need a document identifier although one was not specified. In other words, the client needed to specify for what document an anchor table was desired. The OHP 1.2 specification implies that a GetAnchorTable request should occur after a LaunchDocument request or HeresDocument reply is received. The GetAnchorTable request is then implicitly assumed to refer to the document specified in the previous message. Unfortunately, this assumes that a client can only display one document at a time. Even if this was an acceptable requirement, as discussed in the previous paragraph the active document may be a composite and thus may have separate anchor tables for each component of the composite. Putting aside the issue of composites, it is unrealistic to restrict a client to only one document at a time. Some of the most commonly integrated applications, such as Microsoft Word and Adobe FrameMaker, can open multiple documents at a time and a user would expect to have hypermedia services available from all open documents. Thus, the GetAnchorTable message as currently specified is inadequate for real-world needs and must be modified to handle these issues.
Resolution. This issue was addressed on the OHS mailing list and has been resolved in the OHP 2.0 specification. In particular, the authors admitted that the absence of the parameter to GetAnchorTable was an oversight on their part and it should have indeed appeared in the original OHP specification. In addition, the interfaces defined for the navigational component at OHS 3.5 also address this issue.
3.2.7 Anchor issues
In the original OHS 3.0 workshop paper, only one small issue concerning anchors was
mentioned. The protocol associates a direction with an anchor which can take one of
three values: Start, End, or Bidirect. The
first author noted that it is unclear how this information is actually used by
either a client or OHS. In addition it was noted that an OHS which models links as
sets, in which any anchor of a link can lead to any other anchor of the link, has no
valid value to denote the direction of this kind of anchor. It was recommended that
n-ary should be added as a valid direction in order to support this
class of systems, and the protocol should be modified to specify how this
information is used. However at OHS 3.0, it was questioned why this information is
even needed and it was recommended to delete it from the standard.
Resolution. At OHS 3.5, it was determined that this information should not be stored with an anchor but rather with a link's endpoint. It was also decided to drop the overloaded term anchor and to instead use the term Ref. This paper will not address other issues associated with anchors since these issues are being explored in detail by the work on LocSpecs [24, 26]. This work is examining how these issues are handled in other hypermedia standards such as HyTime [16].
3.3 Scope of the OHP
In several points of the analysis, issues of scope have arisen. In particular, the service-list mechanism described in Section 3.2.1 and the user-interface placeholders described in Section 3.2.2 raise serious questions about the OHP's domain of functionality. The former mechanism has the undesirable side-effect that any service, regardless of domain, may be passed back in a service-list. There is no guarantee that a service-list will contain only hypermedia-related operations and this implies that some OHP clients may evolve to utilize non-hypermedia services provided by a particular OHS and thus lose their ability to interoperate with other OHP-based OHSs. This semantic hole places demands on the OHP (such as the ability to query meta-information about a particular service) which more heavy-weight standards, such as CORBA, have been designed to address. Defining the hypermedia services of the OHP explicitly, removes the problems associated with service-lists and clearly asserts hypermedia as the OHP's domain. In the same fashion, explicitly stating requirements for user-interface issues in the OHP blurs the boundary of the OHP's scope. As much as possible, user-interface details should be left to the participating clients and ignored by the OHP.
At OHS 3.0, two relevant domains of hypermedia-functionality were discussed: collaboration and composites. Collaborative hypermedia allows multiple users to share access to a hyperweb. While this service is extremely important, we recommend that it be addressed in future levels of the OHP protocol. There are two reasons for this recommendation. First, not all OHSs support collaborative hypermedia. If collaboration were included in the first level of the OHP, then these hypermedia systems would be excluded from supporting the OHP even though they could easily provide the more basic hypermedia services. Second, the complexity of the protocol instantly increases once collaboration is considered. Issues of access, group awareness, locking, and ownership become relevant and must be addressed by the specification. A similar argument can be made for the domain of composites [11]: not all OHSs provide support for composites and additional issues such as support for compound documents and new types of links (inter- and intra-composite) must be addressed. The least common denominator problem (trying to accommodate the common functionality of all systems at the expense of more sophisticated features) can eventually be avoided by placing more complex services in higher levels of the protocol while more basic services appear in the lower levels. This allows each OHS to support some subset of the OHP, and gain the benefits of client-interoperability.
The goal of the OHP is to enable client interoperability over a set of open hypermedia systems. In particular, the hypermedia functionality of a client should remain the same regardless of the OHS servicing its requests. This goal will help to reduce the effort of creating OHS clients, since once a client has been made OHP compliant, the rest of the community can use the client with their particular OHS (as long as they have a machine which meets the client's platform requirements). With this goal in mind, we recommend that the OHP focus on providing a core set of hypermedia services to its clients and ignore all other issues (within reason) until the goal has been achieved. To be specific, we recommend providing a client with the ability to create, delete, and edit anchors and links, and to be able to initiate and receive link traversals. Only these operations should be provided in level 1 of the protocol. This, in turn, implies that new requests to invoke these operations and new replies to return the results of these operations must be specified in the OHP specification. Later versions of the protocol can include support for additional hypermedia services such as collaboration, composites, improved support for scripting, overviews, search and query, and visualization. We feel it is more important to focus on the essence of hypermedia first. This narrow focus will also help the community produce a complete specification and implementation of the OHP more quickly. Once the first level of the OHP is complete, the community can turn to more complex issues, such as collaboration and composites, with a more realistic notion of the work involved in producing a useful specification and the associated robust implementation.
Resolution. As indicated in the resolution of Section 3.2.1, the work performed at OHS 3.5 has adequately addressed the issues raised in this section. In particular, the use of a component technology enables the domains addressed by the OHP to be encapsulated within specific components. Compatibility between clients and servers can then be checked by examining the component interfaces that each supports. New services can be added incrementally to the OHP by the specification and creation of new components. The first domain addressed by the OHS working group at OHS 3.5 was hypermedia navigation, which satisfies the recommendation made above to focus on core hypermedia services.
4 Conclusions
OHP 1.2 is an excellent start towards the goal of enabling interoperability between clients and OHSs. This paper has examined the current status of the OHP 1.2 specification and has raised issues and problems which now need to be addressed by the community. The most serious issue raised is the semantic loophole left by the current definition of services in OHP 1.2. We have argued that the OHP should adopt the approach of explicitly defining the hypermedia services of the OHP.
It should be noted that a well-specified protocol does not stifle the growth of the protocol as long as extensibility mechanisms are included in the specification. Currently the OHP includes the Other tag which enables extensibility. A useful service which is introduced via this mechanism can be slated for later inclusion in a new version of the OHP. While the Other tag seems sufficient, it may be beneficial for the community to examine the extensibility mechanisms utilized by other protocols such as HTTP [6]. HTTP attacks the issue of extensibility on several fronts, including ruling that unknown header fields can be ignored, specifying the behavior of proxies and servers when encountering an unknown method, utilizing data types (such as URLs) which are themselves extensible, and allowing the values of some fields to be open-ended.
An additional issue facing the OHS community is determining when the OHP specification is complete. While the initial rationale for the development of the protocol was to foster interoperability between open hypermedia clients and servers, the exact set of services which should be interoperable was never determined. This, combined with the unspecified nature of the services makes it impossible to determine when the OHP is complete. At OHS 3.0, work began on the development of a requirements document for the OHP, and discussion of requirements has since taken place on the community mailing list. We recommend that efforts to write the requirements document become a principle focus of OHP development until the requirements are mostly stable. If there is no agreement on the functionality to be provided by the protocol, there cannot possibly be agreement on the protocol itself. We have stated our recommendations for the hypermedia functionality that level 1 should provide. We hope these suggestions can help to focus the development of the OHP requirements document. Once this requirements document is complete, it can then be used to evaluate the OHP specification by tracing requirements to elements of the protocol.
One crucial element for success is the participation of the entire OHS community in the protocol development process. OHP 1.2 includes features to accommodate for the differences between the various OHSs present in the community. In order to include standard mechanisms for core hypermedia services within the OHP, the protocol elements which are added must be general enough to support the different styles of link and anchor creation used in OHSs. For instance, Chimera (as well as other OHSs) uses the notion of an active link to facilitate link creation. That is, users create a new empty link in a Chimera link editor. They select it to make it the active link. This link is then shared between all of the user's active clients, allowing the user to add anchors to the active link from any client. This style of link creation is markedly different from the style used by Microcosm. However it must be possible to accommodate both styles, and others, in order for the OHP to be successful. This requires community participation. Another recommendation, therefore, is that the OHS community commit to responding to the issues raised here and produce a new version of the proposed standard in a very timely manner. Subsequently, reference implementations of the standard should be implemented and tested to provide feedback for future revisions.
Postscript. With the advent of OHP 2.0 and the results of the OHS 3.5 workshop, the status of the OHP has significantly evolved. The adoption of a component technology approach to specifying and implementing the OHP has addressed many of the concerns raised in this conclusion. In particular, one notion of extensibility, the provision of new services, is handled by defining and implementing new components for the OHP. The OHS 3.5 workshop also identified a small set of subgroups which are working on issues to enable the implementation of the first version of OHP. Finally, all participants of the OHS 3.5 workshop felt that the meeting was highly productive and demonstrates a high degree of participation and a willingness to come to consensus by the open hypermedia community.