Wann man XML verwenden sollte und wann besser nicht

To XML or not to XML?
Kommentare

Die breite Anwendbarkeit von XML und den darauf aufbauenden Techniken kann leicht die Sicht auf besser angepasste Lösungen verstellen. Deshalb ist es wichtig, gründlich zu prüfen, ob XML wirklich die passende und entwicklungsfähige Basis ist. Ansonsten kann es passieren, dass man sich in einer Situation wiederfindet, in der XML die Ursache ernster Probleme ist, aber praktisch nicht mehr ersetzt werden kann – dass man in der XML-Falle sitzt.

Der auf XML basierende Technologie-Stack ist stabil und vielfach bewährt. Allerdings sind universelle Werkzeuge im Einzelfall nie so effizient wie spezielle. Das jeweilige Für und Wider muss abgewogen werden. Hier geht es darum, Anwendungseigenschaften für die kritische Bewertung eines XML-Einsatzes herauszuheben. Dabei können wir uns auf praktische Erfahrungen mit Projekten stützen, bei denen diese Technologie in einem fortgeschritten Stadium zu unerwarteten Problemen geführt hat. Trotz der Konzentration auf das Java-Umfeld sind die besprochenen Probleme und Überlegungen davon weitgehend unabhängig.

XML – die Wurzeln

Seit 1998 existiert XML als Standard. Seitdem wurde praktisch die ganze IT durchdrungen. Angetrieben durch den Erfolg der Sprache HTML und des WWW hat XML einen Hype erlebt, der noch nicht völlig abgeklungen ist. Inzwischen bleiben kritische Stimmen aber nicht mehr unbeachtet, sodass es an der Zeit ist, diese Entwicklung nüchtern zu analysieren und zu sehen, welche dauerhaften Folgen sie für die IT gebracht hat. Dabei kann sich das, was unter den drei Buchstaben XML verstanden wird, je nach Sicht deutlich unterscheiden.

Spätestens mit der Entwicklung des Internets war aus dem Wunsch nach einem allgemein akzeptierten Datenaustauschformat eine Notwendigkeit geworden. Gleichzeitig hatte das WWW mit seiner Sprache HTML einen ersten Eindruck davon vermittelt, wie alles mit jedem verknüpft werden kann, und in einer rudimentären Form auch die Trennung von Daten und Darstellung eingeführt. Allerdings waren konzeptionelle Begrenzungen und Schwächen unübersehbar, sodass schnell der Ruf nach einer völligen Neuentwicklung laut wurde. Diese zwei Faktoren, der sprunghaft gewachsene Bedarf nach einem Standardaustauschformat für komplex strukturierte (d. h. nicht aus einfachen Reihungen bestehende) Daten und die Erfahrungen mit HTML haben die folgende Entwicklung zu XML entscheidend geprägt.
HTML hatte den Auszeichnungssprachen eine breite Öffentlichkeit gebracht. Die Sprache war aus SGML (Standard Generalized Markup Language), einem bis dahin nur wenigen Spezialisten bekannten Formalismus zur Dokumentenbeschreibung, abgeleitet (genauer: ist ein Anwendung von SGML). SGML, 1986 von der ISO standardisiert, geht auf Entwicklungen zurück, die bei IBM in den 1960er Jahren begannen. SGML ist wesentlich durch den historischen Kontext geprägt worden. Der war lange durch eine Trennung zwischen wissenschaftlicher und wirtschaftlicher Datenverarbeitung gekennzeichnet. Auch wenn diese Trennung inhaltlich nicht sonderlich scharf war, hatte sie starken Einfluss, weil die unterschiedlichen Begriffswelten einen intensiven Austausch verhinderten und zu zahlreichen Parallelentwicklungen (unter verschiedenen Namen natürlich) führten.
Man muss die Frage stellen, ob SGML wirklich die ideale Basis für die Entwicklung eines Formalismus mit derart breit gefächertem Anspruch war. Aus heutiger Sicht spricht vieles dagegen. Wenn es Vorteile gab, dann für die Definition, Akzeptanz und Verbreitung. Der Bezug auf die Vorlage hat sicher manche Diskussionen unter den Protagonisten verkürzt oder ganz überflüssig gemacht. Nachdem HTML so erfolgreich etabliert war, wurde zu Beginn der Entwicklung von XML – trotz der ganz anderen Zielstellung – diese Basis nie ernsthaft in Frage gestellt.
Abgesehen davon, dass XML, ähnlich wie das Internet, die Lösung für fast alle Probleme sein sollte, gab es auch einige ambitionierte, aber heute beinahe vergessene Ziele. Eine der Visionen, die zwar bemerkenswerte Ergebnisse hervorgebracht hat, selbst aber verfehlt wurde, war die Ablösung der unscharfen Trennung von Daten und Darstellung in HTML durch die Kombination von XML und XSL. Von Anfang an zeigte sich dabei das Verwischen der Grenzen zwischen dem, was XML ist, und den Zielen, die man damit erreichen kann. Letztlich ging es darum, eine möglichst allgemeine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdaten zu definieren. Im Unterschied zu den Vorgängern SGML/HTML und als ein Zeichen der namensgebenden Erweiterbarkeit sollte es dabei keine vordefinierten Elementnamen geben.

XML – der Mythos

