OHP - Communicating between Hypermedia Aware Applications

    Hugh C Davis, 
    David Millard, Sigi Reich
    Multicosm Ltd
    Multimedia Research Group 
    Chilworth Research Centre
    Department of Electronics & Computer Science
    Southampton, UK
    University of Southampton, UK 
    hcd@multicosm.com
    {dem97r, sr}@ecs.soton.ac.uk 
 

Abstract

A number of systems support hypertext functionality by storing links in link services; these links may then be superimposed on, or included into the document by the client browser. However, there is no standard protocol that allows client side tools to interoperate with link servers. The Open Hypermedia Systems (OHS) Community is therefore proposing a standard protocol called the Open Hypermedia Protocol (OHP) for client side applications to communicate with link servers for the purpose of storing, retrieving and navigating hypermedia objects.  Adoption of this protocol would enable developers and researchers to re-use standard viewers including Web browsers and link servers within their systems.

Keywords:  Open Hypermedia Protocol, linkservice, interoperability.

1. History and Motivation for OHP

Hypermedia systems have been around for a long time. Some of them support only simple point to point links, some implement more advanced hypertext functionality such as generic links in Microcosm (Davis et al., 1992). The Open Hypermedia Systems (OHS) community has conducted research towards the development of a standardized protocol that would allow different clients to communicate and therefore inter-operate with hypermedia link servers. Such a lightweight protocol was first proposed at the workshop of open hypermedia systems in Edinburgh at ECHT'94 (OHS 1).

Currently there are a small number of experimental and commercial link servers and most of these use their own protocol for communicating between the clients and the link service. As a result every link service developer has needed to either write from scratch or adapt their own viewers (browsers) for each data format. One of the aims of the OHS community has been to support hypertext in all applications and data types, so the need to write such viewers is a step in the wrong direction.

The OHS community hoped that if they could agree a standard protocol then they would be able to start experimenting with interoperability between link servers and reduce the overhead of re-implementing viewers. It was intended that this protocol would be simple enough that a third party application such as Word for Windows or a Web browser could be simply adapted using the built in macro programming facilities. Client applications, once adapted to use such an open hypertext protocol (OHP), could be re-used with all link services; and link services, once adapted to communicate using OHP would be accessible to third party viewers. In this respect it is hoped that OHP will play a similar role as has http in establishing open standards for interoperability. A first draft of such an open hypertext protocol (OHP, Davis et al., 1996) was presented at Hypertext '96, and two subsequent meetings of a working group have refined and altered the protocol significantly (see Section "References" for further information on drafts).

OHP is about storing, retrieving and navigating hypermedia objects. Therefore, the protocol focuses on the structure, i.e. the links between objects rather than the objects themselves. As a consequence, OHP does not deal with actual document retrieval (e.g. an instance of a HTML document) but is instead used for storing and retrieving the information that defines the structure of objects and the links between those objects.

In the reminder of this paper we will briefly introduce the data model underlying OHP, we will describe the assumption made on the architecture and we will describe the relationship to related efforts such as PEP and XLL
 

2. A General Hypermedia Data Model

The hypertext community has invested much time and effort in attempting to define hypermedia, and probably the most successful result is the Dexter model (Halasz & Mayer, 1994, Grønbæk & Trigg, 1996). In this section we briefly define the terminology and model that is assumed by OHP. Note, that the complete data model will appear more complex than that of many existing systems, but it will not always be necessary to expose the user to this complexity. The model must be capable of including all previous models of hypertext.

The model of hypertext assumed by OHP consists of dedicated link servers which hold links, endpoints, references and nodes. Each of these objects have unique identifiers within the system. Servers which manage these objects are known as link servers.

A link is a hypermedia object which represents a connection between zero or many endpoints. A link may (or may not) have a type attribute (e.g. "defines"). Traversing a link may move the user's focus to another page; it may as well cause some process to run. For example Figure 1 shows two links, one of which has three endpoints and type "defines", and the other of which has two endpoints and type "supports".
Currently there are a small number of experimental and commercial link servers and most of these use their own protocol for communicating between the clients and the link service. As a result every link service developer has needed to either write from scratch or adapt their own viewers (browsers) for each data format. One of the aims of the OHS community has been to support hypertext in all applications and data types, so the need to write such viewers is a step in the wrong direction.

Figure 1: Example of Data Model.

An endpoint is an object which holds the attributes of the end of a link. Typically an endpoint will hold a traversable direction which might be source, destination or bi-directional. For example, in Figure 1, the link "defines" may be traversed from EP0 to EP1 and EP2, and it may be traversed from EP2 to EP1, but it will not be possible to traverse this link from EP1.

A dataRef defines the node and the point within that node at which the application which shows the data, i.e. the browser or editor should indicate some kind of persistent selection which will be a hypertext "hotspot". We have deliberately avoided the use of the words "anchor" and "button" as these terms have been somewhat overloaded in the past. For instance in Web terminology dataRef DR1 in Figure 1 might simply be a string such as "http://www7.conf.au/workshop.html#wlist". In general, a dataRef consists of a node specification and a location specifier or locspec. A dataRef may be associated with zero or more endpoints. For example, a user may make a number of dataRefs before associating any of them with any endpoint of any link. Also, one dataRef might refer to more than one endpoint, and these endpoints might belong to different links. For example dataRef DR0 in Figure 1 is associated with both EP2 and EP3.

