Locus Looks at the Turing Play:
Hypertextuality vs. Full Programmability
(draft submission)

Permission to make digital or hard copies of all or part of this material for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copyright is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires specific permission and/or fee.

HyperText 98 Pittsburgh PA USA
Copyright ACM 1998 0-89791-972-6/98/6...$5.00

ABSTRACT
Hypertext extensibility is briefly reviewed: strategies have included external execution, published internal primitives, scripted articulation points, generalized object inheritance, and guest algorithms. Hypertext algorithms are typically localized. The user/algorithm relationship in hypertext is typically master/slave; other types of relationship are possible in generalized cybertext. Hypertext algorithms normally have a clear identity; for generalized cybertext, identity of the algorithm may need to be hidden. The algorithm might only be revealed by sampling activities; these activities might or might not be structured. Identity of the programmer needs to be considered as much as that of reader or writer. Hypertext is typically structurally focused; generalized algorithms exhibit behavior, and a behavioral rather than a structural focus may be important in certain types of cybertext. Hypertextuality is not "all or nothing"; there are dimensionalities to hypertextuality, only some of which may be present. The extensibility architecture should be flexible enough to allow for all of these dimensionalities.

KEYWORDS: hypertext, extensibility, user interface, localization, user/algorithm relationship, algorithm identity, sampling, structure, behavior.

