Fig.1: Components and Layers in OHP Definition
Working Draft 2.0 20th June 1997
Authors
Hugh Davis
The Multimedia Research Group
Dept. of Electronics and Computer Science
The University of Southampton
UK, SO 17 1BJ email hcd@ecs.soton.ac.uk
Sigi Reich*
Dept. of Information Systems
University of Linz
A-4040 Linz, Austria
email sre@ifs.uni-linz.ac.at
Antoine Rizk
Euroclid
France
email Antoine.Rizk@inria.fr
Previous Versions
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.
OHP is a protocol which allows a client side application program to communicate with server side programs about the basic hypertext objects, namely anchors, links, nodes, scripts and presentations.
Currently, open hypermedia systems tend to support only their private protocol, and as a result each system developer must also develop client side applications to talk in this protocol, which is a significant task.
An application program which talks in OHP will be able to talk to any linkserver, on the internet for example, about hypertext objects. Currently this would be achieved by providing some shim program which would translate between OHP and the linkserver's native protocol. This means that once an application had been developed for some client architecture, it would be able to work with all linkservices. Similarly, programs with macro languages could be adapted to talk OHP.
However, the OHP protocol, if adopted, should lead to a new generation of linkservers, which would themselves be OHP compliant. We envisage that the community could use OHP as the basis for producing tools for a new generation of distributed linkservers and client applications on the internet, in much the same way as http defined the World Wide Web.
This paper describes Revision 2.0 of this protocol.
We have structured our contribution in three major parts. The first part reviews the concepts involved in hypertext and open hypermedia systems, and introduces the need for a protocol for communicating with linkservers. The second part deals with the actual definition of the protocol and points to example scenarios that show how we think that OHP should be used. The Appendices suggest standards for defining location specifications (where an item is), presentation specifications (what an item should look like) and document specifications (where a document is). These items are not strictly part of the protocol, but if the protocol is to be used to aid interoperability, then it is necessary to agree some standard.
In the Open Systems community the term open is generally assumed to mean that there is some interface through which it is possible to communicate with some system or subsystem, so that third parties may write new components which may communicate with these systems. This is also the assumption in open hypermedia systems, but because of the complex nature of hypermedia systems, the nature of these interfaces is inevitably more complex.
The open hypermedia community (Aßfalg, 1994, Wiil & Østerbye, 1994, Wiil, 1996, Wiil, 1997) have adopted a view that open hypermedia systems are not only those in which the components may be distributed across heterogeneous platforms, but also believe that such systems should provide hypermedia services to all applications on the desktop. Such systems should not be confined to simple models of hypertext, but should be extendible to work with new models, new data formats and new desktop applications. Users should not be confined to using passive browsers, but should be able to edit both content and structure (given appropriate permissions) and should be able to negotiate with linkservers about the sort of links to be provided.
The World Wide Web is an open system: it provides a protocol (HTTP) through which a browser may communicate across the internet with a server. The use of this protocol makes it possible for third parties to produce their own browsers and servers. However, the World Wide Web has not generally been considered an open hypermedia system, since the Hypertext (as embodied by the Href's within html) is very simple, and is entirely embedded within the html rather than held separately.
The Open Hypermedia Systems community has now reached a level of maturity where, following four workshops in the last three years, it feels ready to propose a standard protocol for communication between clients and linkservices. This protocol leans heavily upon the M2000 protocol (Rizk, 1991) developed for use with Multicard, and the Microcosm message model (Davis et al., 1994). 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.
The hypertext community has invested much time and effort in attempting to define hypermedia, and probably the most successful result is the Dexter model (Grønbæk & Trigg, 1996, Halasz & Mayer, 1994). In this section we attempt to define the terminology and model that is assumed by the hypertext community. This description attempts to be as inclusive as possible, but inevitably some systems have features will not easily fit within this description, e.g. transclusions in Xanadu (Pam, 1997).
The model of hypertext assumed in this paper is one in which servers hold links. These servers are known as linkservers.
A link is an object which represents a connection between anchors. A link may (or may not) have a type (e.g. "defines") and may (or may not) have a direction. A link that has a defined direction may only be traversed in that direction: others are traversable in either direction. There may be any number of anchors at either side of a link. In many systems traversing a link may cause some process to run as well as or instead of causing the focus to move to some point at the end of the link.
An anchor is an object which holds the attributes of the end of a link. Typically an anchor will hold the location specifier (LocSpec) and any presentation information. Anchor objects are typically also stored within the linkservice.
LocSpecs hold the information that defines the position at which some embodiment of the anchor should be displayed (sometimes known as the persistent selection).
Sometimes a link or anchor may have an associated script which is executed when the link or anchor is used.
For the purpose of this paper we shall distinguish between nodes and documents. A node is a wrapper object which holds the meta-data about some document (including the information about where to find the file or files which make up that document). A document is that content data which actually appears on the screen in the application program which the user is viewing.
An anchor is generally associated with one or more nodes, so that when the document associated with that node is viewed, the user is able to select that anchor.
Most linkservices store nodes as well as links and anchors. If the linkservice also stores the content data, then it may be referred to as a hyperbase, since it is a database storing the entire set of objects involved in the hypertext.
A linkservice is expected to provide a core set of linkservices which involve the creation, retrieval and use of links, anchors, nodes, scripts and presentations. It will also be expected to provide some level of document management, for example, informing the client the name of the file it must load and display in order to complete a link traversal.
Many linkservices provide extra services, which assist the user in information retrieval and navigation.
OHP is a protocol which allows communication between client side application programs and linkservers. The intention is that the basic protocol should be quite light weight so that it should be easy to adapt existing application programs at the source level, so that they can communicate in OHP. Hopefully it should also be possible to adapt existing programs such as Microsoft Word for Windows and Emacs using built in macro languages. Once an application can communicate in OHP it should be possible for it to communicate with any linkservice which understands OHP. Furthermore, we hope that the protocol is a good representation of the sort of messages which any linkservice will have at its core, so it should be easily possible to convert from OHP to a native protocol using a protocol shim program.
For the definition of the protocol we make some assumptions about the architecture. Note however, that we are not aiming and not claiming to define a reference architecture. The general picture we have in mind when defining OHP is as follows:
Fig.1: Components and Layers in OHP Definition
In defining OHP we abstracted different layers. On the top level an Application Program communicates using 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 is an application layer protocol: it is not concerned with the mechanics of how a connection is achieved between a particular application and a particular linkservice, or how a message is routed between the components. The protocol is completely asynchronous, in that a client may send a request to a server. It will not, however, wait for a reply. When the server is ready it will send a message, which is the reply. However, the communication of these messages may be through a permanent connection between the client and server, or each message may establish its own connection (e.g. UDP): the method of communication is outside the reference of this protocol.
However, there is a problem that impedes the simplicity of the model which has the application program communicating directly with the linkservice. In practice all those who have implemented linkservices have identified the need for some component on the client side which is present throughout the hypertext session. (Goose et al., 1997) called it the "Runtime", (Wiil and Leggett, 1996) call it the "Tool Integrator" and in the original version of this protocol (Davis et al., 1996) it was called the "Communication Protocol Shim". However, we prefer, now, to call it the session manager. The session manager is responsible for handling all communications to and from the linkservice which are concerning topics which are not the direct responsibility of any one application on the client side.
In particular, the responsibilities of the session manager will always include starting an application (with its data) when required to by the linkservice (e.g. as the result of traversing a link to a document which must be handled by some application which is not currently running). This function is necessary as in heterogeneous systems it is not always possible for a server application to start a client on a remote machine.
There are many other tasks that might need to be carried out on the client side, which include such tasks as
At present there is no particular reference architecture on which OHP must operate, so for the moment we must accept that initially system designers will put different responsibilities upon session managers, so clients will not necessarily be portable from one linkservice to another. The establishment of a reference architecture will be one of the first tasks to undertake once a reasonable set of OHP clients have been implemented, so that the responsibilities of the session manager can be more clearly defined. Work on the reference architecture has already begun (Goose et al., 1997, Grønbæk & Wiil, 1997, Wiil & Whitehead, 1997).
Besides the components application program, linkservice and session manager there is a fourth component, the Document Management System (DMS). We are convinced that an additional protocol - a document management protocol (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.
An important aspect of any hypermedia system is to define the position of an anchor in a document, to define how an anchor should appear, and to specify how to fetch a document. From the point of view of the protocol, such information is opaque For example, a program might indicate the fact that it wants to display an anchor as blue, by storing the integer "8" as its presentation specifier. If only this application need to interpret this integer at a later time, then the actual representation is unimportant. However, if we wish to make these specifiers interchangeable so that other applications can interpret them, then we must agree a standard. A similar argument applies to location specification and document specification. Appendices A, B and C introduce our first attempts at such standards. We should emphasise, however, that use of these standards is not currently a requirement of OHP.
Before diving into the details of the protocol we thought it would be useful to give a higher level description of a session. Let us start by assuming that the linkservice has just received a message requiring it to follow a link to an anchor which is at a position some distance through a text document. There is no application which handles text documents currently running on the client. The chain of events might now proceed as follows.
OHP is a peer to peer asynchronous protocol. Messages may be sent by either the linkservice or by the application program. 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 application program and those sent by the linkservice.
For actually defining the mechanics of OHP we will follow a Backus-Naur Form (EBNF) as is for instance done in Internet drafts. We use the following constructs:
- name = definition
- "literal"
- {elem1 | elem2}
- {elem}*
- {elem}+
- [elem]
- <elem>
- ELEM
Additionally we assume the following rules (the US-ASCII coded character set is defined by ANSI X3.4-1986):
- CHAR =
- UPALPHA =
- LOALPHA =
- ALPHA = UPALPHA | LOALPHA
- DIGIT =
- CTL =
- CR =
- LF =
- SP =
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.
The tags that should occur in each message are explained in the protocol definition. They may be presented in any order. The protocol is designed such that if tags are missing, the system will attempt to work with the remaining information, and if extra undefined tags are present, systems that do not understand these tags will simply ignore them. 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.
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" of OHS discussion list). 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.
Every message will have a message header. A message header will contain information about the transaction that both sides of the communication channel may from time to time need to examine. It is not immediately clear that all of this information is essential, but there is a general consensus that parts of this information will, at times, be necessary.
MessageHeader = MessageID VersionID SessionId UserID. MessageID = "\MID " <a unique identifier for the particular message>
Probably this will be realised by a time stamp.
VersionId = "\VID " <current version of the protocol>
E.g. "2.1.Southampton" would indicate version 2.1 of the OHP protocol with Southampton extensions. The X.X part is essential, and the remainder can be ignored.
SessionId = "\SID " <a system dependant string which uniquely identifies
some "transaction" or "session">
We have not yet defined what a session is and we envisage that this will become significant when we attempt to deal with collaboration issues.
UserID = "\UID " <a system dependant string uniquely identifying the user>
The following table gives an overview of the basic messages that form the OHP protocol. The very left column defines the basic entities we have identified, i.e. anchor, link, node, script, presentation specification and list; the top line, i.e. the columns' labels, define the basic functions that can be processed on these entities. The functions are create, get, update, delete, add and remove item. Note that add and remove item will be list specific functions. Lists are introduced as a means to allow aggregation of entities. An anchor table for example would be dealt with in OHP as a list of anchors.
|
|
Create |
Get |
Update |
Delete |
GetList |
Execute |
Notification |
|
Anchor |
X |
X |
X |
X |
X |
X |
|
|
Link |
X |
X |
X |
X |
X |
|
|
|
Node |
X |
X |
X |
X |
X |
|
ClosingNode |
|
Script |
X |
X |
X |
X |
|
X |
|
|
PSpec |
X |
X |
X |
X |
|
|
|
|
Services |
|
|
|
|
X |
X |
|
Tab.1: OHP Message Table
The following messages may be sent by the linkservice:
The Error message might be sent by any component being involved in an OHP session.
We will now present the messages in detail and also give examples or additional comments where necessary to understand the semantics of the protocol.
Note that some of the messages might be rarely used, some even never. However, for reasons of consistency and symmetry of the protocol we defined and kept them as part of the standard.
When a new anchor has been created, the application program will send the following message to the linkservice. Generally an anchor will need a LocSpec and possibly a NodeId in order to define where the anchor is. PSpec and Service tags may well be defaults (e.g. blue and FollowLink respectively).
MESSHEADER
"\Subject CreateAnchor"
"\NodeId " <NodeId>
"\LocSpec " LOCSPEC
"\Direction " "Start" | "End" | "Bidirect"
"\Service " <Service>
"\PSpecId " <PSpecId>
"\Attributes "
{"\Name "<the attribute's name>
"\Value "<its value>}*
"\EndAttributes "
This message allows the application program to ask the linkservice for the current details of the anchor identified.
MESSHEADER "\Subject GetAnchor" "\AnchorId " <AnchorId>
Both messages, CreateAnchor and GetAnchor should be answered by the linkservice with an AnchorDef message.
MESSHEADER
"\Subject UpdateAnchor"
"\AnchorId " <AnchorId>
"\NodeId " <NodeId>
"\LocSpec " LOCSPEC
"\Direction " "Start" | "End" | "Bidirect"
"\Service " <Service>
"\PSpecId " <PSpecId>
"\Attributes "
{"\Name "<the attribute's name>
"\Value "<its value>}*
"\EndAttributes "
MESSHEADER "\Subject DeleteAnchor" "\AnchorId " <AnchorId>
The application program, while running, is expected to maintain the list of anchors. It may obtain this list, for a given node, by sending the following message.
MESSHEADER "\Subject GetAnchorList" "\NodeId " <NodeId>
The linkservice will reply by sending a "AnchorListDef" message.
When an anchor is activated (e.g. clicked ) the following message will be sent to the linkservice to request that whatever action is associated with that anchor (e.g. follow link) will be performed by the linkservice.
MESSHEADER "\Subject ExecuteAnchor" "\AnchorId " <AnchorId>
Sent by the linkservice on request from an application program (CreateAnchor or GetAnchor), or possibly the linkservice might send this autonomously in the case where a new anchor has been made by a user in a different session. The tag attributes is a list of attribute name and value pairs that contain all the attributes the linkservice knows about this object.
MESSHEADER
"\Subject AnchorDef"
"\AnchorId " <AnchorId>
"\NodeId " <NodeId>
"\LocSpec " LOCSPEC
"\Direction " "Start" | "End" | "Bidirect"
"\Service " <Service>
"\PSpecId " <PSpecId>
"\Attributes "
{"\Name "<the attribute's name>
"\Value "<its value>}*
"\EndAttributes "
Sent by the linkservice on request from an application program (GetAnchorList)
MESSHEADER
"\Subject AnchorListDef"
{"\Anchors "
"\AnchorId " <AnchorId>
"\NodeId " <NodeId>
"\LocSpec " LOCSPEC
"\Direction " "Start" | "End" | "Bidirect"
"\Service " <Service>
"\PSpecId " <PSpecId>
"\Attributes "
{"\Name "<the attribute's name>
"\Value "<its value>}*
"\EndAttributes "
"\EndAnchors "
}*
The linkservice might request from the application program to display an anchor for example, as the end of a link that has been followed.
MESSHEADER "\Subject DisplayAnchor" "\AnchorId " <AnchorId> "\PSpecId " <PSpecId>
The next set of messages is concerned with the manipulation of links. In practice most application programs used for viewing data will not handle links, but only anchors. This set of messages is provided partly in order to provide a symmetric set of messages handling all objects within the linkservice. However, we can envisage the case where a developer may wish to produce client side tools for the creation, manipulation and editing of links. From the point of view of the linkservice, it is unimportant whether the messages come from an application program or a link editor, and OHP should provide such messages.
MESSHEADER
"\Subject CreateLink"
"\XAnchors " "\Anchors " {"\AnchorId " <AnchorId>}+ "\EndAnchors "
"\YAnchors " "\Anchors " {"\AnchorId " <AnchorId>}+ "\EndAnchors "
"\Description " <Description>
"\Direction " "XtoY" | "Bidirect"
"\Type " <Type>
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
MESSHEADER "\Subject GetLink" "\LinkId " <LinkId>
Both messages, CreateLink and GetLink should be answered by the linkservice with a LinkDef message.
MESSHEADER
"\Subject UpdateLink"
"\LinkId " <LinkId>
"\XAnchors " "\Anchors " {"\AnchorId " <AnchorId>}+ "\EndAnchors "
"\YAnchors " "\Anchors " {"\AnchorId " <AnchorId>}+ "\EndAnchors "
"\Description " <Description>
"\Direction " "XtoY" | "Bidirect"
"\Type " <Type>
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
MESSHEADER "\Subject DeleteLink" "\LinkId " <AnchorId>
An application program may be interested in manipulating the list of all links. Note that future versions might include a context tag or a query tag in order to allow the client to specify which list of links to get. At present it will deliver all links in the linkservice.
MESSHEADER "\Subject GetLinkList"
The linkservice will reply by sending a "LinkListDef" message.
Sent by the linkservice on request from an application program (CreateLink and GetLink).
MESSHEADER
"\Subject LinkDef"
"\LinkId " <LinkId>
"\XAnchors " "\Anchors " { "\AnchorId " <AnchorId>}+ "\EndAnchors "
"\YAnchors " "\Anchors " { "\AnchorId " <AnchorId>}+ "\EndAnchors "
"\Description " <Description>
"\Direction " "XtoY" | "Bidirect"
"\Type " <Type>
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
Sent by the linkservice on request from an application program (GetLinkList).
MESSHEADER
"\Subject LinkListDef"
{"\Links "
"\LinkId " <LinkId>
"\XAnchors " "(" {"\AnchorId " <AnchorID>}+ ")"
"\YAnchors " "(" {"\AnchorId " <AnchorID>}+ ")"
"\Description " <Description>
"\Direction " "XtoY" | "Bidirect"
"\Type " <Type>
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
"\EndLinks "
}*
Again, as with links, we do not believe that the typical application program will be interested in manipulating nodes, but since nodes are handled by many linkservices, it seems appropriate to provide an interface to these objects so that developers may produce client side tools to manipulate them, such as browsers. The reader is reminded that in this context a node is a wrapper object that contains the meta-data about a document, rather than the document itself.
OHP is not a protocol for dealing with the actual storage and retrieval of documents. We assume that at some stage a protocol will be created for doing this (http is actually one such protocol, if limited in some aspects; the Open Document Management API proposes another see Open Document Management API, 1997). Yet, actually managing content as is represented by documents is what will make OHP a useable protocol. For the moment we will therefore abstract in the definition of the protocol by using an opaque string representing a document. ("DOCSPEC"). However, we also will make some assumptions which components are going to deal with this string in what way, and these are proposed in Appendix C Document Specification.
The following message will create a new node in the linkservice. This message is perhaps the one message related to nodes that might be used by an application program, in the case where a client side program had just loaded or created a new document and wished to register it with the linkservice.
\MESSHEADER
"\Subject CreateNode"
"\NodeName " <A title that the application may choose to display>
"\MimeType " <MimeType>
"\PreferredApp " <The name of the application which we would prefer to use with this data>
"\DocSpec " DOCSPEC
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
MESSHEADER "\Subject GetNode" "\NodeId " <NodeId>
Both messages, CreateNode and GetNode should be answered by the linkservice with a NodeDef message.
\MESSHEADER
"\Subject UpdateNode"
"\NodeId " <NodeId>
"\NodeName " <A title that the application may choose to display>
"\MimeType " <MimeType>
"\PreferredApp " <The name of the application which we would prefer to use with this data>
"\DocSpec " DOCSPEC
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
MESSHEADER "\Subject DeleteNode" "\NodeId " <NodeId>
An application program may be interested in manipulating the list of all nodes. Note that future versions of OHP might include a context tag or a query tag in order to allow the client to specify which list of nodes to get. At present it will deliver all nodes in the linkservice.
MESSHEADER "\Subject GetNodeList"
The linkservice will reply by sending a "NodeListDef" message.
Sent by the linkservice on request from an application program.
MESSHEADER
"\Subject NodeDef"
"\NodeId " <NodeId>
"\NodeName " <A title that the application may choose to display>
"\MimeType " <MimeType>
"\PreferredApp " <The name of the application which we would prefer to use with this data>
"\DocSpec " DOCSPEC
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
Sent by the linkservice on request from an application program (GetNodeList).
MESSHEADER
"\Subject NodeListDef"
{"\Nodes "
"\NodeId " <NodeId>
"\NodeName " <A title that the application may choose to display>
"\MimeType " <MimeType>
"\PreferredApp " <The name of the application which we would prefer to use with this data>
"\DocSpec " DOCSPEC
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
"\EndNodes "
}*
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:
This message is used to create a new script ID. Required parameters are the name of the script language as well as the actual script.
\MESSHEADER
"\Subject CreateScript"
"\Language " <name of the script language, e.g. JavaScript, etc.>
"\Data " <the actual script>
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
MESSHEADER "\Subject GetScript" "\ScriptId " <ScriptId>
Both messages, CreateScript and GetScript should be answered by the linkservice with a ScriptDef message.
\MESSHEADER
"\Subject UpdateScript"
"\ScriptId " <ScriptId>
"\Language " <name of the script language, e.g. JavaScript, etc.>
"\Data " <the actual script>
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
MESSHEADER "\Subject DeleteScript" "\ScriptId " <ScriptId>
A client may send this message to the server, in which case the server will execute the given script, or a linkserver may send this message to a client, in which case, if the client does not currently have the script identified, it will need to send a GetScript message back, in order to execute the script on the client.
MESSHEADER "\Subject ExecuteScript" "\ScriptId " <ScriptId>
Sent by the linkservice on request from an application program.
MESSHEADER
"\Subject ScriptDef"
"\ScriptId " <ScriptId>
"\Language " <name of the script language, e.g. JavaScript, etc.>
"\Data " <the actual script>
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
Alternative presentation of anchors is an important feature in some systems. OHP allows users to specify different presentations. From the point of view of OHP and linkservers, presentation specifiers (PSpecs) are opaque strings, which are interpreted by the application program. However, in order to allow for interoperability or application programs, and in order to allow server end scripts to change the presentation in a client, it is useful to attempt some standardisation of the content of the PSpec. This is discussed in Appendix B Presentation Specification.
MESSHEADER "\Subject CreatePSpec" "\PSpec " PSPEC
MESSHEADER "\Subject GetPSpec" "\PSpecId " <PSpecId>
Both messages, CreatePSpec and GetPSpec should be answered by the linkservice with a PSpecDef message. This ID then can be used as parameter in further message calls.
MESSHEADER "\Subject UpdatePSpec" "\PSpecId " <PSpecId> "\PSpec " PSPEC
MESSHEADER "\Subject DeletePSpec" "\PSpecId " <PSpecId>
Sent by the linkservice on request from an application program.
MESSHEADER "\Subject PSpecDef" "\PSpecId " <PSpecId> "\PSpec " PSPEC
The "GetServices" message is to be sent from application program to linkservice in order to know which additional services are available, above the standard set which manipulate anchors, links, nodes and presentations. The linkservice should answer this request with a "ServicesDef" message. Services are defined by a description and a service name.
MESSHEADER "\Subject GetServices"
The ExecuteService message is a very general message that can be used by the application program to request a linkservice to do one of its services. The available services can be retrieved by the GetServices message.
MESSHEADER
"\Subject ExecuteService"
"\Service " <name of the service>
"\NodeId " <NodeId>
"\LocSpec " LOCSPEC
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
Sent by the linkservice on request from an application program (GetServices).
MESSHEADER
"\Subject ServicesDef"
{"\Services "
"\Service " <name of the service>
"\Description " <a string which may be used to describe the service to a user>
"\EndServices "
}*
The minimum reply should include the service named "FollowLink", which all linkservers must handle. All other services are server dependant.
This message is sent from the application program to the linkservice when a node is closed by the user.
MESSHEADER "\Subject ClosingNode" "\NodeId "<NodeId>
The linkservice might send this message for instance as the result of a follow link from another application. Note the Location tag; it defines where the document is located and therefore allows the session manager or the linkservice to know how to interpret the NodeId. For further details on the issue of document management see Appendix C Document Specification.
MESSHEADER
"\Subject DisplayDocument"
"\NodeId "<NodeId>
"\Location " {"FileSystem" | "Internet"| "DMS" }
"\ReadOnly" {"True" | "False"}
Equally, location specifications might wanted to be displayed by the linkservice.
\MESSHEADER "\Subject DisplayLocSpec" "\LocSpec " LOCSPEC "\PSpecId " <PSpecId>
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.
MESSHEADER
"\Subject CloseNode"
"\NodeId "<NodeId>
"\UpdateNode "{"True" | "False"}
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 application program should send back an error message.
The "Error" message might be sent by any component. It is composed of the following structure:
MESSHEADER "\Subject Error" "\MessageId " <Id of message that caused the error> "\ErrorSubject " <the type of error that occurred> "\ErrorMessage "<the actual error string>
In this section we consider, by reference to some different types of hypermedia viewers, the way these applications might use the OHP protocol. We take the work the OHS group has been doing on scenarios as input and demonstrate how OHP can be used to deal with some of the scenarios.
The first scenario we consider is entitled "Navigational 1" (Nürnberg, Leggett, 1997). It is based on the idea that users want to build and/or browse "associations" between parts of data objects handled by their applications. Associations should be grouped into sets; whole association sets as well as single items in association sets might be created, deleted, opened, closed or merged. Let's see how OHP can be used in this scenario. Following the analysis given by the authors of "Navigational 1" we will go through the goals of the scenario step by step and investigate how these issues are dealt with in OHP.
In order to better demonstrate how OHP could be used for dealing with the requirements arising by the above scenario, we will assume the following subset of actions that show how to use OHP for navigation. This scenario is also available from the Java applet below by selecting "Navigational 1" from the choice menu.
Let's assume a user has started up his favourite text editor, selects a string and wants to follow any links associated with the selected string (for the scenario we assume that the answer includes simply one anchor, though OHP would be able to deal with more than one anchor). The ExecuteAnchor message results in an anchor referring to a spreadsheet file; the user's favourite spreadsheet application is launched and the file opened. The user selects one of the cells in the spreadsheet, defines it as an anchor, switches to an e-mail client, selects an e-mail message and defines this message as an anchor again. In a further step the user creates an association between the two anchors using an application independent application allowing her/him to do so (this application could part be the user interface component of the session manager).
These are the OHP messages to be sent:
The user selects a piece of text and chooses the FollowLink function from a menu. This results in the following message to be sent to the linkservice:
\MID 1700 \VID V1.0.Southampton \SID S02 \UID pete \Subject ExecuteAnchor \AnchorId 152.78.115.213:E:3334-1
The linkservice answers by a DisplayDocument message which is followed by a DisplayLocSpec message.
\MID 1701 \VID V1.0.Southampton \SID S02 UID pete
\Subject DisplayDocument
\NodeId 152.78.115.213:E:100
\Location DMS
\ReadOnly false
\MID 1702 \VID V1.0.Southampton \SID S02 \UID pete
\Subject DisplayLocSpec
\LocSpec
\ContentType ASCII
\Content "a string"
\LocType DataLoc
\NodeId 152.78.115.213:E:100
\Quantum int
\CountList 5 2
\RevCountList 1033 2
\Overrun error
\EndLocSpec
\PSpecId ps33
The user selects a string and defines a new anchor. This could be done by choosing a menu item that would result in the following message to be sent by the application program to the linkservice:
\MID 1755 \VID V1.0.Southampton \SID S05 \UID pete
\Subject CreateAnchor
\NodeId 152.78.115.213:E:100
\LocSpec
\ContentType ASCII
\Content "another string"
\LocType DataLoc
\NodeId 152.78.115.213:E:100
\Quantum byte
\CountList 46 8
\RevCountList 77 8
\Overrun error
\EndLocSpec
\Direction Start
\Service FollowLink
\PSpecId ps33
Lastly, user "Pete" creates an association using one of the anchors of the ExecuteAnchor (i.e. follow link) function and the newly created anchor:
\MID 1756 \VID V1.0.Southampton \SID S05 \UID pete
\Subject CreateLink
\XAnchors
\Anchors
\AnchorId 152.78.115.213:E:100-2
\EndAnchors
\BAnchors
\Anchors
\AnchorId 152.78.115.213:E:100-3
\EndAnchors
\Description "Pete's first link"
\Direction XtoY
\Type supports
And the linkservice would answer with a LinkId message which would confirm for Pete that his association has been created. The LinkId could be used for future references (or also be omitted by the application program).
\MID 1757 \VID V1.0.Southampton \SID S05 \UID pete
\Subject LinkDef
\XAnchors
\Anchors
\AnchorId 152.78.115.213:E:100-2
\EndAnchors
\BAnchors
\Anchors
\AnchorId 152.78.115.213:E:100-3
\EndAnchors
\Description "Pete's first link"
\Direction XtoY
\Type supports
\Attributes
\Name creationDate
\Value 1997-06-20 17:59:22.6122
\EndAttributes
In order to allow readers to 'play' with OHP and to better visualise the communication process we have developed a small Java applet that should help in understanding OHP.
The 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, application program 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. 2: Java Applet allowing to play with OHP
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).
According to the authors, PEP should be used for applications that require more facilities than the standard version of HTTP provides, from distributed authoring, collaboration and printing, to various remote procedure call mechanisms.
PEP is intended to work as follows:
From an OHP point of view PEP could be used in the communications layer which is represented by the session manager component. OHP itself however, is on a higher level and its focus is different to that of PEP being based on HTTP.
Following initial consultation within the OHS community, in this contribution we have introduced a revised version of OHP which we now feel is ready for publication and discussion within a wider community. In particular we believe that the internet community should now consider this proposal.
We have described our motivation in developing OHP, we have presented the various bits and parts of the protocol and have explained the assumptions we make for the underlying components. We have given example scenarios that show how OHP can be used.
We believe that the next stage in developing this protocol should involve
In attempting to solve the above problems, we believe that a number of further issues will become apparent and will need further attention. Those that we are currently aware of are:
The editors would like to thank the OHS community, all of whom have contributed to this draft, but special thanks are due to Pete Nürnberg from Texas A&M University, , Ken Anderson and Richard Taylor from University of California Irvine, Randy Trigg from Xerox Parc , Palo Alto, Uffe Kock Wiil from the University of Aarhus, Denmark, and Ian Heath, Mark Weal, Andy Lewis, Stuart Goose and many others from the University of Southampton, UK, who contributed significantly to the first version of this draft.
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. Therefore, we do not treat location specifications as opaque 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:
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 standardisation 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>
LOC
"\EndLocSpec "
Location specification consist of a content type, the content itself as well as the actual location data. LOC 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 necessary for specific applications. For most cases though, the proposed set of location specifications should be sufficient.
Name space locations are used to reference an object by its name. Names are expressed in OHP by NodeIds so the definition of name locations is as follows:
NAMELOC = "\LocType NameLoc" "\NodeId " <NodeId>
So-called data locations are co-ordinate locations, i.e., objects are addressed by their relative position to another object. Data locations 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 dimension 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 application program>
"\RevCountList " <list of Strings being interpreted by the application>
"\Overrun " { "ignore" | "error" | "trunc" }
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>
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>
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" "\ScriptId <ScriptId>
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 organisation. The point is that it might in some cases make sense to reference these nodes without having a application program for them. Instead, the application program 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" "\Location " <string as description of the object and its physical location>
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 linkservice.
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 linkservice 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 application program specific. i.e. the application program 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 application program 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 application program.
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.
PSPEC =
"\PSpec "
"\Name " <a string>
["\Colour " <colour>]
["\Style " <style>]
["\Visibility " "true" | "false"]
"endPSpec "
Following the original proposal we suggest a triplet of colour, style, visibility, each of which is optional. The above definition 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. black, blue, cyan, white, magenta, green, red and yellow.
As minimal subset of styles we define flashing, bold, italic, outlined and shaded.
We recommend that the following definition for DOCSPEC be used, until such time as further work has improved on this.
DOCSPEC =
"\DocSpec "
"\Name " <the document's name, typically a file name, a URL or a DMS handle>
"\Location " "FileSystem" | "Internet" | "DMS"
"\Attributes "
{"\Name " <the attribute's name>
"\Value " <its value>}*
"\EndAttributes "
"\EndDocSpec "
For example we might have
\DocSpec \Name N:\\DOCS\\FILE.TXT \Location FileSystem
\Attributes
\Name owner \Value hcd
\EndAttributes
\EndDocSpec
or
\DocSpec
\Name http://www.ecs.soton.ac.uk/~hcd
\Location Internet
\EndDocSpec
As far as the linkservice is concerned the DOCSPEC information is opaque. It stores the string, and when the node is required it sends this back. The client side is expected to provide some component which will be able to interpret this string in the cases where the client is asked to display a document. Typically this will be the session manager, which will then organise to actually get the document from the file system or the Internet or the document management system that it is using (which may actually be the linkservice is if the linkservice is a hyperbase).
This section briefly summarises the changes of this version of the protocol to the last version of OHP (OHP: A Draft Proposal for a Standard Open Hypermedia Protocol (Levels 0 and 1: Revision 1.2 - 13th March. 1996)).
The previous version of the protocol allowed that the linkserver provided a list of all the services that it provided. OHP made no assumptions about the services that would be provided by any particular server. However, after some discussion, the community agreed that some services were present in all linkservices, and that there were benefits to standardising their names so that programs could be written that specifically called these services. This situation becomes almost irrelevant in this version of the protocol, since all services to do with object creation now have their own independent message (e.g. CreateAnchor is a message, rather than having to call RequestService with a CreateAnchor Service tag, as was done in the first version). The only change we have thus had to make is to standardise a service called "FollowLink", which all linkservers should provide as a minimum.
Anderson, K.M. A Critique of the Open Hypermedia Protocol. 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997. Available as http://www.da imi.aau.dk/~kock/OHS-HT97/Papers/anderson.html [1997 June 20].
Aßfalg, R. (ed.). The Proceedings of the Workshop on Open Hypertext Systems, Konstanz, May 1994.
Davis, H.C., Knight, S.K. & Hall, W. Light Hypermedia Linkservices: 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. & Davis, H. 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
Grønbæk, K. & Trigg, R.H. From Embedded References to Link Objects: Toward a New Data Model for Open Hypermedia Systems. In: The Proceedings of Hypertext '96. ACM 1996
Grønbæk, K. & Wiil, U.K. Towards a Reference Architecture for Open Hypermedia. 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997. Available as http://www.dai mi.aau.dk/~kock/OHS-HT97/Papers/gronbak.html [1997 June 20].
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.
Haake, J. Collaboration via OHS. A Scenario available from the OHS Working Group Scenario Page http://www.csdl.tamu.edu/ohs/scenarios/collab/ [1997 June 20].
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.
Nielsen, H.F. 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].
Nü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].
Nürnberg, P. & Leggett, J. Navigational 1. A Scenario available from the OHS Working Group Scenario Page http://www.csdl.tamu.edu/ohs /scenarios/nav1/ [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].
Pam, A. Fine-Grained Transclusion in the Hypertext Markup Language. Available as
http://xanadu.com.au/xanadu/draft-pam-html-fine-trans-00.txt;internal&sk=1A3F7418950 [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.a au.dk/~kock/OHS-HT97/Papers/reich.ps [1997 June 20].
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
Taylor, R. N. Response: A Draft Proposal for a Standard Open Hypermedia Protocol. 2nd Workshop on Open Hypermedia Systems, Washington, March 1996. Available from the Author.
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.
Wiil, U.K. The Proceedings of the 2nd Workshop on Open Hypermedia Systems. Available as http://www.daimi.aau.dk/~kock/OHS-HT96, Washington D.C., March 1996.
Wiil, U.K. The Proceedings of the 3rd Workshop on Open Hypermedia Systems. Available as http://www.daimi.aau.dk/~kock/OHS-HT97, Southampton, U.K., April 1996.
Wiil, U.K. & Whitehead, J.E. Interoperability and Open Hypermedia Systems. 3rd Workshop on Open Hypermedia Systems, Southampton, April 1997. Available as http://www.daimi. aau.dk/~kock/OHS-HT97/Papers/wiil.html [1997 June 20].