Eolas Technologies Incorporated v. Adobe Systems Incorporated et al

Filing 1301

Opposed MOTION for Leave to File a Brief Re The Term "Browser Application" by Adobe Systems Incorporated, Amazon.com Inc., CDW Corporation, Google Inc., J.C. Penney Corporation, Inc., Staples, Inc., The Go Daddy Group, Inc., Yahoo! Inc., YouTube, LLC. (Attachments: # 1 Exhibit 1 - Defs Brief re the Term "Browser Application", # 2 Exhibit C to Brief - p353-meyrowitz82, # 3 Exhibit D to Brief - IRIS Hypermedia_Haan92, # 4 Exhibit E to Brief - ADBE0196713 Rowe92, # 5 Exhibit F to Brief - DBE0196715 Hindus93)(Wolff, Jason) (Additional attachment(s) added on 2/1/2012: # 6 Certificate of Authorization to File Under Seal, # 7 Text of Proposed Order) (mjc, ).

EXHIBIT D

original "hypertext" to emphasize
the linking of graphics, animation,
sound, and video with textual information. Conklin's survey article [6)
describes many of these systems.
Some of the more recent systems
are also described in the book by
Nielsen [19].

_Ide t

he subject of this article is
Intermedia, one of these
hypermedia systems.
The authors were part of
a team that developed Intermedia at
Brown University's Institute for
Research in Information and
Scholarship (IRIS) between 1985
and 1990. Intennedia is distinct from
many other hypermedia systems in
that it is intended to model a
multiuser hypermedia framework
rather than a single hypermedia program. We did not want to create an
isolated hypermedia "island~' where
linking functionality was limited to
connections between homogeneous
data managed by a single program
[16]. Our intention was to create a
model for how hypermedia functionality should be handled at the
system level, where linking would be
available for all participating applications in much the same way that
copying to and pasting from the clipboard facility is supported in the
Macintosh and Microsoft Windows
environments.
lntermedia presents the user
with a graphical file system browser
(a functional equivalent of the Macintosh Finder); a set of directmanipulation editors for text,
graphics, timelines, animations,
and videodisc data; a browser for
link information; a set of linguistic
tools; and the ability to create and
traverse links between any two selections in any document in the system. As will be explained in greater
detail, information about selections
(called anchors) and links between
these selections is maintained in a
management
system
database
(DBMS). This separation of link
data and document data is a distinctive feature of the Intermedia design.
The lntermedia user begins by

T

All illustrations used in this article were created by Dynamic Diagrams. Inc.

38

January 19921Vo1.35. No.1/CO....UNICATIO_OFTH.ACM

COMIIUNICATIONSOFTH.ACll/january 1992/Vo1.35. No.1

59

A was to
Inte.llledia
primallV'

gOal ot=
deillonst.ate that an ineeg.ated
application envlllOnlllent bulle using
obJect-o•• ented p.og.alll_ing
eechniques Is ehe bese envlllOn_ent
eo suppo.e lIypepllledla I=uncelonalley.
running the Intermedia program
from the Unix shell. The shell
prompt is replaced by a graphical
file system browser that presents
documents organized in hierarchical folders. Documents and folders
are manipulated using controls
similar to those found in the Macintosh user interface. This view of the
Intermedia document tree, which
resides on a network server, is
shared by all workstations on the
local-area network. Color slides 1-6
are screen displays showing a user
working with an lntermedia collection of nearly 600 documents about
various NASA programs.
As Yankelovich et al. have already stated, "Intermedia is both an
author's tool and a reader's tool.
The system, in fact, makes no distinction between types of users,
provided they have appropriate
access rights to the material they
wish to edit, explore, or annotate.
Creating new materials and making
and following links are all integrated into a single seamless, multiuser environment" [26]. Each Intermedia document opens in its
own window and any document can
be edited by any user with appropriate privileges. In addition to the
usual features offered by directmanipulation text and graphic editors, Intermedia users can create
and follow links between selections
in any document presented by the
file browser. This link creation and
browsing is shared by all parts of
the user environment. Again we
quote from [26]:
In an effort to fit the link-

40

making process into a conceptual
model already familiar to users, the
act of making links between Intermedia documents was modeled as
closely as possible on the Smalltalkl
Macintosh copy/paste paradigm
[10]. If links are to be made frequently, they must be a seamless
part of the user interface. In any
document, users can specify a selection region and choose the Start
Link command from the menu. In
any other document, regardless of
type, users can define another selection region and choose . . . the
Complete Link commands.
To achieve these effects, however,
we did not wish to alter an existing
operating system or create a new
one. We did, in fact, create a hypermedia program running within the
Unix operating system to achieve
the desired level of integration
among different editors. To model
how hypermedia would look when
integrated at the system level, we
created a single application that
appears to the user as though it is
the entire desktop environment. As
we describe in subsection "Integration of Hypermedia into the Desktop," we believe our strategy can be
used as a model for integrating
hypermedia into a multi program
computing environment.
It is not our intention to provide
a detailed summary of the features
of Intermedia, as this has been
done in a number of previous papers. The architecture was first described in [15]. The philosophy of
"seamless integration" among application editors found in all ver-

sions of Intermedia and the objectoriented nature of the software
development effort are detailed in
[26]. Additional features have been
described in a number of papers
over the past few years. These include features to support temporal
data types described in (3, 13, 20];
the integration of morphological
services and full-text retrieval into
this hypermedia framework described in [7]; extensions to support
group annotation of documents
described in [4]; and the ability to
replicate template structures of
linked documents described in [5].
The purpose of this article is to
focus on those unique features of
the software architecture not previously discussed. We will describe
the underlying architecture that
made all of Intermedia's hypermedia functionality possible. The
software architecture described in
this article is that found in Intermedia 4.0, completed in August 1990.
We have chosen the name IRIS
Hypermedia Seroices to describe those
parts of Intermedia which make the
hypermedia functionality possible.
The Intermedia editors, which are
responsible for manipulating the
content of their own documents,
are the surface layer of a complex
system. Each of these editors inherits functionality from the IRIS
Hypermedia Services to support
hypermedia capabilities.
The overall architecture of the
IRIS Hypermedia Services is shown
in Figure 1. The Intermedia system
appears to the Unix operating system as two processes. The Intermedia process is the end-user applica-

January 1992fVo1.35, No.1 fCOMMUNICATIONS OF TN. ACM

In orel••
to aeeOlllpllsh this kind oF Integration,

it is bese to establish ove.al. poliCY
goals and ellen to encapsulate as
lIIuch ot= tile POlicy as possible In the
obJect:-o.lelWed t=.alllewo.k eo be
used by application develope...
tion. This is built from four distinct
layers. Starting from the user's
point of view, the first layer consists
of the file browser (or Finder), the
five editors, each operating on its
own document type, and the link
browser (or Web View). These each
share functionality defined in the
second layer consisting of two
major building blocks: one for text
and one for graphic objects. Above
this is the Intermedia Layer, a set of
objects for managing hypermedia
data that is shared by the building
blocks. All these layers, in turn, are
made from classes defined by
MacApp, an object-oriented application framework developed by
Apple Computer.
Intermedia is a hypermedia application written to work on a specific version of Unix (AlUX 1.1)
and a specific graphical user interface (Macintosh). The IRIS Hypermedia Services, however, embody
those portions of the software that
are independent of both operating
system and graphical user interface. We feel this portion of the system is a useful model for the way
hypermedia services could be migrated into the computing environment and deserves careful consideration by anyone currently
designing software with hypermedia functionality.
The IRIS Hypermedia Services
is comprised of three parts. The
first part consists of the objects defined in the Intermedia Layer and
inherited by the end-user applications. The second part is the Link
Client, a library that is bound with
the Intermedia process. The third

part is the Link Server, a library
bound to a DBMS running as a separate process. The Link Client and
Link Server communicate via Unix
Domain sockets when the two processes are running on the same
machine or via Internet sockets
when they are running on separate
machines.
We will describe the IRIS Hypermedia Services in two stages. The
first section of this article, "Features
of Hypermedia Policy" describes
the hypermedia policy supported
throughout Intermedia. Here we
will describe the end-user interactions, such as copy and paste of anchors and links, and the application-program responsibilities, such
as menu handling, that define what
"hypermedia" means in Intermedia.
In the section "The Intermedia
Mechanism" the mechanism used
to support this hypermedia policy
will be discussed. Here we will describe how the "hypermedia" information was managed and integrated with the application data.
This will consist of a description of
all three parts of the IRIS Hypermedia Services: Intermedia Layer,
Link Client, and Link Server.
After the IRIS Hypermedia Services have been described, this article will conclude with a discussion
of five of the major issues to be explored in future hypermedia systems.

Features of Hypermedia POliCY
A primary goal of Intermedia was
to demonstrate that an integrated

COMMUNICATION80FTHIACM/January 1992/Vo1.35, No.1

application environment built using
object-oriented programming techniques is the best environment to
support hypermedia functionality.
In order to accomplish this kind of
integration, it is best to establish
overall policy goals and then to encapsulate as much of the policy as
possible in the object-oriented
framework to be used by application developers. Our intention was
to implement all general hypermedia policies at the framework
level, leaving only applicationspecific details unresolved. In this
way we assured maximum consistency among Intermedia applications.
Anchor/Link Display, Highlighting
and selection
All Intermedia applications must
support a persistent selection,
called an anchor. Each anchor has
an extent, the application-specific
object to which the anchor refers. A
link in Intermedia is a connection
between any two anchors. All applications must support the display of
a marker associated with each anchor. This marker has two states:
linked and unlinked. A consistent
visual appearance of this marker
and how it is to be selected by the
user is enforced as a matter of general policy in all Intermedia applications.
It is up to the individual applications to determine how to "hook"
the anchor to the appropriate document content and how to highlight the extent of the anchor. The
selection of an object varies from
application to application, depend-

.,

IRIS Hypermedia Services Architecture
This schematic diagram Of Intermedia shows the layered architecture of the Intermedla system,
with the Intermedla process on
the left and the Link server process on the right. The two processes communicate over a
socket connection. The raised and
darkened layers Identify the portions of the architecture that
constitute the IRIS Hypermedia
Services.

InterWord Document
Dickens Blogrnphy

~:~~:~::::I:t ~ 9.~J~-1""-L,··~t-...,tf-'-tI""""!...,~:-'-'-!-'+II-l!.....~-i-'-.....'-:II..............
!
' 1~'...,..1. . .·. -t~""""""-1Ip., ~.-".L.""_
.
.!•.

Paragraph
Poem
Subtitle
Title

fll.!Il!Il!Il

l'IOroIal

11ii~§0! More ... I

Charles, the first often children, was born In the same year.
NicMlas Nic~1Jy gol underway in 1838, and
continued through October 1839. in which year Dickens
resigned as editor of Bentley ~ Miscellany. The first ~.b:~,

J

I[

-

--

Bam8fJy Iltdge, which continued through November of that
year. In 1842 he embarked on a vi$itto Canada and the
United States In which he advocated international
copyright(unscrupulous American publishers, in
particular, were pirating his works) and the abolition of
E!I

slal/ety. His Amelfcan Notes, which created a furor in
America(he commented unfavorably, for one thing, on the
apparently universal-and, so far as Dickens was
concerned, highly distasteful-American predileCtion for
chewing tobacco and spilling out the juice), appeared In

:

Untitled

II

I
I
I

To:ln~

s

of Master HumPhleV~ Ooc};alllleared In 1840. andili'Je :
: &CuiioSfrj S'Wp,-li'e-gun 'In 'Misi'erHUmontiV:contlnued;
I l;3-' _. _ •• - - -, -- ,:WheriOIC'kenS commenced throu~h February 1841
( New
APPlY)
Normel +

InterMail Document

!I)f3]I!U!l

