Hugh Davis, Andy Lewis
The Multimedia Research Group
Electronics and Computer Science
The University of Southampton
Southampton
UK, SO17 1BJ
email hcd@ecs.soton.ac.uk, ajl@ecs.soton.ac.uk

Antoine Rizk
Euroclid
email Antoine.Rizk@inria.fr

Abstract

This paper describes a proposal for a protocol known as OHP, for communication between applications and hypermedia link services. If hypermedia viewers were written to use this protocol, or third party applications were adapted to use the protocol, then these applications could be used with any link service which adhered to the protocol. The paper proposes the use of shims for converting between the OHP protocol and the linkservice's native protocol.

1. Introduction

In order to introduce this paper we would first like to define what we mean by "open" when referring to hypermedia systems. A number of authors (Davis et al., 1992 ; Østerbye, 1996 ) and workshops ( Aßfalg, 1994 ) ( Wiil & Østerbye, 1994 ), have attempted to define the term "open hypermedia", and we believe that the following is a reasonable summary of current thinking.

The term open implies the possibility of importing new objects into a system. A truly open hypermedia system should be open with regard to:

Size: It should be possible to import new nodes, links, anchors and other hypermedia objects of any limitation, to the size of the objects or to the maximum number of such objects that the system may contain, being imposed by the hypermedia system.

Data Formats: The system should allow the import and use of any data format, including temporal media.

Applications: The system should allow any application to access the link service in order to participate in the hypermedia functionality.

Data Models: The hypermedia system should not impose a single view of what constitutes a hypermedia data model, but should be configurable and extensible so that new hypermedia data models may be incorporated. It should thus be possible to interoperate with external hypermedia systems, and to exchange data with external systems.

Platforms: It should be possible to implement the system on multiple distributed platforms.

Users: The system must support multiple users, and allow each user to maintain their own private view of the objects in the system.

In this paper we are concerned with enabling applications to make them link service aware, so that users may have access to the full range of hypermedia functionality from their standard desktop environment. Many of the current generation of hypermedia systems such as DHM (Grønbæk & Trigg, 1992 ) HyperDisco ( Wiil, 1996 ), Microcosm ( Davis et al., 1994 ), Multicard ( Rizk & Sauter, 1992 ) and the Texas A&M system prototypes (e.g. Kacmar & Leggett ) have addressed this problem, but so far no standard has emerged due to the different hypertext data models and communication protocols adopted by these systems.

Unfortunately, linkservice protocols tend to be kept confidential, and are anyway too detailed to form the topic of published papers. However, we have now seen the results of sufficient research in this subject to be able to identify the common themes, and hopefully to abstract the common requirements. This first draft of this protocol leans heavily upon the M2000 protocol (Rizk, 1991 ) developed for use with Multicard, and the Microcosm message model. It is a first attempt at such a standard protocol, and no doubt it will need adapting and will evolve as system designers attempt to map their systems onto the protocol.

We should emphasise at this point that all this protocol attempts to provide is a standard method for applications, such as word processors, graphics viewers and drawing programs, to communicate with a link service so that they may offer hypermedia services to their users. This protocol is not an attempt to produce a complete standard for all inter-component communication, such as would be required for the link service to communicate with agents and other service providing components.

2. The Protocol Shim

In general, open hypermedia systems tend to implement a link service layer which provides the storage and access mechanism for links and anchors. The Dexter reference model ( Halasz & Mayer, 1994 ) refers to this as the storage layer . Some systems call this layer a hyperbase ; such systems usually store not only the links and anchors, but also the nodes in this layer. The distinctions between the different types of system are ill defined, and anyway not the subject of this paper. The thing that all such systems have in common is that the application layer (or runtime layer) is physically separate from the storage layer, and that there is some system of message passing between the two, which allows the applications (editors, viewers) to send and receive messages and query the link service concerning hypertext services.

All systems designers have developed their own private protocols for communicating with the link service, and these protocols are so deeply buried into the system code that in general it would involve a major re- implementation to rewrite the system to adhere to some new, standard protocol. However, the topics of these communication are essentially similar and it should quite possible to abstract a common set of messages. We suggest that the difference between different system protocols could be resolved if each system produced a protocol shim which would sit between the application and the link service as shown in figure 1.

Figure 1: Protocol conversion using a protocol shim.

The advantages of this scheme are:

Once an application (for example a word processor) had been adapted to communicate using the standard protocol (for example, using an application macro language) , then it would be possible to circulate the code extensions or macros so that any system would be able to benefit from this "hypertext aware" application.

Each system developer need develop just one extension to their system (the protocol shim itself)

Applications that have been developed specifically as hypermedia viewer/editors could be used in other systems, so long as they observed the protocols.

The problem with this approach is that some hypermedia systems have much heavier weight requirements on their protocols than others. However many developers have recently acknowledged that it is necessary to accept the concept of "levels of awareness" (e.g. Davis et al., 1994 , Wiil, 1996 ), and that it will not always be possible or reasonable to expect the highest level of hypertext functionality from every third party application. Reflecting these pragmatic observations we propose that the OHP protocol will have a number of levels of conformity, and it would thus be possible to describe a given application as OHP aware to some given level.

3. Anchors

One of the major differences between hypertext implementations is the way that anchors have been treated (Davis, 1995 ). The issues, from the point of view of hypertext enabling third party applications, are:

where anchors are stored;

how new anchors are allocated;

how the anchor refers to the object within the node data that is to be the physical manifestation of that anchor.

Questions about the behaviour of anchors (are anchors actually processes, and what happens when an anchor is activated?) are not of interest in this context, as they are dealt with within the link service rather than within the application. For the purposes of this discussion we will follow Leggett & Schnase's (1994 ) distinction between an anchor (a hypertext object which describes one or other end of a link) and a persistent selection (that object within the node data which is the physical manifestation of the link anchor, such as a coloured text string).