Ohne den Mythos hätte XML schwerlich eine derart atemberaubende Entwicklung vollziehen können. Für die Entstehung eines Mythos ist es wichtig, dass fehlendes Wissen durch Glauben ersetzt wird. Dafür gab es keinen besseren Zeitpunkt als den WWW-Hype (bzw. Dotcom-Boom). Plötzlich wurden so viele Sachen möglich, die vorher undenkbar erschienen, dass es sogar kritischen Geistern schwerfiel, zuverlässig zwischen Wunsch und Wirklichkeit zu unterscheiden. Mit HTML konnten selbst IT-Laien einiges zuwege bringen. Es wurden aber auch Mängel und Grenzen dieser Auszeichnungssprache sichtbar. Gleichzeitig trat der Mangel an standardisierten Datenaustauschformaten immer deutlicher zutage. In dieser Situation wurde XML als willkommene Lösung präsentiert. Und begeistert empfangen.
Es gibt aus jener Zeit kaum einen Artikel über eine neue Webanwendungstechnik, der nicht wenigstens im letzten Absatz darauf verweist, dass sich in Zukunft durch den Einsatz von XML noch ganz andere Möglichkeiten ergeben würden. Um die Jahrtausendwende war scheinbar jeder bemüht, sein Projekt irgendwie mit der magischen Abkürzung XML in Verbindung zu bringen. Die Frage war nur, ob es durch XML zu formalisieren ist (geht eigentlich immer), und nicht, ob das auch sinnvoll ist. Die wichtigsten Zutaten zum Mythos waren dabei:

  • der richtige Zeitpunkt, ein Faktor, den man gar nicht überschätzen kann
  • ein geschickt gewählter Name: Etwas, was eXtensible ist, muss einfach besser sein
  • die einfache Lösung für fast alle Probleme, ganz egal, ob Objektorientierung, Entwurfsmuster oder NoSQL
  • genügend unbestimmt: Da im Allgemeinen nicht so genau zwischen der Auszeichnungssprache und den darauf aufbauenden Technologien unterschieden wird, konnten auch der Technologie nicht besonders nahe stehende Manager mitreden, ohne Gefahr zu laufen, sich zu blamieren (umgekehrt hat das natürlich auch funktioniert – der Autor erinnert sich deutlich an den Eindruck, den man mit dem Verweis auf XML-Erfahrungen in Bewerbungsgesprächen machen konnte)
  • Standardisiert: Zunächst konnte auf den seit 1986 vorliegenden ISO-Standard für SGML verwiesen werden, dann wurde XML selbst sehr schnell als ISO-Standard zertifiziert und – schon vorher und zumindest damals noch beeindruckender – zum Webstandard erklärt
  • bedient auch all die magischen Eigenschaften: Geräteunabhängig, herstellerunabhängig, lizenzfrei, unicode-basiert (nicht, dass diese unwichtig wären, aber für ein ernst zu nehmendes Austauschformat sind das triviale Voraussetzungen)

XML – die Früchte

Wenn man heute von XML spricht, ist häufig gar nicht die Auszeichnungssprache selbst gemeint, sondern das ganze Bündel von Sprachen und Technologien, die eng damit verknüpft und teilweise parallel entstanden sind. Wir wollen uns zunächst auf den Kern, die Sprache XML, konzentrieren.
In vergleichsweise sehr kurzer Zeit wurde ein Standard erstellt. XML-Strukturen sind einfach zu verstehen und dank der Textrepräsentation und im Unterschied zu zahlreichen älteren Datenaustauschformaten relativ leicht zu lesen (solange man die Unicode-Unterstützung nicht extensiv ausnutzt).
Ein weiterer, oft genannter Vorteil ist die strikte Syntax – Weglassungen sind nicht erlaubt. Dieses Argument gilt allerdings nur mit Bezug auf HTML. Außerdem kann die Struktur zulässiger XML-Dokumente definiert werden, sodass eine Validierung möglich ist. Zunächst gab es dafür ausschließlich die Dokument-Typ-Definition (DTD), die allerdings selbst kein XML ist. XML hat von SGML und dessen Vorgängern einen Ansatz übernommen, der Dokumente als eigenen Objektbereich sieht, ohne große Gemeinsamkeiten mit den Forschungsgegenständen der Informatik. Das ist sachlich falsch und hat bedauerlicherweise weitreichende Konsequenzen. Tatsächlich handelt es sich um eine Anwendung formaler Sprachen, deren Theorie bereits in den 1960er/70er Jahren umfassend etabliert wurde und sich in Compilern und Datenanalysesystemen bewährt hat. Es gibt Untersuchungen zu effizienten Parsing-Algorithmen und dazu, wie man Sprachen so definieren kann, dass sie durch solche effizienten Methoden analysierbar werden. Und es gab und gibt hinreichend Tools, mit deren Hilfe Parser zuverlässig und schnell aus formalisierten Grammatiken erzeugt werden können. Die XML-Protagonisten scheinen das zum großen Teil nicht gut gekannt oder aus schwer nachvollziehbaren Gründen bewusst ignoriert zu haben. Der Rückgriff auf den vorhandenen Fundus an Wissen hätte nicht nur dazu geführt, dass (hoffentlich) einiges besser gemacht worden wäre, sondern vieles wäre wohl auch wesentlich schneller gegangen.
Anmerkung: Darauf, dass sich an dieser Ignoranz leider wenig geändert hat, deutet das folgende Zitat aus einer Bewertung von HTML5 hin: „Anscheinend haben die Autoren der Spezifikation den Zusammenhang zwischen DTDs, formalen Sprachen und endlichen Automaten vergessen. In einem endlosen Kapitel 8 breiten sich die Parsing-Regeln … aus. … Hier wird das Rad neu erfunden.“ [1]
So ist XML von seiner Entstehung her eine Dokumentenauszeichnungssprache. Primäres Ziel war die Beschreibung der logischen Struktur von Dokumenten, unabhängig von ihrer Darstellung. Gleichzeitig bestand ein großer Bedarf an einer allgemeinen Datenstrukturbeschreibung. Aus abstrakter Sicht besteht zwischen Dokumenten und Datenstrukturen kein grundsätzlicher Unterschied. Deshalb kann XML für beides eingesetzt werden. Unberücksichtigt bleibt dabei aber der pragmatische Aspekt. Als Austauschformat ist XML deutlich weniger gut geeignet.
Etwas pointiert gesagt, ist XML für Datenstrukturen das, was Assembler für Programme ist: eine sehr allgemeine und damit mächtige, aber auch elementare und durch Unübersichtlichkeit schwierig zu handhabende Beschreibung. Doch während Assembler i. d. R. zu redundanzarmen kompakten Programmen führen, gilt das bei XML für die Daten nicht. Unter den genannten Voraussetzungen ist es nicht überraschend, dass XML vorrangig die Forderungen erfüllt, die für die Dokumentenstrukturauszeichnung wesentlich sind. Die Eigenschaften, die von einem Austauschformat erwartet werden, das innerhalb automatischer Verarbeitungsprozesse eingesetzt wird, sind hingegen deutlich weniger ausgeprägt. Im Folgenden werden einige wichtige Eigenschaften detaillierter betrachtet.

