XML ist zu langsam. XML ist zu speicherhungrig. Das sind nur zwei von vielen Vorurteilen gegenüber XML, die sich mit ein wenig Hirnschmalz schnell entkräften lassen. Zunächst einmal:

XML ist ein Rohmaterial wie Holz.

Dieser schlaue Spruch stammt nicht von mir, sondern aus einem Forum zu XML. Ich habe ihn mir angeeignet, weil er XML sehr treffend umschreibt und er den meisten Entwicklern mehr sagt als

XML ist eine Metasprache.

Die richtige Entscheidung
Mit Holz lässt sich viel machen. Ein Haus bauen. Eine Skulptur schnitzen. Oder einfach nur ein Feuer anheizen. Mit Holz lässt sich aber auch sehr viel falsch machen. Ein Haus, das einstürzt, weil die Statik nicht stimmt. Eine Skulptur, die dem Kunden nicht gefällt. Oder ein Feuer, das einen ganzen Wald und womöglich auch seine Bewohner vernichtet. Und für Holz benötigt man die richtigen Werkzeuge. Säge, Messer und Streichholz haben jeweils ihr ganz eigenes Einsatzgebiet. Oder wie es der Werbespruch auf meinem Leatherman prägnant formuliert:

The right tool for the right job.

Mit XML lässt sich ebenfalls viel machen. Ein Dokumentenformat spezifizieren. Ein Web Service beschreiben. Konfigurationsdaten speichern. Und auch hier lässt sich viel falsch machen. Keine Erweiterungsmöglichkeiten anbieten. Nicht auf die Datenübertragungsmenge achten. Es zu kompliziert zu machen. Schließlich verlangt auch XML je nach Einsatzgebiet die richtigen Werkzeuge. In einem Fall mag RDF angebracht sein, in einem anderen genügt XML Schema und manchmal ist eine DTD die richtige Wahl.

Wer also behauptet, XML sei dieses oder jenes, macht es sich zu einfach. Es hängt von der jeweiligen Anwendung ab. Eine Anwendung im Kontext von XML ist eine Markup-Sprache, mit der sich Daten aus einer bestimmten Anwendungsdomäne strukturieren lassen. Ob in einem Anwendungsfall überhaupt XML in Betracht kommt, ist ebenso eine berechtigte Frage, die es gleich zu Beginn zu stellen gilt, aber ein anderes Mal diskutiert werden soll.

Die entscheidende Frage
Das Wie ist schon schwierig genug, denn es hängt vom Was ab. Was soll gespeichert werden? Nehmen wir als Beispiel Koordinaten im dreidimensionalen Raum, welche die Lage eines Atoms in einem Eiweißmolekül beschreiben. So ein Eiweißmolekül (auch Protein genannt) besteht in der Regel aus mehreren tausend Atomen. Die Datenmenge einer Proteindatenbank ist demnach gewaltig. Betrachten wir der Einfachheit halber nur einen kleinen Ausschnitt:

<database>
  <protein>
    <atom>
      <type>C</type>
      <x>1.0</x>
      <y>1.0</y>
      <z>1.0</z>
    </atom>
    <atom>
      <type>N</type>
      <x>-1.0</x>
      <y>-1.0</y>
      <z>-1.0</z>
    </atom>
    ...
  </protein>
  ...
</database> 

Ja, werden Sie sagen, das ist typisch XML: Ein Geschwulst an spitzen Klammern. Alles überflüssig, werden Sie sagen. Stimmt, sage ich, denn es geht auch anders und besser:

<database>
  <protein>
    <atom type="C" x="1.0" y="1.0" z="1.0" />
    <atom type="N" x="-1.0" y="-1.0" z="-1.0" />
    ...
  </protein>
  ...
</database> 

Elemente durch Attribute zu ersetzen, das ist doch keine Lösung, werden manche sagen. Doch, genau das ist die Lösung.