Probably the most generic description of the anchor is provided by Grønbæk & Trigg (1996) , in which an anchor is described as a binding between a component identifier and a location specifier (LocSpec). A LocSpec contains the details which describe a persistent selection, and the semantics of these details are decided by the application at the time that the anchor is created and resolved using the same algorithm when the anchor is loaded again at a later time. A similar generalisation of the nature of these details comes from the HyTime standard(DeRose & Durand, 1994) which allows that anchors might reference objects within the node using:

counting: e.g. "the string at bytes 1023-1043 through the file", "the 8th line of the 12th paragraph", "the rectangle of dimensions (45,20) pixels at co-ordinates (1427,2393) in the bitmap", etc.;

naming : e.g. "the bookmark called 'MyBookmark' ", "the spreadsheet cell range called 'Total' ", "the drawing object named 'GasMain4' ", "the section of a text named 'Conclusions' ", etc.;

searching: e.g. "the first occurrence in the file of the string 'Xanadu' ", "the record in a database that results from this SQL query", etc.

HyTime also allows that references might be made of combinations of these methods, e.g. "The first occurrence of the string 'Xanadu' in the 5th paragraph of the chapter named 'history' ".

Different systems allocate anchors in different ways. There are four principle methods:

The application embeds the anchor in the node data. In this case the application may also embed all the link information at this point (e.g. URL's embedded in html as HREF's) or might allocate an ID to the anchor which is unique to this node, and which will specify to the link service the link or links in which the anchor participates, as in Hyper-G (Andrews et al., 1995 ).

The application allocates an ID for the anchor, which will be unique for that node, and takes responsibility for maintaining a table of IDs and LocSpecs belonging to the node. The link service can resolve an anchor by using the (node name, anchor ID) pair. This is the approach taken by most Dexter based systems such as DHM.

The application requests that the link service allocates an ID for the anchor, which will be unique over the entire link service. The application will still need to maintain a table of anchor IDs and LocSpecs at run time. This approach is taken by Multicard and the hyperbase class of systems.

The application talks to the linkservice by transmitting the node identifier and LocSpec, and allocates no specific anchor ID at all. This is the approach taken by Microcosm.

In designing our protocol, we must produce a standard which allows existing and future hypermedia systems to participate, regardless of the method they use to represent anchors or LocSpecs or the way that they allocate and store anchors.

So far, the discussion of anchors has assumed that all anchors will be represented by some persistent selection or button within the node data when the data is displayed. Hypertext links are invoked by clicking on the button. This traditional interface to hypermedia is well established, but has limitations that are discussed in Hall (1994) . An alternative interface to hypermedia is the "selection and action" metaphor which has been pioneered in Microcosm, which enables the user to make dynamic queries of the system, for example by selecting some text string and asking the system to compute links using some dynamic information retrieval algorithm. The protocols will need to support this form of hypertext interaction.

4. Communication Protocols

The question of the choice of communication protocol is interesting. The communication is clearly peer-to-peer in the sense that either the shim or the node viewer might initiate a message. We could agree that any suitable method could be used (e.g. DDE on Windows, AppleEvents on the Mac, RPC on Unix), but this approach has problems:

applications that have been enabled for one communication protocol will only be transferable to other systems if that other system has a shim using that protocol.

it would be preferable to build shims that will allow clients on one machine architecture to communicate with link services on other architectures.

For these reasons it makes sense to separate the choice of communication protocol from the hypertext protocol, as shown in figure 2. In this configuration, the application developer produces a communication shim to run on the client side. This shim understands the application protocol (e.g. DDE) and converts it to whatever network protocol is required (e.g. sockets). As we shall see later, this shim needs to be more than just a communication protocol converter, and is required to have some hypertext functionality. The linkservice developer produces the protocol shim, which runs on the same platform as the linkservice, and accepts incoming messages in whatever network protocols are supported.

Figure 2: Communication Protocol Conversion

5. Defining the OHP Protocol

5.1. LocSpecs

The difficulty in defining a standard LocSpec is that if it is to be sufficiently flexible to meet all possible ways of expressing positions in a document as intended by the HyTime standard (see section 3 ) then it will be difficult to parse and thus put considerable onus on the application. Instead we suggest the following simplification, at least for the purpose of getting the standard started. We expect that it will evolve.

LocSpec ::=

{\ContentType MimeType
\Content Mime encoded text string
\Count [Comma separated list of numbers]
\ReverseCount [Comma separated list of numbers]
\Name [Mime encoded text string]
\Script [Viewer Executable Script] }

The important thing to realise about the LocSpec is that although the link service may be required to store this information, it is not usually required to interpret the information in any way. The semantics of the various fields within the LocSpec are decided by the viewer at the time that it creates the LocSpec, and then stored in the linkservice for later retrieval and interpretation by the same viewer. Thus different viewers are not required to keep to any particular convention for representing these fields.

The one exception to the above rule is the content. Some hypermedia systems store the content of the anchors within the linkservice, and use this information as the basis for providing services. For example, Microcosm searches its linkbases for links authored on particular content in order to provide generic links. For this reason, this part of the LocSpec is not optional. The protocol requires that the LocSpec contains at least one method for the viewer to store information about the position of an anchor. However, it is strongly recommended that application developers try to fill as many of these fields as possible. The reasons for this recommendation are that:

some link services may attempt to search their databases for anchors that have particular attributes;

extra information is generally useful if it becomes necessary to mend the position of the anchor after a document has been edited by an editor that was not linkservice aware.

The comma separated list of numbers used in the count and reverse count will depend on the method used by the viewer to represent positions in documents, e.g. 3, 2, 5, 423 might be used by a structured document to mean the 423rd character in the 5th paragraph of section 3.2. Alternatively it might represent the top left and bottom right co-ordinates of a rectangle in a bitmap.

The reverse offset allows us to represent a position by counting from the end of a document. This overloading can be useful when trying to fix LocSpecs that have become broken due to document editing.

The name may be any object understood by the viewer which is unique to the current document, such as a bookmark name or a drawing object.

The script is a set of instructions which may be interpreted by the application which will enable the application to locate the object.

5.2. Presentation Specifics