Trennung von Inhalt und Darstellung

Ein Ziel der XML-Definition war es, die bereits in HTML rudimentär angelegte Trennung von Inhalt und Darstellung konsequent zu Ende zu führen. Ein XML-Dokument sollte so völlig unabhängig vom Darstellungsmedium (im weitesten Sinne) sein. Beispielsweise sollte eine Menge von Daten sowohl in einem Browser als Tabelle oder Grafik darstellbar sein als auch einem automatischen Handelssystem als Entscheidungsgrundlage dienen können. Dieser Ansatz hat sich grundsätzlich bewährt. Er funktioniert überall dort, wo es sich bei den Daten um einen semantisch hinreichend verstandenen Bereich handelt. Tatsächlich treten die größten Probleme dabei auf, ein gemeinsames Verständnis der verwendeten Begriffe zu erreichen. Das ist jedoch eine Frage, die vom verwendeten Formalismus weitgehend unabhängig ist. XML hat dazu beigetragen, dass sie stärker bewusst geworden ist, was sich u. a. in der Forschung in einem größeren Interesse an Ontologien oder den Arbeiten am so genannten Semantic Web niederschlägt.

Dokumententransformation

Die Idee, Daten als XML zu übertragen und dann im Browser mittels (unterschiedlicher) XSL-Dokumente für die Darstellung aufzubereiten, hat sich in dieser Form als Standardtechnik nicht durchgesetzt, obwohl beispielsweise der MS Internet Explorer nach wie vor einen XSLT-Prozessor enthält. Für diesen Misserfolg sind aus Sicht des Autors verschiedene Gründe verantwortlich:

  • XSLT ist zwar ein leistungsfähiges Transformationssystem, ihm fehlen aber wichtige Funktionen, z. B. die zum Rechnen mit Zahlen, was nicht nur zum Skalieren eigentlich unverzichtbar ist.
  • XSLT arbeitet regelbasiert, d. h. nicht prozedural. Alle Erfahrungen mit regelbasierten Programmiersprachen zeigen, dass es einem großen Teil der Anwender offenbar sehr schwer fällt, regelbasiert zu denken, bzw. sich von der erlernten und geübten vorgehensbasierten (prozeduralen) Arbeitsweise zu trennen. Bei vielen XSLT-Dokumenten handelt es sich dann auch um mehr oder weniger verkappte Anweisungsfolgen.
  • Nicht zuletzt hatten auch die im Weiteren betrachteten Verarbeitungsprobleme ihre Wirkung.

Abgesehen davon ist der XSL-Technik durchaus Erfolg beschieden gewesen. Insbesondere, wenn es darum geht, aus Daten Dokumente wie Rechnungen oder Berichte – auch in unterschiedlichen Formaten – zu erstellen, sind die auf XSL aufbauenden Technologien nicht mehr wegzudenken.

Objektserialisierung

Für die Serialisierung/Deserialisierung von (nicht nur) Java-Objekten hat sich XML inzwischen als Standardformat durchgesetzt. Beispielsweise ist die JAXB-Bibliothek seit Version 6 Teil der Java-Distribution. Es gibt zudem stabile und bewährte alternative Implementierungen für alle wichtigen Programmierumgebungen.
Für diesen Erfolg sind jedoch weniger die Qualitäten von XML verantwortlich als vielmehr das Fehlen ernsthafter Konkurrenten. Andere Werkzeuge verwenden proprietäre Formate und sind entweder stark an bestimmte Programmiersprachen gebunden, z. B. Pickle an Python, oder Teil kommerzieller Pakete. Über System- bzw. Programmiersprachengrenzen hinaus verwendbare Formate bieten JSON und YAML. Während JSON nicht alle möglichen Objektstrukturen darstellen kann und die Typisierung schwierig ist, fehlt YAML schlicht die Publizität.

