Working Draft 1.5 20th June 1997

Authors Hugh Davis, Sigi Reich, Antoine Rizk

Source: https://www.southampton.ac.uk/~hcd/ohp/ohp3.htm

Status of this Document

This document specifies the draft for the Open Hypermedia Systems' Protocol (OHP). Distribution of this document is unlimited. Comments are welcome at H.C.Davis@ecs.soton.ac.uk. For discussions about the protocol as well as Open Hypermedia Systems in general see also the OHS Mailing List and the OHS Working Group Home Page.

Abstract

This section should give a management summary and overview. What is the motivation behind OHP? What would be the benefits if OHP would be supported by tools? (viewer independent of linkservice, link editing possible, ...) Should we mention why http is insufficient (because Web users might be interested)?

Protocol Definition

This section specifies the actual form and the minimum set of messages defined in OHP. We describe the message header and the messages to be sent; we evolve on specific issues such as location specifications, presentation specifications, and expected functionality and behaviour of components. We finish with example scenarios, related work, and a list of references.

4. Introduction

The Open Hypermedia Protocol (OHP) is to be used as a standardised protocol between viewers and link services. These agents of OHP transactions can be of various forms: a Viewer can be a dedicated viewer for a specific LinkService; or it can be an adapted version of an existing generic application such as Microsoft Word. The LinkService can be a 'simple' LinkService providing only links as well as a hyperbase providing both, links and documents. For the remainder of this contribution we will only use the terms Viewer and LinkService for these components.

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, 1991) 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.

For the definition of the protocol we additionally make some assumptions on the architecture. Note however, that we are not aiming and not claiming for fully defining a reference architecture. The general picture we have in mind when defining OHP is as follows:

Fig.: Components and Layers in OHP Definition

In defining OHP we abstracted in different layers. On the top-level a so-called Viewer talks OHP to another component which is only interesting from an OHP point of view in that this component understands and answers OHP requests. Typically though this component would be a LinkService or a HyperBase.

OHP abstracts from the communication layer. However, there has to be a component that establishes connections, that 'knows' how to talk to other services and viewers, and the more. We call this component a SessionManager and it could be described as an intermediate component between LinkService and Viewer. For the definition of OHP we assume that both Viewer and LinkService exchange OHP messages via the SessionManager, the actual communication though is not part of OHP.

Besides the components Viewer, LinkService and SessionManager there is a fourth component, the Document Management System (DMS). We are convinced that an additional protocol - a document management procotocol (DMP) - should allow standardised communication to document management systems. The Open Document Management API (Open Document Management, 1997) could serve as a good example and some of the concepts in OHP, e.g. the definition of a NodeId as a unique document identifier, follow this proposal.

5. Form of the Protocol

5.1 General Form

OHP is a peer to peer asynchronous protocol. Messages may be sent by either the LinkService or by the Viewer. If a reply is expected, it is up to the receiving component to initiate a new message. There are thus two main classes of messages to be considered; those sent by the Viewer and those sent by the LinkService.

5.2 Notational Conventions and Generic Grammar

For actually defining the mechanics of OHP we will follow a Backus-Naur Form (BNF) as is for instance done in Internet drafts. We use the following constructs:

name = definition: The name of a rule is simply the name itself and is separated from its definition by the equal "=" character.
"literal": defines a literal. Definition is case sensitive.
{elem1 | elem2}: a "|" can be used to define either/or alternatives.

{elem}*: A "*" indicates repetition, i.e. there can be any number of occurrences.
{elem}+: A "+" indicates that one or more elements have to be present, i.e. there has to be at least one element.
[elem]: Square brackets enclose optional elements.
<elem>: Angle brackets enclose basic types that are not specified in more detail but can be dealt with by the receiving/sending components.

Additionally we assume the following rules (the US-ASCII coded character set is defined by ANSI X3.4- 1986):

CHAR = US-ASCII character (octets 0 - 127)
UPALPHA = any US-ASCII uppercase letter "A".."Z"
LOALPHA = any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA | LOALPHA
DIGIT = any US-ASCII digit "0".."9"
CTL = any US-ASCII control character (octets 0 - 31) and DEL (127) CR = US-ASCII CR, carriage return (13)
LF = US-ASCII LF, linefeed (10)
SP = US-ASCII SP, space (32)

