Open Hypermedia Systems Working Group

OHSWG Compendium

1997.11.05

OHSWG WWW site

Welcome to the Open Hypermedia Systems Working Group home page. From this page, you should find links to a description of our goals, a list of resources we've established to help us conduct our business, specifications we've developed, and sample implementations of compliant systems.

Document Contents

Introduction

This section includes some notes on the purpose of the OHSWG, how this document is organized, and the history of the OHSWG.

Scenarios


The section contains scenarios of OHS use that the group uses to provide rationale for various architectural components or functionality.

Infrastructure (in progress)


This section describes the system infrastructure on top of which OHSWG middleware components are or should be built.

Framework (in progress)


This section describes the component framework in which OHSWG middleware components are or should be built.

Domains (in progress)


This section describes the actual OHSWG middleware components and the areas they are intended to address.

Appendices


This section contains lists of all of OHSWG specifications, sample implementations, lists of members, resources, and meetings.

1 Introduction

This document contains the final and intermediate products of the Open Hypermedia Systems Working Group (OHSWG) effort. In this document, you will find a description of the group, its purpose, and history, released and in progress specifications, e-mail archives of discussions, pointers to off-site information that we are using, and much other material. This document is continually being updated and augmented as our work progresses.

We hope that this document will serve not only as a record of our work, but as an invitation for interested people to join our discussions and use our results. Each page of this document is maintained by one or more responsible people, whose names and contact information are included. Feel free to send questions or comments about any particular page to its maintainer(s) or to the group's mailing list. (The address of this list, as well as instructions on how to subscribe and post, are provided in the appendix page on group resources).

Section Contents

Brief description of the OHSWG

This subsection provides a description of the purpose and philosophy of the OHSWG.

Organization of this document


This subsection describes the different sections of this document.

History of the OHSWG


This subsection provides a history of the OHSWG, including an account of the group's original purpose, how this has evolved over the group's existence, and summaries of previous meetings.

1.1 Brief description of the OHSWG

Purpose of the OHSWG

Previously, systems work in hypermedia tended to be directed toward the traditional application domain of navigation (i.e., the authoring and browsing of structure over data), as inspired by Bush's seminal article, As we may think [1945]. However, hypermedia structuring principles have been applied to a wide variety of domains, including hyperliterature and hypermedia art [Bernstein et al. 1991; Bolter and Joyce 1987; Bolter 1991; Kaplan 1994; Kinsella 1996; Landow and Kahn 1992; Leistøl 1994; Michalak and Coney 1993; Moulthrop 1989; Sawhney 1996], argumentation systems [Conklin and Begeman 1987; Fischer et al. 1989; McCall et al. 1990; Schuler and Smith 1990; Smolensky et al. 1988], spatial hypertext [Marshall and Shipman 1995], and systems for taxonomic work [Nürnberg et al. 1996, 1997; Parunak 1991, 1993].

Much systems work intended for supporting navigation is applicable to supporting these other domains as well. In order to deliver functionality to this broader class of clients, however, it was necessary to consider opening the set of structural abstractions supported by an OHS. A natural way in which to accomplish this is to generalize the link server of contemporary OHS's, replacing this single entity with an open set of link server peers (or simply, structure servers).

Considering an open set of structure servers, however, led to the separation of much of the component infrastructure from the definition of the structure server interfaces themselves. The definition and standardization of these component interfaces and the infrastructure that supports client/server interactions in this environment is the new focus of the group.

The basic purpose of the OHSWG is to standardize these aspects of OHS's. Currently, each OHS implements slightly different interfaces on different infrastructure, making applications integrated into one OHS unable to use the services of other OHS's. Standardization of these aspects of systems will allow clients to operate over all compliant OHS's. Since application integration is an open-ended task, such standardization saves effort on the most costly aspect of OHS implementation. Standardization also allows third parties to build naturally compliant application, bypassing the extra integration step completely.

Philosophy of the OHSWG

Scenario-based specification. All functionality proposed to be part of a given architectural component should be justified through one or more scenarios of OHS use. That is, when proposing that some given functionality should be added to the OHS specifications, a scenario based on actual or foreseen use of an OHS should be submitted to the group for discussion. The group should reach a consensus on whether or not the scenario demonstrates the need for added OHS functionality before discussing how best to specify such functionality.

Component-based specification. Specifications should fall into one of three categories: infrastructure, domain, or framework. Infrastructure specifications address the functionality (interface and operational semantics) of OHS backends on which OHS middleware should be built. Domain specifications address the functionality of OHS middleware on which OHS clients can be built. Framework specifications address how components should request and deliver functionality they provide.

Open specification. The set of domain specifications is open, since the set of potentially useful structure models is open. Additionally, each domain specification should allow for extensibility and tailorability of the core abstractions defined by the specification.

1.2 Organization of this document

This document is divided into five sections and a set of appendices. The first section is entitled Introduction. It contains a brief introduction to the OHSWG, this explanation of the document organization, and a history of the group.

The second section is entitled Scenarios. It describes different scenarios of OHS use that direct the work of the group. It is a premise of this group that functionality should be added to a given architectural component only if a scenario for its use can be constructed and the group members can decide collectively that such a scenario should be handled by an OHS.

The third section is entitled Infrastructure. It describes the system infrastructure on top of which OHSWG middleware components should be built. It describes an OHS reference architecture, explanations of the responsibilities of the various architectural components in this reference architecture, and related issues.

The fourth section is entitled Framework. It describes the various technical issues in defining protocols between architectural components, interfaces to various components, and other related issues.

The fifth section is entitled Domains. It consists of an open set of descriptions of interfaces to OHS middleware. Each interface defines a different structural model to be used in a particular application domain.

The appendices consist of various additional group information, such as a list of subscribers to the OHSWG mailing lists, a complete listing and timetable for all OHSWG specifications and sample implementations, guidelines for authors of OHSWG material, and other related issues.

1.3 Message from the OHSWG chair

Historical Overview

Open hypermedia technology is currently showing its potential for building hypermedia authoring and browsing environments encompassing existing, widely used applications such as Microsoft Word on Windows platforms and Emacs on Unix platforms. The ultimate goal is to introduce hypermedia technology into as many applications and components of existing computing environments as possible to evolve gradually current computing environments into a world-wide, unified hypermedia environment spanning multiple computing platforms. A significant step towards this rewarding and ambitious goal is to introduce open hypermedia standards that allow interoperability between the many small hypermedia environments that make up the global hypermedia environment. Standards also address the concerns of application developers who design applications and system developers who design hypermedia environments. This web site is the main source of information for the ongoing effort in the open hypermedia community to define common guidelines and standards for interoperation between open hypermedia environments.

The open hypermedia community is currently addressing interoperability issues by defining a set of guidelines and standards for interoperation. A working group has been formed and a number of meetings have been held in this ongoing standardization effort. This historical overview sets the context for the contributions on this web site. The remainder of the overview is divided into four parts. Section 2 contrasts closed and open hypermedia systems; Section 3 identifies different approaches to open hypermedia; Section 4 describes previous historical events of this ongoing standardization effort; and finally, Section 5 describes the current status of the standardization effort.

