XML Validierung - wozu? / Interessenkonflikte

Interessenkonflikte

Interessenkonflikte

➪ In der Praxis kann es vorkommen, daß die Interessenlage des Datenlieferanten und des -empfängers hinsichtlich der Qualität der bereitgestellten Daten (wie auch des XML Schema) unterschiedlich ist. Nicht immer findet eine gegenseitige Abstimmung statt. Welche Konsequenzen kann das haben?

Idealerweise stellen Datenlieferanten laufend aktualisierte Informationen zur Verfügung. Daten-Consumer verarbeiten die bereitgestellten XML-Dokumente mit Hilfe von mehr oder weniger komplexen Verarbeitungslogiken. Ein solide definiertes XML Schema (Elemente, Attribute, Namespaces, Typen) dient beiden Seiten als Arbeitsbasis. So weit die Theorie.

Grundsätzlich gibt es folgende Szenarios:

Die Interessenlage des Datenlieferanten

Ein gängiges Rollenverständnis mancher Datenlieferanten basiert auf dem Argument: "Wir stellen Daten bereit. Was die Anwender damit machen, steht nicht unter unserer Kontrolle." Das mag zutreffen, sollte aber kein Grund sein, mit den Anwendern über deren Bedarfe nicht kommunizieren zu müssen.

Gleichwohl können Datenlieferanten im Regelfall keineswegs souverän und eigenmächtig entscheiden, welche Informationen sie den Empfängern gnadenhalber zukommen lassen wollen. Sie sind ihrerseits abhängig nicht nur vom internen Kostendruck, sondern unter anderem auch von gesetzlichen Regelungen, Management- und Empfängerwünschen sowie deren häufig wechselnden Anforderungen.

Der Lieferant kann die Verpflichtung zu hoher Datenqualität als Belastung empfinden. Ihre Einhaltung zieht zusätzlichen Aufwand nach sich, der sogar ganz erheblich sein kann, kostet also Geld. Ist der Consumer nicht bereit, das zu honorieren, bleibt der Lieferant auf den Kosten sitzen.

In diesem Fall liegt das Interesse des Lieferanten in der Bereitstellung einer Datenstruktur, die sich an möglichst breite Abnehmerkreise richtet. Die Anforderungen an die Datenqualität wird flach gehalten, entsprechend allgemein fällt die Definition des XML Schema aus. Die Verantwortung dafür, daß die Empfänger die mit der Datenverwendung angestrebten Zwecke erreichen, wird gezielt begrenzt.

Definiert der Datenlieferant das XML Schema, ohne die Datenempfänger ausreichend in die Strukturdefinition einzubinden, dann ist es möglich,

Änderungen der XML-Input-Dokumentstruktur

Es kommt gar nicht selten vor, daß eine Änderung der XML-Dokumentstruktur unvermeidlich ist. Komplexe Systeme leben nun einmal, Änderungen müssen möglich sein.

Jede Änderung der definierten Datenstruktur erfordert eine entsprechende Anpassung sämtlicher Verarbeitungslogiken, die von dieser Änderung betroffen sind, und zwar auf beiden Seiten: der Datenlieferant muß seine Prozesse anpassen, um die geänderten Daten-Strukturen zu generieren. Jeder Daten Consumer muss seine Programmlogiken zur Verarbeitung des geänderten Inputs ebenso anpassen.

Kleine Ursache: große Wirkung. Eine scheinbar geringfügige Änderung des XML Schema kann überproportional hohe Anpassungen in der Programmlogik auf beiden Seiten nach sich ziehen. Daher ist es sinnvoll, die Notwendigkeit von Änderungen sorgfältig abzuwägen.

Nicht jeder Developer, der das XSD betreut und es schick findet, "mal eben" ein Feld, das bisher klein geschrieben wurde (<xs:element name="lastname"/>), nun plötzlich groß zu schreiben (<xs:element name="Lastname"/>), ist sich bewußt, daß der Datenempfänger anschließend die XPath-Pfade von zwanzig oder fünfzig XSL-Logiken anpassen muß, um die Feldadressierung zu aktualisieren und Informationsverlust zu vermeiden. (Vom Testaufwand gar nicht zu reden.)

