Re: Unique ids in MusicXML 3.1 and beyond

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




> On 8 Sep 2017, at 19:16, Glenn Linderman <v+smufl@g.nevcal.com> wrote:
> 
> On 9/8/2017 10:33 AM, James Sutton wrote:
>> Hi Andrew,
>> 
>> I think you misunderstand my point.
>> 
>> The ema address, as I understand it, addresses a measure by index. If I remove a measure before the addressed one then the same address points to a different measure. This is a problem. I want an address to stay valid however I modify the document. For this I need an invariant uid for each measure
>> 
>> Apropos:
>> If an application would change my IDs without being instructed to do so, that would be the last time for me to use that application… 
>> 
>> If we all use the same convention then we can use the same ids. If not then we cannot since the id is a limited resource (only one is permittted per item), 
>> We have come back to my original point.
> 
> On 9/8/2017 10:39 AM, Andrew Hankinson wrote:
> 
>> It only addresses a measure by index insofar as musicians themselves address it by index ("We're starting from Measure 13"). If you remove a measure from a work, then (arguably) it's not the same work.:)
> 
> Issue: there is only one ID per item. James' wants to use it for a unique, invariant identifier for the item.  By definition, it has to be unique, so there is a correlation between his desired usage, and the definition of an ID. He wants to have a convention to solidify that correlation.  However, other people/software may wish to assign IDs for other valid purposes... but there can only be one. Hence, by choosing to use ID for s unique, invariant identifier, James is setting himself up for interoperability failure: there may eventually be much software that uses IDs for other purposes, that James would use at most once.  Hence, James should find a different mechanism for including his unique, invariant identifier with each item. If there is no different mechanism that can be used, then James should propose the addition of such a mechanism, that, unlike ID, would not be restricted to one instance, so that if James' software wishes to add a value using that mechanism, that doing so would not inhibit the use of that mechanism being used by other software as well.
> 
> For example, in HTML, the ID must be unique, but CLASS need not be.  So James could add a CLASS to each item with a special prefix "James-unique-invariant-identifier-NNNNNNNN" and it would not preclude other uses of CLASS, and could be preserved by software that knows nothing about James or his software, although if that software adds new items, James' software might not be able to address those new items until James' software reads the new version, discovers items without the identifier, and assigns appropriate identifiers to those items.
> 
> I don't know if MNX or MusicXML has the concept of CLASS like HTML does, but some similar mechanism may exist, or maybe should be added.
> 
> EMA is interesting and useful for some use cases, and can address items in the same work, even if they have some kinds of variations, but cannot handle all types of variations or derived works, so is insufficient for all of James' use cases.
> 
> Indeed, if cross-references are to be used from one document to another, a concept like James proposes is almost necessary, if the documents can be processed independently.  If there is no ability to process them independently, then I would question if they should be separate documents.
> 
> Glenn