M2) MusicXML sous le microscope formel

Quand XML rencontre la notation musicale

MusicXML a une grammaire formelle complète — son schéma XSD. Pourtant, il ne peut pas plus générer de musique que MIDI. Comment est-ce possible ?

Où se situe cet article ?

Dans I5, nous avons découvert comment MusicXML fonctionne — balises, mesures, notes, interopérabilité. Dans M1, nous avons passé MIDI au crible des langages formels et découvert qu’il se situe au pied de la hiérarchie de Chomsky (Type 3, langage régulier). Ici, on applique le même microscope à MusicXML.

Le résultat est surprenant : MusicXML se situe un niveau au-dessus de MIDI dans la hiérarchie (Type 2, context-free). Et surtout, contrairement à MIDI, MusicXML possède une grammaire formelle complète — son schéma XSD (XML Schema Definition). Pourtant, cette formalisation ne lui donne aucun pouvoir génératif musical. Comprendre ce paradoxe est fondamental pour saisir pourquoi des systèmes comme BP3 sont nécessaires.

MusicXML vu par les langages formels

Un format XML = un langage → un arbre → une grammaire d’arbre

Tout format XML peut être analysé comme un langage formel. Il a :

Un alphabet : l’ensemble des caractères Unicode, structurés en balises, attributs et contenu textuel.
Une syntaxe : les règles qui déterminent quels documents sont bien formés. Pour XML, la règle fondamentale est l’imbrication correcte des balises — chaque <note> doit avoir son </note>.
Un schéma : les contraintes supplémentaires sur la structure. Pour MusicXML, le XSD définit quels éléments peuvent contenir quels autres éléments, avec quels attributs, dans quel ordre.

La question est : quel type de langage est MusicXML ? Et sa grammaire formelle (le XSD) — qu’est-ce que c’est, exactement, dans la classification de Chomsky (L1) ?

L’alphabet : balises, attributs, contenu textuel

Contrairement à MIDI qui opère sur un alphabet binaire de 256 octets (M1), MusicXML opère sur un alphabet textuel structuré :

Balises : <note>, <pitch>, <measure>, etc. — environ 700 éléments définis dans le XSD
Attributs : id="P1", number="1", type="start" — qualifient les éléments
Contenu textuel : C, 4, quarter — les valeurs entre balises

Cette richesse d’alphabet est possible parce que XML est un format texte, là où MIDI est contraint par un format binaire.

Niveau 1 : XML = Type 2 (context-free) par nature

Les balises imbriquées = récursion = Type 2

Tout document XML bien formé appartient à un langage context-free (Type 2 dans la hiérarchie de Chomsky, L1). La raison est structurelle et fondamentale :

<score-partwise>
  <part>
    <measure>
      <note>
        <pitch>
          <step>C</step>
        </pitch>
      </note>
    </measure>
  </part>
</score-partwise>

Les balises ouvrantes et fermantes forment un système de parenthèses imbriquées. Chaque <note> doit avoir son </note>, et les éléments s’imbriquent les uns dans les autres à profondeur arbitraire. Ce mécanisme — l’imbrication — est exactement ce qui distingue les langages context-free des langages réguliers.

Rappel (L1) : Un langage régulier (Type 3) ne peut pas gérer l’imbrication — il faudrait « compter » les parenthèses ouvertes pour vérifier qu’elles sont toutes fermées. Un automate fini n’a pas de mémoire pour ça. Un automate à pile (le modèle du Type 2) empile les balises ouvrantes et dépile à chaque balise fermante.

Un parseur XML est un automate à pile

Le parsing d’un document XML est exactement celui d’un langage context-free :

Rencontre <note> → empile « note »
Rencontre <pitch> → empile « pitch »
Rencontre </pitch> → dépile, vérifie que c’est bien « pitch »
Rencontre </note> → dépile, vérifie que c’est bien « note »

