5.1. Structuring Standards
This section describes some of the important standards for providing
hyperstructure to multimedia data.
SGML (Standard Generalized Markup Language - ISO 8879) is a
metalanguage for defining markup notations for text. SGML is used to
write Document Type Definitions or DTDs, to which individual document
instances must conform. It finds application in a wide and
increasing range of text processing applications.
The relevance of SGML to distributed hypermedia systems is
surprisingly high, mainly because of the great expressive power of
SGML, and its ability to handle non-textual data using "external
entities" and "notations".
o The World-Wide Web is an SGML application with its own DTD.
o The important HyTime hypermedia structuring standard (see
below) is based on SGML.
o The forthcoming MHEG hypermedia structuring standard (see
below) has an SGML encoding.
o SGML has been used in research hypermedia systems - for
o SGML is used in some commercial hypermedia systems - for
o SGML is of increasing importance for academic publishing
It was interesting to note that at a recent (CEC-sponsored) workshop
on Hypertext and Hypermedia standards, most of the speakers were
conversant with and supportive of the use of SGML for such systems.
A related standard which may become important for SGML on networks is
SDIF (SGML Data Interchange Format - ISO 9069). This standard
specifies how an SGML document, which may exist in a number of
separate files of different media types, may be encoded using ASN.1
into a single bytestream. The entity structure is preserved, so that
the bytestream may be decoded by the recipient into the same set of
HyTime (Hypermedia/Time-Based Structuring Language) is a standardised
infrastructure for the representation of integrated, open hypermedia
documents. It was developed principally by ANSI committee X3V1.8M,
and was subsequently adopted by ISO and published as ISO 10744.
HyTime is based on SGML. It is not itself an SGML DTD, but provides
constructs and guidelines ("architectural forms") for making DTDs for
describing Hypermedia documents. For instance, the Standard Music
Description Language (SMDL: ISO/IEC Committee Draft 10743) defines a
(meta-)DTD which is an application of HyTime. In fact, HyTime
started as an attempt to produce a markup scheme for music publishing
HyTime specifies how certain concepts common to all hypermedia
documents can be represented using SGML. These concepts include:
o association of objects within documents with hyperlinks
o placement and interrelation of objects in space and time
o logical structure of the document
o inclusion of non-textual data in the document
An "object" in HyTime is part of a document, and is unrestricted in
form - it may be video, audio, text, a program, graphics, etc. The
terminology used in HyTime (and in this section) thus differs
slightly from the terminology used in the rest of this report. A
HyTime object corresponds roughly to a node as defined in section
1.2, and a HyTime document is a hyperdocument in the terminology of
HyTime consists of six modules, which are very briefly and
selectively described below:
o Base module. This provides facilities required by other
modules, including a lexical model for describing element
contents; facilities for identifying policies for coping
with changes to a document, or traversing a link ("activity
tracking"); and the ability to define "container entities"
which can hold multiple data objects. This last was added
to the HyTime standard at a late stage, at the instigation
of Apple Computers Inc, as a "hook" for their Bento
o Measurement module. This allows for an object to be located
in time and/or space (which HyTime treats equivalently), or
any other domain which can be represented by a finite
coordinate space, within a bounding box called an "event",
defined by a set of coordinate points. Coordinates may be
expressed in any units (predefined units include
femtoseconds, fortnights, millenia, angstroms, Northern feet
o Location Address module. In addition to the fundamental
ability of SGML to identify and refer to elements, this
module provides a special "named location address"
architectural form which can be used to refer indirectly to
data which spans elements, or which is located in external
entities. Data may also be addressed indirectly through the
use of "queries", which return addresses of objects within
some domain which have properties matching the query. A
"HyQ" notation is provided for defining the query.
o Hyperlinks module. Two basic types of hyperlink are
defined: the contextual link (clink) has two anchors, one of
which is embedded in a document to explicitly denote the
anchor location; and the independent link (ilink) which may
have more than two anchors, and which does not require the
anchors to be embedded in the document. ilinks thus allow
hyperlink information to be maintained separately from
o Scheduling module. This specifies how events in a source
finite coordinate space (FCS) are to be mapped onto a target
FCS. For instance, events on a time axis could be projected
onto a spatial axis for graphical display purposes, or a
"virtual" time axis as used in music could be projected onto
a physical time axis.
o Rendition module. This allows for individual objects to be
modified before rendition, in an object-specific way. One
example is modification of colours in image so that it can
be displayed using the currently-selected colour map on a
graphics terminal, or changing the volume of an audio
channel according to a user's requirements.
It is not envisaged that a hypermedia application would need to use
the entire range of HyTime facilities. An application designer is
able to choose appropriate HyTime architectural forms, and to add
application-specific constraints to them. The designer may also of
course use non-HyTime SGML elements and attributes, but these aspects
of the application can't be understood by a "HyTime engine". Even in
the absence of a HyTime engine, the HyTime architectural forms
provide a useful base of ideas from which a hypermedia system
designer may wish to work.
The role of a HyTime engine is not specified in the standard, but
essentially it is a (sub)program which recognises HyTime constructs
in document instances and performs application-independent processing
on them. For instance, it could interact with multimedia network
servers to resolve and access hyperlink anchors. A commercial HyTime
engine (HyMinder) is under development by TechnoTeacher in the US,
and the Interactive Multimedia Group at the University of
Massachusetts - Lowell (contact firstname.lastname@example.org) is also
working on a HyTime engine (HyOctane).
The Davenport group (a loose consortium of interested companies and
individuals) is producing a series of standards on hypermedia which
further constrain the HyTime architectural forms. One example is the
SOFABED module , which standardises the representation of certain
kinds of navigational information - tables of contents, indexes and
HyTime was envisaged as an interchange format rather than as a format
for directly-executable hypermedia applications. It is therefore
very expressive, but may be difficult to optimise for run-time
An attempt has been made  to adapt the hyperlink structure in
WWW's existing HTML DTD to comply with HyTime's clink architectural
form. This requires changes to WWW document instances as well as to
browser software, and in the absence of any immediate benefit it has
found little favour with the WWW community. However, it is possible
that HTML2 will use some aspects of HyTime.
It is recommended that any further RARE work on networked hypermedia
should take account of the importance of SGML and HyTime.
MHEG stands for the Multimedia and Hypermedia information coding
Experts Group, also known as ISO/IEC JTC1/SC29/WG12 (it used to come
under SC2). This group is developing a standard "Coded
Representation of Multimedia and Hypermedia Information Objects" (ISO
CD 13522, or CCITT T.171), commonly called MHEG. The standard is to
be published in two parts - part 1 being the base notation,
representing objects using ASN.1, and part 2 being an alternate
notation which uses SGML. Part 1 has nearly (June 1993) achieved CD
status, and is intended to reach full IS in 1994. Part 2 is intended
to reach the CD stage in late 1993.
MHEG is suited to interactive hypermedia applications such as on-line
textbooks and encyclopaedia. It is also suited for many of the
interactive multimedia applications currently available (in
platformspecific form) on CD-ROM. MHEG could for instance be used as
the data structuring standard for a future home entertainment
interactive multimedia appliance. Telecommunications operators are
interested in MHEG for providing interactive multimedia services
To address such markets, MHEG represents objects in a non-revisable
form, and is therefore unsuitable as an input format for hypermedia
authoring applications: its place is perhaps more as an output format
for such tools. MHEG is thus not a multimedia document processing
format - instead it provides rules for the structure of multimedia
objects which permits the objects to be represented in a convenient
"final" form with the aim of direct presentation.
The MHEG draft standard is expressed in object-oriented terms. The
main object classes are outlined briefly below.
o Content class. A content object contains the encoded
(monomedia) information to be presented, along with
attributes which identify the type of information and the
encoding method, and mediaspecific attributes such as fonts
used, sampling rate, image size, etc.
o Selection class and Modification class. The user may
interact with MHEG objects which inherit interactive
behaviour from these classes. (The MHEG object model
supports multiple inheritance.)
o Action class. Two types of action may be applied to
objects: projection, which controls how objects are
rendered; and status actions which affect the state of
o Link class. MHEG hyperlinks connect a "start" object with
one or more "end" objects. Links consist of a set of
conditions relating to the state of the start object, and a
set of actions which are carried out when these conditions
are satisfied. Links also define the spatio-temporal
relationships between objects.
o Script class. Script objects are used to describe more
complex interobject linkages (e.g., multiple-source links).
MHEG does not define a scripting language - instead it
provides a formalism for encapsulating scripts which may be
executed by an external program (see SMSL below).
o Composite class. Related objects may be grouped together
into a single composite object (recursively). The
relationships between content objects within a composite
object are determined by link and script objects which also
are members of the composite object.
o Descriptor class. Descriptor objects contain general
information about sets of interchanged objects, so that a
target system can ensure it has adequate resources to run
the hypermedia application represented by the object set.
The relationship between HyTime and MHEG has not yet been fully
established. One possible relationship  is that an MHEG
application could be the output of a compilation process which used
an equivalent HyTime document as input. This approach would benefit
both from the expressive power of HyTime and the run-time efficiency
of MHEG. However, it has yet to be shown that this is feasible,
since the capabilities of HyTime and MHEG do not completely overlap.
There seems to be relatively little interest in or awareness of MHEG
within the Internet community, which is only just beginning to be
aware of HyTime. In view of the draft nature of the MHEG standard,
this report recommends that RARE should not invest substantial effort
in MHEG at this time. However, particularly in view of the interest
in it shown by PTTs, a watching brief should be kept on MHEG, as it
may well be relevant in the future.
The Open Document Architecture standard (ODA - ISO 8613 or T.140) is
a compound document interchange format designed for transferring
documents between open systems. It is able to represent documents in
both a formatted form and a processable (i.e., revisable) form, thus
allowing both the content and the printed appearance of the document
to be unambiguously transferred.
In addition to text data, ODA supports graphics and image data. A
revised version to be published in 1993 will support colour. Future
developments include support for audio content (underway) and video
content (planned). An interface to MHEG is also planned.
ODA differs from SGML in that the former concerns itself with the
physical appearance of the document, while SGML deliberately avoids
doing so. SGML concerns itself with semantic markup, and can be used
to describe a wide range of data and document architectures. ODA has
a more limited concept of a document.
Hypermedia extensions to ODA (HyperODA) are underway. The extensions
o References to data held externally to the document (similar
to SGML's external entities?).
o Non-linear structures, using contextual and independent
hyperlinks based on the HyTime model.
o Temporal relationships between document components (e.g.,
sequential, parallel, cyclic, duration, start delay).
HyperODA is not being developed in competition to HyTime or MHEG its
purpose is to add hypermedia features to ODA rather than to be a
completely general framework for hypermedia applications.
Bearing in mind that:
o the HyperODA extensions are still under development;
o in some senses ODA can be seen as a competitor to SGML,
which has greater presence in the hypermedia world;
o there seems to be a lack of enthusiasm for ODA in the
Internet community (the IETF WG on piloting ODA has
o Adobe's newly-released Acrobat technology (described below)
will have a significant effect on the marketplace;
this report recommends that ODA should not form a basis for
investment in networked hypermedia technology by RARE.
PREMO (Presentation Environment for Multimedia Objects) is a new work
item in ISO/IEC JTC1/SC24 (the graphics standards subcommittee). An
initial draft  exists, and the schedule calls for a CD by June
1994, a DIS by June 1995, and the final IS by June 1996.
PREMO addresses the construction of, presentation of, and interaction
with multimedia objects. It specifies techniques for creating
audiovisual interactive single and multiple media applications. It
is consistent with the principles of the Computer Graphics Reference
Model (CGRM, ISO 11072), and is defined in object-oriented terms.
It is not clear how PREMO relates to HyTime and MHEG. Although these
standards are listed in section 2 (References) of the initial draft,
they appear not to be mentioned in the text. The wisdom of
developing what appears to be yet another structuring standard for
multimedia data is doubtful.
The PREMO work is not sufficiently advanced to permit a judgement of
its usefulness in satisfying the requirements under discussion.
Adobe, Inc. has introduced a new format called Acrobat PDF, which it
is putting forward as a potential de facto standard for portable
document representation. Based on the Postscript page description
language, Acrobat PDF is also designed to represent the printed
appearance of a document (which may include graphics and images as
well as text. Unlike postscript however, Acrobat PDF allows data to
be extracted from the document. It is thus a revisable format. It
includes support for annotations, hypertext links, bookmarks and
structured documents in markup languages such as SGML. PDF files can
represent both the logical and the formatting structure of the
Acrobat PFD thus appears to offer very similar functionality to ODA.
Adobe's successful Postscript de facto standard profoundly influenced
information technology - it is possible that if successful, Acrobat
PDF will be almost as important. RARE should be aware of this
technology and its potential impact on multimedia information
5.2. Access Mechanisms
This section describes some standards which are useful in providing
network access to multimedia data. Of course, there are many
multimedia transport protocols, which this report does not attempt to
describe (see  for further information). The protocols mentioned
below are search/retrieve protocols which were not mentioned in .
Multimedia Extensions to SQL
A new work item in ISO (ISO/IEC JTC1 N2265) to extend the SQL
standard to include multimedia data is expected to be approved
shortly. Initially this work will concentrate on developing a
framework, and on free text data. Support for non-text data will be
added later, using a separate part of the standard for each media
The expected timescale for this standardisation work is lengthy (part
1 - the framework - is targeted for completion in 1996).
There are suggestions that this standard could be used as a query
language in conjunction with the HyQ query component of the HyTime
DFR is the Document Filing and Retrieval system, specified in ISO
10166-1 and ISO 10166-2. It is intended for office automation
applications, and falls within the Distributed Office Applications
(DOA) model of ISO 10031-1. DFR has design similarities to the ISO
Directory and to the X.400 Message Store, and it is likewise part of
DFR defines a Document Store, which provides a service to a DFR User
over an OSI protocol stack incorporating ROSE (and optionally RTSE).
A document in the Document Store may have a number of attributes
associated with it, including pointers to related documents. There
is support for multiple versions of the same document, and for
hierarchical groups of documents. The access protocol supports
searching for documents based on their attributes. DFR itself does
not restrict the content of documents in any way, but the natural
partner to DFR is the ODA standard for document content.
It is not clear that DFR offers significantly more useful
functionality than is available from other, simpler access protocols
already in use on the Internet.
5.3. Other Standards
This section briefly describes other standards in this area and
discusses their relevance.
MIME (Multipurpose Internet Mail Extensions) is a mechanism for
transferring multimedia information in an RFC822 mail message. STD11, RFC 822 defines a message representation protocol which specifies
considerable detail about message headers, but which leaves the
message content as flat ASCII text. RFC 1341 redefines the format of
message bodies to allow multi-part textual and non-textual message
bodies to be represented and exchanged without loss of information.
Because RFC 822 said very little about message content, RFC 1341 is
largely orthogonal to (rather than a revision of) RFC 822.
MIME provides facilities to include multiple objects in a single
message, to represent text in character sets other than US-ASCII, to
represent formatted multi-font text messages, to represent non
textual material such as images and audio fragments, and generally to
facilitate later extensions defining new types of Internet mail for
use by co-operating mail agents. It does not define any structure to
allow relationships between body parts within a message to be
For the purposes of the requirements considered by this report, the
relevance of MIME is that it separates media type from media
encoding, and that it defines a procedure for registering values of
The MIME construct of chief interest is the "Content-Type" field.
This contains a MIME "type" and "subtype", and any "parameters" which
further qualify the subtype. The register of MIME content-types is
maintained by the Internet Assigned Numbers Authority (IANA). Content
types defined in the MIME standard itself include:
Type Subtype Parameters Meaning
text plain charset Plain text
richtext charset Text with SGML-like
image jpeg JPEG File Interchange
gif Graphics Interchange
audio basic 8-bit -law 8kHz PCM
application ODA profile Open Document
(used (Document Architecture
for Application document.
octet- name (e.g., General binary data
stream filename); such as an arbitrary
type (for binary file.
postscript Document in
Private experimental values of types and subtypes starting with X may
be used between consenting adults without registration with IANA.
MIME also defines a "Content-Transfer-Encoding" field, which is used
to specify an invertible mapping between the "native" encoding of a
media type and a representation that may be readily exchanged using
7bit mail transfer protocols.
WWW's HTTP2 protocol makes use of MIME media type and encoding
attributes, and also uses MIME's message format for retrieving data
from the server. It is the first MIME application to utilise the
8bit Content-Transfer-Encoding, which essentially means no encoding.
SMSL is the Standard Multimedia Scripting Language. It is a proposed
new work item for ISO/IEC JTC1/SC18/WG8 (HyTime) and JTC1/SC29/WG12
(MHEG). The functional requirements are expected to be completed in
1994, and the coding scheme completed in 1995.
SMSL is designed as an open language with a similar purpose to
existing vendor-specific scripting languages such as Macromind's
"Lingo", Kaleida's "Script/X", and Gain's "GEL". The intention is to
offer an intermediate open multimedia scripting language which could
be used both for interchange purposes, and for controlling the
presentation of HyTime or MHEG multimedia structures. Several
different approaches to defining SMSL have been suggested, including
using the ANDF (Architecture-Neutral Distribution Format) approach,
and basing SMSL on SGML or on the Scheme language.
The SMSL work is not sufficiently advanced to permit a judgement of
its usefulness in satisfying the requirements under discussion.
However, it is interesting to note that despite the descriptive power
of HyTime and MHEG, there is still perceived to be a role for
The CCITT is defining a set of Audio Visual Interactive Services
(AVIs), intended for offering to domestic and business consumers over
a national network (e.g., by PTTs). These services will be specified
as T.17x recommendations, and will include MHEG. These services
would also make use of the SMSL work.
Insufficient information is available about this area to allow its
relevance to be judged.
5.4. Trade Associations
This section mentions some trade associations which are involved in
standards making in the multimedia area.
Interactive Multimedia Association
The Interactive Multimedia Association (IMA) is an international
trade association with over 250 members, representing a wide spectrum
of multimedia industry players. Members include Apple, Microsoft,
MIT CECI (the developers of AthenaMuse 2), 3DO, and many other
important market actors.
In 1989, the IMA initiated a "Compatibility Project", tasked with
developing technical solutions to the cross-platform compatibility
problem. The Project has published two important documents:
o "Recommended Practices for Multimedia Portability" 
outlines a specification for a common interface to be used
by interactive video delivery systems. It has been adopted
by the US Military as part of Military Standard 1379.
o "Recommended Practices for Enhancing Digital Audio
Compatibility in Multimedia Systems"  defines four
standard digital audio data types and four sampling rates
(from low-end -law 8kHz mono encoding, up through ADPCM
modes to CD-quality 44kHz 16-bit stereo).
Work is continuing to produce further recommendations on other
The Compatibility Project has now initiated a procurement process by
publishing three Request for Technology (RFT) documents, defining the
requirements of a platform-independent interactive multimedia system,
including networking requirements. The RFTs cover "Multimedia System
Services", a "Scripting Language for Interactive Multimedia Titles",
and "Multimedia Data Exchange". An "Architecture Reference Model"
for cross-platform desktop and distributed multimedia systems
provides the framework for these RFTs, which are pragmatic documents
outlining the technical requirements for time-based media handling in
detail. Note that relatively little is said about non-time-based
A first reading of the Multimedia Data Exchange RFT reveals that the
Apple Bento standard  and the Microsoft/IBM RIFF format  both
influenced the development of this document. The selected system may
well be based on one or both of these technologies.
A joint response to the Multimedia System Services RFT has been
received from HP, IBM and Sun. Two responses to the Scripting
Languages RFT have been received - from Kaleida (Script-X) and Gain
Technology (GEL). Two partial responses to the Multimedia Data
Exchange RFT have been received from Apple (Bento) and Avid (Open
Responses to the RFTs are currently being analysed by the IMA, and
the result will be announced in November 1993. The specifications
which will eventually result from this process will be important for
future commercial multimedia products. It is important that the
community keep a watching brief on the IMA Compatibility Project and
its possible implications for distributed multimedia applications on
Multimedia Communications Forum
The Multi-Media [sic] Communications Forum (MMCF) is a recently
formed (June 1993) trade consortium whose initial members include
IBM, National Semiconductor, Apple, Siemens and AT&T. Intended to
complement the work of the IMA, the MMCF plans to develop guidelines
and recommendations for the industry to help ensure "end-to-end
network interconnectivity of multimedia applications, workstations
and devices". They also plan to provide input to standards bodies.
It is still too early to say whether this forum will succeed. If the
IMA Compatibility Project specifications, when they are published,
leave networking issues open, then MMCF could have an important role
to play. It is recommended that RARE consider becoming an Observing
Member ($350 US pa), entitling it to attend general and annual MMCF
meetings (but not committee meetings), and to receive minutes and
other general papers (but not working documents); with the prospect
of becoming an Auditing Member ($1200 US pa) later if relevant.
Multimedia Communications Community of Interest
This is a very new organisation formed at a meeting in France in June
1993. Its charter is to promote the use of applications which let
people in different locations view documents, images, graphics and
full-motion video on a PC screen. The remit includes CSCW aspects.
Members of the organisation include IBM, Intel, Northern Telecom,
Telstra (Australia), BT, France Telecom and DB Telekom. The
companies plan field trials of multimedia services in 1Q94.
6. Future Directions
6.1. General Comments on the State-of-the-Art
Distributed hypermedia systems are now emerging from the research
phase into the experimental deployment stage. Every project team
(and standards committee), almost without exception, hopes for their
system to become the de facto standard for hypermedia.
As we've seen, Gopher and WWW already offer multimedia capability,
but they are still largely oriented to the use of external viewers
for non-text nodes. This "unintegrated" approach is in contrast to
typical stand-alone multimedia applications, where the presentation
of related information in different media is tightly integrated. The
in-line image feature of XMosaic and the new version of HTML
currently under development may represent the start of a move towards
greater integration of different media in such distributed hypermedia
Three important factors in the design of distributed hypermedia
systems appear to emerge from the preceding chapters of this report.
They can each be formulated in terms of distinctions between two
aspects of the system.
o A common and apparently fruitful approach to hypermedia
systems is to distinguish the content from the
hyperstructure. Standards work clearly distinguishes
between these concepts, with standards such as MPEG, JPEG,
G.72x, etc, for content; and HyTime or MHEG for structure.
Currently-deployed systems also make this distinction, most
obviously in Gopher, where the structure/content split maps
onto the server filesystem's directory/file split. In a
similar way, the ability to maintain hyperlink information
separately from data is perceived in hypermedia research
circles as a "good thing". Research systems such as
Microcosm and Hyper-G do this, and HyTime with its ilink
element also supports it. WWW does not support this, but
requires link anchors to be edited into source data. There
are problems with this approach, however - see the section
on Microcosm for details.
o A useful approach to content is to distinguish the media
type from the media encoding. The MIME standard (used by
HTTP2) illustrates how this can be done, and Gopher+ employs
a similar system.
o The distinction between data and protocol is also important
for some systems. WWW for instance has clearly separate
protocol (HTTP) and data (HTML) specifications. However,
Gopher+ is specified without making this distinction. (The
original Gopher system is very simple and arguably has no
need for such separation.)
The most significant mismatches between the capabilities of
currentlydeployed systems and user requirements are in the areas of
presentation and quality of service. Adding flexibility in
presentation capabilities to WWW or Gopher should be possible without
any major change to the protocols (although it may require changes to
data formats). Such capabilities could result from the progress
towards greater integration of media types presaged above. However,
improving QOS is significantly more difficult, as it may require
changes at a more fundamental level. The following section outlines
some possible solutions to this problem.
6.2. Quality of Service
Meeting the responsiveness requirement is certainly the key factor
for the acceptance of networked multimedia information systems in the
user community. To reiterate the requirement given in a previous
o For simple actions such as "next page", tolerable delays are
of the order of 0.2s.
o For more complex actions such as "search for documents
containing this word", then a tolerable delay is of the
order of 2s.
o Users tend to give up waiting for a response after about
There are several methods which may alleviate the problem of poor
responsiveness (or cause the user to revise his or her expectations
of responsiveness!), some of which are described below.
1. Give clues that fetching a particular item might be time-
consuming - simply quoting the size (and/or location) may be
sufficient. WAIS and some Gopher clients already quote the
2. Display a "progress" indicator while fetching data.
3. Allow the user to interact with other, previously fetched
information while waiting for data to be retrieved. The
inability to do this is an annoying limitation of XMosaic.
It can be difficult to implement, except on a multi-threaded
operating system such as OS/2 or Windows NT.
4. Allow several fetches to be performed in parallel. Again,
multithreading support makes this easier. This technique is
less likely to be useful if all the nodes being requested
come from the same server.
5. Pre-fetch information which the client software believes the
user will wish to see next. This requires some "hints" in
the data about which nodes might be good candidates for pre-
6. Cache information locally. The use of Universal Resource
Numbers (see the section on WWW) is relevant for managing
7. Where multiple copies of the same information are held in
different network locations, fetch the "nearest" copy. This
is sometimes known as "anycasting", and is a more general
case of local caching. The proposed URN-to-URL resolution
service  could be used to support this.
8. When retrieving a document, the client should be able to
display the first part of the document to the user. The
user can then start to read the document while the system is
still downloading it. Alternatively, the user may decide
that the document is not relevant and abort the retrieval.
9. Offer multiple views of image or video data at different
resolutions and therefore sizes. This enables the user to
select a balance between speed of retrieval and data
quality. Gopher+ and HTML2 both support this.
10. Future high-speed networks and protocols (ATM, RTP) will
allow real-time display of isochronous data. Information
systems should be able to take advantage of this.
A useful description of the problem is given in . This paper
rightly contends that the view, held by many hypermedia researchers
and implementors, that the network is simply a transparent data
highway which needs no special consideration in application design,
is wrong. It is argued that:
"the very same structural characteristics that may make
a multimedia document appealing to the end user are the
characteristics that are extremely helpful during
dynamic network performance optimisation".
This is a particularly relevant statement considered in the light of
suggestion 5 above.
6.3. Recommended Further Work
To meet the needs of applications such as those described in section
2.1, the community must seek where possible to adapt and enhance
existing tools, not to build new ones. There is now an opportunity
for RARE to stimulate and encourage this process of adaptation and
enhancement, and the following subsections outline a strategy for
Selecting a System
In order to have the greatest effect, RARE should concentrate its
efforts on only one of the existing tools. Candidate technologies
are those already outlined: Gopher, WWW, WAIS, Hyper-G, Microcosm and
It is recommended that RARE should select the World-Wide Web to
concentrate its efforts on. The reasons for this decision are as
o Flexibility. The rich yet straightforward design of WWW,
with its clearly separable components (HTML, URL and HTTP),
means that it is a very flexible basis on which to develop
distributed multimedia applications.
o Existing efforts. The WWW implementor community is already
discussing and designing extensions to HTML (HTML2),
intended (among other things) to support multimedia. There
is clearly much interest in this area, and RARE efforts
could complement existing work.
o Hyperlinks. A clear requirement of many applications is the
availability of hyperlinking, which WWW supports well.
o Integrated solution. Because WAIS, Gopher and Hyper-G (as
well as anonymous FTP servers) may all be accessed from Web
clients, WWW serves as an important integrating tool for
information services. It is important that distributed
multimedia applications, which require extensive support in
the client software, should be based on a technology "close
to" such integrated clients.
o Penetration and growth. Although Gopher far surpasses WWW
in the number of servers available, the rate of growth in
WWW usage is greater than that of Gopher. There is an
increasing realisation in the community that Gopher is over-
simplistic for many purposes, and a corresponding increase
in interest in WWW.
o Attention to QOS issues. There is already an awareness in
the WWW community of the need for achieving an appropriate
QOS, and a mechanism has already been proposed in HTTP2 to
alleviate the problem.
o Standardisation. The WWW team is taking standardisation of
the existing WWW system components seriously. The URL
format has already been published as an Internet draft (and
has been adopted as an important component of the proposed
Internet integrated information infrastructure), and the
current version of HTML is about to follow suit. The use of
SGML as the basis of HTML complies with the perceived
importance of SGML for hypermedia in general (and also fits
in with RARE's approach of adopting appropriate open
o Software status. CERN has recently placed the WWW code
developed by it into the public domain. This is unlike all
the other candidate technologies, which all have
restrictions on who can do what with the code. In the case
of Gopher, these restrictions are already causing some
commercial users to look at other options.
WWW has two significant disadvantages, both of which are being
o Restricted choice of client software. At present, Apple
Macintosh and PC/MS Windows clients are available in beta
form only. By contrast, there are more than one well-tested
Gopher clients available for these platforms.
However, other WWW clients for the Mac and MS Windows are in
o There is a perception in the community that making
information available over HTTP is difficult, and that it
must be put into HTML.
However, it is possible to put plain-text, non-HTML
documents onto the Web. Such documents of course cannot
Furthermore, WYSIWYG HTML text editors are available, to
ease the pain of writing HTML.
The main disadvantages of the other systems are:
o Gopher is designed for simplicity, and therefore lacks the
flexibility of WWW. In particular its structure is too
inflexibly hierarchical and it does not have hyperlinks.
Its main advantage is its very heavy penetration. However,
because of the WWW approach to accessing data using other
protocols, all of gopherspace is part of the Web. Any Web
client should be able to be a gopher client too.
It is neither envisaged that Gopher will go away, nor that
it won't be used for multimedia data. However, Gopher is
unlikely to be used for more sophisticated multimedia
applications such as academic publishing, interactive
multimedia databases and CAL, because of the above-mentioned
o WAIS is a specialised tool, and will certainly form part of
the overall solution, particularly for database-type
applications. It is not a general solution for distributed
o AthenaMuse 2 is commercially-oriented: it is clear that
academic and research users will have to pay to use the
software. Its level of use is thus very unlikely to be as
great as publiclyavailable systems such as WWW. Moreover,
it does not support all the required platforms.
o Microcosm network support is still in early stages, limited
at present to the PC/Windows platform. If it can be shown
to perform adequately over a network, if it is capable of
scaling to global levels, and if the advantages of
maintaining link information separately from documents are
found clearly to outweigh the consequent difficulties, it
may become important in the future. Microcosm's authors need
to ensure that the commercialisation of Microcosm does not
hinder its adoption by the academic community.
o Hyper-G is more difficult to dismiss. It is still in a
relatively early stage of development, but appears to have
many of the necessary features. Its main disadvantages are:
(a) the lack of penetration outside the University of Graz -
the author is aware of only one other site using it; and (b)
it is currently limited to UNIX only. The author believes
that, given WWW's head start in terms of deployment, and the
current progress in adding multimedia facilities to it, WWW
stands a much better chance than Hyper-G of being accepted
as the de facto standard for distributed multimedia
applications on the Internet.
Directions for RARE
Earlier in this report, it was noted that the most important areas
where effort was needed were (a) provision of facilities for the
integrated presentation of multimedia data (including synchronisation
issues); and (b) ensuring adequate responsiveness.
Bearing this in mind, it is recommended that RARE should invite
proposals and (subject to funding being available) subsequently
commission work to:
1. Develop conversion tools from commercial authoring packages
to WWW, and establish authoring guidelines for authors who
wish to use the conversion tools. This is a significant and
high-profile development aimed at enabling sophisticated
multimedia applications to run over the network. (Authoring
guidelines will be necessary to enable authors to fit in
with the Web's way of doing things, and to document features
of the authoring package which should be avoided because of
2. Implement and evaluate the most promising ways of overcoming
the QOS problem. This is an essential task without which
interactive distributed multimedia applications cannot
become a reality. Some possibilities have already been
outlined in the preceding chapter.
3. Implement a specific user project using these tools, in
order to validate that the facilities being developed are
truly relevant to actual user requirements. It may be that
partner funding from the selected user project would be
4. Use the experience gained from 1, 2 and 3 to inform and
influence the further development of HTML2 and HTTP2 to
ensure that they provide the required facilities.
5. Contribute to the development of the WWW clients
(particularly the Apple Macintosh and PC/MS Windows clients)
in terms of their multimedia data handling facilities.
Although it is strictly speaking outside the remit of this report
(since it is not specifically concerned with multimedia data), it is
noted that the rapid growth of WWW may in the future lead to problems
through the implementation of multiple, uncoordinated and mutually
incompatible add-on features. To guard against this trend, it may be
appropriate for RARE, in coordination with CERN and other interested
parties such as NCSA, to:
6. Encourage the formation of a consortium to coordinate WWW
technical development (protocol enhancements, etc).
 "Emerging Hypermedia Standards" B. Markey, Multimedia
for Now and the Future (Usenix Conference
Proceedings), June 1991.
 "Initial Draft PREMO (Presentation Environment for
Multimedia Objects", ISO/IEC JTC1/SC24 N847, November
 "Recommended Practices for Multimedia Portability",
Release 1.1 October 1990, Interactive Multimedia
Association, 3 Church Circle, Suite 800, Annapolis,
MD 21401-1993, USA.
 "Recommended Practices for Enhancing Digital Audio
Compatability in Multimedia Systems", Release 3.00
1992, Interactive Multimedia Association, 3 Church
Circle, Suite 800, Annapolis, MD 21401-1993, USA.
 "RIFF Tagged File Format", Microsoft Inc, 1992.
 "A Vision of an Integrated Internet Information
Service", C. Weider and P. Deutsch, March 1993,
Work in Progress.
 "Delivering Interactive Multimedia Documents over
Networks", S. Loeb, IEEE Communications Magazine, May
 "A Status Report on Networked Information Retrieval:
Tools and Groups", ed. J. Foster, G. Brett and P.
Deutsch, March 1993.
8. Security Considerations
Security issues are not discussed in this memo.
9. Author's Address
Edinburgh University Computing Service
Edinburgh EH8 9LJ
Phone: +44 31 650 3363
Fax: +44 31 662 4809