MusiXML - XML music notation file format：
|
MusiXML - XML music notation file format
MusiXML - XML music notation file formatWhy XML Schema?When we define a new data format,there are some tasks that have to be solved again and again:
This is much work to do in each case and I didn't even mention the concrete problem to be solved. XML 1.0 solvesalmostall of these general problems. You probably haven't even to learn the XML syntax because it's a simplified syntax you know from HTML. The additional benefit is that the formal definition is stored in a language independant way in a separate document (the DTD). A programer who wants to use the format doesn't even have to implement the constraints since they are tested by a parser with well defined APIs. When programers who work with e-commerce or music notation saw it,they immediately knew and agreed that this is what they needed. The main problem is,that XML 1.0 emerged from a (text) document oriented domain. This is the reason why there is no way to define data types,to use inheritance,define keys or reuse general modules in different formats. With XML 1.0 you have to learn a Syntax for XML and a different for DTDs. These problems are addressed by XML Schema. The MusiXML DTDIn spring 1998 I started to develop the MusiXMLDTD(view the MusiXML DTD in your browser) with the experience of developing an unpublished binary format and the knowledge of somemore notation formats. Here is anexamplethat uses the MusiXML DTD. The MusiXML SchemaThe MusiXML DTD works fine,but there are many constraints that are only checked by the application. As explained inWhy XML Schema?,this is a problem when you want others to understand and implement these constraints. MusiXML Schemais fully compliant withXML Schema. Theexampleand theMusiXML Schemaare part of myunit tests,usingXerces2-J. You can look at asimplified browser fiendly viewof MusiXML to get an overview. (I know that the styesheet that generates the overview needs some improvement :-) Anyway it helps. The top level structure of MusiXMLOne main goal is to store each data only once instead of holding them consistent. And we consider separating content from style. Assume we represent musical sheets for a symphony orchestra. To see the problem,we need only the score and the violin 1 part. Using a hierarchical representation,the score looks like this:
Both have the same structure. They have different instances of page,system and staff,but they share parts of <content>. The structure of the graphical hierarchy makes it necessary to store two copies of <content>. The simple idea is to store <content> in a separate place,the logical domain,and to refer to it. Now our structure looks like this:
But the work embeds everything,so we change the structure to
Since <extract> contains declarative instructions,how to process <content>,I saved some hierarchies there,to make it easier to process. The instructions in <extract> have to be declarative and not something like do this and then do that,since procesing goes in both directions: <content> has to be rendered using these instructions and <content> has to be changed using the instructions if the user changes something on the screen. The logical domain <body> contains almost all the the knowledge a music notation program can have about music. It's about the same information that is in the linear input mode of some music notation programs. Then we have a graphical domain that is contained in the <filter> element. It contains <extract> elements. Each <extract> element defines a different printout: the score and each part that is to be printed (In relational databases we would use the term view insted of extract,but we need the term view in the object oriented context). Lucky chance of the day drum corps basel 相关链接：http://www.music-notation.info/en/musixml/MusiXML.html （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |