GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


archive:music:smdl-in.tro
                                                  February 15, 1988

{This document may be duplicated and distributed to others except as noted. To contribute a document and/or to obtain copies of other ANSI X3V1.8M Music Information Processing Standards Committee documents, contact: X3V1.8M Secretariat, c/o Craig R. Harris, The Computer Music Association, P.O. Box 1634, San Francisco, California 94101-1634 USA.}

                      X3V1.8M/SD-6
           Journal of Development, Part One:
          Standard Music Description Language
            -- Objectives and Methodology --

Editors: Charles F. Goldfarb

       IBM Research
       Steven R. Newcomb
       Florida State University

0. Introduction

        NOTE -- The Journal of Development is maintained
        in two parts only to facilitate maintenance by
        separate individuals; the two parts should always
        be read as a single document.  There is much in
        Part Two, for example, that may seem confusing or
        contentious if it is not read in the context esta-
        blished by Part One.
        NOTE -- This introduction appears in both parts of
        the Journal of Development.

0.1. Purpose of the Document

   The Journal of Development describes the status of the
   Standard Music Description Language (SMDL) being
   developed by ANSI X3V1.8M, the Music Information Pro-
   cessing Standards (MIPS) Committee.
        NOTE -- General information about the MIPS commit-
        tee, including a guide to participation, can be
        found in committee document X3V1.8M/SD-0.
   The Journal is in two parts:
   Part One describes the objectives of the project and
   the development methodology employed.
   Part Two describes the language design itself.
  1. 2 -

0.2. Development Methodology

   Both parts are revised by their respective editors
   after each meeting of the committee.  As a result, the
   documents never represent text that has been agreed in
   detail by the committee, but only the editors' best
   efforts to express the committee's ideas.  Moreover,
   the ideas in the journal are subject to further study
   and revision and do not represent a final design.
   Eventually, the design work will reach a point where
   all aspects of the language have been addressed,
   although not necessarily finalized.  At that point, the
   Journal of Development will cease to be the vehicle
   that expresses the current language design.  Instead,
   the committee will produce one or more successive
   "working drafts," consisting of text which represents
   the consensus of the committee.
   During the Journal of Development and working draft
   stages, public comment is sought and considered, but
   the process is informal.  Eventually, when the commit-
   tee is satisfied with a working draft, it will recom-
   mend that X3V1.8 process the document as a "draft pro-
   posal American National Standard."  There will then
   commence a formal public review and ballot, during
   which the contributor of each comment will receive a
   written reply.

0.3. Editorial Conventions

   Formal standards can be complex documents in which
   every word has both legal and technical significance.
   Standards documents may also need to be translated into
   other languages.  For these reasons, editorial conven-
   tions have been established to assure precision, accu-
   racy, and clarity (albeit often at the expense of rea-
   dability by the general public).  The key principles
   are:
   (1)  Precise and consistent definitions of terms.
   (2)  Distinguishing real requirements from mere commen-
        tary, explanations, and examples -- and from
        definitions.
   (3)  Avoidance of redundancy.  (Repetition of a
        requirement is normally a comment, to avoid the
        question of which text governs if the "repetition"
        is imperfect.)
   Part Two of the Journal of Development observes some of
   the editorial conventions of a formal standard, but not
   yet with the strictness and consistency that will be
   required in the final document.  (See annex B of Part
   Two for details.)
  1. 3 -

1. Requirements for a Standard Music Description Language

   (SMDL). The SMDL is being developed to meet the
   requirements described in this clause.

1.1 General Needs

1.1.1 Book Publishing

   Publishers need a way of representing musical examples
   within a document (e.g. a music textbook), so that no
   additional typesetting or formatting cost is incurred,
   and no paste-ups need be done when either the text or
   music portions of the document are edited.

