FAQ | OTDS

Welche Regeln gelten für die Benennung einer OTDS-Datei?

Weiterführende Informationen finden OTDS e.V.-Mitglieder in der Thematischen Spezifikation

Allgemein

Lieferungen erfolgen grundsätzlich als .zip-Datei.
Diese Datei darf ausschließlich eine oder mehrere XML-Dateien enthalten. Die Dateiendung der Dateien muss .xml sein.
Es dürfen keine Unterverzeichnisse verwendet werden.
Alle Dateinamen (außer delivery.xml) müssen mit einer 3-stelligen bzw. (falls die 3 Stellen nicht genügen) mit einer 5-stelligen Ziffernfolge beginnen. Ist die Zahl zu klein, wird diese mit vorangestellten Nullen auf drei bzw. fünf Stellen gebracht.
Die Ziffernfolgen müssen eindeutig sein.
Dateinamen können nach den 3 bzw. 5 Ziffern optional weitere Zeichen enthalten. Diese Zeichen dürfen ausschließlich aus der Menge a-z, A-Z, 0-9, "-" (Minus) und "_" (Unterstrich) stammen.
Die Zip-Datei muss eine Datei delivery.xml enthalten. Diese Datei enthält zusätzliche Informationen zu dieser Lieferung.

Aufbau der XML-Dateien

Alle XML Dateien müssen über eine korrekte Angabe des Zeichensatzes in der ersten Zeile der Datei verfügen: <?xml version="1.0" encoding="UTF-8"?>
Als Zeichensatz für alle XML Dateien sollte der UTF-8 Zeichensatz verwendet werden. Wenn von dieser Empfehlung abgewichen wird, so ist der abweichende Zeichensatz korrekt in der obigen XML Deklaration in allen Dateien anzugeben.
Jede der XML.Dateien (außer die "delivery.xml") muss einzeln über die incremental-XSDs, die in jeder Version der OTDS-Specification enthalten ist, validierbar sein.

Was ist wichtig hinsichtlich der Validierung der Datenlieferung?

Die gelieferten Datenbestände müssen zu jedem Zeitpunkt gegenüber der original OTDS-Schemadatei "otds.xsd " validieren, das heißt, dass zu jedem Zeitpunkt ein gültiger Datenbestand vorhanden sein muss.

Bei der Lieferung von mehreren Dateien in einer Lieferung muss jede Einzeldatei zusätzlich eine Validierung gegen inkrementelle XSD bestehen, bei der der Großteil der Elemente optional ist. Diese XSD (otds.xsd) befindet sich im Schemaverzeichnis im Unterverzeichnis "incremental_xsds".

Welches ist die XSD-"Master"-Datei?

Starten Sie für alle Aktivitäten in den XSD-Dateien mit der Datei otds.xsd. In diese Datei sind alle anderen XSD-Dateien integriert.

Warum gibt es SellingAccom?

SellingAccom enthält die verkaufsrelevanten Daten der Unterbringung, u.a. die Preise und Verfügbarkeiten. Hier wird über die Kombination von bestimmten Zimmern (Unit) und Verpflegung (Board) das eigentliche Produktangebot definiert.

Häufig geht es dabei um den Vertrieb für unterschiedliche Kundengruppen, wie z.B. Familien, junge Paare oder Singles. Zudem werden hier neben den Buchungsparametern (Booking) auch die Eigenschaften der Unterkunft sowie inkludierte Zusatzleistungen in den Properties festgehalten.

SellingAccoms entsprechen quasi Saisons. In der Praxis hat sich gezeigt, dass bei Reiseveranstaltern eine Limitierung auf maximal zehn SellingAccoms sinnvoll ist, denn kein Veranstalter arbeitet wirklich mit mehr Saisons. Für Bettenbanken macht diese Limitierung hingegen keinen Sinn.

Jeder Knoten "SellingAccom" erfordert die Angabe eines eindeutigen Schlüsselwertes für diesen Knoten. In der Regel wird der Schlüsselwert den Buchungscode der Unterkunft und ggf. Saisonkennzeichen oder Reiseart als Parameter enthalten.

Warum gibt es SellingUnit?

SellingUnit enthält alle verkaufsrelevanten Daten des Zimmers für den Vertrieb. Dabei werden neben den Buchungsparametern (Booking) auch die Verfügbarkeiten und die Eigenschaften (Properties) des Zimmers definiert. Durch Filter kann ein Zimmer auf bestimmte Bedingungen begrenzt werden (z.B. nicht buchbar zwischen November und Februar). Alle unter SellingUnit gelieferten Preisbestandteile (PriceItems) gelten nur für das jeweilige Zimmer. Häufig geht es dabei auch um unterschiedliche Belegungen, die auch andere Preise nach sich ziehen. Wichtig: Jeder Knoten "SellingUnit" erfordert die Angabe eines eindeutigen Schlüsselwertes.

Kann ich Freitext in Properties schreiben?

Freitext kann nur in bestimmten Properties verwendet werden:

Zahlreiche Properties erlauben KEINEN Freitext. Aus Gründen der Vereinheitlichung werden in diesen Properties Werte aus einer vorgegebene Liste gewählt.
Bei den Name-Properties ist die Eingabe von Freitext erforderlich, weil diese nicht standardisiert werden können. Konkret sind dies die Properties AccommodationName (Name der Unterbringung, z.B. "Hotel zum Schwan"), UnitName (z.B. "Appartment mit Balkon"), BoardName (Bezeichnung der Verpflegungsleistung, z.B. "Halbpension Plus") sowie AddonName (Bezeichnung der Zusatzleistung, z.B. "Tauchausflug")
Schließlich gibt es noch Properties, deren Inhalte zwar frei eingegeben werden müssen, deren Form jedoch vorgegeben ist, wie beispielsweise bei AccommodationAddress die Unterelemente Street, Mail etc.

Seit OTDS 2.0 ist darüber hinaus die Integration von Nonbookable Content möglich. Dieser Nonbookable Content wurde für die Properties AccommodationInfo, AccommodationCityInfo, UnitInfo, BoardInfo, AddonInfo, AddonServiceInfo, AddonServiceFeatureInfo eingerichtet und erlaubt strukturierten Text.

Wie strukturiere ich PriceItems?

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.

Wie werden Entfernungen definiert?

Entfernungen werden mit Hilfe von "Figures" definiert. Die Entfernungen zu den relevanten Zielen (z.B. Strand, Stadtzentrum, Einkaufszentrum, Flughafen, Haltestelle, Skilift etc.) werden als ganze Zahl in Metern angegeben.