Si la pile est vide à la fin et qu’aucune erreur n’est survenue, le document est bien formé.

Contraste avec MIDI

Aspect	MIDI (Type 3)	MusicXML (Type 2)
Modèle de parsing	Automate fini (pas de mémoire)	Automate à pile (empile les balises)
Structure	Séquentielle (événements plats)	Arborescente (éléments imbriqués)
Imbrication	Impossible	Fondamentale
Récursion	Aucune	Structurelle (un élément contient des éléments)

MIDI est un flux d’événements plats — comme lire une liste. MusicXML est un arbre — comme naviguer dans un organigramme. Cette différence structurelle se traduit directement dans la hiérarchie de Chomsky : MIDI au Type 3, MusicXML au Type 2.

Niveau 2 : XSD = une grammaire formelle complète

Le XSD MusicXML EST une spécification formelle

Voici le fait le plus marquant quand on compare MIDI et MusicXML du point de vue formel :

MIDI : après 40 ans d’existence, il n’existe aucune grammaire formelle du protocole (M1). Quelques fragments semi-formels (pseudo-BNF du SMF, grammaire ABNF dans la RFC 6295), mais rien de complet.
MusicXML : le XSD est une grammaire formelle complète. Il définit exactement quels documents sont valides — quels éléments peuvent contenir quels autres, dans quel ordre, avec quelles contraintes.

C’est un contraste saisissant. Grâce au choix d’XML comme format sous-jacent, MusicXML hérite automatiquement d’un cadre de spécification formelle rigoureux — le XML Schema.

XSD = une grammaire régulière d’arbres

Les travaux fondamentaux de Murata, Lee & Mani (2005) ont établi une classification formelle des langages de schéma XML :

DTD (l’ancien format de validation) ≈ langage d’arbre local : le type d’un élément dépend uniquement de son nom, pas de sa position dans l’arbre
XSD (le format actuel) ≈ langage d’arbre à type unique (single-type tree language) : le type d’un élément dépend de son nom et du type de son parent
RELAX NG (utilisé par MEI) ≈ langage d’arbre régulier : le type peut dépendre du chemin complet depuis la racine — le plus expressif

Le XSD MusicXML est donc une grammaire régulière d’arbres au sens de la théorie des langages formels. Chaque type complexe du XSD (comme note, pitch, measure) définit une production : un nœud parent et la séquence d’enfants autorisés.

partwise vs timewise : deux vues du même arbre

MusicXML offre deux éléments racine possibles — score-partwise et score-timewise (I5). Formellement, ce sont deux grammaires d’arbre différentes qui décrivent le même ensemble de partitions musicales. La transformation XSLT entre les deux est une transformation d’arbre à arbre — une opération bien définie dans la théorie des langages d’arbres.

C’est comme avoir deux grammaires qui génèrent le même langage : les mots sont les mêmes, seule la structure de dérivation change.

La validation XSD = reconnaissance par automate d’arbre

Valider un document MusicXML contre son XSD, c’est demander : « ce document appartient-il au langage défini par la grammaire d’arbre ? » La réponse est donnée par un automate d’arbre déterministe — une machine qui parcourt l’arbre nœud par nœud et vérifie que chaque nœud respecte les contraintes de son type.

Le XSD impose une contrainte appelée UPA (Unique Particle Attribution, attribution de particule unique) : chaque élément enfant doit pouvoir être assigné à exactement une particule du modèle de contenu sans regarder devant (sans lookahead). Cela garantit un parsing déterministe — l’automate d’arbre n’a jamais besoin de revenir en arrière.

Niveau 3 : le contenu musical = zéro pouvoir génératif

La même conclusion que pour MIDI

Point crucial — et résultat identique à M1 : MusicXML en tant que représentation musicale n’a aucun pouvoir génératif.

Un fichier MusicXML décrit une partition spécifique — cette sonate, cette mesure, cette note. Il ne peut pas dire :

