Re: Unique ids in MusicXML 3.1 and beyond

Wouldn't it be the responsibility of the software to update bars[B].parts[P]?
That is, the client software should have code that handles object
insertion, deletion, reordering, etc.

An ID in XML is not meant to be used as a pointer. You should instead have
a pointer to that ID, and that pointer should be updated if the DOM changes
(even though the ID itself has the same value).

It's a very subtle point, but I think it's an important one.

On Fri, Sep 8, 2017 at 1:09 PM, James Sutton <jsutton@dolphin-com.co.uk>
wrote:

> Hi Adrian,
>
> To clarify the original point, the uid is just like a unique address for
> each item in a score, so any document external to the MusicXML can
> unambiguously refer to any item in the score, even when the score is
> changed, until the item is deleted
>
> The problem with bars[B].parts[P]... as an address is that it is not
> robust in the face of modifications to the XML. ie if you add a part or a
> bar then indices B and P do not point to the same place, and you normally
> cannot detect the failure!
> However if you use global uids they remain valid until the target object
> is deleted, and then you can detect when it has failed, as long as ids are
> never reallocated. (An interesting problem is how to ensure that.)
>
> James Sutton
> Dolphin Computing
> 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 15:28, Adrian Holovaty <adrian@holovaty.com> wrote:
>
> On Fri, Sep 8, 2017 at 4:01 PM, James Sutton <jsutton@dolphin-com.co.uk>
> wrote:
>
>> Here is a couple of cases:
>>
>> 1. If any program (eg OMR engine) needs to output non-MusicXML
>> information (eg bounding-boxes of items)  then it could be passed via
>> another channel (XML, JSON, text, ..), cross-referencing by uid
>>
>> 2. a) If a conductor taps a note on her tablet, the note could be
>> highlighted on all the players' tablets by passing a uid. The MusicXML
>> might be generated by a completely independent program which outputs uids.
>>
>> b)  the note might be changed, or a notation might be removed or corrected
>>
>> This does open a general way of referring to elements in a MusicXML file
>> and for passing any information about elements which is not catered for in
>> the MusicXML format.
>>
>
> For these use cases, it would be nice to have a general "selector" API for
> music notation in general — not just MusicXML, but any symbolic common
> Western notation across any app.
>
> Joe has brought up this idea in the past, and I think it's a great one.
> Imagine something like this, to select the second beat of the first voice
> in the first bar of the first part:
>
>     bars[0].parts[0].voices[0].beats[1]
>
> It seems inelegant to shoehorn such a thing into MusicXML via a change to
> the way IDs work, but I admit I don't understand your original proposal,
> despite having read it a few times. :-/
>
> Adrian
>
> --
> Adrian Holovaty
> Soundslice: https://www.soundslice.com/
> Personal: http://www.holovaty.com/
>
>
>