1.1.2 Business Presentations

   Makers of computer-mediated business presentations need
   to integrate music into their productions, and their
   productions need to be portable.  Those who create
   business presentations, especially those who create
   business presentations of the kind that are now com-
   monly done with a PC and a video projector, want to
   incorporate music in such presentations, and they want
   to be in a position to have the music reformatted
   (i.e., rearranged) for different performing resources
   "on the fly."  The business of business presentations
   is a large one and it can be expected to generate con-
   siderable demand for computer music products, and, of
   course, for music itself.

1.1.3 Computer-assisted Instruction

   Computer assisted instruction which employs music as a
   reinforcer, or which actually teaches music, needs to
   be portable in order to maximize its marketability.
   The people who create the instruction need to be able
   to call upon databases of music written by other people
   who wrote or transcribed the music using perhaps incom-
   patible hardware and/or software systems.

1.1.4 Electronic Information Distribution

   Electronic distributors of information (via videotex,
   etc.) need to be able to include music as part of their
   product mix.

1.1.5 Music Creation and Distribution

   Composers, performers, and arrangers would be better
   able to exploit the market for their creativity, and
   their market would be better served and have a wider
   variety of product to choose from, given the existence
   of a lingua franca for music--a single representation
   which is able to encompass the kind of information
   which is available from printed music, as well as the
   kind of information (gesture, nuance) which performers
   add in any given performance.

1.1.6 Information Retrieval

  1. 4 -
   Librarians and information retrieval specialists need a
   standard representation of music data bases, including
   the ability to identify musical works by themes as well
   as conventional bibliographic data.

1.1.7 Musical Analysis and Criticism

   Musicologists, reviewers, editors, and critics require
   the ability to annotate and analyze musical works, and
   to record their analyses in a manner that provides com-
   plete flexibility in their choice of analytical tech-
   nique, as well as precision in indicating musical pas-
   sages and phenomena.

1.2 Specific Assumptions

   Within the above broad categorization of application
   needs, specific requirements have been identified.

1.2.1 User Interface

   It is expected that the primary means of creating and
   revising SMDL documents will be with specialized music
   editors.  However, it is also expected that direct
   access with "dumb" text editors will also be necessary,
   for example:
   1.   By programmers who are developing or maintaining
        the specialized music editors.
   2.   By users who have incorporated SMDL into larger
        documents for publication, and who must modify
        them in an environment where a music editor is not
        available.

1.2.2 Unique Representation

   The representation of a musical work must contain a
   "core" of information that can be encoded in a canoni-
   cal form such that unambiguous comparisons can be made
   between works.  In other words, there must be a defined
   portion of the representation that serves to distin-
   guish a work from all other works.
  • section 1 TO BE COMPLETED: *
  • Contributions are solicited! *

2. The Role of SGML in the SMDL

        NOTE -- The SMDL is intended to be an SGML
        representation of music information.  The nature
        of SGML is such that this objective does not res-
        trict the SMDL design in any practical way.  The
        purpose of this clause is to explain why that is
        so.

2.1 Background

  1. 5 -
   The Standard Generalized Markup Language (SGML) is an
   internationally standardized language for document
   description, published as International Standard ISO
   8879 : 1986.
   SGML has been adopted by a broad variety of organiza-
   tions for a diverse range of applications.
  1. - The Association of American Publishers has adopted

SGML for use by authors submitting manuscripts to

        publishers, and it has published applications of
        the language for journals, books, articles,
        mathematical formulae, and complex tables.
  1. - The U.S. Government, which is the world's largest

publisher, is a major user of SGML, and it is in

        the process of formally adopting it as a Federal
        Information Processing Standard.  Agencies using
        SGML range from the Internal Revenue Service,
        which uses it for tax form preparation, training
        manuals, and other publications, to the Defense
        Department.  The latter has adopted SGML as a
        standard for documentation in its Computer
        Assisted Logistical Support program, a project
        that could see the expenditure of over a billion
        dollars on SGML-based documentation support in the
        next three years alone.
  1. - The IBM Corporation, on whose Generalized Markup

