the morena model for hypermedia authoring and browsing

The morena Model for

Hypermedia Authoring and Browsing

Rodrigo Botafogo

1011 Heberton Ave

Pittsburgh, PA 15206

[email protected]

Daniel Moss�e

Department of Computer Science

University of Pittsburgh

Pittsburgh, PA 15260

[email protected]

ABSTRACT

This paper describes morena (MultimediaORganization Employing a Network Approach), a Petri-

net based platform for the description and execution of hypermedia applications. All the parts that

compose the application, such as sound, video, text, and buttons are described in this model and

the browsing semantics are also speci�ed. The morena model provides support for dynamic data,

such as video or audio. It also provides structured authoring, �ne-grained synchronization of

media, exibility and adaptability through message passing, user interaction, easy prototyping and

simulation, and the ability to reuse logical speci�cations.

morena's parent is Trellis, but it was in uenced by many other systems, merging their features

in a coherent and consistent framework. Applications written based on the morena model are

compact and platform independent.

Keywords: Hypermedia, Petri nets, structured authoring, synchronization, message passing, multimedia

1 Introduction

Developing a hypermedia application is a di�cult problem as many di�erent issues must be con-

sidered: from synchronization of media presentation, to their content and layout on the screen,

to consistency of the user interface in the whole application. In addition, it is well known that

describing concurrent application is an inherently di�cult problem. A simple solution for the syn-

chronization of di�erent streams in multimedia is to avoid the low-level synchronization primitives,

Int'l Conf Multimedia Computing Systems DC, May 1995

and base the presentation on a time-line approach [19], which is easy and well understood for simple

applications, but it is currently not powerful enough to specify complex applications. More com-

plex techniques are being studied and are based on Petri nets [23, 25], synchronization graphs [3],

CCS [10], among others to develop general multimedia systems.

Recently, many new models have been proposed for the development of hypermedia applications.

Buchanan and Zellweger [2] make a good comparison between many systems of interest, namely:

Xavier [13], Fire y [3], CMIF [14], Trellis [23], Geneva [11], and MODE [1]. Also of interest is

OCPN [16] and its derivations [22, 21].

This paper presents a novel model, the morena model, for the development of hypermedia

systems. Although many of the individual features of morena are also present in other systems,

morena brings together these features in a comprehensive and uni�ed formalism. The model

provides an environment for hypermedia application development taking into consideration the

following issues: structured authoring, �ne-grained synchronization of di�erent types of media,

exibility and adaptability through message passing, user interaction, easy prototyping and sim-

ulation (no need of polished data), and the ability to reuse descriptions through templates. This

last issue is not discussed in this paper for want of space (see [24]).

morena is a descendant of Trellis [23] and both systems are based on a Petri-net paradigm.

However, Trellis was originally developed for hypertext applications, and thus two main shortcom-

ings can be identi�ed: (a) it does not provide good support for dynamic data, such as audio or

video, and (b) information presentation is based on a very simple paradigm, namely, every node of

the Petri net is shown on a di�erent window. In morena nodes representing di�erent media can

be merged and shown at the same time on the same window following a visualization description.

morena was also in uenced by CMIF [14] and Videobook [19], which provide structured au-

thoring. Composite nodes containing synchronization speci�cation and multiple media can be

created and manipulated as a whole or can be duplicated and used in di�erent parts of the applica-

tion. Composite nodes have their own structure, browsing semantics and encapsulated information,

forming a hierarchy that can easily be manipulated.

In Trellis, synchronization is coarse-grained, i.e., medias can only be synchronized at their

beginning or end. morena extends the standard Petri net model allowing message passing and

�ne-grained synchronization: a dynamic medium can send synchronization messages at speci�ed

moments during its execution. But messages can be used for more than only synchronization,

since they add exibility and power to the system. The main idea of adding messages and the

2


synchronization primitives is to take advantage of the possible distinct behavior of the computations,

according to the message they receive, and to be able to send di�erent messages according to the

state of the system and the place itself.

Another advantage of morena, due to its Petri net paradigm, is the executable nature of the

model, allowing for quick prototyping. A whole application structure can be created with timing

requirements but without any actual media, and executed by the runtime engine. Authors can wait

until they are convinced that the structure is right before binding the computations to particular

media.

This paper is organized as follows: in the next section the morena model is formally described.

Then we show the implementation of a simple prototype that only implements its basic functionality.

Following that, we summarize the advantages of the morena model. Finally, directions for future

work and concluding remarks end the paper.

2 The morena Model

A morena net is an extension of a Petri net, and can be de�ned as a 5-tuple hP; T; F

