Re: Unique ids in MusicXML 3.1 and beyond

Hi James and all,

There is a lot of interesting discussion here!

I think the more general issues about addressability are best left to MNX. MNX is indeed currently planning to use classes similar to what Glenn mentions. I would expect id attributes to be useful as well.

The id attributes in MusicXML 3.1 are indeed helpful for several different use cases. My problem is seeing where a guideline that specifies that these unique IDs map directly to unique integers is helpful for those use cases.

Finale for instance would probably not want to generate IDs that correspond to unique integers. Finale has data structures that have their unique ID for each type of data. MusicXML IDs generated by Finale might most meaningfully be constructed by a combination of “what type of data is this” as well as a numeric ID. There also might be several different types of data involved, since a single MusicXML element might correspond to multiple Finale data structures.

I don’t see where that causes a problem though. What difference does it make how a unique ID is formatted as long as it is unique within the document, which any XML validator will check?

With many MusicXML applications, these id attributes will not be preserved on a round trip. MusicXML applications tend to read in a MusicXML file and convert to the application’s underlying data structures. Data that doesn’t fit into the application’s data structures is ignored. When the file is exported it is coming from the application’s internal data, not the original MusicXML file. So many things may change between import and export. Mogens has mentioned this many times, but it seems inherent in how MusicXML is currently used for document interchange.

With MNX we are working on a format that is better suited as a native representation for applications, for use cases that go well beyond document interchange. So the preservation of data across cooperating applications becomes a more interesting issue for exploration there.

Of course there are applications already using MusicXML as a native format, or the basis for a native format. Those applications can define the format of the unique IDs however they wish. But I still don’t understand how a standardized id format would enhance interoperability.

For MusicXML 3.1, the main issue is if there is anything we need to change with these new id attributes before release. I don’t think there is, but I am not confident that I am really understanding what is behind James’s request.

Best regards,

Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.

> On Sep 8, 2017, at 11:28 AM, James Sutton <jsutton@dolphin-com.co.uk> wrote:
> 
> Hold on!
> 
> The only reason that the IDs are in the MusicXML 3.1 standard is because I asked for them!
> 
> Are you saying I have to ask for them again?
> 
> We could just adopt an agreed convention for interoperability. If some program flouts the convention then they are not interoperable and that's their choice
> 
> best regards
> James Sutton
> Dolphin Computing
> http://www.dolphin-com.co.uk <http://www.dolphin-com.co.uk/>
> http://www.seescore.co.uk <http://www.dolphin-com.co.uk/>
> http://www.playscore.co <http://www.dolphin-com.co.uk/>