Appendix: The slides format
In this technical appendix, a simplified description will be
given of the slides format.
Slides are fragments of a document that may be presented to an audience.
Our approach allows for displaying slides in either
dynamic HTML or VRML.
Slides are encoded using XML.
The conversion to these formats takes place using XSLT,
the XML transformation language.
The slides contained in a document constitute a slide set.
A slide set is a collection of slides that may contain lines of text
and possibly 3D objects.
Let's look at the XML-encoding of some example
slides.
slides in XML
<document>
...
<slide id="1">
<text>
<line>What about the slide format?</line>
<break/>
<line>yeh, what about it"?</line>
</text>
<vrml>Sphere { radius 0.5 }</vrml>
</slide>
...
<slide id="2">
<vrml>Sphere { radius 0.5 }</vrml>
</slide>
...
</document>

The first slide contains some text and a 3D object.
The second slide contains only a 3D object.
Inbetween the slides there may be arbitrary text.
The slides are converted to VRML using XSLT.
To support slides in VRML a small collection
of PROTO definitions is used, as described below.
The XSLT transformation language is a declarative
language.
It allows for processing an XML-encoded text by templates
matching particular tags.
In addition, the values of attributes of tags
may be used when generating output.
The first part of our XSLT stylesheet for converting
slides to VRML looks as follows.
XSLT stylesheet
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text"/>
Apart from the obligatory declaration
that the stylesheet itself is written in XML,
there is also the indication that the file is a stylesheet.
Since we do want to generate VRML (and not XML or HTML),
we need to indicate that our output method is text,
to avoid having an XML header at the start of the output.
The template for document,
that will result in the declaration of a slideset,
looks as follows.
document
<xsl:template match="/document">
... load (extern) proto(s)
DEF slides slideset {
slides [
<xsl:apply-templates/>
] # slides
}
... include user interface
</xsl:template>
Everything that is not part of a tag containing
the xsl prefix is literally copied
to output.
In this fragment, the full
PROTO declarations have not been included
nor the code for the user interface needed
to traverse the slides.
In the middle of the fragment we see the xsl tag
apply-templates.
This results in further processing the content that is
contained between the document begin and end tag,
using the template definitions given below.
The template for the slide tag is simple.
slide
<xsl:template match="*/slide">
slide { children [
<xsl:apply-templates/>
] }
</xsl:template>
The templates for the text, line and break are equally simple.
They just result in creating an instance of the appropriate
prototypes (see below) with the appropriate content.
The template for the VRML tag is even more simple,
it literally copies the content inbetween the vrml
begin and end tag.
VRML PROTOs
On the VRML-side, we need just a collection of PROTOs
for displaying text in VRML.
The PROTOs were initially developed by
Alex van Ballegooij, who also did the majority
of the coding of an extended collection of PROTOs.
protos
- slideset -- container for slides
- slide -- container for text and objects
- slide -- container for lines of text
- line -- container for text
- break -- empty text

Note that for displaying 3D objects in a slide,
we need no specific PROTO.
Before looking at the PROTO for a set of slides,
let's look at the slide PROTO.
It is surprisingly simple.
slide
PROTO slide [
exposedField SFVec3f translation 0 0 15
exposedField SFRotation rotation 0 1 0 0
exposedField SFVec3f scale 1 1 1
exposedField MFNode children []
] {
Transform {
children IS children
translation IS translation
rotation IS rotation
scale IS scale
}
}
The slide PROTO defines an interface which may be used
to perform spatial transformations on the slide,
like translation, rotation and scaling.
The interface also includes a field to declare the
content of the slide, that is text or (arbitrary) 3D objects.
The interface of the slideset PROTO,
which corresponds to the document tag,
allows for declaring which slides belong
to the set of slides.
slideset
PROTO slideset [
exposedField SFInt32 visible 0
exposedField MFNode slides []
eventIn SFInt32 next
] {
DEF select Switch {
choice IS slides
whichChoice IS visible
}
Script {
...
}
}

Apart from the visible field,
which may be used to start a presentation
with another slide than the first one
(zero being the first index in the array of slides),
the slideset PROTO interface also contains
a so-called eventIn named next
to proceed to the next slide.
To select between the different slides
a Switch node is used,
which is controlled by a Script.
The Script contains a
function next, that implements
the corresponding event. This function simply
traverses through the slides,
one step at a time, by assigning a value to
the whichChoice field of the Switch.
annotated slides
Slides may be annotated with dialogs,
as described in section 5.
The annotation is compiled to DLP code,
which is activated whenever the slide (or level within a slide)
to which the annotation belongs is displayed.
To intercept the occurrence of a particular event,
such as the display of a slide, we use an observer
object which is specified as in the code fragment below.
observer
:- object observer : [actions].
var slide = anonymous, level = 0, projector = nil.
observer(X) :-
projector := X,
repeat,
accept( id, level, update, touched),
fail.
id(V) :- slide := V.
level(V) :- level := V.
touched(V) :- projectortouched(V).
update(V) :- act(V,slide,level).
:- end_object observer.
The observer object
has knowledge of, that is inherits from, an object
that contains particular actions.
When a new instance of an observer
is created,
the non-logical variable projector is set by
the constructor,
and the instance enters a repeat loop to accept
any of the incoming events for respectively id,
level, update and touched.
Each event has a value, that is available as a parameter
when the corresponding method is called on the acceptance
of the event.
To receive events, the observer object
must be installed as the listener for these particular events.
As indicated before, events come from the 3D scene.
For example, the touched event results from mouse clicks
on a particular object in the scene.
On accepting an event, the corresponding method or clause
is activated, resulting in either changing the value
of a non-logical instance variable,
invoking a method,
or delegating the call to another object.