n

; F

a

;Mi, as

follows.

P = fp

1

; . . . ; p

n

g is a �nite set of places;

T = ft

1

; . . . ; t

m

g is a �nite set of transitions;

F

n

� (P � T )[ (T � P ) is the set of normal ow relations.

F

a

� (P � T ) is the set of automatic ow relations.

M � (T � P ) is the set of message relations.

We introduce the morena net and its most important components in an example (Figure 1).

All the components will be later formally described. Places are represented by circles, system

transitions by solid bars, user transitions by rectangles, normal ows by solid arrows, automatic

ows by heavy arrows, and tokens by black circles inside places. This �gure does not show any

message relations, but later those will be represented by dashed arrows.

In Figure 1, when Transition h2i �res, tokens are removed from Background, Timer(5s),

and Customs(small) and added to Customs(large). The most basic type of synchronization in

a morena net is done through automatic ows. An automatic ow immediately �res the transition

3


at its head, when the place at its tail ends. Three such ows are depicted and are represented by

heavy arrows. For instance, when Timer(5s) ends, Transition h2i �res.

<0>

Music

Customs(small)

Customs(large)

Listen

Dialog

Exit<3>

Repeat

Timer(5s)

<2>

<1>

system transitions

user transitions

automatic flows

message relations

normal flows

Background

Figure 1: Example of a morena net.

In what follows, de�nitions marked with an arrow ()) are new, extending the Petri net model,

or de�ning a new term or concept. The other de�nitions are a repetition of the basic properties

and de�nitions of Petri net theory, for completeness of presentation. This section starts by giving

some basic de�nitions and quickly describing the basic execution of a morena net. Later, more

advanced features are presented. For presentation reasons, de�nitions 3 and 4 are simpli�ed. Later,

they will be modi�ed.

De�nition 1 The preset and postset of a transition t are de�ned respectively as:

�t = fp j (p; t) 2 F

a

[ F

n

g;

t� = fp j (t; p) 2 F

a

[ F

n

g:

De�nition 2 Let f be a ow relation in (P � T ) we say that P is the tail of the ow, while T is

the head. If the ow relation is in (T � P ), T is the tail and P the head.

De�nition 3 ) A transition becomes enabled when at least one of the places in its preset has a

token.

Note that this de�nition is di�erent from the standard Petri net de�nition that requires all the

places in the preset of a transition to have tokens for it to become enabled.

De�nition 4 ) A transition �res when it is enabled.

4


De�nition 5 When a transition �res all the places in its preset have tokens removed and all the

places in the postset have tokens added.

When a place receives a token it starts execution and the token is removed when execution ends.

Figures 2 and 3 show the execution of the morena net in Figure 1. Figure 2 is the actual

introduction screen of unit 1 of \Listenovate," an English course for Japanese students developed

by NEC [20, 9].

Place Background in the net is a still picture of in�nite duration that shows the Congress and

the words \Entering the U.S." as title. Customs(small) is also a still picture of in�nite duration

showing the man and the customs o�cer. Timer(5s) is a special node (a timer) that has no visual

representation and that lasts for 5 seconds. Note that although in Figure 2 the user perceives only

one scene, there are actually four active \entities": Background, Timer(5s), Customs(small),

and Transition h2i. In contrast, the pictures Background and Customs(small) in Trellis would

appear in two di�erent windows.

In morena, two types of transitions are de�ned: user and system transitions. As in Trellis,

user transitions, when they become enabled, are mapped onto the screen as buttons, and can be

�red by users. On the other hand, system transitions are never mapped onto the screen; they are

used for synchronization purposes only. In Figure 1, there are three users' transitions: Repeat,

Listen, and Exit and four system transitions numbered from 0 to 3. Note in Figure 3 that buttons

Repeat and Listen are visible.

2.1 Structured Authoring or Object-oriented Composition

The need for structured authoring and composite nodes has prompted many researchers to expand

the basic node and link hypertext model [12, 7, 17]. morena also provides a structuring model

based on composite places. As with SBL-nodes in HyDesign [17], composite places also provide

structure, behavior, and locality. Trellis, Videobook, and CMIF, also provide composite structures.

De�nition 6 A place can either be basic or composite. Basic places have as their content a

medium such as a text, video or audio. Composite places have as their content a morena net (as

de�ned in Section 2), describing a natural hierarchy.

In Figure 1, all the places seen are basic places, and the whole net is a composite place that

can be manipulated as a whole. Since a hierarchy is de�ned, we de�ne a child place to be one of

5


Figure 2: Execution of the morena net in Figure 1. Three units of information are active,

