Sind regelbasierte Datenformate wie OTDS zu kompliziert für Bettenbanken oder andere Aggregatoren? Das kommt darauf an, welchen Teil des Angebots wir betrachten.
Fall 1
Oft handelt es sich bei den angebotenen Produkten um Durchverkäufe, bei denen die Angebotsdaten lediglich als mehr oder weniger vorausberechnete Preise pro Zimmer und Nacht bzw pro Person und Nacht vorliegen. In solchen Fällen sind die Regeln für die Preisberechnungen den Anbietern selbst nicht mehr bekannt, es kommt lediglich eine Aufschlagskalkulation auf die Zimmerrate zum Einsatz. Eine Lieferung solcher Konstrukte gestaltet sich in OTDS in der Tat umständlich und ineffizient, da der eigentliche Anwendungsfall von OTDS, die Erstellung der Angebote auf den Abnehmer zu verlagern und lediglich das Regelwerk dafür zu liefern, verfehlt wird.
Fall 2
Ein kleinerer Anteil des Portfolios einer Bettenbank stammt jedoch aus dem eigenen Inventar, hier sind Regeln für Basispreise, Sonderangebote, Specials etc. bestens bekannt und lassen sich sehr gut in OTDS ausdrücken.
Die Frage ist, ob OTDS für Bettenbanken bereits in der heutigen Form ein attraktives Format darstellt, oder ob OTDS um eine Möglichkeit erweitert werden sollte, die eine effiziente Übermittlung der Zimmerraten aus Fall 1 unterstützt. Im Technischen Ausschuss des OTDS-Vereins wurden dazu erste Überlegungen angestellt, um mit einem sogenannten SimplePriceItem eine Vereinfachung Abbildung "flacher" Daten zu erreichen. Doch wird mit einem solchen Ansatz wirklich eine attraktivere Lösung für Bettenbanken möglich? Es ist eher so, dass eine Einführung von SimplePriceItems auch den Wunsch nach einer Kombinierbarkeit dieses Elements mit bisherigen Konstrukten aufkommen lässt. Im Ergebnis wird die Nutzung von OTDS komplizierter, abgesehen davon, dass die bisherigen Verarbeiter solche Erweiterungen vermutlich nur zögernd umsetzen würden.
Es vermutlich sinnvoller, den bestehenden Sprachumfang zu vereinfachen, Mehrdeutigkeiten zu beseitigen und gleichzeitig die Vorteile regelbasierter Datenlieferungen auch im internationalen Umfeld besser darzustellen.
Während der gemeinsamen Sitzung der DRV-Ausschüsse Dynamisch produzierende Veranstalter, Informationstechnologie und Onlinevertrieb am 16. September 2019 hat a-five das Thema Datenqualität nochmal unter dem Aspekt der Automatisierung mit Hilfe des Offer Inspectors dargestellt. Hier die Präsentation zum kostenlosen Download.
Wie Amadeus am 13.2.2019 in seinem Blog-Post "I killed Kati" mitteilte, bilden die im OTDS-Format angelieferten Daten inzwischen den größten Anteil im Cache des Anbieters. Was wohl zum Aussterben des ersten, ansatzweise regelbasierten Formats KATI führte.
Damit stellt sich die Frage, ob das letzte Legacy-Datenformat INFX das gleiche Schicksal ereilen wird. Unsere Prognose: nein. Im gegensatz zu KATI wird INFX quasi als universelles Format anbieterübergreifend genutzt. Die Vorteile eines regelbasierten Formats wie OTDS lassen sich nur dann nutzen, wenn in kleinteiligen Kontexten live angefragt und gesucht wird. Dann sinken Preis- und Verfügbarkeitsfehler dramatisch und die Aktualisierung der Suchmaschine wird auf Komponentenebene möglich. Zum Massenausrechnen taugt OTDS in der heutigen Fassung leider nur bedingt und es wird in diesem Feld von anderen Formaten deutlich geschlagen.
Abhilfe schaffen könnte hier das konsequente Aufräumen und ein beherztes Refactoring des Standards, davon ist aber die aktuelle Roadmap von OTDS weit entfernt.
Um das Bild nochmal aufzugreifen: I shot the sheriff, but I didn't shoot the deputy. Und somit leben wir weiter mit ausgerechneten und veralteten Angeboten im INFX-Format.
Wie zu lesen war, hat der Veranstalter Bentour seine komplette Distribution auf OTDS umgestellt. Laut eigenen Angaben sollen dadurch Ausgaben i.H.v. 100.000 EUR für den Betrieb aufwendiger Lösungen für INFX und KATI-Produktion eingespart werden.
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.
a-five gibt die Plattform OTDS Inspector zur Nutzung frei. Die seit dem ersten August verfügbare Version unter dem Codenamen "Dr. Watson" verarbeitet OTDS 1.9.3 aus unterschiedlichen Quellen, darunter WBS Blank, Bewotec, FTI i-five und dem hauseignenen OTDS-Caster.
Der OTDS-Inspector kann in unterschiedlichen Ausbaustufen eingesetzt werden:
Wie am 10.6.2016 mehrfach zu lesen war, werden neben den Nur-Hoteldaten nun auch die Pauschalreisen von Schauinsland-Reisen im OTDS-Format an Traveltainment geliefert.
Die Generierung der OTDS-Angebotsdaten erfolgt mit einem speziellen Tool der WBS Blank Software GmbH direkt aus dem gleichnamigen Veranstaltersystem heraus, das Schauinsland-Reisen seit Jahrzehnten mit Erfolg einsetzt. Für WBS Blank ist Schauinsland-Reisen erfolgreicher Pilot für die OTDS-Produktion, die nun für zahlreiche weitere Kunden des Veranstaltersystems eingerichtet wird. Zur zusätzlichen Qualitätssicherung kommt zudem der „OTDS-Inspector“ des Solution Providers a-five zum Einsatz.
Schließlich folgt in Kürze die Umstellung der Datamix-Produktion für die dynamisch paketierten Reisen auf OTDS. Dann sind die Angebotsdaten des Duisburger Reiseveranstalters komplett in diesem Format verfügbar.
Mehr Details finden sich zum Beispiel im Bericht des OTDS-Vereins.
Auf dem Amadeus-Blog erklärt Traveltainment, warum mit der Umstellung auf OTDS die heutige Praxis der Vorausberechnung und Übertragung gewaltiger Datenmengen vermieden wird. Für OTDS-Lieferungen gilt demnach: Alle Daten sind drin, aber sie werden nur im Anfragefall zu Angeboten ausmultipliziert.
Und wenn Sie selbst prüfen wollen, ob bestimmte Angebote aus Ihren OTDS-Daten errechnet werden, emfiehlt sich zum Beispiel der Einsatz des OTDS Inspectors von a-five.
a-five kündigt eine neue Version des OTDS Inspector an. Für das Beta-Testprogramm unter dem Codenamen "The Mentalist" kommen mit Version 5 vor allem Usability und interne Verbesserungen dazu:
Dashboard
Komprimierte Datenlieferung
Autocomplete-Funktion bei der Definition von Testfällen
Der Standard OTDS ist eine XML-Sprache, in der touristische Produkte definiert werden. Dazu gehören die strukturierte Produktbeschreibung so wie das Regelwerk zur Berechnung der Verfügbarkeiten und Preise. Eine OTDS-Datei ist also nicht bloß eine Datenlieferung. Besser wäre es, von einem Quelldokument zu sprechen, ähnlich einem Programm in einer Programmiersprache. Insofern unterscheidet sich OTDS fundamental von allen anderen aktuellen Datenformaten, insbesondere von EDF oder KATI, die lediglich mehr oder weniger strukturierte Datenbeschreibungen darstellen und damit Spielraum für Interpretationen bei der Verarbeitung lassen.
Greifen wir die Analogie zu einem Computerprogramm auf, dann lassen sich zwei Aufgaben klar voneinander trennen. Auf der einen Seite besteht die Aufgabe, das Programm zu schreiben. Auf der anderen Seite muss das Programm ausgeführt werden.
Die Herausforderungen bei der Erstellung von OTDS unterscheiden sich stark von denen bei dessen Ausführung. Auch hier gibt es Analogien. Die Erstellung eines OTDS-Dokuments ist vergleichbar mit dem Programmieren in einer Programmiersprache. Die Erstellung einer OTDS-Verarbeitung ist wie die Entwicklung eines Compilers oder besser, eines Interpreters zu sehen.
Auf beiden Seiten werden jedoch Entwickler die Sprachkonstrukte erlernen und mit der Spezifikation von OTDS arbeiten. Für diejenigen, die an einer Ausführung von OTDS arbeiten, gab es auf dem letzten OTDS-Event im Herbst 2015 einen Erfahrungsbericht aus Sicht eines Entwicklers.