Schwierig wird es, wenn jene Seite, die die XSD's ändert (z.B. Datenlieferant), die jeweils andere Seite (hier: Data Consumer) über die Änderungen nicht rechtzeitig informiert. Dann können die Anpassungen nicht rechtzeitig erfolgen, besonders wenn Daten-Consumer auf die Input-Validierung verzichten und stunden-, tage- oder wochenlang nicht bemerken, daß wichtige Informationen fehlen. Das kann teuer werden: die Folgekosten aufgrund entgangener Umsätze, Konventional- oder anderer Strafen können erheblich bis ruinös sein.

Dabei ist es möglich, daß lediglich die Namespaces (die oft Versionsänderungen dokumentieren) betroffen sind, die Adressierbarkeit der Felder jedoch unverändert bleibt. In anderen Fällen ist zusätzlich die Dokumentstruktur betroffen. Sind lediglich die Namespaces betroffen, so ist die Versuchung groß, die Programmlogik von der engen Bindung an die Namespaces zu entkoppeln und eine namespace-unabhängige Programmierung zu verfolgen.

In diesen Fällen ist es möglich, auf die vorgeschaltete XSD-Validierung völlig zu verzichten und statt dessen eine angepasste XML Schema-Validierung in XSLT 2.0 vorzunehmen, die sich lediglich auf die tatsächich verwendeten Felder bezieht, verbunden mit einer individuellen Fehlerbehandlungsroutine, die Namespace-Änderungen als Warnmeldungen reportet.

Die Interessenlage des Datenempfängers

In der Praxis erhalten Datenempfänger häufig irrelevante Informationen, für die sie keine Verwendung haben. Das liegt nicht zuletzt daran, daß die versendeten Daten sich an einen breiten Empfängerkreis wenden.

Andererseits sind dieselben Daten oft unvollständig, so daß der Empfänger darin nicht alles finden kann, was er für seine Zwecke braucht. Das erfordert zusätzlichen Programmieraufwand, oft auch eigene Datenhaltung.

Beides ist meist dann der Fall, wenn das XML Schema ohne gegenseitige Abstimmung durch den Lieferanten definiert wird und dem Consumer nichts anderes übrig bleibt, als willig zu folgen.

pic/XML_Datenaustausch_verwendbareDaten.jpg

Eine Kernfrage ist hier, was der Empfänger mit den Daten machen möchte und welchen Qualitätslevel er anstrebt. Stellt die Folgeprogrammierung nur geringe Anforderungen (z.B. es wird nur gemappt, was gerade verfügbar ist; es wird nicht kalkuliert; ein möglicher Informationsverlust fällt nicht ins Gewicht) dürfte es kaum lohnen, hochpräzise XML Schema - Validierungen zu bemühen.

Sind die Qualitäts-Anforderungen der gesamten Konvertierungsstrecke jedoch sehr hoch, sieht das anders aus. Das gilt auch und insbesondere, wenn die Qualität der empfangenen Daten deutlich niedriger liegt als die Anforderungen der Folgeprogrammierung.

Hat der Consumer Interesse an einer hohen Datenqualität, so bleibt ihm nur, diese beim Lieferanten einzufordern (heißt auch: entsprechend zu honorieren) oder eigene Anstrengungen zu unternehmen, die Qualitätsmängel der gelieferten Informationen zu beheben. Diese eigenen Anstrengungen können erheblich sein.

Betrachten wir die Datenvalidierung von XML-Dokumenten mit Hilfe von XML Schema als Zwischenschritt in einer Konvertierungsstrecke, die der Datenempfänger konstruiert. Dieser Zwischenschritt stellt sicher, daß jene Annahmen und Voraussetzungen, auf denen der Developer seine Programmierung des XML Inputs aufbaut, auch zutreffen.

Die präzise Adressierung der Datenfelder mittels XPath setzt korrekte Namespaces, Element- und Attributnamen, Datentypen sowie eine verbindlich definierte Dokumentstruktur zwingend voraus, um Informationsverlust zu vermeiden und den Zusatzaufwand bei der Folgekonvertierung zu minimieren. Daher ist das Interesse des Consumers an einer hohen Qualität der eingehenden Daten groß.