The term open has different meanings in different contexts. Generally, a software system can be categorized as open if it specifies and publishes interfaces between its system components. However, what does open mean in the context of hypermedia systems and what does closed (or monolithic) mean? An important matter in hypermedia systems is the distinction between structure and content. Therefore, a hypermedia system that imposes a specific data model format (specifying both structure and contents formats) on its hypermedia enabled applications can be considered closed, since applications have to be custom-made to participate in this type of environment. In contrast, an open hypermedia system only imposes a specific structure format on its hypermedia enabled applications. Allowing applications to store contents in different formats potentially outside the hypermedia system is a basic requirement for integrating and using existing applications in an open hypermedia environment [26]. For example, the World Wide Web (WWW) [5] imposes the HTML format on its browsers (HTML embeds structure in the contents). The following example illustrates the conceptual operation of the WWW.

Example: Link traversal in the WWW

1. The user clicks on an anchor in an HTML file displayed in a WWW browser. By definition, the URL for the other end of the link is embedded in the HTML file being displayed.
2. Based on the information in the URL, the WWW browser sends a "get" request to the appropriate WWW server holding the file at the other end of the link.
3. The WWW server sends the file back to the WWW server.
4. Based on the type of the file, the WWW browser will do one of the following:
• HTML file: the document contents will be interpreted and the document will be displayed with outgoing links if any. It may now be possible for the user to follow links to other files.
• Other file type: the browser can itself display some file types (gif, xbm, etc.), but these file types have no outgoing links. (Only HTML files hold linking information.) If the browser cannot display the file itself, it will launch a plug-in or a separate application that can display the file. These applications have not been enabled to support hypermedia linking. Thus, in either case, the user has now reached a dead end in the hypermedia with no links to follow.

From a general software system perspective the WWW is open, since the interface between browsers and servers is well defined (the http protocol). However, a WWW browser must be custom-made to interpret and display HTML files. In order to integrate an existing application to operate as a WWW browser, the application would have to be altered to use HTML as its basic data model format. This would in most cases require a major rewrite of the application. From this perspective, the WWW is a closed hypermedia system. In general, a closed hypermedia system is characterized by only handling a closed set of data model formats and by having a closed set of hypermedia enabled applications that participate actively in the hypermedia services. An application that is simply launched to display a file cannot be considered a hypermedia enabled application, since it is unaware of the hypermedia system launching it.

An open hypermedia system allows an open set of applications to participate in the hypermedia services and supports an open set of data model formats. The following example illustrates the conceptual operation of an open hypermedia environment. (The exact operation varies from system to system.)

Example: Link traversal in an open hypermedia environment

1. The application communicates a traverse link request to the open hypermedia system due to some action, which can be triggered by a user click on an anchor or by some other event taking place in the application.
2. The OHS resolves the link and determines the file(s) at the other end of the link. Some OHSs support n-ary links in which case step 3 will be repeated for each file at the other end of the link.
3. The OHS can now do one of the following things to display the file:
• It can request that an already running hypermedia enabled application display the file.
• It can launch a hypermedia enabled application to display the file.
• In case no hypermedia enabled applications can display the given file type, the OHS can (like the WWW) launch a "non-hypermedia-aware" application to display the file. Again, the user has reached a dead end with no available links (steps 4 through 8 do not take place for this file). In general, new data model formats can be supported in an open hypermedia environment by enabling an (existing) application that can handle the required data model format.
4. Based on the information from the OHS, the hypermedia enabled application opens the requested file (e.g., by retrieving the file from the file system).
5. The hypermedia enabled application sends a message to the open hypermedia system requesting anchors for the displayed file.
6. The OHS replies with a list of anchors.
7. The hypermedia enabled application displays the anchors and highlights the particular anchor that was connected by the traversed link.
8. The user can now traverse available links from the newly displayed file.

