Re: Unique ids in MusicXML 3.1 and beyond

Hi Michael and all,

comments inline..

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/>


> On 8 Sep 2017, at 19:54, Michael Good <mgood@makemusic.com> wrote:
> 
> Hi James and all,
> 
> 
...

> 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?

Not true. CodeSynthesis xsd/e (which SeeScore uses) does not check this. This is a sensible approach as it can be expensive (time and space) to check in the general case, especially for applications which don't care

> 
> 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.

yes

> 
> 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.

ok, but I am sure we are all apprehensive about the huge pile of work to adopt MNX! Even more for those of us where MusicXML is the document format.

> 
> 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.

numbers are cheap for the sort of processing needed for uids. It is a natural choice. However if one program uses 1,2,3.. for ids and another uses "a", "b", "c".. another uses decimal numbers, another uses hex, and another uses "part1-bar1" how can they interoperate in their use of the id?
In particular, if you edit the file, add an annotation say,  how can the editor generate a new uid in a file which uses different standards? The only possibility is to regenerate all the ids in the file using the standard that the editor uses, notwithstanding strictures from Johannes ;-).
If simple numbers are not seen as a good choice then we could agree some other, but anything involving the index of the item in the file/part/measure does not work as these could not be invariant on file change.

> 
> 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.
> 

Nothing needs to change as far as I am concerned.
If you need more info we could go off this thread