3Encodingnot necessarily an input code, but still human readable (and understandable!)declarative – preferable to procedural representationformal – verifiableexplicit – context independentflexible – allows selective feature encoding, can be constrained, separates visual, gestural, and analytical domainsextensible – for unknown uses, future developmentof particular interest: musical form, text, critical apparatusThe simplicity of a DTD allows for ready creation of differently constrained versions at different points in the document's life cycle.
4Interchange 12 translators MEI 30 translators comprehensive – generalizedsoftware independentN*(N-1) vs. N*2 translators12 translatorsMEI30 translators
6Document element mei (meihead, work) – encodes a single work separates document into data and meta-data parts, allowing meta-data to be shared with other internal and external entitiesname cannot be changed in order to assure an absolute minimum level of MEI complianceFor other elements MEI allows, via architectural forms: longer, descriptive element names for new users; shorter, mnemonic ones for experienced users and reduction of storage requirements; internationalization; extension mechanism based on concept name
7Alternate document element meicorpus (meihead, mei+) – encodes multiple mei instances where each requires a header of its ownalso provides header for entire filename cannot be changed in order to assure an absolute minimum level of MEI compliance
8meihead elementencodes bibliographic (descriptive, administrative, and technical) meta-data for the filefiledesc element contains data, such as title, agent, and publication status, and access data, such as vendor, price, and rights management info, for the filesourcedesc element contains descriptions of each source for the file. source elements employ the same bibliographic elements as filedesc, but also include physical description elements, such as medium, dimensions, provenance, inscription, condition, etc.<!ELEMENT filedesc (titlestmt, editionstmt?, pubstmt, seriesstmt?, extent?, fingerprint?, notesstmt?)><!ELEMENT source (titlestmt, editionstmt?, pubstmt, seriesstmt?, physdesc?, extent?, notesstmt?)><!ELEMENT physdesc (extent|physmedium|dimensions|provenance|inscription|exhibithist|condition|treatmenthist|treatmentsched)+>meihead based on ISBD(G), teiHeader, and FRBR
9work element the "thing" being encoded may include not just music notation, but also the textual matter often found in a critical or historical edition, composer's textual notes, advertisements, etc.name cannot be changed in order to assure an absolute minimum level of MEI compliance
10Work-level textfront and back child elements provide basic logical and presentational text markup functionalityaccommodating text gives control of the text and notation to MEI, which embedding notation in another markup scheme, such as TEI, will not do
11music elementencodes the musical, as opposed to the textual, content of the workcontains highest-level indication of the structure of the composition – one or more discrete, linear segments, called mdiv ("musical division")generic mdiv elements may be typed – symphonies, for example, usually consist of movements while operas are made up of acts
12group elementfacilitates creation of a collection of work elements that share a bibliographic header – a collection of songs by different composers issued under a single title, for examplebasic meta-data for each work may be encoded in its own front matter or in source elements in the file headeruse meicorpus element when a complete bibliographic header is required for each member of a collectionfront matter is usually intended for display; source is usually for machine-processing
13mdiv elementmay contain one or both of two possible organizing views – score and partsscore element contains a time-oriented view of the composition – a full scoreparts element contains part elements each of which represents a performer's view
14mdiv element, con't.score and parts views are intended to accommodate different methods of organizing the markup – no particular presentation is implied, software may render a collection of parts as a score or a score as a collection of partsit is not always possible or desirable to generate one view from the other. A great deal of complexity can be eliminated by separating score and part markup.
15part elementhas all the encoding features of a full score – content models of score and part elements are identicalvoice-leading should be recorded at the event level using the next or prev attributes
16part element, cont. use part elements when there is no score, only a collection of partsparts don't share visual characteristics, such as typeface or layout with the full score or with each otherscore has non-aligning bar linesaccommodating rendering software that requires staff-by-staff encodingIn version 1.4b staff-by-staff encoding can be accomplished without resorting to parts-only markup.
17section elementscore or part may be divided into linear segments or sectionssections usually function as scoping mechanisms for clef signs, key and meter signatures, and expression marksminimize the need for backward scanning to establish context when the starting point for access is not at the beginningwhen a section contains sections, the expan attribute on the outer section element may be used to encode the performance order of the inner sectionsSee example under 'ending element'.
18section element, con't.may also be used for user-defined, that is, analytical or editorial, purposesmay be arbitrarily nested to any level
19app and ossia elementsan app element contains at least one alternative readingeach rdg may be linked to a source description in the headerrdg may contain app so that variants of variants may be describedeach rdg may be assigned an order, e.g. for selection or rendering purposes, other than the encoded orderossia performs a similar function at the measure level, however, it represents an alternative present in the source being transcribed.
20ending elementspecialized form of the section element that may not be recursively nested<section expan="a b a c"><section id="a"><measure>...</measure></section><ending id="b" label="1."></ending><ending id="c" label="2.">...
21measure element contains events, not symbols even though events have visual properties, modeling symbols places too much emphasis on presentation and makes the markup less useful as a general "music" (as opposed to "notation") markup schemeis a linking element that connects the MEI document to an external electronic object, i.e., image, or to another location within the current MEI instance
22Control eventscontrol events, such as dynamics, ties, phrase marks, pedal marks, etc. depend on other eventsdo not fit the principal hierarchy of sections, measures and stavesmultiple control events of the same type, i.e., pedal indications, may be associated with the same set of events, i.e., notes
23staff elementmay be used to indicate division of the measure's contents into multiple data streams<measure><staff def="1"><note /><rest />...</staff><staff def="2"><note /></staff></measure>does not necessarily indicate layout!in a staff-by-staff encoding, staff may contain measure elements<staff><measure n="1">...</measure><measure n="2">...</measure></staff>
24Music Encoding Initiative (MEI) DTD and the OCVE Perry RolandDigital Library Research & Development Group, Alderman Library, University of Virginia