OHSs store the structure separate from the contents. Structure is superimposed on the contents at display time by the hypermedia enabled application handling the contents. Thus, the open set of applications making up an open hypermedia environment can link to and from documents available from many sources (including read-only sources) in the computing environment (e.g., file systems, CD-ROM's and databases).

The lack of consensus in the open hypermedia community about what exactly an OHS is (i.e., what data model and services they should provide and how they should be built) has led to the current line of workshops and meetings described in Section 4.

OHS 1 [24] resulted in two working groups, one focusing on open hypermedia reference models and one dealing with interoperability in OHSs. While the two groups never formally met, individual members of the groups conducted related research and produced a number of significant results, which were presented in position papers at OHS 2 [22] and in conference papers at the ACM Hypertext '96 Conference [4].

The participants at OHS 2 decided to form one new working group on OHSs. The initial mission of the Open Hypermedia System Working Group [14] (OHSWG) was to address two key issues: defining open hypermedia systems (the scenario subgroup) and defining open link services (the protocol subgroup). The OHSWG held its first meeting in December 1996 in Southampton [6] (named OHS 2.5 to indicate that the meeting took place in between OHS 2 and OHS 3). A third key issue, defining an OHS reference architecture (the reference architecture subgroup), was added to the OHSWG agenda at OHS 2.5.

On the surface, these three subgroups may have seemed independent. However, the idea was that the construction of the scenarios must inform the design of the architecture, which in turn specifies what protocols must be defined. The architecture cannot be designed without grounding in actual examples of how designers envision OHSs being used in the real world to solve real problems. Protocol design can only take place within an architectural framework.

By the time of OHS 3 [21], each of the three subgroups had produced significant results that were reported in position papers at the workshop. Of a total of twenty submissions, six position papers presented different scenarios, three position papers proposed different reference architectures and three position papers addressed protocol issues. OHS 3.5 in September 1997 in Aarhus [20] focused on protocol issues. The goal was to get a first working version of a linking protocol finished to allow for future implementations and interoperability experiments. The linking protocol is the protocol between applications and open hypermedia systems, which enables presentation interoperability.

Sections 4.1 through 4.3 describe the rationale behind each of the three OHSWG subgroups (scenario, reference architecture and protocol) and provide a brief overview of the work done by each subgroup up until OHS 3.5 (September 1997). OHS 3.5 resulted in a major reorganization of the OHSWG as described in Section 5.

The OHSWG web site [14] became operational shortly after OHS 2. Among other things, the web site is used to publish scenarios and instructions [15] on how to submit scenarios to the OHSWG. The first scenario, "Navigational 1" [16], was submitted shortly before OHS 2.5 (November 1996). OHS 3 received a total of six scenarios dealing with many different aspects of open hypermedia:

• Propagating Navigation [3]
• A Framework Browser Scenario [9]
• Collaboration via OHS: A Scenario [12]
• A Southampton Scenario for OHS [13]
• Heterogeneity, Structure, and CSCW: Three Challenges for Open Hypermedia [19]
• Fred the Programmer [25]

Some of these scenarios have since been published at the OHSWG web site. As of December 1997, nine scenarios have been published on the web site and one scenario is being written.

The effort to define a reference architecture for OHSs is both of theoretical and practical interest. On the theoretical side, such an architecture will allow researchers to compare and contrast various systems. On the practical side, such an architecture can serve as the starting point for interoperability efforts at different architectural levels, including presentation and storage interoperability (Section 1), by identifying the necessary protocols among OHS components.

The reference architecture issue was added to the OHSWG agenda at OHS 2.5. Three position papers on the subject appeared at the following workshop (OHS 3):

• OHRA: Towards an Open Hypermedia Reference Architecture and a Migration Path for Existing Systems [10]
• Towards a Reference Architecture for Open Hypermedia [11]
• Interoperability and Open Hypermedia Systems [23]

These papers deal with different aspects and issues of open hypermedia architectures and propose different reference architectures for open hypermedia. The proposals identify a number of protocols that should be considered in OHS design.

The work in the protocol subgroup has mostly focused on the definition of a standard linking protocol. Through the linking protocol, various levels of hypermedia awareness on the part of the application, as well as various levels of functionality on the part of OHS, are implicitly defined. The work on the linking protocol will not only address the research question of the nature of open link services, but also provide a practical method of allowing presentation interoperability between different open hypermedia environments (Section 1).

A first draft version of a standard linking protocol for open hypermedia (called the Open Hypermedia Protocol version 1.2 or simply OHP 1.2 [7]) was presented at OHS 2. The OHP proposal was well received and was discussed again in detail at OHS 2.5. At OHS 3, three position papers provided critique and proposed changes to the OHP 1.2 proposal:

• A Critique of the Open Hypermedia Protocol [1]
• How OHP's LocSpecs could benefit from ISO/IEC 10744 [17]
• Applying the HyTime Model to the Open Hypermedia Protocol LocSpec [18]

Based on all the feedback, the OHP was extensively revised, and OHP version 2.0 [8] was released shortly before OHS 3.5. Both at OHS 3 and at OHS 3.5, other protocols (e.g., the storage protocol, which enables storage interoperability between open hypermedia environments) received increasing attention.

Thus, what used to be the concerns of the OHP is now being handled in the navigation component and by the underlying component framework. The OHSWG web site [14] reflects this new organization of the work in the OHSWG.

[1] Anderson, K. M. A Critique of the Open Hypermedia Protocol. In [21], pp. 11-17.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/anderson.html

[2] Aßfalg, R. (ed.). Proceedings of the Workshop on Open Hypertext Systems, (Konstanz, Germany, May 1994).

[3] Bapat, A. Propagating Navigation. In [21], pp. 24-25.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/bapat.txt

[4] Barman, D. ACM Hypertext '96 Conference web site.
http://www.cs.unc.edu/~barman/HT96/

[5] Berners-Lee, T., Cailliau, R., Luotonen, A., Nielsen, H. F., and Secret, A. The World-Wide Web. Communications of the ACM, 37, 8, (August 1994), 76-82.

[6] Davis, H. C. 2.5 Open Hypermedia System Working Group Meeting. (Southampton, England, December 1996).
http://diana.ecs.soton.ac.uk/~hcd/research/invitation.htm

[7] Davis, H. C., Lewis, A., and Rizk, A. OHP: A Draft Proposal for a Standard Open Hypermedia Protocol. In [22], pp. 27-53.
http://www.daimi.aau.dk/~kock/OHS-HT96/Documents/ohp.html

[8] Davis, H. C., Reich, S., and Rizk, A. OHP - Open Hypermedia Protocol. Working Draft 2.0, 20th June 1997.
http://diana.ecs.soton.ac.uk/~hcd/ohp/ohp.htm

[9] Demeyer, S. A Framework Browser Scenario. In [21], pp. 26-36.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/demeyer.html

[10] Goose, S., Lewis, A., and Davis, H. OHRA: Towards an Open Hypermedia Reference Architecture and a Migration Path for Existing Systems. In [21], pp. 45-61.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/goose.html

[11] Grønbæk, K., and Wiil, U. K. Towards a Reference Architecture for Open Hypermedia. In [21], pp. 62-72.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/gronbak.html

[12] Haake, J. M. Collaboration via OHS: A Scenario. In [21], pp. 73-80.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/haake.html

[13] Hall, W., and Davis, H. A Southampton Scenario for OHS. In [21], pp. 81-85.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/hall.txt

[14] Nürnberg, P. J. Open Hypermedia System Working Group web site.
http://www.csdl.tamu.edu/ohs/

[15] Nürnberg, P. J. Open Hypermedia System Working Group web site - scenarios page.
http://www.csdl.tamu.edu/ohs/scenarios/

[16] Nürnberg, P. J., and Leggett, J. J. Navigational 1. OHS scenario at the OHSWG web site.
http://www.csdl.tamu.edu/ohs/scenarios/nav1/

[17] Reich, S. How OHP's LocSpecs could benefit from ISO/IEC 10744. In [21], pp. 98-105.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/reich.ps

[18] Rutledge, L., Hardman, L., and van Ossenbruggen, J. Applying the HyTime Model to the Open Hypermedia Protocol LocSpec. In [21], pp. 111-115.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/rutledge.html

[19] Trigg, R. H., and Grønbæk, K. Heterogeneity, Structure, and CSCW: Three Challenges for Open Hypermedia. In [21], pp. 131-136.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/trigg.html

[20] Wiil, U. K. 3.5 Open Hypermedia System Working Group Meeting. (Aarhus, Denmark, September 1997).
http://www.daimi.aau.dk/~kock/OHS3.5/

[21] Wiil, U. K. (ed.). Proceedings of the 3rd Workshop on Open Hypermedia Systems, Hypertext '97, (Southampton, England, April 1997). CIT Scientific Report no. SR-97-01, The Danish National Centre for IT Research. July 1997.
http://www.daimi.aau.dk/~kock/OHS-HT97/

[22] Wiil, U. K., and Demeyer, S. (eds.). Proceedings of the 2nd Workshop on Open Hypermedia Systems, Hypertext '96, (Washington, DC, March 1996). UCI-ICS Technical Report 96-10, Department of Information and Computer Science, University of California, Irvine. April 1996.
http://www.daimi.aau.dk/~kock/OHS-HT96/

[23] Wiil, U. K., and Whitehead, E. J., Jr. Interoperability and Open Hypermedia Systems. In [21], pp. 137-145.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/wiil.html

[24] Wiil, U. K., and Østerbye, K. (eds.). Proceedings of the ECHT '94 Workshop on Open Hypermedia Systems, (Edinburgh, Scotland, September 1994). Department of Computer Science, Technical Report R-94-2038, Aalborg University. October 1994.
http://www.daimi.aau.dk/~kock/OHS-ECHT94/

[25] Østerbye, K. Fred the Programmer. In [21], pp. 146-149.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/osterbye.html

[26] Østerbye, K., and Wiil, U. K. The Flag Taxonomy of Open Hypermedia Systems. In Proceedings of Hypertext '96, (Washington, DC, March 1996), ACM Press, pp. 129-139.
http://www.cs.unc.edu/~barman/HT96/P51/Flag.ps.gz

2 Scenarios

Introduction

These scenarios are intended to define the scope of open hypermedia systems by example. In order to make this process as open as possible, we actively encourage the submission of scenarios from interested parties. Use the scenario template below to format scenario proposals. Appropriate scenarios will be posted here for discussion amongst the group members.

Scenarios

Examples


• Template - This is approximately what the proposal form looks like after processing.
• Sample - This is a simple example.

Scenarios (in chronological order of submission)


• Navigational 1 - 6 Nov 96 - Peter J. Nürnberg, John Leggett (Texas A&M University)
• Collaboration via OHS - 23 Apr 97 - Jörg Haake (GMD)
• Fred the programmer - 23 Apr 97 - Kasper Østerbye (Aalborg University)
• Spatial 1 - 24 Jun 97 - Peter J. Nürnberg, Frank M. Shipman III (Texas A&M University)
• External 1 - 27 Jun 97 - Peter J. Nürnberg (Texas A&M University)
• Indexer 1 - 27 Jun 97 - Peter J. Nürnberg (Texas A&M University)
• Taxonomic 1 - 5 Nov 97 - Peter J. Nürnberg, Hugh D. Wilson (Texas A&M University)
• The translator - 11 Feb 98 - Roland Grassmann (Institut fuer Telematik, Trier)

Scenarios submitted but not formatted


• Southampton - Wendy Hall, Hugh Davis (University of Southampton)
• Hypermedia and Software Engineering - Serge Demeyer (Brussels Free University)

Scenarios being written

• Dynamic Information - Chao-Min Chiu (Rutgers University)
  

Instructions on submitting a scenario

1. Read the existing scenarios first.


If there are existing scenarios that demonstrate similar functionality as the scenario you would like to propose, it may be more appropriate for you to comment on the existing scenarios first. Your comments may lead to modification of existing scenarios. The forum for commenting on the scenario and protocol work of the OHS working group is an e-mail list called ohs@csdl.tamu.edu. If you would like to subscribe to the list, send a message to listproc@csdl.tamu.edu with a message body of "sub ohs <your name>". Past archives of this mailing list are available from either the list processor (see listproc documentation for more details) or from the home page of this working group in "hypermail"'d form.

2. Download the template scenario.


There are two parts to a scenario on this web site: the scenario proper; and, an analysis. Optimally, you can provide both the scenario itself and the analysis. However, if you have a scenario, but are having trouble filling in the analysis, fill in what you can and submit your work anyway. The discussion on the mailing list about your proposal will help you and the group fill in the analysis. The organizers will format your scenario when it is ready for the web site and provide your scenario a home page. It is best to use the standard scenario proposal form (available on the OHSWG WWW site in HTML source) so that the organizers can get your scenario up on the web site as quickly and efficiently as possible.

3. Replace the place holders in the template with your text.


On your first draft, fill in as much detail as you can. It will be easier to remove unnecessary details later than for people to have to retroactively interpret unclear aspects of your scenario. Your text can include links to relevant resources, examples, or detailed clarifications.

4. Review your proposal terminology.


Terminology in the hypermedia research community, as in many areas, is at times annoyingly inconsistent. Whatever terminological set you use, be sure to include a reference to a paper or established line of work with which people in this community would be familiar. Also, be consistent. Once you choose a set of terminology, stick with it throughout the text of the scenario.

5. Have your proposal reviewed by others.


See if a person uninvolved with the scenario authoring understands what is being proposed in the same way that you do. This will help you eliminate cluttering detail or fill in unclear areas. Oftentimes, another party can catch simple errors or omissions better than the original authors. It is best if your reviewer is familiar with this area, but not a member of your immediate working group. Finding someone external to your everyday efforts will help avoid a "groupthink" effect.

6. Submit your proposal.


Mail your submission to pnuern@csdl.tamu.edu. If your scenario consists of only one file, just mail it. Otherwise, it is best if you tar the directory containing all of the files, compress it using a common compression utility (gzip, compress, or zip), uuencode it, and mail the resulting file. It is preferred that you submit as much material as you can instead of simply providing a set of URL's identifying the material. Once your submission is received, the organizers will contact you about any immediate edits we feel should be made. After this initial editing process, the scenario will be made available on this WWW site.

7. Follow the progress of the discussions concerning your scenario.


Hopefully, your scenario will spark discussions about its implications for the group's work. This discussion may lead to the continual updating, editing, and modification of your proposal. It is important that you follow this discussion to see if the intent of scenario you submitted is being preserved!

2.1 Sample

Preliminaries

Updates
Most recent: 10 April 96 (went to new format)

• 18 January 1997
  

References


• Leggett, J. and Schnase, J. 1994. Viewing Dexter with open eyes. Communications of the ACM 37(2) Feb, 76-86.
  

2.1.1 Sample - Scenario

Scenario Description

2.1.2 Sample - Analysis

Goals of the Scenario

Forge an association between two different words


In this case, I am using the word association to mean a conceptual link. I am following the HRL reference model terminology. More explicitly (and still within this terminological framework), I mean to imply an association with an implicit behavior of replace.

Characters

Author


This is the person who wishes to forge the link.

Data

1. The text file in which the association is to be forged. (sample data found below)

   Description:
   

   This file consists of flat 8-bit ASCII text.

   Access Issues:
   

   The author has read/write permissions over this data.

   Synchronisity Issues:
   

   The author is the only person accessing the data.

Requirements for Participating Applications:

Must be able to store persistently ASCII text files


That is, the application must be able to assign an identifier to a file (or determine the identifier so assigned by another entity), request that it be stored persistently in a store, and be able to retrieve at some later time the file using the previously assigned identifier.

Must persistently address associated words


That is, the application must be able to assign identifiers to the "endpoints" of the association (or determine the identifiers so assigned by another entity), request that they be stored persistently in a store, and be able to determine at some later time the endpoints using the previously assigned identifiers.

Must send "Build association between these persistent addresses" message to server


That is, the application (or a proxy) must indicate to the link server the endpoints selected by the author for the association in question.

Must send "Follow from given source" message to server


That is, the application (or a proxy) must be able to indicate that the author wishes to follow the association, and that furthermore, an endpoint has been specified as the source for this traversal.

Must process "Display given persistent address" message from server


That is, the application (or a proxy) must be able to display what semantically amounts to the destination of an association traversal.

Requirements for Link Server:

Must process "Build association between these persistent addresses" message from client


That is, the link server must be able to receive two association endpoint identifiers from the application, and build an association between them.

Must process "Follow from given source" message from client


That is, the link server must be able to receive an association endpoint identifier from the application and determine the identifier of the "other side" of the association. It is assumed here that for any given endpoint identifier, there is exactly one associated endpoint.

Must send "Display given persistent address" message to client


That is, the link server, once determining the identifier of the "other side" of an association given one identifier (see above), must be able to send a message to the application indicating that this destination endpoint should be displayed.

Requirements for Stores:

Must persistently store ASCII text files for client


That is, an application must be able to request that a file be stored persistently with an associated identifier, and be able to retrieve at some later time the file using this identifier.

Implementations:

1. HOSS (does not use OHP)

Protocol Requirements:

2.1.3 Sample - Data

EIN HERBSTABEN
An Karl Rock

Das braune Dorf.  Ein Dunkles zeigt im Schreiten
Sich oft an Mauern, die im Herbste stehn,
Gestalten: Mann wie Wieb, Verstorbene gehn
In Kühlen Stuben jener Bett bereiten.

Hier spielen Knaben.  Schwere Schatten breiten
Sich über braune Jauche.  Mägde gehn
Durch feuchte Bläue und bisweilen sehn
Aus Augen sie, erfüllt von Nachtgeläuten.

Für Einsames ist ein Schanke da;
Das säumt geduldig unter dunklen Bogen,
Von goldenem Tabaksgewölk umzogen.

Doch immer ist das Eigne schwarz und nah.
Der Trunkne sinnt im Schatten alter Bogen
Den wilden Vögeln nach, die fernzogen.

-Georg Trakl

2.2 Navigational 1

Preliminaries

Updates
Most recent: 20 November 1996 (Added ability to delete assoc (sets) to author description)

Previously updated: 6 November 1996
Previously updated: 5 November 1996


References


• Leggett, J. and Schnase, J. 1994. Viewing Dexter with open eyes. Communications of the ACM 37(2) Feb, 76-86.
  

2.2.1 Navigational 1 - Scenario

Scenario Description

The characters in this scenario want to build and/or browse associations between parts of data objects handled by their applications. The characters want to build these associations for two main reasons: 1) to ease navigation between associated items; and, 2) to indicate semantic associations to other characters in the scenario. These associations should be grouped into sets, that may be arbitrarily opened, closed, and merged. Associations and sets of associations must be able to be deleted. Associations may be in several sets at the same time.

