XML-Validierung / So etwas brauche ich nicht ...

So etwas brauche ich nicht ...

So etwas brauche ich nicht ...

➪ Ob auf eine XML-Schema-Validation des XML-Inputs verzichtet werden kann, hängt davon ab, dass sich die Dokumentstruktur der Input-Daten (einschließlich Namespaces) nicht ändert. Das ist aber keineswegs sichergestellt.

Einige Data Consumer sehen das Thema Validierung entspannt. Nicht ohne Grund: Nur selten werden wirklich alle Daten des XML-Inputdokuments für die Weiterverarbeitung benötigt. Oft finden weniger als zwanzig Prozent Verwendung, die restlichen achtzig Prozent werden verworfen. Wenn in jenen achtzig Prozent, die für die Auswertung nicht benötigt werden, ein liegt, dann wäre die vorgeschaltete Validierung

Stellen Sie sich vor, hinter den XML-Inputs stünden Lieferaufträge in Millionenhöhe. Manches Unternehmen würde wenig Verständnis zeigen, wenn die IT lukrative Aufträge mit der Begründung abblockt, dass irrelevante Daten fehlerhaft strukturiert oder falsch formatiert seien. Wenn also die (fragwürdige?) Qualität der Input-Daten den weiteren Verarbeitungsprozess nicht stört, so kann auf eine Validierung verzichtet werden, so die Argumentation.

Das setzt aber voraus, dass

Änderungen an der Dokumentstruktur können schnell und unbeabsichtigt verursacht werden: der Datenlieferant führt einen "Change" durch. Bereits eine marginale Änderung im SQL-Statement (z.B. Veränderung eines Alias) einer relationalen Datenbank (als Datenlieferant) reicht dazu völlig aus. Wird nicht parallel die Logik der Folgeprogramme angepasst, so zieht der Verzicht auf die Validierung dieser Daten einen Informationsverlust nach sich.

Es können Tage, Wochen, Monate vergehen, bis jemandem auffällt, dass Informationen zwar bereitgestellt, aber nicht verarbeitet werden, weil die XSL-Stylesheets allzu lange noch auf einer mittlerweile veralteten Datenstruktur aufsetzten. Wenn die Adressierbarkeit der Datenfelder nicht mehr gewährleistet ist, kann das sehr teuer werden, es kann auch Menschenleben gefährden.

Die folgenden, sehr einfach gehaltenen Beispiele sollen die Problematik verdeutlichen. Basierend auf einer Datenbanktabelle "Mensch", die mehrere Spalten umfassen kann, wird ein SQL-Statement abgesetzt, dessen Ergebnis in XML-Format zur Verfügung steht. In diesem Beispiel generiert der Alias "vorname" ein entsprechendes XML-Element "<vorname>".

pic/konvstrecke1.png

Im nächsten Schritt dieser Prozesskette setzt ein XSL-Stylesheet auf dieser XML-Struktur auf. Das Ergebnis generiert eine HTML-Tabelle. So weit ist alles in Ordnung.

pic/konvstrecke2.png

Wird nun die SQL-Datenbankabfrage geändert ("VN" statt "vorname"), so ändert sich auch die XML-Dokumentstruktur. Um die Konvertierungsstrecke aufrechtzuerhalten und das gewünschte HTML-Ergebnis bereitzustellen, ist es erforderlich, das XSL-Stylesheet parallel anzupassen und die Adressierbarkeit der Datenfelder sicherzustellen.

Aus verschiedenen Gründen (z.B. bei unübersichtlichen Prozessketten) kann es jedoch vorkommen, dass genau dieser wichtige Schritt versäumt wird. Wenn das XSL-Stylesheet noch mit "vorname" arbeitet, so ist der HTML-Output leer.

pic/konvstrecke3.png

Welche Konsequenzen hat der Informationsverlust, der an dieser Stelle droht?

Es ist ein Irrtum, anzunehmen: Wenn die Information im Output nicht vorhanden ist, dann liegt sie auch im Input nicht vor. Tatsächlich kann es vorkommen, dass die Info vorliegt, jedoch nicht verarbeitet wird, weil sie in einer mangelhaften Änderung der Prozesskette (die vorher fehlerfrei funktionierte) verloren geht.

Eine vorgeschaltete Prüfung der XML-Inputdaten, beispielsweise mithilfe von XML-Schema, kann auf diese Struktur-Änderung sowie über notwendige Anpassung der Verarbeitungslogik automatisch und sofort hinweisen.

pic/konvstrecke4.png

wg / 25. März 2018



Fragen? Anmerkungen? Tipps?

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/XSD2_.html