although the user only perceives one unit.

Figure 3: Execution of the morena net in Figure 1, after transition h2i has �red. The left button

is labeled \Repeat," and the right one is labeled \Listen."

the places in the morena net contained in a composite place. Parent, successor, and predecessor

are de�ned analogously.

In morena, input and output transitions are used to indicate how to start and end a composite

place. When a composite place starts (i.e., receives a token), its input transition �res.

6


De�nition 7 ) An input transition is a transition that has no preset. An output transition is a

transition that has no postset.

A composite place can have multiple input transitions. The use of multiple input transitions

and the rule for deciding which transition to �re will be described later. Output transitions are

represented in the diagrams by a transition whose ow reaches no place. When the output transition

�res, the place ends execution. In Figure 1, Transition h0i is an input transition while Exit is an

output transition.

De�nition 8 ) When a composite place's output transition is �red, the composite place execution

ends. Ending the execution of a composite place ends recursively the execution of every child in it.

Figure 4 shows two composite places hierarchically organized: Presentation and Slide, with

Presentation being the parent and Slide its child. When Presentation starts execution, its input

transition �res adding tokens to Slide and Text. Since Slide receives a token, its input transition

�res; since Slide is a composite place the �ring adds tokens to places Picture and Audio. When

the Audio ends, Slide's output transition �res (there is an automatic ow from Audio to the

output transition) ending the Slide execution. The end of the Slide execution �res Transition

h1i starting the Video, which plays until it ends and then �res Presentation's output transition,

ending the whole application.

<1>

SlideText

Video

PictureAudio

Presentation: Slide:

Figure 4: Structured authoring and coarse-synchronization in morena.

7


2.2 Messages

Messages are the only tool for communication between morena objects

1

. Null or default messages

can be speci�ed by the author of the presentation, as a means to activate child or sibling places. For

instance, when a transition �res, it sends #End# messages to places in its preset and #Start#

messages to places in its postset

2

. Note that this implements the basic browsing semantics of �ring

a transition: tokens are removed from places in the preset and added to places in the postset.

Although default messages are very useful during the simulation of a morena net (for debugging

purposes, for example), any message can be modi�ed by the application author changing the default

browsing semantics of an application. Changing defaults should be done with care as it could be

di�cult to understand the browsing semantics of the net. However, in some cases, this change may

be necessary.

The routing or distribution of messages can follow two distinct semantics, namely they can be

distributed either bottom-up or top-down traversing the predecessor/successor hierarchy. Rules for

message distribution are given later, but it su�ces to say now that a message which is sent to a

place is distributed top-down, starting at the place and propagating down to the place's children,

recursively. A message can also be generated \inside" a place, in which case it will be propagated

bottom-up, from the place to the parent until possibly reaching the root of the hierarchy.

Another important function of messages (aside fromdefault messages that used to implement the

basic browsing semantics) is to obtain �ne-grained synchronization, and to communicate between

medias, as described in the rest of this section.

2.2.1 Discretely-Adjustable Medias

Buchanan and Zellweger [2] call media segments that can change their behavior discretely-adjustable,

and MODE and Videobook use switch triggers [20] to provide this feature. To obtain discretely-

adjustable media segments in morena, authors need to make use of multiple input transitions. In

previous examples, composite places had only one input transitions, yet a composite place can have

multiple input transitions. In addition, a label is associated with each input transition.

De�nition 9 ) A label can be associated with any input transition. A label is a string of charac-

ters that will be matched against a message.

1

Since we are adopting an object-based Petri net model, we will use the terms object and place interchangeably,

when no confusion arises.

2

Default messages sent by the system are depicted enclosed in #.

8


Figure 5 shows a net that implements four behavior depending on the message it receives.

Remember that each input transition has a message and a label associated with it. When a

composite place receives a message, this message is �rst matched against the input transitions'

labels, and the matching one �res. For instance, if this net receives a Summary message, the

transition labeled Summary will �re starting place Sum:TEXT. On messages Audio, Video,

#Start#, and LongVideo the respective transitions will �re (in left to right order in the �gure).

By default, a transition that does not have a label matches a #Start# message.

Adjustable media segments can be used to customize an application. For instance, the place in

Figure 5 should receive di�erent messages according to whom it is presented: the president of the

company could be presented with the short summary, the technical people with a video describing

how to �x a problem, and the technical manager with a longer video with more information.

Presentation:

Tech:TEXT

Tech:VIDEO

Manager:VIDEO

Nar:AUDIO

Conclusion:AUDIO

"Summary" "Audio" "Video" "LongVideo"

