XML wird fast immer nicht gemäß dem vorgesehenen Zweck verwendet.

Die Sprache XML wurde 1996 erfunden. Kaum war sie erschienen, begann man bereits, die Möglichkeiten ihrer Anwendung falsch zu verstehen, und für die Zwecke, für die man sie zu adaptieren versuchte, war sie nicht die beste Wahl.

Es wäre keine Übertreibung zu sagen, dass die überwältigende Mehrheit der XML-Schemas, die ich gesehen habe, eine unzweckmäßige oder falsche Verwendung von XML darstellten. Darüber hinaus zeugte eine solche Anwendung von XML von einem grundlegenden Missverständnis dessen, was XML in erster Linie ist.

XML ist eine Auszeichnungssprache. Es ist kein Datenformat. In den meisten XML-Schemas wurde diese Unterscheidung ausdrücklich nicht berücksichtigt, und man verwechselte XML mit einem Datenformat, was letztendlich bedeutete, dass die Wahl von XML selbst ein Fehler war, da man tatsächlich ein Datenformat benötigte.

Ohne ins Detail zu gehen, eignet sich XML am besten zur Annotation von Textblöcken mit Struktur und Metadaten. Wenn Ihre Hauptaufgabe nicht die Arbeit mit einem Textblock ist, dürften Sie mit der Wahl von XML kaum richtig liegen.

In dieser Hinsicht gibt es einen einfachen Weg zu überprüfen, wie gut ein XML-Schema erstellt wurde. Nehmen wir ein Dokument im angenommenen Schema und entfernen alle Tags und Attribute daraus. Wenn das, was übrig bleibt, keinen Sinn ergibt (oder wenn nur eine leere Zeile zurückbleibt), dann ist entweder Ihr Schema falsch aufgebaut oder es war einfach nicht sinnvoll, XML zu verwenden.

Im Folgenden werde ich einige der häufigsten Beispiele für schlecht konstruierte Schemata anführen.

Hier sehen wir ein Beispiel für einen unbegründeten und seltsamen (wenn auch recht verbreiteten) Versuch, ein einfaches „Schlüssel-Wert“-Wörterbuch mit XML auszudrücken. Wenn man alle Tags und Attribute entfernt, bleibt eine leere Zeile zurück. Im Grunde genommen stellt dieses Dokument, so absurd es auch klingen mag, eine semantische Annotation einer leeren Zeile dar.

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

Was noch schlimmer ist, ist, dass wir hier nicht einfach eine semantische Annotation einer leeren Zeile als extravagante Art der Darstellung eines Wörterbuchs haben – diesmal ist das „Wörterbuch“ direkt in Form von Attributen des Wurzelelements kodiert. Dadurch wird die gegebene Menge von Attributnamen am Element unbestimmt und dynamisch. Darüber hinaus ist deutlich, dass der Autor eigentlich nur eine einfache „Schlüssel-Wert“-Syntax ausdrücken wollte, aber stattdessen eine absolut seltsame Entscheidung getroffen hat, XML anzuwenden, indem er die Verwendung eines einzelnen leeren Elements einfach als Präfix für die Nutzung der Attributsyntax zwingend festlegte. Solche Schemas begegne ich sehr häufig.

John
  London

Das ist schon etwas besser, aber nun sind die Schlüssel aus irgendeinem Grund Metadaten, die Werte jedoch nicht. Eine ziemlich seltsame Sichtweise auf Wörterbücher. Wenn alle Tags und Attribute entfernt werden, geht die Hälfte der Informationen verloren.

Eine korrekte Ausdrucksweise eines Wörterbuchs in XML würde etwa so aussehen:

Name
    John
  
  
    City
    London

Wenn die Menschen jedoch seltsame Entscheidungen treffen, XML als Datenformat anzuwenden und damit ein Wörterbuch zu ordnen, sollten sie verstehen, dass das, was sie tun, unangemessen und unpraktisch ist. Oft wählen Designer fälschlicherweise XML für die Erstellung ihrer Anwendungen. Noch häufiger verschärfen sie die Situation durch sinnloses Anwenden von XML in einer der oben beschriebenen Formen, dabei ignorieren sie, dass XML einfach nicht dafür geeignet ist.

Das schlechteste 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. Diese Dateien erfordern das Herunterladen von XML-Anforderungsdateien über TFTP, die… Im Allgemeinen hier ein Ausschnitt 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 schlechter Witz. Und das ist nicht meine Erfindung:

• Elemente werden einfach als Präfixe verwendet, um Attribute anzuhängen, die selbst hierarchische Namen haben.
• Wenn Werte mehreren Instanzen eines bestimmten Datensatztyps zugeordnet werden müssen, müssen die Attributnamen verwendet werden, in denen Indizes vorhanden sind..
• Darüber hinaus sollten Attribute, die mit softkey.beginnen, an die Elemente <softkey/>angeheftet werden, Attribute, die mit feature.beginnen, an die Elemente <feature/> usw., obwohl dies völlig überflüssig und auf den ersten Blick sinnlos erscheinen mag.
• Und schließlich, wenn Sie gehofft haben, dass der erste Bestandteil des Attributnamens immer mit dem Namen des Elements übereinstimmt – weit gefehlt! Zum Beispiel müssen die Attribute up. an <userpreferences/>angeheftet werden. Die Reihenfolge, in der Attributnamen an Elemente angeheftet werden, ist willkürlich und praktisch vollständig.

Dokumente oder Daten.Gelegentlich macht jemand absolut seltsame Dinge, indem er versucht, XML und JSON zu vergleichen – und zeigt damit, dass er weder das eine noch das andere versteht. XML ist eine Auszeichnungssprache für Dokumente. JSON hingegen ist ein Format für strukturierte Daten, sodass es keinen Sinn macht, sie miteinander zu vergleichen – es ist, als würde man versuchen, Warmes mit Weichem zu vergleichen.

