1 Introduction
The dominance of the World Wide Web browser as the preferred interface for an increasing number of tasks indicates the wide acceptance of the benefits of hypertext functionality for task-oriented applications. The linking and browsing capabilities associated with hypertext navigation are increasingly expected to be part of the interface of any information delivery system.
It is an impossible task, however, for a single information delivery system to meet the needs of all users or to support all hypertext tasks. Some or all of the functionality provided by an application must be tailorable because:
- The requirements of innumerable users with varied specialized interests cannot be incorporated into a single monolithic system.
- Specialized functionality does not freeze in its present state but continues to change as new technologies and new ideas emerge. Task-oriented systems need to be able to accommodate such changes to avoid obsolescence.
- Applications need to adapt to changes in user expectations and requirements.
There are three possible approaches to integrating third-party applications and hypertext functionality:
- retrofitting applications with hypertext functionality
- building hypertext systems that customize access to third-party applications
- building environments (frameworks) in which components can be put together to cooperate as needed to build hypertext applications
Customized access to third-party applications requires that the hypertext system incorporates customized application programming interface (API) access to the applications. It is difficult to rationalize the expense of building customized access to third-party software for individual hypertext systems. For instance, changes in the external software could require changes in the hypertext systems. An example is the proxy program approach. Proxy programs sit between the hypertext link service and the viewer, translating the actions in one system to actions that the other can understand. The disadvantage is that a proxy must be written for each application to be integrated. Proxy programs also have difficulty in reconciling advertised link endpoints with data displayed by the application, so only dynamically-computed, non-advertised links can be provided. In [DAVK94] buttons representing links are placed in the toolbar of the proxy program, allowing a sort of advertised link, although the connection between the clickable button and the actual linked object may not be clear.
An alternative solution would be to build hypermedia management systems (HMSs) that
cooperate with third-party software. Instead of putting hypermedia into third-party
applications, we aim to make the applications available to hypertext applications
via a HMS. Open hypertext systems have taken this approach, and protocols to
accomplish the design and implementation of HMSs that include third-party
applications are under development. [WIIL97]
The
cooperative approach that we favor is the provision of a structure that allows
hypertext systems to be built by selecting the functionalities required and
'hooking' applications that provide those components together at
runtime. The single greatest advantage of this principle is that the functionality
of the HMS is implicitly unbounded. Any third-party application with a scriptable
interface can be used by such a HMS to display information or, if it has a query
interface, can be used to perform link computations. For example, the prototype
hypermedia system described in [ASHV94] was able to make use
of both Unix shell scripts and Oracle SQL statements to provide a set of link type
(computations) that could be extended while the hypermedia system was in use.
Customized and cooperative approaches differ from the retrofitting approach in that hypertext functionality is overlaid on existing display applications without any alteration to these applications. Customized and cooperative approaches differ from each other in that customization is a planned process for integrating a set of applications, whereas the cooperation focuses on an architecture designed to make use of the computation and display capabilities of arbitrary applications, i.e. it is not necessary to plan ahead. In the most general architectures, such as those using services brokers, [NEWT97] the application to perform link computations and display of data is selected at the last moment. So the customized approach is an early binding one, whereas the cooperative HMS uses late binding of applications for the required service.
There is of course no reason why a hypermedia system should not use a combination of these approaches. The most flexible and extensible of the three is the cooperative approach. Unlike retrofitting, this approach does not involve adjusting the third-party application. And unlike the customization approach, the cooperative approach does not involve the development of specific APIs for such applications. Furthermore, the proposed architecture for cooperative hypermedia management is such that any hypermedia system so built could link to retrofitted third-party applications and to applications with customized APIs without an additional change.
The paper first examines (architecture) models for HMSs and then describes in more
detail the cooperative model for HMSs.
2 Architecture/model
Several general (conceptual architecture) models for hypertext management systems (HMSs), such as the Dexter model and extensions, the Amsterdam model, Hypermedia-in-the-Large, and the Open HyperBase model, are described in the literature. [HALS94, HARB94, LEGS94, OREN90] This section will look at such HMS models as being of one of three generic types: unified, collaborative and cooperative (Figures 1, 2, 3).
Figure 1. Unified model of a HMS is typified by the Dexter model. [HALS94] This model has three layers: application, hyperbase and storage (information components and links). Links are defined by the components at which they start and finish. In such a system, storage of links requires the associated storage of the defining nodes (either absolutely or by reference). We call this the unified model as all node data, all link data and all specifications are defined and stored in one common data set
Figure 2. Collaborative model of a HMS is typified by the Open Hypertext
Model. This model stores links and node information in a separate database and to
define protocols to allow access to specific third-party applications. This is
called a collaborative model because specific applications are included in
hypertext application system designs as active collaborators for a given task
Figure 3. In the cooperative model, no individual links or data need be stored by the HMS. All links and data are local to their specific native application and such applications may be called as needed. Cooperating applications may be private or third-party. The HMS does not deal with individual links but rather with link (type) specifications. This model also has three layers, but with the fundamental difference that the storage layer now contains only link (type) specifications. The information components remain in their native applications in the application layer. Linking is accomplished by the HMS, which coordinates the execution of the link specification. Link specifications may be expressed in the query or access language specific to a cooperating application or they may be expressed in a mutually-intelligible query language [NEWT97]
The cooperative HMS can also store individual links should this be required. This allows:
- hand-made links between applications where such inter-application links are not possible otherwise
- the storage of some manifested (i.e. previously computed) links. This may be warranted if it is more cost-effective while still as reliable (with respect to link integrity) as dynamically evaluating each link specification. [ASHM98]
An important feature of the cooperative model is that absolutely no reformatting, no marking up, and no migration of information is necessary. There is no need for compliance with a restrictive information format specific to the HMS, such as HTML or XML. [W3C97] The information remains in its native environment, and the specialised tools developed for handling it in that environment are still available. Computational services also remain in their native environment, i.e. one does not need to build computational services into the HMS. In short, the cooperative HMS requires no native data format and no native link computation software. These can be imported. They all are in the 'pure' version of this architecture. it For response time purposes, however, it may be desirable to build some generally-useful computation tools such as text-based computations into the HMS software, although this departs somewhat from the pure architecture.
The important point is that the HMS functions by default without any internal representation and without any in-built computation software. This substantially extends the scope of information that can be made available. Each of the components can still operate as a stand-alone application so there is no disadvantage arising from cooperation with the HMS. This model has the undoubted advantages of being simpler to implement and simpler to upgrade. Furthermore, users can assemble the applications and functionality they want to use for a given task.
We can describe two implementation variations of this architecture model: direct mode and indirect mode.
In direct (or foreground) mode, links are executed as calls to applications and then the called application effectively moves to the foreground and responds to the call. The user may interact directly with the destination application. The destination application uses its own input and display capabilities and its use is obvious to the user. In this mode, links are one-way, from the source to the destination application.
An early version of the interactive mathematics dictionary hypertext application by Watters [WATH94] demonstrates the direct mode. Figure 4 shows a link from the text to Maple, a large stand-alone symbolic algebra system. The link specification from the text to Maple includes information for use by Maple but the display and interaction with the results is handled exclusively by Maple. In this case the user can interact directly with Maple, independently of the dictionary application, if desired. This corresponds to the 'launch-only' level of cooperation described in [DAVK94].
In the direct mode it is still possible to get links from a third-party application
to something else. This is done by using the cut buffer to duplicate an object of
interest from the third-party application so that the HMS can see it and hence grant
further links on it. [DAVK94]
Figure 4. Direct mode example (full-size figure)
Indirect (or background) mode provides a seamless and integrated link service among the cooperating applications. Figure 5 shows the activation of a link from a newer generation of the interactive math dictionary application. [MATH97] Maple is still responsible for generating the results of links, but now the source application gets the results directly from the destination application and the user is not really aware of the cooperation of the third-party software. Notice that the user can no longer interact directly with the Maple software but only indirectly through the dictionary application.
Figure 5. Indirect mode example (full-size figure)
The feasibility and flexibility of the indirect mode approach to cooperative HMSs has also been shown by the provision of hypermedia functionality simultaneously via a number of different applications. Ashman and Chase [ASHC93] used this approach successfully with databases (Oracle, Progress, Sybase) and Ashman and Verbyla tested it on other information systems. [ASHV93, ASHV94] The HMS uses the same core operations to implement all link types so there is no need to alter software as new link specifications and new third-party applications are incorporated. The functionality of the third-party application, when needed as part of the link specification evaluation, is utilized through its own invocation method, so no changes are necessary to its software either.
3 Design issues for cooperative HMS
This section defines the hypertext components and examines issues of specification for building cooperative HMSs.3.1 Components
A hypertext application can be described, at its most basic level, as a set of nodes and a set of links, where nodes represent information and links represent relationships. In a cooperative HMS, nodes may represent both nodes and links that are not persistent but that are generated by a process as needed. We define a node N in this environment to be a unit of information, of whatever media, by the tupleN=<structure, content, access>where
- structure is (node protocol, i.e., image, video, text, etc.)
- content = bits
- access mode = (r, w, x, rw,...)
Links are (instances of) relationships and are defined by the tuple
L=<type, source, destination, [content]>where
- type means relationship (e.g. goto, example of, compute)
- source identifies one or more source nodes
- destination identifies one or more destination nodes
- content is data passed with the link and is optional
A link is generated by a process. The activation of a link, that is the traversal from a source to a destination, is accomplished by a navigation process. The relationship (or link type) determines what processes are invoked to activate a particular link. The process may vary in complexity from simple 'goto' links, that require the activation of cooperating links, to links that activate processes in other applications, and links that bring data to other applications for processing. The categorization of dynamic links into levels of complexity is described elsewhere. [WATT97] Regardless of complexity, in essence the link generation and activation processes must enable the following:
- a potential source to be confirmed (certified) as being an actual source
- all destinations, one or more, of an actual source to be determined (computed), and if any are chosen they are to be made the current node(s).
The interactive dictionary shown in Figure 5 is an example of the activation of a dynamic link from a static data node, in this case the entry to a third-party application, Maple. In this example, although Maple generates the numeric results, the display is controlled by the dictionary application.
As discussed in the next sub-section, the functional model of the link [ASHV93] provides a generic structure for specifying a link
type and has provided the basis for an architecture to implement a cooperative HMS.
It should be noted that no assumption is made about when (nor where) the process (or
any of its sub-processes) is executed. The link may be pre-computed and persistent
thereafter, computed and cached for some lifetime before re-computation, or the link
may be computed 'just-in-time'. These later links tend to be dynamic
links which, like virtual nodes, are generated as needed and, furthermore, the
target destination of such links need not exist as a persistent node nor does the
target application have to exist at specification time. For instance, in a prototype
HMS based on the functional model of the link [ASHV94], Unix
man (manual) pages had links dynamically generated to related pages regardless of
whether those other pages were available. Furthermore, the source pages remained in
native nroff format with no additional mark-up being required.
3.2 Specification issues
We have been considering the problem of integrating hypermedia functionality with existing third-party applications for some time, including database management systems, geographic information systems, and mathematically based information systems. [ASHV93, ASHV94, WATH94, WATT96] We have found a way to superimpose linking on to a number of third-party applications, with no limit to the number of applications which can be included, no constraints on the location of the applications and no constraints on the types of information they handle. This is done by using the usual access/query interface of each third-party application to generate links. Others have developed alternate approaches, such as Microcosm which is essentially a collection of communication protocols that enable the integration of all types of information processing tools, including a hypermedia link service. [HALL96]A link type specification consists of two computation rules which reflect the two core requirements of the link activation process described earlier, namely source certification or determination, and destination computation. These rules might, for example, be implemented as scripts or queries. Each rule can be in any script or query language, so one link specification might use two languages, one each for the source set and destination set computations. There is no requirement that different link specifications must use the same language, such as in [TNHN91], and this feature is one that radically separates our approach from that of any other. In particular, it enables linking between any combination of third-party applications.
A second fundamentally important aspect that permits inter-application linking is the need to specify not only the destination computation of a linking operation, but also the source determination. The destination computation makes it possible to link into a third-party application; the source determination makes it possible to link out of a third-party application.
An important feature that distinguishes this approach is the form in which
all link types are represented. Our link types are not necessarily defined
on a static set of source objects; instead the validity of each candidate source
object is determined at the time it is required. The static source set approach
implicitly relies on the predetermined validity of the objects in the source set.
This disposes the set of links to integrity constraint errors such as the World Wide
Web's 'Error 404', however, resulting from the deletion and
relocation of data. [ASHM98] It also means that the
'completeness' of a set of links [THIS97] is
not guaranteed as new data may have been added for which links should exist but do
not.
3.3 Link and node management
Dividing the link generation and activation into the two phases of source determination and destination computation makes it possible to involve four (or more) third-party applications in any one link specification, namely:- two computation engines, one each for the source determination and the destination computation scripts
- two (or more) display engines, one for the source and one for each destination object, of which there may be more than one (and it is possible that they are displayed in different ways).
3.4 Standalone application versus cooperative HMSs
In the cooperative HMS approach, any application which has a query or access language can be used in a hypermedia application. There are overheads, however, such as those of communication associated with the cooperative HMS approach. Consequently, in some cases it may be preferable to use a single system with built-in hypermedia functions tailored for the given task. Designers of future information delivery tools might ask the following questions:- How much of the functionality of the information delivery system can already be provided by an external application?
- What is the cost of dynamically evaluating link specifications?
- What variations are expected, over time, of the underlying information collection and its uses?
- To what extent do users want to control their linking functionality?
- How stable is the task requirement?
- Do all users want the same configuration of functionalities?
4 World Wide Web as a cooperative HMS
The example of the World Wide Web is considered in this section because it currently functions as a partially cooperative HMS. Furthermore, the Web has the potential in the future to develop into a fully cooperative HMS.The Web's fundamental HTML-based link model requires that the source of a link be statically specified by embedding it into the HTML document in-situ an <a>-tag pair which contains a href attribute, the destination address (URL). [W3C97] While not completely requiring that all node data, all link data and all specifications are of one common data set, the Web-based HTML hypermedia model is effectively a unified model (see section 2). Its hypermedia functionality breaks down if the destination node (data) is not an HTML document. Non-HTML destination documents typically require that the browser spawn an external viewer. Since such viewers are not fitted with hypermedia functionality, they are dead-ends, i.e. there are no links out of them.
Developments on the Web to support dynamic documents are freeing it from the limitations of the unified model and consequently the Web is becoming a partially cooperative HMS. The qualifier 'partially' applies because the cooperation is still restricted to destination computation. XML and XLS, [W3C98] however, may provide the infrastructure required for applications to cooperate at a functional level on the Web. These may provide the means of incorporating link type specification and dynamic linking into Web functionality. An alternative approach to enhancing the hypertext functionality of the Web (along with other functionalities) has been adopted by the Hyper-G project. [MAUR95] The approach of Hyper-G (and HyperWave, its commercial version) is to incorporate a data model that is much richer than that provided by the Web.
Server-side support for dynamic documents via CGI scripts [NCSA] and, more recently, Java servlets, [SUNb] enable the Web to access third-party applications such as database management systems to link to dynamically created documents. Such destination nodes are returned to the client as HTML marked-up documents, so the user (client) does not need to be aware of the cooperation of the applications. This is a successful example of the indirect mode of the cooperative HMS model (see section 2). It is possible that with the development of a HTTP protocol that supports sessions and transactions, [W3C97] access to server-side execution will further evolve to enable direct (mode) interaction with cooperating applications.
Client-side support is less well established than server-side support for dynamic documents; only recently has it begun to receive significant attention. Such support can take one of three approaches. The first two approaches involve embedded active objects. Active embedded objects, typically Javascript code, [NETS] and referenced embedded objects, typically Java applets, [SUNa] respond to requests for access by dynamically constructing the document required. The third form of client-side support uses dynamic object linking, [W3C97] like that provided by Microsoft's OLE and Apple's OpenDoc. When activated this form of destination computation can provide a link to another application, which the user can interact with directly. This is the direct mode of the cooperative HMSs.
The above discussion indicates that with respect to destination computation, at least, the Web functions partially as a cooperative HMS. A much more difficult issue is that of source determination. All of the above-mentioned destination computations still have as their source embedded tags in an HTML document. A limited amount of research has been done on alternative (or additional) forms of source determination for the Web. Most of this research has focussed on annotation links [ROSM95] since the temporary nature and potential one-to-many nature of such links makes them poor candidates for embedded, marked-up sources.
There is significant scope for further developments in the utilization of
third-party applications for Web-based link source determination. For instance, a
browser could be extended so that a user can be provided with access to a query link
type which when activated would feed the keywords determined from the current
document into a search engine request. This computation of 'similar
document' destinations is already a feature of a number of search engines.
The link would then result in a dynamic destination document containing links to
'similar' documents. (Such pointer-list documents are a necessary
feature of the Web because of its inherent one-to-one unidirectional linking.)
Similar possibilities exist for browser plug-ins providing dictionary, thesaurus and
manual look-up links that are available from a dynamically determined source such as
through user selection (highlighting) of text.