Many systems incorporate the possibility of displaying persistent selections in different ways. For example, persistent selections in text might be coloured blue, or some other colour, and areas of bitmaps might be shaded, raised or outlined; some systems support buttons that are not shown, or are only shown when the pointer is over them. In general this is a user choice, and it applies to all the persistent selections in the view, so may be a setting on the viewer that is completely independent of the link service.

However, there are cases where an author may wish particular persistent selections to show in some way that is different from others. In this case it is possible for the viewer to allow the specification of some particular presentation of the selection, and to store this along with the LocSpec, so that when it is viewed later, it will have the desired appearance. If this were the only requirement, the syntax and semantics of the presentation specifier would belong only to the viewer.

Unfortunately, there are many cases where the link service may wish, as the result of some script, to change the presentation, and the linkservice will not know the presentation unless it is part of the standard.

For the purpose of this version of the protocol we suggest that the information about presentation is kept viewer specific. i.e. the viewer may ask to store any presentation information in any form that it chooses, and the viewer will interpret this data at a later stage when asked to present the data again.

The consequence of this policy will be that link services will not be able to communicate to the viewer that it should change any presentation (e.g. as the result of a script) since it will not know the syntax of the presentation tag for this particular viewer. Later versions of the protocol should standardise the form of this information, e.g. by defining the data as {colour, style, visibility} and giving a set of values and meanings to each of these parameters.

5.3. Scripts

Scripts play an important part in some hypermedia systems (e.g. Hypercard and Multicard) , and are hardly used in others. Scripts may be classified into two types:

Server End Scripts. These are the scripts that are carried out when some particular event occurs or some action is requested. From the point of view of the viewer there is no difference between some process being run or a link being followed by the linkserver. Of course, these scripts may cause new messages to be sent back to the viewer, to change its presentation in some way.

Client End Scripts. These are scripts that are sent to the viewer by the linkserver. In general they are either sent as part of a LocSpec in order to identify an anchor, or they are sent as a process which the viewer will be expected to run, for example in order to change the presentation of the data in some way. OHP must provide support for such scripts if the viewer wishes to use them.

5.4. Communication Channels

It is quite possible that one communication shim may need to maintain communication with more than one application on a client machine, and also quite possible that one application might be concurrently displaying more than one node (e.g. an MDI application in Windows). Similarly, one link server (and protocol shim) may need to maintain communication with more than one client. For this reason it is necessary that messages contain routing information, so that messages sent by the link service are sent to the correct node in the correct application on the correct machine. However, from the point of view of the application developer, it is not necessary to know anything about the content of the routing information. The link service will provide the information to the application, and the application will be responsible for returning this information every time it sends a message to the link service, so that the link service can identify where to reply. This information is known in the protocol as the Channel .

Since the linkservice will maintain a unique channel to each document that is currently connected, it will not be necessary for most of the messages to pass the document name, as this is implicit in the channel. However, there would be nothing to prevent the linkservice explicitly using the document name as part of the channel information.

5.5. Form of the Protocol

OHP is a peer to peer asynchronous protocol. Messages may be sent by either the link service or by the editor / viewer, and no message waits for any form of reply. If a reply is expected, it is up to the receiving component to initiate a new message. There are thus two classes of message to be considered; those sent by the viewer and those sent by the link service.

Messages that the viewer may send will depend largely on the set of services that can be handled by the link server. It therefore makes sense that part of the protocol will allow the definition of the subjects which the link server can handle. These subjects do not need to be known in advance.

On the other hand, the messages which the link server may send to the viewer must be defined in advance, since the viewer must be coded to deal with these messages.

OHP messages will consist of text strings. In the following sections the messages are shown formatted on multiple lines for ease of presentation. However, the messages themselves will be one continuous stream of ASCII text, unbroken by line breaks. The messages consist of Tags, which are proceeded by a backslash ('') and succeeded by a space. The characters that follow, up to the next tag or the end of the message are the tag contents. A tag content may be empty if shown as optional in the message definition. The tags of each message are all compulsory, and must be presented in the order in the message definition. If a backslash ('') or closing curly bracket ('{' or '}') occurs within the tag content, then it should be quoted by preceding it with a further backslash. The bold '+ ' is used in the following descriptions to indicate that one or more of the line indicated may be included at this point.

We can now begin to define the protocol.

5.6. Messages that the linkserver may send

5.6.1. HeresServices


\Subject HeresServices
\Data {\Menuitem Menuitem \Service Service } +
\Channel Channel

Which will define the menu that will be placed on the viewer, and the set of services that will be requested from the link service when such items are selected from the menu.

For example, a Microcosm link server would typically send the following:

\Subject HeresServices
\Data {\Menuitem Follow Link\Service FOLLOW.LINK}
\Data {\Menuitem Show Links\Service SHOW.LINKS}
\Data {\Menuitem Compute Links\Service COMPUTE.LINKS} \Data {\Menuitem Make Start Anchor\Service START.LINK} \Data {\Menuitem Make End Anchor\Service END.LINK} \Channel #9

5.6.2. LaunchDocument


\Subject LaunchDocument
\DocumentName DocName
\ReadOnly True/False
\DocumentNickName [DocNickName]
\DocumentType MimeType
\DataCallBack True or False 
\Channel Channel

This message introduces a special problem. At the time that it is sent there may be no viewer open to receive the message! 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. It is necessary that there is some component at the client end to receive this message that can arrange to fire up the appropriate viewer. We suggest that this functionality should be added to the communication protocol shim, which is anyway at the client end. The shim will need to know which viewer to load, depending upon the mime type of the data. The viewer, when it has been launched will receive this message will be responsible for storing the channel information and using it whenever sending messages back to the linkservice.

A further problem is introduced by the fact that some systems would expect the client viewer to now arrange to fetch its own data (using the document name to describe a file on the file system or a remote server) whereas other systems might expect that the data will be held within the linkservice (hyperbase). The DataCallback tag, allows the linkservice to indicate that it wishes the viewer to send a message back asking for the data, and if such a call-back occurs it will answer with a HeresDocument message. If the call-back is false the linkservice will expect the viewer to arrange to load its own data.

