Audio Version 4.94

home *** CD-ROM | disk | FTP | other *** search

/ Audio Version 4.94 / audioversion4.94knowledgemediaresourcelibraryoctober1994.iso / unix / midi_doc / smdl_ntr < prev next >

Wrap

Text File | 1993-02-08 | 26KB | 728 lines

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.