# Re: Library Standards and URIs

Dirk Herr-Hoyman (hoymand@gate.net)
Sat, 7 Jan 1995 08:41:37 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Tom Sears: "URLs and a private scheme type"
- Previous message: Larry Masinter: "Third (and final?) revision, URI minutes December 1994 IETF"
- Maybe in reply to: weibel@oclc.org: "Library Standards and URIs"
- Next in thread: Dirk Herr-Hoyman: "Re: Library Standards and URIs"

    Date: Sat, 7 Jan 1995 08:41:37 -0500

    Message-Id: <ab34aa0803021004fe47@[199.227.1.88]>

    To: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>, winograd@cs.stanford.edu

    From: hoymand@gate.net (Dirk Herr-Hoyman)

    Subject: Re: Library Standards and URIs

At 4:47 PM 1/5/95, Ronald E. Daniel wrote:
>Terry Winograd sez:
>Right. To push this discussion along, here is a straw-man proposal.
>These files are DTD fragments, modeled along the lines of the TEI's DTD
>fragments that can be mixed, matched, and overridden by user-specified
>DTD fragments. They convey the syntax and are machine-readable. The
>semantics are conveyed in human-readable comments. People who put the
>fragments on the net without specifying the semantics get flamed :-)
>
>As the proposer of the strawman, I get to take the first couple of
>hits at it. First, this requires URI support in SGML applications, which
>may get true SGML people a little upset.

I don't see why this is an objection. HTML 2.0 is "true" SGML. The issue
of URI or any other hyperlinking reference is external to SGML per se.

> Second, it does nothing to solve
>the name collision problem (unless we use the SUBDOC stuff which I am
>told is deprecated).

And/or semantics collision. What about all the different ways to compose
an Author? SGML does not really have a good structure to handle, which
several have already pointed out.

At this point, I still like SGML, even if we convolute it this way. This
is a text database, after all. Another possibility might be in HyTime,
which is an object-oriented method for specifying hyperlinks and is meant
to be used with SGML. I'm not entirely up on HyTime, but from the little I
know, it would provide the kind of extensible framework, in terms of
classes and inheritance, or using the HyTime language, architectural forms,
that Terry and Ronald have discussed.

And in the spirit of brainstorming, I'll pass along this new proposal:

--- cut here ---
The following is a brief overview of the proposed Standard Multimedia
Scripting Language (SMSL). Participation in the ANSI X3V1 Task Group
that will refine this proposal is invited! If you are interested,
please contact me.

Ralph E. Ferris
Project Manager, Electronic Publications
Fujitsu Open Systems Solutions, Inc. (FOSSI), Engineering Services
Phone: (408) 456-7806 Fax: (408) 456-7050
E-mail: ralph@ossi.com

A Davenport Group sponsor. For information on the Davenport
Group see ftp://ftp.ora.com/pub/davenport/README.html
or http://www.ora.com/davenport/README.html

**********************************************************************

Brief Overview of the Proposed Standard Multimedia Scripting Language

1. Introduction

The Standard Multimedia Scripting Language (SMSL) is an open
scripting environment primarily targeted toward SGML/HyTime
applications. SMSL does not describe a single standardized
scripting language, rather it describes the interfaces
required to bring new and existing languages into the
SGML/HyTime arena. The initial proposal for SMSL was
developed by Brian Markey of Permanent Wave Productions.
Brian will present a full draft of the proposal at the
meeting of ISO SC18/WG8, Document Description and Processing
Languages, in February. Refinement of the draft proposal
will be carried out by a Task Group of the ANSI X3V1
committee, the National Body that represents the U.S. in ISO
SC18/WG8.

2. Description

The basic characteristics of the proposed SMSL standard are:

o SMSL documents are created by adding SMSL architectural
forms to HyTime documents.

o SMSL will use architectural forms to define object
classes from which element types can be derived. These
classes could also be used to derive supporting
constructs, for example, C++ header files.

o For a given object class, default methods are defined
as part of SMSL services; additional methods can be
added, or existing methods can be overload. (This
approach differs from the HyTime standard, which does
not define methods as part of its architectural forms.)
Note that the default "methods", which correspond to
required SMSL services, only apply to classes which are
derived from classes specified in the standard.
Examples include "multimedia classes" and "user
interface" classes. SMSL supports all of the criteria
for object-oriented languages, such as encapsulation,
inheritance (including multiple inheritance), and
polymorphism.

o Methods can be added or overloaded through the addition
of scripts to a HyTime document. The content of the
scripts could be in any defined notation, such as C++
or other programming language source code. The content
of the scripts could even be binary code compiled for a
given platform (although this approach is depreciated
since its use runs counter to the application
portability that SMSL is intended to support).

+o When the SMSL scripts are compiled and linked, the
governing application invokes the proper processor on
the script content, as identified by the notation
specified for that content.

o The output could be compiled files and an SGML ESIS
file. In that case the combination of executables and
SGML data files is the application.

o Alternatively, instead of outputting binary code and an
ESIS file, other approaches, such as creating an
application that would be interpreted at runtime, could
be used.

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

o 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.

o The SMSL services will rely on the operating system
services to support the display of dialog boxes, as
well as audio and video playback and any other system
dependent services required by the application.

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

An overview of the SMSL application environment is provided
in the following figure:

_____________________________________
| |
| SMSL Documents |
| |
| _____________ ________________ |
| | Scripts | | HyTime | |
| | | | Documents | |
| |____________| |______________| |
| ^ ^ |
| | | |
|______|___________________|_________|
| |
| |
V V
____________ ________________________________
| User | | SMSL Services |
| Interface|<--->| |
|__________| |______________________________|
^
|
|
V
___________________________
| |
| OS Services |
| - Dialog Box |
| - Audio Playback |
| - Video Playback |
| - Other |
|_________________________|

Standard Multimedia Scripting Language (SMSL)
Application Environment

- Next message: Tom Sears: "URLs and a private scheme type"
- Previous message: Larry Masinter: "Third (and final?) revision, URI minutes December 1994 IETF"
- Maybe in reply to: weibel@oclc.org: "Library Standards and URIs"
- Next in thread: Dirk Herr-Hoyman: "Re: Library Standards and URIs"