RFC 1614
Network Access to Multimedia Information
Pages: 79
Informational
Informational
Part 3 of 3 – Pages 55 to 79
5. Standards 5.1. Structuring Standards This section describes some of the important standards for providing hyperstructure to multimedia data. SGML 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 example Microcosm. o SGML is used in some commercial hypermedia systems - for example DynaText. o SGML is of increasing importance for academic publishing houses. 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 files.
HyTime
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
purposes.
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
this report.
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
specification [18].
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
and lightyears!).
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
document content.
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 lrutledg@cs.ulowell.edu) 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 [19], which standardises the representation of certain kinds of navigational information - tables of contents, indexes and glossaries. 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 efficiency. An attempt has been made [20] 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 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
across ISDN.
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
objects.
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 [21] 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.
ODA
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
will support:
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
disbanded);
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
PREMO (Presentation Environment for Multimedia Objects) is a new work
item in ISO/IEC JTC1/SC24 (the graphics standards subcommittee). An
initial draft [22] 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. Acrobat 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 document. 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 systems. 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 [1] for further information). The protocols mentioned below are search/retrieve protocols which were not mentioned in [1]. 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 type. 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 standard. DFR 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 OSI. 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 MIME (Multipurpose Internet Mail Extensions) is a mechanism for transferring multimedia information in an RFC822 mail message. STD 11, 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 expressed. 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 these attributes. 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
markup for
representing
formatting.
image jpeg JPEG File Interchange
Format
gif Graphics Interchange
Format
audio basic 8-bit -law 8kHz PCM
encoding
video mpeg
application ODA profile Open Document
(used (Document Architecture
for Application document.
application Profile)
-specific
data)
octet- name (e.g., General binary data
stream filename); such as an arbitrary
type (for binary file.
human
recipient),
etc.
postscript Document in
postscript.
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 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 procedural scripting. AVIs 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" [23]
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" [24] 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
issues.
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
data.
A first reading of the Multimedia Data Exchange RFT reveals that the
Apple Bento standard [18] and the Microsoft/IBM RIFF format [25] 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
Media Framework).
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 the Internet. 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
systems.
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 section: 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 20s. 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 size. 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- fetching. 6. Cache information locally. The use of Universal Resource Numbers (see the section on WWW) is relevant for managing this.
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 [26] 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 [27]. 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
this.
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
AthenaMuse 2.
It is recommended that RARE should select the World-Wide Web to
concentrate its efforts on. The reasons for this decision are as
follows.
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
standards).
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
alleviated:
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
the pipeline.
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
contain links.
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
limitations.
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
hypermedia applications.
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
conversion difficulties.)
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
appropriate.
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).
7. References [1] "A Survey of Distributed Multimedia Research, Standards and Products", ed. C. Adie, January 1993 (RARE Technical Report 5). URL=ftp://ftp.ed.ac.uk/pub/mmsurvey/ [2] "The Dexter Hypertext Reference Model", F. Halasz and M. Schwartz, NIST Hypertext Standardisation Workshop, January 1990. [3] "Response Time and Display Rate in Human Performance with Computers", B. Shneiderman, Comp. Surveys 16, 1984. [4] "Gopher+: Proposed Enhancements to the Internet Gopher Protocol", B. Alberti, F. Anklesaria, P. Linder, M. McCahill, D. Torrey, Summer 1992. URL=gopher://boombox.micro.umn.edu:70/11/gopher/gop her_protocol/Gopher%2b [5] "WAIS Interface Protocol", F. Davies, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui and M. Grinbaum, April 1990. URL=ftp://quake.think.com/wais/doc/protspec.txt [6] "Uniform Resource Locators", T. Berners-Lee, March 1993. URL=ftp://info.cern.ch/pub/ietf/url4.ps [7] "The HTTP Protocol as Implemented in W3", T. Berners- Lee, January 1992. URL=ftp://info.cern.ch/pub/www/doc/http.txt [8] "Protocol for the Retrieval and Manipulation of Textual and Hypermedia Information", T. Berners-Lee, 1993. URL=ftp://info.cern.ch/pub/www/doc/httpspec.ps [9] "Hypertext Markup Language (HTML)", T Berners-Lee, March 1993. URL=ftp://info.cern.ch/pub/www/doc/html- spec.ps [10] "Hyper-G: A Universal Hypermedia System", F. Kappe and N. Sherbakov, March 1992. URL=ftp://iicm.tu- graz.ac.at/pub/HyperG/doc/report333.txt.Z
[11] "Towards an Integrated Information Environment with
Open Hypermedia Systems", H. Davis, W. Hall, I. Heath,
G. Hill, Proceedings of the ACM Conference on
Hypertext, Milan 1992, p181-190.
[12] "The AthenaMuse 2 Functional Specification", L.
Bolduc, J. Culbert T. Harada, J. Harward, E.
Schlusselberg, May 1992.
URL=ftp://ceci.mit.edu/pub/AM2/funcspec.txt.Z
[13] "Research and Technology Development in Advanced
Communications Technologies in Europe: RACE '92",
CEC, March 1992. Available from:
raco@postman.dg13.cec.be
[14] "Esprit Programme Synopses", CEC, October 1992. In
seven volumes. Available from
esprit_order_mailbox@eurokom.ie
[15] "CMIFed: A Presentation Environment for Portable
Hypermedia Documents", G. van Rossum, J. Jansen, K. S.
Mullender, D. C. A. Bulterman, Amsterdam 1993 (also
presented at ACM Multimedia 93 conference).
URL=ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9305.ps.Z
[16] "The Amsterdam Hypermedia Model: extending hypertext
to support real multimedia", L. Hardman, D. C. A.
Bulterman, G. van Rossum, Amsterdam 1993
URL=ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9306.ps.Z
[17] "Deja-Vu Distributed Hypermedia Application
Framework", A. Eliens.
URL=ftp://ftp.cs.vu.nl/eliens/Deja-Vu-proposal.ps
[18] "Bento Specification", J. Harris and I. Ruben, Apple
Computer Inc, August 1992.
URL=ftp://ftp.apple.com/apple/standards/Bento_1.0d4.1
[19] "Davenport Advisory Standard for Hypermedia (DASH),
Module I: Standard Open Formal Architecture for
Browsable Hypermedia Documents (SOFABED)", ed S. R.
Newcomb and V. T. Newcomb.
URL=ftp://sgml1.ex.ac.uk/davenport/sofabed.0.9.6.ps.Z
[20] Article in comp.text.sgml newsgroup, 24 May 1993, by
Eliot Kimber (drmacro@vnet.ibm.com).
URL=ftp://ftp.ifi.uio.no/SGML/comp.text.sgml/by.msg
id/19930524.152345.29@almaden.ibm.com
[21] "Emerging Hypermedia Standards" B. Markey, Multimedia
for Now and the Future (Usenix Conference
Proceedings), June 1991.
[22] "Initial Draft PREMO (Presentation Environment for
Multimedia Objects", ISO/IEC JTC1/SC24 N847, November
1992.
[23] "Recommended Practices for Multimedia Portability",
Release 1.1 October 1990, Interactive Multimedia
Association, 3 Church Circle, Suite 800, Annapolis,
MD 21401-1993, USA.
[24] "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.
[25] "RIFF Tagged File Format", Microsoft Inc, 1992.
[26] "A Vision of an Integrated Internet Information
Service", C. Weider and P. Deutsch, March 1993,
Work in Progress.
[27] "Delivering Interactive Multimedia Documents over
Networks", S. Loeb, IEEE Communications Magazine, May
1992.
[28] "A Status Report on Networked Information Retrieval:
Tools and Groups", ed. J. Foster, G. Brett and P.
Deutsch, March 1993.
URL=ftp://mailbase.ac.uk/pub/nir/nir.status.report
8. Security Considerations Security issues are not discussed in this memo. 9. Author's Address Chris Adie Edinburgh University Computing Service University Library George Square Edinburgh EH8 9LJ United Kingdom Phone: +44 31 650 3363 Fax: +44 31 662 4809 EMail: C.J.Adie@edinburgh.ac.uk