💾 Archived View for spam.works › mirrors › textfiles › music › smdl-in.tro captured on 2023-06-16 at 19:19:43.
-=-=-=-=-=-=-
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.
- 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.)
- 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
- 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
- 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.
-- 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.
-- 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.
-- 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.
-- 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.
- 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:
- 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."
- 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
- 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.
- 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.
- 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
- 12 -
premature optimization might cause us to overlook
important differences.