element ids needed

[jsutdolph]

It would be very useful to allow certain elements in MusicXML to have unique identifiers as an attribute e.g. <note id="123">...</note> This would allow an app to store data associated with a MusicXML score for e.g.

1. Annotations - a set of annotations by one person (director) could be combined with a set of annotations by another person (player) and they could be applied separately to the source file
2. measurement data about visible score features from an OMR program

I suggest useful elements to have the id would be <bar>, <key>, <time>, <clef>, <note>, <lyric>, <barline>, <beam>, <harmony>, <figured-bass>, <transpose>, <sound> <notations>, <tied>,<slur>,<tuplet>,<glissando>,<slide>,<ornaments>,<technical>,<articulations>,<dynamics>,<fermata>,<arpeggiate>,<non-arpeggiate>,<accidental-mark>,<other-notation> <direction>, <direction-type>, <rehearsal>,<segno>,<words>,<coda>,<wedge>,<dynamics>,<dashes>,<bracket>,<pedal>,<metronome>,<octave-shift>,<harp-pedals>,<damp>,<damp-all>,<eyeglasses>,<string-mute>,<scordatura>,<image>,<principal-voice>,<accordion-registration>,<percussion>,<other-direction> <credit>

a total of 52 elements

I don't think that it is necessary to include the id in all the technical and ornament subtypes since there is generally only one thing inside these elements so it can be uniquely identified by an id in the parent. However the articulation element could often contain multiple e.g. a staccato dot and a tenuto at the same time so a case could be made to add the id to all articulations subtypes also:

(<up-bow>,<down-bow>,<harmonic>,<open-string>,<thumb-position>,<fingering>,<pluck>,<double-tongue>,<triple-tongue>,<stopped>,<snap-pizzicato>,<fret>,<string>,<hammer-on>,<pull-off>,<bend>,<tap>,<heel>,<toe>,<fingernails>,<hole>,<arrow>,<handbell>,<other-technical>) i.e. another 24 elements. I do not feel strongly about this and it may not be worth the extra work for a feature which might never be needed

[jsawruk]

You seem to be missing the list of elements that you are suggesting should have IDs.

[jsutdolph]

updated with escaped xml

[mdgood]

To clarify, these would all be optional attributes with a type of xs:ID, correct?

[jsutdolph]

I understand that this would allow "a123", but not "123". Is that correct?

[jsutdolph]

definitely optional yes

[mdgood]

Thanks, James. Yes, you are correct that the xs:ID definition allows "a123" but not "123". This is consistent with all the id attributes currently in MusicXML 3.0.

[jsutdolph]

That's a pity but acceptable. Thank you

[dspreadbury]

This proposal looks good to me!

[mdgood]

I have put this in scope for MusicXML 3.1.

[mdgood]

In looking over the element list I have a few questions and suggestions:

• By <bar> do you mean the <measure> element?
• If we include the <beam> element perhaps we should include the <stem> element too?
• Perhaps we should add other children of the <note> element including <accidental>, <dot>, and <notehead>?
• I would suggest adding the credit element children as well, in parallel to the direction-type child elements. That would add <credit-image>, <credit-words>, and the new <credit-symbol> element.
• Perhaps also add the <frame> and <grouping> elements from the direction.mod file and the <measure-style> element from the attributes.mod file?

My inclination at the moment would be to not add the articulations children. But I could easily be swayed on that, especially if we add the technical and ornament children as well.

[jsutdolph]

1. Oops! Sorry I meant <measure>
2. <stem> <accidental><dot><notehead> The reason I didn't include these is that they are (except accidental) uniquely identified by the id of the note.
3. <credit> children. I don't have any view about these.
4. Good idea, assuming these correspond to the same in musicxml.xsd.
5. apropos articulations - I would prefer to leave these so as to hasten the release.

[mdgood]

Thanks. I will plan to add <credit-image>, <credit-words>, <credit-symbol>, <symbol>, <frame>, <grouping>, and <measure-style> to the initial proposal, and not include the <articulations> child elements.

[mdgood]

I suggest we implement this as follows:

1. Add a new "optional-unique-id" attribute group including the single attribute definition:

   <xs:attributeGroup name="optional-unique-id">
       <xs:annotation>
           <xs:documentation>The optional-unique-id attribute group allows an element to optionally specify an ID that is unique to the entire document. This attribute group is not used for id attributes that are required, or id attributes that specify an id reference.</xs:documentation>
       </xs:annotation>
       <xs:attribute name="id" type="xs:ID"/>
   </xs:attributeGroup>

2. Update the types for the above elements (in @jsutdolph's initial proposal with the updates from the previous 3 replies) to include this attribute group.

3. Consider adding new types that include the optional-unique-id if we find duplication when adding this attribute-group to the different types.

[jsutdolph]

"optional-unique-id" is a very long name! Could significantly increase the size of the file if it's used a lot. Couldn't it be something more economical like "id", "uid" or "oid"?

[mdgood]

James, that is just the name of the attribute group for documentation in the schema file. That name won't appear in any MusicXML files. The actual attribute name is "id", consistent with existing MusicXML usage.

[webern]

I would like to have the ability to "point" a <direction> element at a note. The use case is that, in my application, some directions (wedge, for example) are specifically tied to Notes with pointers, and I would like to represent this in my MusicXML. (Note that we are using MusicXML as a native file format, not just for export.)

So for a direction, I would like an attribute such as note-id="N12387"

[mdgood]

In MusicXML 3.0 this is done by having the direction element precede the note element. Could you please elaborate more on the use case for an additional attribute here?

[webern]

Is it clear in the documentation that a direction should precede the note that it "points" to? Reviewing this now...

[webern]

I think that this should possibly be re-written A direction is a musical indication that is not attached to a specific note.

[mdgood]

Matt, could you please start a new issue for clarifying the direction element documentation? This issue is already a pretty big one, so I would like to keep other things separate for easier tracking. Thanks so much for your review of these issues!

[webern]

I wonder what the point of a NoteID is if I cannot point to it? As an user, I would prefer not to have so much state remembered during my loops.

For example, to know that a direction points to a note I need to remember from my previous loop iteration that I recently encountered a direction and I need to delay my full construction of the direction until later when I encounter its note. What if I encounter a direction followed by a figured-bass then a backup then a forward then a harmony and then a note. Does the direction still apply to the note? When should I complete the construction of direction in the case that it is not followed by a note?

Just for clarification, can anyone explain the use case of a unique ID if it is not being referenced anywhere else in the document?

[mdgood]

James mentioned two use cases when creating this issue. The annotations and measurement data that he describes could be saved in a separate file that could be part of the package in a compressed MusicXML file. Once applications gain more experience with these features, we could have more of a basis for standardization in MNX and/or a future version of MusicXML.

To quote from James's message to the group list on 2 Aug 2016:

1. Store a set of annotations for a conductor and for each user and merge them as required into a single source document so each user sees his own annotations + the conductors but uses the same source document, which can even be edited, and everything will continue to work.

2. Store other information in another file for which there is no identified element in the MusicXML such as bounding boxes where the xml is generated from an image

These are 2 examples, and I'm sure there are others, which require UIDs on elements. The only way currently to handle these cases is by defining a non-MusicXML document format. However we would prefer to contiinue to use MusicXML as our document format

@jsutdolph, @dspreadbury, or anyone else, please correct or elaborate on this if I have missed or misstated something.

[mdgood]

Pull request #175 addresses this issue. I also added id attributes to the <print> and <staff-divide> elements which were not mentioned above.

@jsutdolph, would you have a chance to review it to make sure this is what you are looking for? Of course any other reviews are most welcome as well!