It is also a useful point to introduce the idea of levels of the protocol. Many linkservices allow third party applications to participate in the hypertext, in so far as they may be launched and run with given node data, and they may be closed. This is the functionality that is supported by OHP Level 0. In this case the will be expected to handle messages to open the node (LaunchDocument) and close the node (CloseNode). The application itself is not expected to deliver and hypermedia functionality. All other messages in this document are part of the Level 1 Protocol. Level 2 of the protocol is not yet defined, but is discussed in the section 8. The client end communication shim is responsible for knowing the level of the applications it launches so that it does not attempt to send messages to non-communicating applications, but instead returns error messages. In this respect the shim acts as a proxy for the application.

The ReadOnly Tag enables the link service to inform the viewer that it should not allow the user to edit the node contents.

The DocumentNickName allows for the case where the linkservice may supply better descriptions of the document than the filename alone, and the viewer may elect to display this name somewhere, typically in the title bar.

5.6.3. HeresDocument

This message is sent by the linkservice if it has received a call-back asking the linkservice to supply the document data.

\Subject HeresDocument
\Data Mime Encoded Data
\Channel Channel

5.6.4. HeresAnchorTable

After a document is launched the viewer may request the anchor table. This linkservice will reply with this message.

\Subject HeresAnchorTable
\Data {\AnchorID AnchorID
  \LocSpec LocSpec
  \Direction Start/End/Bidirect
  \Presentation colour,style,display
  \Service Service } +
\Channel Channel

An anchor record is thus seen to consist of an unique identifier, a LocSpec, a direction and a service.

The direction field allows the linkservice to specify whether the given anchor is the start of a link, the end of alink, or one end of a bi-directional link.

The service field allows for the case that not all hypertext buttons will require a Follow Link type of service. Sometimes a anchor may be created that causes some other service (e.g. dynamically generate links) to be requested.

5.6.5. DisplayAnchor

When a document is launched, or possibly at some other time, it will often be necessary to send a message requesting that a particular anchor is displayed, e.g. by moving the cursor to the anchor, or highlighting the anchor. This message is sent to the viewer to request such an action. \Subject DisplayAnchor \AnchorID AnchorID \Presentation colour,style,display \Channel Channel

5.6.6. DisplayLocSpec

Sometimes it is necessary to display something other than a pre-defined anchor, for example, the result of a search. This message may define the object to be viewed. \Subject DisplayLocSpec \LocSpec LocSpec \Presentation colour,style,display \Channel Channel

5.6.7. HeresNewAnchor

The protocol requires that the viewer is not responsible for allocating anchor ID's. Instead a message will be sent to the linkservice asking for an anchor ID, and the linkservice will reply: \Subject HeresNewAnchor \Data {\AnchorID AnchorID \LocSpec LocSpec \Direction Start/End/Bidirect \Presentation colour,style,display \Service Service } \Channel Channel

5.6.8. Interpret

This message allows the link service to send scripts to the application which the application will interpret. Such scripts might alter the presentation of a node, change the contents of a node or anything else that the interpreter contained in the application is capable of undertaking. \Subject Interpret \ScriptType ScriptingLanguage \Data { Script } \Channel Channel The ScriptType tag will define the interpreter that will be required by the application that receives the following script. In the simplest case an application might interpret keystrokes that could be played to the application. At the other end of the scale, the application might implement a Java interpreter. The protocol may need extra messages to allow the linkservice to query the application to discover the scripting language(s) that it can handle. In its current form the linkservice must either know what languages can be handled, or must accept that the script may be ignored.

5.6.9. HeresNewChannel

This message is sent by the linkservice to an application when it has requested a new connection to the linkservice (see CreateNode below). \Subject HeresNewChannel \SendDocument True / False \DocumentNickName [DocNickName] \Channel Channel The SendDocument Tag is used by the linkservice to request that the viewer follows up by actually sending the contents of the node, as is required by many of the hyperbase variety of linkservices. If the linkservice already knows of the document, and has a nickname for the document, it will return this.

5.6.10. CloseNode

This message is sent by the link service to a node that it wishes to automatically close. \Subject CloseNode \UpdateNode True / False \Channel Channel The application is then responsible for closing itself, ensuring that it has updated any anchors and its contents if required by the UpdateNode tag.

5.7. Messages that the Editor/Viewer May Send

5.7.1. GetNode

This message allows the viewer to ask the linkservice to send it the contents of a node. This is only required where the linkservice actually stores the node data, and would typically be sent in response to a LaunchDocument message which had the DataCallBack flag set. The linkservice will respond with a HeresDocument message. \Subject GetNode \DocumentName DocName \Channel Channel The DocumentName is redundant when calling back for a node, as the linkservice already knows this. However, this message might also be sent to request a new document.

5.7.2. GetServices

When a viewer has loaded up, it will be necessary for it to ask the linkservice to itemise the set of services it may provide on a menu. \Subject GetServices \Channel Channel The linkservice should respond with a HeresServices message.

5.7.3. GetAnchorTable

The viewer, while running is expected to maintain the anchor table. It is expected to obtain the anchors from the linkservice by sending the message: \Subject GetAnchorTable \Channel Channel and the linkservice is expected to respond with a HeresAnchorTable message.

5.7.4. RequestService

Most of the hypertext functionality will be obtained by either clicking on buttons or sensitive areas (which are representations of anchors) or making a selection and requesting an action from the menu, or simply choosing an action from the menu. In the case where a button is clicked, the viewer will know the service that is required from the anchor table. In the case where an action is chosen from the menu, this will define the required service. Messages requesting services will take the form: \Subject RequestService \Service Service

\AnchorID [ AnchorID ] \LocSpec [ LocSpec ] \Presentation [ colour,style,display ] \Channel Channel

The anchor ID will be empty in many of these messages, for example, when requesting that an anchor is created on a given LocSpec.

The LocSpec may be empty, for example in the case where a simple action has been chosen from a menu.

5.7.5. Update Anchors

When a document has been edited the viewer is responsible for ensuring that the LocSpecs in the anchor table are changed. Consequently it will be necessary to communicate these changes to the link service. \Subject UpdateAnchors \Data {\AnchorID AnchorID \LocSpec LocSpec \Direction Start/End/Bidirect \Presentation colour,style,display \Service Service }+ \Channel Channel

