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

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

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

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

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

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

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

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

LocSpec ::=

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

We can now begin to define the protocol.

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

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

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

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

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

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

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

The viewer might now request the services

\Subject GetServices \Channel #9

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

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

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

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

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

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

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

\Subject Closing \Channel #9

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

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

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

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

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

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

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

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

The linkservice might follow it original LaunchDocument request with:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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