Next

Figure 5: A discretely-adjustable media segment.

2.2.2 Synchronization

Messages are also used for �ne-grain and coarse-grain synchronization. Coarse-grain synchroniza-

tion is obtained through the use of automatic ows as shown in Figure 1. However, as with input

transitions, automatic ows can have associated with them a label. The automatic ow will �re

the transition at its head only when a message matches this label.

De�nition 10 ) Flows can be of two types: normal and automatic: Automatic ows di�er from

normal ows in that they �re the transition at their head only when they receive a matching message.

9


An automatic ow that has no label matches an #Expired# message. Together with the

following de�nition, this implements the default behavior associated with automatic ows.

De�nition 11 ) When an output transition �res, an output message associated with this transi-

tion is emitted. By default the message emitted is #Expired#.

The above de�nition is applicable directly to composite places, but the principle is also appli-

cable to basic places. Even though a basic place is not composed of a net (just performs some

actions and thus do not have output transitions), they also emit a #Expired# message at the

end of their execution. This message is used to notify the parent place that it (the basic place) has

terminated its mandated functions.

Remember that messages generated \inside" a place are propagated bottom-up. If the place

has an automatic ow, the message is matched against the ow's label. If they match, the ow will

�re the associated transition. An example of the use of labeled automatic ows will be given after

the discussion of message relations.

2.2.3 Message Relations

Message relations allow di�erent media types to communicate with each other, adding power and

exibility to the system. Message relations are represented in the �gures by dashed arrows from

transitions to places.

De�nition 12 ) A message relation is a relation between a transition and a place, and the relation

has a message associated with it. When the transition �res the message is sent to the place.

Figure 6 is an example in which most of the features provided by morena nets are used: struc-

tured authoring, encapsulation, multiple input transitions, normal and automatic ows, message

relations, message emission, and change of browsing semantics. In the picture, two composite places

are shown: Show, the parent, and Film, the child. When Show starts, tokens are added to child

places Subtitle and Film. Since Film is a composite place, when it receives a token, its unlabeled

(the default) input transition �res adding tokens to places Tech:AUDIO and Tech1:VIDEO. At

this point, users can click on any of the three buttons that appear on the screen: Exit, Dim, and

Stop. Each button is associated with one of the the three manual (user) transitions depicted by

the thin rectangles in the �gure.

If the user presses the Exit button, tokens are removed from Subtitle and Film, consequently

ending the whole application. Pressing the Stop button will send Stop messages, through the

10


<3>

Film:

"Dim"

Timer(.5s)

<2>"Volume: −1"

"NX"

SendEmit: "Next"

Stop"Stop"

"Stop"

Tech:AUDIO

Tech1: VIDEO

"Bright: −1"

Show:

SubtitleFilm

Dim

"Dim"

Exit

"Next"

<1>

"Next"

system transitions

user transitions

automatic flows

message relations

normal flows

Figure 6: Message passing with the use of message relations.

message relations, to the audio and video, stopping their execution

3

. Pressing the Dim button

generates a more complex behavior:

1. A "Dim" message is sent to the composite place Film.

3

For simplicity of presentation, there is no resume transition in this net. A resume transition would send a resume

message to the places allowing them to be restarted.

11


2. The transition labeled "Dim" in Film �res.

3. Place Timer(.5s) starts running.

4. After .5 seconds the timer ends, automatically �ring Transition h2i.

5. Messages "Bright: {1" and "Volume: {1" are sent to the video and audio places, respec-

tively. Those messages are absorbed there and the video fades a little bit, while the volume

goes down. At the same time a new token is added to the timer restarting it. The e�ect being

that every .5 seconds the picture fades a little and the volume goes down a little, obtaining

a dimming e�ect that acts synchronously in two di�erent medias.

Place Tech1:VIDEO in Film is a video with internal points marked. Whenever an internal

point is reached a "NX" message is emitted. This message matches Tech1:VIDEO's automatic

ow label, �ring transition h3i. When a token is added to place Send, a Next message is emitted

which will be sent to the parent place, the composite place Film in Show. There, the Next

message matches Film's Next automatic ow, �ring Transition h1i that sends a Next message

to Subtitle, which will display the next subtitle. Note how the complexity of Film is encapsulated

(and not seen by Show) and synchronization between the subtitles and the internal video achieved.

Two other points are of relevance in this picture: the two ows connected by an arc in Show

and the � symbol. The � symbol in the �gure indicates a change in the default message sent

from the transition to the place in its preset. Remember that when a transition �res, places in its

preset receive #End# messages. With the � symbol added to the ow, no message is sent. For