2.2.2 Navigational 1 - Analysis

Goals of the Scenario

Create a set of associations


An author or set of authors must be able to specify a (possibly empty) set of associations and then indicate to the link server that an association set consisting of these associations is to be created.

Delete a set of associations


An author must be able to specify an association set and then indicate to the link server that this association set should be deleted.

Open a set of associations


An author or browser must be able to specify an association set and then indicate to the link server that this association set should be opened. Opening an association set should apply only to the workspace of the author or browser that requested the operations. Opening an association set "activates" the associations in the set. Only active associations may be followed.

Close a set of associations


An author or browser must be able to specify an association set and then indicate to the link server that this association set should be closed. Closing an association set should apply only to the workspace of the author or browser that requested the operations. Associations in a set that is closed should be made inactive, unless they belong to other open sets.

Create an association


An author or set of authors must be able to specify a set of endpoints and then indicate to the link server that an association is to be created between these endpoints. The endpoints should be individually designated as source points or destination points.

Delete an association


An author must be able to specify an association and then indicate to the link server that this association should be deleted.

Place an association in an association set


An author must be able to specify an association and an association set and then indicate to the link server that this association is to be placed in this set.

Remove an association from an association set


An author must be able to specify an association and an association set and then indicate to the link server that this association should be removed from this set.

