XML wird fast immer missbraucht

Die XML-Sprache wurde 1996 erfunden. Kaum war es erschienen, begannen die Möglichkeiten seiner Anwendung bereits missverstanden zu werden, und für die Zwecke, an die man es anzupassen versuchte, war es nicht die beste Wahl.

Es ist keine Übertreibung zu sagen, dass es sich bei der überwiegenden Mehrheit der XML-Schemata, die ich gesehen habe, um unangemessene oder falsche Verwendungen von XML handelt. Darüber hinaus zeigte diese Verwendung von XML ein grundlegendes Missverständnis darüber, worum es bei XML geht.

XML ist eine Auszeichnungssprache. Dies ist kein Datenformat. Die meisten XML-Schemata haben diesen Unterschied explizit übersehen und XML mit einem Datenformat verwechselt, was letztendlich zu einem Fehler bei der Wahl von XML führt, da es sich um das Datenformat handelt, das tatsächlich benötigt wird.

Ohne zu sehr ins Detail zu gehen: XML eignet sich am besten zum Annotieren von Textblöcken mit Struktur und Metadaten. Wenn Ihr Hauptziel nicht darin besteht, mit einem Textblock zu arbeiten, ist die Wahl von XML wahrscheinlich nicht gerechtfertigt.

Unter diesem Gesichtspunkt gibt es eine einfache Möglichkeit zu überprüfen, wie gut das XML-Schema erstellt ist. Nehmen wir als Beispiel ein Dokument im vorgesehenen Schema und entfernen alle Tags und Attribute daraus. Wenn das, was übrig bleibt, keinen Sinn ergibt (oder wenn eine Leerzeile übrig bleibt), ist entweder Ihr Schema nicht korrekt erstellt oder Sie hätten einfach kein XML verwenden sollen.

Im Folgenden werde ich einige der häufigsten Beispiele für falsch aufgebaute Schaltkreise nennen.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Hier sehen wir ein Beispiel für einen unbegründeten und seltsamen (wenn auch sehr häufigen) Versuch, ein einfaches Schlüsselwertwörterbuch in XML auszudrücken. Wenn Sie alle Tags und Attribute entfernen, bleibt eine leere Zeile übrig. Im Wesentlichen handelt es sich bei diesem Dokument, so absurd es auch klingen mag, um eine semantische Annotation einer Leerzeile.

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

Erschwerend kommt hinzu, dass wir hier nicht nur eine semantische Annotation eines leeren Strings als extravagante Möglichkeit haben, ein Wörterbuch auszudrücken – dieses Mal wird das „Wörterbuch“ direkt als Attribute des Wurzelelements kodiert. Dadurch wird der angegebene Satz von Attributnamen für ein Element undefiniert und dynamisch. Darüber hinaus zeigt es, dass der Autor eigentlich nur eine einfache Schlüsselwertsyntax ausdrücken wollte, aber stattdessen die absolut bizarre Entscheidung traf, XML zu verwenden und die Verwendung eines einzelnen leeren Elements einfach als Präfix für die Verwendung der Attributsyntax zu erzwingen. Und ich stoße sehr oft auf solche Schemata.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

Das ist etwas Besseres, aber aus irgendeinem Grund sind die Schlüssel jetzt Metadaten und die Werte nicht. Ein sehr seltsamer Blick auf Wörterbücher. Wenn Sie alle Tags und Attribute entfernen, geht die Hälfte der Informationen verloren.

Ein korrekter Wörterbuchausdruck in XML würde etwa so aussehen:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Aber wenn Menschen die seltsame Entscheidung getroffen haben, XML als Datenformat zu verwenden und es dann zum Organisieren eines Vokabulars zu verwenden, dann sollten sie verstehen, dass das, was sie tun, unangemessen und nicht bequem ist. Es kommt auch häufig vor, dass Designer fälschlicherweise XML zum Erstellen ihrer Anwendungen wählen. Aber noch häufiger machen sie die Sache noch schlimmer, indem sie XML sinnlos in einer der oben beschriebenen Formen verwenden und dabei ignorieren, dass XML dafür einfach nicht geeignet ist.