5.7.6. CreateNode

A user may wish to register a new document that they are currently viewing with the link service. In this case there will not yet be an established channel between the document and the linkserver. The viewer/editor will send the following message. \Subject CreateNode \DocumentName DocName \DocumentType MimeType When the linkservice gets the message, it will send a HeresNewChannel message back (see above), and if necessary (SendDocument = True) the viewer will then arrange to send the actual contents of the document using the UpdateNode message. Note that it is quite possible that the document concerned may already be registered with the link service: in this case this message serves only to open a communication channel to the linkserver. Also note that the message contains no information about document ownership or permissions: it is assumed that the linkservice, on receiving this message, will enter into a dialogue with the user to obtain such information.

5.7.7. UpdateNode

If the contents of a node have changed during a session (or if it is a new node) it may be necessary to send the contents back to the linkservice, if the linkservice is of the type that stores the actual contents. \Subject UpdateNode \DocumentType MimeType \Data Mime Encoded Data \Channel Channel

5.7.8. Closing

This message is sent when a node is closed by the user. \Subject Closing \Channel Channel This will close the channel which may now be re-assigned.

5.8. Messages that both may send

5.8.1. Other

We are very much aware that at times such protocols are insufficient for the needs of a particular problem. We therefore suggest that for experimental purposes, the following extensions to the protocol are allowed. Any message may include a tag

\Other Data

where the data may be anything that the application and the link service wish to include.

Furthermore, either the application or the linkservice may send a message

\Subject Other
\UserDefinedTag User Defined Data +
\Channel Channel

so that they can create their own messages with their own data.

Application developers are strongly encouraged to attempt to make the interpretation of these tags and messages optional at the client end, or the applications that they hypertext enable will not be transferable to other systems.

5.8.2. Error

There may be times when a message is sent by one component that the other component does not understand or is for some reason unable to service. In these cases it may be important that the sending component is informed of the error. Either the linkservice or the editor should send an error message when it receives a message that it is unable to process.

\Subject Error \ErrorSubject Subject tag of error message \ErrorMessage Message \Channel Channel

The Error Message might be used to display in a message box to the user.

5.9. Protocol Summary

Now that we have introduced the entire protocol, it may be convenient to classify the types of messages. Appendix A classifies all messages using this scheme:

Linkservice Requests: messages that the linkserver sends to the client asking for some action.

Linkservice Replies: messages that the linkserver sends in response to all client requests.

Client Initialisation Requests: Messages that the client sends, typically at start-up, in order to initialise itself with the necessary linkservice information.

Client Update Requests: Messages that the client sends to the linkserver to inform the linkserver of changes to the linkservice information that have occurred at the client end.

Client Event Requests: Messages that are sent when a sensitive area is clicked on, or a choice has been made from a link service supplied menu.

Client Replies: Messages that are sent by the client in response to requests from the linkservice.

Bi-directional Messages: Messages that may be sent either way.

6 . E x a m p l e S ce n a r i o s

In this section we consider, by reference to some different types of hypermedia viewer / editors, the way that these applications might use the OHP Protocol.

6.1. A Microcosm Semi-Aware Viewer

A Microcosm semi-aware viewer might be a program such as Word for Windows, which has been adapted, usually by the use of application specific macros, to allow the user to make selections and request actions. For the purpose of this example we will assume that we are not going to attempt to enable the application to handle persistent selections: in Microcosm terms this viewer will not handle buttons or specific links, but will allow the user to create local and generic links, and will allow the user to follow such links and to request other services such as computed links.

Let us assume that in this case the user has been working in Word for Windows "off-line", and the scenario begins at the moment that the user decides that they wish to start using hypertext services.

The user selects a menu option on Word asking to register with the link service. This menu might cause the following message to be sent to the link service:

 \Subject CreateNode \DocumentName C:\DOCS\MYDOC.DOC \DocumentType Word4Windows

The Linkservice would check to see if it already knew about this document. If not, it would create a new record in the link database registering the document. Assuming that there were already 8 live connections to the link service, it might return the message:

\Subject HeresNewChannel \DocumentNickName Hugh's Comments On The Protocol\SendDocument False \Channel #9

The viewer might now request the services

\Subject GetServices \Channel #9

The linkservice would decide, which would now know the document type, and thus the viewer, and would return the appropriate available services, e.g.

\Subject HeresSubjects \Data {\Menuitem Follow Link\Service FOLLOW.LINK} \Data {\Menuitem Show Links\Service SHOW.LINKS} \Data {\Menuitem Compute Links\Service COMPUTE.LINKS} \Data {\Menuitem Make Start Anchor\Service START.LINK} \Data {\Menuitem Make End Anchor\Service END.LINK} \Channel #9

The viewer on receiving this message would build a menu for the user to select these services. Since this viewer is not intended to be capable of handling persistent selections, no request will be sent to the link service for the anchor table.

Now, a user might select the string "making a menu" within the document and select "Make Start Anchor" from the menu. The viewer will send the message:

\Subject RequestService \Service START.LINK \AnchorID \LocSpec {\ContentType ASCII\Content making a menu\Count \ReverseCount \Name \Script } \Presentation \Channel #9

The link service, on receiving this message would note that no LocSpec information, other than the content, had been provided, and would thus start up the link making dialogue with options to create local or generic links. Note that the link making dialogue is within the province of the link service, and is not, currently, part of the OHP protocol.

The user might continue to request further services in a similar way to the above, and then when finished would close the document, which action would cause the following message to be sent.

\Subject Closing \Channel #9

6.2. Microcosm fully aware

Now let us consider the case of Word for Windows adapted as a fully aware Microcosm viewer. In this example perhaps the user follows a link to a node that is a Word for Windows document held on the network file system. Thus the linkservice might begin by sending the message:

\Subject LaunchDocument \DocumentName N:\docs\file.doc \ReadOnly False \DocumentNickName \DocumentType Word4Windows \DataCallBack False \Channel #10

indicating that the linkservice wishes Word for Windows to be launched with the named document in editable mode. The linkservice has allocated channel 10. When word has been launched it will send back the messages:

