XML-Schema

XML-Schema

➪ Hier lesen Sie, wie und warum ein XML-Dokument auf seine Gültigkeit überprüft (validiert) werden sollte. Mithilfe von DTD, XML-Schema, RelaxNG, NVDL oder Schematron stehen verschiedene Technologien zur Normung (Definition) und automatisierten Prüfung von Datenstrukturen zur Verfügung.

Die enorme Gestaltungsflexibilität der XML-Dokumente zwingt zu systematischer Strukturierung, damit sie durch Folgeprogramme effizient ausgewertet werden können. Zahlreiche XML-basierte Standards setzen ihrerseits eine bestimmte Struktur voraus: XSL, XML-Schema, SVG, FO, MathML, ANT, XProc, Maven, Docbook, DITA, ebenso etablierte Konzepte zur Auswertung von XML (SAX, DOM, ...).

Je nach Aufgabenstellung sind die Gestaltungsmöglichkeiten von DTD, XML-Schema, RelaxNG jedoch begrenzt: für gezielte weitere Einschränkungen oder Modifizierungen der Ursprungsdeklarationen (etwa: ursprünglich optionale Felder sind gezielt verboten oder zwingend notwendig) kommt Schematron zum Einsatz.

Insofern dient XML (als Datenformat betrachtet) als Schnittstelle zur Datenübergabe an Folgeprogramme, die zum korrekten Funktionieren einen bestimmten Aufbau der XML-Dokumente zwingend erfordern. Die Folgeprogramme sind oft genug in Java, C#.NET, C++, Python oder in jeder anderen Programmiersprache geschrieben, häufig kommen auch XML-Technologien wie XSLT, XQuery, XProc oder andere zum Einsatz.

Ein simples Beispiel soll das demonstrieren. Um XSL-Stylesheets wie dieses ...

 <xsl:template match="/">
  <Root>   
   <xsl:for-each 
        select="/Orte/Ort/Mensch
          [Gehalt &gt;= sum(Kauf/Gesamt)]">
    <Person>
     <VN>
       <xsl:value-of select="vorname"/>
     </VN>
     <NN>
       <xsl:value-of select="name"/>
     </NN>
     <WO>
       <xsl:value-of select="../name"/>
     </WO>
     <Saldo>
       <xsl:value-of 
            select="Gehalt - sum(Kauf/Gesamt)"/>
     </Saldo>
    </Person>
   </xsl:for-each>   
  </Root>
 </xsl:template>

... oder alternativ um XQuery-Anweisungen wie die folgende:

<Root>
 {
  for $x in /Orte/Ort/Mensch
            [Gehalt >= sum(Kauf/Gesamt)]
  return
   <Person>
    <VN>{$x/vorname/text()}</VN>
    <NN>{$x/name/text()}</NN>
    <WO>{$x/../name/text()}</WO>
    <Saldo>
      {$x/xs:decimal(Gehalt) - 
       sum($x/Kauf/xs:decimal(Gesamt))}
    </Saldo>
   </Person>
 }
</Root>

... oder andere Auswertungsprogramme in diversen Sprachen und APIs zuverlässig schreiben zu können, ist es unerlässlich, über den Aufbau des XML-Dokuments eine klare Vorstellung zu haben. Denn das XPath-Statement

/Orte/Ort/Mensch[Gehalt >= sum(Kauf/Gesamt)]

liefert nur dann brauchbare Ergebnisse, wenn es die Inhalte des XML-Dokuments eindeutig adressiert.

Ein XPath-Statement, das nicht zum Aufbau des XML-Dokuments passt, liefert keine Ergebnisse. Bereits die abweichende Adressierung /Orte/ort/Mensch würde kein XML-Element ansprechen, weil zwischen Ort (im XML-Input) und ort (im XPath-Statement) ein gravierender Unterschied besteht.

Ein geeignetes XML-Dokument könnte beispielsweise diesen Inhalt aufweisen:

<Orte>
  <Ort>
    <id>1</id>
    <name>Neustadt</name>
    <Mensch>
      <id>1</id>
      <name>Holzflos</name>
      <vorname>Hugo</vorname>
      <Gehalt>234.56</Gehalt>
      <idOrt>1</idOrt>
      <Kauf>
        <idMensch>1</idMensch>
        <anzahl>3</anzahl>
        <bez>Hemd</bez>
        <preis>12.99</preis>
        <Gesamt>38.97</Gesamt>
      </Kauf>
      <Kauf>
        <idMensch>1</idMensch>
        <anzahl>9</anzahl>
        <bez>Hemd</bez>
        <preis>12.99</preis>
        <Gesamt>116.91</Gesamt>
      </Kauf>
    </Mensch>
  </Ort>
</Orte>

Daher ist eine Prüfung sinnvoll, ob der XML-Input jenen Annahmen und Voraussetzungen entspricht, denen die Programme zugrunde liegen. Diese Validierung kann vor Beginn oder während des Transformationsprozesses erfolgen. Geschieht das nicht, so funktionieren die Folgeprogramme möglicherweise nicht korrekt, und es droht Informationsverlust.

<xs:schema id="Orte" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Orte">
    <xs:complexType>
      <xs:sequence>
        <xs:element 
            ref="Ort" 
            maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="Ort">
    <xs:complexType>
      <xs:sequence>
        <xs:element 
            ref="name"/>
        <xs:element 
            ref="Mensch" 
            maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="Mensch">
    <xs:complexType>
      <xs:sequence>
        <xs:element 
            ref="name"/>
        <xs:element 
            name="vorname" 
            type="xs:string"/>
        <xs:element 
            name="Gehalt" 
            type="xs:decimal"/>
        <xs:element 
            ref="Kauf" 
            maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="Kauf">
    <xs:complexType>
      <xs:sequence>
        <xs:element 
            name="Gesamt" 
            type="xs:decimal"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element 
            name="name" 
            type="xs:string"/>
</xs:schema>

Folgeprogramme lesen den Inhalt der XML-Datenfelder aus und verarbeiten sie weiter. Wenn einzelne Datenfelder jedoch nicht vorhanden sind oder nicht in dem vom Programmierer erwarteten Datentyp übernommen werden können, dann gerät die korrekte Auswertung in Gefahr. Der Programmieraufwand zur Behandlung fehlerhaften Daten-Inputs kann sehr hoch und teuer werden, umso mehr, wenn gleich mehrere (Hunderte?) unterschiedliche Programme auf diesem Dateninput aufsetzen.

Insofern kann eine vorgeschaltete XML-Input-Validierung Abweichungen aufzeigen, die zur systematischen Weiterentwicklung der Folgeprogramme beitragen sollten. Möglich ist auch, die gesamte Weiterverarbeitung komplett zu stoppen, wenn der XML-Input nicht valide ist. Das erspart eine aufwendige Struktur- und Typprüfung in der Verarbeitungslogik, bewahrt aber nicht vor grundsätzlichen Programmierfehlern oder vor mangelhaften Anschlusstests.

wg / 17. April 2021

Fragen? Anmerkungen? Tipps?

Bitte nehmen Sie Kontakt zu mir auf.