Re: Library Standards and URIs

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


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
Cc: uri@bunyip.com

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