Follow an active association


An author or browser should be able to specify an active association and indicate to the link server that this association should be followed. The act of following an association should result in all endpoints of the association being displayed in the appropriate workspace.

Characters

Browsers


These characters have the ability to open and close sets of associations, as well as follow any association. There may be any number of browsers.

Authors


These characters have the all the abilities of browsers, plus the ability to create and delete associations and association sets, and add and remove associations to and from association sets. There may be any number of authors.

Data

1. Text
   
   Description
   
   These objects contain ASCII text. Endpoints may be spans of text.
   
   Access Issues
   
   All characters have read access to this data. Some set of authors may have write access to this data.
   
   Synchronicity Issues
   
   Many characters may have simultaneous read access to this data. At most one author will have write access at any one time to any one object.
   

2. Graphics
   
   Description
   
   These objects contain still pictures. Endpoints may be (spatial) regions of the graphic.
   
   Access Issues
   
   All characters have read access to this data. Some set of authors may have write access to this data.
   
   Synchronicity Issues
   
   Many characters may have simultaneous read access to this data. At most one author will have write access at any one time to any one object.
   

3. Audio
   
   Description
   
   These objects contain audio information. Endpoints may be (temporal) regions of the sound clip.
   
   Access Issues
   
   All characters have read access to this data. Some set of authors may have write access to this data.
   
   Synchronicity Issues
   
   Many characters may have simultaneous read access to this data. At most one author will have write access at any one time to any one object.
   

4. Video
   
   Description
   
   These objects contain moving pictures. Endpoints may be (spatial and/or temporal) regions of the graphic.
   
   Access Issues
   
   All characters have read access to this data. Some set of authors may have write access to this data.
   
   Synchronicity Issues
   
   Many characters may have simultaneous read access to this data. At most one author will have write access at any one time to any one object.
   

Requirements for Participating Applications

Requirements for Link Server

Ability to create, modify, and delete associations and association sets


Ability to address associations and association sets persistently


A link server must be able to persistently store structure objects and retrieve these objects, including across multiple instantiations and instances of the link server.

Ability to send a request to display the referent of a persistent endpoint address


A link server must be able to send a message to an application, requesting that a particular persistent endpoint address be displayed. A link server may need to send such a message in the fulfillment of a request to follow an association.

Ability to send a message informing an application of persistent endpoints which represent active or inactive associations


A link server must be able to send a message to an application informing the application which persistent endpoint addresses are currently part of active or inactive associations. Link servers send these messages when sets of associations are opened or closed.

Ability to receive a persistent endpoint address


A link server must be able to respond to an application's message that a persistent endpoint address has been selected for some link service operation.

Ability to start an application


If no instance of the application to which a link server would send a request to display a persistent endpoint address is running in the applicable workspace, the link server must arrange for an instance of that application to be started.

Requirements for Stores

Ability to store and retrieve data, associations, and sets of associations

Implementations

This section of the scenario is not to be filled in until the scenario has been circulated among the OHS mailing list (ohs@csdl.tamu.edu).

Protocol Requirements

This scenario seems for the most part to be adequately handled by version 1.2 of the Level 1 OHP protocol. Specifically, addressing only the application/link service interactions (i.e., ignoring the interactions with the store), the protocol messages addressing the requirements above are as follows:

1. 5.6.2 - LaunchDocument seems to address link server requirement 6.
   
2. 5.6.4 - HeresAnchorTable seems to address application requirement 5 and link server requirement 4, except that in this scenario, the application does not precede this message with the 5.7.3 - GetAnchorTable.
   
3. 5.6.5, 5.6.6 - DisplayAnchor, DisplayLocSpec seems to address application requirement 4 and link server requirement 3.
   
4. 5.7.4 - RequestService seems to address application requirement 3 and link service requirement 5.
   

This scenario points out the following possible modifications to the protocol:

1. Allow that the message 5.6.4 - HeresAnchorTable be sent without request by the application. This does not imply that the 5.7.3 - GetAnchorTable message need be invalidated, but only that the timing or causal constraints between these messages should be relaxed.

2.3 Collaboration via OHS

Preliminaries

Updates
Most recent: February 12, 1997

• created February 12, 1997
  

References

2.3.1 Collaboration via OHS - Scenario

Scenario Description

• multiple (equal or greater than two) co-authors are located at different sites,
• each co-author may use another hypermedia authoring environment,
• the co-authors need to share a common (but potentially distributed) hyperdocument, and
• there is a need to support both, asynchronous as well as synchronous collaboration.

