Move DTD Doctype System Identifier (and XSD URI) to github.io

[mscuthbert]

Proposal is to move the system identifier (the URL in DTDs) in MusicXML 4.1 to point to the appropriate DTDs at w3c.github.io/musicxml/ - which will be added as soon as the first draft of 4.1 is put out.

The URL will be version specific, which didn't exist in the previous musicxml.org URIs, even though I suspect that 4.1 will be one of the last releases to still support DTDs.

The rationale is that the MusicXML spec should be pointing to sites that w3c itself controls the content of. (no, w3c does not own GitHub, but I imagine that it should be a stable site for at least a decade).

The first draft of 4.1 will be identical to 4.0 except for this change. Then PRs will go in to update the spec as it improves 4.0.

Opening for comments. Will close after 5 days w/o substantive discussions. Thanks!

[mdgood]

Would the schemaLocation attributes in the XSD for xml.xsd and xlink.xsd change at the same time?

[mscuthbert]

Yes -- though I am a little unclear why these pointed to the versions on musicxml.org to begin with. Shouldn't xml.xsd point schemaLocation="http://www.w3.org/2001/xml.xsd" and xlink.xsd to http://www.w3.org/1999/xlink.xsd -- do you remember the reason for hosting them locally instead of w3's site? I would prefer not to point those to anything we maintain (though I'll keep them in the schema since it doesn't hurt much).

[mdgood]

MusicXML's version of xlink.xsd is a subset of the full W3C xlink.xsd. The W3C version has many extra features that wouldn't be used. Having our own version makes the features simpler to understand with less to document and test. I don't recall if xml.xsd has the same issue, but once we had a local subset of xlink.xsd, it was easier to add xml.xsd to the same location.

[mscuthbert]

Ah! Got it. That I didn't know. Yes, then they should also be referenced in the same location. This is in fact annotated in the xlink.xsd, but I didn't see it because I didn't scroll right enough.

[mscuthbert]

Thanks for the discussion on the list -- I'd like to consolidate here if possible.

Andrew: When you say “until the next major version change” meaning 5.0? It’s somewhat semantic if the next version is 4.1 or 5.0 — I consider this issue more of a bug fix (the DTD/XSD don’t point to a place where they live, they’re going to point to a place where they live). The choice of major version change vs minor in MusicXML is, as far as I understand it, always been about amount of work, not about semantic versioning. Lots of 3.1 docs cannot be parsed by 3.0, for instance. 4.0 was going to be called 3.2 until rather later in the game.

[ahankinson]

There are two issues, which are separable. The first is the URL to the DTD in the DOCTYPE declaration. This is expected to resolve and currently doesn’t. I personally don’t think this requires a “major” version change to fix. The files with the old value will continue to not work, but the files with the new value will work. It’s a functional issue, not an identity issue.

The second is the issue of the URI namespace. The primary function of this is as a unique identifier, and it doesn’t necessarily have to resolve. However, in XML-speak, changing this value effectively creates a brand new spec, since the namespace is the thing that says “there may be many other <note> elements out there, but I’m a MusicXML note.” Changing the namespace to another value also changes the identity of every element in that namespace.

Historically, MusicXML hasn’t really done much with the namespace, so whether this matters is up for debate. For MEI, where it’s much more likely that MEI elements will coexist with other standards (TEI, METS, MODS, etc) it’s pretty important. It also allows for definitions of elements within the file — it’s why we can embed SVG in MEI, and keep the identities of the elements separate — we simply identify them as being in different namespaces.

however, since the namespace isn’t actually expected to resolve, you can keep using the old value for as long as you want, as long as you’re comfortable with the aesthetics of having this value in your files.

[mscuthbert]

To Carine Bournez’s point “Changing a doctype is not something recommended in any case. W3C could probably host…” I believe that changing it to W3C is also a change in the system identifier in the doctype. So there would be a change no matter what.