Werkzeuge

Der Erfolg von XML ist eigentlich ein Erfolg der verfügbaren Werkzeuge. Ohne die schnelle Unterstützung durch zum großen Teil freie Software wäre die Durchdringung der verschiedenen IT-Bereiche kaum möglich gewesen. Bei genauerem Hinsehen zeigt sich aber auch, dass oft Schnelligkeit vor Gründlichkeit gegangen ist. Für Programme ist das kein Problem, weil man Fehler durch Updates beheben kann. Wie noch gezeigt wird, haben sich nachteilige Festlegungen jedoch auch in das API eingeschlichen, wo man sie später wesentlich schwerer verbessern kann.
Da auf der Basis der vorhandenen Werkzeuge relativ schnell und problemlos prototypische Lösungen realisiert werden können, tragen sie entscheidend zur Verbreitung dieser Technologie bei. Bei allen kritischen Bemerkungen soll nicht bestritten werden, dass XML und diese Werkzeuge an vielen (aber nicht allen) Stellen helfen, Software effizient zu erstellen. Allerdings scheint es so, als wäre die dynamische Phase der Werkzeugentwicklung seit einigen Jahren vorbei. Die Technologie ist stabil und etabliert. Das große Interesse der Webgemeinde ist weitergewandert zu HTML5.

Problembereiche

XML ist ohne Zweifel eine bewährte Standardtechnologie. Das heißt nicht, dass keine Mängel zu konstatieren wären. Im Folgenden sollen einige der Punkte genauer betrachtet werden, die für Probleme verantwortlich sein können. Dabei soll nicht vergessen werden, dass eine Einordnung als Vor- oder Nachteil immer von der jeweiligen Sicht abhängt. Entscheidend sind die Umstände des Einsatzes. In diesem Sinn handelt es sich eher um Denkanstöße als um Bewertungen – Letztere sind dem Leser in seiner konkreten Situation vorbehalten.

Offene Fragen

Die Flexibilität von XML stellt den Anwender gleich zu Beginn vor Fragen, deren Konsequenzen nicht leicht überschaubar sind. Das beginnt mit der Unterscheidung zwischen wohlgeformten und gültigen Dokumenten. Ein XML-Dokument, das elementaren Regeln genügt, wird als wohlgeformt bezeichnet. Ein wohlgeformtes Dokument ist gültig, wenn es darüber hinaus eine DTD (direkt oder als Referenz) enthält und den darin definierten Regeln entspricht. Für den Anwender gibt es keine festen Regeln, welche Form er benutzen sollte, nur Ratschläge (s. Kasten).

Ratschläge: ein Beispiel

Müssen Sie immer ein gültiges XML-Dokument mit einer DTD schreiben oder reicht ein wohlgeformtes Dokument? Die Antwort ist nicht eindeutig: Es hängt von Ihren Bedürfnissen ab. (…) Dadurch, dass man auf die DTD verzichtet, bleibt der XML-Code schön übersichtlich. Und wenn Sie mal auf die Schnelle ein kleines XML-Dokument erstellen wollen, ist das wohlgeformte XML ohne DTD immer einfacher programmiert.

Was kaum beachtet wird, ist die Auswirkung auf die Verarbeitung. Die Prüfung auf Gültigkeit erfordert, dass nicht nur das XML-Dokument eingelesen und analysiert wird, sondern auch die DTD (bzw. XSD). Das schafft zwar eine größere Sicherheit gegen falsch strukturierte Dokumente und kann besonders in Editoren hilfreich sein, verursacht aber einen entsprechend größeren Verarbeitungsaufwand. Darüber hinaus sollte man nicht übersehen, dass die häufig verwendete Referenzierung externer DTD ein Tor für Angriffe durch Manipulation dieser DTD öffnet, wenn keine zusätzlichen Vorkehrungen getroffen werden. Prinzipiell ist es auch möglich, aus der Strukturbeschreibung (DTD/XSD) dedizierte Parser zu generieren. Offensichtlich rechtfertigt der dadurch mögliche Performancegewinn den Aufwand nicht. In Ansätzen findet sich diese Lösung lediglich beim Generieren von Web Services.
Eine andere Frage, die immer wieder kontrovers diskutiert wird, ist die nach Regeln, wann etwas als Attribut und wann als Element definiert werden soll. Der häufig aufgeführte Vorschlag, dass Attribute primär für Metadaten und Elemente für die eigentlichen Nutzdaten verwendet werden sollen, hat für Dokumente durchaus Sinn. Bei reinen Datenstrukturen, wie beispielsweise serialisierten Objekten, ist die Unterscheidung aber sehr sophistisch. In der Praxis führt das bisweilen dazu, dass ausschließlich Elemente verwendet werden, da diese das allgemeinere Konstrukt sind, während es für Attribute und deren mögliche Werte verschiedene Einschränkungen (aber auch genauere Wertspezifikationen) gibt. Statt relativ kurz

<property name="ID" value="22"> 

muss dann

<property>
  <name>ID</name>
  <value<22</value>
</property>

