In welchem Format sollen IT-Systeme Daten austauschen? Modellbasiert mit XML? Oder gibt es auch Gründe, einfache und modellbefreite Formate wie CSV zu verwenden?
Wir leben im einem Zeitalter vernetzter IT-Systeme: Applikationen ohne Datenaustausch-Schnittstellen zu anderen Systemen sind kaum noch zu finden. Wie aber tauschen Systeme diese Daten aus? Dazu hatte ich letztens eine interessante Diskussion mit meinem Kollegen Stephan Heuel. Die Erkenntnis daraus: Die Vor- und Nachteile verschiedener Formate ändern mit dem Anwendungszweck – genau wie bei einem Taschenmesser braucht man das passende Werkzeug für eine Aufgabe.
XML und Co. – modellbasiert und umfassend
In den Projekten, an denen ich aktuell arbeite, implementieren wir die meisten Schnittstellen mit XML (oder INTERLIS, aber das ist ja auch XML). XML wird meist benutzt, wenn ein ausgearbeitetes Datenmodell vorliegt. Die Modelldefinition kann in einem standardisierten Format beschrieben werden und es gibt Werkzeuge, mit denen man Dateien validieren kann. Alle Formate unterstützen die Umsetzung von komplexen Datenmodellen.
Aus meiner Sicht bieten diese Formate verschiedene Vorteile:
- Die Modellbeschreibung dient als Vertrag für den Datenaustausch. Damit ist für alle beteiligten Systeme klar festgelegt, wie sie die Daten liefern bzw. empfangen müssen.
- Wenn mein System Daten erhält, kann ich diese mit Standardwerkzeugen einfach validieren, ohne dass ich dafür eigene Prüfmethoden oder -werkzeuge entwickeln muss.
- Wenn das Datenmodell für den Austausch identisch mit dem Datenmodell meiner Applikation ist, braucht es keine Modelltransformation beim Import oder Export von Daten. Ich muss zugeben, dass das in einigen Fällen eine egoistische Sichtweise ist, weil der Aufwand bei anderen beteiligten Systemen entsprechend höher sein kann. Gerade im Fall von INTERLIS (da wird es ja schnell aufwändig…) ist es aber praktisch, wenn das Transfermodell und die Quell-/Zielmodelle keine grossen Unterschiede haben (die minimalen Geodatenmodelle bilden dafür eine gute Basis).
Aus diesen Gründen schien es mir klar, dass XML in vielen Anwendungsfällen gegenüber Formaten wie CSV die Nase vorn hat. Man könnte statt XML auch JSON als „fett-freie“ Variante von XML benutzen, da man mit JSON auch Modelle und Strukturen abbilden kann.
CSV und Co. – einfach und zugänglich
Ein modellbasierter Datenaustausch über XML ist in der Theorie immer richtig und in der Praxis insbesondere dann, wenn die Beteiligten sich auf das gleiche Daten bzw. Objektmodell geeinigt haben. Leider ist es so, dass in der Praxis nicht von vornherein klar ist, wer die Empfänger von Daten sind und diese nicht unbedingt das darunterliegende Objektmodell kennen – oder gar nicht daran interessiert sind.
- Aus der Erfahrung sind fachgetriebene Modellbeschreibungen sehr komplex, da jeder Fachexperte, jede Fachexpertin im Zweifelsfall eine Klasse, Attribut oder Relation mehr modelliert statt weniger. Auch minimale Geodatenmodelle sind davor nicht unbedingt geschützt. Dies erschwert die Zugänglichkeit der Daten für Dritt-Entwicklerinnen und -Entwickler teilweise erheblich.
- Die Werkzeuge für den Datenaustausch müssen zugänglich und umfassend unterstützt werden. Dabei haben natürlich generelle, international weit verbreitete Formate wie CSV einen Vorteil.
- Als (fachfremder) Empfänger und Nutzer von Daten gehe ich davon aus, dass die gelieferten Daten fachlich korrekt sind – wieso sollte ich die also nochmals prüfen? Oder, wenn ich sie prüfe, dann möchte ich sie für meinen speziellen Anwendungsfall prüfen, die der Produzent der Daten aber nicht unbedingt kennt.
Daher möchte ich als Nutzer die Daten in einem möglichst einfachen Format lesen, das von jeder Software oder API unterstützt wird. Ein für mich gutes Beispiel für ein sehr zugängliches Datenangebot findet man im Bereich der Fahrplandaten: Das Format General Transit Feed Specification (GTFS) ist eine Sammlung von CSV-Dateien und wird weltweit von Transportunternehmen zur Publikation ihrer Daten benutzt, auch wenn sie intern andere Modelle und Formate benutzen. Für die Schweiz gibt es den ÖV-Fahrplan übrigens unter https://opentransportdata.swiss/de/dataset/timetable-2018-gtfs. Die Daten sind einfach strukturiert und simpel zu importieren. Zwar kann man allenfalls manche Spezialfälle nicht einfach abbilden (beispielsweise eine „Aufteilung der Zugkomposition an einer Haltestelle“), kann aber dafür einen niederschwelligen Zugang zu einem gesellschaftlich wichtigen Datensatz anbieten bzw. nutzen.
Das richtige Werkzeug
Was ist also richtig? In einem konkreten Fall ermittelt man für ein System die Anforderungen und entwickelt anschliessend eine passende Lösung. Dabei wird man die oben aufgeführten Vor- und Nachteile berücksichtigen.
Es gibt aber noch einen weiteren wesentlichen Aspekt: Was ist der Zweck des Datenaustauschs? Beim Anwendungsfall von Stephan geht es darum, Daten öffentlich verfügbar zu machen (beispielsweise als Teil einer Open Data-Strategie). Der Herausgeber stellt die Datenqualität sicher und möchte, dass die Daten einfach und breit einsetzbar sind: Es macht wenig Sinn, allen Nutzerinnen und Nutzern für ihr System ein komplexes Datenmodell aufzuzwingen.
Der Anwendungsfall bei den Systemen, welche JSON oder XML verwenden, ist normalerweise ein anderer: Hier empfängt ein System Daten von anderen Systemen. Um die Datenqualität im Zielsystem sicherzustellen, ist eine Prüfung zwingend. Die oben erwähnten Vorteile des modellbasierten Austauschs zeigen hier ihren Nutzen.
Was denken Sie zur Thematik? Gibt es noch weitere Punkte zu berücksichtigen? Wir freuen uns über einen Austausch, zum Beispiel am 6. oder 7. Juni beim GEOSummit in Bern. Ralph Straumann und Stephan Heuel werden EBP am Stand von Esri repräsentieren und freuen sich auf ein Gespräch. Oder sonst über Social Media oder am nächsten GeoBeer.