Cc:1
SUbject:lrequ~t for bibli09raPh~

181 Salle me a copy

( Send)

Nicole,

Q

~

I jusl gol another request for the Hypermedia

,~i~~~ar~h~we should send !~$ ~~M·~!S~i~
.!r!l~ ~ ~~u~~~t,~ her.lfIease send a
the version

.. ---,s

copy 10 this address in the liSt.

<>

11O'2l

QI

E!I

OctOber of that year, Mattin CINIzzlewif, part of which was

.IGU• • ..

Anchors In Text
Both Interword (left) and InterMali (right) Inherft anchor behavior from the WOrd Building Block. In these
text-based applications, an anchor conSists of any contiguous selection of characters. The anchor marker IS
placed at the upper-left corner of the flrst character In the anchor and cannot be repositioned. The highlighting Of the anchor extent Is done with the dotted line Of the "marquee."

o

i

Anchors In GraphiCs
The remaining four Intermedla applications Inherft anchor behavior
from the Graphics Building Block. The anchor'S extent Is Indicated by
plaCing grey "handles" around the objects. In the case of the Interval
tlmellne O. any time event or group of events can be an anchor. In
Intervldeo . , any line or group Of lines defining a single frame
or sequence of frames on a videodisc can be an anchor. Selections do
not have to be contiguouS, but In bOth cases the anchor marker Is
placed at the upper left Of the first Item selected and cannot be repositioned. In Intervldeo the order of selection determines the order In
which the video clips are played when following a link to the anchor.
Both InterDraw" and the InterPlay animation editor 0
allow any graphic object or combination of objects (any object
In any frame of the animation In InterPlay) to be an anchor. While at
creation the anchor marker appears at the upper left of the first obJect selected, It can be moved In these two applications In the same
way as any other graphic object.