Schlechtestes XML-Schema? Übrigens, der Preis für das schlechteste XML-Schema, das ich je gesehen habe, Ruft das Konfigurationsdateiformat für die automatische Bereitstellung für Polycom IP-Telefonietelefone ab. Für solche Dateien müssen XML-Anforderungsdateien über TFTP heruntergeladen werden, was... Im Allgemeinen ist hier 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 schlechter Scherz. Und das ist nicht meine Erfindung:

• Elemente werden einfach als Präfix zum Anhängen von Attributen verwendet, die ihrerseits hierarchische Namen haben.
• Wenn Sie mehreren Instanzen eines bestimmten Datensatztyps Werte zuweisen möchten, müssen Sie dazu Attributnamen verwenden. die über Indizes verfügen.
• Darüber hinaus beginnen Attribute mit softkey., muss auf Elementen platziert werden <softkey/>, Attribute beginnend mit feature., muss auf Elementen platziert werden <feature/> usw., obwohl es auf den ersten Blick völlig unnötig und bedeutungslos erscheint.
• Und schließlich, wenn Sie hoffen würden, dass die erste Komponente eines Attributnamens immer mit dem Elementnamen übereinstimmt – nichts dergleichen! Zum Beispiel Attribute up. muss angehängt werden <userpreferences/>. Die Reihenfolge, in der Attributnamen an Elemente angehängt werden, ist nahezu willkürlich.

Dokumente oder Daten. Hin und wieder macht jemand etwas völlig Seltsames, indem er versucht, XML und JSON zu vergleichen – und damit zeigt, dass er beides nicht versteht. XML ist eine Dokumentauszeichnungssprache. JSON ist ein strukturiertes Datenformat. Wenn man sie also miteinander vergleicht, gleicht man dem Versuch, warm mit weich zu vergleichen.

Das Konzept des Unterschieds zwischen Dokumente und Daten. Als Analogon zu XML können wir ein bedingt maschinenlesbares Dokument nehmen. Obwohl es maschinenlesbar sein soll, bezieht es sich metaphorisch auf Dokumente und ist aus dieser Sicht tatsächlich mit PDF-Dokumenten vergleichbar, die meist nicht maschinenlesbar sind.

In XML ist beispielsweise die Reihenfolge der Elemente wichtig. Aber in JSON ist die Reihenfolge der Schlüssel-Wert-Paare innerhalb von Objekten bedeutungslos und undefiniert. Wenn Sie ein ungeordnetes Wörterbuch mit Schlüssel-Wert-Paaren erhalten möchten, spielt die tatsächliche Reihenfolge, in der die Elemente in dieser Datei erscheinen, keine Rolle. Aus diesen Daten lassen sich aber viele verschiedene Arten von Daten bilden. Unterlagen, weil im Dokument eine bestimmte Reihenfolge herrscht. Metaphorisch gesehen ähnelt es einem Dokument auf Papier, obwohl es im Gegensatz zu einem Ausdruck oder einer PDF-Datei keine physischen Abmessungen hat.

Mein Beispiel einer richtigen XML-Wörterbuchdarstellung zeigt die Reihenfolge der Elemente im Wörterbuch im Gegensatz zur JSON-Darstellung. Ich kann diese Reihenfolge nicht ignorieren: Diese Linearität ist dem Dokumentmodell und dem XML-Format inhärent. Einige mögen es vorziehen, die Reihenfolge bei der Interpretation dieses XML-Dokuments zu ignorieren, aber es hat keinen Sinn, darüber zu streiten, da das Problem den Rahmen einer Diskussion des Formats selbst sprengt. Wenn Sie das Dokument außerdem im Browser sichtbar machen, indem Sie ihm ein Cascading Style Sheet hinzufügen, werden Sie feststellen, dass die Wörterbuchelemente in einer bestimmten Reihenfolge und in keiner anderen erscheinen.

