Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- musicxml2ly:musicxml_criticism [2013/03/13 10:42] – Externe Bearbeitung 127.0.0.1
+++ musicxml2ly:musicxml_criticism [2013/09/09 23:42] (aktuell) – gelöscht reinhold
@@ Zeile 1: / Zeile 1: @@
-====== Shortcomings of the MusicXML format ======
-  * The children of a <note> element have to be in a fixed order!
-  * There is no proper way to encode a cadenza
-  * The <credits> elements are simply text labels, but do not store its function (i.e. Composer, poet, title, etc.)
-  * There is no system delimiter (usually two slashes)
-  * All children with the same function have different names (e.g. <alter>/<key-alter>/<tuning-alter>/<root-alter>/<degree-alter>, <step>/<key-step>/<tuning-step>/<root-step>, <octave>/<key-octave>/<tuning-octave>). This makes it much harder to implement a parser, because each of them has to be treated separately, rather than using one base class for pitches, that simply reads the <alter>, <step> and <octave> children.
-  * While all other elements are defined so that each child with a different function has a different name, the <metronome> element of the form "old notevalue = new notevalue" is defined with the form (beat-unit, beat-unit-dot*, beat-unit, beat-unit-dot*), so one cannot simply access the old tempo unit and the new tempo unit separately, but has to go through the children sequentially, checking for an existing dot. This is unfortunately, in particular, since everywhere else, MusicXML tries to give each item with a slightly different function its own name. Only in <metronome>, this paradigm is badly broken.
-  * Lots of property values are badly defined (some possible values mentioned, but not exhaustive)
-  * Only syntax checking, not semantic checking (e.g. are spanners properly closed?)
-  * A measure can contain an arbitrary number of beats, irrespective of the time signature
-  * The <harp-pedals> allow you to give the pedals for  D, C, B, E, F, G, and A in a different order. It is not specified whether the order of the <pedal-tuning> elements inside the <harp-pedals> should be used or whether the pedals can/should be reordered to match the standard  DCBEFGA...
-  * Figured bass only has a slash value, but does not specify whether this is a forward slash or a back tick (usually through a "6"). It seems to implicitly assume that for a given number, only one type of slash does make sense. Anywhere else, MusicXML tries to prevent such assumptions and typically overspecifies things...
-  * Several attributes allow a text value that is to be interpreted as an integer...
-  * The spec is quiet how to proceed if a piece has an <attributes> element with explicit clefs and time signatures given for each measure. Shall the clef/time sig then be shown for each element or only if they change?
-  * Lyrics can have a number and name attribute to distinguish them. But the spec does not say how to distinguish different stanzas. Whether number, name or number+name should be used to determine which syllables belong together
-  * How shall notes with <voice> and ones without <voice> be combined? Should a default of 1 be assumed?
-  * Page headers need to be defined for each page...
-  * Figured bass is defined to be assigned to the next note, but it does not say if this is meant in XML order or in time-order. In particular, what should happen if there is a forward/backward immediately after the figured bass? Also, by "note", does the spec mean a <note> element or a real note? In other words, if the next <note> element is a rest, will the figure be assigned to that rest?
-  * There must be a note without a <chord/> tag somewhere before a note with a <cord/> element. In particular, there can be other elements like harmony or direction, but no forward or backward. This cannot be properly modelled with a DTD or a Schema.