Review requested for MusicXML media type proposals
MusicXML is a digital sheet music format currently used for interchange between Finale, Sibelius, and over 75 other music notation programs. The format was developed by Recordare LLC and you can find more information at Recordare's web site: http://www.recordare.com/xml.html The current version is 1.1, but version 2.0 is in beta test. The main goal of the MusicXML 2.0 update is to move from being primarily a music notation interchange format to being a music notation distribution format - the equivalent of MP3 files for digital sheet music. With this broader goal, it now seems appropriate to register media types. MusicXML 2.0 files will come in two versions: an uncompressed XML file similar to what is used in the current MusicXML format, and a zip-compressed XML file similar to what is used in ODF and other XML-based distribution formats. We are proposing two media types for these two versions: application/vnd.recordare.musicxml application/vnd.recordare.musicxml+xml The +xml version is for the uncompressed XML file; the other is for the compressed file format. We have posted draft registration proposals on the MusicXML developer mailing list and are now ready for review on this list. My next two e-mail messages will be the registration proposals for these two media types. Thank you very much for your assistance in reviewing these proposals. Best regards, Michael Good Recordare LLC www.recordare.com ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265
Some comments .... Where is the specification for MusicXML? The template references a DTD in the specification section, but it seems to be just a DTD, not a spec. I can't find any other spec for it on the site either. The XML format will need its own file extension. Reusing ".xml" is unsuitable because it is commonly bound to the application/xml, text/xml, or text/rss media types. Consult http://filext.com to find a suitable one. Kudos on making MusicXML 1.x files valid 2.0 files. It probably warrants a mention in the interoperability section, because it means that 1.x files can also use these media types (perhaps just the +xml one). It also makes me wonder what media types (and file extensions) were used for 1.x, and if they are registered. Mark. On 6/6/07, Michael Good <musicxml@yahoo.com> wrote:
MusicXML is a digital sheet music format currently used for interchange between Finale, Sibelius, and over 75 other music notation programs. The format was developed by Recordare LLC and you can find more information at Recordare's web site:
http://www.recordare.com/xml.html
The current version is 1.1, but version 2.0 is in beta test. The main goal of the MusicXML 2.0 update is to move from being primarily a music notation interchange format to being a music notation distribution format - the equivalent of MP3 files for digital sheet music. With this broader goal, it now seems appropriate to register media types.
MusicXML 2.0 files will come in two versions: an uncompressed XML file similar to what is used in the current MusicXML format, and a zip-compressed XML file similar to what is used in ODF and other XML-based distribution formats. We are proposing two media types for these two versions:
application/vnd.recordare.musicxml application/vnd.recordare.musicxml+xml
The +xml version is for the uncompressed XML file; the other is for the compressed file format.
We have posted draft registration proposals on the MusicXML developer mailing list and are now ready for review on this list. My next two e-mail messages will be the registration proposals for these two media types.
Thank you very much for your assistance in reviewing these proposals.
Best regards,
Michael Good Recordare LLC www.recordare.com
____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265
* Mark Baker wrote:
Where is the specification for MusicXML? The template references a DTD in the specification section, but it seems to be just a DTD, not a spec. I can't find any other spec for it on the site either.
Of course a published specification is not necessary for vendor tree registrations, and the proposed registration documents say it is "to be published".
The XML format will need its own file extension. Reusing ".xml" is unsuitable because it is commonly bound to the application/xml, text/xml, or text/rss media types. Consult http://filext.com to find a suitable one.
There are many formats that re-use application/xml and there are many +xml formats that cite or otherwise use .xml as appropriate extension. There is no actual need for a separate file extension. If .xml is what applications and documents use now, that's what should be registered. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
On 6/7/07, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
The XML format will need its own file extension. Reusing ".xml" is unsuitable because it is commonly bound to the application/xml, text/xml, or text/rss media types. Consult http://filext.com to find a suitable one.
There are many formats that re-use application/xml and there are many +xml formats that cite or otherwise use .xml as appropriate extension. There is no actual need for a separate file extension. If .xml is what applications and documents use now, that's what should be registered.
Disagree. For the vast majority of server configurations, ".xml" maps to one of those three types, and would therefore pretty much guarantee the mislabelling of many MusicXML files. In addition, IIRC, we've requested that at least a couple of registrations use their own file extension instead of ".xml"... here's one; http://www.alvestrand.no/pipermail/ietf-types/2006-May/001753.html Mark.
* Mark Baker wrote:
Disagree. For the vast majority of server configurations, ".xml" maps to one of those three types, and would therefore pretty much guarantee the mislabelling of many MusicXML files.
Using application/xml or text/xml for XML documents is no mislabeling; using text/plain or application/octet-stream on the other hand is, and most servers would use one of those types or some other incorrect type if they don't recognize the extension. You would have a point if you'd say it is easier to configure typical servers to use the proposed type if the documents use a dedicated extension, but you have to weight the benefit of that against the very high risk of actual mislabeling. It'd be worse if legacy applications do not support the "official" exten- sion, but use .xml instead, which is very likely. So, no, there is no actual need for a dedicated extension. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
On 6/7/07, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
* Mark Baker wrote:
Disagree. For the vast majority of server configurations, ".xml" maps to one of those three types, and would therefore pretty much guarantee the mislabelling of many MusicXML files.
Using application/xml or text/xml for XML documents is no mislabeling; using text/plain or application/octet-stream on the other hand is, and most servers would use one of those types or some other incorrect type if they don't recognize the extension.
Well, the point is that if you had two HTTP messages with the same body, but one with application/vnd.recordare.musicxml+xml and the other with application/xml, those messages mean two different things. text/plain would mean something different than those two messages. Only with application/vnd.recordare.musicxml+xml is there an authoritative, publicly specified (self-descriptive) path from the HTTP message to the MusicXML specification, and therefore that's the only message that means "interpret this as MusicXML". Mark.
* Mark Baker wrote:
Well, the point is that if you had two HTTP messages with the same body, but one with application/vnd.recordare.musicxml+xml and the other with application/xml, those messages mean two different things. text/plain would mean something different than those two messages. Only with application/vnd.recordare.musicxml+xml is there an authoritative, publicly specified (self-descriptive) path from the HTTP message to the MusicXML specification, and therefore that's the only message that means "interpret this as MusicXML".
The point is that you said the proposal needs to be changed and that .xml is not suitable for the proposed type. This is not backed by RFC 4288, RFC 3023, or by consensus on the ietf-types list. There are in- deed good arguments to pick a different extension, and there are good arguments against doing that. It's fine to present arguments for either approach and express personal preferences, but claiming requirements where there are none is not. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
On 6/8/07, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
The point is that you said the proposal needs to be changed and that .xml is not suitable for the proposed type. This is not backed by RFC 4288, RFC 3023, or by consensus on the ietf-types list.
I pointed out that at least one other media type registration switched from ".xml" to a media type specific file extension. I think that demonstrates that it has been the concensus position of the list in the past. On what basis do you claim that it is not? Mark.
Dear Mark and Björn, Thank you for your comments! For MusicXML 1.0 and 1.1, there is no separate specification document. The DTDs are the specification. We are of course aware of the desirability of a separate specification document, but Recordare is a small commercial company in a small market. We do hope to get a specification document out for 2.0 later this year, but it will not be ready for MusicXML 2.0's initial release later this month. That is why the specification section of the registrations points to the DTD index. For now, the DTDs are the specification, and that has worked adequately (if not ideally) in practice. For the compressed format, the container format will be described in the container.dtd file. I will add a note to the specification section that "The zip-based container format is described in the container.dtd file." There have been no MusicXML-specific MIME types registered in the past. Most servers probably use the application/xml type. It is intended that MusicXML 1.0 and 1.1 files can use the application/vnd.recordare.musicxml+xml media type. Thank you for the suggestion about adding information to the interoperability considerations section. The draft now reads "As all MusicXML 1.0 and 1.1 files are valid MusicXML 2.0 files, this media type may be used by files in these earlier versions of the MusicXML format." Does that seem appropriate? All MusicXML software to date uses and relies on the .xml suffix, so that cannot change. If we were starting off new, we would have more flexibility. One benefit of the compressed format is that we can add our own special .mxl suffix, which over time will help the usability of these files. Best regards, Michael Good Recordare LLC www.recordare.com ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469
On 6/8/07, Michael Good <musicxml@yahoo.com> wrote:
All MusicXML software to date uses and relies on the .xml suffix, so that cannot change. If we were starting off new, we would have more flexibility. One benefit of the compressed format is that we can add our own special .mxl suffix, which over time will help the usability of these files.
Ah, I see. In that case, I agree that ".xml" should be listed. I'd still recommend specifying a new file extension though, enabling new software, or new versions of existing software, to support it when they can. I'm quite certain that your users will ask for it eventually, once they discover that multiple applications on their desktop are competing for who gets the message when a ".xml" file is double-clicked. Also, as another data point along these lines, when XML files are delivered as "application/xml", many recipients (including all browsers except IE) use the namespace of the root element to do follow-on dispatching[1]. As MusicXML doesn't use namespaces, it won't work well with those recipients when delivered as application/xml. [1] http://www.markbaker.ca/2004/01/XmlDispatchTest// Mark.
* Mark Baker wrote:
On 6/8/07, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
The point is that you said the proposal needs to be changed and that .xml is not suitable for the proposed type. This is not backed by RFC 4288, RFC 3023, or by consensus on the ietf-types list.
I pointed out that at least one other media type registration switched from ".xml" to a media type specific file extension. I think that demonstrates that it has been the concensus position of the list in the past. On what basis do you claim that it is not?
That is invalid reasoning, one can easily hold that .xml is suitable for types beyond those defined in RFC 3023 and that some types might or even should use other extensions at the same time. Evidence that there is no consensus that all +xml types must have an extension different from .xml is easy to come by, take the registrations of these types for examples: * application/epp+xml * application/simple-filter+xml * application/conference-info+xml * application/dialog-info+xml * application/cpl+xml * application/watcherinfo+xml * application/reginfo+xml * application/vnd.avistar+xml * application/vnd.informedcontrol.rms+xml * ... All of them cite .xml as only or alternate extension, the latest of them being RFC 4930 which revises the application/epp+xml registration. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
On 6/9/07, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
That is invalid reasoning, one can easily hold that .xml is suitable for types beyond those defined in RFC 3023 and that some types might or even should use other extensions at the same time.
It's obviously suitable, just as ".txt" is suitable for ASCII XML files.
Evidence that there is no consensus that all +xml types must have an extension different from .xml is easy to come by, take the registrations of these types for examples:
* application/epp+xml * application/simple-filter+xml * application/conference-info+xml * application/dialog-info+xml * application/cpl+xml * application/watcherinfo+xml * application/reginfo+xml * application/vnd.avistar+xml * application/vnd.informedcontrol.rms+xml
Unfortunately, I didn't review those 8-) Anyhow, it would be good if you could respond to my earlier comments about message semantics. Perhaps we can continue this on ietf-xml-mime though, per Larry's email. Mark.
After reviews here and on the MusicXML mailing list, we have now submitted our MusicXML media type registration requests to the IANA. These media types are: application/vnd.recordare.musicxml application/vnd.recordare.musicxml+xml The +xml version is for the uncompressed MusicXML format, while the other is for the compressed .mxl format. Thanks to everyone for their help in reviewing these registration requests! Best regards, Michael Good Recordare LLC ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/
participants (3)
-
Bjoern Hoehrmann -
Mark Baker -
Michael Good