42

InterVal Document

!i!!1.~_~iiii£!D~I't~.~ns]jTlm~e~lin!!J.~~!!i1i!!!i1i!~
_

Wntl$ autGIblographitaJ fragment

Dlrlctl and acts in amateurUlealnCais
eJ

P~bllshl$ fin.af Cnrlstmas book.,
Haunte~

~a."'id

The

Man,ln Dlcember

Copper1lllld btgins running

Da'll.tJ Capperftlld tlnls~lBs in November

Foondsencledrlllhewe,UyHOU1:8hold
Words

iiei"n-s-wmiOn-eiip.-House."------"a
fiifiiaiHouseliigiMlO appearmoiliii"i-S
fieirHousee~isiji8ii;iT.-"1
Tou" ltiJy _
Collins.

Augustu. Egg and Wilkie

Retum.loEnglllld
Glv..... lInlofmany publiC ..lading' ~O'"
hhiO\lmwork"S.

Januar~'

1992/VoI.35, No.l/COMMUMlCATIONS OPTH...eM

ing on whether the object is text,
graphics, or a cell in a table. The
relative location of the anchor
marker and the anchor extent is
also a matter determined by the
individual application.
For example, I nterWord , the
Intermedia text editor, places the
anchor marker above the first character in the anchor extent. This
marker moves with the anchor as
the text is edited, but cannot be
repositioned independently of the
anchor extent. InterDraw, the
graphics editor, and InterPlay, the
animation editor, both initially
place the marker at the upper-left
corner of the first object selected
and then allow the user to move the
marker to any position in the document. Figures 2 and 3 illustrate how
the marker is displayed in the various document types. Figure 2 depicts anchors in text-based applications; Figure 3 illustrates anchors in
graphics-based applications.
The relationship between selection of the anchor marker and selection of the anchor extent is a
matter of general policy. Regardless of the relative position of the
two, selecting the anchor marker
constitutes selecting the anchor itself. This means that editing operations (e.g., cut or copy) on a selection which includes the anchor
marker affects the anchor and link
information. An editing operation
on any portion of an anchor's extent not including the marker affects only the content of the anchor.
InterVideo Document
NEW Uh,eo Unls 2