Die bessere Wahl
Ein Atom besitzt nur eine x-Koordinate, eine x-Koordinate kann nur einen einfachen Wert annehmen und schließlich gehören zusätzliche Informationen wie die Angabe einer Maßeinheit zum Koordinatensystem und nicht zur Koordinate. Ein Element macht hier keinen Sinn. Nein, hier sind Attribute gefragt.

Die machen immer dann Sinn, wenn 

1. es sich um atomare oder einfach strukturierte Werte handelt,
2. Werte einen im jeweiligen Kontext eindeutigen Namen besitzen,
3. die Reihenfolge der Werte keine Rolle spielt und
4. die Werte für sich allein ohne Bedeutung sind.

Wenn alle diese Bedingungen zutreffen, spricht nichts gegen den Einsatz von Attributen. Andererseits, wenn eine der Bedingungen nicht erfüllt ist, sind Elemente sehr wahrscheinlich die bessere Wahl.

Die Bedingungen 1. und 2. resultieren unmittelbar aus der Beschränkung, dass Attribute nur einfache Zeichenfolgen speichern können und einen eindeutigen Namen besitzen müssen. Punkt 3. wird oft und gerne übersehen. Die Reihenfolge von Attributen ist per Spezifikation unbestimmt. Punkt 4. ist noch weniger durchsichtig. Er resultiert aus dem Umstand, dass sich per XInclude nur Elemente aus fremden Dokumenten einfügen lassen. Sind die gewünschten Daten in Attributen abgelegt, sind sie für eine Inklusion nicht erreichbar.

Grundsätzlich gilt: Ein (XML-)Element repräsentiert eine (Daten-)Entität, also ein Objekt; ein (XML-)Attribut repräsentiert ein Attribut, also ein Objektmerkmal.

Das positive Ergebnis
Es bleibt die Frage, was durch den Einsatz von Attributen gewonnen ist. Ein offensichtlicher Vorteil ist die kompaktere und damit auch verständlichere Darstellung der Daten. Die atom-Einträge vermitteln den Eindruck einer Tabellenzeile und lassen sich so besser vom "Menschenauge" lesen. Doch wer liest schon tausende Zeilen Atomkoordinaten?

Entscheidend ist vielmehr das, was man nicht mehr sieht: die unverhältnismäßig vielen Zeichen für die Darstellung der Metadaten. Ein Element benötigt, wenn es einen Wert speichern soll, eine Start- und eine Endmarke. Die Namen von Elementen tauchen also in der Rechnung Metadaten versus Nutzdaten zweimal auf der linken Seite auf. Rechnet man noch den Leerraum hinzu, der für die Formatierung, also die Einrückung der Elemente und die Zeilenumbrüche verwendet wird, verschlechtert sich das Verhältnis noch weiter. Wie genau, das lässt sich übrigens mit einem kleinen Programm namens XmlStatistic herausfinden.

Relativiert wird diese Rechnung freilich dadurch, dass einerseits XML-basierte Dokumentenformate wie OpenDocument, Office Open XML und die XML Paper Specification auf die ZIP-Komprimierung setzen, demnach die doppelten Namensnennungen nicht ins Gewicht fallen, und andererseits für die Übertragung von XML-Daten über das Netz, z.B. im Falle von SOAP-Nachrichten, oftmals auf eine Formatierung verzichtet wird. Eine Einladung zur Verschwendung (von wertvollem Speicherplatz, Arbeitsspeicher und Leitungskapazitäten) ist auch das allerdings nicht.

In diesem Sinne, Rechner aus, Kopf an und bis in 14 Tagen,

Ihr Martin Szugat

Martin Szugat hat im Rahmen eines Forschungsprojekts am Bioinformatik-Lehrstuhl der LMU das BioSchemas-Projekt mitinitiiert, welches sich mit dem Entwurf von XML-Schemas für die Biowissenschaften beschäftigt. Über XML & Co. berichtet er außerdem in der XML-Corner im dot.net magazin, in seinem Blog unter www.aboutxml.de und auf der BASTA im kommenden Jahr.