Language (GML) the SGML is based, is the world's

        second largest publisher.  It uses GML for over
        90% of its publications.
  1. - The Oxford University Press is using SGML to

create an immense data base of the contents of the

        Oxford English Dictionary and its many supple-
        ments.  It will be the base for the publication of
        the New Oxford English Dictionary and many spe-
        cialized dictionaries, and it will eventually be
        available for online information retrieval.
   Implementations of SGML for IBM and Macintosh personal
   computers, DEC minicomputers, and IBM mainframes among
   others, are already available, and more are under
   development.

2.2 Document Representation with SGML

2.2.1 Structure

   SGML allows a document to be described as a hierarchy
   of logical elements.  For example, a "book" may be
   described as a sequence of "chapter" elements, each of
   which contains a "title" element followed by one or
   more "paragraph" elements.
  1. 6 -
   The title of a chapter might appear as:
            <title>How Dorothy Returned to Oz</title>
   and the first paragraph might appear as:
        <p>When Dorothy returned to her room, there was a
        tiny cameo lying on her dresser.  She picked it
        up, and it began to glow, while the tiny face on
        it seemed to come to life.</p>
   While this example may seem trivial, it illustrates the
   beauty of SGML: an SGML document need not contain any
   formatting instructions, but all the information about
   the document needed to format it automatically (by
   means of an application designed to do that) can be
   placed within the document itself.  Having created a
   document expressed in SGML, the author or editor can
   instruct a formatting program that, for example, all
   chapter titles are to be centered on new pages, one
   third of a page down, followed by a specified amount of
   blank space.  Thus, if the document is reprinted in a
   journal or anthology with different formatting conven-
   tions, no one needs to edit the document itself,
   because a formatter can reformat it according to the
   desired publishing style. SGML documents can contain
   normal text characters, graphics, images, mathematical
   formulae, and other specialized notations.
   In the above example, the structure of this instance of
   a book (a very short one!) was:
           <book>
                   <chapter>
                           <title>
                                   data ...
                           <para>
                                   data ...
   where "data" was those characters other than the markup
   tags -- the "real" text of the document.

2.2.2 Data Content Notations

   In our book, the data was a string of normal English
   characters interpreted in the usual way.  But consider
   the following data:
                       three over four
   This example could also be normal English text, but in
   a different context it could be interpreted as the
   equivalent of:
  1. 7 -
                             3/4
   The interpretation of data characters in a specialized
   manner like that described is called a "data content
   notation."  Data content notations are frequently used
   in SGML documents to describe the content of elements
   such as mathematical formulas and pictures.
   However, the example could also have been represented
   as an SGML structure that did not require a data con-
   tent notation:
              <fraction><numer>3<denom>4</fraction>
   Here, "fraction" is an element (like "title" or "p");
   it contains a numerator ("numer") and a denominator
   ("denom").  In other words, the structure is:
           <fraction>
                   <numer>
                           data ...
                   <denom>
                           data ...
   And, just as in our book, the data need no special
   interpretation -- the formatting of "fraction" is what
   specifies that the "numer" should be displayed above
   the "denom".
   The coding schemes conventionally used for musical
   scores are essentially data content notations.  In
   them, for example, the letters "a" through "g" might
   stand for notes of a particular pitch, while the digits
   "4" and "8" might represent durations.
   By using such a notation, an SGML document like our
   book could contain a "song" element within (say) a
   chapter:
      <book><chapter><title>Some Obscure Songs</title>
         <para>Here is a really obscure song:</para>
         <song notation="DARMTRAN">4EDCDEEER</song>
   Here, the "notation" attribute on the tag that intro-
   duces the "song" element tells us that the data content
   of the element is interpretable by the "DARMTRAN" nota-
   tion.  The formatting program could call a "DARMTRAN"
   processor for that element in order to obtain the
   typeset music.

