Re: Unique ids in MusicXML 3.1 and beyond

Jeremy,

But what if the address needs to have its own independent existence? May I remind you we are talking about interoperability between different programs?

If they build a new house in my street, they do not (normally) change my house number, so I can still receive mail at the same address.

You say:
"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)."

This is new to me. Why can't we use an id as a pointer? How do we point to an id? Can you give me a reference/link to this rule and its explanation? Incidently I am not using a DOM.


Andrew,

If I am the composer I might decide to add some bars before the fugue. Ok it's not exactly the same work, but it might be really convenient if I can address the same measure without changing the address. It is certainly inconvenient if I think I am addressing the same measure but it's not!
Rehearsal marks (A, B, etc) are the same idea. You can add or remove bars and the rehearsal mark is still at the same bit of music, even though the bar number might have changed.


Summary
I need an unchanging unique address for each editable item in a file, and I need to be able to modify the file and still address the same entity with the same address. Anything like ema or bars[N].notes[M] will definitely not work. Is there a problem?

Can somebody object if this discussion is too noisy for the public mail list?

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



> On 8 Sep 2017, at 18:36, Jeremy Sawruk <jeremy.sawruk@gmail.com> wrote:
> 
> 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 <mailto: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.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 <mailto:adrian@holovaty.com>> wrote:
>> 
>> On Fri, Sep 8, 2017 at 4:01 PM, James Sutton <jsutton@dolphin-com.co.uk <mailto: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/ <https://www.soundslice.com/>
>> Personal: http://www.holovaty.com/ <http://www.holovaty.com/>
>