Re: element UIDs in MusicXML 3.1?

Hi Jeremy,

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


> 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 <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 <mailto: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.dolphin-com.co.uk/>
> http://www.seescore.co.uk <http://www.dolphin-com.co.uk/>
> 
> 
> 

Received on Tuesday, 2 August 2016 20:08:26 UTC