geschrieben werden. Das ist wesentlich schlechter lesbar, insbesondere, wenn man an eine ganze Liste solcher Properties denkt. Derartige Überlegungen haben wohl auch dazu beigetragen, dass z. B. Tomcat ab der Version 5.5 in den Konfigurationsdateien von der reinen Elementstruktur auf die Verwendung von Attributen umgeschwenkt ist. Die Lesbarkeit dieser Dateien hat dadurch erheblich gewonnen, und die Konfiguration ist (zumindest gefühlt) einfacher geworden, weil man auf einen Blick (bzw. auf einem Bildschirm) mehr Informationen erhält als vorher.
Das Attribut-Element-Dilemma ist letztlich Ausdruck der unterschiedlichen Anwendungskontexte. XML ist primär für die Strukturierung von Dokumenten entworfen worden. Als Datenaustauschformat ist es nur bedingt geeignet. Die syntaktische Armut eröffnet gleichzeitig vielfältige Möglichkeiten, ein und denselben Sachverhalt auf viele verschiedene Weisen darzustellen. Das erscheint zunächst als großer Vorteil, hat auf die Dauer aber u. a. die folgenden Nachteile:

  • Es ist schwierig, Coding-Standards für XML-Strukturen zu etablieren. Die Tatsache, dass man XML benutzen kann, ohne vorher eine Struktur definieren und damit durchdenken zu müssen, begünstigt voreilige Entscheidungen, die oft nicht mehr korrigierbar sind.
  • Es ist nicht möglich, den Inhalt von Elementen zu beschränken (Längenbeschränkung, zulässige Zeichen usw.). Das gilt auch bei Verwendung einer DTD. Nur XSD bringt diesbezüglich eine Verbesserung.

Geschwätzigkeit (Verbosity)

Die Geschwätzigkeit von XML ist beabsichtigt. Sie soll die Lesbarkeit (für Menschen) verbessern. Gleichzeitig erhöht diese Redundanz die Robustheit gegen Datenfehler. Der letzte Punkt ist für die Langzeitspeicherung von Dokumenten wichtig und nur dafür gültig, denn die durch XML gegebene Redundanz ist auf die Strukturauszeichnung beschränkt. Für Textdokumente im weiteren Sinn, d. h. den ursprünglichen SGML-Objektbereich, ist diese Einschränkung akzeptabel, weil natürlichsprachliche Texte selbst höchst redundant sind. Für die Daten einer serialisierten Objektrepräsentation gilt das nicht. Dort besteht eine deutliche Asymmetrie zwischen der redundanten Strukturinformation und der wenig redundanten inhaltlichen Information. Dem scheinbaren Vorteil der Fehlertoleranz gegenüber wurde dem erhöhten Platz- bzw. Bandbreitenbedarf keine wesentliche Bedeutung zuerkannt, da einerseits Speicherplatz immer billiger wird und andererseits XML-Daten sehr gut komprimiert werden können.
XML-Dokumente sind deutlich umfangreicher als in anderen vergleichbar ausdrucksstarken Formaten angelegte Dokumente. Wenn Daten aber komprimiert, d. h. nicht direkt lesbar abgelegt werden, warum dann im XML-Format und nicht in einem besser angepassten? Wenn sie nicht komprimiert werden, entsteht ein Mehraufwand, der von der Anzahl der Tags und der Länge von Element- und Attributnamen abhängig ist und bis auf fast 50 Prozent steigen kann. Niemand kommt auf die Idee, Programme als XML-Strukturen zu schreiben (s. Kasten „Java in XML“). Die Texte wären viel länger und entgegen den XML zugeschriebenen Eigenschaften auch schlechter lesbar. Das führt zur Frage: Warum soll, was für Programme gilt, nicht auch für die Datenbeschreibung zutreffen?

Java in XML

Nichts spricht grundsätzlich dagegen, ein Java-Programm als XML-Dokument zu schreiben:

<class scope="public" name="Beispiel" package="de.xml.bsp">
   <extends class="de.xml.bsp.Base" />
   <implementing>
     <implements name=java.util.List" />
   </implementing>
  <statics> ...
</class>

wäre denkbar für

package de.xml.bsp;
import java.util.List;
class Beispiel extends Base implements List { 
  ...
}

Wem das obige Beispiel noch nicht abschreckend genug erscheint, analoge Datenstrukturen werden auch so beschrieben:

<class>
<properties|>
  <property>
    <name>name</name>
    <value>Beispiel</value>
  </property>
  <property>
    <name>scope</name>
    <value>public</value>
  </property> ...
</class>

Gute Ingenieursarbeit zeichnet sich durch Sparsamkeit aus, und zwar nicht nur in Bezug auf die Kosten, sondern auf alle eingesetzten Mittel. Im Software-Engineering ist dieser Grundsatz etwas aus dem Fokus geraten. Daran ist sicher die schnelle Entwicklung der Hardware Schuld, die zu einer einseitigen Konzentration auf die Entwicklungskosten geführt hat. Es ist absehbar, dass, wie in allen reiferen Technologien, das Streben nach sparsamen und einfachen Lösungen zunehmen wird. Vermutlich wird in Zukunft die Suche nach speicher- und prozessorzyklensparenden Formaten und Methoden in der Softwareentwicklung eine ähnliche Rolle einnehmen wie sie heute z. B. die Suche nach festen und leichten Materialien im Fahrzeugbau hat. Sparsamkeit ist eng verknüpft mit Einfachheit. Je komplexer die Anforderungen werden, desto wichtiger wird Einfachheit als Designprinzip . Das Thema wird uns nicht verlassen.

