Re: Unique ids in MusicXML 3.1 and beyond

I have opened MusicXML issue #235 for this topic at https://github.com/w3c/musicxml/issues/235 <https://github.com/w3c/musicxml/issues/235>. I have referenced this thread and quoted summary information from James’s initial post and Joe’s replies.

Please continue further discussion there. I believe we are all in agreement that this issue does not need to hold up the release of MusicXML 3.1.

Best regards,

Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.

> On Sep 11, 2017, at 10:48 AM, Joe Berkovitz <joe@noteflight.com> wrote:
> 
> Hi James,
> 
> Standards should only properly "suggest" practices insofar as they make implementations work better (e.g. reduce memory usage or increase speed). But interoperability is kind of a binary thing. If the purpose is interoperability, standards have to take a more definite, normative position. And this is where the rubber hits the road: we can't adopt a definite position that would be at odds with the XML standard, just because it is more convenient for some developers.
> 
> Since xml:id works the way it does, the recourse is indeed to throw the ones in an incoming document away, and generate new ones. This is not an uncommon thing to see in the XML world, though, and it's perfectly safe since (thanks to the opacity of ID structure) you can be very sure that no other application cares what ID yours assigned to some element. That's what most applications will probably do.
> 
> .            .       .    .  . ...Joe
> 
> Joe Berkovitz
> Founder
> Noteflight LLC
> 
> 49R Day Street
> Somerville MA 02144
> USA
> 
> "Bring music to life"
> www.noteflight.com <http://www.noteflight.com/>
> 
> On Mon, Sep 11, 2017 at 1:13 PM, James Sutton <jsutton@dolphin-com.co.uk <mailto:jsutton@dolphin-com.co.uk>> wrote:
> 
>> Begin forwarded message:
>> 
>> From: James Sutton <jsutton@dolphin-com.co.uk <mailto:jsutton@dolphin-com.co.uk>>
>> Subject: Re: Unique ids in MusicXML 3.1 and beyond
>> Date: 11 September 2017 at 18:05:57 BST
>> To: Joe Berkovitz <joe@noteflight.com <mailto:joe@noteflight.com>>
>> 
>> 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 11 Sep 2017, at 17:43, Joe Berkovitz <joe@noteflight.com <mailto:joe@noteflight.com>> wrote:
>>> 
>>> Hi all,
>>> 
>>> The co-chairs just discussed this question on our call this morning. Here are our thoughts:
>>> 
>> ..
>> 
>>> - The chairs are in agreement that, as per the XML ID spec https://www.w3.org/TR/xml-id/ <https://www.w3.org/TR/xml-id/>, the only "interoperable" aspect of xml:id is its uniqueness within a document. We're not allowed to impose special syntactic constraints, or assign domain-specific semantics to the actual content of the ID, so we consider it closed for MusicXML 3.1. An xml:id must be an opaque label, and no more. 
>>> 
>>> - In line with Jeremy Sawruk's last reply, we're not able to think of any application functionality that is prevented by letting applications choose IDs according to any scheme they like. Applications can always remap both ID declarations and ID references in an incoming document to any desired internal scheme, without any perceivable effect to the end user. The sole function of the ID is to resolve a reference to some object, and that is all. It does not matter if an element is labeled "measure1" or "MyAuntFlossie".
>> 
>> Sorry I did not post my reply to Jeremy to the group. I've forwarded it now
>> 
>> The main problem here is that if a new element is added to a document containing ids which follow an unknown pattern it is not simple to generate a new unique id. The only sane solution is to throw away all the existing ids and generate new ones which fit the known scheme.
>> 
>> A secondary issue is that numbers are easier to handle than strings. Any scheme involving unique strings requires a (good) hashing function which adds unnecessary complexity, and chances for failure (if the chosen hash function fails to discrimnate).
>> 
>> It seems very little to add to the specification a (perhaps multiple) suggested format(s) for those who wish to use it. It is extremely helpful to know that this aids interoperability - exactly what a specification is for. Without anything we are each forced to invent our own scheme, which is a shame
>> 
> 
>