OHP messages will consist of text strings (CHAR). 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 feeds (LF). The messages consist of Tags, which are proceeded by a backslash ('\') and succeeded by a white space (SP). 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 of the message definition. If a backslash ('\') occurs within the tag content, then it should be quoted by preceding it with a further backslash.

We can now begin to define the protocol.

6. Definitions

6.1 Message Header

As opposed to the previous draft of OHP (Davis et al., 1996), which define a Channel as an identifier for messages, we have defined a dedicated message header (see Thread "Channels in OHP"). As already mentioned above, OHP abstracts from the communication layer so the header does not include any host or port or other communication specific information.

The OHP message header is defined as

MessHeader = \MessId the OHP Id and version number
             \Subject name of this message

MessId uniquely identifies this type of message and gives OHP version information. The subject field is considered to be particularely helpful in case a component can not understand a message; it could then at least provide additional information about the message.

Besides basic header information there are two more fields that will be present in almost all messages but that do not have to be understood by the LinkService. These fields are

\SessionId a byte string that can be used for uniquely identifying
           messages and deal with transaction management

\UserId a byte string that can be used for identifying a user

As mentioned above, the actual managing of documents is a crucial issue. Within OHP, documents are therfore not dealt with directly but are called by a reference, the NodeId. A NodeId has to be unique within a given usage scenario. However, from a protocol perspective the NodeId is opaque.

6.2 Responsibilities of Session Manager

The abstraction from communication information within the OHP header requires a number of assumptions about the underlying components' functionality. The main component both LinkService and Viewer will be talking to is the so-called "SessionManager". Note that there is a manifold of different terms for this component: in the previous draft of OHP it has been called "Communication Protocol Shim" (Davis et al., 1996), (Goose et al., 1997) call it "Runtime", (Wiil and Leggett, 1996) call it "Tool integrator"; all approaches have in common that they require a component at the client's side managing different OHP sessions. That's why we use the term SessionManager.

This is the basic functionality and behaviour we are assuming a SessionManager component to have:

Establishing of connections to the LinkServices the user wants to connect; transfering and receiving of OHP messages;

Loading of documents if asked to by the LaunchDocument message; the parameter given is of type NodeId.

Providing of document management functions in the absence of a document management system. The SessionManager should then do tasks such as providing attribute access functions for a given document (its NickName, Type, Preferred Viewer etc.).

Additionally, as creation of links between node in different application windows is a crucial issue, also this functionality could be part of the SessionManager. Issues such as joining n to m anchors, defining direction, scope etc. would probably be best implemented just once in the Session Manager. This means that the SessionManager not in some implementations might not only be a process but also have a user interface component available to all applications on a user's desktop.

6.3 Overview of Messages

Tab.: Message Requests by Viewer and Answers by LinkService

Additionally, the Viewer might send the following messages:

RequestService

ClosingNode

UpdateAnchors

UpdateNode

CreateLink

CreateNode

The LinkService might send the following messages to the Viewer

LaunchDocument

DisplayAnchor

DisplayLocSpec

Interpret

NewAnchor

CloseNode

All, Viewer, LinkService as well as other components speaking OHP can send an error message.

We will now present the messages in detail and also give examples or additional comments where necessary to understand the semantics of the protocol.

Message Pair "GetServices/Services"

The "GetServices" message is to be sent from Viewer to LinkService in order to know which services are available. The LinkService has to answer this request by a "Services" message. Services are defined by a description and a service name.

Note the naming of message IDs in OHP: "MV" is short for "message from viewer", the second token gives the name of the message and the last two tokens define that the message class this message belongs to is OHP and give version information. Equally, service originated messages start with "MS", short for "message from service". Messages that can be originated by any of the components start with "M".

\MessId MV_GetServices_OHP_1.0
\Subject "GetServices"
\SessionId <SessionId>
\UserId <UserId>

The linkservice will reply with


\MessId MS_Services_OHP_1.0
\Subject "Services"
\Data
  {\Service the name of the service
   \Description a description of the service in the
    local language}+
\SessionId <SessionId>
\UserId <UserId>

We have identified a number of default services that each LinkService supporting OHP has to provide. These services include

FollowLink

MakeAnchor - which must also add the service for the anchor

DeleteAnchor

Any of these services may be requested by a "RequestService" message, for instance

\MessId MS_RequestService_OHP_1.0
\Subject "RequestService"
\Service "FollowLink"
\AnchorId 152.78.115.213:D:999
\LocSpec {\ContentType ASCII
          \Content "OHS Home Page" \LocType "NameLoc"
          \NodeId 152.78.115.213:E:3334}
\Presentation
\SessionId 33
\UserId Hugh

Message Pair "GetNodeId/NodeId"

OHP does not actually deal with the documents being involved in an OHP session; it uses references to documents instead. However, in many situations it might be useful to get a document identifier given the name of a document or any of its attributed. For this purpose the message pair "GetNodeId / NodeId" is introduced.

\MessId MV_GetNodeId_OHP_1.0
\Subject "GetNodeId"
\DocumentName the name of the document
\DocumentAttributes
    {\name the attribute's name
     \value its value}*
\SessionId <SessionId>
\UserId <UserId>

The LinkServer will answer this request with

\MessId MS_NodeId_OHP_1.0
\Subject "NodeId"
[\NodeId NodeId | \result a result message string]
\SessionId <SessionId>
\UserId <UserId>

If there is no NodeId for the given document name and attributes then the document is either currently unknown to the LinkService or it is unavailable (it could for instance be locked). The LinkService specifies this in the result tag. It is the responsibility of the SessionManager to register this node or pass the error on to the user. In case it wants to reister a new node the SessionManager would send

\MessId MV_CreateNode_OHP_1.0
\Subject "CreateNode"
\DocumentName the name of the document
\DocumentAttributes
   {\name the attribute's name
     \value its value}*
\SessionId <SessionId>
\UserId <UserId>

The LinkServer will eventually send back a NodeId message (see above).

Message Pair "GetAnchorTable/AnchorTable"

Now that we have the document itself and an appropriate application for the document, the application needs to know

a. What services it may offer (see above)

b. What anchors to display in the current document

In order to get the anchors for a given document (represented by its NodeId) the GetAnchorTable message is used. Note that the message is asynchronous, and that it should result in one or more AnchorTable messages, e.g. if a distributed LinkService came up with separate answers. The application should be capable of concatenating the tables.

\MessId MV_GetAnchorTable_OHP_1.0
\Subject "GetAnchorTable"
\NodeId <NodeId>
\SessionId <SessionId>
\UserId <UserId>

The LinkService should answer this with the "AnchorTable" message.

\MessId MS_AnchorTable_OHP_1.0
\Subject "AnchorTable"
\NodeId <NodeId>
\Data {\AnchorId <AnchorId> \LocSpec
       \Direction {"AtoB" | "bidirectional"} \Presentation \Service}+
\SessionId <SessionId>
\UserId <UserId>

Message Pair "CreateLinkId/LinkId"

This message is sent by the Viewer - it could also be sent by the SessionManager's user interface component - when a user creates a link. OHP allows any number of incoming and outging anchor ids; a link at least has a direction and a name. The CreateLinkId message should be answered by the LinkService with a LinkId message (see below). If the creation of the link has not been successful for any reason a result tag instead of a LinkId should be answered.

\MessId MV_CreateLinkId_OHP_1.0
\Subject "CreateLinkId"
\AAnchors {\AnchorId <AnchorID>}+
\BAnchors {\AnchorId <AnchorID>}+
\Direction {"AtoB" | "bidirectional"}
\Description textual description of the link
\SessionId <SessionId>
\UserId <UserId>

The LinkServer's answer

\MessId MS_LinkId_OHP_1.0
\Subject "LinkId"
[\LinkId LinkId | \result a result message string]
\SessionId <SessionId>
\UserId <UserId>

Delete as well as update link messages are omitted as those are supposed to be done at the LinkService. It

is not clear that there is a simple interface to this function which could be provided at the client end.

Message "RequestService"

The RequestService message is a very general message that can be used by the Viewer to request a LinkService to do one of its services. The available services can be retrieved by the GetServices message.

\MessId MV_RequestService_OHP_1.0
\Subject "RequestService"
\Service name of the service
\AnchorId <AnchorId>
\LocSpec
\Presentation
\SessionId <SessionId>
\UserId <UserId>

Message "ClosingNode"

This message is sent from the Viewer to the LinkService when a node is closed by the user.

\MessId MV_ClosingNode_OHP_1.0
\Subject "ClosingNode"
\NodeId <NodeId>
\SessionId <SessionId>
\UserId <UserId>

Message "Update Anchors"

The UpdateAnchors message is sent by the Viewer to the LinkService when the Viewer wants to update the existing anchor list for a given NodeId.

\MessId MV_UpdateAnchors_OHP_1.0
\Subject "UpdateAnchors"
\NodeId <NodeId>
\Data {\AnchorID <AnchorId> \LocSpec <LocSpec>
       \Presentation \Service }+
\SessionId <SessionId>
\UserId <UserId>

Message "LaunchDocument"

We start the list of messages being sent by the LinkService to the Viewer with the LaunchDocument message. The LinkService might send this message for instance as the result of a follow link from another application.

\MessId MS_LaunchDocument_OHP_1.0
\Subject "LaunchDocument"
\NodeId <NodeId>
\DMS "SessionManager" | "LinkService"| DMS handle ???
\ReadOnly "True" | "False"
\SessionId <SessionId>
\UserId <UserId>

I think NodeId should be interpreted by the SessionManager. We should not have to deal with the DMS stuff here. LaunchDocument will not have DatacallBack. Instead it will have a DMS field which will have the value "SessionManager", "LinkService" or the name of the DMS which can interpret the DocId.

The Viewer might now get the document and - in case in can not deal with the type of document on its own - launch the appropriate Viewer. This will be initiated by advising the SessionManager to to this task.

The SessionManager may use a document management protocol (DMP) to get the document, or it may do it itself, or ask the LinkService. It may also use DMP to obtain any document attributes, such as nickname, document type and preferred Viewer. If it doesn't do this, then it will be necessary for the SessionManager to supply these values.

Alternatively, we may have loaded a document and wish to start Link services.

Message "DisplayAnchor"

The LinkService might request from the Viewer to display an anchor in case a document has changed. For this purpose the "DisplayAnchor" message is used.


\MessId MS_DisplayAnchor_OHP_1.0
\Subject "DisplayAnchor"
\SessionId <SessionId>
\Subject DisplayAnchor
\AnchorID <AnchorId> \Presentation
\UserId <UserId>

Message "DisplayLocSpec"

Equally, location specifications might wanted to be displayed by the server.


\MessId MS_DisplayLocSpec_OHP_1.0
\Subject "DisplayLocSpec"
\LocSpec \Presentation
\SessionId <SessionId>

Message "Interpret"

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.

The message being foreseen to deal with these scripts is the Interpret message. It is sent fom the LinkService to the Viewer in order to execute a script at the Viewer. If the script is not executable or any other type of error occurs this message should be answered by the Viewer with an "error" message.


\MessId MS_Interpret_OHP_1.0
\Subject "Interpret"
\ScriptLanguage language, e.g. Perl, JavaScript, ...
\Data the actual script
\SessionId <SessionId>
\UserId <UserId>

Message "NewAnchor"

The LinkService might independently inform the Viewer about new anchors. It can do so by sending "NewAnchor" messages.


\MessId MS_NewAnchor_OHP_1.0
\Subject "NewAnchor"
\Data {\AnchorId <AnchorId>\LocSpec
       \Direction {"AtoB" | "bidirectional"}
       \Presentation \Service}
\SessionId <SessionId>
\UserId <UserId>

Message "CloseNode"

This message is sent by the LinkService to a node that it wishes to automatically close e.g. in order to free a lock on a document.


\MessId MV_CloseNode_OHP_1.0
\Subject "CloseNode"
\NodeId <NodeId>
\UpdateNode {"True" | "False"}
\SessionId <SessionId>
\UserId <UserId>

The application is then responsible for closing the node itself, ensuring that it has updated any anchors and its contents if required by the UpdateNode tag. In case of any errors the Viewer should send back an error message.

Message "Error"

The "Error" message might be sent by any component. It is composed of the following structure:


\MessId M_Error_OHP_1.0
\Subject "Error"
\MessageId Id of message that caused the error
\ErrorSubject the type of error that occurred
\ErrorMessage the actual error string
\SessionId <SessionId>
\UserId <UserId>

6.4 Location Specifications

The definition of the location specifications has been quite a controversial issue (see Thread "opaque locspecs"). The two main camps being the "opaque" people on one side and the "HyTime" people on the other end of the spectrum. The argument towards opaque location specification is that for the LinkService location specifications should be opaque because the LinkService does not actually deal with them but rather wants to handle them as uninterpreted byte blocks. The HyTime (HyTime; 1992) followers on the other hand argue that at some point you actually have to have a specification so that an application is able to locate a specific position within a document's multimedia content. And if you have to define it use an existing standard that has been developed in order to deal with location specifications in an abstract, platform independent way.

We have learned from both viewpoints and have concluded that both are right. Therfore, we do not treat location specifcations as opqaue but we allow components to do so by simply ignoring the specifications.

A number of additionally criteria have been influencing our decision for the current definition of location specifiers:

A full HyTime implementation was considered to put too much onus on the application and also would be rather difficult to implement in a macro-like language. We thus agreed on a subset of location specifications as defined in HyTime.

The protocol is assumed to develop, thus in a first step the focus is on establishing the protocol and later on improving and enhancing it. However, we are convinced that without a basic agreement on the location specifications real interoperability between viewers is not possible.

As an example let us take the simplest data type, e.g. ASCII text. Most systems have developed similar fairly rich methods of locating strings. The location specification should include standards for these methods. Later, we might extend standards for such things as pictures, formatted text, videos etc. But opaque types will always be allowed and supported.

We also would like to stress the point that standarisation of location specifications is only partially subject to OHP. This can be compared to the situation with the document management protocol: strictly speaking this should not be part of the definition of OHP; however, if OHP should be really useful there have to be some common assumptions about both location specifications and document management functionality. For the current version of OHP we therefore provide these features so that OHP as a protocol can be implemented.

Now that we have explained in general our decisions we are able to define location specifications as part of OHP.

LocSpec =
\ContentType type, e.g., ASCII, binary
\Content Mime encoded text string
\LocData Loc

Location specification consist of a content type, the content itsef as well as the actual location data. LocData is defined as

Loc =  NameLoc | DataLoc | TreeLoc | PathLoc | ScriptLoc | NALoc

In the sequel we will explain these different basic types of location specifications. Again, it is up to the developer to introduce his own additional location specification or to add additional tags where necessry for specific applications. For most cases though, the proposed set of location specifications should be sufficient.

Name Space Locations

Name space locations are used to reference an object by its name. Names are expressed in OHP by NodeIds so the defintion of NameLoc is as follows:

NameLoc =
        \LocType "NameLoc"
        \NodeId <NodeId>

Data Locations

So-called data locations are coordinate locations, i.e., objects are addressed by their relative position to another object. DataLocs will be heavily used by OHP as most systems define anchors by relative positioning, for instance by keeping an offset. In order to know how this dimension specification should be interpreted, i.e. to get its data type, a quantum tag is defined. Count list follows the HyTime semantics of defining a dimenstion list. In particular, two markers define beginning and end of a node on an axis thus resulting in (number of axes * 2) markers.

A reverse counter is kept in order to do cross checking of validity of anchors. In case the expected object still can not be found an overrun behaviour can be specified: the error can simply be ignored, the markers can be truncated to the last unit on the axis or an error can be raised.

The HyTime time quantum "utc" expects items in the form yyyy-mm-dd hh:mm:ss.decimal, e.g., 1997-06- 06 17:59:22.6122.

DataLoc =
        \LocType "DataLoc"
      \NodeId <NodeId>
        \Quantum "string" | "int" | "byte" | "utc"
        \CountList list of Strings being interpreted by the viewer
        \RevCountList list of Strings being interpreted by the viewer
        \Overrun "ignore" | "error" | "trunc" overrun attribute

Tree Locations

Tree locations can be used for addressing a single object within a tree. The addressing is done in a way that on each level of the tree an object is selected by its position. These position numbers are expressed in CountList. For example a count list of "1 2 3" applied to a NodeId referencing a book would get the third section of the second chapter of the book (assuming that a book has a structure with chapters and sections).

TreeLoc =
        \LocType "TreeLoc"
        \NodeId <NodeId>
        \Overrun "ignore" | "error" | "trunc"
        \CountList list of numbers

Path Locations

As opposed to tree locations path locations are used to address a range of nodes by a path. This is done by addressing a tree as though it were a matrix in which the rows are the levels of the tree and the columns are the paths. Therefore the count list of a path location consists of an even number of pairs: the first pair identifies the columns (i.e. the paths to the leaves) and the second pair selects the rows.

PathLoc =
        \LocType "PathLoc"
        \NodeId <NodeId>
        \Overrun "ignore" | "error" | "trunc"
        \CountList list of numbers

Script Locations

OHP does not define a specific query mechanism for addressing locations (as thus for instance HyTime with the standard DSSSL Query Language, SDQ). However, by allowing script locations we define a way for those Hypermedia systems that use scripts to identify and address locations at the client's side.

ScriptLoc =
        \LocType "ScriptLoc"
        \Script viewer executable script

Inaccessible Locations

An idea borrowed from HyTime is to address data that is currently not accessible. This could be a printed book which is not available on-line, a radio broadcast or even a person or an organization. The point is that it might in some cases make sense to reference these nodes without having a Viewer for them. Instead, the Viewer could display a notification string, stating for example where to find a book in a shelf in a library. We call this location specification NALoc for "not accessible" location.

NALoc =
        \LocType "NALoc"
        \Loc string as description of the object and its physical location

6.5 Presentation Specification

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 the LinkService 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.

We are aware that strictly speaking presentation styles should not be defined within OHP (Anderson, 1997). However, as is true for the document management part and also for the location specifications, in order to make OHP really useable in the first phase a standardised agreed way of expressing presentation specifics has to be found.

\Presentation [\Colour colour][\style style]
              [\visibility "true"| "false"]

Following the original proposal we suggest a triplet of colour, style, visibility, each of which is optional. The above defintion allows us to only put these things if we have them, and we could also add other tags if needed. We will define some tag values which will be understood.

We assume that the eight primary computer colours are supported, i.e. blue, cyan, green, magenta, orange, pink, red and yellow.

As minimal subset of styles we define flashing, bold, italic, outlined and shaded.

7. Example Scenarios

In this section we consider, by reference to some different types of hypermedia viewers, the way these applications might use the OHP protocol. In order to allow readers to 'play' with OHP and to better visualize the communiction process we have developed a small Java applet that should help in understanding OHP.

Try out OHP!

The following simple applet is based on the assumptions we have made about the components being involved in an OHP scenario. On the OHP level we thus only have two components, Viewer and LinkService, that talk OHP to each other. The communication layer is not shown in the applet.

In order to play with OHP select a scenario and walk through it by pressing 'start'.

Fig.: Java Applet allowing to play with OHP

8. Related Work

8.1 Protocol Extension Protocol (PEP)

The World-Wide Web Consortium proposes a standardised way to extend the HyperText Transfer Protocol. This extension is called Protocol Extension Protocol (PEP, Nielsen, 1997).

PEP should be used for situations where applications require more facilities than the standard version of HTTP provides, from distributed authoring, collaboration and printing, to various remote procedure call mechanisms.

The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of HTTP clients and servers by software components. The PEP mechanism is to associate each extension with a URI, and use a few new header fields to carry the extension identifier and related information from HTTP clients, through proxies and intermediaries, to servers, and back again.

From an OHP point of view PEP could be used in the communications layer which is represented by the SessionManager component. OHP itself however, is on a higher level and its focus is different to that of PEP being based on HTTP.

8.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 Apple Event Model (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.

9. Summary and Conclusion

We sum up what we have proposed, conclude. List of open issues:

Collaboration

Transaction Semantics

Acknowledgements

The OHS community, all that have contributed in any form. Special thanks to Pete Nürnberg, Ken Anderson, Richard Taylor.

References

Kenneth M. A. A Critique of the Open Hypermedia Protocol. 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997. Available as http://www.daimi.aau.dk/~kock/OHS- HT97/Papers/anderson.html [1997 June 20].

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., 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 [1997 June 20].

Davis, H.: Channels in OHP. Thread in OHS Mailing List (1997 June 6) Available as http://www.csdl.tamu.edu/ohs/archive/0032.html [1997 June 20].

Goose S., Lewis A., Hugh D. OHRA: Towards an Open Hypermedia Reference Architecture and a Migration Path for Existing Systems. 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997. Available as http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/goose.html [1997 June 20].

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

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

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.

Nürnberg, P.: opaque locspecs. Thread in OHS Mailing List (1997 April 17) Available as http://www.csdl.tamu.edu/ohs/archive/0023.html [1997 June 20].

Open Document Management API (ODMA): Open Document Management API Version 1.5. Available as http://www.aiim.org/odma/odma15.htm [1997 June 20].

PEP - an Extension Mechanism for HTTP: W3C Working Draft 28 April 1997. Edited by Henrik Frystyk Nielsen. Available as http://www.w3.org/TR/WD-http-pep-970428 [1997 June 20].

Reich, S.: How OHP's LocSpecs could benefit from ISO/IEC 10744. 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997. Available as http://www.daimi.aau.dk/~kock/OHS- HT97/Papers/reich.ps [1997 June 20].

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

Taylor, R. N. Response: A Draft Proposal for a Standard Open Hypermedia Protocol. 2nd Workshop on Open Hypermedia Systems, Washington, March 1996. Available as ?????????????????? [1997 June 20].

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. 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. An OHP application must also provide an interface to allow anchors to be updated e.g. after document editing.