Provide additional guidance for formatting of id attributes

[mdgood]

James Sutton (@jsutdolph) has proposed that we add additional guidance for the formatting of the new id attributes in MusicXML 3.1 added in issue #145. This has been discussed on a mailing list thread at https://lists.w3.org/Archives/Public/public-music-notation-contrib/2017Sep/0008.html. To summarize the request:

In my application I am labelling every editable item in the file (notes, notations, directions etc) with a globally unique integer id so that file edits can be recorded and replayed, allowing users to share musical annotations

If we are looking for interoperability such that one program can read another program's integer ids we will need a standard way to convert between string and integer (ie defining a prefix and integer base), bearing in mind that it is mandated by the standard for (https://www.w3.org/TR/xml-id/) that the xml:id must start with a non-numeric character. I propose the prefix "uid" followed by a hex integer eg "uid9ab".

It is not immediately obvious that 2 programs developed in isolation will need to access each other's uids in most cases, but it is not unimaginable that certain applications will find a use for this interoperation.

One main concern is how application A could add a new id to a file created by application B without redoing all of application B's id attributes.

This is something that could be addressed after the MusicXML 3.1 release as a sort of recommended practice which could be standardized later if desired.

[mdgood]

To summarize from @joeberkovitz's replies on the mailing list:

The chairs are in agreement that, as per the XML ID spec https://www.w3.org/TR/xml-id/, the only "interoperable" aspect of xml:id is its uniqueness within a document. We're not allowed to impose special syntactic constraints, or assign domain-specific semantics to the actual content of the ID, so we consider it closed for MusicXML 3.1. An xml:id must be an opaque label, and no more.

Standards should only properly "suggest" practices insofar as they make implementations work better (e.g. reduce memory usage or increase speed). But interoperability is kind of a binary thing. If the purpose is interoperability, standards have to take a more definite, normative position. And this is where the rubber hits the road: we can't adopt a definite position that would be at odds with the XML standard, just because it is more convenient for some developers.

Since xml:id works the way it does, the recourse is indeed to throw the ones in an incoming document away, and generate new ones. This is not an uncommon thing to see in the XML world, though, and it's perfectly safe since (thanks to the opacity of ID structure) you can be very sure that no other application cares what ID yours assigned to some element. That's what most applications will probably do.

[jsutdolph]

This is an acceptable solution.
Thanks for considering this option

[jsawruk]

If applications need additional semantics beyond those provided by xml:id, and would like to interoperate through such a convention, then I would recommend an approach similar to HTML 5 data-* attributes.

For example:

<note id="a-valid-xml-id" data-music-id="note-0001">

This would then be a specific microformat, which could be standardized or agreed upon.

Note that data-music-id is just a placeholder; we could have an attribute of any name to store additional metadata like this. I just used this name to conform to the HTML5 data-* convention.

[jsutdolph]

that's interesting. Something to consider for MusicXML 3.2?

[joeberkovitz]

At the moment there is no plan for a MusicXML 3.2, but this approach will definitely be considered for MNX. I like the data- attribute scheme, which is used both in HTML and SVG.

[joeberkovitz]

One thing about data- attributes: they're great for exposing custom information from an application, but I don't know that there's a precedent for requiring applications to preserve this information across a round trip.

This sort of round-tripping might require the application to maintain an internal data model that corresponds in a 1:1 sense to the document schema, which seems like a large potential implementation barrier.

[Glenn-smufl]

Yes, data- attributes seem to be a good solution for this issue. Whether an application chooses to preserve them is up to it, but it certainly can be a "recommended best practice" to preserve such: I would certainly approve of language that would indicate that it is a best practice to preserve data- attributes, both those created and understood by an application, and those discovered and not understood in imported files. That is said with understanding that it could be an implementation barrier to a greater or lesser degree for various applications.

Applications that don't understand (and therefore delete) particular musical notation, would not be expected to preserve the data- attributes for that notation either, but for any notation that they do understand and re-export, preserving any imported data- attributes in the exported file would be a best practice.

[ahankinson]

It's will also be difficult to write a DTD, W3Schema, or RelaxNG schema validator for these attributes.

See: https://www.oxygenxml.com/forum/topic7698.html

[jsawruk]

@ahankinson: That's a good point about difficulty with writing a schema validator. Maybe instead of allowing data-*, we could just use a prefix (like data- or music-) for any of the attributes that we would need for the cases discussed in this issue.