2.2.3 Cross-references

   Elements can have other attributes besides "notation."
  1. 8 -
   One such attribute, called an "ID", allows a name to be
   assigned to an individual element.  Relationships
   between other elements and that one can be expressed
   with an "IDREF" (ID reference) attribute whose value is
   the ID of that one.  In the following example, a para-
   graph contains a "songref" (song reference) element
   that refers to the song whose ID is "song1":
   <para>I am referring to <songref idref="song1"></songref>
           when I speak of true obscurity.</para>
   <song id="song1" notation="DARMTRAN" >T"Obscure Song"CDEFEDC</song>
   The "songref" element has no data of its own; presum-
   ably the formatting application will generate an
   automatic reference based on material that is decoded
   by the data content notation processor.  (There seems
   to be a title hidden in there, but only a DARMTRAN pro-
   cessor would know for sure!)
   An alternative technique might be to define "song" ele-
   ments as containing a "title" and a "body", with only
   the body being in the data content notation:
           <song id="song1"><title>Obscure Song</title>
         <body notation="DARMTRAN">CDEFEDC</body></song>
   Now the formatting application can be smart enough on
   its own (without the DARMTRAN processor) to extract the
   content of the "title" element of the song and use it
   to generate data for the "songref" element!

2.2.4 Data Content Notation Encoding

   The data content notations in our examples were both
   character coded.  An advantage of a character coded
   notation is that it can be typed at a non-graphics ter-
   minal and printed in the form of a listing by non-
   graphics printers.  This can be particularly helpful to
   programmers who write the friendly "front-ends" and
   applications that create and process SMDL documents.
   However, SGML documents also have the ability to con-
   tain binary data content notations, e.g., photographs.
   To a software developer, this may appear, at first
   blush, to be the most appropriate for music representa-
   tion.  However, the distinction between the SMDL and a
   representation that is internal to an application
   should always be kept in mind.  The SMDL representation
   will be for the purpose of allowing applications with
   DISSIMILAR internal representations to communicate with
   one another.  A binary encoded notation will not neces-
   sarily be more convenient for a given application to
   handle than a character coded one.

2.3 An SGML Design Tradeoff

  1. 9 -
   There is obviously a tradeoff that must be made here
   when designing an SGML application.  A data content
   notation, because it is designed specifically to
   describe a certain kind of information, will likely
   require fewer characters to express the same thing as a
   general-purpose description language like SGML.  (To
   avoid any misapprehension that SGML is unacceptably
   verbose, it should be noted that SGML has "markup
   minimization" features that, if used, would have sub-
   stantially reduced the amount of markup in the previous
   examples.)
   On the other hand, the more detail about an element
   that is exposed at the SGML level, the greater the pos-
   sibility of interaction with other parts of the docu-
   ment (such as cross-references).  Another benefit of
   maximizing the use of SGML structure is that any tex-
   tual information in the music could be handled in the
   same way as any other text, and there would be the
   least likelihood of conflict between the formatting
   conventions for the text outside the music portion of a
   document and the formatting conventions for the text
   and music inside the music portion.
   A document expressed in SGML may be visualized as a
   tree, in which only the leaves contain data.  The
   flatter the tree structure, the more likely that a
   notation will be required to interpret that data.  But
   whether the tree has one level or one hundred, it is
   still an SGML document.
   In creating SMDL as an application of SGML, therefore,
   a range of possibilities present themselves:
   1.   The bare minimum of SGML structure could be used:
              <symphony notation="SMDL">GGGEb</symphony>
   2.   SGML structure could be used for some levels, but
        not for all of them.  For example, SGML could be
        used for the few highest level elements of the
        tree where it might be useful to have cross-
        references, etc., and where there is little effi-
        ciency to be lost because there are so few
        instances of them:
        <symphony>
        <movement id="first" notation="SMDL">GG</movement>
        <movement id="second" notation="SMDL">GEb</movement>
        </symphony>
   3.   SGML structure could be used right down to the
        leaves.
  1. 10 -
   The choice between the above alternatives cannot be
   made with certainty until the full set of information
   to be represented in SMDL has been identified.  The
   final language will almost certainly be some mix of
   SGML and a data content notation, but some difficult
   design work will be needed to implement it.  For one
   thing, we will have to design (or adapt) a data content
   notation.
   In the interim, we can easily express the set of infor-
   mation to be represented by using alternative #3, as it
   does not require us to invent a notation at this time.
   Once the full set of information is defined, we can
   devise a coding scheme (data content notation) for the
   leaves and appropriate levels of node, and leave the
   remainder to be represented with SGML markup.

