XML wird praktisch immer unzweckmäßig eingesetzt.

Die XML-Sprache wurde 1996 erfunden. Kaum war sie aufgetaucht, begannen die Möglichkeiten ihrer Anwendung missverstanden zu werden; für die Zwecke, für die sie angepasst werden sollte, war sie nicht die beste Wahl.

Es wäre keine Übertreibung zu sagen, dass die überwiegende Mehrheit der XML-Schemas, die ich gesehen habe, ein unzweckmäßiger oder falscher Einsatz von XML war. Darüber hinaus zeugte eine solche Anwendung von XML von einem grundlegenden Missverständnis, was XML in erster Linie ist.

XML ist eine Auszeichnungssprache. Es ist kein Datenformat.In den meisten XML-Schemas wurde diese Unterscheidung offensichtlich nicht berücksichtigt, was XML mit einem Datenformat verwechselte, was letztendlich einen Fehler in der Wahl von XML darstellte, da tatsächlich ein Datenformat benötigt wurde.

Ohne ins Detail zu gehen, eignet sich XML am besten zur Annotation von Textblöcken mit Struktur und Metadaten. Wenn Ihre Hauptaufgabe nicht darin besteht, mit einem Textblock zu arbeiten, ist die Wahl von XML wahrscheinlich nicht gerechtfertigt.

Von diesem Standpunkt aus gibt es einen einfachen Weg, um zu überprüfen, wie gut das XML-Schema erstellt wurde. Nehmen wir ein Beispiel für ein Dokument im angenommenen Schema und entfernen alle Tags und Attribute daraus. Wenn das, was übrig bleibt, keinen Sinn ergibt (oder wenn eine leere Zeile übrig bleibt), dann ist entweder Ihr Schema falsch aufgebaut oder es war einfach nicht angebracht, XML zu verwenden.

Ich werde nun einige der häufigsten Beispiele für falsch konstruierte Schemata anführen.

Hier sehen wir ein Beispiel für einen unbegründeten und seltsamen (wenn auch sehr verbreiteten) Versuch, ein einfaches „Schlüssel-Wert“-Wörterbuch in XML auszudrücken. Wenn wir alle Tags und Attribute entfernen, bleibt eine leere Zeile übrig. Im Wesentlichen stellt dieses Dokument, so absurd es auch erscheinen mag, eine semantische Annotation einer leeren Zeile dar.

<root name="John" city="London" />

Was noch schlimmer ist, wir haben hier nicht nur eine semantische Annotation einer leeren Zeile als extravagante Art, ein Wörterbuch auszudrücken – diesmal ist das „Wörterbuch“ direkt in Form von Attributen des WurzelsElements kodiert. Dadurch wird der festgelegte Satz von Attributnamen am Element unbestimmt und dynamisch. Darüber hinaus zeigt sich, dass alles, was der Autor tatsächlich ausdrücken wollte, eine einfache „Schlüssel-Wert“-Syntax war, aber stattdessen hat er die absolut seltsame Entscheidung getroffen, XML zu verwenden und einen einzelnen leeren Element nur als Präfix für die Verwendung der Attributsyntax zu zwingen. Solche Schemata begegne ich sehr oft.

John
  London

Das ist schon etwas besser, aber jetzt sind aus irgendeinem Grund die Schlüssel Metadaten und die Werte nicht. Ein ziemlich merkwürdiger Blick auf Wörterbücher. Wenn man alle Tags und Attribute entfernt, geht die Hälfte der Informationen verloren.

Eine korrekte Darstellung eines Wörterbuchs in XML würde ungefähr so aussehen:

Name
    John
  
  
    City
    London

Wenn Menschen sich entschieden haben, XML als Datenformat zu verwenden und damit ein Wörterbuch zu organisieren, müssen sie verstehen, dass das, was sie tun, unangemessen und unpraktisch ist. Häufig wählen Entwickler fälschlicherweise XML zur Erstellung ihrer Anwendungen. Noch häufiger verschärfen sie die Situation durch die sinnlose Anwendung von XML in einer der oben beschriebenen Formen und ignorieren dabei, dass XML dafür einfach nicht geeignet ist.