Ein Verständnis dessen wird durch das Konzept des Unterschieds zwischen Dokumenten und Datenhelfen. Als Analogon zu XML kann man bedingt ein maschinenlesbares Dokument heranziehen. Obwohl es zum Lesen durch Maschinen gedacht ist, ist es metaphorisch mit Dokumenten verbunden und stellt aus dieser Sicht eine faktisch vergleichbare Kategorie zu PDF-Dokumenten dar, die in der Regel nicht maschinenlesbar sind.

Zum Beispiel spielt die Reihenfolge der Elemente in XML eine Rolle. In JSON hingegen hat die Reihenfolge der "Schlüssel-Wert"-Paare innerhalb von Objekten keine Bedeutung und ist nicht definiert. Wenn Sie ein ungeordnetes Wörterbuch von "Schlüssel-Wert"-Paaren erhalten möchten, ist die tatsächliche Reihenfolge, in der die Elemente in dieser Datei folgen, irrelevant. Aber Sie können aus diesen Daten viele verschiedene Dokumenteerstellen, da im Dokument eine bestimmte Reihenfolge vorhanden ist. Metaphorisch ist dies analog zu einem gedruckten Dokument, obwohl es im Gegensatz zu einem Ausdruck oder einer PDF-Datei keine physischen Maße hat.

In meinem Beispiel für eine korrekte Darstellung eines Wörterbuchs in XML wird die Reihenfolge der Elemente im Wörterbuch gezeigt, im Gegensatz zur Darstellung in JSON. Ich kann diese Reihenfolge nicht ignorieren: Diese Linearität ist von Natur aus ein Merkmal des Dokumentmodells und des XML-Formats. Jemand könnte bei der Interpretation dieses XML-Dokuments entscheiden, die Reihenfolge zu ignorieren, aber darüber zu streiten, ist sinnlos, da diese Frage über den Rahmen der Diskussion des Formats hinausgeht. Darüber hinaus wird man sehen, dass die Elemente des Wörterbuchs in einer bestimmten Reihenfolge folgen, wenn das Dokument im Browser angezeigt wird und ein Stylesheet attached ist, und nicht in irgendeiner anderen.

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

Darüber hinaus folgt auch daraus, dass es ineffizient wäre, ein maschinenlesbares Dokument nur zum Austausch von Daten zu verwenden. Es verwendet ein Modell, das in diesem Fall unnötig ist; es würde nur stören. Zudem müsste ein Programm geschrieben werden, um die ursprünglichen Daten zu extrahieren. Es wäre kaum sinnvoll, XML für etwas zu verwenden, das zu einem bestimmten Zeitpunkt nicht in Dokumentform gebracht werden kann (sagen wir durch CSS oder XSLT oder beides), da dies der Hauptgrund (wenn nicht der einzige) ist, die Dokumentenmodell zu verfolgen.

Darüber hinaus gilt, dass im XML keine Zahlen (oder booleschen Ausdrücke oder andere Datentypen) vorhanden sind, weshalb alle in diesem Format dargestellten Zahlen lediglich als zusätzlicher Text gelten. Die Schema und ihre Beziehung zu den entsprechenden ausgedrückten Daten müssen bekannt sein, um Daten zu extrahieren. Auch muss man wissen, wann im Kontext ein bestimmtes Textelement eine Zahl darstellt, die man in eine Zahl umwandeln sollte, usw.

Damit unterscheidet sich der Prozess der Datenauslese aus XML-Dokumenten nicht wesentlich von dem der Erkennung gescannter Dokumente, die beispielsweise Tabellen mit vielen Seiten numerischer Daten enthalten. Ja, dies ist grundsätzlich möglich, aber es ist nicht der effizienteste Weg – es sei denn, es gibt absolut keine anderen Optionen. Eine kluge Lösung wäre einfach, eine digitale Kopie der originalen Daten zu finden, die nicht in das Dokumentmodell eingelegt sind, in dem die Daten mit ihrer spezifischen textlichen Darstellung verbunden sind.

Es überrascht mich nicht, dass XML in der Geschäftswelt populär ist. Der Grund dafür ist, dass das Dokumentenformat (auf Papier) für Unternehmen verständlich und vertraut ist, und sie möchten weiterhin mit dem vertrauten und verständlichen Modell arbeiten. Aus demselben Grund werden in der Geschäftswelt viel zu oft PDF-Dokumente anstelle von maschinenlesbaren Formaten verwendet – weil sie nach wie vor an dem Konzept der gedruckten Seite mit einer bestimmten physikalischen Größe gebunden sind. Dies gilt selbst für Dokumente, die wahrscheinlich nie gedruckt werden (z. B. eine PDF-Datei der Dokumentation eines Registers mit 8000 Seiten). Aus dieser Sicht ist die Verwendung von XML in der Geschäftswelt im Wesentlichen eine Manifestation von Skeuomorphismus. Menschen verstehen die metaphorische Idee einer gedruckten Seite mit begrenzter Größe und sie wissen, wie sie Geschäftsprozesse auf der Grundlage gedruckter Dokumente erstellen können. Wenn dies Ihr Maßstab ist, stellen maschinenlesbare Dokumente ohne begrenzte physische Größe – XML-Dokumente – eine Innovation dar, die zugleich ein vertrauter und komfortabler Ersatz für das Dokument ist. Was nicht hindert, dass sie weiterhin eine ungenaue und übermäßig skeuomorphe Art der Datenpräsentation sind.

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

Quelle: habr.com