The Open Score Format Public Beta begins
Status: Beta
Brought to you by:
robinkidd
Menu
▾
▴
We're pleased to announce that the Open Score Format has been released as a public beta at http://openscoreformat.sourceforge.net/
The Open Score Format is based on MusicXML and provides:
* A package format for combining digital scores with other media assets such as HTML, video, audio and MIDI into a single distribution package
* MusicXML 2.0 profiles for common content types. These are subsets of MusicXML that form the basis for compatibility between tools, simplifying the job of writing and testing score editing and viewing software
* A Structured metadata format based on the Dublin Core, used for describing the content of packages and their relationships with other content
* Digital signing for packages and their contents
* The OSF Packaging Toolkit - A command-line tool for creating, unpacking, validating and signing Open Score Format packages
The Open Score Format is Open Source Software, licensed under a combination of the BSD license and the MusicXML Document Type Definition Public License Version 2.0.
The Open Score Format started life as a collaborative project between Hal Leonard Corporation, MakeMusic, MusicSales Group Ltd, Recordare LLC and Yamaha Corporation, with the aim to MusicXML as the basis for a commercial score format.
It has now been released as Open Source Software in order to gain feedback from members of the MusicXML community. We welcome your feedback.
Hi,
great project, and I like the format, but I do wonder why the signature is placed inside the manifest.xml itself, instead of in a separate signatures.xml file ?
Especially since the OSF spec refers to OEBPS Container Format 1.0 (ePub, uses a signatures.xml) which is related to ODF packages (also uses a signatures.xml)...
Best regards,
Bart
Bart,
I think the answer to your question is that we didn't follow OEBPS spec that closely! (OEBPS is in fact the pre-cursor to MusicXML compressed containers (MXL files) which OSF is at least forward compatible with. Another influence for the design came from the Yamaha Digital Music Notebook service (http://www.digitalmusicnotebook.com/) which uses packages that are similar to OSF.
At one point, some of the project partners were interested in digital rights management as well. We did the design work for this, and there are several hooks in the design of the manifest to allow a DRM scheme to be overlaid at a later stage. The usage scenarios are in fact very close (but not quite identical) to e-books.
In practical terms, The location of the signatures makes little difference to implementation complexity - wherever the signature is held, the document containing the signatures requires an enveloping signature for integrity. We found that by using a library implementation of XML DSIG, there was actually very little work to implement this.
Many thanks for your interest!
Well, I'm mainly looking at it from a cross-format perspective :-) Having a separate signature.xml makes it slightly more efficient to check whether a package is signed or not (checking if a zip entry is present instead of parsing a file), and a bit more consistent with the other formats, so it saves a few lines when developing signature tools for various formats.
Anyway, I'll give it a try in Java and the tools available for signing ODF, and of course the OSFPackagingTool will be very helpful for verifying it :-)
Do you know if there are many artists digitally signing their work without really using DRM features ? More like: "proving" they wrote a score or as a means for their fans to verify if the score wasn't altered ?
Regarding whether content authors would want to prove the authenticity of their works - to be honest I am not sure. However, OSF packages can contain other media objects, and packages might be used in commercial score distribution systems. In both cases, the viewing platform may well be interested in proving the authenticity of the package.
Also, the production of content often involves several parties who have an interest in content authenticity.