Re: Unique ids in MusicXML 3.1 and beyond

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

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