« Joue ce motif 3 fois avec variation » (il faut écrire les 3 occurrences)
« Choisis aléatoirement entre deux harmonisations » (pas de stochasticité)
« Superpose ces deux flux en ratio 3:4 » (pas de polymétrie native)
« Définis une phrase comme séquence de motifs recombinables » (pas de variables musicales)

En termes de langages formels, un fichier MusicXML est un mot du langage, pas une grammaire. Il décrit un résultat, pas un processus de génération.

Le parallèle « mot vs grammaire » (comme pour MIDI)

Concept	En langages formels	En MusicXML
Grammaire	Ensemble de règles qui définit un langage	Le XSD (définit quels documents sont valides)
Mot	Une séquence spécifique du langage	Un fichier MusicXML (une partition spécifique)
Génération	La grammaire produit des mots	Le XSD ne produit pas de partitions

Le paradoxe MusicXML : formalisé mais pas génératif

Deux formats, deux gaps, même résultat

Comparons les situations :

MIDI : pas de grammaire formelle du protocole + pas de pouvoir génératif musical
MusicXML : grammaire formelle complète (XSD) + toujours pas de pouvoir génératif musical

La formalisation syntaxique du format ne confère aucun pouvoir expressif au contenu musical. Le XSD peut dire « un élément <note> doit contenir un <pitch> ou un <rest/>« , mais il ne peut pas dire « un accord de dominante résout sur la tonique » ou « répète ce motif en augmentation ».

Pourquoi ?

Parce que le XSD formalise le conteneur (la structure du fichier), pas le contenu (les relations musicales). C’est la différence entre :

Définir les règles de la syntaxe d’une langue (grammaire du français)
Écrire un texte dans cette langue (un roman)

Le XSD est une grammaire du format MusicXML. Un fichier MusicXML est un texte écrit dans ce format. Mais ni le XSD ni le fichier ne sont une grammaire de la musique elle-même.

La formalisation syntaxique ne donne pas le pouvoir expressif musical

Ce point est fondamental pour le projet : formellement, la situation est la suivante :

Niveau	MIDI	MusicXML	BP3
Grammaire du format	Absente (gap)	Présente (XSD)	Présente (EBNF)
Grammaire de la musique	Absente	Absente	Présente (règles de réécriture)
Pouvoir génératif	Aucun	Aucun	Oui (stochastique, polymétr.)
Type Chomsky du contenu	Mot (instance)	Mot (instance)	Grammaire (Type 2 → Turing)

Comparaison : les trois formats étudiés

Format	Parsing	Grammaire formelle ?	Contenu génératif	Type Chomsky
MIDI 1.0 (M1)	Automate fini	Non (gap de recherche)	Aucun	Type 3
SMF (M1)	Parseur LL(1)	Pseudo-BNF (partielle)	Aucun	Type 2 (faible)
MusicXML	Automate à pile / automate d’arbre	Oui (XSD complet)	Aucun	Type 2
BP3 (I2)	Parseur CFG + interpréteur	En construction	Oui (grammaires)	Type 2 → Turing

La leçon : la formalisation d’un format d’échange ne suffit pas — il faut un langage de spécification musicale pour obtenir le pouvoir génératif. MusicXML a une grammaire formelle complète et pourtant n’est pas plus génératif que MIDI.

D’autres formats musicaux (MEI, ABC, LilyPond, **kern…) méritent la même analyse formelle. C’est l’objet de M8.

Contraste avec BP3

Format vs Langage

Aspect	MusicXML	BP3
Nature	Format d’échange (un mot)	Langage de spécification (une grammaire)
Le XSD/EBNF définit…	« Quels documents sont valides »	« Quelles séquences sont générables »
Récursion	Structurelle (XML) mais pas musicale	Musicale (règles récursives)
Stochasticité	Aucune	Oui (poids, modes RND/SUB)
Polymétrie	Non (une seule timeline par mesure)	Oui (ratios, parallèle)
Résultat	Une partition figée	Un espace de partitions

