Hi Tom,
danke für Ihre Antwort zum XML. Der Thread geht zwar nicht (nur) über XML sondern eher um die automatisierte Erkennung und Erfassung von (gedruckten) Partituren, und deshalb ist das evtl. OT, aber ich erlaube mir dazu einige Anmerkungen und hoffe, daß dies nicht belehrend wirkt.
> XML kann man nicht 'falsch implementieren', dazu ist es zu simpel
Und ob, "man" kann. ;-)
Geht ganz leicht, wenn gegen Regeln (Syntax) verstossen wird, die hier
http://www.w3.org/standards/xml/ spezifiziert sind und den "physischen Aufbau" beschreiben. Das gilt für jede XML-Datei (aka Dokument), unabhängig vom logischen Aufbau. Sie werden kein Dokument (verarbeiten) parsen können, wenn schon diese Syntax nicht eingehalten wird, es sei denn, Sie schreiben den Parser selbst oder parsen auf byte-ebene, aber dann ist es kein XML.
Es stimmt allerdings, die "physische Struktur" von XML ist simpel. Dis Spezifikation umfasst ca 26 Seiten.
> Zusammenhänge können in einer optionalen Document Type Definition (DTD) vereinbart werden
Der "logische" Aufbau (nicht nur Zusammenhänge) eines Dokumentes ist - wie Sie erwähnt haben - mit einer DTD (afaik veraltet) oder einer Schema-Definition (XSD) beschrieben. Wobei eleganterweise das XSD physisch auch wieder XML ist und die Möglichkeiten zur Beschreibung der Struktur die der DTD bei weitem übersteigt.
> wenn die fehlt, ist alles zwischen Anfangs- und Ende-Marker eine reine Datensammlung
Fehlt die Angabe der DTD oder der XSD im Kopf eines Dokumentes, dann handelt es sich strenggenommen nicht um valides XML. btw: jede Datei ist ersteinmal ein Datenfriedhof, wenn die Struktur nicht bekannt ist, insbesondere wenn es sich um binäre Daten handelt. Ein Vorteil von XML gegenüber den meisten anderen Datenformaten ist eben, daß die Beschreibung der Datenstruktur mit dem Dokument verknüpft ist, das sie formalisiert ist und das die Daten und die ElementName/-Attribute gemeinsam mit den Daten in einem Dokument enthalten sind.
> ... er ist nur der Rahmen - um das Bild darin muss man sich (bzw der Anbieter der Software) selbst kümmern ...
Genau das ist nicht die Intention. Der logische Aufbau bzw. die Spezifikation ("das Bild") des XMLs, über das in diesem Thread geschrieben wird, ist im MusicXML Schema beschrieben, das auf
http://www.musicxml.com/ zu finden ist. Das ist in diesem Fall herstellerunabhängig, deshalb ist es als Austauschformat geeignet. Darüberhinaus besteht die Möglichkeit der Versionierung einer XSD.
> vom Potential her ist es natürlich das flexibelste Format
ja, es kann logische Inhalte als eine mehr oder weniger hierarchische Baum-Struktur organisieren.
> es lässt sich sehr einfach lesen und
Das bezieht sich sicher darauf, dass XML-Dokumente "plain Text", auch multibyte-Character-Sets, sind, binäre Daten sind direkt nicht verwendbar.
Allerdings gehen die Meinungen der "human" readability nach meiner Erfahrung auseinander. Bei dokumentzentrierten Dokumenten ja, bei datenzentrierten Dokumenten eher nicht. Das dürfte auch der Grund für ähnliche Formate wie z.B. JSON oder YAML sein, die später entstanden sind.
> ggf funktional erweitern,
eher nicht. wobei zu klären ist, was "funktional" in diesem Zusammenhang bedeuten kann.
> um Inhalte zu ergänzen oder
jein. Entweder über eine Versionierung, deshalb enthält die XSD immer eine Versionsnummer. Oder über Namespaces, die allerdings im XSD dann definiert sein müssen.
> auch anders auszuwerten
ja. macht jeder Brower, z.B. siehe (X)HTML, was physisch seit 4.01+ auf XML basiert. Daneben gibt es im XML-Umfeld Werkzeuge, wie z.B. XSL(T) oder XSL-FO.
> ... und genau da gehen die Vorstellungen gern mal auseinander...
Kann sein. aber wenn eine Software als Feature anpreist, MusicXML zu unterstützen, dann ist genau dieser logische Aufbau gemeint, wie er im XSD für eine bestimmte Version festgeklopft ist. Verwendet eine Software ein "eigenes" (proprietäres) Format, das kann jeder Hersteller nach belieben entwerfen, ist dies zum Austausch nicht per se geeignet und ist auch kein MusicXML.
Eine Tatsache ist allerdings, daß die Serialisierung und/oder das Marshalling basierend auf (Music)XML nicht vollständig oder fehlerhaft implementiert ist. Und genau dieser Umstand erfordert noch beim Datenaustausch zwischen unterschiedlichen Programmen eine Kontrolle und evtl. Nachbearbeitung. Was nicht heißen soll, das beim Import von proprietären Formaten (zum Beispiel GP5 in TuxGuitar) nicht auch Fehler entstehen können, weil keine vollständige Implementierung der Spezifikation vorliegt bzw. die Spezifikation nur durch reverse engineering ermittelt werden kann.
Grüße aus Berlin
KlaBueBaer
