Introduction to MEI and XML Schema

The Music Encoding Initiative (MEI) is a framework for representing music notation in a structured, machine-readable way. It is based on XML, which means that MEI files are plain text files with a clear hierarchical structure.

For musicologists, this is useful because it allows us to:

• describe notation precisely
• document editorial decisions
• process musical data computationally
• validate encodings automatically
• exchange data between tools and projects

For the official documentation, see the MEI Guidelines: Introduction.

You can think of MEI like this:

• music notation = the thing we want to describe
• XML = the language used to write that description
• schema = the rulebook that says what is allowed
• MEI = a music-specific XML vocabulary

So MEI is not „just XML“. It is a specialized XML language for music notation.

XML stands for eXtensible Markup Language.

For absolute beginners, the easiest way to understand XML is:

XML is a way of writing structured information using labeled elements.

Example:

<note pname="c" oct="4" dur="4"/>

This means:

• the element is called note
• it has a pitch name: c
• it has an octave: 4
• it has a duration: 4

XML is made of elements and attributes.

Elements are the named building blocks, for example:

• <measure>
• <staff>
• <layer>
• <note>
• <rest>

Some elements have opening and closing tags:

<measure>
  ...
</measure>

Some are empty and written in a short form:

<note pname="c" oct="4" dur="4"/>

Attributes add information to an element.

Example:

<note pname="f" oct="5" dur="2"/>

Here:

• pname = pitch name
• oct = octave
• dur = duration

A useful beginner distinction is:

• element = what kind of thing this is
• attribute = extra information about that thing

A schema is a set of rules for an XML language.

For beginners, the most useful mental model is:

A schema is like a grammar or rulebook for XML.

It tells us things like:

• which elements are allowed
• where they are allowed
• which attributes they may have
• which values are valid

Without a schema, you could write almost anything. With a schema, a computer can check whether your file follows the rules.

So a schema helps answer questions like:

• Is a <note> allowed here?
• May a <measure> contain a <staff>?
• Is pname=„h“ valid?
• Does this link point to an existing element?

For editorial and research work, schema is important because it helps us avoid errors.

It can catch problems such as:

• invalid element names
• misplaced elements
• missing required information
• invalid attribute values
• broken references

So schema validation is one of the reasons MEI is useful in scholarly work:

• it makes encodings more consistent
• it makes collaboration safer
• it improves interoperability

MEI is an XML-based encoding framework. Its rules are not invented separately by each project. Instead, MEI defines a structured vocabulary for music notation.

For beginners, the important point is simply:

• XML gives the syntax
• MEI gives the music-specific elements and attributes
• the schema checks whether the encoding is valid

<measure n="1">
  <staff n="1">
    <layer n="1">
      <note pname="c" oct="4" dur="4"/>
      <note pname="d" oct="4" dur="4"/>
      <note pname="e" oct="4" dur="4"/>
      <note pname="f" oct="4" dur="4"/>
    </layer>
  </staff>
</measure>

You can read this as:

• one measure
• containing one staff
• containing one layer
• containing four notes

A very common beginner structure is:

score
└── section
    └── measure
        └── staff
            └── layer
                └── note / rest / chord / etc.

A practical way to understand this is:

• score = the whole musical object
• measure = one bar
• staff = one staff in that measure
• layer = one musical stream or voice on that staff
• note = one event inside that layer

Two important elements are:

• <scoreDef>
• <staffDef>

These do not usually encode the individual notes themselves. Instead, they define the notational environment.

You can think of them like this:

• scoreDef = settings that can apply to the whole score
• staffDef = settings for a particular staff

These are often used for things such as:

• clef
• key signature
• meter
• staff properties

A useful beginner idea is that these elements often act like defaults: they remain in force until they are changed later.

In Common Music Notation (CMN), MEI defines a note through three basic parameters:

• pname = pitch name
• oct = octave
• dur = duration

Example:

<note pname="c" oct="4" dur="4"/>

This means:

• pitch name = C
• octave = 4
• duration = quarter note

Pitch in beginner MEI examples is usually encoded with:

• pname
• oct

Example:

<note pname="g" oct="5" dur="2"/>

This means G5 as a half note.

So the basic pitch information is split into:

• note name
• octave

A written accidental can be encoded with the accid attribute.

Example:

<note pname="f" oct="4" dur="4" accid="s"/>

This means an F sharp quarter note.

For beginners, the important idea is:

• pname gives the diatonic pitch name
• accid adds the written accidental

In other words:

• pname=„f“ = F
• accid=„s“ = sharp sign written on that note

Duration is encoded with dur.

Common beginner values include:

• 1 = whole note
• 2 = half note
• 4 = quarter note
• 8 = eighth note

Example:

