Fig.: Components and Layers in OHP Definition
Authors
Hugh Davis, Sigi Reich, Antoine Rizk
Previous Versions
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:
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.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)
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:
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
The following table gives an overview of the messages that are dependent in
that a Viewer's request results in a LinkService's answer. 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 those customized messages will be understood at the other end!
| Viewer Requests | LinkService Replies |
| GetServices | Services |
| GetNodeId | NodeId |
| CreateNode | NodeId |
| CreateLinkId | LinkId |
| 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 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
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
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).
Now that we have the document itself and an appropriate application for the document, the application needs to know
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>
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.
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>
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>
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>
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.
\MessId MS_DisplayAnchor_OHP_1.0 \Subject "DisplayAnchor" \SessionId <SessionId> \Subject DisplayAnchor \AnchorID <AnchorId> \Presentation \UserId <UserId>
Equally, location specifications might wanted to be displayed by the server.
\MessId MS_DisplayLocSpec_OHP_1.0 \Subject "DisplayLocSpec" \LocSpec \Presentation \SessionId <SessionId>
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:
\MessId MS_Interpret_OHP_1.0 \Subject "Interpret" \ScriptLanguage language, e.g. Perl, JavaScript, ... \Data the actual script \SessionId <SessionId> \UserId <UserId>
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>
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.
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>
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:
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 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. 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 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
PathLoc = \LocType "PathLoc" \NodeId <NodeId> \Overrun "ignore" | "error" | "trunc" \CountList list of numbers
ScriptLoc = \LocType "ScriptLoc" \Script viewer executable script
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.
In order to play with OHP select a scenario and walk through it by pressing 'start'.
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.
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:
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.
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].
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.