example, when Stop �res no message is sent, through the ow relations, to Tech:AUDIO and

Tech1:VIDEO. Normally, when this transition �res, tokens inTech:AUDIO and Tech1:VIDEO

should be removed, but by changing the message, those tokens are not removed and the video and

audio are undisturbed, until, of course, receiving the Stop messages, through the message relation.

2.3 And/Or Flows and Activation Sets

In Petri nets, a transition becomes enabled when all the places in its preset have tokens. It was

previously de�ned for morena that a transition would become enabled if at least one of the places

in its preset had a token. Using this rule reduces the power of morena nets as some types of

synchronization cannot be achieved, yet simpler nets can be created by allowing the \reuse" of

transitions, as for example in �gure 5, where all the places point to the same Next transition. By

12


de�ning activation sets (AS) of a transition, the whole power of Petri nets is regained, and the

\reuse" of transitions is still possible.

De�nition 13 ) Let AS

1

; AS

2

; . . . ; AS

n

be subsets (de�ned by the author of the presentation)

of a transition's (t) preset such that no two sets have any elements in common. We say that

AS

1

; AS

2

; . . . ; AS

n

are activation sets (AS) of t.

We show visually a transition's activation set by connecting the ows leaving the elements of the set

with an arc and we call the ows that are connected And ows. If a transition has more than one

activation set, then the ows comming from di�erent sets are called Or ows. Figure 7 shows tran-

sition Next that has two activation sets: fTech:TEXT, Tech2:VIDEOg and fExec:VIDEOg.

Note that the two places in the activation set are connected by an arc.

In what follows we de�ne the state of transitions and the transitions amongst states. In other

words, what are the possible states that transitions can be in and what are the conditions that

make transitions change from one state to another, respectively.

De�nition 14 Transitions can be in three states: inactive, disabled, and enabled, corresponding

to the AS states.

De�nition 15 ) Transitions are by default inactive. This state depicts the condition that there

are no tokens in the transition's preset (any AS). If all places in a transition's AS have tokens, the

AS is said to be enabled and the transition also becomes enabled. A transition becomes disabled if

it is not inactive or enabled.

Figure 7 shows an example of the use of And/Or ows and activation sets. This net is also a

discretely adjustable net. If message Executive is received, place Exec:VIDEO starts running

and transition Next becomes immediately enabled; however, if message Technical is received,

transition Next does not become immediately enabled. Places Tech:TEXT and Tech1:VIDEO

start running. When Tech1:VIDEO ends, Tech2:VIDEO starts running, only then enabling

transition Next.

Unlike typical Petri nets, having activation sets requires a change in the rules for token removal

from the AS when a transition �res:

De�nition 16 ) When a transition t �res, all places in all its enabled AS's have their tokens

removed. However, tokens will not be removed from places in AS's that are disabled.

13


Next

Tech:VIDEO Exec:VIDEOTech:TEXT

Technical Executives

Figure 7: And/Or ow with two activation sets: fTech:TEXT, Tech2:VIDEOg, fExec:VIDEOg.

2.4 Message Distribution

In this section we expand on the issue of message distribution, show the advantages of having such

scheme, and discuss the problems that arise from such a scheme. Remember that composite places

naturally de�ne a hierarchy, and through this hierarchy messages can be distributed either bottom-

up or top-down. Allowing messages to travel through the hierarchy allows encapsulation as seen in

�gure 6: when authoring Show, it is su�cient to know that place Film emits Next messages and

accepts Dimmessages. Next, the rules for message distribution through the hierarchy are de�ned.

De�nition 17 ) When a place receives a message through a message relation (i.e., generated

outside the place), the message is distributed in a top-down fashion according to the following rules:

� If the place is a basic place, it receives the message and absorbs

4

it.

� If the place is a composite place:

1. Match the labels of the input transitions against the received message. If the label and the

message are identical, we say that the transition matches the message, and the transition

�res

5

.

2. If the message does not match any input transition, the message is forwarded to all the

children that have tokens.

4

An absorbed message is processed by the absorbing object and disappears from the system.

5

Without loss of generality, we consider a single matching transition.

14


The above behavior ensures that if a message cannot be matched with an input transition label,

it will be forwarded to the children for examination. However, the transition that matches that

input message (if any) may send messages to its children.

Figure 8 shows a top-down message distribution. The �gure shows the state after step 6 below

is executed. The following steps were followed in Figure 8:

1. When Sender starts, a #Start# message is sent to Rec

1

.

2. In Rec

1

the unlabeled transition �res sending a #Start# to Rec

2

.

3. The Rec