<note pname="a" oct="4" dur="8"/>

Measures are encoded with <measure>.

Example:

<measure n="12">
  ...
</measure>

Here:

• measure identifies the bar
• n stores the measure number or label

The measure acts as a container for the musical material belonging to that bar.

Inside a measure, notes are usually organized through:

• <staff>
• <layer>

Example:

<measure n="1">
  <staff n="1">
    <layer n="1">
      <note pname="c" oct="4" dur="4"/>
    </layer>
  </staff>
</measure>

For beginners:

• staff tells us which staff this is
• layer tells us which musical stream or voice on that staff

Key signatures are generally defined at the score or staff level, often through:

• <scoreDef>
• <staffDef>
• the keysig attribute

Example:

<scoreDef keysig="1s"/>

A beginner reading of this is:

• keysig stores the written key signature
• 1s means one sharp

Similarly:

<scoreDef keysig="2f"/>

means two flats.

For beginners it is enough to understand that:

• the key signature is usually a context-setting property
• it applies to the following music until changed

Meter is also typically defined in scoreDef or staffDef.

The most common beginner attributes are:

• meter.count = top number
• meter.unit = bottom number

Example:

<scoreDef meter.count="4" meter.unit="4"/>

This means 4/4.

Another example:

<scoreDef meter.count="3" meter.unit="8"/>

This means 3/8.

Clefs are usually part of the score or staff definition as well.

Typical attributes are:

• clef.shape
• clef.line

Example:

<staffDef n="1" clef.shape="G" clef.line="2"/>

This gives a treble clef on line 2.

One of the most important attributes in MEI is:

xml:id

This gives an element a unique identifier inside the document.

Example:

<note pname="g" oct="4" dur="4" xml:id="n42"/>

The key idea is:

xml:id gives this exact note its own identity.

That matters because other elements can refer to it.

For beginners, xml:id does three important things:

• it makes an element uniquely identifiable
• it allows linking
• it helps keep references stable

This is especially useful when we want to say:

• a dynamic starts at this note
• a slur begins here and ends there
• this annotation belongs to that symbol
• this facsimile zone corresponds to this note

<measure n="10">
  <staff n="1">
    <layer n="1">
      <note pname="f" oct="4" dur="4"/>
      <note pname="g" oct="4" dur="4" xml:id="n10_2"/>
      <note pname="a" oct="4" dur="4"/>
      <note pname="c" oct="5" dur="4"/>
    </layer>
  </staff>
 
  <dynam startid="#n10_2">f</dynam>
</measure>

Here:

• the second note has xml:id=„n10_2“
• the dynamic uses startid=„#n10_2“
• the # means „point to the element with this id“

So the dynamic is explicitly attached to that note.

For editorial and analytical work, xml:id is crucial because it lets us refer to specific musical objects.

That is important when:

• encoding slurs, ties, dynamics, and other control elements
• linking notation to facsimile zones
• attaching annotations
• documenting editorial intervention
• aligning musical data across tools

In practical terms:

• the note is no longer just „the third note in bar 10“
• it becomes a uniquely addressable object

A good beginner analogy is:

• the element itself is the musical object
• xml:id is its name tag
• another element can point to that name tag

Without xml:id, references are harder. With xml:id, you can point exactly to one specific note or symbol.

Not always.

In principle, a note can be encoded without xml:id.

Example:

<note pname="c" oct="4" dur="4"/>

But as soon as you want to point to that note from elsewhere, a unique identifier becomes extremely useful, and often necessary in practice.

For editorial workflows, it is often a very good idea to assign stable xml:id values systematically.

• MEI is an XML language for music notation
• XML consists of elements and attributes
• a schema is the rulebook for valid XML
• notes in MEI are often defined by pname, oct, and dur
• measures group the music into bars
• scoreDef and staffDef define context such as clef, key, and meter
• xml:id gives a specific element a unique identity
• other elements can point to that identity using attributes like startid and endid

The following snippet shows the core musical logic of notes, accidentals, meter, key signature, and xml:id.

However, it is still only a score fragment. A complete MEI document usually requires a larger outer structure, which is explained in the next section.

<score>
  <scoreDef keysig="1s" meter.count="4" meter.unit="4"/>
  <section>
    <measure n="1">
      <staff n="1">
        <layer n="1">
          <note pname="g" oct="4" dur="4" xml:id="m1n1"/>
          <note pname="a" oct="4" dur="4" accid="s" xml:id="m1n2"/>
          <note pname="b" oct="4" dur="4" xml:id="m1n3"/>
          <note pname="c" oct="5" dur="4" xml:id="m1n4"/>
        </layer>
      </staff>
      <dynam startid="#m1n2">f</dynam>
    </measure>
  </section>
