Der Blog von fm-ProductNode

BMEcat mit einer XML-Schema-Definition validieren?

Mauersteine
Verfasst von franz-mue am 26. Januar 2018

Warum macht sich fm-ProductNode eigentlich die Mühe, das Rad selbst neu zu erfinden, und prüft eine BMEcat-2005-Datei nicht einfach anhand der XSD-Datei, die ergänzend zur BMEcat-Spezifikation gleich mitgeliefert wird? Auf den ersten Blick stellt sich diese Frage natürlich. In meinem Beitrag erläutere ich, warum die XML-Schema-Datei für den Zweck der BMEcat-Validierung nicht in Frage kommt.

Bereits in meinem BMEcat-Fachbuch habe ich erläutert, dass die zur BMEcat-2005-Spezifikation mitgelieferte XML-Schema-Datei an manchen Stellen von der Spezifikation abweicht. Schon aus diesem Grund allein ist die Verwendung der XML-Schema-Datei nicht zielführend.

Jedoch stellt sich sofort die nächste Frage: Wäre es nicht möglich gewesen, die Fehler und Widersprüche der Schema-Datei auszumerzen, und auf die modifizierte Schema-Datei zurückzugreifen?

Die Frage ist mit "ja, aber" zu beantworten. Die modifizierte Schema-Datei könnte zwar die Struktur eines BMEcat-2005-Dokuments prüfen, eine komplette Validierung wäre auch damit nicht durchführbar.

Der Grund liegt an der Komplexität der BMEcat-2005-Spezifikation. Aus einer oberflächlichen Betrachtung der Spezifikation erschließen sich die Besonderheiten und manche eigenwillige Konstrukte nicht gleich. Erst bei der Vertiefung in die Details der Spezifikation kommen sie zum Vorschein. Ich nenne einige Beispiele (für eine genauere Betrachtung verweise ich auf mein Buch):

  • Manche Identifikator-Elemente sind nicht innerhalb eines gesamten BMEcat-Dokuments eindeutig, sondern innerhalb bestimmter Dokumenten-Bereiche.
  • Es gibt sprachabhängige Identifikatoren. Auf solche sprachabhängigen Identifikatoren verweisen sprachabhängige Referenzen. Um von einer derartigen Referenz auf den zugehörigen Identifikator zu verweisen, verlangt die BMEcat-2005-Spezifikation, dass die zugehörigen Elemente für alle Sprachen in durchgehend derselben Reihenfolge aufzulisten sind.
  • Es gibt Referenzen, die auf unterschiedliche Zielpfade verweisen.
  • Zur Prüfung einiger Referenzen ist die Auswertung von eingebettetem JavaScript Code erforderlich. Der JavaScript Code enthält dabei Variablen, die auf Elementinhalte des BMEcat-Dokuments zurückgreifen.
  • Zweistufige Referenzen; der erste Referenz-Teil grenzt den Ziel-Dokumententeilbaum ein. Der zweite Referenz-Teil wählt innerhalb des vorher bestimmten Dokumententeilbaums das endgültige Referenz-Ziel aus.
  • Existenz-Bedingungen zwischen Dokumententeilbäumen; in einigen Fällen sind Dokumentenbereiche an unterschiedlichen Stellen des BMEcat-Dokuments über Verbindungen logisch verknüpft. Es handelt sich um Bedingungen der Art wenn-dann, wenn-nicht-dann oder wenn-nicht-dann-nicht. Ob die Bedingung im Anschluss tatsächlich zu prüfen ist, hängt teilweise von dem Vorhandensein eines weiteren Dokumentenpfades ab.

Zumindest ein Punkt könnten dabei im Rahmen einer XML-Schema-Definition abgehandelt werden: Verschiedene, alternativ in Frage kommende Referenzziele könnten zum Beispiel mittels Pipe in einem XPath-Ausdruck formuliert werden.

Darüber hinaus ist darauf hinzuweisen, dass eine XML-Schema-Definition von Hause aus hauptsächlich dafür gedacht ist, eine bestimmte Struktur für eine XML-Datei sicherzustellen. Für eine weitergehende Validierung sollten andere Werkzeuge ins Visier genommen werden. Ein mächtigeres Hilfsmittel wäre etwa mit dem Schematron-Ansatz gegeben. Per Schematron-Einsatz könnte ein größerer Anteil der Validierung abgedeckt werden als per XSD - kaum jedoch vollständig.

Es gibt einige weitere Gründe, warum fm-ProductNode die Validierung eines BMEcat-2005-Dokuments selbst übernimmt, und dabei auf das YAML-Format anstelle des XML-Formats baut:

Als erstes ist dabei die bessere Lesbarkeit in Texteditoren von YAML-Dateien gegenüber XML-Dateien zu nennen.

fm-ProductNode erlaubt beim Validieren oder Einlesen von BMEcat-Dokumenten zusätzliche anwenderspezifische Validierungen oder Anpassungen der Inhalte. Mit der Hinterlegung eines XML-Schemas wäre diese Funktionalität nicht so einfach zu realisieren.

Das feingranulare Einstellen von Verarbeitungsmodi für das Validieren oder Einlesen von BMEcat-Dokumenten wäre ohne Eigenimplementierung ebenfalls schwierig zu umzusetzen.

Und schließlich generiert fm-ProductNode für einen erheblichen Teil der Schnittstellen den Code automatisch aus den YAML-Definitionsdateien. Gleiches gilt für einen erheblichen Teil der Testfälle zum Schnittstellen-Code. Eine Realisierung per XSD/XSL/XPath würde für die Entwicklung die Verwendung weiterer Programmiersprachen bedeuten. Damit verbunden wäre insbesondere eine höhere Gesamtkomplexität.

Die vollständige Implementierung der BMEcat-2005-Validierung in der Programmiersprache PHP bedingte einen ausgesprochen hohen Ressourcen-Aufwand. Aus meiner Sicht war er notwendig, denn die "üblichen Verdächtigen" XSD/XSL/XPath hätten nicht ausgereicht.

Tags: BMEcat, Validierung, XML, Yaml, XSD, Schematron
Foto: bluebudgie / pixabay.com

« Ein neues Fundament für das eBusiness (II): Bestandsaufnahme