Re: element UIDs in MusicXML 3.1?

Hi James,
I think that bookmarks and IDs are semantically distinct. If you can use
Michael's bookmark idea to implement your solution without modifying the
underlying MusicXML schema, then that is probably your preferred solution.

However, I still think IDs should be added to every element. Here is my
rationale:
- IDs typically exist on every element in other markup languages, including
HTML and SVG

- I don't personally see the benefit of having IDs on only some elements.
HTML and SVG have optional IDs on every element. For example, I use IDs on
<div> elements all the time, but I have never had to use an ID on a <bdo>
element. However, it's there if I need it.

- Having IDs may make DOM manipulation easier through the use of standard
DOM APIs. See Joe Berkovitz's MusicXML demo from the W3C meeting at
Musikmesse.

- Also, at the W3C meeting at Musikmesse, we discussed using CSS or a
CSS-like styling language. Having IDs would allow certain elements to be
styled. This is not an immediate goal, and we may never reach this state,
but having the IDs in place would make this transition easier if we decide
to go this route.

- I don't know how much IEEE 1599 is adopted, but if we add IDs, then it
could increase MusicXML adoption into this standard as Luca suggests. I
will defer this to Luca.

That's just my opinion. I'm hope that the bookmark solution that Michael
proposed is able to meet your specifications.

J. Sawruk

On Wed, Aug 3, 2016 at 5:46 AM, James Sutton <jsutton@dolphin-com.co.uk>
wrote:

> Hi Michael,
>
> Thank you for bringing this to my attention. I see now how the bookmark is
> meant to be used, and I think that in principle it could be used for what
> is needed, though I forsee difficulties.
>
> I guess the motivation for doing it this way is to avoid adding ids into
> hundreds of elements, but unfortunately it could be rather complicated to
> use in practice, with rich potential for errors due to non-locality. For
> instance if a non-bookmark-savvy app edits a file containing bookmarks but
> preserves existing elements which it doesn't use (the normal correct
> behaviour) then it will very likely break bookmarks unwittingly. If the ids
> were in the actual elements to which they apply then it would still be
> correct after the edit.
>
> Certainly the local id wouldn't need to be added to all elements -
> just <bar>, <key>, <time>, <clef>, <note>, <lyric>, <barline>,
> <notations>-daughter (15) and <direction-type> (22) should suffice - a
> total of 44 elements - less than the number of nested "print-style" elements
>
> with best regards
> James Sutton
> Dolphin Computing
> http://www.dolphin-com.co.uk
> http://www.seescore.co.uk <http://www.dolphin-com.co.uk>
>
>
>
> On 2 Aug 2016, at 21:26, Michael Good <mgood@makemusic.com> wrote:
>
> Hi James,
>
> Thank you for this suggestion. I think we already handle these cases in
> MusicXML 3.0, but with a somewhat different solution.
>
> Would it work for you to add bookmark elements where you need them? The
> bookmark element has a required id attribute, and allows you to specify
> where in the next element the bookmark should go. It seems to me it should
> be able to handle all the cases you mentioned. The bookmark and link
> elements can also be used to cross-reference material within a compressed
> .mxl file.
>
> I could very easily be missing or misunderstanding something. If this
> doesn't work for your needs, could you please elaborate on what is missing?
>
> Best regards,
>
> Michael Good
> VP of MusicXML Technologies
> MakeMusic, Inc.
>
> On Aug 2, 2016, at 1:05 PM, James Sutton <jsutton@dolphin-com.co.uk>
> wrote:
>
> Hi Jeremy,
>
> comments inline..
>
> James Sutton
> Dolphin Computing
> http://www.dolphin-com.co.uk
> http://www.seescore.co.uk <http://www.dolphin-com.co.uk/>
>
>
>
> On 2 Aug 2016, at 20:30, Jeremy Sawruk <jeremy.sawruk@gmail.com> wrote:
>
> Hi James,
> I think MusicXML should follow the analogy employed by HTML:
> - All elements may have an ID attribute
> - All ID attributes are optional
> - The ID attribute must be an ID type (i.e. it can only be used once per
> document. See:
> https://www.w3.org/TR/2008/REC-xml-20081126/#sec-attribute-types)
>
>
> This sounds fine
>
> I don't think any MusicXML client should be expected to generate IDs.
>
>
> No but those who want to use them *can* generate them if they are
> permitted in the schema.
>
> I can see how they could be helpful in certain scenarios. For example, I
> assume that you're trying to use a DOM API method like getElementById to
> make DOM manipulation easier.
>
>
> We are not using a DOM, we just need to identify any element either for
> edit or for other markup.
>
>
> Alternatively, we could leave the specification as is. Your client could
> internally generate IDs on file load, then remove the IDs on file
> save/export. This would allow you to use IDs within your client without
> having to modify the MusicXML schema
>
>
> We need to store the IDs in the document and MusicXML is our document
> format. There are many advantages to being able to identify individual
> elements in a stored document. For example:
>
> 1. Store a set of annotations for a conductor and for each user and merge
> them as required into a single source document so each user sees his own
> annotations + the conductors  but uses the same source document, which can
> even be edited, and everything will continue to work.
>
> 2. Store other information in another file for which there is no
> identified element in the MusicXML such as bounding boxes where the xml is
> generated from an image
>
> These are 2 examples, and I'm sure there are others, which require UIDs on
> elements. The only way currently to handle these cases is by defining a
> non-MusicXML document format. However we would prefer to contiinue to use
> MusicXML as our document format
>
>
> .
>
> J. Sawruk
>
> On Tue, Aug 2, 2016 at 1:51 PM, James Sutton <jsutton@dolphin-com.co.uk>
> wrote:
>
>> Hello all MusicXML Users,
>>
>> I wonder if it would be possible to add optional UID fields to the major
>> elements in MusicXML 3.1, especially <note>, <direction-type>, and all the
>> daughters of <notation> in MusicXML 3.1. A simple optional attribute <...
>> id="12345"> is all that is required
>>
>> This would give us a huge boost, allowing transformations to scores, and
>> annotations which can be overlaid, things which at the moment are next to
>> impossible because notes etc. cannot be uniquely identified in a a changing
>> score
>>
>> I know the dangers of spec creep but it seems this could be added very
>> simply, with a very big payoff for those of us using MusicXML as a
>> first-class document.
>>
>> Any thoughts?
>>
>> with best regards
>> James Sutton
>> Dolphin Computing
>> http://www.dolphin-com.co.uk
>> http://www.seescore.co.uk <http://www.dolphin-com.co.uk/>
>>
>>
>>
>>
>
>
>
>