Woran erkennt man ein gutes XML-Format?

Man kann trefflich darüber philosophieren, ob es überhaupt so etwas wie ein „gutes XML-Format“ geben kann. Denn bekanntlich gibt es ja nichts Richtiges im Falschen1. Aber wer sich schon immer gefragt hat, woran man gute XML-Formate erkennen kann, dem gebe ich hier gern meinen stark subjektiv eingefärbten Regelsatz mit.

Daran:

Klare Problemstellung

Ein gutes XML-Format versucht eine möglichst klar abgegrenzte Problemstellung zu lösen. Je weiter die Aufgabe ausfranst, um so größer und unhandlicher wird das Format, da dann oft mehr Variationen innerhalb des Formats notwendig werden und mehr Sonderfälle berücksichtigt werden müssen. Natürlich gibt es immer Fälle, in denen das Problem komplex ist. Aber oft genug wäre es besser gewesen, die Problemstellung in mehrere einfachere Teile zu zerlegen, die entsprechend leichter zu implementieren sind.

Beispiel: Ein Austauschformat für Rechnungen braucht keine Strukturen für einen kompletten Produktkatalog. Es ist besser, für den Produktkatalog ein eigenes Format zu verwenden.

Wenige Autoren

Aus meiner Erfahrung muss ich feststellen, dass Formate, die von großen Komitees geschrieben wurden, in der Regel sehr viel schlechter sind, als die, die von kleinen Komitees oder nur wenigen Autoren geschrieben wurden. In großen Entscheider-Gruppen herrscht leider oft der Eindruck vor, dass jeder Einzelne „seine“ Punkte möglichst gut durchsetzen muss, anstatt eine möglichst gute Entscheidung herbeizuführen.

Gute Dokumentation

Ohne eine gute Dokumentation ist selbst ein sonst gutes XML-Format nichts wert. Wenn die Dokumentation unklar oder sogar falsch ist (dazu gehört auch, dass die Dokumentation nicht dem Schema des Formats entspricht), muss der Entwickler, der das Format Nutzen will, entweder den Support der Autoren suchen, selbst recherchieren oder raten. Davon abgesehen, dass die Qualität des Ergebnisses leiden kann, zeigt es mangelnden Respekt vor den Entwicklern, die dieses Format verwenden wollen, denn deren Zeit wird unnötig verbrannt.

Gut lesbares XML

Wenn man es genau nimmt, ist XML ein Binärformat – aber eines, das von Menschen gelesen werden kann2. Und als solches sollte es auch verstanden sein, wenn man ein XML-Format definiert.

Ein deutliches Alarmsignal sind für mich meist Elementnamen in Versalien. Die sind extrem schwer lesbar. Ich persönlich finde Elementnamen in Kleinbuchstaben mit Trennungen durch Bindestriche am besten lesbar. Aber auch camelCase oder UpperCamelCase sind besser lesbar als Versalien.

Das XML-Format sollte möglichst sprechende Element- und Attributnamen verwenden. Oft erkennt man bereits an den Elementnamen, das es sich beim XML um eine reine Ausgabe einer Datenbank-Tabellen-Struktur handelt. Das daraus resultierende XML-Format ist dann leider oft auch nicht berauschend.

Hierarchische Datenstruktur

Wenn man in einem XML-Format auf Datenstrukturen trifft, die, obwohl sie recht komplex sind, relativ flach aussehen, dann hat man es vielleicht mit einem Fall von schlecht aufgebauten Datenstrukturen zu tun. Ein klassischer Fehlgriff sind stumpf nacheinander in XML überführte Datenbanktabellen. Wenn die Tabellen inhaltlich keine Bezugspunkte zueinander haben, gehören sie meist auch nicht in das selbe XML-Format. Wenn die Tabellen zueinander in Beziehung stehen, dann sollten die Daten in einer gemeinsamen Struktur landen, welche die Beziehungen über die Hierarchie abbildet.

Moderate Nutzung fremder Vokabulare

Natürlich ist es gut, wenn ein XML-Format möglichst kompakt und in sich geschlossen ist. Aber was spricht dagegen, kleine Teile eines Vokabulars zu verwenden, das bereits jemand anderes einmal sauber durchdefiniert hat? Man denke nur mal an so etwas wie die Nutzung des Vcard-Vokabulars für Kontakt- oder Adressdaten.

Allerdings ist das immer auch eine Frage des Abwägens: Es ist niemandem geholfen, wenn ein XML-Format aus einer riesigen Menge unterschiedlicher fremder Vokabulare definiert wird. Das hilft Entwicklern bei der Nutzung dieses Formats auch nicht unbedingt.

Sparsame Verwendung von XML-Namespaces

„XML namespaces are an imperfect solution to a difficult problem“, (wie schon Uche Ogbuji schrieb3). Die Kunst beim Entwerfen eines Formats liegt darin, genau die richtige Menge von Namespaces zu verwenden. Zu viele Namespaces sind schlecht – zu wenige aber auch. XML-Namespaces haben ihre Daseinsberechtigung – so lange sie korrekt eingesetzt werden4.

Wenig Überraschungen

Je klarer und eindeutiger ein Format spezifiziert ist um so besser. So ist es beispielsweise immer eine gute Idee, wenn nur ein Format für ein Datum definiert wird und nicht Dutzende. Dann muss nämlich auch nur eine Validierung für ein Format implementiert werden. Und es kann dann auch nicht passieren, dass Datumsangaben an zwei Stellen in zwei unterschiedlichen Formaten erfolgen müssen5.

War das alles?

Nein, sicher nicht. Aber als eine kleine Richtschnur sollte es reichen.

  1. Das geflügelte Wort stammt von Adorno und lautet eigentlich korrekt: „Es gibt kein richtiges Leben im falschen.“ https://de.wikipedia.org/wiki/Es_gibt_kein_richtiges_Leben_im_falschen
  2. Das stammt von davetron5000: http://stackoverflow.com/questions/116195/before-xml-became-a-standard-and-given-all-its-shortcomings-what-made-xml-so-po#comment24355_116230
  3. „Principles of XML design: Use XML namespaces with care“ http://www.ibm.com/developerworks/library/x-namcar/
  4. Ein paar gute Beispiele dazu liefert http://www.rpbourret.com/xml/NamespacesFAQ.htm#ns_2
  5. Glaubt mir, das gibt es wirklich.