Performance

Wenn es darum geht, XML als Austauschformat zu verwenden, wird auf die gute Komprimierbarkeit verwiesen. Die ist zwar tatsächlich gegeben und beweist die Redundanz, aber Komprimieren und Dekomprimieren sind nicht kostenlos. Beides erfordert Prozessorleistung. Trotz aller Fortschritte ist Prozessorleistung in großen Systemen eine unverändert knappe Ressource. Nebenbei, Prozessoroperationen verbrauchen Energie. Die Verarbeitung von XML-Dokumenten erfordert schon heute signifikante Energiemengen.
Es gibt einen zweiten Punkt, der aufwändig ist: das Parsen und Schreiben der XML-Dokumente. Der Aufwand dafür ist mindestens linear von der Anzahl der Zeichen abhängig. Publizierte Benchmarks zeigen sogar einen deutlichen Leistungsrückgang, wenn die Dokumente größer werden, selbst wenn ihre Verschachtelungstiefe nicht zunimmt, und zwar unabhängig von den verwendeten Parsing-Methoden.
Die Bedeutung des Verarbeitungsaufwands wird auf absehbare Zeit noch zunehmen, da Leistungssteigerungen bei Prozessoren immer weniger durch erhöhte Taktraten erreicht werden. Die Beschleunigung durch superskalare und Mehrkern-CPU kommt beim Parsen jedoch kaum zum Tragen. Der relative Anteil der für die XML-Verarbeitung benötigten Zeit wird (bei sonst unveränderten Bedingungen) allein durch diese technische Entwicklung steigen. Wie groß der Overhead wirklich ist, kann man sich leicht veranschaulichen durch den Vergleich der Leistung des Java-Compilers, der um Größenordnungen komplexere Operationen ausführt, mit dem Einlesen oder Transformieren eines XML-Dokuments. Natürlich ist dieser Vergleich nicht ganz fair, weil ein allgemeineres, in Java kodiertes Verfahren einem speziell optimierten gegenüber immer im Nachteil ist, aber die Unterschiede sind einfach zu groß, um sie damit begründen zu können.
Außer dem grundsätzlichen Problem gibt es im XML-API für Java noch einige hausgemachte Performancekiller, für die jedoch wenigstens teilweise Abhilfe möglich ist. Listing 1 zeigt eine Methodensignatur aus Javas Standard-XML-Interface und die analoge Definition aus der Javolution-Bibliothek.

// Javax-API
// javax.xml.stream.XMLStreamWriter: 
public void writeStartElement(String localName) throws XMLStreamException;

// Javolution-API
// javolution.xml.stream.StreamWriter: 
public void writeStartElement(CharSequence localName) throws XMLStreamException;

Der vermeintlich kleine Unterschied kann bei geschickter Programmierung deutliche Effizienzgewinne ermöglichen, nämlich dann, wenn die zu schreibende Zeichenkette selbst vorher zusammengesetzt wird. Listing 2 zeigt den Unterschied. Die zweite, nur mit Javolution mögliche Variante, vermeidet pro Aufruf die Erzeugung eines String-Objekts. Trotz aller erreichten Verbesserungen ist die Objekterzeugung eine relativ teure Operation geblieben, ganz abgesehen vom unnötig allozierten Speicherplatz. Dazu kommt, dass beim Anlegen eines Strings dessen Wert in einen internen Puffer kopiert wird, einer Operation mit längenabhängigen Kosten, die ebenfalls eingespart wird.

StringBuilder stringBuilder= new StringBuilder();
stringBuilder.append(...);
...
streamWriter.writeStartElement(stringBuilder.toString());  // javax u. Javolution

// nur mit Javolution möglich
streamWriter.writeStartElement(stringBuilder);  // javolution API

Analoge Effizienzgewinne sind beim Parsing möglich. Trotzdem ist die Javolution-Bibliothek zum Standardinterface weitgehend quellcodekompatibel. Eine Neukompilierung mit den geänderten Importen ist ausreichend. Um die gezeigten Vorteile konsequent nutzen zu können, sind allerdings entsprechende Anpassungen nicht zu umgehen.

Datentypen