\Subject GetServices \Channel #10 \Subject GetAnchorTable \Channel #10

The linkservice might reply to this by sending the same HeresServices message as in the previous section, and also send the message:

\Subject HeresAnchorTable
\Data {\AnchorID id_1 \LocSpec {\ContentType ASCII \Content bank balance
\Count 1045 \ReverseCount 2345 \Name \Script } \Direction Start
\Presentation 1,1,1 \Service FOLLOW.LINK}
\Data {\AnchorID id_2 \LocSpec {\ContentType ASCII \Content html editors
\Count 2085 \ReverseCount 1305 \Name \Script } \Direction Start
\Presentation 1,1,1 \Service COMPUTE.LINKS}
\Data {\AnchorID id_3 \LocSpec {\ContentType ASCII \Content Dr Smith \Count 3045 \ReverseCount 345 \Name \Script } \Direction End \Presentation 1,1,2 \Service Nil}
\Channel #10

In this example three link anchors are described. The first two are start anchors, and the third is a destination anchor (which has a service of Nil). The LocSpecs of these anchors describe the persistent selections in terms of byte offsets through the file, in both directions. An interesting problem arises here. Word can handle and save bookmarks, which would make an ideal method for representing persistent selections. However, if the user who is making links within the document does not have write permission for this document, then it will not be possible to save the document with the bookmarks embedded. For this reason the viewer is not attempting to save the bookmarks with the file, but is saving their position within the anchor's LocSpec, and might turn these positions into bookmarks during the period that the file is being viewed or edited.

The first thing that the viewer would need to do would be to put the bookmarks into the given positions. It will need to check that the content at these position does match the expected content, and if not it will need to apply some algorithm to find where the bookmarks should be placed.

The linkservice might follow it original LaunchDocument request with:

\Subject DisplayLocSpec {\ContentType ASCII \Content Dr Smith \Count 3045 \ReverseCount 345 \Name \Script }\Presentation 1,1,1\Channel #10

The viewer will now need to highlight the string "Dr Smith" and scroll the document so that this destination anchor is within view.

Maybe the user now clicks on the bookmark over the string "html editors". In this case the viewer will send the message:

\Subject RequestService \Service COMPUTE.LINKS \AnchorID id_2\LocSpec\LocSpec {\ContentType ASCII \Content html editors \Count 2085 \ReverseCount 1305 \Name \Script }\Presentation \Channel #10

This will cause the linkservice to apply the COMPUTE.LINKS service to the given LocSpec. Before the viewer is closed, it will be the responsibility of the viewer to send an UpdateAnchors message to the linkservice to ensure that all its LocSpecs coincide with the current position of the bookmarks.

Before leaving Microcosm, it is worth making two particular points.

Microcosm does not store anchorID's. A Microcosm link consists principally of the start and end LocSpecs. The anchor id's in the anchor table were inserted by the protocol shim for the sake of complying with the OHP protocol. Microcosm itself will never use them: it will communicate with the shim entirely in terms of LocSpecs, and will never send the DisplayAnchor message.2 It is important that the viewer does not make any assumption that the set of bookmarks it has at any particular time represents the entire set of available bookmarks. This is because Microcosm allows the installation of different sets of links (or Webs), and there may be other anchors within the document that are not currently available. This feature will be common to any distributed link service.

6.3. Classic Dexter Systems

Many of the classic Dexter systems expect that the application will own the anchor table. Such systems might store this table with the data, or might arrange to store the table outside the data in a separate but associated file. When a new anchor is created, its identifier is allocated by the viewer application and is unique within that context. The links that are stored within the linkservice have ends which consist of a (Document Name, AnchorID) pair. This situation can easily be handled by the OHP protocol as follows.

The OHP protocol shim should be written to handle the storage and delivery of the anchor table for each document. Thus when the GetAnchorTable message is received by the protocol shim, it will retrieve the correct file (which it will identify from the channel information). The linkservice itself will never see this message. The viewer will communicate to the linkservice about anchors in terms of the anchorID and the channel (and perhaps the LocSpec), and the shim will convert this into messages about the anchorID and the document name, as shown in figure 3.

Figure 3: Anchor Table Handling in Classic Dexter Systems.

Since such linkservices do not normally provide a service for allocating anchor identifiers, the protocol shim will need to provide the service instead. When the viewer sends a service request for a new anchor, the OHP shim will consult the appropriate anchor table and allocate the next available anchorID, which it will pass back to the viewer.

6.4. Hyperbase Systems

Most hyperbase systems differ from the descriptions given so far in two respects:

They expect to allocate anchors that are globally unique, and they provide a service to allocate such identifiers. The linkservice must of course still know which document an anchor belongs within so that it can display the correct document when a link is followed to the anchor.

They often expect to store the node contents. The protocol has the HeresDocument and Update node messages specially to deal with this case. In many cases the node contents may contain the (anchorID, LocSpec) table. If this is the case, the OHP protocol shim will need to arrange to separate the table from the raw node contents, so that the application may first load the contents, then call for the anchor table which will be sent on in a separate HeresAnchorTable message.

6.5. Embedded Anchor Viewers

Where a viewer is being specially built for a format that will only be used hypertext systems it is likely that the developer will specify data format in such a way that the persistent selections may be held as mark-up within the data. Such a format is htf used by Hyper-G. In such cases the anchorID will be encoded into the mark-up and passed to and from the link service to identify the ends of links. These anchorID's might be unique to the document or to the link service as a whole. It is important to realise, however, that not all the anchors held in the document will necessarily be currently valid. In many systems separate Webs of links may be installed, and the anchors that will be valid will depend on the choice of Web.

Therefore, if such a viewer is to work with the protocol it must still send the GetAnchorTable to the linkservice: only those anchors which the linkservice returns should be offered to the user.

7. Existing Standards

A question that has often been posed to the open hypermedia research community is, why do we not use existing standards such as OLE and CORBA? The usual answer has been that these standards do not provide the correct services, and anyway they are by no means standard across architectures, or are not in common use. It is worthwhile, however to consider at this point how existing and emerging standards might be of use in implementing an application to work with a protocol such as OHP. The prevailing problems, when it comes to hypertext enabling an application are:

