XML-Validierung / Interessenkonflikte

Interessenkonflikte

Interessenkonflikte

➪ In der Praxis kann es vorkommen, dass die Interessenlage des Datenlieferanten und des -empfängers hinsichtlich der Qualität der bereitgestellten Daten (wie auch des XML-Schemas) 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 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-Schemas aus. Die Verantwortung dafür, dass 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, dass 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 muss seine Prozesse anpassen, um die geänderten Datenstrukturen zu generieren. Jeder Datenconsumer muss seine Programmlogiken zur Verarbeitung des geänderten Inputs ebenso anpassen.

Kleine Ursache, große Wirkung. Eine scheinbar geringfügige Änderung des XML-Schemas 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 kleingeschrieben wurde (<xs:element name="lastname"/>), nun plötzlich großzuschreiben (<xs:element name="Lastname"/>), ist sich bewusst, dass der Datenempfänger anschließend die XPath-Pfade von 20 oder 50 XSL-Logiken anpassen muss, um die Feldadressierung zu aktualisieren und Informationsverlust zu vermeiden. (Vom Testaufwand gar nicht zu reden.)

Schwierig wird es, wenn jene Seite, die die XSDs ändert (z.B. Datenlieferant), die jeweils andere Seite (hier: Dataconsumer) ü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, dass 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, dass 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 stattdessen eine angepasste XML-Schema-Validierung in XSLT 2.0 vorzunehmen, die sich lediglich auf die tatsächlich 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, dass die versendeten Daten sich an einen breiten Empfängerkreis wenden.

Andererseits sind dieselben Daten oft unvollständig, wodurch 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 Sie die Datenvalidierung von XML-Dokumenten mit XML-Schema als Zwischenschritt in einer Konvertierungsstrecke, die der Datenempfänger konstruiert. Dieser Zwischenschritt stellt sicher, dass 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 dieser am besten weiß (wissen sollte), welche Daten zur Weiterverarbeitung benötigt werden.

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 Sie sich über die Struktur der Inputdaten ebenso zweifelsfrei im Klaren sind wie der Outputdaten. Auf der Basis XSD-valider Input-Daten ein ebenso fehlerfreies Output-Dokument zu generieren, ist dann kein Kunststück.

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

Zunächst treffen Ihre 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 Sie also nicht verwenden. Was aber sonst? Gar nicht validieren? Auch keine Lösung! Die Gefahr, dass 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 muss her! Eines, das alle möglichen Konstellationen des Inputs zumindest so weit abbildet, dass 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, dass die verwendeten Datenfelder korrekt adressiert werden können; dazu müssen Sie 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, dass 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 / 12. April 2018



Fragen? Anmerkungen? Tips?

Bitte nehmen Sie Kontakt zu mir auf.






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