RFC 0001 — Version 0.3
Status: DraftCreated: 2025-12-12
Authors: MRS Working Group
License: CC BY 4.0
Abstract
This document specifies MRS (Music Representation Syntax), a format for encoding musical scores optimized for AI-assisted composition workflows. MRS uses a single canonical syntax (MRS-S) for complete, archival-quality score encoding, combined with a Working Set Envelope protocol that enables machine agents to operate on bounded fragments of scores with appropriate surrounding context. The key insight is that agents need context management—the ability to focus on specific regions while understanding their musical surroundings. The Working Set Envelope extracts a self-contained MRS-S fragment with explicit boundaries, graduated context rings providing surrounding material at reduced detail, and access to a structural synopsis of the full score. Agents receive valid MRS-S, return valid MRS-S, and the orchestrator performs replacement with full validation. Every measure carries a stable UUID identifier; measure numbers are display properties for human navigation. All internal references—scopes, spans, overlays—use UUIDs, ensuring structural stability through insertions, deletions, and reorderings. The specification prioritizes semantic completeness, deterministic parsing, structural stability, and lossless extract-replace round-trips. MRS serves as a universal interchange format and as the native representation for AI-assisted and agent-driven workflows over full scores at professional scale.Table of Contents
- Introduction
- Design Principles
- Architecture Overview
- MRS-S: The Canonical Format
- Working Set Envelope
- Synopsis Format
- Analytical Overlays
- Data Model
- Extract-Replace Protocol
- Agent Operations
- Query Resolution
- Validation Rules
- Extension Mechanisms
- MIME Types and File Extensions
- Security Considerations
- Appendix A: Complete Grammar
- Appendix B: Quick Reference
- Appendix C: Comparison with Existing Formats
- Appendix D: Glossary
1. Introduction
1.1 Motivation
Existing music notation formats fall into two categories: Interchange formats (MusicXML, MEI) prioritize completeness but are verbose, difficult to parse, and hostile to both human editing and machine learning workflows. A simple four-bar melody may require hundreds of lines of XML. Compact formats (ABC notation, LilyPond) optimize for human entry but sacrifice semantic precision, lack formal grammars, and cannot represent the full complexity of professional scores. Neither category addresses two fundamental challenges: Scale: A full orchestral score contains too much information for any single context window, human or machine. Editing measure 847 should not require loading measures 1-846 into memory. Context: Musical decisions require understanding surrounding material. An agent writing a countermelody needs to know what it’s responding to—not just the target measures, but phrase boundaries, harmonic rhythm, and thematic relationships. MRS solves this through a single canonical format combined with a context-aware extraction protocol:- MRS-S provides complete, unambiguous encoding of any score with stable UUID identifiers
- Working Set Envelopes extract bounded MRS-S fragments with graduated context rings
- Synopsis provides compressed structural views for global awareness
- Agents receive and return valid MRS-S—no second syntax, no parsing ambiguity
- A formal extract-replace protocol guarantees lossless round-trips
1.2 Goals
- Semantic completeness: Encode everything a professional engraver needs
- Deterministic parsing: One input → one parse tree, always
- Structural stability: UUIDs survive insertions, deletions, and reorderings
- Context-aware operations: Agents work with appropriate surrounding context
- Machine-friendly: Predictable patterns for reliable LLM/agent generation
- Human-auditable: People can review and debug outputs
- Diff-friendly: Line-based changes produce meaningful diffs
- Renderer-agnostic: Describe what, not how to draw
1.3 Non-Goals
- Encoding visual layout (page breaks, staff spacing, collision avoidance)
- Providing a programming language (no loops, conditionals, macros)
- Defining audio synthesis or playback behavior
- Replacing domain-specific formats (MIDI, audio, engraving source)
1.4 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.| Term | Definition |
|---|---|
| Score | A complete musical work in MRS format |
| Part | A single instrument or voice throughout a score |
| Staff | A visual grouping of five lines; parts may have multiple staves |
| Voice | An independent melodic/rhythmic stream within a staff |
| Measure | A metrical unit bounded by barlines, identified by UUID |
| Event | An atomic musical occurrence (note, rest, chord), identified by UUID |
| Span | A relation connecting multiple events (slur, beam, hairpin) |
| Synopsis | A compressed structural view of the full score |
| Working Set | A subset of a score extracted for editing with context |
| Overlay | Analytical metadata attached to score regions |
2. Design Principles
2.1 Explicit Over Implicit
Every musical element has an explicit representation. Position in the measure is stated, not inferred from accumulated durations. Voice assignment is declared, not guessed from stem direction. Rationale: Implicit state creates cascading errors. If an LLM miscounts one duration, all subsequent events are misaligned. Explicit positions are independently verifiable.2.2 Stable Identity Over Positional Reference
Measures and events carry stable UUIDv7 identifiers. Measure numbers are display properties for human navigation, not structural identity. All internal references use UUIDs. Rationale: Positional references break when content is inserted or deleted. UUID references survive structural changes, enabling fluid compositional workflows where form evolves during the creative process.2.3 Semantic Over Visual
MRS encodes musical meaning, not visual appearance. A crescendo is marked with start/end points and type, not with specific hairpin coordinates. Rationale: Visual rendering is context-dependent (page size, staff spacing, font). Semantic encoding remains valid across all rendering contexts.2.4 Predictable Over Clever
The format uses regular patterns even when more compact alternatives exist. Every note uses the same syntax regardless of context. Rationale: LLMs generate more reliably when patterns are consistent. A 10% size reduction is not worth a 50% increase in generation errors.2.5 Context Over Isolation
Working Sets include graduated context rings—surrounding material at reduced detail levels. Agents operate on focused regions while understanding their musical surroundings. Rationale: Musical decisions are contextual. A countermelody responds to what precedes and follows it. Phrase boundaries, harmonic rhythm, and thematic relationships inform compositional choices.2.6 One Format, Scoped Extraction
MRS uses a single syntax (MRS-S) for all operations. Working sets are not a different format—they are bounded MRS-S fragments wrapped in an extraction envelope with context. Rationale: Maintaining two syntaxes creates parsing complexity, abbreviation ambiguity, and merge conflicts. A single syntax means agents receive what they return: valid MRS-S.3. Architecture Overview
MRS enables context-aware agent operations on full-scope scores: tools and machine agents operate on focused regions with appropriate surrounding context, while the orchestrator maintains the full score and handles structural coordination.3.1 Core Components
3.2 The Context Problem
A full orchestral score is fundamentally too large for efficient manipulation:| Score Type | Parts | Measures | Events | MRS-S Size | Tokens |
|---|---|---|---|---|---|
| Lead sheet | 1 | 32 | ~200 | ~8 KB | ~2K |
| Piano sonata | 2 | 300 | ~5,000 | ~150 KB | ~40K |
| String quartet | 4 | 400 | ~8,000 | ~250 KB | ~65K |
| Choral + piano | 6 | 100 | ~3,000 | ~100 KB | ~25K |
| Chamber orchestra | 25 | 500 | ~50,000 | ~1.5 MB | ~400K |
| Full orchestra | 90 | 1000 | ~200,000 | ~6 MB | ~1.5M |
- What melodic material the clarinet responds to
- The harmonic context (what chords are sounding)
- Where phrase boundaries fall
- What comes before and after the edit region
- Content: Full-detail MRS-S for the edit region (writable)
- Context rings: Surrounding material at reduced detail (read-only)
- Synopsis access: Structural overview of the entire score (read-only)
3.3 Stable Identifiers
Every Measure, Event, and Span in an MRS-S score MUST carry a stable identifier in the form of a UUIDv7 (monotonic + random) under the key:id.
Measure identifiers:
:id— Stable identity, survives insertions/deletions, used for all internal references:number— Display property for human navigation, can change when bars are inserted/deleted
:display-hint fields for human readability; they are never used for structural reference.
Once assigned, an :id is immutable for the lifetime of the score.
3.4 Dual Positioning Model
Every part MUST contain a parallel absolute time spine expressed in two units:- Beats – exact rational number of quarter-notes since the start of the part (using the rational syntax in this document, e.g.,
487+1/2). - Seconds – floating-point seconds since start (optional, but REQUIRED if any tempo automation exists).
- Structural position within measure (beat index) for human readability
- Absolute position
:at(beats) for meter-agnostic reasoning
3.5 Sequential Composition Model
Composition is fundamentally sequential at the structural level. Form, phrase lengths, and section boundaries are discovered through the compositional process. MRS supports:- Sequential agent operations with full structural flexibility
- Insertion and deletion as first-class operations
- UUID stability ensuring references survive structural changes
- Structural checkpoints when appropriate (optional)
4. MRS-S: The Canonical Format
4.1 Overview
MRS-S is an S-expression-based format optimized for:- Complete semantic fidelity
- Clear hierarchical structure
- Self-documenting readability
- Straightforward parsing
- Stable identity via UUIDs
4.2 Document Structure
overlays, alternatives, and layout are REQUIRED. Sections MUST appear in the order shown.
4.3 Version Declaration
4.3.1 Version Domains
This RFC uses three distinct version identifiers:- RFC version (e.g., “RFC 0001 — Version 0.3”) — the editorial version of this document.
- MRS-S format version — the value in
(mrs-s <version> ...)that governs parsing/validation of score documents. - Working Set Envelope protocol version — the
:versionfield inside(working-set ...)and(working-set-response ...).
4.4 Metadata Section
4.4.1 Required Metadata Fields
| Field | Type | Description |
|---|---|---|
:title | string | Primary title of the work |
4.4.2 Optional Metadata Fields
| Field | Type | Description |
|---|---|---|
:subtitle | string | Secondary title |
:composers | [string] | List of composer names |
:arrangers | [string] | List of arranger names |
:lyricists | [string] | List of lyricist names |
:copyright | string | Copyright notice |
:created | string | Original creation date |
:modified | ISO 8601 | Last modification timestamp |
:source | string | Source edition reference |
:language | ISO 639-1 | Primary language for lyrics |
:tags | [string] | Classification tags |
:key | pitch-class | Default key (A-G with optional #/b) |
:mode | keyword | major, minor, dorian, etc. |
:time | fraction | Default time signature |
:tempo | integer | Default tempo in BPM |
:tempo-text | string | Tempo marking text |
4.5 Parts Section
4.5.1 Part Identifier
The part identifier (e.g.,flute-1, clarinet-bb) MUST be unique within the score and MUST match the regex [a-z][a-z0-9-]*.
4.5.2 Part Attributes
| Attribute | Required | Type | Description |
|---|---|---|---|
:name | YES | string | Full display name |
:abbr | YES | string | Abbreviated name for systems |
:staves | YES | [clef] | List of staff clefs |
:section | NO | keyword | Instrument family grouping |
:midi-program | NO | 0-127 | General MIDI program number |
:transposition | NO | interval | Transposition from written to sounding |
:range | NO | [pitch pitch] | Playable range (written pitch) |
:has-lyrics | NO | boolean | Whether part carries lyrics |
:staff-connect | NO | keyword | brace, bracket, line, none |
4.5.3 Clef Values
4.5.4 Section Values
4.5.5 Transposition Specification
4.6 Measures Section
4.6.1 Measure Attributes
| Attribute | Required | Type | Description |
|---|---|---|---|
:id | YES | UUIDv7 | Stable identifier for all references |
:number | YES | positive int | Display number (1-indexed) |
:beat-start | YES | rational | Absolute beat position since part start |
:sec-start | CONDITIONAL | float | Absolute seconds (REQUIRED if tempo automation) |
:time | NO | fraction | Time signature change |
:key | NO | pitch-class | Key signature change |
:mode | NO | keyword | Mode specification |
:tempo | NO | integer | Tempo change in BPM |
:tempo-text | NO | string | Tempo marking text |
:rehearsal | NO | string | Rehearsal mark |
:barline-left | NO | barline-type | Left barline style |
:barline-right | NO | barline-type | Right barline style |
:pickup | NO | duration | Pickup/anacrusis duration |
4.6.2 Barline Types
4.6.3 Attribute Inheritance
Measure attributes inherit from previous measures unless overridden::time— persists until changed:key,:mode— persist until changed:tempo,:tempo-text— persist until changed:rehearsal— does NOT inherit (single-measure):barline-*— do NOT inherit (per-measure)
4.7 Part Content Within Measures
4.7.1 Voice Naming
For single-staff parts:v1throughv4for independent voices- Voice
v1is the primary voice; higher numbers are secondary
:rh/:lhfor right/left hand- Or
:staff1/:staff2for numbered staves - Each staff may contain multiple voices:
(:rh (v1 ...) (v2 ...))
Layers (Same-Rhythm Sub-Structure)
Within a voice, layers MAY be used to represent same-rhythm content:4.8 Event Syntax
4.8.1 The Beat-Position Event
| Component | Description |
|---|---|
: | Event marker (always present) |
<beat> | Beat position within measure (0-indexed, exact rational) |
<pitch-expr> | Pitch with duration, chord, or rest |
<properties> | Zero or more :keyword value pairs |
:id— Stable UUIDv7 identifier (REQUIRED):at— Absolute beat position as rational number (REQUIRED)
4.8.2 Beat Position
Beat positions are zero-indexed exact rationals relative to the measure start. They MUST be representable without approximation. Implementations MUST treat these values as exact numbers (no floating point tolerance).- Integers MAY be written as
0,1,2, … - Non-integers SHOULD be written in the same rational syntax used elsewhere in this spec (e.g.,
0+1/3,1+3/4).
4.8.3 Pitch Expression
Single Note:4.8.4 Pitch Format
4.8.5 Duration Format
| Symbol | Name | Relative Value |
|---|---|---|
w | Whole | 4 beats |
h | Half | 2 beats |
q | Quarter | 1 beat |
e | Eighth | 0.5 beats |
s | Sixteenth | 0.25 beats |
t | Thirty-second | 0.125 beats |
x | Sixty-fourth | 0.0625 beats |
. for dotted values
| Symbol | Name | Relative Value |
|---|---|---|
w. | Dotted whole | 6 beats |
h. | Dotted half | 3 beats |
q. | Dotted quarter | 1.5 beats |
e. | Dotted eighth | 0.75 beats |
..
| Symbol | Name | Relative Value |
|---|---|---|
h.. | Double-dotted half | 3.5 beats |
q.. | Double-dotted quarter | 1.75 beats |
4.8.6 Event Properties
4.8.7 Dynamic Values
4.8.8 Articulation Values
4.8.9 Ornament Values
4.8.10 Technique Values (String)
4.8.11 Technique Values (Wind)
4.9 Tuplet Syntax
4.10 Grace Notes
4.11 Spans Section
Spans define relationships between events that cross event boundaries. All span endpoints use UUID references.4.11.1 Reference Format
All span endpoints MUST use stable UUID identifiers:4.11.2 Span Types
| Type | From/To | Description |
|---|---|---|
slur | YES | Phrase marking |
tie | YES | Connects identical pitches |
beam | events list | Connects note flags |
hairpin | YES | Dynamic wedge |
ottava | YES | Octave transposition |
pedal | YES | Piano pedal marking |
trill-span | YES | Extended trill line |
gliss | YES | Glissando line |
cross-beam | events list | Beam across staves |
volta | YES | Ending bracket |
bracket | YES | Analysis/grouping bracket |
line | YES | Generic line (8va, etc.) |
4.12 Cross-Boundary Spans and Envelope Safety
When extracting a Working Set Envelope, spans that cross envelope boundaries MUST be handled according to these rules:4.12.1 Boundary Marking
- Span exits envelope: Any span starting inside and ending outside MUST be included with
:boundary-exit:
- Span enters envelope: Any span starting outside and ending inside MUST be included with
:boundary-entry:
- Span crosses envelope: Any span that starts before and ends after MUST have both markers.
:boundary-entryand:boundary-exitindicate which endpoint UUID lies outside the envelope.- A boundary-marked span MAY reference out-of-envelope event UUIDs at the marked endpoint(s).
- Boundary markers are REQUIRED for any span that would otherwise reference an out-of-envelope event UUID.
4.12.2 Write Protection
Cross-boundary spans are write-protected at their boundary endpoints. On replacement, orchestrators MUST enforce:- Immutable semantic fields:
:from,:to, and any event endpoint lists (e.g.,:eventsfor beams) MUST NOT change. - Allowed modifications: agents MAY change only rendering/editorial properties:
- keys in the
render:*namespace - keys in the
edit:*namespace - keys with
x-prefix
- keys in the
4.13 Directions
4.14 Layout Hints (Optional)
Layout hints are NON-NORMATIVE suggestions for rendering engines.4.15 Alternatives: Ossia, Variants, and Editorials
4.16 Score Structure: Movements
5. Working Set Envelope
5.1 Overview
A Working Set Envelope wraps a bounded MRS-S fragment with context for focused agent operations. The key design principles:- Agents receive valid MRS-S and return valid MRS-S—no second syntax
- Scopes use UUIDs—not measure numbers—for structural stability
- Context rings provide surrounding material at reduced detail
- Scope negotiation enables flexible conversational workflows
5.2 Envelope Structure
5.3 Envelope Fields
5.3.1 Required Fields
| Field | Type | Description |
|---|---|---|
:version | decimal | Envelope version (currently 1.0) |
:scope | scope-spec | UUID-based extraction boundaries |
:content | MRS-S | The actual score fragment (writable) |
5.3.2 Scope Specification
:display-hint—never for structural reference.
5.3.3 Optional Fields
| Field | Type | Description |
|---|---|---|
:source-hash | string | SHA-256 hash for conflict detection |
:context | string | Human-readable task description |
:constraints | list | Validation rules agent must satisfy |
:context-near | context-spec | Adjacent measures at reduced detail |
:context-far | context-spec | Distant measures at further reduced detail |
:synopsis-ref | string | Hash reference to score synopsis |
5.4 Context Rings
Context rings provide graduated detail levels for surrounding material. All context ring content is read-only.5.4.1 Reduction Levels
| Level | Content |
|---|---|
:full | Everything (no reduction) |
:melodic-skeleton | Downbeats, phrase boundaries, structural tones |
:harmonic-rhythm | Chord roots, key changes, bass line |
:structural | Rehearsal marks, tempo changes, texture shifts only |
5.5 Agent Response Format
Agents return a replacement fragment:5.6 Scope Negotiation Protocol
Agents can request scope adjustments when the current scope is insufficient:- Grant: Provide expanded Working Set
- Deny: Return error with reason
- Offer alternative: Suggest different scope
5.7 Self-Containment Principle
Every Working Set Envelope MUST be self-contained: the:content can be parsed and validated independently.
This means:
- Part definitions MUST be included
- Time/key/tempo state at extraction start MUST be declared
- Spans MUST have both endpoints within scope (or be marked with boundary markers)
6. Synopsis Format
6.1 Overview
The Synopsis is a compressed structural view that provides global context without full detail. It is:- Derived: Computed from full MRS-S
- Read-only: Agents cannot modify it
- Lossy by design: Context, not content
6.2 Synopsis Structure
6.3 Synopsis Fields
| Field | Description |
|---|---|
:hash | SHA-256 of the synopsis itself |
:source-hash | SHA-256 of the MRS-S it was derived from |
:structure | Movement/section boundaries |
:parts | Part summary (section, range, transposition) |
:harmonic-spine | Chord progression and key areas |
:thematic-regions | Theme appearances and recurrences |
:density-profile | Texture information by region |
:rehearsal-map | Rehearsal marks with UUID/measure mappings |
6.4 Synopsis Access
Working Set Envelopes reference the synopsis by hash:7. Analytical Overlays
7.1 Overview
Overlays attach analytical metadata to scores. They are:- Typed: Different analysis types have different schemas
- Attributable: Track provenance (author, timestamp)
- Optional: Renderers ignore them; agents can use them
- Separable: Can be recomputed without touching musical content
7.2 Overlay Structure
7.3 Overlay Types
| Type | Content |
|---|---|
harmonic-analysis | Chord symbols, Roman numerals, cadences |
motivic-analysis | Theme definitions and occurrences |
form-analysis | Structural sections |
voice-leading | Part writing analysis |
orchestration | Doubling and texture analysis |
7.4 Overlay Operations
Overlays can be:- Created: Agent analyzes score, produces overlay
- Queried: Agent requests specific overlay
- Merged: Multiple overlays combined
- Recomputed: Overlay regenerated after score changes
8. Data Model
8.1 Overview
MRS-S and Working Set Envelopes serialize the same underlying data model.8.2 Core Entities
8.3 Invariants
- Unique identifiers: No two measures, events, or spans may share a UUID
- Display numbers: Measure numbers must be positive; may have gaps
- Beat bounds: Event beat positions must be ≥ 0 and < measure duration
- Duration sum: Sum of durations in a voice should not exceed measure duration
- Tie pitch match: Tied notes must have identical pitch
- Span validity: Span endpoints must reference existing events by UUID
- Voice consistency: Events in a voice should not overlap temporally
- UUID immutability: Once assigned, an
:idis immutable - Dual positioning: Every event MUST have both
beatand:at - Measure identity: Every measure MUST have
:idand:number
8.4 Temporal Model
MRS uses a dual positioning model: Structural positioning (measure-relative):- Beat 0 is the first beat of the measure
- Beat positions are exact rationals
- Used for human readability
:at— Rational quarter-notes since part start:sec— Seconds since start (if tempo automation)- Used for meter-agnostic reasoning
9. Extract-Replace Protocol
9.1 Overview
The Extract-Replace Protocol defines how to create Working Set Envelopes and apply agent responses.9.2 Extraction (MRS-S → Working Set)
9.2.1 Extraction Parameters
9.2.2 Extraction Algorithm
9.3 Replacement (Working Set → MRS-S)
9.3.1 Replacement Algorithm
9.3.2 Measure Attribute Rules (Determinism)
To keep replacement deterministic and safe for partial scopes:- A
working-set-responseMUST include the target measures by:id. - For any measure replaced,
:idMUST match the source measure:id. - For any measure replaced,
:beat-startMUST match the source value. :numberis a display hint and MAY differ; orchestrators MAY normalize it.- Other measure-level attributes (
:time,:key,:tempo, barlines, etc.) MUST NOT be changed via scoped replacement in v1.0. If provided in the response, they MUST exactly match the source or replacement MUST be rejected.
9.4 Round-Trip Guarantee
For any valid MRS-S document S and extraction parameters P:9.5 Insertion Operations
When agents need to insert new measures:- Assigns
:numbervalues based on position - Updates
:beat-startand:sec-startfor subsequent measures - Preserves all UUID references
10. Agent Operations
10.1 Overview
MRS supports AI-assisted composition through context-aware agent operations. Agents receive Working Set Envelopes with appropriate context and return valid MRS-S fragments.10.2 Task Definition
10.3 Sequential Workflow Model
Composition proceeds through sequential agent operations. Form and structure emerge through the creative process:- Receives current state in Working Set Envelope
- Has context rings for surrounding material
- Has synopsis access for global awareness
- Returns valid MRS-S fragment
- May request scope expansion via negotiation
10.4 Constraint Language
10.5 Validation Pipeline
11. Query Resolution
11.1 Overview
The orchestrator translates human-friendly references to UUIDs. Agents always receive and work with UUIDs.11.2 Query Types
Measure number resolution:11.3 Reverse Resolution
UUID to display information:12. Validation Rules
12.1 Syntax Validation
- Document matches grammar
- All required sections present
- Version is supported
12.2 Structural Validation
| Rule | Severity | Description |
|---|---|---|
| STRUCT-001 | ERROR | Duplicate UUIDs |
| STRUCT-002 | ERROR | Invalid measure numbers (non-positive) |
| STRUCT-003 | ERROR | Invalid beat position |
| STRUCT-004 | ERROR | Reference to non-existent UUID (except boundary-marked span endpoints) |
| STRUCT-005 | ERROR | Missing required :id or :at |
| STRUCT-006 | WARNING | Gap in measure numbering |
| STRUCT-007 | WARNING | Empty measure |
12.3 Musical Validation
| Rule | Severity | Description |
|---|---|---|
| MUSIC-001 | ERROR | Tie connects different pitches |
| MUSIC-002 | ERROR | Duration overflow |
| MUSIC-003 | WARNING | Extreme pitch |
| MUSIC-004 | WARNING | Parallel fifths/octaves |
| MUSIC-005 | WARNING | Voice crossing |
| MUSIC-006 | WARNING | Large melodic leap |
12.4 Span Validation
| Rule | Severity | Description |
|---|---|---|
| SPAN-001 | ERROR | Span references non-existent UUID |
| SPAN-002 | ERROR | Slur from/to identical |
| SPAN-003 | WARNING | Slur spans more than 8 measures |
| SPAN-004 | WARNING | Overlapping slurs |
| SPAN-005 | FATAL | Boundary-anchored span endpoint modified |
13. Extension Mechanisms
13.1 Custom Properties
Events, spans, and directions support custom properties withx- prefix:
13.2 Namespace Extensions
| Namespace | Purpose |
|---|---|
x-* | Unregistered extensions |
analysis:* | Music theory analysis |
mei:* | MEI compatibility |
midi:* | MIDI-specific data |
render:* | Rendering hints |
edit:* | Editorial metadata |
14. MIME Types and File Extensions
14.1 MIME Types
| Format | MIME Type |
|---|---|
| MRS-S | application/vnd.mrs+sexpr |
| Working Set Envelope / Response | application/vnd.mrs-work+sexpr |
14.2 File Extensions
| Format | Extension |
|---|---|
| MRS-S | .mrs or .mrs-s |
| Working Set Envelope | .mrs-work (typically ephemeral) |
14.3 Encoding
MRS documents MUST be encoded in UTF-8. BOM SHOULD NOT be used.15. Security Considerations
15.1 Input Validation
Parsers MUST validate:- Maximum document size
- Maximum nesting depth
- Maximum event count per measure
- Valid Unicode in strings
15.2 Denial of Service Protection
Implementations SHOULD protect against:- Deeply nested structures
- Very large measure numbers
- Excessive span counts
- Malformed UTF-8
15.3 Information Disclosure
Working Set Envelopes may expose:- Source document structure
- Source document hash
- Creator/modifier identity
Appendix A: Complete Grammar
A.1 MRS-S Key Productions
A.2 Working Set Envelope Key Productions
Appendix B: Quick Reference
B.1 Duration Codes
| Code | Duration | Beats |
|---|---|---|
w | Whole | 4 |
h | Half | 2 |
q | Quarter | 1 |
e | Eighth | 0.5 |
s | Sixteenth | 0.25 |
t | 32nd | 0.125 |
B.2 Required Event Properties
| Property | Description |
|---|---|
:id | Stable UUIDv7 identifier |
:at | Absolute beat position |
B.3 Required Measure Properties
| Property | Description |
|---|---|
:id | Stable UUIDv7 identifier |
:number | Display number (human navigation) |
:beat-start | Absolute beat position |
Appendix C: Comparison with Existing Formats
| Aspect | MRS-S | MusicXML | ABC | LilyPond |
|---|---|---|---|---|
| Syntax | S-expression | XML | Custom | Custom |
| Formal grammar | Yes | Yes (XSD) | Partial | No |
| UUID identifiers | Yes | No | No | No |
| Context-aware extraction | Yes | No | No | No |
| Agent-friendly | Yes | No | Partial | No |
| Semantic precision | High | High | Low | Medium |
Appendix D: Glossary
| Term | Definition |
|---|---|
| Agent | An AI system that operates on MRS documents |
| Context Ring | Surrounding material at reduced detail |
| Event | An atomic musical occurrence with UUID identity |
| Measure | A metrical unit with UUID identity |
| Orchestrator | System coordinating agents and the full score |
| Overlay | Analytical metadata attached to score regions |
| Scope | UUID-based boundaries of a Working Set |
| Synopsis | Compressed structural view of the full score |
| Working Set | A subset of a score extracted for editing |
End of Specification