ISO/IEC JTC1/SC18/WG8 **N1802**

# ISO/IEC JTC1/SC18/WG8 Document Processing and Related Communication--- Document Description and Processing Languages {#isoiec-jtc1sc18wg8-document-processing-and-related-communication-document-description-and-processing-languages .Heading-0-(nobreak)}

  -------------------- --------------------------------------------------
  **Title:**           Standard Hypermedia/ Multimedia Scripting Language
                       (SMSL) ISO/IEC CD 13240

  **Source:**          Brian Markey

  **Project:**         JTC1.18.43

  **Project editor:**  Brian Markey

  **Status of          CD Text
  document:**          

  **Requested          For CD processing by ISO/IEC JTC1/SC18
  action:**            

  **Date**             11 July 1995

  **Distribution:**    WG8 and liaisons

  **References:**      

  **Supersedes:**      
  -------------------- --------------------------------------------------

ISO/IEC

13240

Information Technology  Standard Hypermedia/ Multimedia Scripting
Language (SMSL)

Reference Number

ISO/IEC CD 13240

Contents

**1 Scope**

2 Normative References

3 Definitions

4 Relationship Between SGML, HyTime and SMSL

4.1 HyTime Location Addressing Module

4.2 HyTime Measurement Module

4.3 SMSL Parameter Entity

5 SMSL Application Model

5.1 Object-Oriented Model

5.1.1 Encapsulation

5.1.2 Inheritance

5.1.3 Composition

5.1.4 Polymorphism

5.1.5 Virtual Functions

5.2 Message Passing Model

5.3 Multimedia Authoring Paradigms

5.4 User Interface Paradigm

5.5 Authoring-time Environment

5.6 Run-time Environment

7 Classes

7.1 The Class Architectural Form

7.2 Memfunc Architectural Form

7.3 Memdata Architectural Form

7.4 Virtual Functions

8 Collections

8.1 The Collection Architectural Form

9 Object Identifiers

9.1 The objectid Architectural Form

10 Messages

10.1 The message Architectural Form

10.2 The Message Routing Service

12 SMSL Predefined Classes

12.1 User Interface Classes

13 SMSL Services

13.1 ObjectConstruct

Purpose

Use

Input

Output

13.2 ObjectDestroy

Purpose

Use

Input

Output

13.3 SendMessage

Purpose

Use

Input

Output

Annex A: IDL Notation for composing collections

Annex B: Using C++ as a Scripting Language

Annex C: The SMSL Meta-DTD

0 Introduction

The traditional view of computer processing holds that a program and the
data it processes are physically and logically separate. This appears to
be a natural division as clearly, one should not have to modify a
program to process new data. The problem with this theory is that most
applications require the data (information) to be structured in a
particular way before the program may process it. One program\'s
definition of the data structures is often at odds with another. Data
must be converted from one format to another, often with some associated
loss of information. If the structure of data changes, programs must be
modified.

The solution is to make data self-describing. A requisite step in this
process is separating the data (content) from the structure of the data.
ISO/IEC 8879: Standard Generalized Markup Language (SGML) and ISO/IEC
10744: Hypermedia/Time-based Structuring Language (HyTime) provide a
mechanism for describing structure without affecting content. This
description is known as a Document Type Definition (DTD). To apply
object-oriented terminology to SGML, the DTD defines a class of
documents and each document is an instance of a class.

While structure may be defined in a standardized manner, the semantics
are application defined. This has led to much misunderstanding; how can
a standard be useful if there are no semantics attached to it? The
answer becomes clear when one realizes the benefits of self-describing
information. In this scenario, the structure of the information drives
the application; not the other way around. The imposition of semantics
would subvert this model.

The emphasis of the Standard Hypermedia/Multimedia Scripting Language
(SMSL) is on information, not programming. SMSL is not a programming
language; rather, it standardized interface between programs (which may
be written in any number of languages) and SGML documents.

# 1 Scope

This International Standard defines an environment for authoring and
running hypermedia applications. An application is comprised of a
program (an executable entity), data, and structure.