<J[>

51.,

1<11>1

Stop

InterDraw Document

!!!~~~I~'[~.'~M~IH~OgW.~U~IW~~"-~~~

c:::I

So...

Data Consistency
It is a matter of general policy to
keep document data and anchorl
link data consistent at all times. The
system must maintain integrity of
the links and their respective endpoints in the face of editing operations on document names, locations, and contents. This is
necessary to prevent "dangling
links," (i.e., link references that
point to nonexistent data or empty
anchor references that point to data
that was not saved).
There are basically two mechanisms that have been used to maintain data consistency in hypertext
systems. The system can store anchor and link information in the
same files as the data, thereby ensuring that editing operations will
affect them both. This mechanism
is adequate for "read-only" hypertext collections where data consistency is fixed, and has been favored
in many commercial systems. However, an editing operation that affects an anchor in one document
will not necessarily affect all anchors in other documents linked to
that anchor without some further
consistency support. Unless some
additional system-wide coordination is provided, editing operations
as basic as changing a document's
name and location will cause "dan-

,~~i~!t [E ·i'~iiJ

Curr.M

.,.,

..

The user can always clarify what
portion of a document is "hooked"
to a marker by choosing the marker
and displaying its anchor extent.

gling links."
Alternatively, the anchor and
link information and the document
contents can be stored and managed in a separate but coordinated
fashion. This is the mechanism
used in Intermedia. We explain the
strategy we used in the following
two paragraphs, and in greater detail in the subsection "The Intermedia Layer."
Intermedia stores document data
in standard U nix files and anchorl
link data in a separate database.
The Intermedia document tree
begins at a "root" on a local or
mounted Unix file system such as
"/intermedialdocuments" and consists of all documents in that file
system created by Intermedia editors. The link and anchor information is stored separately in a DBMS.
Collections of anchor and link data
are partitioned into "webs." From
the user's point of view, a web is a
specific context in which anchors
and links are created and stored.
The user opens a web in order to
browse and edit a specific collection
of links. Each user can open only
one web at a time.
Responsibility for coordination
of document data with anchor/link
data resides in the IRIS Hypermedia Services. Editing operations
performed by all applications and
the Intermedia file browser pass
through this layer of the framework. For example, the deletion of
a document from the Intermedia
file browser will cause the deletion

o

InterPlay Document
New£UiIt

II

Current

Line Widths flrrowheads

lin.

../--

,. ..

50lllngo
fill

leHt letkgroond

vIt--8
~

_

a---B
8----tI

s.... =:J:tD
r••

5"'"

I~::;~

I

Dt>
1<11>1

COMMUNICATIONS OF THI ACMfJanuary 1992/VoI.35, No.1

43

and to that document throughout
the database. Saving the web, that is
saving the changes to the set of anchors and links displayed in the
Web View, will cause the application editors to first save editing
changes in all documents containing those anchors and links. If the
user saves changes to documents
but discards changes to the web,
anchor and link information that
had been cached in memory during
the editing session is not written out
to the database and remains unchanged.
selection Handling
It is a matter of policy that all applications manage persistent selections. This must be done by communicating
with
the
IRIS
Hypermedia Services, not by saving
anchor information in the documents themselves. Each editor must
support the ability to edit document
data and keep track of the location
and current state of the markers
and anchor extents. The support
for this policy varies from editor to
editor.
Menu Handling
All commands used for editing
links (create anchor, start link, complete link, etc.), displaying link
properties (display anchor properties, display link properties), and
browsing links (show anchor extent,
follow, push, pulJ) are consistent
across all Intermedia applications.
All these commands are managed
in the Intermedia Layer rather
than by the individual applications
and are presented in a pull-down
menu shared by all editors.
Editing AnchorIlink Objects
It is a matter of policy that cut!

copy/paste operations work in a
similar fashion for both document
data and anchorllink data. The
copying or cutting of the anchor
marker, not the data in the anchor
extent, constitutes the copying or
cutting of the anchor and any link
data.
Resizing of the anchor extent is

supported in the same way that resizing or extending selections is
supported. The undo and redo of
editing operations involving anchors and links are also supported
in a manner identical with other
forms of document data. For example. InterWord, like all Intermedia
editors, supports undo and redo of
all edit operations in the "live" copy
of the document maintained in
memory between Save operations.
This support is extended to cut!
copy/paste of anchor information
as well. It is possible to make a selection in one InterWord document
that contains text and link markers,
and cut that selection, thereby deleting the selected text and unlinking the selected markers. The user
can then paste the selection into
another document thereby inserting both the text and links. The
changes in the Web View map for
both documents will be reflected
immediately. Undoing the cut operation will affect the "live" copy of
the first document while undoing
the paste operation will affect the
"live" copy of the second document.
Multiuser Access to Documents,
Anchors, and Links
Intermedia supports multiple users
reading and annotating a single
document, and only one user writing to a document at a time. While
each user can have only a single
web open at a time, any number of
users on the same network can simultaneously open the same web
and view the same documents, anchors, and links. The first user to
edit the document content locks out
all other users from editing the
content until the document is
closed.
By annotation we mean the creation or modification of anchors and
links as distinct from the creation or
modification of document data.
Because Intermedia stores anchor
and link data in a separate database, we are able to support simultaneous annotation, allowing many
users to make links to the same documents at the same time. Intermedia supports separate access rights

for read, write, and annotate privileges on a per-document basis.
This world of multiuser hypermedia running across local-area
networks requires a policy establishing when changes to data by one
user become available to all users.
In Intermedia, all newly created
anchors and links are local to the
user's workstation until they are
saved to disk. Changes made to
open documents are not broadcast
to other users. Intermedia does not
update the view of anchors and
links in any open document based
on the actions of another user. Each
user must close and reopen a document and associated web to see
changes made by another user.
Active Anchors
To support editors that manipulate
temporal data such as animation
and motion video, Intermedia
adopted the policy of active anchors
[20]. Editors of temporal data support an action flag associated with
each anchor. The temporal editors
must examine the state of the action
flag on the anchor when following a
link to an animation or video document. Note that active anchors can
also be used to execute a query or
perform a sequence of actions defined in a script associated with the
destination anchor.
If the anchor's action flag is set, a
follow into that anchor causes the
application-specific action, such as
running an animation, to occur. If
the action flag is not set, following
the link opens the document and
highlights the anchor without performing the action. The content of
the anchor can be viewed, edited,
played, or executed using manual
controls.
Transfer of webs
Sets of linked documents can be
transferred from one Intermedia
system to another using a canonical
form of the link data described in
[21]. This transfer functionality
supports the selection from the Intermedia file browser of one or
more file system folders (representing the document data) containing

January 1992/Vo1.35, NO.l/COMMUNIc&TIONS OF TH. AeM

one or more web documents (representing the link data).
Though it is not specifically addressed in the Intermedia policy,
we recognize that the interchange
of hypermedia data between different hypermedia systems is an important issue. One of the authors of
this article (Meyrowitz) participated
in discussions which led to the Dexter Interchange Format (12], an
abstract reference model for hypermedia data. Another author (Riley)
participated in the planning process that has led to the proposed
HyTime standard (ISO/IEC DIS
10744) [11,18], a markup language
for representing multimedia, hypermedia, and time/space-based
documents.
Although lntermedia's transfer
policy was originally designed to
support the exchange of data between Intermedia users, Killough
has shown it to be viable as an interchange format between Intermedia
and other hypertext systems as well
[14]. This was accomplished by converting the lntermedia interchange
data into the Dexter Interchange
Format, and from this data generating the format used by the KMS
hypertext system [1]. One of the
design criteria for HyTime is that it
be Dexter-compliant. This suggests
it should be possible to convert the
Intermedia interchange format
into a HyTime format as well.

The Intermedla Mechanism
In Intermedia, the hypermedia
policies are encapsulated in a mechanism that has two major components: the Intermedia Layer and the
Link Engine. The Intermedia Layer
supports all live data manipulation
while the Link Engine supports the
storage and retrieval of persistent
link data. The storage and retrieval
of document data is managed elsewhere in the Intermedia process
and is not discussed in this article.
The Intermedia Layer is implemented as a set of classes that inherit from the MacApp application
framework as well as newly defined
classes that model anchors, links,
and webs. The Link Engine is com-

posed of the Link Client, the Link
Server, and a DBMS. The Link Client is a class with which the Intermedia Layer communicates. The
Link Client in turn communicates
with the Link Server. The Link
Server is a generalized class communicating data requests to a
DBMS.
A schematic diagram of the three
parts of the IRIS Hypermedia Services and their relation to the other
parts of the I ntermedia architecture is shown in Figure 1. This
shows how the Intermedia Layer
and Link Client are bound in the
Intermedia process and the Link
Server and DBMS are bound in a
separate process.

The Intermedia Layer
The Intermedia Layer consists of
extensions to the MacApp framework to support linking capabilities.
Included in this layer is a data
model class (IntDoc) which handles
reading anchor/link data associated
with a document. A data view class
(IntView) provides a set of abstract
methods for the display of anchor
markers and for highlighting anchor extents. Cut, copy, and paste
operations are supported by the
IntClipboard class. Activation of and
response to hypermedia operations
in the menus (create anchor, start
link, complete link, etc.) is supported by methods of the IntSelection class.
Within this object-oriented application framework, we created application building blocks that inherit some of the functionality from
the Intermedia Layer and override
some of its abstract methods. For
example, the Graphics Building
Block subclasses the IntView class
to handle graphic object selection
and highlighting of anchor extent
shown in Figure 4. This, in turn, is
used in both the InterDraw and
InterPlay editors.
The Intermedia Layer also contains a Web class. When a web is
opened, an instance of the class, the
Web Object, is created. This object
contains a live copy of all newly created and edited anchor and link

COMMUNICATIONS OF THE ACMIJanuary 1992/VoI.35, No.1

data on a per-web basis. This live
data is merged by the Intermedia
Layer with the current data from
the link database. It is here that the
policy of data consistency is enforced. The document and link
database are synchronized by forcing documents to be saved before
the data of the Web Object can be
saved. For example, a user has
made a link between a selection in
an existing document and a selection in a newly created document.
To save this link, the user saves the
Web View, which first saves the
documents that have been edited
before saving the anchor and link
information in the web. This ensures that all anchor and link information in the link database is synchronized with the current saved
state of each document.
Consistency is also maintained in
operations that affect anchor and
link information in unopened webs.
For example, when a document is
deleted, all links containing anchors
in that document are removed
from the database. The delete operation will affect links in any web
in the database. In addition, a user
can edit a portion of a document
that is all or part of an anchor extent in an unopened web. The effect this has on the anchor extent is
resolved when the edited document
and the web containing that anchor
are opened.
Intermedia provides an orientation feature called the Web View
which contains a list of the documents viewed by the user and a
map of documents linked to the
currently active window. The Web
View rationale and functionality is
described in [23]. The link map in
the Web View relies on the Web
Object for its information.
All Intermedia editors read in
anchor information from the link
database and correlate this to the
application data in each document
at the time the document is opened.
Subsequent changes in the Web
Object are displayed in the live copy
of the document and Web View on
each user's workstation, but are not
propagated to the live copy of the

45

same documents elsewhere on the
network.
The Link Engine

link, and document transactions to
the Link Engine and reads that information from the Link Engine via

the methods of the Link Client
class. These methods, which constitute Intermedia's linking protocol,

The Web Object of the Intermedia
Layer communicates the anchor,
Application Framework Architecture
The class hierarchy of Intermedla's application framework Is illustrated In part. The View
method In the MacApp layer Is
subclassed by Intvlew In the Intermedla layer where several abstract methodS to manage the
display of anchors and markers
are added. These methods are
then defined In the gVlew and
tVlew classes of the oraphlcs and
Word Building Blocks. In addition
to the subclasses from MaCApp,
the Intermedla layer adds new
classes for Anchor, Link, and Web,
shown on the right.
Client/Server/DBMS Flow of Control
The OetAnchorLlst method In the
web class of the Intermedla Layer
(see Figure 4) requests a list of all
anchors In a document. This request Is passed to the AnchorGetFirst method In the Link Client o.
This passes the request over the
socket connection to the abstract
method AnchorGetUst In the Link
Server 8 which Is defined In Link
Ctree method AnchorGetL/st •.
This method translates the request Into a series of low-level
DBMS operations (REDVREC), requesting all anchors with a specific document 10, returning the
anchors and repeating until done
O. This list of all anchors Is
cached In the Link Server" and
then returned to the AnchoroetNext method In the Link Client CD
one at a time across the socket.
••GU• •

e.

Link Engine Data Model
This shows the six major relations
In the Link Engine data mOdel.
The primary key for each relation
Is raised to Illustrate how the
data Is connected. Note that the
DOcument 10 JOins the Document
relation to the Document Lock,
Link, and Anchor relations. The
Anchor 10 Joins the Anchor, An·
chor View, Anchor Application,
and Link relations. The Link Is de·
fined as pairs of Anchor and DOCument IDS. The web Is defined as
a field of the Anchor and LInk relations.

46

January 1992/VoI.35, No.IICO .... UNICATION.OFTH.AC..

support establishment of connections over sockets, opening and
dosing of databases, and a set of
operations for manipulating document, link, and anchor data.
An example of how this data is
communicated will illustrate the
way different parts of the architecture share in the hypermedia
mechanism. When the Intermedia
process is initialized, the Link Client establishes a connection to the
Link Server and opens the link
database. When the Intermedia
user opens a web document, the
Web Object in the Intermedia
Layer requests all the corresponding web information from the Link
Engine. The Web Object has a
method called GetAnchorList (shown
in the Web class in Figure 4) which
returns a list of all anchors and
links for a document each time a
document is opened. When the
user opens a document, this request
is communicated to the Link Client,
which passes the request to the Link
Server over the socket, using a predefined set of byte codes. The Link
Server accepts these byte-coded
messages and then performs a series of operations on the database
to retrieve all anchor and link information for that document by
making calls to a DBMS, in this case
the commercially available C- Tree
[9]. The information is then returned to the Intermedia Layer
along the same communication
path. This is shown in Figure 5,
which follows the AnchorGetFirst
method from the Link Client, to the
Link Server, to the DBMS, that performs the low-level operation to
read the anchor data for the specified document ID from the database. The resultant list of all anchors is cached by the Link Server.
This list is then accessed one anchor
at a time by the Link Client through
the AnchorGetNext method. The Intermedia Layer then passes the
application-specifIc anchor information to the document editor by
invoking abstract methods that the
document editor has overridden.
These methods then display a
marker for each anchor and hook

the anchor to the appropriate data
in the document.
The Link Engine can be described in terms of a data model
and the operations that can be performed on that data model.
Data Model
The persistent link information is
organized in five major relations:
document, anchor, anchor view,
anchor application, and link. A
schematic diagram of these relations is found in Figure 6.

Document Relations. The document
relation matches a unique document identifier with the document
name, Unix path and the basic
properties such as creator, creation
time, modifier, and modification
time. The primary index for this
relation is the unique document
identifier to support efficient retrieval and reliable operation independent of changes in document
name and location.
A secondary relation is the document lock relation which maintains
information on which documents
are locked for editing. The unique
document identifier for each
locked document is related to the
process identifier of the editing
process. This information is used
during release of document locks.
Anchor Relations. The anchor relation matches a unique anchor identifier with a document identifier
and basic properties of the anchor
including creator, creation time,
modifier, modification time, and
explainer. The primary index for
this relation is the unique anchor
identifier.
Additional anchor information is
stored in two other relations.
The anchor view relation is used
to store the location of the anchor
markers in graphics documents
where the marker is positioned independently from the anchor extent. This relation, which contains
an anchor identifier, a view identifier, and three long integers, was
designed to support applications
that present more than one view of

COMMUNICATION. OF T"_ ACM'January 19921Vo1.35, No.1

the document data. An example of
this was InterSpect, a viewer for
three-dimensional
wire-frame
models that was part of an early
version of Intermedia. InterSpect
supported both a two-dimensional
and a three-dimensional view of the
same data.
The third relation with anchor
information is the anchor application
relation. Intermedia applications
store various amounts of information to define an anchor extent in
this relation, which contains an anchor identifier, three long integers,
and a string. The string, which was
included in the design to support
extensibility, is unused. In the InterDraw application, for example,
an anchor can consist of more than
one graphic object. The identifier
for each graphic object in an anchor extent is stored in one of these
relations. Managing information
about changing anchor locations in
text streams presents a particular
challenge. The InterWord application stores the information it needs
to resolve the location of each anchor-consisting of beginning offset, ending offset, and an index into
a document's history list-in a single instance of the anchor application
relation. The history list, a sequence of numbers appended to
the end of the document, tracks
additions and deletions to the document. By indexing to the appropriate point in the history list, InterWord is able to resolve the
appropriate location of each anchor.

Link Relation. The link relation
matches a unique link identifier
with basic properties of the link including creator, creation time,
modifier, and modification time.
Each link relation consists of a pair
of unique anchor identifiers and
unique document identifiers for
each side of the link. The primary
index for this relation is the unique
link identifier.
Other Relations. The database also
contains an object identifier relation
which provides the next available

47

unique identifier for the major object types. The numbers generated
by this relation are used to identify
all new document, anchor, and link
objects.
Finally, the database contains
database-computed queries stored
in separate relations that contain
the scope information displayed by
the Web View. These relations contain total numbers of anchors, links,
and documents for each unique
web identifier.
Link Engine Operations
The initial operation of the Link
Engine is the opening and dosing
of a socket connection between the
Link Client and the Link Server.
The locations of the Intermedia
document hierarchy. the Link
Server, and the link database are
passed as environment variables at
run time. Once the connection is
established, the Link Engine can
open and dose the database, using
the DBMS bound with the Link
Server. Another basic operation
returns the next availabJe unique
identifier assigned to documents,
links, and anchors.
The Link Engine supports similar sets of operations on the data
associated with documents, anchors, and links. These including
adding, modifying, and deleting
entire objects or data elements associated with each object. Move and
delete operations are supported for
folders (i.e., Unix directories) as
wen. Separate methods for manipulating access rights, path name,
and edit lock are supported for
documents.
As discussed previously in the
subsection "Transfer of Webs," a set
of operations for exporting and
importing document, anchor, and
link information is also provided.
Exporting one or more folders creates a copy of the document hierarchy in those folders and a set of
ASCII files in a canonical form containing the link data for webs in
those folders. The importing of
document and link data in this format is supported by a complementary set of operations.

48

Features for the Next
Generation
In designing and implementing
Intermedia, we have identified a
number of features that are critical
for making hypermedia a useful
part of the computing environment. The development of the Intermedia system ceased before we
could implement solutions for these
issues. Some of these features, such
as wide-area hypermedia support,
require a more extensive networking architecture than we have employed. Others, such as the need
for filtering tools, are features that
were in the original specification
for Intermedia (see [25J for an
early discussion of filtering), but
were never implemented.
The following discussion represents the results of our efforts to
define future hypermedia system
capabilities that took place at IRIS
over the past several years. The
next generation of hypermedia systems should explore solutions to
these issues.
Integration of Hypermedia
into the Desktop
If hypermedia functionality is isolated in specific hypermedia programs, the usefulness of that functionality will be very limited.
Hypermedia functionality must be
a feature of the entire computing
environment, fully reflected in
whatever graphical user interface
integrates information on the user's
screen. Whether that interface is
built around a desktop, notebook.
or room metaphor, hypermedia
linking must be available in all documents, in all applications.
This means the Link Engine. an
equivalent of the Link Client/Link
Server/DBMS layer in Intermedia.
should be as integral to the computing environment as the file system
is today.
The functionality found in the
Intermedia Layer, however, should
be separated into two parts: highlevel integration support for applications and an intermediary process that handles link-related requests.

Integration support can be provided through an application program interface (API) to a high-level
toolkit, requiring the application
developer to make calls to the API
at the appropriate times. The toolkit should contain the embodiment
of a system's hypermedia policies.
In addition, a predefined set of
callback routines will have to be
implemented by each application.
An alternate method of providing
this integration support is an application framework such as Apple's
MacApp.
Between the application features
found in this API and the database
features found in the Link Engine,
a general desktop hypermedia system will require an intermediary
process we call a Link Hub. This
Link Hub should serve four primary functions:
• keeping the list of pending links
(i.e., links not yet committed to
the database);
• managing the creation of links;
• knowing how to follow a link (i.e.,
knowing how to locate documents and which application to
invoke in order to open them);
• providing link information to a
link browser equivalent to the
Intermedia Web View.
By employing an API, a Link Hub,
and a Link Engine, all applications
should be able to incorporate linking. allowing hypermedia to be as
common an integrating feature as
cut, copy and paste is today.
Multiple Webs
The limitation of having only one
web open at a time has proven too
restrictive. We created the concept
of a web in lntermedia to provide a
specific context in which to collect
aU related anchors and links. This
context helped to separate sets of
anchors and links overlaid on the
same documents for different purposes. Restricting the user to one
active web simplified the user interface.
Developers should keep in mind
that providing no context, that is
displaying all links at all times, may
seem adequate when hypertext

January 1992/Vo1.35, No.1ICOMMUNICATfONa OF THE ACM