Re: Unique ids in MusicXML 3.1 and beyond

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