Fwd: Unique ids in MusicXML 3.1 and beyond

> Begin forwarded message:
> 
> From: James Sutton <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>
> 
> 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
>