L’import MusicXML → BP3 (documenté sur le site du Bol Processor) est une transformation d’un mot en une grammaire : les fragments de la partition deviennent des variables manipulables, réorganisables, combinables. C’est le passage d’une description statique à une spécification dynamique.

Ce qu’il faut retenir

MusicXML est un langage context-free (Type 2) : les balises imbriquées nécessitent un automate à pile, contrairement à MIDI (Type 3, automate fini).
Le XSD MusicXML est une grammaire formelle complète : contrairement à MIDI qui n’a jamais été formellement spécifié, MusicXML a une spécification rigoureuse grâce au XML Schema.
XSD = grammaire régulière d’arbres : les travaux de Murata, Lee & Mani (2005) classifient les schémas XML dans la théorie des langages d’arbres.
MusicXML n’a aucun pouvoir génératif musical : malgré sa formalisation syntaxique, il décrit une partition figée, pas un processus de génération. C’est un mot, pas une grammaire.
Le paradoxe : la formalisation du format (conteneur) ne confère pas de pouvoir expressif au contenu (musique). MIDI sans grammaire et MusicXML avec grammaire sont également non-génératifs.
BP3 opère à un niveau fondamentalement différent : là où MusicXML formalise le format d’échange, BP3 formalise le processus de génération musicale.

Glossaire

Automate à pile (pushdown automaton) : machine qui étend l’automate fini avec une pile (mémoire LIFO — Last In, First Out). Reconnaît exactement les langages context-free (Type 2). Un parseur XML est un automate à pile. Voir L1.
Automate d’arbre (tree automaton) : machine qui reconnaît des arbres (plutôt que des chaînes). Utilisée pour la validation de documents XML contre un schéma.
Context-free (hors-contexte) : type de grammaire (Type 2) où chaque règle remplace un seul symbole, indépendamment du contexte. Permet la récursion et l’imbrication — exactement ce que fait XML. Voir L2.
DTD (Document Type Definition) : ancien format de validation XML, correspondant à un langage d’arbre local. Supplanté par XSD depuis MusicXML 4.0.
Grammaire d’arbre (tree grammar) : grammaire qui opère sur des arbres plutôt que sur des chaînes de caractères. Les schémas XML sont des grammaires d’arbres.
Imbrication : propriété structurelle des langages context-free — un élément peut contenir d’autres éléments du même type, à profondeur arbitraire. C’est la clé du Type 2.
RELAX NG : format de validation XML plus expressif que XSD, correspondant à un langage d’arbre régulier complet. Utilisé par MEI.
UPA (Unique Particle Attribution) : contrainte du XSD qui impose un parsing déterministe — chaque élément enfant correspond à exactement une particule du modèle de contenu.
XSD (XML Schema Definition) : format de validation XML du W3C. Pour MusicXML, le XSD constitue une spécification formelle complète du format.

Liens dans la série

Série Introduction (prérequis) :

I5 — Introduction à MusicXML : la partition numérique universelle

Série Langages formels (outils théoriques) :

L1 — Hiérarchie de Chomsky : le cadre de classification utilisé ici
L2 — Grammaires context-free : le niveau auquel MusicXML se situe
L3 — EBNF : la notation formelle pour les grammaires

Série Musique :

M1 — MIDI sous le microscope formel (contraste Type 3 vs Type 2)
M3 (à venir) — Les trois paradigmes de représentation musicale
M8 — Formats symboliques au-delà de MIDI et MusicXML

Série BP3 :

B1 — Grammaires probabilistes : BP3 commence au Type 2

Glossaire :

Glossaire — Glossaire général de la série

Prérequis : I5, L1
Temps de lecture : 15 min
Tags : #musicxml #langages-formels #chomsky #xml-schema #grammaire-arbre #formalisation

Prochain article : M3 — Les trois paradigmes de représentation musicale

← Retour à l’index