2

subnet has no unlabeled transition, and at this time no token is added to this net

(the message is now absorbed and discarded); however, in Rec

1

place Rec

2

still has a token.

4. When the user presses the Send transition, a M

2

message is sent to Rec

1

.

5. Rec

1

has no transition labeled M

2

so it distributes this message to all its children currently

having tokens, in this case, Rec

2

.

6. Rec

2

has a transition labeled M

2

that �res adding a token to the place.

Rec2 Rec3

M1

Rec1: Rec2:

M2

Rec3:

M2

Sender:

Rec1

M2

Send

Figure 8: Top-down message distribution.

De�nition 18 ) When a message is generated inside a place (basic or composite), it is distributed

according to one and only one of the following rules:

1. Examine the automatic ows connected to this place. If any of them has a label that matches

the message, absorb the message and �re the appropriate transition.

15


2. If the message was not absorbed in the previous step, check the net's input transitions' labels.

If there is a match, �re the matching transition and absorb the message.

3. If the message was not absorbed in the previous steps, forward the message to the parent place.

Figure 9 shows a bottom-up message distribution (see �gure 6 for an example of the use of this

type of message distribution). The state represented in the �gure is after the user has pressed the

R

1

transition. The following steps were followed:

1. When Top starts, it adds a token to Child that adds a token to P enabling transitions R

1

and R

2

.

2. When the user presses R

1

message M

1

is emitted by Sender

1

.

3. Since Sender

1

has no automatic ows the message is passed \up" to the net (Child:).

4. Since this net (Child:) has no transition labeled M

1

the message is once again passed up,

reaching place Child in the Top net.

5. Place Child has two automatic ows, one of them labeledM

1

, which will �re the correspond-

ing transition adding a token to Rec

1

.

Top: Child:

Child

Rec1 Rec2Sender1Emit "M1"

R1 R2

M1 M2

Sender2Emit "M2"

p

Figure 9: Bottom-up message distribution.

16


3 Implementation

A prototype of the morena model was implemented using GNU C++ (g++V2.3.3)

6

, InterViews

(V3.1)

7

, and micro system (�System V4.3.1)

8

. This prototype implements only the model's basic

functionality, not implementing for instance, message relations, multiple input transitions, and

And/Or ows. The prototype has some 3000 lines of code, not including the size of the libraries:

InterViews and �System.

InterViews [15, 18] is a C++ class library that encapsulates the X windowing system, providing

high level abstractions such as buttons, menus, windows, brush, color, styles, �eld editors, etc. It

supports the composition of user interface components using the T

E

X composition model of boxes

and glues, that provides for device independent description of the position of objects on the screen.

For instance, in Figures 2 and 3, three \objects" are overlayed: a box containing the background

�gure, a box for the small picture of the custom's o�cer, and a box for the big picture of the

custom's o�cer and the Repeat and Listen buttons. InterViews also takes care of hardware events,

such as mouse clicks, keyboard input, etc. Every InterViews application runs an in�nite event

dispatching loop. If there are no events, the InterViews process blocks and waits for them.

�System [5] is a library of C routines that provides light-weight concurrency for shared memory

multi-processor or single processor UNIX systems. It provides tasks that have their own execution

thread, coroutines, and messages passing between tasks. Tasks can be synchronized using P and V

operations [8].

When a morena application starts, it puts the InterViews dispatching loop in an independent

thread making sure that it does not block while waiting for user input, but that it instead yields

control of the CPU. The morena net simulator then starts running on a separate thread.

Places and transitions are derived from class Scene. A scene can either be composite or ba-

sic. Scenes implement a standard interface with the following member functions: run, finish,

suspend, resume, map, unmap, and end. When a composite scene starts, every of its child

places and transitions start executing on a di�erent thread. \Executing" here means that every

scene starts listening for messages, but there are no changes in the interface. The composite scene

then looks for its input transition (there is only one in the current implementation) and sends a

#Fire#message to it. When the transition �res it will send#Start# messages to all appropriate

places.

6

GNU C++ is provided by the FSF

7

InterViews was developed by Mark Linton et al. at Stanford Junior University.

8

�System was developed by Peter A. Buhr et al. at the Univerity of Waterloo.

17


When a scene receives a message it calls the appropriate member function, e.g., when a place

receives a #Start# message it calls the run member function. The run member function is

implemented di�erently for every subclass of Scene. For instance, a still picture, when run, will

notify InterViews that the picture should be mapped onto the screen, an audio will send the audio

�le to the speakers, etc.

For quick prototyping, when an author instantiates an object (picture, audio, etc.) there is no

