Die XML-Sprache wurde 1996 erfunden. Er war kaum erschienen, bevor die Möglichkeiten seiner Anwendung bereits missverstanden worden waren, und für die Zwecke, für die sie versuchten, ihn anzupassen, war er nicht die beste Wahl.
Es wäre nicht übertrieben zu sagen, dass die überwiegende Mehrheit der XML-Schemata, die ich gesehen habe, unangemessen oder missbräuchlich für XML ist. Darüber hinaus zeugt diese Verwendung von XML von einem fundamentalen Missverständnis dessen, worum es in erster Linie bei XML geht.
XML ist eine Auszeichnungssprache.
Dies ist kein Datenformat . In den meisten XML-Schemata wurde diese Unterscheidung nicht explizit berücksichtigt, wodurch XML mit dem Datenformat verwechselt wurde, was letztendlich einen Fehler bei der Auswahl von XML bedeutete, da tatsächlich das Datenformat benötigt wurde.
XML eignet sich am besten zum Kommentieren von Textblöcken mit Struktur und Metadaten, ohne auf Details einzugehen. Wenn Ihre Hauptaufgabe nicht darin besteht, mit einem Textblock zu arbeiten, ist die Auswahl von XML wahrscheinlich nicht gerechtfertigt.
Unter diesem Gesichtspunkt kann auf einfache Weise überprüft werden, wie gut das XML-Schema erstellt wurde. Nehmen Sie zum Beispiel das Dokument im vorgeschlagenen Schema und entfernen Sie alle Tags und Attribute daraus. Wenn es keinen Sinn mehr gibt, was übrig bleibt (oder wenn eine leere Zeichenfolge übrig bleibt), ist Ihr Schema entweder nicht richtig erstellt, oder Sie hätten XML einfach nicht verwenden sollen.
Im Folgenden werde ich einige der häufigsten Beispiele für falsch aufgebaute Schaltungen geben.
<rot> <item name="name" value="John" /> <item name="city" value="London" /> </rot>
Hier sehen wir ein Beispiel für einen unvernünftigen und merkwürdigen (wenn auch weit verbreiteten) Versuch, ein einfaches Schlüsselwert-Wörterbuch in XML auszudrücken. Wenn Sie alle Tags und Attribute löschen, bleibt eine leere Zeile übrig. Im Grunde ist dieses Dokument, egal wie absurd es auch klingen mag, die semantische Annotation einer leeren Zeile.
<root name="John" city="London" />
Erschwerend kommt hinzu, dass es sich hier nicht nur um eine semantische Annotation eines leeren Strings als extravagante Ausdrucksform eines Wörterbuchs handelt - diesmal wird das „Wörterbuch“ direkt als Attribute des Root-Elements codiert. Aus diesem Grund wird eine bestimmte Menge von Attributnamen für ein Element undefiniert und dynamisch. Darüber hinaus wird hier deutlich, dass der Autor nur eine einfache Schlüsselwertsyntax zum Ausdruck bringen wollte. Stattdessen traf er eine absolut seltsame Entscheidung, XML zu verwenden, und erzwang die Verwendung eines einzelnen leeren Elements lediglich als Präfix Attributsyntax. Und solche Pläne kommen mir sehr oft vor.
<rot> <item key="name">John</item> <item key="city">London</item> </rot>
Dies ist bereits etwas besseres, aber jetzt sind die Schlüssel aus irgendeinem Grund Metadaten, die Werte jedoch nicht. Ein sehr seltsamer Blick auf Wörterbücher. Wenn Sie alle Tags und Attribute löschen, geht die Hälfte der Informationen verloren.
Der korrekte Wörterbuchausdruck in XML sieht ungefähr so aus:
<rot> <item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item> </rot>
Wenn die Leute jedoch die seltsame Entscheidung getroffen haben, XML als Datenformat zu verwenden und dann das Wörterbuch zu organisieren, sollten sie verstehen, dass das, was sie tun, unangemessen und unpraktisch ist. Noch immer entscheiden sich Designer fälschlicherweise für XML, um ihre Anwendungen zu erstellen. Aber noch häufiger verschärfen sie die Situation durch den sinnlosen Einsatz von XML in einer der oben beschriebenen Formen und ignorieren die Tatsache, 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, erhält das Format der Konfigurationsdatei für die automatische Ressourcenzuweisung für IP-Telefone von Polycom. Für solche Dateien müssen XML-Anforderungsdateien über TFTP geladen werden. Dies ist im Allgemeinen 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 Witz. Und das ist nicht meine Erfindung:
- Elemente werden einfach als Präfix zum Anhängen von Attributen verwendet, die selbst hierarchische Namen haben.
- Wenn Sie mehreren Instanzen eines Datensatzes eines bestimmten Typs Werte zuweisen möchten, müssen Sie die Namen der Attribute verwenden, in denen sich Indizes befinden .
- Zusätzlich Attribute beginnend mit
softkey. müssen Sie auf den <softkey/> -Elementen Attribute platzieren, die mit feature. , sollte auf die <feature/> -Elemente usw. platziert werden, obwohl es vollständig redundant und auf den ersten Blick sinnlos aussieht.
- Und schließlich, wenn Sie gehofft haben, dass die erste Komponente des Attributnamens immer mit dem Elementnamen übereinstimmt - nichts dergleichen! Zum Beispiel die Attribute
up. muss an <userpreferences/> angehängt werden. Die Reihenfolge, in der Attributnamen an Elemente angehängt werden, ist willkürlich und fast vollständig.
Dokumente oder Daten . Von Zeit zu Zeit unternimmt jemand absolut seltsame Dinge, um XML und JSON zu vergleichen - und dabei zu zeigen, dass er weder den einen noch den anderen versteht. XML ist eine Dokumentauszeichnungssprache. JSON ist ein strukturiertes Datenformat. Wenn Sie es also miteinander vergleichen, wird versucht, warm mit weich zu vergleichen.
Um dies zu verstehen, hilft das Konzept des Unterschieds zwischen
Dokumenten und Daten . Als Analogon zu XML können Sie ein maschinenlesbares Dokument beliebig verwenden. Obwohl es von einer Maschine gelesen werden 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 von Bedeutung. In JSON ist die Reihenfolge der Schlüssel-Wert-Paare in den Objekten nicht sinnvoll und nicht definiert. Wenn Sie ein ungeordnetes Wörterbuch aus Schlüssel-Wert-Paaren erhalten möchten, spielt die tatsächliche Reihenfolge der Elemente in dieser Datei keine Rolle. Sie können jedoch aus diesen Daten viele verschiedene
Dokumente erstellen, da das Dokument eine bestimmte Reihenfolge hat. Metaphorisch ist dies eine Entsprechung eines Dokuments auf Papier, obwohl es im Gegensatz zu einem Ausdruck oder einer PDF-Datei keine physischen Abmessungen hat.
In meinem Beispiel für die korrekte Darstellung des Wörterbuchs in XML wird im Gegensatz zur Darstellung in der JSON-Sprache die Reihenfolge der Elemente im Wörterbuch angezeigt. Ich kann diese Reihenfolge nicht ignorieren: Eine solche Linearität ist dem Dokumentmodell und dem XML-Format eigen. Bei der Interpretation dieses XML-Dokuments kann sich jemand dazu entschließen, die Reihenfolge zu ignorieren, aber es ist sinnlos, darüber zu streiten, da dieses Problem über die Erörterung des Formats selbst hinausgeht. Wenn Sie ein Dokument in einem Browser anzeigen, indem Sie ihm ein Cascading Style Sheet anhängen, können Sie außerdem sehen, dass die Dictionary-Elemente in einer bestimmten Reihenfolge und auf keine andere Weise folgen.
Mit anderen Worten, ein Wörterbuch (ein Fragment strukturierter Daten) kann in
n verschiedene mögliche Dokumente (in XML, PDF, auf Papier usw.) konvertiert werden, wobei
n die Anzahl der möglichen Kombinationen von Elementen im Wörterbuch ist und die anderen noch nicht berücksichtigt wurden mögliche Variablen.
Daraus folgt jedoch auch, dass die Verwendung eines maschinenlesbaren Dokuments, wenn Sie Daten allein übertragen möchten, nicht effektiv ist. Es wird ein Modell verwendet, das in diesem Fall überflüssig ist, es wird nur stören. Außerdem muss ein Programm geschrieben werden, um die Quelldaten zu extrahieren. Es ist kaum sinnvoll, XML für etwas zu verwenden, das zu einem bestimmten Zeitpunkt nicht als Dokument formatiert wird (z. B. mit CSS oder XSLT oder beidem), da dies der Hauptgrund (wenn nicht der einzige) dafür ist am Dokumentenmodell festhalten.
Da XML nicht über das Konzept von Zahlen (oder Booleschen Ausdrücken oder anderen Datentypen) verfügt, werden alle in diesem Format dargestellten Zahlen nur als zusätzlicher Text betrachtet. Um die Daten zu extrahieren, müssen das Schema und seine Beziehung zu den entsprechenden ausgedrückten Daten bekannt sein. Es ist auch notwendig zu wissen, wann, basierend auf dem Kontext, das eine oder andere Element des Textes eine Zahl ist, und es sollte in eine Zahl usw. umgewandelt werden.
Daher unterscheidet sich der Vorgang des Extrahierens von Daten aus XML-Dokumenten nicht so sehr vom Vorgang des Erkennens gescannter Dokumente, die beispielsweise Tabellen enthalten, die viele Seiten numerischer Daten bilden. Ja, im Prinzip ist dies möglich, aber dies ist nicht der optimalste Weg, es sei denn, es gibt im Extremfall überhaupt keine anderen Optionen. Eine kluge Entscheidung wäre, einfach eine digitale Kopie der Originaldaten zu finden, die nicht in das Dokumentenmodell eingebettet ist, in der die Daten mit ihrer spezifischen Textdarstellung kombiniert werden.
Es überrascht mich jedoch überhaupt nicht, dass XML in der Wirtschaft beliebt ist. Der Grund dafür liegt gerade darin, dass das Format von Dokumenten (auf Papier) für Unternehmen verständlich und vertraut ist und sie das bekannte und verständliche Modell dort weiterhin verwenden möchten. Aus dem gleichen Grund werden in Unternehmen zu oft Dokumente im PDF-Format verwendet, anstatt sie für maschinelle Verarbeitungsformate bequemer zu machen - da sie immer noch an das Konzept einer gedruckten Seite mit einer bestimmten physischen Größe gebunden sind. Dies gilt auch für Dokumente, deren Ausdruck unwahrscheinlich ist (z. B. eine PDF-Datei mit einer Registrierungsdokumentation von 8.000 Seiten). 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 mit einer begrenzten Größe und sie verstehen, wie Geschäftsprozesse auf der Grundlage gedruckter Dokumente erstellt werden. Wenn dies Ihre Richtlinie ist, sind Dokumente ohne begrenzte physische Größe, die maschinenlesbar sind (XML-Dokumente), eine Innovation und gleichzeitig eine vertraute und komfortable Entsprechung eines Dokuments. Das hindert sie nicht daran, eine falsche und übermäßig skeuomorphe Art der Datenpräsentation zu bleiben.
Bisher sind die einzigen XML-Schemata, von denen ich weiß, dass sie wirklich die richtige Verwendung dieses Formats bezeichnen können, XHTML und DocBook.