how do we change the behaviour of the program so that it will send and receive the necessary messages? We can usually only achieve this is if the program has an internal macro language or else we can get access to the source code to extend its behaviour.

how do we get the required information for the LocSpec? This requires that the application allows us to understand something about its data format.

how do we indicate the presence of anchors within the application data? This requires that we are able to alter the display characteristics of the application.

Existing standards which are well worth noting are the Apple Event Object Model (AEOM) which is a Macintosh standard, and OpenDoc which is a multi-platform model which will shortly be able to interoperate with OLE.

7.1. The Apple Event Object Model

The Apple Event Object Model (AEOM) consists of a number of standardised sets (or suites) of messages and abstract data objects, which are intended to cover both the inter-application exchange and manipulation of most forms of data, and the external control of applications.

The Required Suite is a set of four basic messages which every Macintosh application is required to support. These are: Open Application, Open Document, Print Document and Quit Application.

The Core Suite must be supported by every AEOM compliant application. The messages allow chiefly for the retrieval and modification of data within applications, plus closing documents, and the making of selections.

Other suites are defined for specific data types, including text, pictures, tables, Quicklime and sound.

Most suites define a set of objects to cover the data type that they handle. An application's data is arranged as a hierarchy of these objects. For example: at the top of the hierarchy is the "application" object. This will have a set of "window" elements. A window within an application can be specified by name, or by order: window 1 will be the frontmost, window 2 the second from the front, etc. A window has a number of properties, including name, position, bounding rectangle etc., and selection. It is therefore very easy to retrieve the user selection from the front window of any compliant application. Furthermore, the calling application can specify the form in which it wants the data: it can ask for the content of the selection, or for its offset and range, or for any other attributes that are applicable. If an application is unable to produce the data in the necessary type, it may substitute an alternative, but the form of data supplied is always specified in its reply.

The AEOM is in many ways ideally suited for use with OHP. LocSpec requirements can be translated almost verbatim into AEOM queries, which can be sent to a target application. The application need not be written with any knowledge of OHP; it must simply be written to take full advantage of its own target platform. The AEOM is open to the creation of new suites, so an OHP suite can be defined and used to create applications with a higher level of awareness, using only established tools and techniques.

7.2. OpenDoc

OpenDoc is a multi-platform component-based architecture, based around CORBA. OpenDoc uses compound documents, where the data in each component is viewed and accessed by means of "part editors". OpenDoc assigns the correct editor to handle each different data type, looking first at user preferences, and failing that, making an intelligent decision based on the data type, and its knowledge of the available editors. The part editors share windows, menus and other resources within a document. OpenDoc provides a highly versatile persistent storage system known as Bento, which allows multiple part editors to share a single document file. The Bento storage units and mechanisms are also used for clipboard transfers, drag-and-drop, and linking between parts, documents and/or networks.

OpenDoc includes the Open Scripting Architecture a highly versatile mechanism that includes an AEOM style communication architecture. Consequently the same kind of Shims that would work with the AEOM would work with properly built OpenDoc part editors, and hence with OpenDoc applications. OpenDoc is a multi-platform architecture, and if it is successful in establishing itself the implications are significant.

8 . Conclusions

This paper has described the first draft of level 0 and level 1 of a protocol for client viewers to communicate with a link service. No doubt, as developers try to match the protocol to their own link service, deficiencies will emerge and enhancements will be required.

It is intended that almost any application may run as a level 0 viewer (launch and run with no hypertext), and that level one, as described here, will be the sort of functionality that should be possible to achieve by adapting third party applications. We envisage that level 2 of the protocol will be a much heavier weight implementation.

There are a number of ways in which we can imagine the protocol expanding in the future.

The system described here is a fairly passive form of linkservice: clients send requests and get answers which they display. However, systems such as Multicard (Rizk & Sauter) which run server end scripts tend to be much more active, interacting with and changing the data in a node, updating the presentation characteristics, altering the menus interactively, etc. Such behaviour puts a greater onus on the application as there are a much larger number of link service requests that it must be able to handle. We envisage that such extensions will be in level 2 of the protocol.

At present the protocol allows the passing of scripts, both to identify a persistent selection, and also as a message in its own right to carry out some process at the client end. At present the language of the script is not prescribed, and the linkservice must know what sort of script to dispatch to a particular viewer. It is possible that these scripts could be standardised in level 2 of the protocol.

There are a number of other cases where the link service needs to communicate with the user. For example, as link anchors are identified it is necessary for the linkservice to send the user a dialogue for eliciting such information as the link attributes. Also, when a document is registered with the system the linkservice will need to be given the document attributes. Such dialogues will be highly dependant on the particular link service, but it is quite possible that the protocol could be extended to include the communication of these dialogues to some standard demon at the client end.

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.

The best known hypertext system is without doubt the World Wide Web, and the standard html viewers played an important part in making the Web so popular. The Web does not currently use a link service, but there is plenty of research aimed at producing link services for the Web, e.g. the Distributed Link Service (Carr et al, 1995 ), and once the links are abstracted from the documents, then the Web will no longer be dependant on html to provide hypertext functionality. It will become possible to use any viewer. Perhaps this protocol could have a future in providing a standard interface to Web link services.

Appendix: Summary of Protocol

LocSpec Definition

{\ContentType \Content \Count [] \ReverseCount []\Name [] \Script []}

Presentation Specification

\Presentation

where the data that follows the presentation tag is opaque, and will be understood only by the viewer that created it in the first place.

Messages Classified by Type

Linkservice Requests

(messages that the linkserver sends to the client asking for some action.)


\Subject LaunchDocument \DocumentName \ReadOnly \DocumentNickName []
\DocumentType \DataCallBack \Channel
\Subject DisplayAnchor \AnchorID \Presentation \Channel
\Subject DisplayLocSpec \LocSpec \Presentation \Channel \Subject Interpret \ScriptType \Data {} \Channel \Subject CloseNode \UpdateNode \Channel