Author A and author B are working on a common hyperdocument that consists of a network of nodes and links that are partitioned into two (for each author exactly one) subsets. Each subset is maintained by the respective author's hypermedia authoring environment. Now imagine the following collaboration process:

Author A works on his local partition (i.e., browses and edits the document's components)


While doing so, he might follow a link to author's B partition which is maintained by her hypermedia authoring environment (server). Thus, access to and display of "foreign" document parts/partitions must be possible.

Now, author A wants to edit a part of author B's partition (i.e., either change existing objects, or add objects)


Thus, the issue of access control occurs. Furthermore, the server of author B must now either store or at least reference objects created by the client/browser of author A.

At this time, author B enters the game by opening her browser and noticing A's presence


This means that there must be some group awareness mechanism that allows the collaborators to recognize each other's presence (and activities). This mechanism consists of awareness detection (potentially in the server) and awareness presentation (in the client/browser).

Author B now wants to join author's A editing session to coordinate their common efforts


Thus, B's browser needs a mechanism to contact A's browser and to establish a cooperative editing session. In such a session, the authors want to share a joint workspace (e.g., the workspace of author A) and a joint view (potentially some relaxed WYSIWIS presentation). For this, the coupled browsers or hypermedia environments need to translate their respective navigation commands into each other's "command language". Furthermore, the translation of different display techniques (even of a shared document) need to be supported. Additional communication channels (such as A/V or a chatbox) need to be provided.

After they coordinated their efforts, author B then leaves the joint session and starts to work on her own (in a different part of the document)


Thus, dynamic and spontaneous session creation, join and leave must be supported.

Sometimes later, author A finishes his work and quits his browser. Now, author B deletes some objects referenced by A's environment.


In this situation, one would expect some functionality that allows the communication of such changes between the different systems (either delayed or immediate) to ensure consistency.

2.3.2 Collaboration via OHS - Analysis

Goals of the Scenario

Support for references between distributed hyperdocument partitions


Support for references from a hyperdocument maintained by one hypermedia environment into another hyperdocument maintained by another hypermedia environment. This includes not only the issue of addressing (URL's) but also of document retrieval and display of "foreign documents" and the storage of references to remote documents (parts).

Support for access control


To control access to documents/hypermedia objects, user authentification and the definition of access rights is required.

Support for group awareness


There must be some group awareness mechanism that allows the collaborators to recognize each other's presence (and activities). This mechanism consists of awareness detection (potentially in the server) and awareness presentation (in the client/browser).

Support for joint editing sessions


Thus, browsers need a mechanism to contact other/remote browsers and to establish a cooperative editing session. In such a session, the authors want to share a joint workspace (e.g., the workspace of one author) and a joint view (potentially some relaxed WYSIWIS presentation). For this, the coupled browsers or hypermedia environments need to translate their respective navigation commands into each other's "command language". Furthermore, the translation of different display techniques (even of a shared document) need to be supported. Additional communication channels (such as A/V or a chatbox) need to be provided.

Dynamic and spontaneous session creation, join and leave must be supported.

Support for consistency between remote document partitions


If co-authors change a document partition with dependencies to other remote document partitions (e.g., removing an object that is referenced by other remote objects) then consistency should be maintained. This can be achieved by different approaches: e.g., notification mechanisms, transactions, object replication and synchronization techniques.

Characters

Authors


Authors are humans using a hypermedia authoring environment to create and manipulate (possibly distributed) hyperdocuments.

Browsers


Browsers are clients (front end) of a hypermedia authoring environment providing (navigational) access to a hyperdocument provided by the server (back end) of a hypermedia authoring environment.

Servers


Servers are the back end of a hypermedia authoring environment providing storage, computational and retrieval functionality for accessing and manipulating hypermedia documents (nodes, links).

Hyperdocument


A hyperdocument is a graph structure consisting of (typed) nodes and (typed) links, that can be partitioned into one or more subsets each maintained by a server. Thus, links can either connect objects within one links (and be contained in that partition) - so called intra-server links - or links can connect objects located in different partitions (or be themselves contained in a different partition) - so called inter-server links). The same is true for references in general (say, objects referenced in aggregate nodes (composites)).

Session


A session is characterized by a set of collaborators using applications (here browsers) to access and manipulate a shared artifact (here the shared hyperdocument part) within a certain time interval. Different types of sessions can be defined depending on the specific kind of support they provide for the collaborators (e.g., extent of WYSIWIS property of shared views, synchronicity, communication channels, or specific operations).

Data

1. Hypermedia objects
   
   Description
   
   Nodes (atomic, composite), Links, Anchors etc. with attributes
   
   Access Issues
   
   Hypermedia objects are accessible by every browser that can connect to the server providing the object. Access rights might restrict access for certain authors.
   
   Synchronisity Issues
   
   Many authors can have simultaneous read access to the same hypermedia object. In order to ensure consistency, only "consistent" updates are allowed (issue of concurrency control).
   

2. Usage Informaion
   
   Description
   
   This is a record identifying who is currently working on a specific partition, and on which part of it. Potentially, more specific information (login time, current action etc.) could be provided. This information is required by the group awareness mechanism.
   
   Access Issues
   
   Every browser displaying a part of a partition can access the usage information of that partition. By accessing the usage information of related partitions, a kind of fisheye view of the usage situation could be provided.
   
   Synchronisity Issues
   
   Multiple parallel reads, but only the currently active browser of a user can update its user's usage information. If multiple browsers can execute in parallel, this is either a concurrency control problem or one needs to distinguish between different threads.
   

3. Session Information
   
   Description
   
   Describes the actual state of a session (e.g., users and their browsers, shared artifact, sharing properties, information required for joining, etc.). Note, a session is always stored at the partition where the shared artifact is maintained (e.g., represented by a composite node). The sharing properties can be arbitrarily complicated (e.g., coupling of view attributes, translation of certain operations between browsers).
   
   Access Issues
   
   Every browser in a session can read and potentially write the state (depending on floor control policy etc.). Other browsers can only read the session information for joining or for generating collaboration state overviews.
   
   Synchronisity Issues
   
   Is a floor control and concurrency control issue.
   

   ---

   Requirements for Participating Applications:

   Requirements for participating browsers are:
   Accessing and displaying group awareness
   

   Each browser needs to be able to access the usage information of the partitions it works on and to create some kind of visualization of the current usage situation in the workspace (or in the whole partition).

   Displaying remote partitions
   

   Each browser needs to be able to access a part of a remote partition via its link service and to display the retrieved object. If this is not possible, the next best option is to start the browser of the hypermedia environment maintaining the target partition on the user's workstation, so that the remote partitionis displayed via its natural interface. However, this requires the presence of an installed browser software on each participating user's machine.

   Following links accross partitions
   

   When asking the link server to trigger the destinations of a inter partition link, the link server has to trigger the display of th target objects (see above).

   Identifying its user
   

   To enable access control in the link server or stores, a user id must be provided.

   Commands for joining and leaving sessions
   

   Browsers must provide a UI for joining and leaving sessions, and controlling session behavior.

   Shared workspace functionality
   

   Browsers must provide both, functionality for transmitting their user's activities to other session members (e.g., scrolling, pointing, input activity) as well as functionality for receiving updates from remote collaborators' browsers (e.g., updating collaboration status, display etc.). This either requires a direct communication channels between cooperating browsers in a session, or a mediator object provided by the link server (see below).

   Notification interface
   

   A browser needs an interface for displaying notifications caused by remote collaborators' activities (e.g., removing referenced objects during the user's absence) and to deal with potential problems caused by these changes.

   ---

   Requirements for Link Server:

   Provide and update usage information for browsers
   

   Whenever browsers access objects via a link server, the respective usage information must be updated. Browsers can ask for usage information.

   Provide and update session information
   

   Whenever browsers access sessions via a link server (join or leave or change sharing aspects, or create sessions), the respective session information must be updated. Browsers can ask for session information.

   Provide notification information
   

   Browsers might ask for notifications (provided by the store) explicitly, or the link server might call the browser to deliver notifications actively.

   Provide access to other link servers information
   

   There are two general options when solving the problem of how browsers can access remote partitions: Either all requests are send to the local link server and transparently propagated to the target link server, or the browser itself can interact with several link servers at the same time.

   Provide mediator service to connect session members
   

   If a mediator object or service is used that mediates the communication between browsers in a session, this service can also be used to translate operations between different browsers. A more difficult problem is the translation between different display techniques.

   Public interface for access by other link servers or browsers
   

   Is required to allow other browsers to - directly or by using their link server - access objects maintained by this link server.

   ---

   Requirements for Stores:

   Storage of hypermedia objects
   

   as usual, inluding references to objects maintained by other link servers/stores.

   Storage of usage information
   

   see above

   Storage of session information
   

   see above

   ---

   Implementations:

   This section of the scenario is not to be filled in until the scenario has been circulated among the OHS mailing list (ohs@csdl.tamu.edu).

   ---

   Protocol Requirements:

    

    

   ---

   2.4 Fred the programmer

   Kasper Østerbye, U Aalborg, Denmark
      kasper@cs.auc.dk   http://www.cs.auc.dk/~kasper/

    

   Preliminaries

   Scenario description submitted for the OHS workshop in Southampton April 6-7 1997.

   Updates
   Most recent: 13 March 1997
   

   References
   

   The purpose of this scenario is primarily to force us to look forward and to highlight issues that will arise when we succeed with what can be called first generation OHS, which could be characterized by being open to integrate other applications, but where the systems themselves are somewhat closed. The scenario is about a programmer who has a system which is better than any of the present OHS systems, and still he has a lot of problems with accessing information and navigating.

    

    

   ---

   2.4.1 Fred the programmer - Scenario

    

   Scenario Description

   Fred is developing a new WWW server for the "Parts 'R us" company, which specializes in auto parts for vintage cars. The company want to allow customers to search and order parts though a WWW based interface. The company keeps it inventory in the Miracle-database. The server will be written in C++, and run on a standard Windows NT machine. Previously Fred worked on the graphical user interface used by those taking orders by phone.

   At the moment Fred is having problems with understanding the Miracle API. He is using the MegaSoft visual C++ development environment. The problem lies somewhere in the search routine he is developing. The idea is that the customer can type in free text descriptions, and the server will then respond with parts corresponding to the description. First guess is that it is the "pullDescription" that doe not properly return the string from the client message. He clicks on pullDescription in the editor, and a new window opens with the code for this procedure. "I always get this wrong Fred thinks" - "to get to the documentation you have to shift click the identifier so that it will use the CCLE (Corporate Collaborative Link Engine - by ViceCosm), rather than the build in hypertext facilities of MS Visual C++."

   The documentation and a simple test convinces Fred that the pullDescription is not the problem. Somewhere else then. The function that categorizes keywords so that they can be searched for in the database is written by Fred himself, so he is certain that that is not the problem. "Is there something I have missed from the telephone-based system?" he wonders. He has forgotten where the design document is, but knows where the maintenance manual for the telephone-based system is, as he was in charge of that himself. And sure enough, on the first page it says "to get a overview of the system - read the introduction to the *Design Document*". He clicks on "Design Document", and CCLE resolves the link. "Document viewer for WordPerfect 2.1 now available" it responds. Fred ponders if it is worth the effort to find some one who has an old version of WordPerfect around. His version of Word will not convert WordPerfect documents that old. He decides against it, and hope that he is not fundamentally wrong.

   "Didn't Barney do a free text search routine when he was here" Fred suddenly remembers. He loads the telephone system into the programming environment as the CCLE does not support wildcards in the link resolution mechanism, but the programming env. does. He search for all links tagged with "search" or "find", and among 16 hits, he sees Barney's routine. He follows the link, and the programming environment brings up the file, and scrolls to the appropriate place. The comment looks promising, but the routine is huge. He ..."shift clicks" on the routine name to get to any other stuff that is linked to this. There are again a number of possible hits from CCLE. But there is also a warning that "location specifier not link-resolvable". "I wish they would just use the net Fred punders, there I am lost but not put down". But the entry is selectable, and after a bit of investigation it turns out the link-base that Barney used is no longer available. An other dead end.

   He returns to his own code. "There is the call to the Miracle database to perform a relational select". "Can't be that Fred thinks" but he decides to check it out anyway. Clicks on "select" and the source code pops up. "Not again..". He shift-clicks on the "select" identifier, and CCLE looks up this link. It is in the context of a module that uses the Miracle-API, so we also need to include links from the Miracle company online documentation. The CCLE gets the appropriate documentation page from Miracle, and displays the result in the Netscape browser. Fred is puzzled. The code seem to be just according to the specifications, but never the less, the database does not seem to return the right results. Fred decides to ask the resident Miracle expert. He writes a short description of the problem, with links to the documentation he relies on to the files he is using including the little test program he is not able to get to work. He then mails a reference to this description to Wilma.

   He closes down the programming environment and starts to write a log entry about where he got to regarding the search routine. He adds a link to the message he sent to Wilma, and makes a personal note that he suspects in some way that the wrong database table is being used. He heads of for lunch - "Hope the afternoon is going to more productive!"

   Wilma reads the message from Fred and look up the various aspects regarding the miracle database (just like people are always home to answer the phone in movies, programmers always respond to you call for help in scenarios). She reads the message - "Oh no, not again. He is relying on online documentation from the web." She follows the link to the page describing the select call. When scrolled to the very end she gets the version number. "As I thought, they have now a newer version of the Miracle database than we have. Silly plot to get people to upgrade!" Wilma decides to update (or is it downgrade) the entry in CCLE to use the old index and pages when looking up links to Miracle. She the follows the link to Fred’s test program, which brings up the MS Visual C++ environment and makes it scroll to where the call to select is done. She does the simple changes necessary, and the test program works. She writes an answer to Fred, stating that the documentation was wrong, but the it should be OK now, and includes a link to the corrected test program.

   When Fred returns, he looks at the new documentation. The test program works fine, but he is quite annoyed that he cannot get to the new documentation, perhaps there was a way to make this "forward compatible", sometime soon we will get the new version of this Miracle database, and then I might have to change it. Well, he knows, the designers of CCLE say versioning of links across hypertext systems will be included in the next major release, but they always say so. He makes a entry in his log, and links it to the source of the search routine, so that he (or someone else) will at least know the problem and its solution when it arises next time.

    

    

   ---

   2.4.2 Fred the programmer - Analysis

    

   Analysis of the scenario:

   The following is my preliminary analysis of how to address some of the issues brought up in "Fred the programmer".

   There is a need to be able to address nodes across hypertext systems. As an example if one wants to link from documentation maintained by the CCLE to a function which is maintained in a file managed by the programming environment. My thoughts in this direction is that from the point of view of the CCLE, the programming environment is a huge composite, and it is possible to address nodes and links in that composite, perhaps in a composite specific way. I thus believe that composites can play a vital role in cross-hypertext integration. This will likely produce new and interesting variations on dangling links, and perhaps also "dangling composites". Notice that the CCLE also need to export itself as a composite, to allow the reverse integration, linking from the programming environment to the CCLE.

   As I should have expected the versioning and configuration issues always play an important role. Though several persons myself included have come up with flexible and powerful data models that can handle the issues presented in the scenario, I now believe that the real challenge in versioning and configuration is to develop a user model that is simple enough to be useful in practical situations. Cross hypertext linking does complicate the matters further and I have no solutions.

   Also notice that the hypertext system is "at the core". There is hypertext functionality everywhere at the author level as well as the reader level. Eg., it is easy for Wilma to create a few free hanging notes and links and send them by e-mail to Fred. How this is done I have no clue. But the separation between loc. specs and ref. specs as advocated by Kaj and Randy might be all that is needed to make emailing hypertext practical.

   ---

   Goals of the Scenario

   Fred has a bad day
   

   The overall goal is to investigate through a scenario where I assume the existence of the kind of open hypermedia systems we are looking at today, the kind of problems that will arise for various practical reasons. The goal is to see if OHS will solve the real problems.

   User models
   

   Some applications will have their own internal hypertext systems, help systems, or as in the scenario, where the programming environment offers computed links to navigate the source code. How do we make a consistent user-interface across a number of hypertext systems?

   Integration of different hypertext systems
   

   Normally integration has been taken to mean usage of 3rd party editors for node contents. When we are successful in getting OHS systems on the market we must also address how these can themselves be integrated. At least we must consider how we can combine internet and intranet hypertext, where the important issue is who owns what.

   ---

   Characters

   ---

   Data

   ---

   Requirements for Participating Applications:

   These requirements have yet to be figured out. Here are some keywords in loose enumeration: Versioning across platforms, access to outdated data, world wide integration, ......

   ---

   Requirements for Link Server:

   ---

   Requirements for Stores:

   ---

   Implementations:

   This section of the scenario is not to be filled in until the scenario has been circulated among the OHS mailing list (ohs@csdl.tamu.edu).

   ---

   Protocol Requirements:

   Not yet worked out, but need extensions to most if not all published integration schemes.

    

    

   ---

   2.5 Spatial 1

   Peter J. Nürnberg, U Aarhus, Denmark
      pnuern@daimi.aau.dk   http://www.daimi.aau.dk/~pnuern

    

   Preliminaries

   Updates
   Most recent: 15 June 1997 (initial version)
   

   References
   

   • Marshall, C. and Shipman, F. 1995. Spatial hypertext: designing for change. Communications of the ACM 38, 8 (Aug), 88-97.
     
   • Nürnberg, P, Leggett, J., and Schneider, E. 1997. As we should have thought. Proceedings of HT 97.
     
   • Nürnberg, P, Leggett, J., Schneider, E., and Schnase, J. 1996. HOSS: A new paradigm for computing. Proceedings of HT 96.
     

    

    

   ---

   2.5.1 Spatial 1 - Scenario

    

   Scenario Description

   Background

   People faced with the task of organizing pieces of information may be able to use spatial hypertext tools to help them perform this task. Spatial hypertext systems take advantage of people's ability to organize information spatially. In these systems, a piece of information (datum) is represented by an object with certain visual characteristics (shape, color, etc.) that help determine the "kind" of information it is. A given datum may have its visual characteristics changed by a user. Additionally, the image of the datum may contain text and/or other information.

   Users are expected to place like data into spatial structures such as stacks, vertical lists, etc. These structures may themselves be placed into structures, and so forth. For example, several vertical lists may be placed side by side, forming a group of lists.

   The spatial hypertext system should be able to recognize the spatial structures generated by users and allow users to treat all objects in such a structure as a unit for certain operations, such as movement or deletion. It recognizes these structures by conducting a "spatial parse" the space in which the data reside. An important aspect to the structure generated by a spatial parse is that it is dynamic. Repositioning one or more data may invalidate the results of a previous spatial parse. Furthermore, it is difficult to modify the results of a previous parse to account for data movement. Also, this parse is relatively (time-wise) inexpensive to perform. This means that there is no reason to keep the results of a parse after data are moved. Instead, new structures can be generated by the parser as requested.

   Scenario

   Casper is using a spatial hypertext system to organize his thoughts about a paper on a natural language problem on which he is working. He is trying to determine what existing systems can address his problem. To this end, he creates a datum for each system in which he is interested. These data are visually represented as blue boxes with the name of the system listed in the box. He organizes these blue boxes into three lists: those systems that do address his problem, those that do not, and those about which he is unsure. He heads each list with a red box datum that contains the name of the list. He is considering 7 systems. 3 of these (foo, bar, and baz) he decides do address his problem. 2 of these (widget and gadget) do not. He does not know about the final 2 (weeble and wobble). His space initially looks like this:
   
   Figure 1. The initial space.

   The spatial hypertext system he is using allows hierarchic click selection. That is, the first click on a datum selects it for a further operation, such as movement or deletion. A second click on an already selected datum additionally selects all of the datum's "neighbors" in the next highest spatial structure. Such selection of neighbors in ever higher-level structures can continue until all neighbor's in the highest level structure in which the original datum is located are selected. Clicking in "empty space" (space in which no datum resides) unselects all selected data.

   Casper decides after further reading that the weeble and wobble system do not address his problem. Casper selects the weeble object. He then clicks again to select all objects in the structure in which weeble is embedded. The spatial parser recognizes that there is a list of blue objects in which weeble is embedded, and selects all other objects in that structure. In this case, only one other datum is in this structure, that being the wobble datum. With these objects selected, his space looks like this:

   
   Figure 2. The space with the first-level neighbors of weeble selected.

   He then moves these objects into the Don't column. He then deletes the Unsure list header. His screen then looks like this:

   
   Figure 3. The space after merging the Don't and Unsure lists.

   Later, Casper decides he doesn't want to discuss systems that don't address his problem in his paper. He again selects weeble. Then he clicks again, which selects all objects in the list of blue objects in which weeble is located. In this case, the widget, gadget, and wobble data are all selected. He clicks again, and the Don't datum is added, since it belongs to the "red-headed list of blue data" structure. With these objects selected, his space looks like this:

   
   Figure 4. The space with the second-level neighbors of weeble selected.

   He then deletes all of these objects and continues his writing task.

    

    

   ---

   2.5.2 Spatial 1 - Analysis

    

   Under construction...