A nodeSpec will resolve to one or more node identifiers (nodeID's) which will each uniquely identify one node, e.g. a URL identifying an HTML document in the World-wide Web.

There are some more definitions that form part of OHP such as location specification, presentation specification or scripts. We refer to the current version of the protocol for further details (http://www.ecs.soton.ac.uk/~hcd/ohp/ohp35.htm).

3. Architecture Issues

Addressing interoperability not only requires some common understanding of the data model; but also requires some consensus on the underlying architecture. This is because the data model usually makes assumptions about the architecture and because functionality and behavior are to a large extent based on the architecture. The Open Hypermedia Systems Community has therefore undertaken research on a reference architecture for hypermedia systems (Goose et al., 1997, Grønbæk & Wiil, 1997, Wiil & Whitehead, 1997).

There is a problem that impedes the simplicity of a model which has the application program communicating directly with the link server. In practice all those who have implemented link servers have identified the need for some component on the client side which is present throughout the hypertext session. (Goose et al., 1997) call it the "Runtime", (Wiil & Leggett, 1996) call it the "Tool Integrator" and in the original version of OHP (Davis et al., 1996) it was called the "Communication Protocol Shim". However, we prefer, now, to call it the CSF. (This acronym might be said to stand for "Client Side Functions"; actually it originally stood for "Client Side Foo", which was the "stub" name adopted by the group in order to prevent any further argument about the name). Figure 2 gives a graphical representation.

The responsibilities of the CSF will always include starting an application (with its data) when required to by the link server (e.g. as the result of traversing a link to a document which must be handled by some application which is not currently running). This function is necessary as in heterogeneous systems it is not always possible for a server application to autonomously start a client process on a remote machine. This mechanism can be compared to launching external programs from within a Web browser.

There are many other tasks that might need to be carried out on the client side, such as

For the above reasons we believe that it is necessary that some of the communications between client side applications and link servers are routed through the CSF. The exact routing of the messages is irrelevant from the point of view of the link server, which simply receives the messages and sends replies. However, if we want to allow third party viewers to plug in to a CSF, there will need to be some standardization so that the viewer can know which services to expect the CSF to provide. For example some systems may allow the CSF to intercept and handle all requests to produce content so that they can proxy for the document management system. The CSF might be seen as analogous to a plug-in architecture for a browser that supports no data formats itself. In practice, as explained above, the CSF must perform a number tasks, and might consist of a number of components designed to implement each task.
Fig. 2: Current OHP Architecture.

Figure 2 gives an example of the kind of architecture we are assuming. In this figure there are two client side applications. One is a the Amaya Web browser, which has been adapted as an OHP aware viewer, and one is a special purpose picture viewer which was written to work with OHP. Both these communicate with the link servers via the CSF using the OHP protocol. One of the servers is a native OHP server, whereas the other might be a DHM (DeVise Hypermedia) server, and a shim has been inserted in order to convert the OHP protocol to the DHM native protocol.
 

4. Related Efforts: Relationship to WebDAV, PEP and XLL

OHP aims at being a 'real world' protocol that is actually being used - the definition itself attempts to be abstract. This means that although the semantics of OHP might be expressed using ASCII strings and although there might be implementations using strings streamed over simple socket connections there is no pre-defined way of implementing and communicating OHP. Therefore, a number of possible technologies including CORBA, DCOM and Java's RMI have been  investigated by the Open Hypermedia Systems Working Group (see e.g. http://www.csdl.tamu.edu/ohs/tech/framework/).

A Web implementation of OHP might very well use Web technology such as the Protocol Extension Protocol (PEP, Nielsen et al., 1997) for communicating OHP semantics via HTTP. The World Wide Web Distributed Authoring and Versioning group (WebDAV, Whitehead, 1997) has worked already in a similar direction and has done sample implementations of WebDAV using PEP (http://www.w3.org/TR/WD-http-pep). It should be noted however, that although PEP is a standardized extension, this does not mean that if OHP is implemented using PEP that OHP is a standard.

The eXtensible Linking Language (XLL, Bray & DeRose, 1997) is a W3C working draft that specifies how links between objects might be inserted into XML documents. XLL links will be more sophisticated than today's HTML linking mechanism by providing multi-ended or typed links, by allowing different presentation and behavior of links, and the more.

XLL is based on the idea of elements. So if a word is not an element, then there is no possibility of using it. This makes implementing some more advanced hypermedia features difficult, e.g. generic links in microcosm. XML and XLL will offer some of the linking functionality that open hypermedia systems already provide. However, XLL does not support generic links, different linkbases might be difficult and there is - without WebDAV - no notion of editing.

5. Summary, Status and Conclusion

This paper has introduced OHP, the Open Hypermedia Protocol that is being proposed by the Open Hypermedia Systems Working Group as a standardized protocol for navigating, retrieving and storing structural information of multimedia documents. We have shown the underlying data model as well as the assumptions we made on the architecture. And we have described how we believe that OHP will be embedded within the world of the WWW.

The work on the OHP protocol has so far been largely a "paper-based" exercise. Two simple prototypes of the original protocol were built on top of existing open hypermedia systems. However, the protocol has been much expanded in both size and functionality since these prototypes. Therefore, based on a common effort of four research groups within the open hypermedia systems community prototypical implementations of OHP using Java's RMI and TCP/IP as a communication mechanism are currently under work. The aim is to demonstrate interoperability between different client systems and open hypermedia systems using OHP as a communication protocol.

The current version of the protocol makes a first stab at a definition of location specifications that are based on ideas of the HyTime standard (HyTime, 1992). However, as mentioned above, the Web community is currently making an investment in this area (as well as in presentation specifications) through the XML/XLL working groups. Without agreement on how to treat the opaques within the current proposal, we will not be able to interoperate. There is much work that can be done in this area, and such work must ensure interoperability with emerging Web standards.

Currently the Web does not treat links as first class objects, making it very difficult to implement some of the more advanced functionality that hypermedia offers (e.g. generic links). It also has no concept of state, which prevents co-operative editing in a distributed system. OHP is an attempt to address these concerns. It suggests an architecture where the browser is no longer a nexus for Internet communication. Instead all applications will be OHP aware, with the CSF eventually integrating fully with the operating system, finally providing an open environment where all applications are equal.

Acknowledgments

We would like to acknowledge the contribution of all the members of the open hypermedia systems working group (see http://www.csdl.tamu.edu/ohs/app/people.html). The work of Sigi Reich has been supported by the Austrian Fonds zur Förderung der wissenschaftlichen Forschung (FWF, grant No. J1507-INF).

References

The home page of the Open Hypermedia Systems Working Group can be found at http://www.csdl.tamu.edu/ohs/.
The latest version of the Open Hypermedia Protocol (OHP) is available from http://www.ecs.soton.ac.uk/~hcd/ohp/ohp35.htm.

Bray, T. & DeRose, S. Extensible Markup Language (XML): Part 2. Linking. W3C Working Draft. Available as http://www.w3.org/TR/WD-xml-link. 1997

Davis, H.C., Hall, W., Heath, I., Hill, G. & Wilkins, R. Towards an Integrated Information
Environment with Open Hypermedia Systems. In: D. Lucarella, J. Nanard, M. Nanard, P.
Paolini, eds. The Proceedings of the ACM Conference on Hypertext, ECHT '92 Milano, pp 181-190. ACM Press, 1992.

Davis, H., Lewis, A. & Rizk, A. OHP: A Draft Proposal for a Standard Open Hypermedia Protocol (Levels 0 and 1: Revision 1.2 - 13th March. 1996). 2nd Workshop on Open Hypermedia Systems, Washington, March 1996. Available as http://www.ecs.soton.ac.uk/~hcd/protweb.htm.

Goose, S., Lewis, A. & Davis, H. OHRA: Towards an Open Hypermedia Reference Architecture and a Migration Path for Existing Systems. In JoDI - Journal of Digital Information, Special Issue on Open Hypermedia. 1997.

Grønbæk, K. & Trigg, R.H. Toward a Dexter-based model for open hypermedia: Unifying embedded references and link objects. In: The Proceedings of Hypertext '96. ACM 1996, Washington D.C. 1996.

Grønbæk, K. & Wiil, U.K. Towards a Reference Architecture for Open Hypermedia. Proceedings of the 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997.

Halasz, F. & Mayer, S. (edited by Grønbæk, K. & Trigg, R.H). The Dexter Hypertext Reference Model.
Communications of the ACM. pp. 30-39. 37(2). Feb. 1994.

ISO - International Organization for Standardization Information Technology - Hypermedia/Time-based Structuring Language (HyTime), ISO/IEC 10744, 1992.

Nielsen, H. F., Connolly, D., Khare, R., and Prud'hommeaux, E. PEP - an extension mechanism for HTTP. W3C working draft 21 november 1997. Tech. rep., World-wide Web Consortium (W3C) Report number WD-http-pep-971121, Nov. 1997.

Whitehead, J. E. World wide web distributed authoring and versioning (WEBDAV): An introduction. ACM StandardView 5, 1 (Mar. 1997), 3-8.

Wiil, U.K. & Leggett, J. The HyperDisco Approach to Open Hypermedia Systems. In: The Proceedings of the ACM Conference on Hypertext '96, Washington D.C., pp. 140-148. ACM Press. March 1996.

Wiil, U. K., and Østerbye, K. (eds.). Proceedings of the ECHT '94 Workshop on Open Hypermedia Systems, (Edinburgh, Scotland, September 1994).

Wiil, U.K. & Whitehead, J.E. Interoperability and Open Hypermedia Systems. Proceedings of the 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997.