Aktuelle Remote-Seminare mit Durchführungsgarantie: Noch freie Termine im Dezember! Termine: 07.12.-09.12.2020, 22.03.-24.03.2021, 07.06.-09.06.2021, 06.09.-08.09.2021, Termin nach Wunsch, noch in Dezember 2020 möglichXML Einführung und Grundlagen Termine: 25.03.2021, 10.06.2021, 09.09.2021XML - der professionelle Überblick Termine: 29.03.-01.04.2021Einstieg in die Programmierung Termine: 14.12.-16.12.2020, 07.04.-09.04.2021XML, XSLT, XPath, XSL-FO Einführung Termine: Termin nach Wunsch, noch in Dezember 2020 möglichEinstieg in C#.NET Termine: 11.01.-13.01.2021, 26.05.-28.05.2021, 27.09.-29.09.2021, Termin nach Wunsch, noch in Dezember 2020 möglichVB.NET für Visual Basic-Programmierer Termine: Termin nach Wunsch, noch in Dezember 2020 möglichC#.NET für Fortgeschrittene Termine: 08.03.-10.03.2021, 19.07.-21.07.2021, 23.08.-25.08.2021, Termin nach Wunsch, noch in Dezember 2020 möglichXML Grundlagen, XSL-FO, SVG, DocBook, DITA Termine: Termin nach Wunsch, noch in Dezember 2020 möglichJava Grundlagen Termine: Termin nach Wunsch, noch in Dezember 2020 möglich, 29.03.-01.04.2021C++ für Programmiereinsteiger Termine: 16.03.2021, Termin nach Wunsch, noch in Dezember 2020 möglichXProc Grundlagen Termine: 23.11.-25.11.2020, 25.01.-27.01.2021, 12.04.-14.04.2021, 26.07.-28.07.2021, Termin nach Wunsch, noch in Dezember 2020 möglichPython für Programmiereinsteiger Last-Minute-Seminare, noch freie Plätze XML Einführung und Grundlagen07.12.-09.12.2020 XML, XSLT, XPath, XSL-FO Einführung14.12.-16.12.2020

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, 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 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 / 2. Juni 2020



Fragen? Anmerkungen? Tipps?

Bitte nehmen Sie Kontakt zu mir auf.




XML

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