INTRODUCTION
It would be possible to implement a hypertext using purely physical means, without any recourse to software at all. Still, when one hears the word `hypertext', one thinks most often of text in which software plays a crucial role. Hypertext is a particular kind of software however; hypertext is not coequal with all software. Hypertextuality is typically viewed as a property which derives from using such particular software. Hypertext systems have varied greatly in their degree of extensibility. Although hypertext systems have been fully programmable ever since their inception [16], [45], there is a wide perception that the advent of Java has brought about a change in atmosphere, in which generalized programs might be found in hypertext anywhere. (E.g. [41].) This paper attempts to address issues facing the identity of hypertext in the face of fully Turing complete generalized programmability. (By "Turing complete" is meant a system containing a programming language with sufficient power to emulate any theoretically achievable calculation; the name refers to an abstract machine devised by Alan Turing which he proved could emulate any calculation process.) Although the focus will be on literary hypertext, it is hoped the discussion will be applicable to a broad range of hypertexts. In discussing literary hypertext we will make a point of opening the discussion to cybertextual[1] forms that may or may not be considered hypertext depending on one's point of view; to extend the discussion to more generalized kinds of algorithmic texts is important, since the issue is exactly the relationship of hypertext to more generalized algorithmic forms. A theme which will emerge throughout this paper is that dimensionalities pertaining to the algorithm are one way in which genre may be expected to operate in cybertext, and that hypertextuality -- rather than being "all or nothing" is a condition to which only some of these dimensions may apply. Hypertextuality may vary (e.g. be artistically varied) even within a single work.

Since the subject is hypertextuality vs. generalized programmability, we begin with a brief survey of the kinds of strategies that have been used in hypertext systems to provide extensibility -- i.e. to add generalized algorithms into an existing hypertext system.

A BRIEF REVIEW OF HYPERTEXT EXTENSIBILITY
Any hypertext system may be considered extensible if the source code is published. Of course publication of source code is rare in commercial systems. Apart from the ability of a user to adapt generalized algorithms to a hypertext system by modifying source code, the following strategies are among those that have been used to provide hypertext extensibility.

External Execution
A hypertext system may allow calls to external routines, which may be in any programming language supported by the native operating system. Examples of this type of extensibility are the cgi-bin interface of HTML [23] and the HyperCard XCMD/XFCN interface [29]. This type of extensibility may be severely limited by the circumstances under which the call is allowed to occur. For instance a cgi-bin script can be executed from an HTML page only by clicking on a link; the cgi-bin mechanism cannot be used to extend HTML behavior to implement e.g. "no-click" hot-spots.

Internal Languages / Published Internal Primitives
Some hypertext systems have been built on top of programming languages. NLS/Augment was built in a specially constructed language called L10, with interface components in a language called CML [46]. (And it should be noted that in NLS/Augment, links are specified fundamentally by addressing [17] which is basically a programmatic concept.) In this approach, extensibility derives from publishing to the user the primitives on top of which the hypertext system was built, allowing the user to add additional functionality using those primitives. NoteCards was built on Lisp primitives that the user could invoke [44]. Other hypertext systems, such as Trellis [19] have added a layer that includes an internal language offering a great deal of extensibility.

Scripted Articulation Points
A hypertext system may allow the author to work in units; at the points where these units "go together" the author may be able to interpose an algorithm in a scripting language supported by the hypertext system. Such languages are typically unique to the hypertext system, rather than being generalized operating-system-level languages. Examples include HyperCard [20], MacWeb [34], KMS [3], and JavaScript [24]. For instance HyperCard uses such units as stacks, cards, and buttons; depending on what the user does messages are generated; these units can contain scripts in a language called HyperTalk -- a fully Turing complete language -- which are triggered when the unit receives a message.

One weakness of this method of extensibility is that while the programming language may be fully Turing complete, it typically does not allow the author to change the structure of how the "articulation points" work. For instance in HyperCard, a HyperTalk script author may not alter the inheritance sequence by which objects receive messages. Or another HyperCard example: an object which receives a mouse-down event then "owns" the mouse, directly receiving all future mouse events until a mouse-up event occurs. This behavior cannot be altered through HyperTalk scripts.

Generalized Object Inheritance
Where a hypertext system is written in a fully object oriented programming language, such as Smalltalk, extensibility may be provided by the general mechanism of object inheritance provided by that language. Examples of such systems are Sepia [43], Dolphin [21], Hyperform[47], and HyperDisco [48]. (One could make the case that this is really the same concept as published internal primitives; the object inheritance is simply the method by which the primitives are published.)

Guest Algorithms
In HTML a Java applet maintains complete control over a window, where it becomes a kind of "guest algorithm". This can pose difficult aesthetic questions. There may be only a limited relationship between the guest algorithm and its host lexia; the guest algorithm may use a completely inconsistent interface from that of the host, and may "subvert" the host to the point of becoming a cuckoo that takes over the whole nest. At this point the host framework becomes largely irrelevant, and we are left with a study of the guest algorithm as if there were no host.

Guest algorithms provide a way to experiment with "user interface laboratories" within otherwise inflexible systems, such as HTML.

IDENTITY OF THE USER INTERFACE / LOCALIZATION OF THE ALGORITHM

Localization of the Algorithm
"Classical" hypertext might be described as text whose units bear with them their own user interface. Such fundamental concepts as following a link are typically triggered by operating a user interface object which in most cases visually appears to be in amidst the text as a visually marked anchor.[2] "Widgets", such as a standard scroll-bar or dialog box, have locations where the user is to perform some action which are likewise clearly marked. The algorithms encountered when such user interface objects are operated may seem fairly trivial, but they may in turn trigger "handlers" for algorithms of great complexity (as in the scripted articulation points concept above.) While it is typical in the case of link anchors for these to have clearly articulated boundaries, the presence or absence of a handler, and the nature of this handler (if present) may have no visible indication in the user interface. A handler may impose conditional behavior, such as a Storyspace guard field [6]. In literary hypertexts containing guard fields, there is typically no visible indication at all concerning whether a guard field is present, or what its parameters are. (E.g. see Afternoon [26].) Hypertexts presented by means of HyperCard may allow no access at all to the source code underlying event handlers; thus while the user may encounter a button with clear boundaries, there is nothing clear about the nature of the algorithm triggered when the button is clicked. Thus while some might consider this poor design, it may not be possible to place a clear boundary on the concept of "user interface" and state clearly just what kind of algorithm may be involved.

One property often found in hypertext algorithms is that they are highly localized. Or, as Deleuze and Guattari [14] might have put it, the algorithm in hypertext is typically territorialized. An anchor exists at a certain location in a lexia. User interface widgets are found at predictable locations on screen objects. Generalized algorithms, however, maintain state information which may be global to an entire system. Is localization part of what we intuitively consider a characteristic of hypertext objects when distinguishing hypertext from more generalized kinds of software? While a guard field is "more algorithmic" than a link with no guard field, the guard field concept is still highly localized: whether a link can be traversed is dependent on what other links have been visited. [28] implements what the author describes as "floating links" [27] in which a localized user interface button is connected to a global state variable used in algorithms to determine what text is presented to the user. In this case, user interface behavior somewhat resembling familiar links is used algorithmically in a highly non-local way which the user must simply "discover" to determine the effect of having performed this user interface operation. Similarly, the cybertext Book Unbound by John Cayley [12] uses a localized interface familiar from hypertext -- clicking on a range of adjacent words -- as input to its text generation algorithm, but the results are highly non-local: words clicked on one screen may appear in any future screen. (But one may argue that in this case there is a local character to the reappearance of the selected words when they do appear.) The HTML concept of "cookies" [24, Appendix D] was devised to overcome the stateless nature of HTTP transactions, achieving global state from a simple action of following a link.

Even in conventional hypertext, when the user follows a link, the resulting lexia may be generated by an algorithm. E.g. MacWeb [34] can produce lexia that are generated "on the fly". Such an algorithm is localized in the sense that the lexia is localized in the overall geography of the hypertext, though of course such an algorithm may have global state. A similar situation exists where a link is computed dynamically, e.g. a Microcosm generic link [18].

While hypertext may have had its origins in text with attached algorithms of a highly local character, shall we insist on this as a characteristic of hypertext? This seems arbitrary and unreasonable; one may say "global yearnings" are becoming increasingly common in working hypertexts. Localization is simply one among several dimensions of the algorithm which we will consider in this paper as emerging dimensions of cybertext genre.

The User/Algorithm Relationship
A user interface object may be characterized as an algorithm with a clear and predictable behavior triggered by localized identifiable objects; the relationship between the user and this algorithm may be described as master/slave where the user is the master and the algorithm is the slave. By complete contrast, a purely algorithmic text, such as the poème animée "Soleil" by Patrick Burgaud [11], presents the user with almost no interface -- indeed no interactivity at all; the user is simply present as the algorithm unfolds its results, much as the viewer is present at the cinema. (Though the user can quit.) This relationship between user and algorithm may also be described as master/slave, but in this case the user is the slave and the algorithm is the master. Unlike user interface algorithms, in this type of cybertext there may be no predictability at all to what the algorithm will do: one must simply discover this by observing its results -- perhaps during several sessions (see the discussion of "sampling" below) -- much as one must discover plot by simply observing a story unfold.

Other user/algorithm relationships are possible; e.g. in a game approach, the user might "play against" the algorithm, making the user and algorithm peers of a kind [13] (see also [38]).[3] Of course in literary hypertext an author need not make a rigid commitment to a single approach; interface elements might sometimes be invisible, might sometimes be operated entirely under control of the algorithm, and this might change without visible indication to the user. For instance "passage" by Philippe Bootz [10] is an example of a literary cybertext in which the user has a certain (unknown!) window of time in which to act; if the user does not make a choice within that window the algorithm will act on its own.

The master/slave analysis of the user/algorithm relationship is similar to but not quite the same thing as Aarseth's discussion of determinacy [2]. A user interface device could trigger random behavior under "control" of the user but without predictable outcome (e.g. Judy Malloy's Its name was Penelope [31]), and conversely an algorithmic text could be completely determinate yet leave the user in the role of slave to the algorithm as master.

IDENTITY OF THE ALGORITHM
Where algorithms are confined to simple user interface elements, the identity of the algorithm is quite clear; it is established completely by (1) the boundaries of the objects that trigger the user interface behavior and (2) the specification of that behavior. It is typical for such behavior to be completely specified in documentation that explains how to use a hypertext. For other types of cybertext the identity of the algorithm is much more problematical. One possibility is that all algorithms are accessible to the user, and indeed are considered by the author as aesthetically integral to the work. Such accessibility might in fact operate by means of typical hypertext operations, e.g. offering the text of a handler algorithm as a special type of link [34], [20]. (Of course the algorithms of a cybertext might be completely inaccessible. Some degree of inaccessibility of the code is in fact typical; most computer usage takes place on systems for which accessibility of source code for the operating system or major applications is the exception. Source code for commercial systems such as Storyspace and HyperCard is simply not made available.)

Should the source code for literary cybertext be an aesthetic object? [13] gives a striking example of a cybertext where the algorithm is itself a poem. Such works are currently the exception.

Sampling Activity Structure
Where the algorithm is not accessible directly, its effects may be understood by sampling: observing the results of the algorithm in repeated sessions. (Aarseth [2] describes very briefly a somewhat similar concept as "playing for plot".) This poses some interesting issues for criticism. Consider the case of poems generated algorithmically, such as a work by Jean Pierre Balpe [4]. Formally, each poem has an appearance identical to a poem that might have been written "by hand"; because the algorithm is inaccessible, the only way to determine the aesthetic characteristics of the algorithm is by repeatedly sampling the poems. In this case we are somewhat removed from hypertext as it is usually construed: once the poems are generated there is no interactivity to them at all. But it would be a mistake to say there is no interactivity involved whatsoever in this work: it is the user who decides how many poems to generate, i.e. when to stop. Is the artistic work in this case (1) those poems actually generated (2) all poems which might be generated (3) the algorithm itself -- even though this is completely hidden? Discovery of the algorithm through sampling is not so very different from discovery of the topography of a hypertext through the discovery of contours [5], [25]; the formal similarity of the poems produced by a generator algorithm such as those employed by Balpe to poems that might be written by hand is not so very different from the similarity of the individual lexia in many hypertexts to pieces of conventional linear text.

Where aesthetic issues pertaining to algorithm sampling may differ significantly from hypertext aesthetic issues of lies in the organization of the sampling: What is the structure of sampling activities? Hypertext activity is structured, as reflected in devices in the hypertext [40]. Repeated samplings of the results of a literature generator may offer no clear activity structure. On the other hand, where algorithms themselves are accessible by means of hypertext activities, e.g. links, algorithm sampling activity may be structured by the activity structure pertaining to these activities. The extent to which algorithm sampling activities are structured is yet another dimensionality of cybertext genre.

Identity of the Programmer
Closely tied to the issue of the identity of the algorithm is the identity of the programmer. While the literature of hypertext rhetoric is replete with discussions involving the role of reader as writer (e.g. [30], [25]), far less attention is paid to the tripartite agency of reader/writer/programmer. (For discussion on this point see [39], [13], [38].) This is a difficult issue. Surely not all writers will relish the thought of becoming programmers. Should extensibility be extended to the reader? If we are to give the reader the freedom to participate in constructing a hypertext, it is arbitrary and unreasonable to impose an artificial boundary prohibiting the reader from participating in constructing algorithms in a more general sense. At what point does "authorial intention" reside in the algorithm?

STRUCTURE VS. BEHAVIOR
Hypertext analysis and rhetoric have long been concerned with structure; one may say the node link model is an inherently structural concept. On the other hand, it is characteristic of an algorithm that it exhibits behavior; underlying structure may be much more problematical. At its most extreme an algorithm may exhibit "nothing but pure behavior" with no underlying structure at all. Thus the issue of what kind of algorithms we might call hypertext is deeply involved in the relationship between structure and behavior. In this section we explore these issues directly.

Structure vs. Behavior in the Classical Node-Link Model
The node-link model of hypertext -- say as elucidated in the Dexter Reference Model [22] -- presumes an underlying structure, namely the graph formed by the nodes and links. The system implementer is deeply involved in this structure, since the software comprising the hypertext system must maintain it and provide a way for the hypertext author to construct it. When a hypertext is complete, the extent to which this structure is accessible to the reader varies considerably with the particular hypertext. There may or may not be a graphical view attempting to give the reader a direct view of this structure, the hypertext author may encourage or discourage the reader from focusing on the structure, etc. Accessibility of the structure may vary among categories of reader; e.g. those readers with access to a full authoring environment for the hypertext system may have access to graphical views of the structure, while those with only a "run-time" viewer may not. (See [2] on this point.) Still, regardless of how directly the underlying structure can be accessed, the reader is aware that there is such a structure, and it heavily influences what a reader will do. For instance, if a graphical view of the structure is not available, one of the things a reader may attempt to do is form a "mental map" anyway [15].

Behavior in the node-link model -- as experienced by the reader -- is typically confined to navigation. When a link is followed, the system is expected to respond by presenting the lexia at the target end of the link. Other behaviors are related to choices of where to navigate; e.g. the user interface may be expected to bring up a presentation of what links are available, possibilities of backtracking etc.[4] Behavior thus takes place explicitly with reference to the underlying structure.

Of course for the hypertext author, the authoring environment will offer many behaviors related to constructing the structure.

Behavior in Alternative Hypertext Models
Various alternative hypertext models have been proposed, e.g. relations [32], piles [33], sets [36], Petri Nets [42], simultaneities [37]; some of these kinds of structure may be described as conjunctive rather than disjunctive [37] in that rather than viewing e.g. links as alternatives to one another, the user forms an abstraction consisting of the combination of elements. The behavior of the hypertext system is called upon to assist in this process. While it is not necessarily quite the same thing as navigation, such behavior is still highly focused on structure: the behavior is aimed at bringing the reader to "construction points" in the structure.

The Structural Point of View
Nürnberg, Leggett, and Schneider [35] presented a view of hypertext as just one example of what they call structural computing. In this paradigm, hypertext concepts are reformulated in terms of generalized "structure stores" and "structure processors". Behaviors are abstracted separately, and viewed as "computations over structure". This paradigm makes explicit the primacy of structure, which it seeks to generalize broadly to many realms of computing beyond hypertext. When working from this point of view, the question of "what behaviors are hypertext" seems strangely irrelevant. The degree to which a system should be considered hypertext would logically focus on the nature of the structure stores and structure processors; presumably any behaviors of such a system would inherit hypertextual characteristics from the nature of the structures they operate on. Under this paradigm, there is an abstraction layer for behaviors, but behaviors are to operate on an existing layer of structure stores.

How would a generalized algorithm fit into this scheme? While virtually any of the extensibility strategies discussed above would "work", generalized behavior not in accord with the structural framework might pose difficulties. Probably the scripted articulation points or guest algorithm concepts would be the easiest to implement.

The Behavioral Point of View
The opposite point of view is also tenable: a primary focus on behavior, with no preconceptions about structure. In a number of papers poet Philippe Bootz has argued forcefully for the functional point of view [7], [8], [9].[5] Figure 1, reproduced from [9], shows part of his scheme. The textes-auteur consists of notations prepared by the author for the programmer who will implement the génération -- the "algorithm box"; these notations might be such materials as paper scripts or storyboards, i.e. not necessarily machine readable. The texte-à-voir is the textual layer accessible to the reader. The texte-à-voir appears based on whatever functional devices trigger in the "algorithm box" (génération); structure within the algorithm box is not generally accessible. (The layer shown as texte-lu -- "text read" is a mental construction layer created by the reader; this is somewhat analogous to the notion of gathering as presented in [40].) One should note that Bootz's poetics differs considerably from much of the rhetoric familiar in the hypertext community: contrast his insistence that the various domains of author, text, and reader be separate vs. frequent assertions of reader/writer interchangeability [25], [30]. (There is no feedback loop in Bootz's scheme from the texte-lu to the textes-auteur.) Or, consider his concept of l'oevre verrouillée ("locked work") vs. constructive hypertext [25]. In this framework, structure is entirely contingent on what happens in the texte-à-voir.

What type of extensibility might open a hypertext to the behavioral point of view? Obviously the guest algorithm concept comes to mind, but this has the difficulty discussed above of cognitive dissonance between the native hypertext behavior and that within the guest. A more natural approach is the published internal primitives concept. This would allow the behavioral point of view to "be in charge" and yet use hypertext behavior where appropriate by simply invoking it.

DIMENSIONS OF HYPERTEXTUALITY
The common view of hypertext is that one chooses to work in a particular hypertext system, and the result becomes hypertext -- "thereby". The picture for cybertexts that allow full generalized programmability is much more complicated. In such a context, there is no reason whatever to assume that hypertextuality is "all or nothing". Rather: there are dimensions to hypertextuality; these dimensions become artistic variables, just like other artistic variables. Some could be present with others absent; the author might vary completely the degree to which a dimension is present depending on where one is in the work. (For instance, in "passage" [10] a mouse cursor -- in the image of a computer mouse -- can appear at some points; when this cursor appears the user can click and obtain hypertextual behavior. One doesn't really know how or where or when this cursor might be available; sometimes it happens, sometimes it doesn't.) How an author treats dimensions of hypertextuality is one of the ways that genre may be expected to emerge in cybertext space. Let us now review these dimensionalities:
 

ARCHITECTURAL SUPPORT FOR ALGORITHM GENRE
A system designed to provide support for hypertextuality yet be open to the full range of possible cybertext algorithm genres faces some interesting challenges. The guest algorithm concept would certainly support any possible algorithm, and hence e.g. any possible approach to behavior vs. structure. For the cybertext author, however, the guest algorithm concept is extremely stark: it presents the author with a "blank page" programming concept -- i.e. no real architectural support at all. The scripted articulation point concept does provide for somewhat flexible behavior, though within the confines of the architecture of the articulation points. (It should be noted that HyperCard is far more popular as a cybertext authoring tool among poets -- who often need more flexible behavior -- than among fiction writers.)

From the point of view of a cybertext author, the most desirable approach to extensibility would be to blend all of the extensibility strategies mentioned above and make them all available. The scripted articulation points concept can be achieved on top of published internal primitives. The concept of a guest algorithm space can be offered to guest primitives -- ideally presented as some form of construction kit. A construction kit built on top of published internal primitives would offer off-the-shelf abstractions to those who need only a modest amount of extensibility, yet provide all the flexibility needed by those with more extensive programming requirements.

ACKNOWLEDGMENTS
 I am grateful for the comments of Catherine C. Marshall, who read an early draft of this paper.

REFERENCES
[1] Aarseth, Espen, Cybertext: Perspectives on Ergodic Literature, Johns Hopkins University Press, Baltimore, 1997.

[2] Aarseth, Espen, "Nonlinearity and Literary Theory", Hyper / Text / Theory, ed. George Landow, Johns Hopkins University Press, Baltimore, MD., 1994, pp. 51-86.

[3] Aksyn, Robert M., and McCracken, Donald L., "Design of Hypermedia Script Languages: The KMS Experience", The fifth ACM Conference on Hypertext Proceedings, ACM, New York, 1993 pp. 268-269.

[4] Balpe, Jean Pierre, "Hommage à Jean Tardieu", A:LITTÉRATURE, Circav-Gerico, Villeneuve D'Ascq, 1994.

[5] Bernstein, Mark, Joyce, Michael, and Levine, David, "Contours of Constructive Hypertexts", ECHT `92 Proceeding of the ACM Conference on Hypertext, ACM, New York, 1992, pp. 161-170.

[6] Bolter, Jay David, Bernstein, Mark, Joyce, Michael, and Smith, John B., Getting Started with Storyspace, Eastgate Systems, Watertown, MA., 1996.

[7] Bootz, Philippe, "Poetic Machinations", Visible Language 30.2, Providence, RI, 1996, pp. 119-137.

[8] Bootz, Philippe, "Un modèle fonctionnel des textes procéduraux", Cahiers du CIRCAV ndeg. 8, éd. REXCAV, Villeneuve, d'Ascq, 1996, pp. 191-216.

[9] Bootz, Philippe, "Le point de vue fonctionnel: point de vue tragique et programme pilote", alire 10 / DOC(K)S, MOTS-VOIR, Villeneuve d'Ascq, 1997, pp. 28-47.

[10] Bootz, Philippe, "passage", alire 10 / DOC(K)S, MOTS-VOIR, Villeneuve d'Ascq, 1997.

[11] Burgaud, Patrick-Henri, "Soleil", Poemes et Quelques Lettres, Woord-Beeld, Rotterdam, to appear.

[12] Cayley, John, Book Unbound, Wellsweep, London, 1995.

[13] Cayley, John, "Pressing the Reveal Code Key", EJournal, Volume 6 Number 1, 1996, http://www.hanover.edu/philos/ejournal/archive/ej-6-1.txt.

[14] Deleuze, Giles, and Guattari, Félix, A Thousand Plateaus, University of Minnesota Press, 1987.

[15] Douglas, J. Yellowlees, "`How Do I Stop This Thing?': Closure and Indeterminacy in Interactive Narratives", Hyper / Text / Theory, ed. George Landow, Johns Hopkins University Press, Baltimore, MD., 1994, pp. 159-188.

[16] Engelbart, Douglas C., and English, William K., "A Research Center for Augmenting Human Intellect," AFIPS Conference Proceedings of the 1968 Fall Joint Computer Conference, San Francisco, CA, December 1968, Vol. 33, pp. 395-410.

[17] Engelbart, Douglas C., "Authorship Provisions in AUGMENT," COMPCON `84 Digest: Proceedings of the COMPCON Conference, San Francisco, CA, February 27 - March 1, 1984, pp. 465-472.

[18] Fountain, Andrew M., Hall, Wendy, Heath, Ian, and Davis, Hugh C., "MICROCOSM: An Open Model for Hypermedia With Dynamic Linking", The Proceedings of the European Conference on Hypertext, Cambridge University Press, 1990, pp. 298-311.

[19] Furuta, Richard, and Stotts, P. David, "Programmable Browsing Semantics in Trellis", Hypertext `89 Proceedings, ACM, New York, 1989, pp. 27-42.

[20] Goodman, Danny, The Complete HyperCard Handbook, Bantam Books, New York, 1987.

[21] Haake, Jörg M., Neuwirth, Christine M., and Streitz, Norbert A., "Coexistence and Transformation of Informal and Formal Structures: Requirements for More Flexible Hypermedia Systems", European Conference on Hypermedia Technology 1994 Proceedings, ACM, New York, 1994, pp. 1-12.

[22] Halasz, Frank G., and Schwartz, Mayer, "The Dexter Hypertext Reference Model", Hypertext Standardization Workshop, NIST, 1990.

[23] National Center for Supercomputing Applications HTTPd Development Team, "The Common Gateway Interface", 1996, http://hoohoo.ncsa.uiuc.edu/cgi/.

[24] Netscape Communications Corporation, JavaScript Guide, Mountain View, CA, 1996, http://home.netscape.com/eng/mozilla/3.0/handbook/javascript/index.html.

[25] Joyce, Michael, Of Two Minds: Hypertext Pedagogy and Poetics, The University of Michigan Press, Ann Arbor, 1995.

[26] Joyce, Michael, Afternoon, Eastgate Systems, Watertown, MA, 1990.

[27] Kendall, Robert, "Hypertextual Dynamics in A Life Set for Two", Hypertext `96, ACM, New York, 1996, pp. 74-83.

[28] Kendall, Robert, A Life Set for Two, Eastgate Systems, Watertown, MA, 1997.

[29] Koscheka, Donald, "XCMD CookBook", MacTech Magazine, Volume 4 Number 6, 1984, http://www.mactech.com/articles/mactech/Vol.04/04.06/XCMD-CookBook/text.html.

[30] Landow, G. P., Hypertext: The Convergence of Contemporary Critical Theory and Technology, Johns Hopkins University Press, 1992.

[31] Malloy, Judy, Its name was Penelope, Narrabase Press, Berkeley, CA, 1990, reprinted by Eastgate Systems, Watertown, MA, 1993.

[32] Marshall, Catherine C., Halasz, Frank G., Rogers, Russell A. and Janssen, William C. Jr., "Aquanet: a hypertext tool to hold your knowledge in place", Proceedings of Hypertext `91, ACM, New York, 1991, pp. 261-275.

[33] Marshall, Catherine C., Shipman, Frank M. III, and Coombs, James H., "VIKI: Spatial Hypertext Supporting Emergent Structure", European Conference on Hypermedia Technology 1994 Proceedings, ACM, New York, 1994, pp. 13-23.

[34] Nanard, Jocelyne, and Nanard, Marc, "Using Structured Types to Incorporate Knowledge in Hypertext", Proceedings of Hypertext `91, ACM, New York, 1991, pp. 329-343.

[35] Nürnberg, Peter J., Legget, John J., and Schneider, Erich R., "As We Should Have Thought", Hypertext 97, ACM, New York, 1997, pp. 96-101.

[36] Parunak, H. Van Dyke, "Don't Link Me In: Set Based Hypermedia for Taxonomic Reasoning", Proceedings of Hypertext `91, ACM, New York, 1991, pp. 233-242.

[37] Rosenberg, Jim, "Navigating Nowhere / Hypertext Infrawhere", SIGLINK Newsletter 3, 3, December 1994, pp. 16-19, http://www.well.com/user/jer/NNHI.html.

[38] Rosenberg, Jim. "Notes Toward a Non-linear Prosody of Space". ht_lit Mailing List, March 26, 1995, http://www.well.com/user/jer/nonlin_prosody.html.

[39] Rosenberg, Jim, "Making Way for Making Way: Co-striation Act Topographer of the Mingle Scriptor Transform Dance" SIGLINK Newsletter 4, 3, December 1995, pp. 16-17, http://www.well.com/user/jer/MWMW.html.

[40] Rosenberg, Jim, "The Structure of Hypertext Activity", Hypertext `96, ACM, New York, 1996, pp. 22-30, http://www.cs.unc.edu/~barman/HT96/P17/SHA_out.html.

[41] Smith, John B., "The King is Dead; Long Live the King!", Keynote Address, Hypertext 97, Southampton, April 1997, http://www.cs.unc.edu/~jbs/talks/ht97/pages/over.html.

[42] Stotts, P. David and Furuta, Richard "Petri-net based hypertext: Document structure with browsing semantics", ACM Trans. Off. Inf.Syst., 7, 1, (January), 1989.

[43] Streitz, Norbert, Haake, Jörg, Hannemann, Jörg, Lemke, Andreas, Schuler, Wolfgang, Schütt, Helge, and Thüring, Manfred, "SEPIA: a Cooperative Hypermedia Authoring Environment, ECHT `92 Proceeding of the ACM Conference on Hypertext, ACM, New York, 1992, pp. 11-22.

[44] Trigg, Randall H., Moran, Thomas P., and Halasz, Frank G., "Adaptability and Tailorability in NoteCards", Proceedings of INTERACT 87, Stuttgart, West Germany, 1987, pp. 723-728.

[45] Victor, Kenneth E., "A Software Engineering Environment," Proceedings of AIAA/NASA/IEEE/ACM Computers In Aerospace Conference, Los Angeles, CA, October 31-November 2, 1977, pp. 399-403.

[46] Watson, Richard W., "User Interface Design Issues for a Large Interactive System," AFIPS Conference Proceedings, Vol. 45, National Computer Conference, June 6-7, 1976, pp. 357-364.

[47] Will, Uffe Kock, and Leggett, John J., "Hyperform: Using Extensibility to Develop Dynamic, Open and Distributed Hypertext Systems", ECHT `92 Proceeding of the ACM Conference on Hypertext, ACM, New York, 1992, pp. 251-261.

[48] Will, Uffe Kock, and Leggett, John J., "The HyperDisco Approach to Open Hypermedia Systems", Hypertext `96, ACM, New York, 1996, pp. 140-148.