3. Design Philosophy

   This clause describes the principles that are observed
   in formulating the SMDL design.

3.1 Role of a Description Language

   A description language (such as SMDL) is a method of
   expressing certain material that falls within a range
   that the language designers specify.  A description
   language does not make any demands on the material
   other than that it be within its range, nor is there
   any dynamic aspect to a description language.
   English can be used to illustrate the concept of the
   range of a language.  English is a language that is
   ideally suited for writing material such as this docu-
   ment.  English also lends itself beautifully to poetry.
   Mathematics, on the other hand, can only poorly be
   expressed in English (calculus and algebra are far
   better), and music cannot usefully be represented at
   all.  Clearly, some material is within the range
   addressed by English, and some is not.  English imposes
   a certain structure (grammar, vocabulary, spelling,
   etc.) on its range of subject material, but does not
   restrain the content.

3.2 Terminology

   The terms for SMDL constructs are chosen with care, but
   some may be different from conventional music terminol-
   ogy, in the following ways:
   1.   The term may be used in a more restricted (or more
        general) sense in the Standard than in common
        music parlance.
   2.   The term may refer to an SMDL language construct
        that corresponds to, but is not identical to, a
        construct in music.
  1. 11 -
   3.   The term may refer to a construct from another
        discipline that is here being applied to music.
        The term "thread," for example, refers to a con-
        cept which does not have a counterpart in conven-
        tional music terminology, but it is a metaphor
        like the one used when speaking of the "thread" of
        a story line or argument.
   The terminology, like everything else in SMDL, is sub-
   ject to review and revision, but for now we need "han-
   dles" for various concepts, and these are workable.

3.3 Efficiency

   It is intended that SMDL be able to express the bulk of
   the material it is intended to represent in an elegant
   and straightforward manner, with some thought given to
   efficiency as well.
   However, efficiency with respect to potential modifica-
   tion is much less a concern, since any given instance
   of a musical piece is static.  The only criterion is
   whether the versions existing both before and after the
   change can be expressed correctly.
   Dynamic efficiency is more the concern of designers of
   the internal representations used by application
   software that will read and create SMDL documents.  (It
   is especially easy for those of us who are software
   developers to fall into the trap of thinking like pro-
   grammers rather than language designers.)

3.4 Redundancy and Consistency

   Our general approach is to avoid the possibility of
   conflicting information in an SMDL document, which is
   tantamount to avoiding redundancy.  While it is recog-
   nized that internal redundancy can serve as a vehicle
   for error-checking, our belief is that it is the
   responsibility of the originator of an SMDL document to
   assure that it is error-free and conforms to the stan-
   dard.  A non-redundant design assures that the document
   is internally consistent, and therefore processable,
   even if it does not correctly express the intention of
   the originator.

3.5 Economy of Constructs

   We intend that the final language design be elegant, in
   the sense of having no more constructs than are needed
   to describe the full range of subject material.  During
   the design process, however, we prefer to err on the
   side of defining too many constructs, rather than too
   few, so that distinctions can easily be made as we gain
   better understanding of the differences between
   apparently similar things.  We will, of course, remove
   any duplications when finalizing the design, but
  1. 12 -
   premature optimization might cause us to overlook
   important differences.
/data/webs/external/dokuwiki/data/pages/archive/music/smdl-in.tro.txt · Last modified: 2000/08/13 06:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki