Fig.: Components and Layers in OHP Definition
Authors
Hugh Davis, Andy Lewis, Sigi Reich, Antoine Rizk
Previous Versions
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:
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 components understands and answers OHP requests. Typically though this component would be a LinkServer or a HyperBase. For the remainder of this document we will refer to it by LinkService.
OHP abstracts from the communication layer. However, there has to be a component that establishes connections, '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 [ODMA97] 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.
Form of the Protocol
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 classes of messages to be considered; those sent by the
Viewer and those sent by the LinkService.
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 constructs such as
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.
Additionally we assume the following rules (the US-ASCII coded character
set is defined by ANSI X3.4-1986 [21]):
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)
We can now begin to define the protocol.
Definitions
Message Header
As opposed to previous versions of this draft, which define a Channel as an identifier for messages, we have defined a dedicated message header. 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
\SessionId a byte string ?? do we have a unique id or
not?? not yet sure about that
MessId uniquely identifies this type of message and gives OHP version information. The subject field is considered to be particularely helpful in cases of the components cannot understand a message and could then at least provide additional information about the message.
Besides basic header information there is a number of fields that will be present in almost all messages but that does not have to be understood by the LinkService. These fields comprise
\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 rather by a reference called NodeId. A NodeId has to be unique within a given usage scenario. However, from a protocol perspective the NodeId is opaque.
| Viewer Requests | LinkService Replies |
| GetServices | Services |
| GetNodeId | NodeId |
| CreateNode | NodeId |
| GetAnchorTable | AnchorTable |
Additionally, the Viewer might send the following messages:
The LinkService might send the following messages to the Viewer
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. >
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 OHP as a message and give version information. Equally, service originated messages start with MS short for "message from service".
\MessId MV_GetServices_OHP_1.0 \Subject "GetServices" \SessionId \UserId
The linkservice will reply with
\MessId MS_Services_OHP_1.0
\Subject "Services"
\SessId??
\Data
{\Service the name of the service
\Description a description of the service in the local language}+
\UserId
We have identified a number of default services that each LinkService supporting OHP has to provide. All OHP compliant applications must provide at least the following services in the above list
Any of these services may be requested by
\MessId MS_RequestService_OHP_1.0 \Subject "RequestService" \Service the name of the service \AnchorID [] \LocSpec [] \Presentation \SessionId \UserId
An OHP application must also provide an interface to allow anchors to be updated e.g. after document editing.
We do
\MessId MV_GetNodeId_OHP_1.0 \Subject "GetNodeId" \DocumentName the name of the document \SessionId ?? \UserId
The LinkServer will answer this request with
\MessId MS_NodeId_OHP_1.0 \Subject "NodeId" \SessionId \NodeId NodeId \UserId
If the NodeId is "Null", then the document is currently unknown to the LinkService, and it is the responsibility of the SessionManager to register this node (are there cases where it could raise an error?). The SessionManager would thus send
\MessId MV_CreateNode_OHP_1.0 \Subject "CreateNode" \SessionId \DocumentName the name of the document \UserId
The linkserver will eventually send back a NodeId message (see above). As a follow up, the SessionManager should then send a SetDocumentAttributes (DMP) message.
\MessId MV_SetDocumentAttributes_OHP_1.0
\Subject "SetDocumentAttributes"
\SessionId ??
\NodeId <NodeId>
\Attributes
{\name the attribute's name
\value the value}+
\UserId
The LinkService might send this message (e.g. as the result of a follow link from another application)
\MessId MS_LaunchDocument_OHP_1.0 \Subject "LaunchDocument" \SessionId ?? \NodeId <NodeId> \DMS "SessionManager" | "LinkService"| DMS handle ??? \ReadOnly "True" | "False" \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. Definition, ... is thus not part of OHP.
It may use a document management protocol (DMP) to get the document, or it may do it itself, or ask the LinkService. The SessionManager 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.
Altrenatively, we may have loaded a document and wish to start Link services.
\MessId MV_UpdateAnchors_OHP_1.0
\Subject "UpdateAnchors"
\SessionId ??
\NodeId <NodeId>
\Data {\AnchorID <AnchorId> \LocSpec <LocSpec>
\Presentation <Presentation> \Service ???}+
\UserId
Whereas the interface to link creation (joining n to m anchors and defining direction, scope etc) would probably be best implemented just once in the Session Manager.
We will need a Create Link message.
\MessId MV_CreateLink_OHP_1.0
\Subject "CreateLink"
\SessionId ??
\AAnchors {\AnchorID <AnchorID>}+
\BAnchors {\AnchorID <AnchorID>}+
\Direction "AtoB" or "Bidirectional"
\Description <text string>
\UserId
(Delete link is omitted as it can 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)
Now that we have the document itself and an appropriate application for the document, the application needs to know
The following message is sent to get the anchors for a given document. Note that the message is assynchronous, 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 concatting the tables).
\MessId MV_GetAnchorTable_OHP_1.0 \Subject "GetAnchorTable" \SessionId ?? \NodeId <NodeId> \SessionId \UserId
The LinkService should answer this with the "AnchorTable" message.
\MessId MS_AnchorTable_OHP_1.0
\Subject "AnchorTable"
\SessionId ??
\NodeId <NodeId>
\Data {\AnchorID <AnchorId> \LocSpec
\Direction \Presentation \Service}+
\UserId
The LinkService might also independently inform the Viewer about new
anchors. It can this by sending "NewAnchor" messages.
\MessId MS_NewAnchor_OHP_1.0
\Subject "NewAnchor"
\SessionId ??
\Data {\AnchorID \LocSpec \Direction
\Presentation \Service}
\UserId
The LinkService might also request from the Viewer to display an anchor. For this purpose the "DisplayAnchor" message is used (this is a French thing, isn't it ??????)
\MessId MS_DisplayAnchor_OHP_1.0 \Subject "DisplayAnchor" \SessionId ?? \Subject DisplayAnchor \AnchorID \Presentation \UserId
Equally, location specifications might wanted to be displayed by the server.
\MessId MS_DisplayLocSpec_OHP_1.0 \Subject "DisplayLocSpec" \SessionId ?? \LocSpec \Presentation \UserId
Again a French thing: interpret script
\MessId MS_Interpret_OHP_1.0 \Subject "Interpret" \SessionId ?? \ScriptType \Data
If the contents of a document have changed during a session (or if it is a new document) it may be necessary to store the contents in the DMS (or Hyperbase). We will need a StoreDocument thing in the DMP for this.
This message is sent when a node is closed by the user.
\MessId MV_ClosingNode_OHP_1.0 \Subject "ClosingNode" \SessionId ?? \NodeId <NodeId> \UserId
This message is sent by the LinkService to a node that it wishes to automatically close. ??? Should'nt that be answered by a 'successful' or 'don't want to' or a simple 'cannot'.
\MessId MV_CloseNode_OHP_1.0 \Subject "CloseNode" \SessionId ?? \NodeId <NodeId> \UpdateNode "True" / "False" \UserId
The application is then responsible for closing itself, ensuring that it has updated any anchors and its contents if required by the UpdateNode tag.
(Messages that may be sent either way. )
\MessId M_Error_OHP_1.0 \Subject "Error" \SessionId ?? \MessageId Id of message that caused the error \ErrorSubject \ErrorMessage \UserId
(Note that the protocol is completely extensible in that other
messages may be invented, and other tags inserted, and other values given
to a tag. Of course there is no guarantee that they will be understood at
the other end!)
Location Specifications
Pete argues that LocSpecs should be opaque byteblocks. Indeed, as far as OHP itself is concerned they could be.
On the other hand, if every applications makes its own LocSpec, applications will never be interchangeable.
We believe that a combination of both appraoches is necessary.
If we take the simplest data type, e.g. ASCII text, we have all developed similar fairly rich methods of loacting strings. The LocSpec 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 OK.
The LocSpec standard, like DMP, is separate from OHP, but in order to be useful, we are defining some of it now.
We will use the Sigi approach but add optional extra tags at all levels.
We describe why Pete and Randy are both right. We motivate for the usage of HyTime [ISO92]. We introduce locspecs in general. we give a definition with a detailed description and examples.
LocSpecs in OHP are defined as follows:
LocSpec =
\ContentLength an Integer given the total length of this LocSpec in bytes
\ContentType type, e.g., ASCII, binary
\Content Mime encoded text string
\LocData Loc
where "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 necessry 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 defintion of NameLoc is as follows:
NameLoc =
\LocType "NameLoc"
\NodeId <NodeId>
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. A reverse counter is kept in order to do cross checking of validity of anchors. In case the expected object still cannot be found an overrun behaviour can be specified: the error can simply be ignored, the markers be truncated to the last unit on the axis or an error can be raised.
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, e.g. trunc, ignore, error
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 obejct is selected by its position. These position numbers are expressed in CountList.
\TreeLoc
can be used for addressing a single node of a tree in the
standard manner by selecting a node on each level by its position geiven
by an integer. Example with a book assuming that a book has a structure
with chapters and sections "1 2 3" would get the third section of the
second chapter of a book.
\LocType "TreeLoc"
\NodeId <NodeId>
\Overrun "ignore" | "error" | "trunc"
\CountList list of numbers
\PathLoc
ScriptLoc =
NALoc :=
\LocType "NALoc"
Additional specifications:
count list follows the HyTime semantics of defining a dimenstion list. In
particular, two markers define beginning and end on an axis thus resulting
in number of axes * two markers. Example:
overrun behaviour specifies what to do in case of an overrun, i.e., in
case the expected item cannot be found at the given position. This fact
could be simply ignored, an error raised or the count list be truncated in
that its items point to the last position.
utc expects CountList items in the form yyyy-mm-dd hh:mm:ss.decimal
format, e.g., 1997-06-06 17:59:22.6122.
Again we have to do some of this. I originally
suggested triplet of Colour, style, visibility.
The above 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.
How about RED, BLUE, GREEN, (the eight primary computer colours)
Flashing, bold, italic, outlined, shaded,
The World-Wide Web Consortium proposes Protocol Extension Protocol (PEP).
HTTP is used increasingly in applications that need more facilities than the standard
version of the protocol 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. The kind of extensions capable of being introduced by PEP are
envisioned as ranging from:
a simple qualification of a normal HTTP transaction;
changes to HTTP semantics;
new HTTP syntax, encoding or marshaling;
initiation of HTTP-based protocols for new applications; to...
protocols, which once initiated by a PEP transaction, run completely independently
of HTTP.
PEP interacts with specific features of HTTP/1.1 [RFC2068] including scoping rules and
cache semantics. PEP is intended to be compatible with HTTP/1.0 [RFC1945] inasmuch as
HTTP/1.1 is compatible with HTTP/1.0, see [RFC2068], Section 19.7. It is proposed that
the PEP extension mechanism is included in future versions of HTTP.
Kenneth M. Anderson: 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.
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.
ISO - International Organization for Standardization: Information Technology -
Hypermedia/Time-based Structuring Language (HyTime), ISO/IEC 10744, 1992.
Open Document Management API (ODMA): Open Document Management
API Version 1.5. Available as http://www.aiim.org/odma/odma15.htm.
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.
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.
\LocType "TreeLoc"
\Overrun "ignore" | "error" | "trunc"
\NodeId
\LocType "ScriptLoc"
\Script viewer executable script
\Loc string as description of the object and its physical location
Presentation Specification
\Presentation [\Colour colour][\style style][\visibility
true/false]
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.
Acknowledgements
The OHS community, all that have contributed in any form.
References