XML * XML-SCHEMA * XPATH * XSL * XSL-FO * SVG * XQUERY * XPROC * ANT * DIVERSES



XML-Schema

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: , , , , MathML, , , Maven, , , 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 Felder sind gezielt verboten oder zwingend notwendig) kommt zum Einsatz.

Insofern dient XML (als Datenformat betrachtet) als Schnittstelle zur 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 , , oder andere zum Einsatz.

Ein simples Beispiel soll das demonstrieren. Um -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 -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 -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 des Transformationsprozesses erfolgen. Geschieht das nicht, so funktionieren die Folgeprogramme möglicherweise nicht korrekt, und es droht Informationsverlust.

pic/XSD_Orte_Ort_Mensch.jpg


<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 / 1. November 2020



Fragen? Anmerkungen? Tipps?

Bitte nehmen Sie Kontakt zu mir auf.




XML

XML-Verarbeitung ohne vorherige Validierung?

So etwas brauche ich nicht ...

Interessenkonflikte

RelaxNG - Beispiel

RelaxNG compact - Beispiel

DTD

DTD - Beispiel

XML-Schema: Verschiedene Designs

XML-Schema: "Russian Doll"

XML-Schema: Globale complexTypes, simpleTypes, xs:group

XML-Schema: Globale Elementdeklaration, lokale Referenzierung

XML-Schema: Benennung von Namespaces

XML-Schema: Einbindung extern deklarierter Namespaces

XML-Schema: Verwendung verschiedener Designs in einem XML-Schema

XML-Schema 1.0

xs:element name

xs:complexType

xs:simpleType

xs:element ref

xs:group

xs:unique, xs:key, xs:keyref, xs:selector, xs:field

xs:any, xs:anyType

xs:element abstract, substitutionGroup

elementFormDefault, attributeFormDefault

xs:choice

xs:sequence, xs:all

xs:all

xs:annotation

xs:any

xs:anyAttribute

xs:appinfo

xs:attribute

xs:attributeGroup

xs:complexContent

xs:documentation

xs:enumeration

xs:extension

xs:field

xs:fractionDigits

xs:import

xs:include

xs:key

xs:keyref

xs:length

xs:list

xs:maxExclusive

xs:maxInclusive

xs:maxLength

xs:minExclusive

xs:minInclusive

xs:minLength

xs:notation

xs:pattern

xs:redefine

xs:restriction

xs:selector

xs:sequence

xs:simpleContent

xs:totalDigits

xs:union

xs:unique

xs:whiteSpace

xs:ENTITY, xs:ENTITIES

xs:nillable, xsi:nil

XML-Schema-Beispiel: Buecher

NVDL

XML-Schema-Validierung mit ANT

XML-Schema Validierung in Java

XML-Schema 1.1

Schemavalidierung mit XSLT 3.0

Schematron

XPath



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