Gern stehe ich zur fachlichen Unterstützung in XML-Technologien, C#.NET, VisualBasic.NET und Java zur Verfügung. Sprechen Sie mich einfach an: Mail oder ☎ 0151 . 750 360 61


Warum XML-Validierung? / XML-Verarbeitung ohne vorherige Validierung?

XML-Verarbeitung ohne vorherige Validierung?

XML-Verarbeitung ohne vorherige Validierung?

➪ Der Sinn der XML-Schema-Validierung besteht darin, ein XML-Dokument hinsichtlich seiner Datenstruktur (Elemente, Attribute, Namespaces) und deren Datentypen zu prüfen, um die Folgeprogrammierung abzusichern und Informationsverlust vorzubeugen. Welchen Sinn macht es, XML-Dokumente zu verarbeiten, ohne sie vorher zu validieren?

Bei der XML-Validierung geht es weniger darum, dem Datenlieferanten Fehler und Fahrlässigkeit nachweisen zu können. Wichtiger ist, die Annahmen und Voraussetzungen der Folgeprogrammierung abzusichern und damit weitergehenden Informationsverlust zu vermeiden. Macht es Sinn, darauf zu verzichten?

pic/XSL_Workflow.png

Eine XSD-Validierung vor Beginn des Konvertierungsprozesses macht nur Sinn, wenn der Workflow gestoppt werden soll, sobald die XSD-Validierung auf einen Fehler läuft: Die XSL-Konvertierung würde also erst gar nicht starten. Dafür kann es triftige Gründe geben.

Ein Grund mag sein: Sie verfolgen eine kompromisslose Politik, dass Input-Streams entweder vollständig fehlerfrei oder vollständig unbrauchbar sind. Entweder "stimmt" das Input-Dokument hundertprozentig oder gar nicht. Eine Grauzone "dazwischen" kann es nicht geben. Wenn das Dokument schon in Teilen nicht stimmt, dann ist es wahrscheinlich, dass sich Fehler auch in jenen Bereichen eingeschlichen haben, die Sie für die Anschlusskonvertierung benötigen. Also stoppen Sie lieber das Ganze, bevor Sie sich die Mühe machen, durch eine aufwendige Implementierung Datenfehler automatisiert zu erkennen und zu beheben.

Zudem ist eine solche vorherige XSD-Validierung auch ein Stück Sicherheit, wenn Ihre Implementierungslogik konsequent auf einem bestimmten XML-Schema des Datenlieferanten aufbaut, quasi fest damit "verdrahtet" ist. Sendet der Datenlieferant nun ohne Vorwarnung andere Datenstrukturen an Ihr System, dann besteht keine Gefahr einer zufälligen Fehlkonvertierung mit Informationsverlust, die sich ohne Vorprüfung ergeben könnte.


<Menschen>
 <xs:schema id="Menschen" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Menschen">
   <xs:complexType>
    <xs:sequence minOccurs="0" maxOccurs="unbounded">
     <xs:element name="Mensch">
      <xs:complexType>
       <xs:sequence>
        <xs:element name="id" type="xs:int" />
        <xs:element name="name" type="xs:string" />
        <xs:element name="vorname" type="xs:string" />
        <xs:element name="Gehalt" type="xs:string" />
        <xs:element name="idOrt" type="xs:int" />
       </xs:sequence>
      </xs:complexType>
     </xs:element>
    </xs:sequence>
   </xs:complexType>
   <xs:unique name="primarykey">
    <xs:selector xpath=".//Mensch" />
    <xs:field xpath="id" />
   </xs:unique>
  </xs:element>
 </xs:schema>
 <Mensch>
  <id>1</id>
  <name>Holzflos</name>
  <vorname>Hugo</vorname>
  <Gehalt>234.56</Gehalt>
  <idOrt>1</idOrt>
 </Mensch>
 <Mensch>
  <id>2</id>
  <name>Sagblos</name>
  <vorname>Stefan</vorname>
  <Gehalt>321.45</Gehalt>
  <idOrt>1</idOrt>
 </Mensch>
 <Mensch>
  <id>3</id>
  <name>Sorglos</name>
  <vorname>Siggi</vorname>
  <Gehalt>987.58</Gehalt>
  <idOrt>1</idOrt>
 </Mensch>
</Menschen>

Auf der anderen Seite ist die Aussagekraft der Schemavalidierung begrenzt, da sich zwar sehr präzise, aber auch ebenso definieren lassen.

