Dept. of Computer Science
Ny Munkegade, Bldg. 540
8000 Århus C, Denmark
++45 8942 3281
Dept. of Computer Science
Texas A&M University
College Station, TX
++1 409 845 0298
Center for IT Research
Ny Munkegade, Bldg. 540
8000 Århus C, Denmark
++45 8942 3358
The historical development of hypermedia systems can be characterized as a series of successive abstractions of functionality away from the "core" hypermedia server, often resulting in a new open layer in the hypermedia environment architecture. Recently, this trend of abstraction has been applied to the hypermedia server itself, replacing the notion of a single, closed hypermedia server with an open layer of structure servers. This newest development brings with it a new set of challenges and research issues for open hypermedia researchers. In this paper, we discuss these issues, review some of our collective applicable experience with contemporary open hypermedia systems and other work, and point out some of the more pressing and intriguing open questions that we feel are facing open hypermedia researchers today. We also examine the "split" in the current hypermedia research community between "system" and "domain" researchers and the still-present need for interoperability among systems, and discuss why any attempt to address the issues we discuss in this paper must account for these observations.
KEYWORDS: Open hypermedia system (OHS), component-based open hypermedia system (CB-OHS), structural computing, hypermedia middleware, hyperbase, hypermedia operating system, hypermedia domain research
Hypermedia systems have developed over the past several decades from the monolithic systems of Bush and Engelbart to the open hypermedia systems of today. Each development in hypermedia system design has been characterized by increased openness, which in turn led to greater applicability and flexibility. Recently, open hypermedia researchers have started to address opening the hypermedia server itself, discussing hypermedia environments that consist of an open layer of structure servers with their associated servers and clients. This "component-based" hypermedia middleware approach allows us to support a much wider range of structural abstractions than has been possible with the closed link server layers that are typical in contemporary systems.
With these new hypermedia component-based systems comes a new set of research issues. Although we have little direct experience with many of these new issues, we do have a wealth of related experience upon which we can draw to form initial understandings. In this paper, we present an agenda containing some of the new issues that confront us as we consider the next generation of component-based open hypermedia systems (CB-OHS's). We also present a framework that allows us to generate and analyze these issues systematically.
The remainder of this paper is structured as follows. Firstly, we present the current state of hypermedia research as it applies to CB-OHS's. This discussion is cast in terms of a "split" in the hypermedia field and the work that has been accomplished within the context of this split. Secondly, we discuss the motivations for the move toward component-based hypermedia middleware, especially with regard to bridging this split. Thirdly, we present and discuss an agenda of research issues that must be addressed by open hypermedia researchers wishing to design and implement a CB-OHS. Fourthly, we describe what we feel are necessary preconditions to any attempt by our field to address the issues on our agenda. Lastly, we present our conclusions based on the work presented here.
From its inception, hypermedia research has been concerned with how people use structure, how to present structure to people, and how to build systems to support people working with structure. Early hypermedia researchers such as Bush addressed all of these concerns. In his seminal article "As We May Think" , he noted that people use associative structures in their memories, discussed how these associative structures could be presented to people (trails of associations), and described a system (the Memex) that could support these structures and their navigation.
The hypermedia research field has become partitioned, however, and issues surrounding the design of systems to support people working with structure have become separated from issues surrounding how people use structure in different problem domains and how such structure should be presented. Researchers concerned with the former issues (called system researchers here) have gone on to describe ever more powerful and complex systems, but their prototypes have generally not supported work in more recently described problem domains. Conversely, researchers concerned with the latter issues (called domain researchers here) have gone on to describe new domains and presentations of structure, but their prototypes have generally not used more recent system designs. Below, we briefly describe the work done in each of these "subfields".
Early hypermedia systems were monolithic (Figure 1a). A monolithic system is one in which all aspects of the system (e.g., client, store, behavior, etc.) are realized in a single process. The limitations of monolithic systems were quickly realized and are well documented, and led to a series of improvements. Roughly speaking, the development of hypermedia system architectures occurred in stages . In each stage, some functionality or architectural component was abstracted away from the "core" hypermedia system. Often, each abstraction was tantamount to the replacement of a part of the hypermedia system with an open set of processes that interact with the rest of the hypermedia system environment through some well-defined interface. First, the frontend of the hypermedia system was abstracted to an open set of clients or applications (Figure 1b). This led to the "open link service" systems of the late 1980's and early 1990's, such as those described in . Next, the backend of the hypermedia system was abstracted and opened, leading to open hyperbase systems (Figure 1c), representative of systems of the early and mid 1990's (e.g., ). Then, traversal computations were abstracted and opened, leading to what are today known as open hypermedia systems, or OHS's (Figure 1d). Most contemporary hypermedia system research environments (e.g., Chimera , DHM , HOSS , HyperDisco , and Microcosm ) are OHS's
Figure 1: Conceptual architectures of hypermedia systems demonstrating various stages of successive abstraction. Above, "Be" stands for "behavior" (link traversal computation) and "LS" stands for "Link Server".
Most OHS's generally support only the abstractions described by the earliest hypermedia researchers (i.e., the associative structures described by Bush). Few contemporary OHS's claim to provide support for any other problem domain, much less for the integration of an open set of new domains. Even when some newer abstractions (e.g., "context" and "generic link") have been adopted by some systems, the focus of these systems has continued to be exclusively navigational. Generally, no attempt has been made to support other problem domains, such as those discussed below.
As mentioned above, Bush and other early hypermedia pioneers considered the use and presentation of associative structures, or what could be called the navigation domain of hypermedia. Since then, many researchers have considered different domains, including hypermedia literature [5, 21, 28], argumentation systems [7, 20, 31], spatial hypermedia systems , hypermedia art [15, 29], and taxonomic hypermedia systems [22, 24, 25]. Work in all of these domains addresses how people use structure for various tasks, whether those tasks be writing or reading literature, participating in or reviewing a decision process, etc. Each domain also has its own specialized abstractions, its own terminology, and its own context. We can understand each of these domains as a kind of hypermedia because all share a focus on structure, but we can also understand each of these domains as unique because of their individual characteristics.
Domain researchers have often built systems to test their ideas about different structure models or presentations. However, these systems have tended to reflect the architectures of the earliest hypermedia systems, since they are almost always monolithic. None of the systems designed to study domains other than the navigation domain provide the distribution, flexibility, or power of contemporary OHS's.
At the Second Open Hypermedia Systems Workshop  held in Washington, DC, in conjunction with the ACM Hypertext '96 conference, the Open Hypermedia Systems Working Group (OHSWG) was formed. The OHSWG has met semi-annually and has established a WWW site (http://www.csdl.tamu.edu/ohs/) and several mailing lists to carry out its work. Currently, most major research OHS's, including all of those mentioned above, are represented in the group.
The main purpose of the group is to foster interoperability between contemporary OHS's. Initially, the goal was to provide a framework for the definition of a common link (i.e., associative structure) services protocol between link servers and their clients . To help provide context for this protocol definition, the group adopted a scenario-based design approach. The need for each modification to the protocol was to be demonstrated by a scenario of hypermedia system use.
In its initial work toward defining a standard protocol for associative structure servers, the group encountered the problem that different contemporary OHS's support different structural abstractions. Although all OHS's support abstractions such as "link", other abstractions, such as "context", "composite", or "generic link" were only supported by some systems. Scenarios describing the need for these other abstractions were submitted, and it was generally agreed that good cases for the adoption of all of these abstractions could be made. Thus, the draft standard started to reflect a union of all services provided by the representative systems. This made it difficult or impossible for any contemporary system to support this standard fully.
This situation was further aggravated when scenarios were submitted to the group that contained examples of use of hypermedia systems that supported other domains, such as spatial and taxonomic hypermedia. It soon became clear that no one structure server (and therefore no one protocol) could support what seemed to be an open set of structural abstractions. It was equally clear, however, that hypermedia domain research and use scenarios could demonstrate the need for these different structural abstractions.
At the OHSWG's most recent meeting in Århus, Denmark, in September 1997 (OHS 3.5), the group adopted a modification to their conceptual reference architecture to address the issue of supporting an open set of structure abstractions. This modification continues the trend of successive abstraction in system development noted above by adopting the abstraction of the link server itself into an open layer of link service peers, each which serves a particular structural model. An open layer of link server peers (or structure servers) allows the support of an open set of structural abstractions, which in turn allows the support of an open set of hypermedia domains. The resulting component-based open hypermedia system architecture is shown below.
Figure 2: Conceptual architecture adopted by the OHSWG. Although strictly speaking, the OHSWG has yet to adopt any particular reference architecture formally, it has been agreed that any such architecture must reflect the need for an open structure server layer. Above, "SS" stands for "structure server".
The successful design and implementation of CB-OHS's involves addressing many research issues. Some of these are the same or similar to those issues that surround work on contemporary OHS's, while some are completely new or noticeably more complicated. Since no system based completely on the new CB-OHS architecture and interface specifications of the OHSWG has been developed yet, we have little direct experience on which to draw to even identify what issues should be on our research agenda. However, as a field, we have a wealth of related experience that we can adapt and extend to provide us with some initial insights.
Before we begin discussing issues, however, we want to introduce a framework for organizing these issues. There are undoubtedly many ways in which to describe the research issues surrounding CB-OHS's. We have chosen to use the new conceptual architecture itself as a framework, examining each layer and interface as well as the system's users. This framework partitions the problem space into seven areas that serve both to help identify new issues and to organize our thinking about those already identified. The figure below illustrates the resultant areas of issues as they relate to the CB-OHS conceptual architecture.
Below, we discuss each area separately, starting from the top of Figure 3 and moving downwards. For each area, we begin by considering experiences gained by working with contemporary OHS's and other hypermedia systems, and how these experiences might be applicable to thinking about CB-OHS's. We continue by discussing some issues that seem particularly challenging or interesting to us based on our collective experiences in developing the HOSS  and HyperDisco  systems over the last seven years.
Figure 3: A mapping of the layers and interfaces of the CB-OHS conceptual architecture and its environment to seven areas of research issues.
Experiences. Since all hypermedia domain research is based on observations of people's use of structure, the hypermedia field as a whole has much experience in considering people's use of structure. For Bush, the observation of the way in which people's memories operate led to the definition of the navigation hypermedia domain . We mentioned several other hypermedia domains above. All of these share their beginnings in observation of people's work practices (e.g., observations of the premature formalization problem that led to spatial hypertext ).
It has always been a concern of domain researchers to find new ways in which people apply different structural abstractions to different problems. As system researchers, we generally have few experiences in this area. We have relied and will continue to rely on domain researchers to identify and describe new domains.
Issues. The issues for domain researchers in this area remain the same despite any changes to system architectures we consider. For us, however, the open structure server layer in CB-OHS's makes this an area we can no longer ignore. In the past, we have relied nearly exclusively on the initial navigational domain observations made by Bush, occasionally considering new issues or abstractions, but rarely straying too far from this basis to incorporate results from new domains. Now that we are considering systems designed specifically to support multiple hypermedia domains, results from this area are directly applicable to extending our systems.
Experiences. There are many examples of hypermedia interface work. A full review is well outside the scope of this paper. Here, we mention only a small representative sample of this work.
Domain researchers have much experience with considering the interfaces of hypermedia systems. Even though systems that implement non-navigational hypermedia tend to be monolithic, we can still regard the interface of these monolithic systems as conceptual "client interfaces" in our framework, placing experience gained from these systems in this area. The interfaces of many any non-navigational hypermedia systems have received much attention in the literature and have even been a major focus of the work in some domains (e.g., spatial hypermedia system interfaces ).
System researchers, too, have considered interface issues. This has become especially important when integrating third-party applications into open hypermedia systems. The hypermedia functionality exported to these third-party applications must be realized in the interfaces of these applications. Reports on different designs at this level as well as rationale for these designs are widespread (e.g., ). There has been much work on navigational aids as well. Several types of overviews have been proposed and implemented (e.g., fish-eye views ). Even early work on navigational monolithic systems often considered interface aids to offset cognitive disorientation (e.g., ).
Issues. Despite the plethora of interface work, there has been very little consensus on even relatively "old" interface issues such as how best to display link endpoints in data. For example, even considering only textual data, is blue, underlined text really the best way to denote a source anchor? In systems that allow multiple destinations, should a pop-up menu list these destinations after a source has been clicked on or when the mouse passes over the source ? Should overview maps of the hyperspace be constructed, and if so, how? How should the rhetorics of arrival and departure be effected ? How should the user specify structural queries ?
Furthermore, the interface issues that arise from different hypermedia domains previously could be considered separately. The possibility of clients that present multiple structure models to users simultaneously, however, raises issues of consistency of presentation. For example, consider the HOSS TaxEd, a client of both taxonomic and associative structure servers . In this case, it is not reasonable to consider presentation of taxonomic and associative structures separately since this client must present both. In general, new CB-OHS's that serve multiple (and even an open set of) structural abstractions and models call for a new, integrative approach to these interface issues.
Experiences. The construction of clients from scratch has been the focus of some hypermedia research, especially work in early open navigational systems (e.g., SP2 ). In these cases, the job of the client designer was relatively straightforward, apart from the HCI issues discussed above. Some excellent recent work regarding the construction of such clients has been done .
Recent system work has tended to focus on integration of third-party applications into open hypermedia environments. Finding appropriate applications has been relatively easy, since associative hypermedia structures are (ideally) independent of the data types over which they are defined.
Issues. Although no open environments for other hypermedia domains have yet been implemented, some have been contemplated in the literature (e.g., an open spatial hypermedia environment in which arbitrary graphics editors are integrated with the services of a spatial hypermedia structure server ). Analogous examples of integration of applications into other environments can also be defined.
Work regarding integration of third-party applications into associative environments has noted that there are different "levels" of integration that can be achieved for different clients [8, 35, 37]. Integration into general structural domain environments suggests an extension of this principle. In what ways (i.e., to what levels) can a graphics editor be integrated into a spatial hypermedia environment? What levels of integration are shared across all structure domains, and which are specific to individual domains? Considering the levels of integration defined by Davis et al. , perhaps some of the lower levels of compliance (e.g., "launch only" integrations) are in fact independent of any particular domain, whereas higher levels of compliance (e.g., "fully integrated") actually correspond to a semantic "understanding" of the particular abstractions of a given domain and are thus not common across domains.
As with the issue areas above, there are ramifications of applications acting as clients of multiple structure servers simultaneously. Can (or should) a procedure for integration of an application into a given domain environment be defined in a way independent of that application's participation in other domain environments? Can some of the effort expended in the integration of an application into one domain environment be reused in its integration into other domain environments?
Finally, there are a series of issues with regard to the recognition and use of advanced backend facilities and the automatic distribution of this new architecture for non-associative clients (or, more commonly, client "parts" of monolithic systems). Most such clients use relatively basic backend functionality. Considering such clients as part of next generation CB-OHS's allows new kinds of experimentation to occur in these domains. What does versioning allow in taxonomic hypermedia systems? How can the collaborative work support of hypermedia system backends be used in a spatial hypermedia system?
Experiences. Open hypermedia systems are called "open" in part because they publish an API. This public interface allows third-party applications to be integrated or designed to be compliant from the start. All open systems face the problem of how to define their interface. An API should be complete and convenient to use as well as extensible. Once an interface is defined, decisions on the means by which it should be served must also be made. Should communication take place over TCP/IP sockets, Apple Events, or RPC, or does an existing component framework such as CORBA provide the necessary infrastructure for routing requests and replies transparently? All designers of contemporary OHS's have faced these problems. This experience will serve as a good basis for addressing the issues below.
Issues. An open structure server layer introduces new concerns about compatibility between the different interfaces. It is certainly a requirement that all middleware components in a given system share the same mechanisms for communicating client service requests and responses. Additionally, there should be a kind of conceptual harmony among the interfaces at this level. Client designers familiar with one component interface should find it relatively easy to program clients for other interfaces.
There are other aspects to the coordination of various structure server interfaces. Names (as well as identifiers, addresses, etc.) of objects and structures valid for one structure server should be valid for all structure servers. Naming has received little explicit attention in hypermedia systems research outside of the WWW to this point. The kind of radical interoperability and openness for which the community is now aiming, however, makes this an issue that must be explicitly addressed.
In addition to object and structure naming, service (or structure server) naming must also be addressed. In contemporary OHS's in which there exists a single (or closed set of) structure servers, it suffices simply to name a well-known port (or equivalent) for each server and allow clients to hard-wire this information into their communication routines. In CB-OHS's, with their open set of structure servers, another layer of service naming must be admitted. Clients may still have the notion of a well-known port, but this port must be to a (service) name server that can resolve a given service name to the correct communication address.
It may be argued that the choice of an existing component framework for communication infrastructure allows some of these concerns to be ignored by system designers. For example, CORBA addresses object and service naming. However, as mentioned above, integration of existing third-party applications is a key concern in CB-OHS's. It is impractical to require that MS Word, for example, be made CORBA compliant in order to participate in such a system. If a system designer adopts such a component framework, it will still be the case that clients that do not adhere to the standards of that framework will still need to be integrated.
Experiences. System researchers clearly have experience in building at least one kind of structure server, namely one that serves associative structure. Another important aspect of this layer is the presence of arbitrary traversal computations, or behaviors. This kind of structural computation has long been acknowledged as a difficult and important issue in hypermedia. Several different kinds of computation have been discussed, including traversal computations (or behaviors) , "active" hypertexts , and dynamically defined structures .
Issues. The construction of structure servers will of course be a major undertaking in the construction of CB-OHS's. While there are clearly important issues in this task, there seem to be many more unresolved and difficult issues surrounding behaviors.
Even in the simple case of contemporary OHS's with only one structure server, no consensus has been reached as how best to represent behaviors. For example, some systems provide their own scripting language (Multicard ), some use existing language facilities (HyperDisco ), and some use compiled object code (HOSS ). For dynamic structure computations, some systems use link filters (Microcosm ) and some systems use arbitrary active information systems . If next generation hypermedia systems are to achieve the degree of interoperability desired, some agreement must be reached on how best to represent these computations.
Considering interoperability between different structure servers (i.e., components serving different structure models) is also interesting. This implies the need for each structure server (or one of its behaviors) to be able to interpret (translate) the structure manipulated by other servers. Is this a realistic or even useful goal?
Without considering the generic case for a moment, it is clear that the ability of one structure server to interpret the structure of another can be useful in certain circumstances. For example, consider an associative structure server that can interpret spatial hypermedia structures. One can imagine a relatively straightforward mapping from spatial structures to associative ones. For example, each structure in the space could correspond to a "document" that contains associative links that lead to the substructures and/or atomic objects that are contained in that spatial structure. Spatial hypermedia systems are used to evolve organizations over time, but if these organizations settle into some configuration, it may be desirable to view this configuration as if it were a set of standard WWW pages, for example.
Clearly, we cannot yet say that translating from any given structure model to any other is a useful undertaking, but it does seem that at least some of these translations would be useful. How best to define these translations is a difficult problem. The best possible solution to this problem would be a generic one in which only the descriptions of the source and destination structure model could be provided to some algorithm that could generate such a mapping. Less generic but more easily attainable translations could be hand-constructed. Even after translations are derived, there remain many questions. If a set of spatial structures is translated into a set of associative structures, does this imply the creation of a new set of structures, or just a different "view" on an existing one? How can we (or should we) coordinate changes in one set/view with changes in another? Are different translations best handled by versioning? While there is some work that may hold promise for mechanism (e.g., using XML  or the Dexter model  as an interchange format, as reported in ), no work to date has focused on the semantic problems raised by such inter-domain translations.
Experiences. Many contemporary OHS's consider at least some type of backend distribution or infrastructure support for their link servers. Often, this support has been in the form of structure aware storage engines. Many OHS's have a hyperbase component that encapsulates and distributes the structure management [12, 22, 37]. In general, the abstraction of the structure-aware store from the structure server itself has been a positive development for those systems that have implemented it.
Issues. The new OHSWG architecture contains both a structure server layer and a backend layer. The API to the backend layer concerns the support provided to structure servers. It defines the set of services that structure servers (and clients) can expect from the underlying system.
Associative structure servers have evolved from the "passive storage and retrieval systems" of which Halasz spoke a decade ago . Even given that no consensus on how to represent behavior in contemporary OHS's has been reached, as mentioned above, most systems do provide their clients computation facilities. Many systems use dynamic structures and/or provide at least some form of structural query. Should we now consider the support of these advanced features at the backend layer as well?
One way to look at this issue is how support for implementing structure servers should be distributed. If structure-aware stores have worked out positively for OHS development, it certainly suggests that, for example, structure-aware computation facilities have similar promise. Thus far, the OHS community has been slow to consider offloading more functionality from structure servers into the backend, despite the fact that such offloading could make structure server construction a simpler task and promote even greater interoperability by removing idiosyncratic features from the structure server layer. Considering the newly opened structure server layer, however, functionality such as general structural computation will be required in an open number of processes. The need for support of functionality common to all processes in an open layer argues even more strongly for its abstraction.
Experiences. As a community, we have few experiences with backend construction outside of hyperbases. This is not surprising in light of the fact, as mentioned above, that most systems do not even provide a structure-aware backend API. Initial thoughts in this direction, however, were provided in . The potential benefits of structure-aware process management, memory management, protection schemes, etc., have been described. These topics have not been of interest only in the hypermedia community, however. Issues such as semantic locality have been actively researched in the operating systems community as well .
Issues. Independent of the level of structure awareness in the interface to the backend, there are potential gains in making the internals of any backend structure-aware.
Traditional operating system design is based on empirical observations of resource use in predominantly monolithic, data-oriented systems. Notions of semantic locality being related to physical locality, for example, are rooted in 1960's style computing environments. In today's computing environments, in which hypermedia structures and their resultant "chunking" of information are a reality, and in which Java applet code-on-demand reachable by WWW links is increasingly more common, it is clear that the basic principles underlying many of the algorithms and policies of older operating systems are becoming outdated.
One might argue that these are the concerns of operating systems researchers. This is clearly correct, in the same way as many of the issues in the first several areas discussed above are the concerns of HCI researchers. Hypermedia has always been an interdisciplinary field. Given the development of hypermedia from predominantly frontend phenomenon to inclusion of middleware and backend components, and the changing needs of operating systems design, however, we argue that there are reasons to undertake collaborations with another branch of research to investigate the construction of hypermedia backend (i.e., operating system) internals.
There are a number of ways in which the research issues that surround CB-OHS's can be addressed. However, we feel that the discussion above points out two necessary preconditions that must be fulfilled by any approach for it to be successful. Both of these preconditions are discussed in more detail below.
We noted above a split in the hypermedia field between system and domain researchers. Though there are people who fit into both categories, it still remains true that results from one area are rarely applied in the other. It has been the case that domain researchers have not been able to use many of the system advances because these systems were rarely flexible enough to support non-associative structures. It continues to be the case that such researchers can choose not to develop on any existing infrastructure or experiment with open systems, though there seem clear benefits and new interesting areas available to those domain researchers that want to experiment with the new CB-OHS's.
It has also been the case that system researchers have been able to ignore many domain research results because of the relatively narrow focus of contemporary OHS's . It continues to be the case that such researchers can choose to ignore other domains and focus on implementing open sets of structure servers that happen to contain only one component, though whether this is interesting or valuable seems debatable.
The fact is, however, that there are many potential benefits for members of both areas to co-operate and share work and results with one another. Domain researchers can explore entirely new sets of questions concerning distribution, collaboration and integration of different structure models without having to implement backend (or perhaps even structure server) support. System researchers can gain whole new audiences in which to test designs and implementations. The situation seems laden with exciting possibilities for the hypermedia field. If CB-OHS's are to realize their full potential, though, the gap between domain and system research must be bridged.
Not only must there be co-operation between system and domain researchers -- it must also exist between different system researchers. It has been the case that contemporary OHS's have been developed independently from one another, with occasional borrowing of ideas or implementations when convenient. However, for several years, the need for (or at least benefits of) some standards among the different OHS's has been recognized. This need was driven by the recognition that allowing an open set of clients implies the potential for an open set of integrations that must be performed. Implementing an OHS became an open-ended task. If client integration could be performed in a standardized way, it was reasoned, all OHS's would benefit when a new client was integrated into one OHS.
This need to spread effort and prevent re-implementations and re-integrations is even more acute for CB-OHS's than for contemporary OHS's. Until now, only clients of associative structure servers were candidates for integration into a hypermedia environment. Now, we can consider integrations of arbitrary clients and even new structure servers. Also, as mentioned above, CB-OHS's require a large amount of "infrastructure" support (e.g., naming services, location services, etc.) as well, which suggests further benefits of standards to promote interoperability. Finally, any attempt to convince domain researchers to use CB-OHS's for experimentation and development must come with some guarantee of stability. Setting standards will help ensure this stability.
The hypermedia field is at an important and interesting time in its development. The system work that has been done over the last decade has reached a level of stability and maturity, embodied in the OHSWG adoption of a CB-OHS conceptual architecture and evidenced by the convergence of functionality of many contemporary systems and the emergence of well-defined standards. It is now time to apply the results of this work to support the domain work that has occurred and continues to occur. This promises new and exciting possibilities for many researchers in the field. Domain researchers can expect easier construction of more powerful clients and systems for their experiments and work, while system developers can expect a growing number of users with diverse requirements to fuel the improvement of their work.
These developments introduce a new set of issues that must be confronted by open hypermedia researchers, however. Allowing the support of multiple structure models in the same environment requires new thinking on how to harmonize the presentation of these models to both client programmer and user. The increasing complexity of structure servers coupled with developments in the operating systems field points to new possibilities for collaboration. We feel that open hypermedia researchers must address the issues we discuss above in the coming years if the promise of CB-OHS's is to be fulfilled.