Note that the DOCTYPE already mentions a company that does not manage MusicXML at present (RECORDARE). The idea of the change is that the DOCTYPE should point to where the spec actually lives, which is on the w3c repo on GitHub. And the public identifier of the doc type changes with each version. However, no other change seems necessary (the number of regular expressions to change would be huge I'd imagine).

[mscuthbert]

Just in general about using another domain: I'm really not open to creating another domain and maintaining that. It just creates the exact problem that we have now—the drafts and releases of the spec pointing to a place other than where it is being updated. There is no dependency being added by mentioning GitHub — it is already a key dependency of musicxml and the entire Music Notation Community Group. And I’m not going to look MakeMusic’s long-term generosity to the community in the mouth. “They should hand it over” was said — to whom would they hand it over to? Me? I’d just turn it over to my own company to manage, and then we’d be in the same problem.

There is no Music-Notation-Community-Group-501c-Non-Profit that has an endowment to create and maintain assets: it’s just the people who contribute to the community. W3 provides hosting for the site’s blog and links to where active development is happening and for musicxml, like the majority of W3 specs, this actually takes place on GitHub. W3C’s activity is our assurance that the spec, like that of SMuFL and MNX, is freely available to the community and not proprietary. I definitely do not see the problem with having their name in the URL. Thanks!

[ahankinson]

Not if the domain you register is owned by the working group, and is hosted with GH pages where you also have the spec.

I don’t know anything about the legal structure of the WG, but it seems to be the entity that “owns” a lot of the resources it produces. Practically speaking, it just means that you guys have a way to share passwords for the admin stuff.

[dspreadbury]

I don't think there is a good way for the CG itself to "own" a domain. Certainly the CG has no budget, for one thing, so even the simple financial matter of paying for the domain registration is a vexed issue.

[ReinholdH]

For the consolidation of the discussion I would like to add my points here.

I vote not to make this change.

Reasons:

• The change is a MusicXML protocol change which requires code changes of the programs which use MusicXML
• Downdward compatibility is unclear to me. At least for some time both doctypes need to co-exist. I am also not sure what it means with regards to all the MusicXML files which 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...

[mscuthbert]

Thanks everyone for the discussion here. There's some voices in support and some voices against. I am going to try 4.1 candidate with the system identifiers pointing to where the systems actually live and we can have more discussion closer to when the community decides to ratify (or not) the new version.

[ahankinson]

So now accepting all other changes to 4.1 means accepting this change? What is the process of ratification?

[mscuthbert]

Andrew -- the ratification process for W3C community group deliverables is at https://www.w3.org/community/about/process/#cgroups under "Deliverables".

Note that the community group here is not musicxml but the music-notation working group (including SMuFL, MNX, and potentially other projects in the future).

I didn't mean to imply that I want to close off all discussion until ratification, only that there's a chicken and egg problem at present: a resolution (temporary or permanent) of this is needed to move forward with the 4.1 process: I don't want to publish 4.1 Drafts with a broken DTD URI; no one's going to care about 4.1 until there are new features in it; and no one's going to know if a new URI solution is workable until there are features.

[mscuthbert]

If there were people who volunteered to make progress on the topic who were overlooked, I am sorry I missed it.

There is pressure to move forward on the community group from people who want their ideas and contributions to be merged into a new draft (rightly so). I and the other chairs need to make decisions that will occasionally disappoint one person or another: Just ask @dspreadbury if I've ever truly forgiven SMuFL's decision to drop support for woodwind fingering fonts in v0.99 :-) it was one of those things that the community leaders needed to make a decision on: the inclusion of those ranges was making all other kerning and layout problems worse in the entire spec, but there was no one with the expertise or time to make the solutions that would enable those diagrams.

As has been noted: the old DTD did not work for validation even when musicxml.org was up and running -- no matter what version of XML the DOCTYPE implied, if the spec was downloaded from the URL, it was always validated against the latest version (or the last version downloaded).