- From: Michael Asato Cuthbert <michael.asato.cuthbert@gmail.com>
- Date: Fri, 26 Apr 2024 14:41:48 -1000
- To: Andrew Hankinson <andrew.hankinson@gmail.com>
- Cc: Reinhold Hoffmann <reinhold@notation.com>, Music Notation Community Group <team-community-process@w3.org>, public-music-notation@w3.org
- Message-Id: <C6F6AA84-422C-4C15-9497-88341380E1D0@gmail.com>
Let’s consolidate discussion at https://github.com/w3c/musicxml/issues/480 I am happy to consider other options, but I haven’t seen any that solve the problem of getting to a domain the music notation community group controls, which has a good chance of stability in the future, and accepts frequent updates during the development of the spec. Best, Myke ----- Michael Scott Asato Cuthbert music21 creator / co-founder ArtusiMusic.com / founder DH Lab at MIT New email: michael.asato.cuthbert@gmail.com > On Apr 25, 2024, at 21:42, Andrew Hankinson <andrew.hankinson@gmail.com> wrote: > > See this conversation: https://github.com/w3c/musicxml/issues/480 > > The namespace should stay the same (http://musicxml.org/xsd/MusicXML <http://musicxml.org/xsd/MusicXML>), at least until the next major version change. But the DTD URLs in the DOCTYPE declaration can change. They are already broken, so the only change to files would be to make them work again. > > An alternative solution would be to register another domain and host them there. There are lots of possibilities if you get creative: musicxml.digital, mxml.info <http://mxml.info/>, etc. That would avoid injecting both "w3c" and "github" into the spec. (Since the W3C doesn't manage the spec, it's probably best to avoid mentioning them too.) > >> On 26 Apr 2024, at 05:04, Reinhold Hoffmann <reinhold@notation.com> wrote: >> >> Hi, >> >> Thanks for the minutes. >> >> With reagrds to >> >> "Myke proposes that the DOCTYPE system identifier for MusicXML should move >> from www.musicxml.org to a URL within w3c.github.io/musicxml, since the >> latter is under the control of the CG, while the former (quite rightly) >> remains under the stewardship of MakeMusic. We welcome community feedback on >> this issue, so please share your thoughts here." >> >> I would like to object. >> >> Reasons: >> - this is a MusicXML protocol change which requires code changes of the >> programs which use MusicXML. I am not sure what it means to downwards >> compatibilities. At least for some time both doctypes need to co-exist. >> - the URL www.musicxml.org is a neutral URL which reflects "MusicXML" where >> w3c.github.io/musicxml is not >> - "github" adds another kind of company dependancy to the protocol which >> should definitely be avoided >> - There should be a difference of "who hosts the URL" vs "the name of the >> URL itself" >> - if MakeMusic is not willing to host www.musicxml.org any longer, they >> should hand it over to community >> >> Ideally, the hoster should be w3.org but I am not sure if this change can be >> managed. >> >> My 2 cents... >> >> Thanks >> >> Regards, >> >> Reinhold >> >> >> -----Ursprüngliche Nachricht----- >> Von: W3C Community Development Team [mailto:team-community-process@w3.org] >> Gesendet: Donnerstag, 25. April 2024 23:32 >> An: public-music-notation@w3.org >> Betreff: Co-chair meeting minutes: April 25, 2024 [via Music Notation >> Community Group] >> >> MNX >> >> >> >> Adrian has been working on some issues opened by Yuriy Kravets: >> >> >> >> >> #334: There were several key names in the specification that used hyphens >> rather than camel case; Adrian has now fixed this. A few values remain that >> contain hyphens, and Adrian plans to fix these in due course. Adrian has >> also updated the MNX converter where needed to handle these changes. >> >> >> >> #335: This required adding an enumeration for the showValue value for >> tuplets (inner, none, both) >> >> >> >> #333: The staffSymbol object was missing the value none for its enumeration; >> this has now been added. >> >> >> >> >> Myke pointed out that it might be preferable to have more specific values >> than "none" for enumerations, since "none" can be a special keyword in >> several languages (typically equating to "null", "unknown", or "undefined"). >> We spent some time discussing possible approaches to this, and agreed that >> in principle we should use a more specific value than "none". Adrian will >> review the other enumerations and see which others should be modified. >> >> >> >> Adrian has also been working on the MNX viewer, and it can now handle some >> more notations, including accidentals, repeat barlines, and so on. >> >> >> >> MusicXML >> >> >> >> Myke proposes that the DOCTYPE system identifier for MusicXML should move >> from www.musicxml.org to a URL within w3c.github.io/musicxml, since the >> latter is under the control of the CG, while the former (quite rightly) >> remains under the stewardship of MakeMusic. We welcome community feedback on >> this issue, so please share your thoughts here. >> >> >> >> Next meeting >> >> >> >> The next co-chairs' meeting will be in three weeks, on Thursday 16 May 2024. >> >> >> >> ---------- >> >> This post sent on Music Notation Community Group >> >> >> >> 'Co-chair meeting minutes: April 25, 2024' >> >> https://www.w3.org/community/music-notation/2024/04/25/co-chair-meeting-minu >> tes-april-25-2024/ >> >> >> >> Learn more about the Music Notation Community Group: >> >> https://www.w3.org/community/music-notation >> >> >> >> >
Received on Monday, 13 May 2024 06:55:18 UTC