XML Validierung - wozu? / Sowas brauche ich nicht ...

Sowas brauche ich nicht ...

Sowas brauche ich nicht ...

➪ Ob auf eine XML-Schema-Validation des XML Inputs verzichtet werden kann, hängt davon ab, daß 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 Input Dokuments 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 wir uns 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, daß irrelevante Daten fehlerhaft strukturiert oder falsch formatiert seien. Wenn also die (fragwürdige?) Qualität der Input-Daten den weiteren Verarbeitungsprozeß nicht stört, so kann auf eine Validierung verzichtet werden, so die Argumentation.

Das setzt aber voraus, daß

Ä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 angepaßt, so zieht der Verzicht auf die Validierung dieser Daten einen Informationsverlust nach sich.

Es können Tage, Wochen, Monate vergehen, bis jemandem auffällt, daß 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 Prozeßkette 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 aufrecht zu erhalten und das gewünschte HTML-Ergebnis bereitzustellen, ist erforderlich, das XSL-Stylesheet parallel anzupassen und die Adressierbarkeit der Datenfelder sicherzustellen.

Aus verschiedenen Gründen (z.B. bei unübersichtlichen Prozeßketten) kann es jedoch vorkommen, daß 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, daß die Info vorliegt, jedoch nicht verarbeitet wird, weil sie in einer mangelhaften Änderung der Prozeßkette (die vorher fehlerfrei funktionierte) verlorengeht.

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

pic/konvstrecke4.png

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