Re: element UIDs in MusicXML 3.1?

A good candidate, yes, but we are hoping to be more explicit.  Once we can
tag notes with ID's then I will be tempted to stick my NoteID in some
lesser-known, usually unused place like <sound elevation="0.123254"/> where
123254 is my NoteID (or a numeric representation of it).  So I guess I have
a workaround.

I should mention that we are using MusicXML as our native application file
format, so it's not about exchanging with other programs, it's about fully
representing the state of our object model in our applications files.

Thanks.
Matt


..mjb


On Fri, Dec 9, 2016 at 10:16 AM, James Sutton <jsutton@dolphin-com.co.uk>
wrote:

> Hi Matt
>
> The following note (or chord) in the MusicXML file is probably a good
> candidate for a <direction-type> attachment without needing any other
> elements.
>
> 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 9 Dec 2016, at 17:20, Matthew James Briggs <matthew.james.briggs@gmail.
> com> wrote:
>
> I'm sorry if this has already been addressed in the thread, but it would
> be ideal if <direction-type> could have an attribute to "point to" a note
> using the note's uid.  Is that the intention?  This is something that we
> need here as well as we want wedges (and other direction types) to attach
> to notes.
>
> Thanks.
> Matt
>
>
> .mjb
>
>
> On Wed, Dec 7, 2016 at 3:02 AM, James Sutton <jsutton@dolphin-com.co.uk>
> wrote:
>
>> Thanks Michael,
>>
>> We are hoping for an early 2017 release for this if possible as we have
>> immediate need for it.
>>
>> 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 6 Dec 2016, at 22:10, Michael Good <mgood@makemusic.com> wrote:
>>
>> Thanks to James for proposing this addition to MusicXML 3.1, and for
>> writing it up in GitHub as issue 145 at https://github.com/w3c/musi
>> cxml/issues/145.
>>
>> I would like to add this to the scope of MusicXML 3.1 as I think James,
>> Luca, Anthony, and others have made compelling arguments for its inclusion.
>> There are several real-life application scenarios that we can make easier
>> and more robust by adding this feature now, rather than waiting for a more
>> universal solution with MNX.
>>
>> Best regards,
>>
>> Michael Good
>> VP of MusicXML Technologies
>> MakeMusic, Inc.
>>
>> On Sep 20, 2016, at 9:04 AM, Michael Good <mgood@makemusic.com> wrote:
>>
>> Hi Joe, James, and all,
>>
>> James is correct that you cannot just add xml:id attributes into MusicXML
>> 3.0 documents and have them still be valid. While the xml:id attribute is
>> referenced in the xml.xsd schema that is part of MusicXML 3.0, it is never
>> used in the MusicXML schema. The xml.xsd schema is there so that MusicXML
>> 3.0 can use the xml:lang and xml:space attributes in other areas such as
>> the text-formatting attribute group.
>>
>> James, could you please write up an issue for this at GitHub at
>> https://github.com/w3c/musicxml/issues? As long as we keep to your
>> original proposal of adding this as an optional attribute to the 44 key
>> elements you listed, there won't be any conflicts with the existing use of
>> id as an IDREF in about 5 other elements. I would like to keep this as an
>> unqualified id attribute for now, rather than using xml:id.
>>
>> Thomas's suggestion of using xml:id is a promising way at approaching a
>> universal solution in MusicXML 3.1. But I think the issue of having each
>> element have a unique ID is something that might be best saved for MNX. The
>> partial solution that James suggests seems like it handles several good use
>> cases even if it is not universal, and should cause no confusion with
>> existing MusicXML 3.0 features.
>>
>> I would be happy to have that issue in scope for V3.1 if people think
>> that would be useful, and not cause issues with forthcoming MNX work.
>>
>> Best regards,
>>
>> Michael Good
>> VP of MusicXML Technologies
>> MakeMusic, Inc.
>>
>> On Sep 20, 2016, at 3:34 AM, Joe Berkovitz <joe@noteflight.com> wrote:
>>
>> Hi James.
>>
>> I do not have any expertise with using xml:id in validating parsers -- it
>> seems like a feasible idea, but perhaps real-world support for it is
>> lacking. Although it's technically not necessary, you might be able to
>> define the xml namespace explicitly in the root element of the document
>> using the attribute xmlns:xml="http://www.w3.org/XML/1998/namespace"
>>
>> In the forthcoming MNX proposal we will address element ids in a uniform
>> way that does not require use of the xml namespace, although unfortunately
>> that doesn't help you now.
>>
>> Best,
>>
>> .            .       .    .  . ...Joe
>>
>> Joe Berkovitz
>> President
>> Noteflight LLC
>>
>> +1 978 314 6271 <(978)%20314-6271>
>>
>> 49R Day Street
>> Somerville MA 02144
>> USA
>>
>> "Bring music to life"
>> www.noteflight.com
>>
>> On Tue, Sep 20, 2016 at 3:54 AM, James Sutton <jsutton@dolphin-com.co.uk>
>> wrote:
>>
>>> Hi Joe and other XML experts,
>>>
>>> The validating parser which I use (CodeSynthesis xsd/e) does not allow
>>> addition of xml:id attributes into arbitrary MusicXML elements. The
>>> designer of this parser says that the attribute need to be explicitly
>>> defined in elements (see http://stackoverflow.com/
>>> questions/14198166/validating-xml-with-attributes-in-namespace-xml)
>>>
>>> I found an online validating parser (http://www.xmlforasp.net/sche
>>> mavalidator.aspx) to test the attached MusicXML file against the
>>> MusicXML schema, and it did not allow the xml:id attribute. (I also checked
>>> it permitted the same file without the xml:id). There are many online
>>> validators but most did not work at all!
>>>
>>> Any other views on this? Any other validating parsers been tried
>>>
>>> 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 19 Sep 2016, at 17:03, Joe Berkovitz <joe@noteflight.com> wrote:
>>>
>>> Sorry to be coming back to this so late in the thread.
>>>
>>> MusicXML seems to already specify that xml:id can be used as per Thomas
>>> Weber's suggestion, independently of the "id" attribute as defined in
>>> MusicXML: http://www.musicxml.com/for-developers/musicxml-xsd/xml-name
>>> space/
>>>
>>> This would be an area that I would want to clarify in MNX by avoiding
>>> use of any MusicXML-specific "id" attributes, so that there is no potential
>>> for conflict. I see xml:id as ultimately becoming the only "id" attribute.
>>>
>>> .            .       .    .  . ...Joe
>>>
>>> Joe Berkovitz
>>> President
>>> Noteflight LLC
>>>
>>> +1 978 314 6271
>>>
>>> 49R Day Street
>>> Somerville MA 02144
>>> USA
>>>
>>> "Bring music to life"
>>> www.noteflight.com
>>>
>>> On Wed, Aug 3, 2016 at 9:05 PM, Thomas Weber <tw@notabit.eu> wrote:
>>>
>>>> Am 03.08.2016 um 18:18 schrieb Michael Good:
>>>> > Unfortunately we can't quite do the "every element has an id
>>>> attribute that is an ID type" proposal without breaking compatibility with
>>>> earlier MusicXML versions. MusicXML 3.0 already has several commonly-used
>>>> elements where the id attribute is an IDREF rather than an ID.
>>>> >
>>>> >
>>>>
>>>> Standards to the rescue:  With xml:id attributes, there's no
>>>> incompatibilities with earlier versions.
>>>>
>>>>   https://www.w3.org/TR/xml-id/
>>>>
>>>>
>>
>>
>
>

Received on Tuesday, 13 December 2016 23:07:31 UTC