Linkservice Replies

(messages that the linkserver sends in response to all client requests.)

\Subject HeresServices \Data {\Menuitem\Service }+ \Channel \Subject HeresDocument \Data \Channel \Subject HeresAnchorTable \Data {\AnchorID \LocSpec \Direction \Presentation \Service}+ \Channel \Subject HeresNewAnchor \Data {\AnchorID \LocSpec \Direction \Presentation \Service} \Channel \Subject HeresNewChannel \SendDocument \DocumentNickName [] \Channel

Client Initialisation Requests

(Messages that the client sends, typically at start-up, in order to initialise itself with the necessary linkservice information.)

\Subject GetNode \DocumentName \Channel
\Subject GetServices \Channel
\Subject GetAnchorTable \Channel
\Subject CreateNode \DocumentName \DocumentType \Channel

Client Update Requests

(Messages that the client sends to the linkserver to inform the linkserver of changes to the linkservice information that have occurred at the client end.)

 \Subject UpdateAnchors \Data {\AnchorID \LocSpec \Direction \Presentation \Service }+ \Channel
\Subject UpdateNode \DocumentType \Data \Channel
\Subject Closing \Channel

Client Event Requests

(Messages that are sent when a sensitive area is clicked on, or a choice has been made from a link service supplied menu.)

\Subject RequestService \Service \AnchorID [] \LocSpec [] \Presentation \Channel

Client Replies

(Messages that are sent by the client in response to requests from the linkservice.)

There are none in Level 1 of the Protocol

Bi-directional Messages

(Messages that may be sent either way. )

\Subject Error \ErrorSubject \ErrorMessage \Channel \Subject Other \UserDefinedTag +\Channel Channel

There may also be an optional extra tag on the end of any message.

\Other

Levels of the Protocol

Level 0: Only Supports LaunchDocument and CloseNode messages from linkserver to client. No communication. No hypertext. Any application should be able to run as a Level 0 viewer.

Level 1: Supports the functionality described in this paper. It is intended that it will be possible to achieve this level by adapting third party applications.

Level 2: Not yet defined, but envisaged to support extensions to deal with content manipulation, presentation and standard client end scripts. It is expected that this level of conformity will only be achieved by writing specialised applications.

Responsibilities of the Shims

Server Side Protocol Shim.

(Produced by Link Service suppliers).

Accept Messages from Link Server, convert to OHP equivalent and pass to correct Client.

Accept Messages from Client side in OHP, convert and pass to link service in private protocol.

Client Side Communication Shim.

(One needs to be produced for each client platform, for each communication protocol conversion)

Accept OHP messages from network and communicate message to correct viewer/editor.

Accept Messages from viewer editor and forward to linkservice in network protocol.

Maintain table of applications on this platform which should be used for each data type.

Maintain table showing what level of protocol can be expected from each viewer/editor.

Handle LaunchDocument messages at the client end, and, if a DataCallBack is required, send the GetNode message and handle the transfer of the data from the HeresDocument message to the application.

For level 0 applications, handle CloseNode messages, and return error messages for other linkservice requests.

References

Andrews K., Kappe, F. & Maurer, H. Hyper-G: Towards the Next Generation of Network Information Technology. Journal of Universal Computer Science, April 1995. Aßfalg, R. (ed.). The Proceedings of the Workshop on Open Hypertext Systems, Konstanz , May 1994. Carr, L.A., De Roure, D., Hall, W. & Hill, G.J. The Distributed Link Service: A Tool for Publishers, Authors and Readers. In: The Fourth International World Wide Web Conference Proceedings. pp 647-656. O'Reilly & Associates, Dec 1995.

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.C., Knight, S.K. & Hall, W. Light Hypermedia Link Services: A Study in Third Party Application Integration. In: The ACM Conference on Hypermedia Technology, ECHT '94 Proceedings. pp 41-50. ACM. Sept. 1994.

Davis, H.C. To Embed or Not to Embed..., Communications of the ACM, Vol 38(8), pp 108-109. August 1995. DeRose, S.J & Durand, D.G. Making Hypermedia Work: A User's Guide to HyTime. Kluwer Academic Press. 1994

Grønbæk, K. & Trigg, R.H. Design Issues for a Dexter-Based Hypermedia System.

In: D. Lucarella, J. Nanard, M. Nanard, P. Paolini. eds. The Proceedings of the ACM Conference on Hypertext, ECHT '92 Milano , pp 191- 200. ACM Press. Nov. 1992

Grønbæk, K. & Trigg, R.H. From Embedded References to Link Objects: Toward a New Data Model for Open Hypermedia Systems . To be published in The Proceedings of Hypertext '96. ACM 1996 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.

Hall, W. Ending the Tyranny of the Button . IEEE Multimedia 1(1). 1994. Kacmar, C.J. & Leggett, J.J. PROXHY: A Process-Oriented Extensible Hypertext Architecture. ACM Trans. on Information Systems, 9(4) pp 299-419. Oct. 1991.

Leggett, J. & Schnase, J. Dexter with Open Eyes. Communications of the ACM 37(2) pp 77-86. Feb. 1994 Østerbye, K. & Wiil, U.K. The Flag Taxonomy of Open Hypermedia Systems , To be published in The Proceedings of Hypertext '96. ACM 1996

Rizk, A. The M2000 Protocol Description Manual. Euroclid. (Available from the author) 1991 Rizk, A. & Sauter, L. Multicard: An Open Hypermedia System .

In: D. Lucarella, J. Nanard, M. Nanard, P. Paolini. eds. The Proceedings of the ACM Conference on Hypertext, ECHT '92 Milano , Italy, December 1992, pp 181-190. ACM Press. 1992

Wiil, U.K & Østerbye, K. (eds.). The Proceedings of the ECHT '94 Workshop on Open Hypermedia Systems, Edinburgh, Sept. 1994. Technical Report R-94-2038. Aalborg University. Oct. 1994. Wiil, U.K. & Leggett, J.L. The HyperDisco Approach to Open Hypermedia Systems , To be published in The Proceedings of Hypertext '96. ACM 1996. View publication stats