In SMSL, the program is represented as a series of scripts, which are
written in a special language known as a Scripting Language.

A Scripting Language is a Programming Language, however, not all
Programming Languages are Scripting Languages. More precisely, the set
of Scripting Languages is a subset of the set of Programming Languages.
The attributes which differentiate the Scripting Language subset are
subtle, and often have more to do with perception than with any clear
technical distinctions.

However, Scripting Languages often display one or more of the following
characteristics:

language syntax and grammar resemble natural (spoken) languages

language is usable by people who are not professional programmers

language design stresses simplicity over functionality

language is \"application focused\", in that it is intended to address
the needs of one class of application (language is not \"general
purpose\")

The programs written in a Scripting Language are called \"Scripts\".

Scripting languages are most frequently applied to tasks where the
required scripts are relatively simple, as well as somewhat repetitive;
for example, application installation. The creation and modification of
the script is often hidden from the user. For instance, a terminal
emulator may support logon scripts, but the creation of the scripts
might be managed by a menu-driven front end.

The Standard Multimedia/Hypermedia Scripting Language (SMSL), as its
name implies, is designed for manipulating multimedia information. Any
information that can be stored in a computer system and manipulated
under software control qualifies as multimedia information.

In this standard, the data, scripts and structural information are
organized into a single identifiable unit known as a document. The term
document has the same meaning in this context as in SGML (ISO 8879) and
HyTime (ISO/IEC 10744).

# 2 Normative References

ISO/IEC 10744: 1992 Information Processing --- Text and office systems
--- Hypermedia/Time-based Structuring Language (HyTime)

ISO 8879:1986 Information Processing --- Text and office systems ---
Standard Generalized Markup Language (SGML)

ISO DIS 13522-1 Information Technology --- Coding of Multimedia and
Hypermedia Information

ISO DIS 10179 Document Style Semantics and Specification Language
(DSSSL)

# 3 Definitions

  --------------------- ------------------------------------------------------
  **architectural       (use ISO/IEC 10744 definition)
  form**                

  **attribute**         (use ISO 8879 definition)

  **authoring**         The process of creating multimedia applications.

  **authoring system**  The software and hardware associated with the creation
                        and testing of scripted applications.

  **authoring time**    When a scripted application is created and tested.

  **class**             A set of objects that share a common structure and a
                        common behavior.

  **collection**        A simple or compound data structure, constructed using
                        the rules of SGML.

  **construct**         To create a run-time instance of an object, including
                        the allocation of memory and other system resources
                        required by the object.

  **destruct**          To destroy a run-time instance of an object, including
                        the deallocation of all resources used by the object.

  **document**          A collection of information that is identified as a
                        unit and that is intended for human perception; in
                        SMSL, the document encapsulates data, structure and
                        scripts.

  **element**           (use ISO 8879 definition)

  **entity**            (use ISO 8879 definition)

  **HyTime**            ISO/IEC 10744:1992 The Hypermedia/Time-based
                        Structuring Language.

  **member data**       The data encapsulated within a class.

  **member function**   The methods, or functions, encapsulated within a
                        class.

  **message**           Information communicated between objects.

  **message handler**   A method that handles a particular message type.

  **message map**       A data structure which maps message type to message
                        handler for a class.

  **object**            An instance of a class. An object has state, behavior
                        and identity.

  **object-oriented**   A design based upon the object module which
                        encompasses the principles of abstraction,
                        encapsulation, modularity, hierarchy, typing,
                        concurrency, and persistence.

  **run-time**          When a scripted application is run; usually by the
                        application's target user.

  **scripting           A programming language used with SMSL applications.
  language**            

  **semaphore**         A shared resource used to implement mutual exclusion
                        algorithms.

  **SGML**              ISO 8879:1986 The Standard Generalized Markup Language

  **Superclass**        The class from which another class is derived; the
                        parent class.
  --------------------- ------------------------------------------------------

# 4 Relationship Between SGML, HyTime and SMSL

## 4.1 HyTime Location Addressing Module

This section is about the interface between SMSL and the HyTime
hyperlink module.

1.  Creating objects which correspond to anchors so that events
    automatically occur relative to a link.

## 4.2 HyTime Measurement Module

This section is about the interface between SMSL and the FCS module.

1.  Define the sequencing of events in a "timeline-based" authoring
    paradigm

2.  Define virtual coordinate spaces for displays

## 4.3 SMSL Parameter Entity

# 5 SMSL Application Model

SMSL is a standardized scripting environment.

An application is comprised of three components: data, structure, and
methods.

An SMSL application is synonymous with a document, in that the document
"contains" (or encapsulates) the three essential application components.

SMSL is intended to support \"self-contained\" applications, in which
case, most of the processing associated with the application is embedded
in the scripts.

Any number of languages may be used as a scripting language with SMSL.

Scripts interact with documents via SMSL services.

There are no media restriction in SMSL, the application can reside on
any number and combination of media including CD-ROM, local disk and
network server disk.

The application is intended to be as platform-independent as possible
and SMSL provides the mechanisms for achieving almost universal
portability. However, the application designer and/or SMSL implementor
may choose not to support full portability for a variety of reasons
(security, economics, etc.) and SMSL does not discourage them from doing
so.

![](media/image1.emf){width="3.58125in" height="3.4902777777777776in"}

**Figure 1 SMSL Application Architecture**

## 5.1 Object-Oriented Model

SMSL supports all of the criteria for object-oriented languages,
including: encapsulation, inheritance (including multiple inheritance),
polymorphism, containment and virtual functions.

Scripting languages used with SMSL do not have to be object-oriented
languages.

Using SMSL implies superimposing object-oriented design on an
application, even if the languages(s) used are not object-oriented.

The interface between SGML documents and applications (provided by SMSL)
is object-oriented.

### 5.1.1 Encapsulation

SMSL classes support encapsulation (also known as "data hiding").

### 5.1.2 Inheritance

SMSL classes support the inheritance relationship ("Is-a"). No limits
are placed upon the depth or breadth of the class hierarchy. SMSL
supports multiple inheritance; that is, a class may be derived from any
number of parent (base) classes. However, the inheritance graph must be
acyclic; a class cannot be derived from itself, either directly or
indirectly.

### 5.1.3 Composition

A class may contain other classes (the definition of the contained class
may be as simple as a primitive data type). For example, a class
corresponding to a dialog box can be built from other, more primitive
classes (button, text edit box, list box, etc.). There is no limit on
the depth or breadth of containment.

### 5.1.4 Polymorphism

Polymorphism is the ability to call a variety of functions using the
same interface.

SMSL supports polymorphism by allowing multiple implementations of a
method, providing that each instance either return a different data
type, that the order and type of arguments vary, or some combination of
the previous criteria.

### 5.1.5 Virtual Functions

SMSL supports virtual functions. Any class can over-ride the methods
inherited from classes from which it is derived.

An attribute on the message architectural form (clause 10.1) provides
the mechanism for distinguishing between the virtual function in a base
class, and one in a derived class; e.g if a method in a derived class
wishes to explicitly call a function in its base class.

## 5.2 Message Passing Model

Many modern software systems are based on a processing model where
objects receive messages (or commands) which control their processing.

Each message type handled by an object corresponds to one member
function of the class from which the object was instantiated.

The SMSL run-time environment serves as a kernel through which all
application messages are passed. The kernel manages the ordered message
queue.

Using the SendMessage service, an SMSL application can request that a
message be sent to an object. These messages are known as synchronous
events.

The kernel can, in some instances (such as mouse button events) send
messages to an object that were not specifically requested to be sent by
the application. These messages are known as asynchronous events.

The application or the kernel can request messages be sent to an object
either at a specific time, or at a time relative to another event. These
messages are known as isochronous events.

A message map establishes the relationship between a message and a
message identifier (messageID).

## 5.3 Multimedia Authoring Paradigms

SMSL does not constrain the authoring paradigms used by multimedia
applications.

## 5.4 User Interface Paradigm

Due to the fact that SMSL is intended for use in multimedia
applications, SMSL assumes, but does not require, a graphical user
interface. Graphical user interfaces share a number of common
characteristics, and SMSL exploits these characteristics through
"built-in" class libraries.

The SMSL services rely on the underlying operating system to support the
display of windows and dialog boxes, display of graphics, audio and
video playback, and other system dependent services required by the
application. The interfaces between the SMSL run-time environment and
the underlying operating system are not prescribed by SMSL.

## 5.5 Authoring-time Environment

The authoring-time environment provides the services required to author
an SMSL application.

## 5.6 Run-time Environment

The run-time environment provides the services an SMSL application needs
to run in its target (possibly "end user") environment.

6 Event Sequencing

SMSL provides a mechanism for producing a sequence of messages that are
sent to objects. This is a simple method of building an application from
a set of objects. It is assumed that most of the processing will be
performed by the methods associated with the objects, thus only the most
rudimentary operations are supported using event sequencing. Still, most
interactive multimedia applications could be implemented using this
mechanism. Event sequencing is based on HyTime Finite Coordinate Spaces
(FCS) and a variation of the HyLex and HyQ notations (see Annex A in
ISO/IEC 10744 for further information.)

A common application of the Event Sequencing facility would be to have
compiled scripts which implement the methods associated with a class of
objects, and to interpret the event sequence at run time to implement
the actual application.

# 7 Classes

A class is a set of objects that share a common structure and behavior.

Classes are declared in SMSL documents using the class architectural
form. New classes can be derived from existing classes which are either
implied by the element hierarchy of an SGML/HyTime document, or are
defined as part of this standard.

One of the useful characteristics of SMSL is that new class hierarchies
can be superimposed onto existing documents.

The content of a class is arbitrary, however two additional
architectural forms are available which correspond to the
object-oriented programming paradigm: the memfunc architectural form
which is used to declare the member functions of a class (also known as
methods), and the memdata architectural form which is used to declare
data members.

The organization and use of the class by the scripting languages is not
specified by SMSL. The class declaration may be used to derive any
combination of authoring and run-time information that the implementor
chooses. For example, if C or C++ is used as a scripting language, the
class declarations may be used to produce header files that can be
compiled along with the scripts.

SMSL provides limited support for dynamic classes; that is, classes
which can be declared and/or modified at run-time. Since SMSL classes
are declared within the context of an SGML document  and since parsing
the document may be part of the run-time processing required by the
application  the basic mechanism for dynamic class declaration is in
place. However, the ability to support dynamic classing is also a
function of the scripting language and implementation, and SMSL does not
require such support.

## 7.1 The Class Architectural Form

The class architectural form is used when declaring a new class. The
content of a class element is member function (script) elements, and
data member elements. If additional content is required then a new
element type, with the appropriate content model, should be derived from
class.

The super attribute is a list of superclass names from which the new
class is derived (i.e. a list of classes from which the new class will
inherit data and function members). The order the superclasses are
listed is not of significance to SMSL, although it may be significant to
the scripting language implementation. The elements referenced by the
super attribute must also specify the class architectural form.

A class is of ctype abstract if it cannot be directly instantiated; i.e.
only other classes may be derived from this class. A class is of ctype
normal (the default) if an instance of the class can be directly
constructed.

In some languages, other attributes may be appropriate. For example, in
C++, keywords such as virtual, public, private or protected are commonly
used in class declarations. If the scripting language used by an
application supports (or requires) additional keywords, they can be
declared as additional attribute types of the derived element type.

\<!element class - - (memfunc\|memdata\|class)+ \>

\<!attlist class

SMSL NAME #FIXED "class"

id ID #REQUIRED

super IDREFS \--rettype(class)\-- #IMPLIED

\-- default: no inherited class \--

ctype (normal, abstract) normal

\>

## 7.2 Memfunc Architectural Form

The memfunc architectural form declares a member function of a class.
The content of a memfunc element (or an element type derived from
script) is a script in a declared notation.

The funcname attribute names the function. In some languages, there may
be additional constraints placed upon the name. The only restrictions
SMSL places on the function name is that it be a generic identifier that
is unique to the class in which the function is declared.

The functype attribute names the notation that the script is written in.
The notation must be declared according to the rules of clause 11.

The message attribute, if provided, must have as its value an IDREF to a
message element. The message attribute indicates that the function acts
as a handler when messages of that type are sent to the object. This is
the primary mechanism for creating "virtual functions" in SMSL. Refer to
clause 7.4 for further information about virtual functions.

\<!element memfunc - O (#PCDATA) \--lextype(data-type-notation)\--\>

\<!attlist memfunc

SMSL NAME #FIXED "memfunc"

funcname NAME #REQUIRED

functype NOTATION #REQUIRED

collin IDREF \--rettype(collection)\-- #IMPLIED

\-- default: no input collection

collout IDREF \--rettype(collection)\-- #IMPLIED

\-- default: no output collection

message IDREF \--rettype(class)\-- #IMPLIED

\-- default: if none, private func.\--

\>

In addition to the other attributes listed above, an implementation may
add its own attribute types to a class derived from memfunc. For
example, when C++ is used as a scripting language, it may be useful to
create an access attribute that has as its possible values "protected",
"public" or "private".

## 7.3 Memdata Architectural Form

The memdata architectural form declares a data member of a class. Each
data member is a collection even if it is comprised of a single basic
data type.

The collection may be declared externally to the class, in which case
the ID of the collection is supplied when the data member is declared,
or the collection may be declared in place, in which case the content of
the memdata element declares the collection using the rules described in
clause 8.1.

The memname attribute specifies the name of the data member. The memname
is a generic identifier that must be unique to the class in which the
memdata element is defined.

The collname attribute specifies the ID of an collection. If the
collname attribute is used, the content of the memdata element must be
empty.

NOTE: Assume HyTime "context" attribute is used.

\<!element memdata - O (collection) \>

\<!attlist memdata

SMSL NAME #FIXED memdata

memname NAME #REQUIRED \-- data member name,

must be unique to

this class \--

collname IDREF #IMPLIED \-- collection name \--

\>

## 7.4 Virtual Functions

Virtual functions are implemented in SMSL by overloading message
handlers. This is accomplished by declaring a method in a derived class
that handles messages with the same message ID as a method in the parent
class(es). Unlike certain object-oriented languages (for example, C++),
the name of the method is not significant.

To explicitly call a method in a parent class, for which an overloaded
function exists, specify the parent's class name as an argument to the
message passing service.

The implementation is responsible for providing default message handlers
for each message type in the built-in classes that the implementation
supports.

## 7.5 Polymorphism

Polymorphism in SMSL is achieved by assigning each implementation for a
given method a unique collection-type attribute (refer to clause 8).

# 8 Collections

Collections are a method of describing and constructing data structures.
The purpose of collections are to avoid platform and/or
language-dependent data types. Collections may be expressed in any
number of notations. IDL, the SMSL reference notation, is described in
Annex A.

SMSL does not prescribe the run-time (binary) format of collections
since different behavior is required by different environments.
Ultimately, it is a compatibility issue for SMSL implementors. For
distributed environments, a platform-independent binary coding
mechanism, such as the Basic Encoding Rules (BER) of ISO 8825:1990 or
ONC/RPC, may be desirable. Thus, data could be passed between objects
which exist not only on different systems, but systems with different
operating systems and/or processors, with little consideration of data
format compatibility issues.

## 8.1 The Collection Architectural Form

The collection architectural form is used to construct collections
compatible with SMSL applications. The content model for the collection
architectural form is general. SMSL applications may derive new element
types based on the collection architectural form, which may further
constrain their content model.

SMSL provides predefined notation types for \[IDL and\...\], and
architectural forms which properly constrain the content model for the
notation in use.

\<!ELEMENT collection - - (%SMSL;)\*\>

\<!ATTLIST collection

SMSL NAME "collection"

id ID #REQUIRED

notation NOTATION #REQUIRED

\>

# 9 Object Identifiers

Object identifiers uniquely identify an object. The object identifier is
a run-time entity; its purpose is to address the object only during the
"life" of the object.

The format of the object identifier is left as an implementation
decision. In some implementations, the value of the object identifier
might be a handle. In others, the value of the object identifier might
be a pointer to the object's location in memory, or even a network
address.

It is possible for object identifiers to be reused if the implementation
so chooses, providing that at any point in time, an object identifier
maps to one and only one object.

The SMSL run-time environment is required to maintain a database of
object identifiers and object locations.

An object identifier results from invoking the SMSL ObjectConstruct
Service (clause 13.1).

## 9.1 The objectid Architectural Form

Used to declare an object identifier usable by the object instantiation
services.

\<!ELEMENT objectid - - (#PCDATA) \>

\<!ATTLIST objectid

SMSL NAME #FIXED "objectid"

id ID #REQUIRED

\>

# 10 Messages

Messages are passed between objects in SMSL applications under control
of the message routing service. There are two types of messages: SMSL
and Application. SMSL messages are defined by the standard. Application
messages are defined by the application.

## 10.1 The message Architectural Form

The message architectural form is used to define message types in SMSL
applications. Each message type is assigned a unique generic ID. The
content of a message element, or an element type derived from message,
is a string of letters and/or numbers that an SMSL implementation uses
to identify the message. It is assumed that these values will be unique
to each implementation of SMSL.

\<!ELEMENT message - - (#PCDATA) \>

\<!ATTLIST message

SMSL NAME #FIXED "message"

id ID #REQUIRED

\>

The unique identifier specified when a message element is declared is
used (in an IDREF) when member functions for a class are declared (refer
to clause 7.2). This provides a mapping between the message type and the
functions which handle that message for a particular class.

## 10.2 The Message Routing Service

The message routing service is used to pass messages between objects in
SMSL applications. The arguments to the message routing service are the
object ID of the object to receive the message, the message ID of the
message to be sent, a collection ID for the arguments passed to the
message handler function, and a second collection ID that will contain
the function results when the message handler returns.

**NOTE:** The mechanism for presenting the arguments to the message
routing service is left as an implementation detail.

11 Declaring Script Notations

SMSL is designed to work with any number of scripting languages. A
notation declaration (refer to ISO/IEC 8879:1986) is required for each
language in use. The following example notation declaration would allow
the LISP dialect known as *scheme* to be used as a scripting language in
SMSL applications.

\<!notation scheme PUBLIC

"+//ISBN 0-1802-1802-1::Programming Language//NOTATION

IEEE Scheme Specification//EN"\>

# 12 SMSL Predefined Classes

The classes described in this clause are all catalogued in the SMSL
meta-DTD.

The messages described in the clause are also catalogued in the SMSL
meta-DTD.

The data members are all described as collections using the SMSL
notation for IDL.

The methods described for each supported class must be implemented as
part of the SMSL services.

Classes are "modularized" (as in HyTime) so that an implementation has
some flexibility as to which classes it supports and which it does not.

## 12.1 User Interface Classes

User interaction will take place through a variety of user interface
objects, such as dialog boxes, movie players, sound players, text
editors, windows, and graphics interpreters.

# 13 SMSL Services

-   The SMSL services use an object (message passing) architecture.

## 13.1 ObjectConstruct

### Purpose

To create an instance of an object at run time.

### Use

Runtime

### Input

Location of root of element tree signifying the class to be
instantiated.

### Output

An object ID for the created class.

## 13.2 ObjectDestroy

### Purpose

To destroy an instance of a run-time object.

### Use

Runtime

### Input

Object ID: The object to be destroyed.

Depth: The depth to which contained objects are destroyed.

### Output

## 13.3 SendMessage

### Purpose

To send a message to an object.

### Use

Runtime

### Input

### Output

# Annex A: IDL Notation for composing collections

**(NORMATIVE)**

# Annex B: Using C++ as a Scripting Language

**(NORMATIVE)**

# Annex C: The SMSL Meta-DTD

**(NORMATIVE)**