Sehr attraktiv für den Daten-Consumer ist daher das Szenario, das XML Schema eigenständig definieren zu können, und sämtliche Datenlieferanten müssen diesen Vorgaben folgen. Eine Abstimmung findet nicht statt.

Die Anforderungen und die Datenqualität präzise festlegen zu können, ohne sich mit irrelevanten Informationen belasten zu müssen, ist vorteilhaft für den Empfänger, da er am besten weiß (wissen sollte), welche Daten, deren strukturellen Aufbau und Typen er zur Weiterverarbeitung benötigt.

Für die Lieferanten bedeutet dieses Szenario meist Zusatzaufwand. Sie müssen Konvertierungsstrecken unterhalten, um die individuellen Anforderungen der Empfänger zu bedienen.

Ein XML Schema - oder mehrere?

Eine verlustfreie Transformationslogik zu planen und zu implementieren, ist nur dann möglich, wenn wir uns über die Struktur der Inputdaten ebenso zweifelsfrei im Klaren sind wie mit jener der Outputdaten. Auf der Basis XSD-valider Input-Daten ein ebenso fehlerfreies Output-Dokument zu generieren, ist dann kein Kunststück.

Problematisch ist indes eine mangelhafte Input-Datenqualität. Setzen wir den Fall, daß jenes XML Schema, das wir zur Validierung der Inputdateien verwenden möchten, nicht alle real möglichen Konstellationen korrekt abbildet. Dann haben wir ein doppeltes Problem.

Zunächst treffen unsere Annahmen über die Input-Datenstruktur nicht zu. Damit sind Fehler in der implementierten Logik zu erwarten. Diese Fehler tauchen im Regelfall erst im Produktivbetrieb auf, werden relativ spät entdeckt, haben mittlerweile schon teure Konsequenzen nach sich gezogen und müssen nach Entdecken unter Hochdruck beseitigt werden.

Zweitens würde eine vorgeschaltete Validierung mit einem faktisch fehlerhaften XML Schema zahlreiche XSL-Transformationsprozesse stoppen. Die Folge wäre nun erst recht Informationsverlust.

Ein solches XML Schema können wir also nicht verwenden. Was aber sonst? Gar nicht validieren? Auch keine Lösung! Die Gefahr, daß der reale Input weit von den Voraussetzungen der Programmierlogik abweicht und daher ebenfalls Informationsverlust verursacht, ist zu groß.

Die Lösung: ein zweites XML Schema muß her! Eines, das alle möglichen Konstellationen des Inputs zumindest soweit abbildet, daß eine Programmierlogik darauf aufbauen kann.

Ein solches XML Schema kann irrelevante Datenfelder, die nicht für die Transformationslogik benötigt werden, vermutlich ignorieren. Wichtig ist aber, daß die verwendeten Datenfelder korrekt adressiert werden können; dazu müssen wir auch deren Namespaces und Datentypen kennen.

Ändert der Datenlieferant nun im Rahmen eines minor oder major changes spontan die Namespaces, die Datentypen oder die gesamte Struktur in einer Weise, daß die implementierte Logik die Felder nicht mehr korrekt adressieren kann, dann wird das durch die XML Schema-Validierung sofort angezeigt.

Es kostet einiges an Arbeit und Erfahrung, auf der Basis einer sorgfältigen Datenanalyse ein solches XML Schema zu erstellen, kombiniert mit sinnvoll ausgewählten Testszenarios. Die Investition lohnt sich aber spätestens dann, wenn mehrere Folgetransformationen auf denselben Annahmen und Voraussetzungen beruhen. Jede in der Programmierlogik nicht überprüfte Annahme und Voraussetzung führt mit hoher Wahrscheinlichkeit zu Fehlern und Informationsverlust.

wg / 11. Februar 2018



Fragen? Anmerkungen? Tips?

Bitte nehmen Sie Kontakt zu mir auf:

Vorname
Nachname
Mailadresse







Vielen Dank für Ihr Interesse an meiner Arbeit.


V.i.S.d.P.: Wilfried Grupe * Klus 6 * 37643 Negenborn

☎ 0151. 750 360 61 * eMail: info10@wilfried-grupe.de

www.wilfried-grupe.de/Interessenkonflikte.html