</score>

This example shows:

• a score definition with key and meter
• one measure
• one staff
• one layer
• notes with pitch, octave, and duration
• one accidental
• unique xml:id values
• a dynamic linked to a specific note

So far, many examples in this introduction have shown only small fragments, such as a single measure or a short score passage.

That is useful for learning individual elements, but it is important to understand that a complete MEI file normally needs a larger structure around those fragments.

A beginner should think of MEI on two levels:

• document level = the whole file
• music level = the encoded notation inside the file

A normal MEI document usually has this overall form:

mei
├── meiHead
└── music
    └── body
        └── mdiv
            └── score
                └── section
                    └── measure
                        └── staff
                            └── layer
                                └── note / rest / chord / etc.

This can be read as:

• <mei> = the whole MEI document
• <meiHead> = metadata about the document
• <music> = the musical content
• <body> = the main musical body
• <mdiv> = a musical division, for example a movement or other large unit
• <score> = the score representation
• <section> = a segment of music
• <measure> = one measure
• <staff> = one staff
• <layer> = one layer or voice stream
• <note> = one musical event

This earlier example:

<score>
  <scoreDef keysig="1s" meter.count="4" meter.unit="4"/>
  <section>
    <measure n="1">
      <staff n="1">
        <layer n="1">
          <note pname="g" oct="4" dur="4" xml:id="m1n1"/>
          <note pname="a" oct="4" dur="4" accid="s" xml:id="m1n2"/>
          <note pname="b" oct="4" dur="4" xml:id="m1n3"/>
          <note pname="c" oct="5" dur="4" xml:id="m1n4"/>
        </layer>
      </staff>
      <dynam startid="#m1n2">f</dynam>
    </measure>
  </section>
</score>

is useful as a score fragment, but it is not yet a complete MEI document.

In practice, tools such as Verovio often expect a fuller MEI wrapper around the score data.

The following example shows the same musical idea inside a more complete MEI structure:

<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1">
  <meiHead>
    <fileDesc>
      <titleStmt>
        <title>Minimal MEI example</title>
      </titleStmt>
      <pubStmt/>
    </fileDesc>
  </meiHead>
 
  <music>
    <body>
      <mdiv>
        <score>
          <scoreDef keysig="1s" meter.count="4" meter.unit="4">
            <staffGrp>
              <staffDef n="1" lines="5" clef.shape="G" clef.line="2"/>
            </staffGrp>
          </scoreDef>
 
          <section>
            <measure n="1">
              <staff n="1">
                <layer n="1">
                  <note pname="g" oct="4" dur="4" xml:id="m1n1"/>
                  <note pname="a" oct="4" dur="4" accid="s" xml:id="m1n2"/>
                  <note pname="b" oct="4" dur="4" xml:id="m1n3"/>
                  <note pname="c" oct="5" dur="4" xml:id="m1n4"/>
                </layer>
              </staff>
              <dynam startid="#m1n2">f</dynam>
            </measure>
          </section>
        </score>
      </mdiv>
    </body>
  </music>
</mei>

Important: In a normal five-line staff, <staffDef> should usually include lines=„5“. Without this, some renderers may not display the staff correctly.

You can try to render this score yourself via Verovio Editor

This example now includes the parts that were missing before:

• <mei> as the document root
• xmlns to declare the MEI XML namespace
• meiversion to indicate the MEI version
• <meiHead> for metadata
• <music> for the musical content
• <body> and <mdiv> as structural containers around the score
• <scoreDef> and <staffDef> to define the notational context

Only inside this larger wrapper do we get to the actual note material.

The <meiHead> element contains metadata.

For beginners, it is enough to understand that this is where information about the encoded object and the encoding can be stored, for example:

• title
• source information
• editorial responsibility
• encoding notes
• revision history

In small teaching examples, the header may be very short. In research projects, it can become much more detailed.

Inside <music>, the musical content is usually placed inside <body>.

Inside the body, <mdiv> represents a musical division. Depending on the source, this may represent:

• a whole piece
• a movement
• an act
• a scene
• another large formal division

For simple teaching examples, one <mdiv> is usually enough.

When writing MEI for testing or rendering, it is safest to think in this order:

1. start with <mei>
2. add <meiHead>
3. add <music>
4. inside music, add <body>
5. inside body, add <mdiv>
6. inside mdiv, add <score>
7. inside score, add <scoreDef> and <section>
8. inside section, add measures, staves, layers, and notes

This avoids the impression that a musical fragment by itself is already a complete MEI file.

A useful memory formula is:

• MEI document = metadata + music
• music = body + divisions + score content
• score content = sections + measures + staves + layers + events

For the official reference documentation, see:

• MEI Guidelines: Introduction