Re: Unique ids in MusicXML 3.1 and beyond

"The only sane solution is to throw away all the existing ids and generate
new ones"

I'm sorry, but I don't see why doing this is problematic. If you create a
new element and want to assign an ID to it, just generate a new ID. If that
ID is already in use, then generate another one, or choose a method to
generate IDs that would generate fewer collisions.

If program A uses a specific ID scheme (which they certainly can), what
difference does that make to program B? Even if program B followed program
A's convention, there's no guarantee that program A would respect that.

Let's say I have a fragment with two IDs output from program A:
<note id="id-1">...</note>
<note id="id-2">...</note>

I import that into program B, and generate a new ID:
<note id="id-1">...</note>
<note id="id-1.1">...</note>
<note id="id-2">...</note>

If I then export that from B, import it back into A, and export back out,
what will my IDs be? There is no guarantee. It certainly could be:
<note id="id-1">...</note>
<note id="id-2">...</note>
<note id="id-3">...</note>

"It seems very little to add to the specification..." - A small amount of
text may have large repercussions.

Could we please move this conversation to Github as per Joe's
recommendation?


On Mon, Sep 11, 2017 at 1:13 PM, James Sutton <jsutton@dolphin-com.co.uk>
wrote:

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