Schwierig wird es, wenn das verwendete XML-Schema keine Fakten erzwingt, die in der XSLT-Logik verwendet werden können, sondern je nach den Prozesserfordernissen "zurechtgebogen" und dabei entschärft wird. Ein einfaches Beispiel: Das XML-Element wert sei im XML-Schema als xs:decimal deklariert. Korrekt im Sinn vom XML-Schema wäre daher ausschliesslich <wert>123.45</wert>. Die XML-Daten kommen jedoch teilweise auch im Format <wert>123,45</wert>. Daher würde die XML-Schema-Validierung auf einen Fehler laufen, der anschließende Konvertierungsprozess würde gestoppt.

Um das zu vermeiden, bleibt nur, das XML-Schema so anzupassen, dass es als Dezimaltrenner sowohl ein Komma als auch einen Punkt akzeptiert. Das wäre möglich durch eine Umdefinition von wert vor xs:decimal auf xs:string mit einem pragmatisch gedrechselten Pattern. Ein solchermaßen "entschärftes" XML-Schema zieht in der XSLT-Konvertierungsphase zusätzlichen Programmieraufwand nach sich: 123,45 muss erst nach 123.45 konvertiert werden, bevor Sie damit korrekt kalkulieren können.

Die Möglichkeiten, die XML-Schema bietet, werden selten vollständig genutzt. Ich habe wiederholt XSDs gesehen, deren Elemente und Attribute pauschal als xs:string definiert wurden, sogar einige, wo nur das Root-Element und einige allgemeine Strukturdefinitionen, der Rest aber als deklariert wurde. Auch eine Deklaration gegenseitiger Abhängigkeiten im Sinne von habe ich in XSDs selten gefunden, obwohl diese in den XML-Dokumenten durchaus vorhanden waren: Diese Dinge mussten dann später im Konvertierungsprozess aufwendig geprüft werden. Das Argument "Wir haben ein XML-Schema" sagt daher nichts aus über die Qualität des XML-Schemas, das als Stopp-Kriterium für umfangreiche Konvertierungsstrecken dienen soll.

Wichtig ist auch, dass die Eingangsvalidierung sich grundsätzlich auf das gesamte XML-Dokument bezieht. Die Anschlussprogrammierung wertet aber nur selten mehr als zwanzig Prozent der Eingangsdaten aus. Wenn die Validierung wegen einiger Fehler schiefgeht, die bei der Datenauswertung ohnehin ignoriert werden, und deswegen die Folgekonvertierung nicht startet, dann kann das problematisch werden. Nehmen Sie an, ein Kunde sendet Ihnen einen Millionenauftrag in XML-Format. Sie werden sich dreimal überlegen, den Auftrag abzulehnen wegen einiger Fehler, die für die automatisierte Verarbeitung irrelevant sind.

Zudem wird die Qualität der gesamten Datenlage beim Datenempfänger durch teilweise gestoppte Eingangskonvertierung nicht unbedingt erhöht. Es kommt (gar nicht selten) vor, dass aktuell eingehende Datenströme sich auf andere Daten beziehen, die zeitversetzt entweder bereits geflossen oder noch zu erwarten sind. Wenn es dem Datenempfänger wichtig ist, einen möglichst geschlossenen, vollständigen Datenkontext über einen ganzen Zeitraum verfügbar zu haben, dann kann die Eingangsvalidierung sehr hinderlich sein. Es können sich Datenlücken ergeben, die die Aussagekraft einschränken.

Dabei ist es nicht notwendig, eine "schlechte Datenqualität" der Inputstreams vorher durch Validierung abzufangen, um die Folgekonvertierung nicht zu belasten. Das wäre nur dann zwingend erforderlich, wenn die Folgeanwendung selbst nicht in der Lage ist, eine suboptimale Datenqualität abzuwehren. Das ist bei XSLT 2.0, XSLT 3.0, XQuery 3.0 und den korrespondierenden XPath-Standards aber nicht der Fall.

Eine eher pragmatische Sicht der Dinge ist daher, ob sich auch ein teilweise fehlerhafter Inputstream sinnvoll verwenden lässt, indem man auf die vorgeschaltete Validierung verzichtet und diese stattdessen in die verlegt. Dann ist es möglich, irrelevante Daten zu ignorieren und sich auf die tatsächlich benötigten Informationen zu konzentrieren. Die Möglichkeiten sind ab XSLT 2.0 vorhanden; sie müssen nur genutzt (und ausreichend getestet) werden.

wg / 30. Juni 2019



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