need to immediately bind the object to the data. If no data is provided, a \dummy" object of the

appropriate type is created. Users can create dummies with parameters to better simulate their

�nal data. For example, the author can instantiate an audio and assign to it a 10 seconds duration,

even though there is no data. At simulation time, the audio icon will appear on the screen for

10 seconds, properly synchronized. For a picture, a grayed rectangle (of a default size or of size

speci�ed by the user) appears on the screen with the words: \space reserved for picture x," where

x is the name of the picture as given by the user.

Since scenes listen for messages and messages are just strings of characters, it is easy to add

new functionality to a class. For instance, to add a fade command to a picture class, it is su�cient

to implement the fade member routine and have pictures call this member function when they get

a Fade message.

4 Future Work

We are starting the implementation of the model using GNU C++, InterViews, and �C++.

�C++ [4, 6] is an extension to C++, introducing concurrency to the language. It provides high level

abstractions for the construction of concurrent programs such as tasks, mutex classes, monitors,

etc. [6].

The model also needs to be enhanced. For instance, it does not yet provide for more complex

interaction with users other than by mouse clicks on buttons. It would also be interesting to add

variables (local and global) and a way of communicating them through the network. Tokens with

values, and transitions that use those values could be used. We intend next to add a video class

for digitized video by deriving it from \Scene" and implement the basic member functions. The

calling of functions at the appropriate time is done by Scene.

Although morena's runtime engine is powerful, as of yet, it has no compile time checker or

formatter. As a future direction we would like to perform similar analysis as performed on Petri

nets. We are well aware that the ability to change the browsing semantics of a morena net restricts

18


the kinds of possible analysis. However, we expect that in most applications those changes will be

localized and with the help of the author useful results might be obtained.

The lack of a compile time formatter also adds some limitations: for instance it is not possible to

automatically center medias as it is possible with Xavier or Fire y. One solution is to try to extend

the model to remove this limitation. Another possibility is to solve this problem by incorporating

a di�erent model into morena. For instance, it would be possible to use a Xavier

9

description to

create \basic" places displaying this type of behavior.

Another direction we are taking is to add real-time constraints and trying to make the net

distributed. Some research has already been done in that direction based on Petri nets (namely

OCPN) and we hope to be able to integrate it in our model. This will clearly necessitate a resource

allocation scheme.

5 Conclusions

The morena model presented in this paper is a powerful model containing many features existing

in other models in a coherent and consistent framework. But morena also adds new features. For

example, we are not aware of any other system that could implement the dimming e�ect of Figure 6

with such a simplicity.

The Object-Based paradigm with independent objects that communicate through message pass-

ing makes morena exible, extensible, and it can be implemented in a distributed system, as none

of the objects need global information: all their knowledge is localized. Also in morena, dynami-

cally binding algorithms allow messages can be distributed through the hierarchy without the need

of a recipient to be speci�ed.

Structured authoring and �ne-grained synchronization are two strong features of morena and

they are smoothly integrated. Although CMIF, Trellis, and Videobook all provide structured

authoring and synchronization, the integration of both features is short of ideal. For instance,

it is not possible in those systems for a child in the hierarchy to synchronize with a parent as

was done in �gure 6, in which the internal video synchronized with the subtitles in the parent

network. In CMIF this synchronization could be done through the Channel View. The Channel

View shows all the di�erent media of a presentation as a at (non hierarchical) description, and in

it, synchronizing arcs can be added between any two media. However, this violates locality making

9

Xavier is also implemented on top of InterViews and it is thus very simple to integrate it with .

19


reuse and maintenance of the speci�cation more di�cult, specially as the application becomes

larger.

morena also uses the notion of And/Or ows and Activation Sets that permits the creation of

smaller nets by \reusing" transitions. One di�culty with Petri-net-like models is that users have

a great di�culty in understanding their semantics and large nets are a further encumbrance. The

hierarchical structuring and the message independence of morena allows places to be duplicated

or reused in di�erent parts of the application e�ciently.

Acknowledgement

The authors would like to thank Ryuichi Ogawa and Yoshinori Hara for criticism and help with a

draft of this paper. We would also like to thank the Joke (J�oh�o

�

Oy�o KEn) lab for the help and

support.

References

[1] G. Blakowski, J. Hubel, and U. Langrehr. Tool support for the synchronization and presentation of

