Re: The MusicXML challenge and Chords - "open commands" - the user/producer is totally reponsible for content, programming and test

Am 29.10.2015 um 07:49 schrieb mogens@lundholm.org:
> Wonder if the problem could be solved by having half open and total open commands (like in Midi).


I fear opening up things too much defeats the purpose of a standard or at least bears the risk that in practice, applications will water it down to an extend it is not useful any more.  However, in some clearly defined cases, I think allowing an application to add their own data might still be considered legit (see below).


> The idea is to move the problems from the MusicXML specification to the people doing and
> using some special construction like notes written in a spiral. Data is hexadecimal data.
>
> E.g. a "half open contruct".
>
> <bitmap PositionType=relative, X=56, Y=56, Rotation=90, Type=transparent> 8A6554876F.....</bitmap>
>
> or
>
> <soundfont 8A6554876F.............../>
>
> (Just examples - there is already an <image>-definition)
>
> And a total open construct - the user is reponsible for all the data, but must have an
> account on W3 - the user name shall be identification of the user and item. Data is just
> hexadecimal data.


XML basically already supports everything you describe in the form of XML namespaces.  No need to register a W3C account or anything.  XML namespaces are tied to a URL that is supposed to be controlled by the entity introducing namespaced elements or attributes.  And with those namespaced nodes, there's no need to restrict content to inaccessible hex blobs.  (There's also XML processing instructions which the XML standard defines to be application specific.  They've in fact been used by Dolet, but they don't prevent name clashes by means of namespaces and don't allow structured data, just a string.)

Typical XML consuming applications just ignore the nodes they don't know, so the *only* case where I think such application specific extensions are acceptable would be if it's actually perfectly fine to ignore the additional stuff.

As we were speaking of spirals, I attached an example of how Inkscape defines spirals.  SVG doesn't have a concept for spirals, but of course you can draw *anything* including spirals using SVG's <path> element.  Inkscape preserves all spiral specific information needed for its dedicated spiral tool in a custom namespace.  If you strip all that information, Inkscape (or any other SVG enabled editor) will still allow you to edit the spiral shaped path, but only with the generic path tool, not the spiral tool.

There are however two issues.

* Firstly, while it works in practice, the extended SVG officially isn't valid any more.  It would be possible, though, to provide additional data in a standard conforming way using SVG's <metadata> elements.
* Secondly, the added spiral info isn't just complementing the actual SVG, it introduces redundancy.  If you're editing the spiral's path data outside of Inkscape and preserve Inkscape specific spiral info, the edits to the path will be lost when opening the file in Inkscape again as Inkscape will re-generate the path data if it finds its custom spiral info.

What does this mean for Spiral Galaxy by George Crumb that Dennis Barthory-Kitsz linked[1]?  It is only a spiraled up version of a long continuous staff that, if stretched out, would still be meaningful notation.  As opposed to SVG, we don't expect 100% rendering fidelity from MusicXML.  Assuming MusicXML *was* capable of capturing the notation, be it stretched out or not, then it might be considered legit that an application adds information about the spiral shape as it's not required to make sense of the content.

Extensibility however still is a double edged sword for a standard that is supposed to allow exchange of data.  It's proper use is hardly enforcible or detectable and the problem remains how to avoid inconsistency if edits change the content that some third party metainformation (even if it's not redundant) might refer to.  So instead of this:


> Music notation programs shall preserve this data, whenever possible - but ignore data.
> (unless the program knows how to interpret the data.)
>
> And the originator of the data is responsible for definining the structure, accept
> edited files from common notation programs (not crash if a note is added)


it might be safest to strip all unknown information once an edit has been made to a file, if such a thing should actually be allowed eventually.


P.S.:  In any case, MusicXML should definitely use a proper XML namespace, like all(?) the other W3C XML based standards to make them interoperable.  E.g. SVG allows arbitrary content in its <metadata> element.  An SVG file representing music could actually provide a MusicXML snippet in the <metadata> element of each note.  To make this data recognizable as MusicXML, it should be in its proper namespace rather than in the null namespace as it is at the moment.


[1] http://40.media.tumblr.com/b755cf8cd1e90e2151100589c8400850/tumblr_n7g4f8trhG1qbdqqlo1_1280.jpg

-- 
Thomas Weber
Notabit
Burgkstraße 28
01159 Dresden

Tel.: +49 (0)351 4794689
http://notabit.eu/