Re: Unique ids in MusicXML 3.1 and beyond

When I said "a standard way" I really meant a convention.
If we make it a standard then it prevents all sorts of useful ways of using the id as Jeremy says. That was not what I intended.
However perhaps some words could be added to the standard to tie down how they might be conventionally used to express a (non-negative) integer value? 

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




> On 8 Sep 2017, at 14:10, Jeremy Sawruk <jeremy.sawruk@gmail.com> wrote:
> 
> Hi Janina,
> I am genuinely curious, how would specifying additional semantic structure on xml:id "maximize the accessibility of the new protocol"?
> 
> There are many ways that IDs could be constructed. As James said, they could be based on partial or full UUIDs, or they could be constructed in another way, such as "noteXXX".
> 
> Please note that IDs are used in places other than just the MusicXML/MNX file. IDs can also be used in stylesheets and/or code that accesses the DOM. As a developer, I want to make sure that any ID that I create is readable in all situations so that I can debug my code earlier. James' suggestion would seem to make IDs more readable, but I am concerned that, by creating a more restrictive standard, we are limiting the ability for developers to work with code in whatever way THEY see fit rather than how WE see fit.
> 
> For example, James gives an example ID of "uid9ab". Software that imports/exports MusicXML/MNX would have no problem with that, but as a developer, I find that difficult to read. Let's say I have developed a browser-based renderer and am trying to debug it. Something is not rendering correctly, so I want to write code that specifically gets that element from the DOM. If we followed the stricter rules that James is proposing, I couldn't go in and modify my source MusicXML/MNX file so that the ID is something more meaningful to me as a developer at the moment, such as "#note-that-wont-render". 
> 
> I would think that DOM manipulation code would also be easier to utilize when using the less restrictive xml:id as opposed to James' proposal. I would much rather debug:
> 
> var x = document.getElementById("note-that-wont-render");
> 
> than
> 
> var x = document.getElementById("uid9ab");
> 
> Again, I do not think James' idea is bad. This is one of the few times where I agree with him. It could be a useful convention for software to follow, but I don't think it belongs in the standard. I hope the above explains my point of view.
> 
> J. Sawruk
> 
> On Fri, Sep 8, 2017 at 8:14 AM, Janina Sajka <janina@rednote.net <mailto:janina@rednote.net>> wrote:
> Hello:
> 
> I've been quietly lurking on list for some months now--since last TPAC.
> 
> I want to now voice support for an approach such as is outlined below.
> Something like this is important to maximize the accessibility of the
> new protocol. I strongly support the approach.
> 
> 
> Janina
> 
> James Sutton writes:
> > Hi all,
> >
> > The sample MusicXML files use ids for cross-referencing items in the file - eg parts "P1" and instruments "P1-I3".
> >
> > In my application I am labelling every editable item in the file (notes, notations, directions etc) with a globally unique integer id so that file edits can be recorded and replayed, allowing users to share musical annotations
> >
> > If we are looking for interoperability such that one program can read another program's integer ids we will need a standard way to convert between string and integer (ie defining a prefix and integer base), bearing in mind that it is mandated by the standard for (https://www.w3.org/TR/xml-id/ <https://www.w3.org/TR/xml-id/>) that the xml:id must start with a non-numeric character.  I propose the prefix "uid" followed by a hex integer eg "uid9ab".
> >
> > It is not immediately obvious that 2 programs developed in isolation will need to access each other's uids in most cases, but it is not unimaginable that certain applications will find a use for this interoperation.
> >
> > Does the group have any view on this?
> >
> > with best regards
> > James Sutton
> > Dolphin Computing
> > http://www.dolphin-com.co.uk <http://www.dolphin-com.co.uk/> <http://www.dolphin-com.co.uk/ <http://www.dolphin-com.co.uk/>>
> > http://www.seescore.co.uk <http://www.seescore.co.uk/> <http://www.dolphin-com.co.uk/ <http://www.dolphin-com.co.uk/>>
> > http://www.playscore.co <http://www.playscore.co/> <http://www.dolphin-com.co.uk/ <http://www.dolphin-com.co.uk/>>
> 
> --
> 
> Janina Sajka,   Phone:  +1.443.300.2200 <tel:%2B1.443.300.2200>
>                         sip:janina@asterisk.rednote.net <mailto:sip%3Ajanina@asterisk.rednote.net>
>                 Email:  janina@rednote.net <mailto:janina@rednote.net>
> 
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org <http://a11y.org/>
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair, Accessible Platform Architectures        http://www.w3.org/wai/apa <http://www.w3.org/wai/apa>
> 
> 
>