distributed multimedia. Computer Communications, 15(10):611{618, December 1992.

[2] M. C. Buchanan and P. T. Zellweger. Automatic temporal layout mechanisms. In ACM Multimedia 93,

pages 341{350, Anaheim, California, August 1993.

[3] M. C. Buchanan and P. T. Zellweger. Specifying temporal behavior in hypermedia documents. In

Proceedings of the European Conference on Hypertext, pages 262{271, Milano, Italy, November 1993.

[4] P. A. Buhr, G. Ditch�eld, R. A. Stroobosscher, B. M. Younger, and C. R. Zarnke. �c++: Concurrency

in the object-oriented language c++. Software{Practice and Experience, 22(2):137{172, February 1992.

[5] P. A. Buhr, H. I. Macdonald, and R. A. Stroobosscher. �System Reference Manual. University of

Waterloo, 1990. Version 4.3.1.

[6] P. A. Buhr and R. A. Stroobosscher. �C++ Annotated Reference Manual. University of Waterloo,

1992. Version 3.7.

[7] P. De Bra, G. Houben, and Y. Kornatzky. An extensible data model for hyperdocuments. In Proceedings

of the European Conference on Hypertext, pages 222{231, Milano, Italy, 1992.

[8] E. W. Dijkstra. The structure of the "THE"-multiprogramming system. Communications of the ACM,

11(5):341{346, May 1968.

[9] NEC Home Electronics. Listenovate. CD-ROM for PC-9800 series.

[10] S. B. Eun, E. S. No, H. C. Kim, H. Yoon, and S. R. Maeng. Speci�cation of multimedia composition

and a visual programming environment. In ACM Multimedia 93, pages 167{173, Anaheim, California,

August 1993.

[11] E. Fiume, D. Tsichritzis, and L. Dami. A temporal scripting language for object-oriented animation.

In Proccedings of Eurographics'87, 1987.

[12] F. Garzotto, P. Paolini, and D. Schwabe. HDM { A model for the design of hypertext applications. In

Proceedings of the Hypertext 91 Conference, pages 313{328, San Antonio, Texas, December 1991.

20


[13] R. Hamakawa and J. Rekimoto. Object composition and playback models for handling multimedia

data. In ACM Multimedia 93, pages 273{281, Anaheim, California, August 1993.

[14] L. Hardman, G. van Rossum, and D. C. A. Bulterman. Structured multimedia authoring. In ACM

Multimedia 93, pages 283{289, Anaheim, California, August 1993.

[15] M. A. Linton, P. R. Calder, J. A. Interrante, S. Tang, and J. M. Vlissides. InterViews Reference Manula

Version 3.1. The Board of Trustees of the Leland Stanford Junior University, 1992.

[16] T. D. C. Little and A. Ghafoor. Synchronizationn and storage models for multimedia objects. IEEE J.

on Selected Areas of Communication, 8(3):401{412, April 1990.

[17] M. Marmann and G. Schlageter. Towards a better support for hypermedia structuring: The hydesign

model. In Proceedings of the European Conference on Hypertext, pages 232{241, Milano, Italy, 1992.

[18] S. Mayer. Introduction to InterViews. Technische Universit�at M�unchen Institut f�ur Informatik, 1992.

[19] R. Ogawa, H. Harada, and A. Kaneko. Scenario-based hypermedia: A model and a system. In Proceed-

ings of the European Conference on Hypertext, pages 38{51, Paris, France, November 1990.

[20] R. Ogawa, E. Tanaka, D. Taguchi, and K. Harada. Design strategies for scenario-based hypermedia: De-

scription of its structure, dynamics, and style. In Proceedings of the European Conference on Hypertext,

pages 71{80, Milano, Italy, November 1992.

[21] B. Prabhakaran and S. V. Raghavan. Synchronization models for multimedia presentation with user

participation. In ACM Multimedia 93, pages 157{166, August 1993.

[22] N. U. Qazi, M. Woo, and A. Ghafoor. A synchronization and communication model for distributed

multimedia objects. In ACM Multimedia 93, pages 147{155, Anaheim, California, August 1993.

[23] P. D. Stotts and R. Furuta. Petri-net-based hypertext: Document structure with brwosing semantics.

ACM Transactions on Information Systems, 7(1):3{29, January 1989.

[24] E. Tanaka, R. A. Botafogo, K. Harada, and D. Taguchi. A scenario description architecture for large

scale multimedia applications. In Proceedings of the IPSJ, pages 57{62, Kyoto, Japan, March 1994. (in

japanese).

[25] T Znati, Y Deng, B Field, and S K Chang. Multi-level Speci�cation and Protocol Design for Distributed

Multi-media Communication. In Conference on Organizational Computing Systems, pages 255{268,

Atlanta, GA, Nov 1991.

21

the morena model for hypermedia authoring and browsing

Documents