Mit anderen Worten, ein Wörterbuch (ein Stück strukturierter Daten) kann konvertiert werden n verschiedene mögliche Dokumente (in XML, PDF, Papier usw.), wo n - die Anzahl der möglichen Kombinationen von Elementen im Wörterbuch, und wir haben andere mögliche Variablen noch nicht berücksichtigt.

Daraus folgt jedoch auch: Wenn Sie nur Daten übertragen möchten, ist die Verwendung eines maschinenlesbaren Dokuments hierfür nicht zielführend. Es verwendet ein Modell, das in diesem Fall überflüssig ist; es wird nur im Weg stehen. Darüber hinaus müssen Sie zum Extrahieren der Quelldaten ein Programm schreiben. Es macht kaum Sinn, XML für etwas zu verwenden, das nicht irgendwann als Dokument formatiert wird (z. B. mit CSS oder XSLT oder beidem), da dies der Hauptgrund (wenn nicht der einzige) dafür ist. sich daran zu halten zum Dokumentmodell.

Da XML darüber hinaus kein Konzept für Zahlen (oder boolesche Ausdrücke oder andere Datentypen) hat, werden alle in diesem Format dargestellten Zahlen lediglich als zusätzlicher Text betrachtet. Um Daten zu extrahieren, müssen das Schema und seine Beziehung zu den entsprechenden ausgedrückten Daten bekannt sein. Sie müssen auch wissen, wann ein bestimmtes Textelement je nach Kontext eine Zahl darstellt und in eine Zahl usw. umgewandelt werden sollte.

Daher unterscheidet sich der Prozess des Extrahierens von Daten aus XML-Dokumenten nicht so sehr vom Prozess der Erkennung gescannter Dokumente, die beispielsweise Tabellen enthalten, die viele Seiten mit numerischen Daten umfassen. Ja, das ist prinzipiell möglich, aber das ist nicht der optimale Weg, außer als letztes Mittel, wenn es absolut keine anderen Möglichkeiten gibt. Eine vernünftige Lösung besteht darin, einfach eine digitale Kopie der Originaldaten zu finden, die nicht in ein Dokumentmodell eingebettet ist, das die Daten mit ihrer spezifischen Textdarstellung kombiniert.

Dennoch überrascht es mich überhaupt nicht, dass XML in der Wirtschaft beliebt ist. Der Grund dafür liegt gerade darin, dass das Dokumentformat (auf Papier) für Unternehmen verständlich und vertraut ist und sie weiterhin ein vertrautes und verständliches Modell verwenden möchten. Aus dem gleichen Grund verwenden Unternehmen zu oft PDF-Dokumente anstelle besser maschinenlesbarer Formate – weil sie immer noch an das Konzept einer gedruckten Seite mit einer bestimmten physischen Größe gebunden sind. Dies gilt sogar für Dokumente, die wahrscheinlich nie gedruckt werden (z. B. ein 8000-seitiges PDF mit Registrierungsunterlagen). Aus dieser Sicht ist die Verwendung von XML im Geschäftsleben im Wesentlichen eine Manifestation des Skeuomorphismus. Die Menschen verstehen die metaphorische Idee einer gedruckten Seite begrenzter Größe und sie verstehen, wie man Geschäftsprozesse auf der Grundlage gedruckter Dokumente erstellt. Wenn das Ihr Leitfaden ist, stellen Dokumente ohne physische Größenbeschränkung, die maschinenlesbar sind – XML-Dokumente – eine Innovation dar und sind gleichzeitig ein vertrautes und komfortables Gegenstück zu Dokumenten. Dies hindert sie nicht daran, eine falsche und übermäßig skeuomorphe Art der Datendarstellung zu bleiben.

Bisher sind XHTML und DocBook die einzigen mir bekannten XML-Schemas, bei denen ich wirklich von einer gültigen Verwendung des Formats sprechen kann.

Source: habr.com