Mittels DTD können Strukturen für XML-Dokumente vorgegeben werden, es ist jedoch nicht möglich, Einschränkungen der zulässigen elementaren Werte zu definieren. (Das geht zu einem gewissen Grad nur bei den Attributen.) Letztlich wird alles als Zeichenkette (CDATA/PCDATA) betrachtet. Auch dieses Erbe der SGML-Abstammung ist bei entsprechenden Dokumenten akzeptabel. Wenn XML als Format für den Austausch von Datenstrukturen wie beispielsweise serialisierten Objekten verwendet wird, ist eine genauere Beschreibung jedoch zwingend. Um diesen Mangel zu beheben, wurde vom W3C die Beschreibungssprache XML Schema (auch XSD für XML Schema Document) entwickelt. Im Unterschied zu DTD werden XSD-Dokumente in XML formuliert. Im Ergebnis handelt man sich mit dieser eigentlich wünschenswerten Vereinheitlichung wieder die bereits diskutierten Nachteile, insbesondere die Geschwätzigkeit, ein.
Listing 3 zeigt eine einfache Schema-Definition in XSD-Schreibweise. Die abgesehen vom Namensraum gleichwertige DTD ist in Listing 4 zu sehen. Man kann deutlich erkennen, dass der größere Umfang der XSD-Beschreibung nur zu einem unwesentlichen Teil auf die genauere Typauszeichnung zurückzuführen ist.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="doc">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="body" type="xs:string"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="head">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="title" type="xs:string"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>
<!ELEMENT doc (head, body)>
<!ELEMENT head (title)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT body (#PCDATA)>

XSD stellt atomare Datentypen bereit und bietet Konstruktoren, mit deren Hilfe zusammengesetzte Typen definiert werden können. Auch Typerweiterungen oder -einschränkungen sind möglich. Die Beschreibung ist hinreichend genau, um daraus Code generieren zu können (und umgekehrt), wovon im Web-Service-Umfeld Gebrauch gemacht wird.
Aktuell ist die Version XSD 1.1 (April 2012). Die XSD-1.0-Spezifikation wurde 2001 publiziert. Es ist nicht gelungen, XSD als einheitliche XML-Schema-Sprache zu etablieren. Der Einsatz konzentriert sich auf Bereiche, in denen die exakte Typisierung der Elemente essenziell ist. Für Dokumente im weiteren Sinn sind nach wie vor DTD die Standardbeschreibung. Die aktuelle Einführung in die Java-XML-Verarbeitung enthält immer noch die Aussage: „Because there are very few XML parsers supporting the XML Schema specifications, most of the sample programs use the first set of XML documents, based on DTD.“
Es gibt mit RELAX NG (REgular LAnguage for XML Next Generation) noch eine weitere Schema-Sprache, die neben dem XML-Format eine wesentliche kürzere so genannte Compact-Syntax besitzt. Diese Sprache wurde 2003 als Teil eines ISO-Standards normiert. Trotzdem hat sie vergleichsweise wenig Verbreitung gefunden. Obwohl die benötigten Technologien existieren, werden aus Schema-Definitionen praktisch nie Parser generiert und als Komponenten verfügbar gemacht. Auch das ist ein ungenutztes Optimierungspotenzial.

Pro und Contra

„There really is no single ‚better’—it depends on what you want.” Für die Verwendung von XML sprechen viele Gründe. Die meisten wurden bereits erwähnt:

  • Es existiert ein Standard
  • Es gibt zahlreiche Tools, und viele Programme unterstützen XML
  • XML ist bei Entwicklern bekannt, Erfahrungen sind vorhanden
  • Kurz, XML ist allgemein akzeptiert

Keine Diskussion gibt es auch dann, wenn XML als Schnittstellenformat gefordert wird. Dann bleibt höchstens zu überlegen, ob für interne Prozesse eine Alternative in Betracht kommt. Es gibt noch einige weitere Überlegungen, die zu einer Entscheidung pro XML führen können:

  • Wenn es sich um (große) Dokumente handelt, für die z. B. kein wirklich effizienteres Format existiert – also um den ursprünglichen SGML-Aufgabenbereich
  • Wenn bestimmte Software eingesetzt werden soll oder muss, z. B. XSL-FO-Prozessoren
  • Wenn die Anwendung nicht performancekritisch ist und keine großen Datenmengen entstehen (geringe Leistungsanforderungen, Prototypen)
  • Wenn – ganz allgemein – die aus der Verwendung vorgefertigter Bausteine resultierenden Vorteile (geringerer Entwicklungs- und Testaufwand) größer sind als die daraus resultierenden Nachteile

Gegen die Verwendung von XML sprechen die aufgeführten Problembereiche. Ganz besonders kritisch sind dabei Kernkomponenten zu betrachten, die für die Gesamtleistung entscheidend sind. Die Gefahr, dass man sich Leistungsprobleme einhandelt, ist besonders groß, wenn sehr viele (kleine) XML-Dokumente zu erzeugen und zu parsen sind. Zum ohnehin vorhandenen Overhead kommt dann noch der Aufwand für die jeweils erforderliche Initialisierung hinzu. Ein typisches Beispiel dafür ist die in verschiedenen Applikationsservern übliche Serialisierung/Deserialisierung mittels XML-Format.
Es lohnt sich, die Argumente genauer zu prüfen, die für die XML-Verwendung sprechen. Nur wenn es einen konkreten Nutzen für das vorliegende Projekt gibt, sollten sie akzeptiert werden. Allzu oft findet man Begründungen, die auf eher unbestimmte Vorteile durch mögliche Nachnutzungen oder leichte Austauschbarkeit von einzelnen Komponenten verweisen. Das kann zutreffen. Man muss aber vorher kritisch fragen: Wie oft habe ich es erlebt, dass eine entsprechende Komponente wirklich ausgetauscht oder nachgenutzt wurde? Wie wahrscheinlich ist es, dass das diesmal geschieht? Nur wenn es eine hinreichend realistische Chance gibt, dass dieser Fall eintritt, sollten solche Vorteile gewertet werden. Es ist klar, dass diese Bewertung für ein Softwareprodukt völlig anders ausfallen wird als für ein kundenspezifisches Projekt.

Alternativen suchen

Alternativen gibt es mehr, als ein flüchtiger Blick vermuten lässt, und es gäbe sicherlich noch mehr, wenn öfter danach gefragt würde. Getreu dem Motto „Eines schickt sich nicht für alle“ können hier nur einige Denkanstöße gegeben werden. Eine wichtige Voraussetzung für die erfolgreiche Suche ist, dass man sich die in den vorangegangenen Abschnitten diskutierten Punkte klar gemacht hat, dass man weiß, wonach zu suchen ist. Im Folgenden werden einige Beispiele für alternative Lösungen kurz diskutiert:

  • Konfigurationsdateien: In vielen Fällen können XML-Konfigurationsdateien problemlos durch ganz normale Property-Dateien ersetzt werden. Nachdem eine Zeitlang der umgekehrte Weg vorherrschend war, findet man das jetzt wieder häufiger. Dabei muss es nicht beim standardmäßig vorgegebenen Format bleiben, Erweiterungen können mit vergleichsweise einfachen Mitteln implementiert werden. Es existieren diverse Bibliotheken.
  • Druckdokumente: Als Alternative für die Erzeugung hochwertiger Druckdokumente durch das ressourcenintensive XSL/FO-Paar kommt beispielsweise LaTeX in Frage. Ähnlich wie bei XML werden Texte dabei mit einer logischen Auszeichnung versehen. Es gibt eine große Anzahl von stabilen Implementierungen für (fast) alle Rechnerplattformen und Betriebssysteme. Besonders hervorzuheben ist die Eignung für umfangreiche Dokumente. Größere Erfahrungen im Umgang sind außerhalb des Hochschulbereichs nicht so stark verbreitet. Andererseits hat ein erheblicher Teil der Absolventen seine Abschlussarbeit in diesem Format erstellt, sodass es durchaus einiges an Basiskenntnissen gibt, die sich relativ einfach aktivieren lassen.
  • Objektserialisierung: In diesem Bereich war offenbar der „Leidensdruck“ besonders hoch, da hier Alternativen inzwischen Fuß gefasst haben. Am bekanntesten ist JSON (JavaScript Object Notation), ein kompaktes, für Mensch und Maschine lesbares Datenformat. Der Hauptvorteil ist die Kompaktheit – JSON-Dokumente sind deutlich kürzer als vergleichbare XML-Texte. Die Vorteile bei der Verarbeitung und Übertragung sind so wesentlich, dass für Webtechnologien wie REST und Ajax JSON fast schon das Standardformat ist. Eng verwandt mit JSON ist YAML (YAML Ain’t Markup Language), das einen etwas allgemeineren Ansatz verfolgt. In der aktuellen Version YAML 1.2 ist jedes JSON-Dokument auch ein gültiges YAML-Dokument. Für beide Formate existieren Bibliotheken, die den Einsatz, auch mit unterschiedlichen Programmiersprachen, ohne großen Aufwand ermöglichen. Falls erforderlich, ist eine Umwandlung in XML möglich, für Teilbereiche existieren sogar entsprechende Tools.
  • Fachsprachen (DSL – Domain Specific Languages): In vielen Bereichen existieren bereits mehr oder weniger formalisierte Beschreibungen. Solche Fachsprachen (DSLs) sind eine hervorragende Basis nicht nur für die Algorithmenbeschreibung – wo sie seit einiger Zeit wieder verstärkt beachtet werden – sondern auch für die Datenstrukturen. In ihnen manifestiert sich jahrelange Erfahrung, die sie für den betrachteten Bereich zu einer nahezu optimalen Lösung machen. In der Praxis sollte man sich nicht davon abschrecken lassen, dass diese Formalismen zu den Rändern hin manchmal etwas „ausfransen“, d. h. weniger streng oder eindeutig sind. Das ist eine notwendige Bedingung für ihre lebendige Weiterentwicklung. Es gibt immer einen Kern, auf den die implementierte Fachsprache beschränkt werden kann. Diese Einschränkung darf (und sollte) durchaus auch im Hinblick auf die einfache Implementierbarkeit erfolgen. Wichtig ist, dass wie bei XML die Texte lesbar sind. Erstellt werden sie im Allgemeinen durch Programme oder mithilfe von Programmen, wodurch das Einhalten der Beschränkungen leicht garantiert werden kann.

Zusammenfassung

XML ist ein Bündel von bewährten Technologien, das sich in vielen Bereichen als effektiv erwiesen hat. Allerdings ist die Verwendung im laufenden Betrieb oft nicht sehr effizient. Entscheider stehen deshalb vor der schwierig zu beantwortenden Frage, ob die Effizienz der Erstellung oder die Effizienz im Betrieb höher zu bewerten ist. Die Antwort hängt immer von den konkreten Umständen ab. Im Artikel wurden die wichtigsten Einflussfaktoren dargestellt und diskutiert. Dabei wollten wir XML nicht verdammen, sondern das Gespür dafür schärfen, dass es sich um eine Technologie handelt, die wie alle ihre Vor- und Nachteile hat, und die deshalb vor jeder Adaption ebenso gründlich bewertet werden muss. Es gibt oft Alternativen, nur sind sie meist weniger bekannt. Nicht zu vergessen: Mit Bewährtem geht man zwar kein oder nur ein geringes Risiko ein, aber auf neuen Wegen sind die größeren Erfolge möglich.

Links & Literatur

[1] Stefan Mintert: „Freie Bahn – Neue Elemente, weniger Einigkeit“, iX Sonderheft „Webdesign“ 2/2012

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -