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. Siehe unten auf dieser Seite!

Sprachen zum Verfassen von Regelwerken für XML Instanzen gibt es einige verschiedene. DTD, ist die älteste aber auch einfachste, XML Schema 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:

  1. Jedes in einer Instanz notwendige Tag muß durch eine <!ELEMENT …> Deklaration explizit eingeführt werden.
  2. 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:

  1. 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.
  2. Steht hinter dem Namen kein Sonderzeichen, muß das Tag genau einmal vorkommen.
  3. Steht hinter dem Namen ein Pluszeichen, bedeutet dies, daß das Tag mindestens einmal vorkommen muß, aber auch öfter vorkommen kann.
  4. Steht hinter dem Namen ein Fragezeichen, bedeutet dies, daß das Tag einmal vorkommen darf, aber nicht muß.
  5. Steht hinter dem Namen ein Sternchen – ‚*‘, bedeutet dies, daß das Tag mehrmals vorkommen darf, aber auch ganz fehlen darf.
  6. Die spezielle Konstruktion #PCDATA teilt mit, daß an dieser Stelle beliebige Daten stehen dürfen. (PCDATA = „Parseable Character Data“)
  7. 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

w3schools

Fertige Regelwerke - TEI

Seit den Gründungstagen arbeitet die TEI (Text Encoding Initiative) an Standards zur strukturellen und konzeptuellen Codierung von Textbestandteilen. In Form von Guidelines werden seit 1994 Richtlinien veröffentlicht, die regelmäßig durch das Konsortium angepasst werden und einen De-Facto-Standard in den Geisteswissenschaften darstellen. PDF

Die Zielsetzung des Projektes besteht darin, so viele textuelle Merkmale unterschiedlicher Textsorten wie möglich in Form von Metadaten zu repräsentieren und gleichzeitig das Kodieren unterschiedlicher Textauffassungen zu ermöglichen. Die Universalität der TEI bedingt aber gleichzeitig ihre Komplexität und es bedarf einige Zeit der Einarbeitung für einen souveränen Umgang mit diesem Standard.

Die veröffentlichten Guidelines sind modular aufgebaut und basierten ursprünglich auf SGML. Im Jahr 2002 wurde die erste XML-basierte Version veröffentlicht und die ursprüngliche DTD wurde in ein TEI-Schema transformiert, das seinerseits automatisiert in gängigen Schemata wie XML-Schema, Relax-NG oder DTD umgeformt werden kann. Zusätzlich zu den vollständigen Guidelines steht eine abgeleitete, reduzierte Version namens TEI Lite zur Verfügung, die zugunsten einer leichteren Handhabbarkeit auf Vollständigkeit verzichtet und nicht zuletzt für Einsteiger konzipiert wurde.

Wie alle markupbasierten Systeme ist auch die TEI softwareunabhängig, es wird also keine bestimmte Software benötigt, um diesen Standard zu benutzen. Mittels spezieller Software und XML-Editoren, die zum Teil die TEI direkt integriert haben, ist ein deutlich komfortableres Arbeiten möglich.

Die Vorgaben der TEI beinhalten viel Freiraum, sodass eine individuelle Sicht auf einen Text möglich bleibt. Es handelt sich um Empfehlungen und Richtlinien und nicht um ein starres Regelwerk. Diese Selbstbestimmung durch den User ist aber gerade für den Einstieg eher ein Hindernis, da zwischen vielen möglichen Variationen entschieden werden muss, welche für den eigenen Zweck die beste ist. So kann diese Einführung auch nur eine Hilfestellung beim selbständigen Erarbeiten der Guidelines und kein Tutorial im klassischen Sinne sein. Es handelt sich auch nicht um eine vollständige Referenz, sondern um eine umfangreiche Auswahl der wesentlichen Charakteristika und die Beispiele sind überwiegend direkt den Guidelines entnommen.