OTDS Compressed - ein verwirrender Name
Auf der Info-Veranstaltung "Beefed-Up by OTDS" des OTDS-Vereins, die am 27.9.2016 in Köln stattfand, war angekündigt, etwas zu der Neuerung "OTDS Compressed" zu berichten. Leider gelang es aus technischen Grümdem lediglich, eine allgemeine Einführung in das Problemfeld der OTDS-Produktion von Linienflügen zu geben.
Die Argumentation geht dahin, dass ein Linienflug-Produkt sich stark von Veranstalter-Flügen bzw. Charterflügen unterscheidet, da mehr Parameter zur Suche des Produkts benötigt werden. In der Konsequenz entstünde aufgrund der Regelbasiertheit von OTDS eine Vielzahl von einzelnen Flug-Komponenten, da sich die Preis-Berechnung nicht ohne weiteres abstrahieren lässt. Das dadurch entstehende XML-Markup wäre demnach eine Ineffizienz, da zuviel "Overhead" in Form von XML-Tags benötigt würde.
Als Ausweg wird wohl eine "flache Datenlieferung" in Form einer in das OTDS eingebetteten "Tabelle" angestrebt, die bereits fertig ausgerechnete Produkte zeilenweise enthält.
Leider ist dieses Thema von außen betrachtet nicht schlüssig und - entgegen der bisherigen Praxis - auch nicht vorab dokumentiert.
Zum Einen ist das Argument des Overheads durch XML nicht stimmig. Genau so gut kann man sich darüber beschweren, dass die menschliche Sprache zuviele Redundanzen enthält. Im normalen Gebrauch stört das nicht. Setzt man moderne Tools zur Verarbeitung ein, spielen die Tags in Punkto Laufzeit-Effizienz ohnehin keine Rolle. Ein weiteres Argument, nämlich das der zu großen Dateien, ist noch leichter zu widerlegen. Eine XML-Datei mit vielen redundaten Elementen wird mit einem Kompressionsverfahren wie zip komplett eingedampft, da bleibt kaum was vom "Overhead" übrig und der Transport ist kein Problem mehr.
Jede moderne Programmierplatform bietet die Möglichkeit, riesige Dateien häppchenweise zu verarbeiten. Alle, die schonmal echte Big-Data-Probleme gelöst haben, wissen das und können damit umgehen. Warum sollten also einige Milliarden Bytes an dieser Stelle überhaupt zum Thema gemacht werden?
Daher besteht die Gefahr, dass hier in Wirklichkeit der Versuch gestartet wurde, die alte, flache Datenwelt quasi durch die Hintertür wieder salonfähig zu machen. Die Flugdaten liegen doch als Flatfile-Cache vor, warum also diese nicht direkt in den OTDS-Container reinwerfen und durchtunneln? Und nach der gleichen Logik schieben wir dann als nächstens die fertig ausgerechneten Cache-Files der EDF-Player nach etc.
Da stellen sich dann gleich zwei Fragen:
1. Warum entwirft man ein regelbasiertes Datenformat, wenn man eigentlich lieber flache Dateien verarbeiten möchte?
2. Warum nennt man das Kind nicht beim Namen und sagt dazu OTDS-Expanded statt OTDS Compressed?
Wenn nämlich bereits fertig ausgerechnete Produkte in die OTDS-Lieferung packt, stellen diese die expandierten Komponenten dar.
Es bleibt zu hoffen, dass hier bald eine Klarstellung erfolgt, verbunden mit einem Bekenntnis zum regelbasierten Ansatz des Formats.
Die Argumentation geht dahin, dass ein Linienflug-Produkt sich stark von Veranstalter-Flügen bzw. Charterflügen unterscheidet, da mehr Parameter zur Suche des Produkts benötigt werden. In der Konsequenz entstünde aufgrund der Regelbasiertheit von OTDS eine Vielzahl von einzelnen Flug-Komponenten, da sich die Preis-Berechnung nicht ohne weiteres abstrahieren lässt. Das dadurch entstehende XML-Markup wäre demnach eine Ineffizienz, da zuviel "Overhead" in Form von XML-Tags benötigt würde.
Als Ausweg wird wohl eine "flache Datenlieferung" in Form einer in das OTDS eingebetteten "Tabelle" angestrebt, die bereits fertig ausgerechnete Produkte zeilenweise enthält.
Leider ist dieses Thema von außen betrachtet nicht schlüssig und - entgegen der bisherigen Praxis - auch nicht vorab dokumentiert.
Zum Einen ist das Argument des Overheads durch XML nicht stimmig. Genau so gut kann man sich darüber beschweren, dass die menschliche Sprache zuviele Redundanzen enthält. Im normalen Gebrauch stört das nicht. Setzt man moderne Tools zur Verarbeitung ein, spielen die Tags in Punkto Laufzeit-Effizienz ohnehin keine Rolle. Ein weiteres Argument, nämlich das der zu großen Dateien, ist noch leichter zu widerlegen. Eine XML-Datei mit vielen redundaten Elementen wird mit einem Kompressionsverfahren wie zip komplett eingedampft, da bleibt kaum was vom "Overhead" übrig und der Transport ist kein Problem mehr.
Jede moderne Programmierplatform bietet die Möglichkeit, riesige Dateien häppchenweise zu verarbeiten. Alle, die schonmal echte Big-Data-Probleme gelöst haben, wissen das und können damit umgehen. Warum sollten also einige Milliarden Bytes an dieser Stelle überhaupt zum Thema gemacht werden?
Daher besteht die Gefahr, dass hier in Wirklichkeit der Versuch gestartet wurde, die alte, flache Datenwelt quasi durch die Hintertür wieder salonfähig zu machen. Die Flugdaten liegen doch als Flatfile-Cache vor, warum also diese nicht direkt in den OTDS-Container reinwerfen und durchtunneln? Und nach der gleichen Logik schieben wir dann als nächstens die fertig ausgerechneten Cache-Files der EDF-Player nach etc.
Da stellen sich dann gleich zwei Fragen:
1. Warum entwirft man ein regelbasiertes Datenformat, wenn man eigentlich lieber flache Dateien verarbeiten möchte?
2. Warum nennt man das Kind nicht beim Namen und sagt dazu OTDS-Expanded statt OTDS Compressed?
Wenn nämlich bereits fertig ausgerechnete Produkte in die OTDS-Lieferung packt, stellen diese die expandierten Komponenten dar.
Es bleibt zu hoffen, dass hier bald eine Klarstellung erfolgt, verbunden mit einem Bekenntnis zum regelbasierten Ansatz des Formats.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded