Validierung
XML Instanzen können uns sollten immer gegen Regelwerke validiert werden, damit Menschen, die diesem Standard akzeptieren, unabhängig voneinander gleichförmige Strukturen erzeugen. Wird eine Instanz konform zu einem Regelwerk erzeugt, ist dies eine valide Instanz. |
Regelwerke stehen zu vielen Topics fertig konzipiert im Internet zur Verfügung. Für die Geisteswissenchaften sehr relevant ist die TEI Text Encoding Initiative, die für unterschiedlichste Textsorten Regelwerke bereithält.
Sprachen zum Verfassen von Regelwerken für XML Instanzen gibt es einige verschiedene: DTD, ist die älteste aber auch einfachste, XML Schema (Video) eine umfangreiche, sehr komplexe Sprache, RELAX NG und Schematron sind weitere Optionen.
DTD – selbsterzeugte Regelwerke
Die DTD, eine Definition eines Dokumententyps, ist eine Möglichkeit festzulegen, wie eine Baumstruktur aufgebaut sein muss, indem zu jedem Element (Tag) festgeschrieben wird, ob, welche und wie viele Kind-Elemente enthalten sein dürfen oder müssen. Eine ihr folgende XML- Instanz muss exakt nach diesem Muster aufgebaut sein muss.
Eine DTD sollte möglichst genau und streng das zu Grunde liegende Konzept abbilden, da dies eine wesentliche Voraussetzung für das Erstellen guter Instanzen darstellt.
DTDs sollten immer als externe Ressourcen erstellt werden, können aber auch in der Instanz selber stehen. Dies ist aber ausdrücklich NICHT empfehlenswert.
Die Datei wird unter einem beliebigen Namen mit dem Suffix .dtd abgespeichert.
Folgende syntaktische Regeln müssen beachtet werden:
- Jedes in einer Instanz notwendige Tag muß durch eine <!ELEMENT …> Deklaration explizit eingeführt werden.
- In dieser Deklaration folgt zunächst der Name des Tags, in exakt der gleichen Schreibung, in der er in der Instanz verwendet werden soll.
Dahinter folgt in einem Klammerpaar das Content Modell.Beispiel:
<!ELEMENT bildersammlung (name?, lokalisation, bild+)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT lokalisation EMPTY>
<! ATTLIST lokalisation
url CDATA #IMPLIED
postal CDATA #IMPLIED
>
<!ELEMENT bild (titel, url, abstract*, person+, bauwerk+)>
<!ELEMENT titel (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT abstract (#PCDATA)>
<!ELEMENT person (bezeichnung+)>
<!ELEMENT bauwerk (bezeichnung+)>
<!ELEMENT bezeichnung (#PCDATA)>
Das Content Modell oder Inhaltsmodell ist eine Spezifikationen, die Reihenfolge und Umfang der Kindelemente festlegt:
- In Form einer durch Kommata geordneten Liste werden alle Tags, die in dem betroffenen enthalten sein dürfen, in der Reihenfolge angegeben, in der sie vorkommen müssen.
- Steht hinter dem Namen kein Sonderzeichen, muß das Tag genau einmal vorkommen.
- Steht hinter dem Namen ein Pluszeichen, bedeutet dies, daß das Tag mindestens einmal vorkommen muß, aber auch öfter vorkommen kann.
- Steht hinter dem Namen ein Fragezeichen, bedeutet dies, daß das Tag einmal vorkommen darf, aber nicht muß.
- Steht hinter dem Namen ein Sternchen – ‚*‘, bedeutet dies, daß das Tag mehrmals vorkommen darf, aber auch ganz fehlen darf.
- Die spezielle Konstruktion #PCDATA teilt mit, daß an dieser Stelle beliebige Daten stehen dürfen. (PCDATA = „Parseable Character Data“)
- EMPTY als Keyword im Content Model bedingt, dass ein solches Tag nur aus einem Start-Tag besteht und keine Information umschlossen wird. Diese Tags enthalten häufig Attribute, die spezifische Information beinhalten.
Hierarchisierung
Elemente können/müssen über beliebig viele Ebenen gestaffelt sein. In DTDs tritt eine deutliche Hierarchisierung auf: ein Baum mit Eltern,- Kind,- und Geschwisterelemente (Vorfahren und Nachfahren).
Je mehr Hierarchieebenen eine XML-Datei aufweist, umso komplexer und genauer ist die Beschreibung der Ressource.
Beispiel:
Denktipp: Streng genommen ist ‚Eiffelturm‘ nicht das Bauwerk selbst, sondern es handelt sich um eine Bezeichnung für dieses. Ebenso verhät es sich mit ‚Mona Lisa‘. Diese Idee kann in das Konzept einbezogen werden:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE bildersammlung SYSTEM "bild01.dtd">
<bildersammlung>
<name>Neue schöne Bilder</name>
<lokalisation url=http://www.bilder.de/>
<bild>
<titel>Mona Lisa vor dem Eiffelturm</titel>
<url>http://www.woauchimmer.de</url>
<person>
<bezeichnung>Mona Lisa</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Eiffelturm</bezeichnung>
</bauwerk >
</bild>
<bild>
<titel>Ritter, Burgen, Adel</titel>
<url>http://www.beispielseite.de</url>
<person>
<bezeichnung>byzantinische Kaiserin</bezeichnung>
</person>
<person>
<bezeichnung>Ritter des 13.Jhd</bezeichnung>
</person>
<person>
<bezeichnung>fränkischer Edelmann</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Wasserburg</bezeichnung>
</ bauwerk >
</bild>
<bild>
....
</bild>
</bildersammlung>
Neben der DTD gibt es eine weitere Validierungssprache, die deutlich restriktiver eingesetzt werden kann.
XML Schema
NIEMAND IRRT FÜR SICH ALLEIN. ER VERBREITET SEINEN UNSINN AUCH IN SEINER UMGEBUNG. (Lucius Annaeus Seneca)
Eine der Zielsetzungen von XML-Schema ist die Verbesserung der Validierungsmöglichkeiten einer Instanz und die leichtere Integrierbarkeit in größere Softwarekontexte. XML-Schema bietet die Möglichkeit, die Eingaben, also die von den Tags umschlossene Information, zu kontrollieren. War es bei einer DTD möglich, die Metainformation PLZ mit der Information „Flughafen Port Elizabeth“ zu verknüpfen, obwohl eine deutsche Postleitzahl gemeint war, stellt XML-Schema eine Möglichkeit zur Verfügung, die Information auf eine fünfstellige Zahl festzulegen. Des Weiteren könnendie Kardinalitäten deutlich genauer festgelegt werden. Die Reduktion auf die Angabe „mehrfach“ ist durch eine exakte Festlegung der Häufigkeit aufgehoben.
Bei sinnvollem Einsatz kann dies einerseits Irrtümer, andererseits offensichtlichen Unfug in der Instanz deutlich reduzieren und die Datenqualität erheblich verbessern. Weitere Vorteile liegen in der Berücksichtigung von Namensräumen, der besseren Programmierschnittstelle und der Grundlegung auf XML. Das Schema ist selbst ein XML-Dokument, das auf Wohlgeformtheit überprüft werden kann.
Weiteres dazu siehe:
S. Kurz: Digital Humanities 2. Aufl. 2016, © Springer Fachmedien Wiesbaden 2016
E-Book ISBN: 978-3-658-05793-0 S. 152ff