Was ist das schlimmste XML-Schema? Übrigens, der Preis für das schlechteste XML-Schema, das ich je gesehen habe, geht an das Konfigurationsdateiformat für die automatische Ressourcenzuweisung von Polycom IP-Telefonen. Solche Dateien erfordern das Herunterladen von XML-Anforderungsdateien über TFTP, die… Nun, hier ist ein Auszug aus einer solchen Datei:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

Das ist kein missratener Scherz. Und das ist nicht meine Erfindung:

• Die Elemente dienen einfach als Präfix zum Anhängen von Attributen, die hierarchische Namen haben.
• Falls Werte mehreren Instanzen eines bestimmten Datensatztyps zugewiesen werden müssen, müssen die Attributnamen genutzt werden, die Indizes enthalten..
• Darüber hinaus sollten Attribute, die mit softkey., auf die Elemente <softkey/>, Attribute, die mit feature., auf die Elemente <feature/> , usw. beginnen, platziert werden, auch wenn das auf den ersten Blick überflüssig und sinnlos erscheint.
• Und schließlich, wenn Sie hofften, dass der erste Bestandteil des Attributnamens immer mit dem Namen des Elements übereinstimmt — weit gefehlt! Zum Beispiel müssen die Attribute up. an <userpreferences/>. Die Zuordnung von Attributnamen zu Elementen ist beliebig und nahezu vollständig.

Dokumente oder Daten. Manchmal stellt jemand absurde Vergleiche zwischen XML und JSON an, und dabei zeigt er, dass er von beidem nichts versteht. XML ist eine Auszeichnungssprache für Dokumente. JSON hingegen ist ein Format für strukturierte Daten, sodass ein Vergleich zwischen beiden so ist, als würde man versuchen, Äpfel mit Birnen zu vergleichen.

Um das zu verstehen, hilft das Konzept des Unterschieds zwischen Dokumenten und Daten. Als Analogie zu XML kann man grob ein maschinenlesbares Dokument betrachten. Obwohl es für Maschinenlesbarkeit gedacht ist, bezieht es sich metaphorisch auf Dokumente und ist aus dieser Perspektive faktisch vergleichbar mit PDF-Dokumenten, die in der Regel nicht maschinenlesbar sind.

Beispielweise spielt in XML die Reihenfolge der Elemente eine Rolle. In JSON hingegen hat die Reihenfolge der Paare "Schlüssel-Wert" innerhalb von Objekten keine Bedeutung und ist nicht definiert. Wenn Sie ein ungeordnetes Dictionary aus "Schlüssel-Wert"-Paaren erstellen möchten, spielt die tatsächliche Reihenfolge der Elemente in dieser Datei keine Rolle. Sie können jedoch aus diesen Daten viele verschiedene Dokumente, da es in dem Dokument eine bestimmte Reihenfolge gibt. Metaphorisch ist dies akin zu einem Dokument auf Papier, auch wenn es im Gegensatz zu einem Ausdruck oder einer PDF-Datei keine physischen Maße hat.

In meinem Beispiel für die korrekte Darstellung eines Wörterbuchs in XML wird die Reihenfolge der Elemente im Wörterbuch gezeigt, im Gegensatz zur Darstellung in JSON. Diese Reihenfolge kann ich nicht ignorieren: Eine solche Linearität ist ursprünglich ein Merkmal von Dokumentenmodellen und dem XML-Format. Jemand könnte bei der Interpretation dieses XML-Dokuments beschließen, die Reihenfolge zu ignorieren, aber es macht keinen Sinn, darüber zu streiten, da diese Frage über die Diskussion des Formats hinausgeht. Darüber hinaus, wenn das Dokument im Browser sichtbar gemacht wird, indem es mit einem Stylesheet versehen wird, kann man sehen, dass die Elemente des Wörterbuchs in einer bestimmten Reihenfolge angeordnet sind und in keiner anderen.

Anders ausgedrückt, das Wörterbuch (ein Fragment strukturierter Daten) kann in n verschiedene mögliche Dokumente (im XML-Format, PDF, auf Papier usw.) umgewandelt werden, wo n — die Anzahl der möglichen Kombinationen von Elementen im Wörterbuch, und wir haben noch nicht andere mögliche Variablen berücksichtigt.

Es folgt daraus, dass es unwirksam ist, ein maschinenlesbares Dokument nur zur Übertragung von Daten zu verwenden. In diesem Fall wird ein Modell eingesetzt, das überflüssig ist und nur stört. Um die ursprünglichen Daten zu extrahieren, muss ein Programm geschrieben werden. Es macht kaum Sinn, XML für etwas zu benutzen, das in einer bestimmten Phase nicht in einem Dokumentenformat präsentiert wird (zum Beispiel durch CSS oder XSLT oder durch beides), da dies der Hauptgrund (wenn nicht sogar der einzige) ist, um an einem Dokumentenmodell festzuhalten.

Darüber hinaus gibt es in XML kein Konzept von Zahlen (oder booleschen Werten oder anderen Datentypen), alle in diesem Format dargestellten Zahlen werden lediglich als zusätzlicher Text betrachtet. Um Daten zu extrahieren, muss das Schema und dessen Beziehung zu den entsprechenden ausgedrückten Daten bekannt sein. Zudem muss man wissen, wann je nach Kontext ein bestimmtes Textelement eine Zahl darstellt, die in eine Zahl umgewandelt werden sollte, usw.

Der Prozess der Datenextraktion aus XML-Dokumenten unterscheidet sich nicht grundlegend von der Erkennung gescannter Dokumente, die beispielsweise Tabellen mit vielen Seiten numerischer Daten enthalten. Ja, theoretisch ist das machbar, aber es ist nicht der optimale Weg – es sei denn, es gibt absolut keine anderen Optionen. Eine vernünftige Lösung wäre es, einfach eine digitale Kopie der ursprünglichen Daten zu finden, die nicht in das Dokumentenmodell eingebettet sind, in dem die Daten mit ihrer spezifischen textlichen Darstellung kombiniert sind.

Es überrascht mich überhaupt nicht, dass XML in der Geschäftswelt beliebt ist. Der Grund dafür liegt darin, dass das Dokumentenformat (auf Papier) für Unternehmen verständlich und vertraut ist, und sie möchten weiterhin mit einem vertrauten und verständlichen Modell arbeiten. Aus demselben Grund werden in der Geschäftswelt viel zu häufig PDF-Dokumente anstelle von maschinenfreundlicheren Formaten verwendet – denn sie bleiben nach wie vor an dem Konzept der Druckseite mit einer bestimmten physischen Größe gebunden. Dies betrifft sogar solche Dokumente, die wahrscheinlich niemals ausgedruckt werden (zum Beispiel eine 8000 Seiten umfassende PDF-Dokumentation des Registers). Aus dieser Perspektive ist die Verwendung von XML in Unternehmen im Wesentlichen ein Ausdruck von Skeuomorphismus. Die metaphorische Idee einer Druckseite mit begrenzter Größe ist den Menschen vertraut, und sie verstehen, wie man Geschäftsprozesse auf der Grundlage von Druckdokumenten erstellt. Wenn dies Ihr Maßstab ist, stellen Dokumente ohne eine begrenzte physische Größe, die maschinenlesbar sind – XML-Dokumente – eine Innovation dar, während sie gleichzeitig ein vertrauter und komfortabler Ersatz für Dokumente sind. Das hindert sie jedoch nicht daran, eine fehlerhafte und übermäßig skeuomorphe Art der Datenpräsentation zu bleiben.

Bis heute sind mir nur zwei XML-Schemata bekannt, die ich tatsächlich als angemessene Anwendungen dieses Formats bezeichnen kann: XHTML und DocBook.

Quelle: habr.com