Vergleich von Buch-Schemata unter Berücksichtigung des

Transcription

Vergleich von Buch-Schemata unter
Berücksichtigung des automatischen
Layouts wissenschaftlicher Bücher
– überarbeitete Version –
DIPLOMARBEIT
Hochschule für Technik, Wirtschaft und Kultur Leipzig (FH)
Fakultät Medien
Studiengang Verlagsherstellung
Vorgelegt von: Andrea Heidrich, geboren am 24.12.1985 in Leipzig
Betreut von: Andreas-Martin Selignow
Leipzig, 28. Februar 2010
Bibliografischer Nachweis
Heidrich, Andrea: Vergleich von Buch-Schemata unter Berücksichtigung des
automatischen Layouts wissenschaftlicher Bücher.
DIPLOMARBEIT: Hochschule für Technik, Wirtschaft und Kultur Leipzig (FH)
Fakultät Medien, Studiengang Verlagsherstellung, 2010.
148 Seiten, 23 Abbildungen, 18 Tabellen, 85 Quellenangaben, 2 Anlagen,
1 Datenträger.
Autorreferat
Die vorliegende Arbeit untersucht exemplarisch die vier DTD-Schemata ISO
12083, DocBook, TEI und das NCBI Book Tag Set. Dazu werden Kriterien für
die Auswahl eines Schemas für das Layout wissenschaftlicher Bücher entwickelt.
Zielgruppe dieser Arbeit sind diejenigen, die sich erstmalig mit der Problematik
auseinander setzen, welche DTD für ihr wissenschaftliches Buch geeignet ist und
demnach kaum Vorkenntnisse auf diesem Gebiet besitzen.
Ziel ist es, dem Anwender einen schnellen Einstieg in die Strukturen der Schemata
zu bieten sowie einen zusammenfassenden Überblick zu geben.
Des Weiteren wird anhand eines geisteswissenschaftlichen und eines medizinischen Fachbuches getestet, inwiefern sich welches Schema am Besten für die Abbildung des Layouts eignet. Dabei wird ebenso darauf eingegangen, wie InDesign
mit XML-Daten und DTDs umgeht und wie Absatz- und Zeichenformate mit den
Elementen der DTD verknüpft werden können.
Abschließend erfolgt ein Vorschlag für die Benennung von Absatz- und Zeichenformatvorlagen für den automatischen Satz.
3
Inhaltsverzeichnis
Einleitung
1. Problemstellung
2. Zielsetzung
3. Vorgehensweise
9
9
10
10
I. Begriffe und Definitionen
1. Auszeichnungssprachen
1.1 SGML
1.2 XML
2. Überblick über die Schemasprachen
2.1 Grammatikbasierte Schemasprachen
2.1.1 DTD
2.1.2 W3C XML-Schema
2.1.3 Relax NG
2.2 Regelbasierte Schemasprachen
2.2.1 ISO Schematron
2.3 Zusammenfassung
3. Allgemeines zu den Strukturelementen
von DTDs
3.1 Namensräume
3.2 Elementdeklarationen
3.2.1 Inhaltsmodelle
3.2.2 Häufigkeitsindikatoren
3.2.3 Inhaltstypen
3.3 Attributdeklarationen
3.3.1 Datentypen
3.3.2 Standardwerte
3.4 Entities
3.4.1 Globale, interne Entities
3.4.2 Globale, externe Entitäten
3.4.3 Interne Parameter-Entities
3.4.4 Externe Parameter-Entities
3.4.5 Geparste und ungeparste Entities
3.4.6 Notationen
12
12
12
12
13
13
13
14
15
15
15
16
17
18
18
18
19
19
20
20
21
22
22
23
24
24
25
25
II. Darstellung und Analyse der DTD-Schemata
1. Vergleichskriterien
1.1 Allgemeine Kriterien
1.1 DTD bezogene Kriterien
1.2 DTD-XML bezogene Kriterien
2. ISO 12083
2.1. Allgemeines
2.2 Aufbau und Struktur
2.3 Analyse anhand der Kriterien
2.3.1 Allgemeine Kriterien
2.3.2 DTD bezogene Kriterien
2.3.3 DTD-XML bezogene Kriterien
2.4 Beispiel: XML-Auszeichnung
26
26
26
26
27
28
28
28
29
29
32
34
35
Inhaltsverzeichnis4
3. DocBook
3.1. Allgemeines
3.3 Analyse der DTD anhand folgender Kriterien
4. TEI (Text Encoding Initiative)
4.1. Allgemeines
5. NCBI Book Tag Set
5.1 Allgemeines
5.2 Aufbau und Struktur 5.3 Analyse anhand der Kriterien
6. Vergleich der DTDs
6.1. Vergleichstabelle
6.3 Zusammenfassung der Kriterien
6.3.1 Zugänglichkeit
6.3.2 Dokumentierung
6.3.3 Entwicklung und die Umsetzung der Schemata in
Modulen
6.3.4 Umfang 6.3.5 Benutzerfreundlichkeit
6.3.6 Typografische Auszeichnungen
6.3.7 Möglichkeiten zur Anpassung der DTD an eigene
Anwendungen
6.3.8 Besonderheiten der Schemata
6.4 Zwischenfazit
III. Umsetzung der Bücher in XML und InDesign-Import
1. Strukturanalyse der Bücher
1.1 Vorstellung der Bücher
1.2 Geisteswissenschaftliches Buch
1.2.1 Block- und Inline-Elemente
1.2.2 Anforderungen an die DTD
1.2.3 Test: TEI
1.2.4 Test: DocBook
1.2.5 Test: NCBI Book Tag Set
1.2.6 Fazit zum Test
37
37
37
39
39
42
46
48
50
50
50
51
51
54
60
65
67
67
67
69
69
71
75
77
79
79
82
82
82
82
83
84
85
85
85
86
87
87
87
87
87
89
90
92
94
95
Inhaltsverzeichnis5
1.3 Medizinisches Fachbuch
1.3.4 Test: DocBook
2. Der XML-Workflow in InDesign
2.1 Arbeitsmittel
2.1.1 XML-Editoren
2.1.2 InDesign
2.2 Tabellenformate
2.2.1 OASIS Open Exchange CALS Table Model (XML)
2.2.2 XHTML
2.2.3 Zuordnung der Elemente
2.3 Von XML zu InDesign
2.3.1 Problematik
2.3.2 Herangehensweise
2.3.3 Validierung mittels DTD
2.3.4 Formatzuordnung
2.3.5 Probleme und Anmerkungen zum InDesignXML-Import
2.4 Liste der Absatz- und Zeichenformatvorlagen
2.4.1 Geisteswissenschaftliches Buch
2.4.2 Medizinisches Fachbuch
2.5 Zwischenfazit
IV. Fazit
96
96
99
99
101
103
104
104
104
105
105
106
107
109
109
109
109
110
111
112
114
114
118
123
125
Anhang
127
Glossar128
Quellenverzeichnis129
Selbstständigkeitserklärung133
Danksagung134
Thesen zur Diplomarbeit
135
6
Abbildungsverzeichnis
Abb. 1:
Abb. 2:
Abb. 3:
Abb. 4:
Abb. 5.
Abb. 6:
Abb. 7:
Abb. 8:
Abb. 9:
Abb. 10:
Abb. 11:
Abb. 12:
Abb. 13:
Abb. 14:
Abb. 15:
Abb. 16:
Abb. 17:
Abb. 18:
Abb. 19:
Abb. 20:
Abb. 21:
Abb. 22:
Abb. 23:
XML in Publishing Process
Überblick über die Entities
Top-level Struktur der ISO-DTD
ISO 12083, Buch-DTD
Top-level-Struktur eines DocBook-XML-Dokumentes
Aufbau der DocBook-Module
DocBook: DocBook-DTD
Top-level-Struktur eines TEI-XML-Dokumentes
TEI: tei.dtd
Erstellung einer TEI-DTD
Ein Schema erstellen, modifizieren oder auswählen
Metadaten für die Datei festlegen
Hinzufügen und Entfernen von Modulen
Hinzufügen und Entfernen von Elementen
Hinzufügen und Entfernen von Attributen
Top-level-Struktur eines Book Tag Set-XML-Dokumentes
Übersicht über alle Module des Book Tag Sets
NCBI Book Tag Set: Book-DTD
Aufbau des TEI-XML-Dokumentes
Aufbau des DocBook-XML-Dokumentes (geisteswissenschaftlich)
Aufbau des Book Tag Set XML-Dokumentes (geisteswissenschaftlich)
Aufbau des Book Tag Set XML-Dokumentes (medizinisch)
Aufbau des DocBook-XML-Dokumentes (medizinisch)
7
Tabellenverzeichnis
Tab. 1:
Tab. 2:
Tab. 3:
Tab. 4:
Tab. 5:
Tab. 6:
Tab. 7:
Tab. 8:
Tab. 9:
Tab. 10:
Tab. 11:
Tab. 12:
Tab. 13:
Tab. 14:
Tab. 15:
Tab. 16:
Tab. 17:
Tab. 18:
Allgemeine Kriterien
DTD bezogene Kriterien
DTD-XML bezogene Kriterien
DocBook-Versionen
TEI-Versionen
TEI-Module und Beschreibung
Book Tag Set-Versionen
Vergleich der DTDs
Blockelemente geisteswissenschaftliches Buch
Blockelemente medizinisches Fachbuch
Elemente und Attribute des CALS-Modells
Elemente und Attribute des XHTML-Modells
Zuordnung der Elemente von XHTML zu CALS
InDesign Tabellenattribute
Absatzformatvorlagen für geisteswissenschaftliches Buch
Zeichenformatvorlagen für geisteswissenschaftliches Buch
Absatzformatvorlagen für medizinisches Fachbuch
Zeichenformatvorlagen für medizinisches Fachbuch
8
Abkürzungsverzeichnis
AAP
ANSI
CALS
GNU
ISO
MWV
NCBI
NISO
NLM
OASIS
Association of American Publisher
American National Standards Institute
Continous Acquisition and Life-Cycle Support
GNU is not Unix
International Organization for Standardization
Medizinisch Wissenschaftliche Verlagsgesellschaft
National Center for Biotechnology Information
National Information Standards Organization
National Library of Medicine
Organization for the Advancement of Structured Information
Standards
ODD
One Document Does it all
Relax NG
Regular Language Description for XML New Generation
TEI
Text Encoding Initiative
W3C
World Wide Web Consortium
WYSIWYG What You See Is What You Get
9
Einleitung
Digitalisierung, Automatisierung, Standardisierung, eBook und ePublishing sind
Begriffe, die die Verlagsbranche derzeit maßgeblich beherrschen. Seit die neuen
eBook-Reader auf den deutschen Markt drängen, ist eine Auseinandersetzung mit
XML und der damit verbundenen Workflow-Umstellung nicht mehr aus der Verlagsbranche wegzudenken. Hinzu kommt die weltweit angestrebte Digitalisierung
und Volltextsuche von Bibliotheksbeständen, die eine zukünftige elektronische
Aufbereitung erfordern, um eine weltweite Nutzung der Inhalte zu ermöglichen.
Die Buchbranche befindet sich in einer Umbruchphase, in der die Bedeutung
des Verlages als Dienstleister stark zunimmt. Hier gilt es neue Geschäfts- und
Workflowmodelle zu entwickeln. Die Verlage aller Art sehen sich daher zusehendes mit den Themen XML, medienneutrale Datenhaltung und cross-medialem
Publizieren konfrontiert.
XML (Extensible Markup Language) ist das Basisformat für eBook Standards wie
ePub und Mobipocket. Während einige Verlage (Springer 1, de Gruyter) ihre Workflows bereits auf XML umgestellt haben, müssen andere sich erstmals intensiv mit
dem Standard auseinandersetzen. XML wird überall dort notwendig, wo es um
medienneutrale Datenhaltung geht. Die Bedeutung der medienneutralen Datenhaltung nimmt wiederum zu, weil es wirtschaftlicher ist, Inhalte unabhängig von
der späteren Verwendung zu erstellen und für unterschiedliche mobile Endgeräte
(Handhelds, Smartphones, Handys, eReader etc.) und Plattformen (Websites,
Communities etc.) aufzubereiten. Hier beschleunigen der technologische Druck
und andere Anbieter wie Google, Amazon und Apple das Handeln der Verlage.
Besonders im wissenschaftlichen Bereich sind die neuen Formen und Möglichkeiten des elektronischen Publizierens bereits sichtbar. Durchschnittlich 96,5%2
aller wissenschaftlichen Zeitschriften aus dem Bereich Medizin werden bereits
nach automatisierten und standardisierten Prozessen hergestellt. Die Vielfalt an
Fachzeitschriften bleibt trotzdem erhalten.
In der Wissenschaft nimmt die Aktualität der Inhalte eine zentrale Rolle ein
und es besteht großes Interesse, sich global mit Wissenschaftlern auszutauschen.
Erst mit der Entwicklung des Internets und den jetzigen Werkzeugen wie Content
Management Systemen, Redaktionssystemen und dem Online-Publizieren kann
weltweit auf die Inhalte zugegriffen werden.
1. Problemstellung
Anders als im Publikumsverlag, zeichnen sich Texte in den Fach- und Wissenschaftsverlagen durch eine starke Strukturierung aus. Das Layout folgt dem
Inhalt und unterstützt die Informationsaufnahme optisch. Zahlreiche Fußnoten, Anmerkungen, Marginalien, Verweise, Indizes, Abbildungen, Tabellen und
Sonderzeichen müssen verwaltet werden.
1 http://www.le-tex.de/de/xml.html, Zugriff am 24.01.10.
2 laut Vorlesung „Geschäftsprojektmanagement“ bei Joachim Brunold vom 22.01.–24.01.09.
Zielsetzung10
Es ist eine Herausforderung den Inhalt unter Berücksichtigung einer DTD
(Document Type Definition) abzubilden, so dass der Inhalt den Anforderungen
des wissenschaftlichen Satzes entspricht. Es dürfen keine Strukturelemente bei
der Auszeichnung der XML-Dokumente verloren gehen und die Auszeichnungen
müssen eindeutig sein.
Zu Beginn des Publizierens mit XML liegt die Schwierigkeit in der Strukturanalyse und der daraus abgeleiteten Verwendung einer bestimmten DTD. Entweder
wird eine Standard-DTD als Grundlage benutzt oder eine verlagseigene DTD
entwickelt. Bei einer Vielzahl an möglichen Inhaltsstrukturen fällt es schwer sich
auf eine geeignete DTD festzulegen, da sie ebenso einen sauber strukturierten
Text erzwingt. Der Einsatz einer DTD sichert damit eine einheitliche Struktur
der Bücher und eine Qualität des Workflows. Besonders für Reihentitel oder
periodisch erscheinende Zeitschriften bietet sich daher XML unter Verwendung
einer DTD an.
2. Zielsetzung
Der Schwerpunkt der Arbeit liegt zum einen auf der Analyse der DTDs und zum
anderen auf der Strukturanalyse zweier wissenschaftlicher Bücher und deren
Umsetzung mit XML unter Berücksichtigung einer DTD. Ziel ist ein valides
XML-Dokument für den InDesign XML-Import und eine Liste mit Absatzund Zeichenformatvorlagen für die automatische Zuordnung von XML-Tags zu
InDesign-Formaten.
Den Rahmen für die Strukturanalyse bilden die DTDs. Ausgehend von dem
ISO 12083-Standard haben sich weitere DTDs zur strukturierten Darstellung von
Inhalten herausgebildet. Relevant für diese Arbeit sollen die Formate DocBook,
TEI und das NCBI Book Tag Set sein. Jedes Format nutzt beispielsweise eine andere Notation für die Definition der Strukturelemente, die es in der vorliegenden
Arbeit zu untersuchen und zu vergleichen gilt. Dabei müssen geeignete Vergleichskriterien gefunden werden.
Die Diplomarbeit dient dazu, ein Gefühl für Strukturen und die Umsetzung in
XML mittels DTDs zu schaffen. Sie soll außerdem dazu ermutigen sich mit den
Strukturen von Dokumenten auseinander zu setzen, damit es leichter fällt, einen
XML-basierten Workflow aufzubauen.
3. Vorgehensweise
Die Arbeit entstand in Kooperation mit einem Verlagsdienstleister und einem
Verlagsservice in Berlin. Für die Analyse wissenschaftlicher Texte stehen aus jedem Unternehmen jeweils ein Buch und die entsprechende InDesign-Datei zur
Verfügung.
Als Einstieg in das Thema wird ein Überblick über die relevanten Begriffe,
die im Zusammenhang mit den Auszeichnungs- und Schemasprachen stehen,
gegeben.
Hinsichtlich des Vergleiches der DTDs soll der Frage nachgegangen werden,
welche DTD sich am besten für die Auszeichnung eines geisteswissenschaftlichen
und ein medizinischen Fachbuches eignet und welche Gründe dafür sprechen.
Vorgehensweise11
Im Praxisteil der Arbeit werden die Vor- und Nachteile der jeweiligen DTD deutlich ausgearbeitet und die XML-Dokumente der Bücher erstellt.
Für eine eindeutige Zuordnung der XML-Tags zu InDesign-Formatvorlagen
ist eine XSLT-Transformation notwendig. Die Regeln dazu werden anhand von
Überlegungen dargestellt. Eine praktische Umsetzung ist nicht Gegenstand dieser
Arbeit. Außerdem wird auf die Arbeit von XML mit InDesign CS4 eingegangen.
Die XML-Dateien und die verwendeten DTDs liegen der Diplomarbeit als CD bei.
Die mit einem hochgestellten „G“ gekennzeichneten Begriffe sind im Glossar auf
Seite 128 erläutert.
Hinweis: Aus Copyrightgründen fehlen im Anhang die Belegtexte der analysierten Bücher.
12
I. Begriffe und Definitionen
1. Auszeichnungssprachen
Auszeichnungssprachen oder auch Markup-Sprachen sind Sprachen, um Texteoder Textbestandteile beliebigen Inhaltes und beliebiger Länge auszuzeichnen.3
Zum Markup eines Dokumentes zählen die Start- und Endtags, Entity-Referenzen,
Kommentare, Deklarationen sowie Verarbeitungsanweisungen.4
1.1 SGML
SGML bedeutet Standard Generalized Markup Language und ist eine so genannte
Metasprache, das heißt eine Auszeichnungssprache zur Definition anderer Auszeichnungssprachen. SGML ist ein von der International Organization for
Standardization (ISO) als Norm ISO 8879 verabschiedeter Standard, der 1986
entwickelt wurde. Der Standard beschreibt wie Auszeichnungssprachen für eine
medienneutrale und elektronische Verarbeitung definiert sein müssen.
Abgeleitet von SGML sind beispielsweise HTML, XML und XHTML. Alle
Sprachen, die dem SGML-Standard entsprechen, sind ebenfalls Markup-Sprachen
und damit eine Anwendung von SGML.5
1.2 XML
XML ist eine Teilmenge von SGML. XML heißt Extensible Markup Language,
das heißt eine erweiterbare Auszeichnungssprache zur Darstellung von Inhalten.
Entwickelt wurde XML vom World Wide Web Consortium (W3C)G als
offener Standard. XML ist ein flexibel einsetzbares Textformat und dient der
strukturierten Speicherung und dem Austausch von Daten. Trotz vorgeschriebener
Syntaxregeln (z. B. der Verschachtelung von Tags) ist es möglich eigene Namen
für die Tags zu benutzen. Deshalb lassen sich XML-Dokumente auch mit wenig
Erfahrung leicht lesen und ihre Informationen leicht verstehen.
XML trennt zwischen den Daten selbst und der Verarbeitung von Daten. Einfach ausgedrückt wird zwischen Inhalt, Struktur und Layout unterschieden. Eine
XML-Datei kann mit verschiedenen anderen Dateien (DTD, CSSG, XSL) verknüpft
und auf unterschiedlichen Medien ausgegeben werden. Dadurch ist es möglich
Dokumente zielgruppengerecht aufzubereiten. Der Vorteil von XML besteht darin, dass es die Verarbeitung bei der Entstehung des XML-Dokumentes offen lässt
und lediglich den Inhalt und die Struktur abbildet.6 XML-Dokumente werden
von einem so genannten XML-ParserG interpretiert.
3
4
5
6
Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 25.
Vgl. Vonhoegen, Helmut: Einstieg in XML, S. 560.
Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 58f.
Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 17f.
Überblick über die Schemasprachen13
Andere von XML abgeleitete Sprachen sind XSLTG, XPathG, XQueryG etc. XML
ist demzufolge ein Sammelbegriff für eine Technologie.
2. Überblick über die Schemasprachen
Ein Schema im Sinne der Informatik bezeichnet die formale Beschreibung einer
Datenstruktur.
Bezogen auf XML, definiert ein Schema die Struktur und den Inhalt (Text,
Bild, Zahl, Link etc.) eines XML-Dokumentes. Spezielle Schemasprachen sind
z. B. Relax NG, W3C XML Schema und DTD, die in den folgenden Abschnitten
näher beleuchtet werden sollen.7
Schemasprachen unterteilen sich in grammatikbasierte und regelbasierte
Sprachen.8 Abgebildet sind diese in der ISO-Norm 19757, einem im Jahr 2006
entwickelten Standard für die Document Schema Definition Languages (DSDL).
Dieser ist eine Zusammenfassung verschiedener Techniken zur Validierung von
XML-Dokumenten mittels Relax NG, Schematron, Namespace-based Validation
Dispatching Language (NVDL), Data Type Library Language (DTLL), Document
Type Definition (DTD) und weiterer Sprachen. Mit DSDL ist es möglich ein XMLDokument mit mehreren Schemasprachen statt einer Einzigen zu validieren.
2.1 Grammatikbasierte Schemasprachen
Die grammatikbasierten Sprachen sind weit verbreitetet. Sie definieren die Aufbauregeln für XML-Dokumente, beispielsweise welche und wie viele Unterelemente (= Child elements) ein Element enthalten darf. Des Weiteren bestimmen
grammatikbasierte Schemasprachen welche Attribute ein Element besitzen darf
oder muss. Für die Attribute lassen sich unterschiedliche Datentypen (Text, Zahl,
u. a.) und Werte (required, implied, fixed) festlegen.
Die grammatikorientierten Sprachen unterscheiden sich teilweise stark in ihrer
Restriktivität, was bedeutet, dass einige Sprachen sehr genaue Vorschriften für die
Verwendung der Elemente und Attribute machen.
2.1.1 DTD
DTD ist die Abkürzung für Document Type Definition. Eine DTD wird benötigt,
um die Struktur eines XML-Dokumentes festzulegen. Sie ist vergleichbar mit der
Grammatik einer Sprache. Die DTD ist außerdem eine Hilfestellung für die Erstellung von XML-Dokumenten, da sie die Verwendung und Reihenfolge der Elemente klar definiert. Der Verweis auf eine DTD erfolgt aus dem XML-Dokument
heraus. Ohne DTD ist ein XML-Dokument zwar wohlgeformt, aber nicht gültig.
Die DTD bildet die Elemente und Attribute aus einem XML-Dokument ab und
dient der Zuweisung erlaubter Werte. Das bedeutet, dass alle XML-Dokumente,
die die gleichen Elemente benutzen und mit der DTD verknüpft sind, gleich behandelt werden. DTDs sind case sensitive, das heißt es wird zwischen Groß- und
Kleinschreibung unterschieden.
7 Vgl. Kränzler, Christiane: XML, XSL für Buch und Web, S. 358.
8 Vgl. Wilde, Erik: XML Schemasprachen: Übersicht und Einordnung, PDF-Präsentation.
Eine DTD lohnt sich jedoch erst für die Verarbeitung mehrerer gleichartiger
Dokumente oder wenn viele verschiedene Personen XML-Dokumente erstellen.
DTDs wurden ursprünglich für die Validierung von SGML-Dokumenten erstellt. Mit der Einführung von XML mussten auch die DTDs angepasst werden.
XML-DTDs sind im Vergleich zu SGML-DTDs etwas strikter, indem sie beispielsweise keinen unordered content und mixed content nur eingeschränkt verarbeiten
können.9 In einer SGML-DTD ist beispielsweise angegeben, bei welchen Elementen
die Endtags wegfallen dürfen; es wird nicht zwischen Groß- und Kleinschreibung
unterschieden und bei Attributen kann teilweise auf die Anführungszeichen verzichtet werden.10
Nähere Informationen zu den Inhalten von DTDs folgen unter 3. ab Seite 17.
2.1.2 W3C XML-Schema
Die DTD ist ein Schema um XML-Dokumente zu validieren, sie ist jedoch nicht in
XML-Syntax geschrieben. Außerdem sind DTDs weniger restriktiv, zum Beispiel
hinsichtlich der Datentypen. Aus diesen Gründen entwickelte das W3C 2001 das
XML-Schema. Hin und wieder taucht in der Literatur der Begriff XML-Schema
Definition Language (XSDL) auf. Sie ist gleichbedeutend mit XML-Schema und
W3C XML-Schema.
Das XML-Schema unterteilt sich in zwei Teile: Teil 1 ist die XSDL. Sie beschreibt
die Strukturen und Restriktionen von XML-Dokumenten. Diese Spezifikation
hängt von dem folgenden Teil 2 ab.11 Teil 2 beschreibt neben anderen XML-Spezifikationen12 die Datentypen, die in XML-Schema benutzt werden.
Mit Hilfe eines XML-Schemas lassen sich Elemente unter anderem kontextabhängig darstellen. Das Element für einen Absatz kann beispielsweise einmal mit
und einmal ohne Fußnote deklariert werden. Name und Elementtyp (simple type,
complex type) eines Elementes sind nicht direkt miteinander verbunden, sondern
nur assoziiert. Im Vergleich dazu ist es in einer DTD nur möglich die Fußnote
für einen Absatz optional zu halten, was ein weniger restriktives Inhaltsmodell
bedeutet.13
Zusammenfassend hat das XML-Schema im Vergleich zur DTD folgende Vorteile: Es ist restriktiver, das heißt, Inhalte lassen sich besser strukturieren und damit
kontrollieren; es unterstützt mehrere Datentypen und Namensräume; es ist selbst
in einem eigenen Namensraum definiert (xmlns:xsd=“http://www.w3.org/2001/
XMLSchema“) und ist in XML-Syntax geschrieben. Darüber hinaus sind in einem
XML-Schema ähnlich wie in einer DTD die Elemente, Attribute, deren Reihenfolge
und Häufigkeit etc. bestimmt. Der Nachteil eines XML-Schemas ist die schlechte
Lesbarkeit der XML-Dokumente durch die Verwendung eines NamensraumPräfixes.
9 Vgl. Walsh, Norman: Converting a SGML DTD to XML. http://www.xml.com/pub/a/98/07/dtd/
index.html#XMLDTD, Zugriff am 30.08.09.
10 Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 84.
11 Thompson, Henry S. et al.: XML Schema Part 1: Structures Second Edition. http://www.w3.org/
TR/xmlschema-1, Zugriff am 08.12.09.
12 Biron, Paul V et al.: XML Schema Part 2: Datatypes Second Edition. http://www.w3.org/TR/
xmlschema-2, Zugriff am 08.12.09.
13 Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 51ff.
2.1.3 Relax NG14
Relax NG ist die Abkürzung für Regular Language Description for XML New
Generation. Der Standard wurde Ende 2001 durch das Technical Committee von
OASIS (Organization for the Advancement of Structured Information
Standards) entwickelt und ist Bestandteil der oben genannten ISO-Norm (ISO
19757). Relax NG basiert auf den Sprachen TREX (Tree Regular Expressions for
XML) von James Clark und RELAX Core von Makoto Murata.
Relax NG hat folgende Eigenschaften: Es existiert sowohl eine ausführliche
XML-Syntax als auch eine kompakte Nicht-XML-Syntax; es unterstützt XMLNamensräume (XML namespaces) und es kann mit anderen Schemasprachen zusammenarbeiten. Des Weiteren sind Attribute immer Teil des Inhaltsmodells (vgl.
DTD und XML-Schema, hier sind die Attributdeklarationen von den Elementen
getrennt) und es wird eine uneingeschränkte Unterstützung von unordered und
mixed content gewährleistet.
In Relax NG existieren nur die beiden vordefinierten Datentypen text und token.
Aus diesem Grund konzentriert sich Relax NG im Vergleich zum XML-Schema auf
die Strukturbeschreibung. Es ist jedoch möglich weitere Datentypen einzubinden.
Relax NG gilt als eine einfacher zu handhabende Alternative zu XML-Schema,
es ist weniger umfangreich und leichter erlernbar.15
2.2 Regelbasierte Schemasprachen
Was grammatikbasierte Sprachen nicht oder nur teilweise können, ist die Strukturen in Abhängigkeiten von anderen Elementen und Attributen zu beschreiben.16
Regelbasierte Sprachen hingegen können überprüfen, ob ein Element oder ein
Attribut einen bestimmten Inhalt hat oder nicht. Beispielsweise ist es möglich,
dass ein Element direkt Text enthält, oder dass das gleiche Element ein Attribut
mit dem Text enthält. Eine Sprache wie Schematron überprüft, ob dieser Text in
einer der beiden Varianten vorkommt. Falls beide Varianten zu einem negativen
Ergebnis führen, ist es ein Widerspruch und folglich ein Fehler.
Die regelbasierten Sprachen sind eine gute Ergänzung zu den grammatikbasierten
Sprachen. Sie geben dem Workflow mehr Stabilität und Sicherheit. Existiert zum
Beispiel ein Workflow auf der Grundlage von DTDs, lässt sich ein SchematronDokument zur Überprüfung der Abhängigkeiten dazwischen schalten, das heißt
noch vor die Transformation des XML-Dokumentes.
2.2.1 ISO Schematron
Die regelbasierte Schemasprache Schematron dient der Ergänzung der grammatikbasierten Schemasprachen. Der ISO-Standard, im Oktober 2004 herausgegeben, definiert Regeln in der XML-Sprache XPath für die Überprüfung von
XML-Dokumenten. Aus der Perspektive jedes Elementes werden Szenarien beschrieben, die Zusammenhänge zwischen Elementen testen. Das Ergebnis kann
14 Vgl. Makoto, Murata: Relax NG. http://relaxng.org, Zugriff am 21.09.09.
16 Dünckel, Björn et al.: Über die Eignung von Schema-Sprachen zur Prüfung von XML-Dokumenten. http://it-republik.de/php/artikel/Ueber-die-Eignung-von-Schema-Sprachen-zur-Pruefungvon-XML-Dokumenten-2459.html, Zugriff am 21.09.09.
wahr oder falsch sein – zum Beispiel ob eine bestimmtes Element das Kindelement
von einem anderen Element ist.17 Schematron schaut folglich auf Zusammenhänge
und Muster in der Baumstruktur des XML-Dokumentes.
Für die Erstellung einer Regel werden lediglich die vier Elementtypen pattern,
rule, assert und report benutzt. Mit pattern gruppiert man alle Regeln zu einem
bestimmten Element. Das Attribut context gibt den Ort des Elementes durch einen XPath-Ausdruck an. Das Attribut test beschreibt einen XPath-Ausdruck zum
Testen des Elementes. Ein XPath-Ausdruck kann beispielsweise eine Funktion
oder eine logische Verknüpfung sein.
Außerdem definiert ISO Schematron die XML-Sprache SVRL (Schematron
Validation Report Language). Damit wird eine Reportdatei über die Ergebnisse
der Validierung und eventuelle auftretende Fehler im XML-Dokument erstellt.18
2.3 Zusammenfassung
Bevor im Verlauf der Arbeit intensiver auf die DTDs eingegangen wird, soll an
dieser Stelle ein Überblick über das Zusammenwirken von Inhalt, Struktur und
Format gegeben werden.
Parser
Wohlgeformtheit testen
Parser
Validierung des
XML-Dokumentes
durch die DTD
Parser
1. Struktur definieren
DTD
0. Strukturdiagramm
2. Inhalt erstellen
XML
Transformer
3. Formatieren
und Publizieren
XSL
datenorientierter
Output, zum
Beispiel ein Register
dokumentorientierter
Output, zum Beispiel
ein Buch
Abb. 1: XML in Publishing Process.19
Um zu einer DTD zu gelangen, existieren zwei verschiedene Ansätze. Die eine
Möglichkeit ist die Erstellung einer eigenen DTD auf der Grundlage eines Strukturdiagrammes. Die andere Variante greift auf eine Standard-DTD zurück. Beide Ansätze haben Vor- und Nachteile, die an dieser Stelle nicht weiter diskutiert
werden sollen.
17 Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 539 f.
18 Vgl. Schematron: How is Schematron used? http://www.schematron.com, Zugriff am 26.09.09.
19 Vgl. Kari Aaltonen: Defining XML in Publishing vom 31.08.06. In: XML and Multichannel
Publishing. Finnland: EVTEK.
Allgemeines zu den Strukturelementen von DTDs17
In einem ersten Schritt wird durch den Parser die Wohlgeformtheit des Dokumentes überprüft. Ein XML-Dokument gilt als wohlgeformt, wenn es den Regeln
der XML-Syntax20 entspricht.
Im nächsten Schritt kann die Gültigkeit des Dokumentes überprüft werden.
Ein Dokument ist gültig, wenn es wohlgeformt ist und den Regeln der DTD oder
des Schemas entspricht.21 In einer DTD ist die Struktur des XML-Dokumentes
abgebildet, anhand derer der Parser die Gültigkeit des Dokumentes prüft.
Ein XML-Dokument lässt sich zwar ohne DTD verarbeiten, es wird jedoch keine
Übereinstimmung mit einer definierten Struktur gewährleistet. Insbesondere für
mehrere, gleichartige XML-Dokumente lohnt es sich eine DTD in den Workflow
einzubauen. Hinzu kommt, dass die meisten XSLT-Prozessoren G lediglich nach
dem Vorhandensein einer DTD-Deklaration suchen, aber ein Dokument nicht
automatisch gegen diese validieren. Aus diesem Grund können ungültige, aber
wohlgeformte XML-Dokumente entstehen.22 Es ist daher sinnvoll ein Dokument
vor der Transformation in andere Formate zu validieren.
Das valide XML-Dokument wird schließlich mittels XSLG transformiert. XSL ist
ein „Konzept für die Verarbeitung und Nutzung von XML-Daten bzw. -Dokumenten.23 “. Die Teilkonzepte von XSL heißen XSLT, XPath und XSL-FOG. 24 Während
des Transformationsprozesses können Informationen aus dem XML-Dokument
entfernt, hinzugefügt, umsortiert und umbenannt werden. Die Verarbeitung hängt
von der Struktur des XML-Dokumentes ab. Die Struktur sollte immer möglichst
eindeutig sein.
Ein XML-Dokument wird nach verschiedenen Ansätzen formatiert: zum einen
der dokumentorientierte Ansatz und zum anderen der datenorientierte Ansatz,
je nachdem was ausgegeben werden soll. Im Bereich der Verlage ist meistens der
dokumentorientierte Ansatz vordergründig. Das bedeutet, dass XML vor allem
zum Transport und zur Speicherung von Informationen in einem medienneutralen
Umfeld genutzt wird und dass es um das Dokument als Ganzes geht. Hinsichtlich
der Strukturen sind in Büchern hauptsächlich semistrukturierte Informationen
wie Überschriften, Abschnitte, Fließtexte usw. enthalten, aber teilweise auch hochstrukturierte Informationen wie beispielsweise Tabellen.25
3. Allgemeines zu den Strukturelementen
von DTDs
Nachdem im vorherigen Kapitel der Begriff DTD im Zusammenhang mit XMLDokumenten erläutert wurde, widmet sich dieses Kapitel den Strukturelementen
von DTDs. Dazu zählen Namensräume, Element- und Attributdeklarationen,
Entities und Notationen.
21 Vgl. W3 Schools: XML Validation. http://www.w3schools.com/XML/xml_dtd.asp, Zugriff am
11.05.09.
22 Vgl. Stayton, Bob: DocBook XSL: The Complete Guide, S. 13 f.
23 Vgl. Krüger, Manfred: XSL-FO verstehen und anwenden. S. 3.
24Ebenda.
Allgemeines zu den Strukturelementen von DTDs 18
3.1 Namensräume
Namensräume bzw. namespaces sind erforderlich, wenn in einem XML-Dokument
mehrere XML-Sprachen verwendet werden. Bekanntermaßen ist die XML-Sprachfamilie sehr groß. Jede Sprache besitzt eigene Elemente und Attributnamen, die
sich überschneiden können, sobald sie in einem gemeinsamen XML-Dokument
verwendet werden. Die Verwendung eines Präfixes verhindert dieses Problem:
Es kommt zu keinen Konflikten oder Mehrdeutigkeiten in der Bennennung von
Elementen.26
Eine DTD erlaubt beispielsweise die zwei verschiedenen Tabellenmodelle
XHTML und CALS. Um Konflikte zu vermeiden, erhält jedes Element des CALSModells das Präfix oasis (Das Tabellenformat hat die Organisation OASIS entwickelt.) und die Elemente einer XHTML-Tabelle kein Präfix. Für den Vergleich der
beiden Tabellenmodelle siehe Kapitel II, Abschnitt 2.2, Seite 106.
Namensräume sind weiterhin sinnvoll, wenn beispielsweise mehrere Personen
an einem Dokument arbeiten. In diesem Fall arbeitet jede Person in einem eigenen Namensraum und bei einer möglichen Zusammenführung der Dokumente
entstehen keine Konflikte.
Der Namensraum definiert sich über das spezielle XML-Attribut xmlns. Zur
Identifizierung wird ein eindeutiger URIG benötigt. Eine Deklaration könnte wie
folgt aussehen:
<TEI xmlns=“http://www.tei-c.org/ns/1.0“>
Hat ein Element kein Präfix, gilt der default namespace (siehe oben). Die Namensraumdeklaration hat keine Verweisfunktion. Der URI dient lediglich der eindeutigen, formalen Bezeichnung des Namensraumes.
Optional kann für jeden Namensraum ein eigenes Präfix bestimmt werden.
Dann sieht die Deklaration folgendermaßen aus. Das Präfix ist in diesem Fall „tei“.
<TEI xmlns:tei=“http://www.tei-c.org/ns/1.0/“>
3.2 Elementdeklarationen
Ein Element wird in einer DTD durch ein Inhaltsmodell und die Häufigkeitsindikatoren beschrieben.
3.2.1 Inhaltsmodelle27
Ein Inhaltsmodell beschreibt, welche Art von Inhalt, in welcher Reihenfolge und
wie oft für ein Element zugelassen ist. Die Reihenfolge sollte in Abhängigkeit von
einer sinnvollen Struktur gewählt werden.
Inhaltsmodelle enthalten entweder Sequenzen von Elementen (Trennung
durch Kommata) oder Wahlmöglichkeiten zwischen Elementen (Trennung durch
26 Vgl. Herpers, Franz-Josef: XML-Namensräume und Validierung. http://aktuell.de.selfhtml.
org/artikel/xml/namensraeume, Zugriff am 09.12.09.
vertikalen Strich) oder beides (mixed content).28 Durch die Festlegung von Inhaltsmodellen wird eine Konsistenz der Daten erreicht.
3.2.2 Häufigkeitsindikatoren
Die Indikatoren +, * und ? legen die Häufigkeit der einzelnen Elemente fest.
+ mindestens einmal oder wiederholt auftauchend
* gar nicht, einmal oder beliebig oft auftauchend
? kein Mal oder genau einmal auftauchend
Steht keines dieser Indikatoren bedeutet es, dass das Element einmal vorhanden
sein muss.
3.2.3 Inhaltstypen
Die Inhaltstypen sind Teil des Inhaltsmodells. Sie heißen ANY, EMPTY, #PCDATA und #CDATA, Gemischter Inhalt und Elementinhalt. Durch Kombination
der Inhaltstypen mit den Häufigkeitsindikatoren lassen sich die unterschiedlichsten Inhaltsmodelle bauen, wie in den folgenden Abschnitten dargestellt.
<!ELEMENT buecher ANY> Jeder Inhalt ist für das Element möglich, sowohl
verschiedene Elemente als auch Zeichendaten. ANY wird vom Parser nicht auf
Gültigkeit überprüft, dies widerspricht dem Zweck einer DTD.29 Deshalb sollte
dieser Inhaltstyp möglichst vermieden werden, da er zu viel Freiraum lässt und
die Struktur nicht eindeutig definiert.
<!ELEMENT verweis EMPTY> Dieser Typ definiert, dass ein Element keinen
Inhalt enthalten darf. EMPTY ist sinnvoll, wenn ein Element keine anderen Elemente enthält, sondern nur Attribute, wie beispielsweise eine Bildreferenz.
<!ELEMENT absatz #PCDATA> Das Element enthält Zeichendaten. PC bedeutet
Parsed Characters und gibt dem Parser den Hinweis, dass dieses Element Text
enthält.
<!ELEMENT bild #CDATA> steht für Character Cata. Dieser Inhaltstyp wird für
Zeichendaten ohne Markup verwendet und wird nicht vom Parser gelesen.
<!ELEMENT buecher (#PCDATA | buch)*> Hier enthält das Element „buecher“
gemischten Inhalt (mixed content), das heißt eine Kombination aus Zeichendaten
und Unterelementen. Es bleibt offen, ob das Element „buecher“ nur Zeichendaten
enthält oder das Kindelement „buch“.
Der Nachteil von gemischten Inhalten ist der Kontrollverlust über die Reihenfolge
und die Häufigkeit der Elemente. Gemischter Inhalt erfordert das Sternchen *.
<!ELEMENT buecher (buch+, kategorie)> Das Element „buecher“ enthält nur
Unterelemente in einer festgelegten Reihenfolge: „buch“ und „kategorie“ sind
28 Vgl. NCBI: Implementing These Tag Sets. http://dtd.nlm.nih.gov/book/tag-library, Zugriff am
05.09.09.
29 Vgl. Vonhoegen. Einstieg in XML: Grundlagen, Praxis, Referenzen, S. 85.
Kindelemente von „buecher“. Das Element „buecher“ enthält ein oder mehrere
Elemente „buch“ und ein Element „kategorie“.
3.3 Attributdeklarationen
Attribute stellen Zusatzinformationen für Elemente dar. In der DTD ist festgelegt,
welche Attribute ein Element besitzt und welche Werte ein Attribut annimmt.
In der DTD sind Attribute immer nach dem folgenden Schema mit dem Schlüsselwort ATTLIST deklariert.
<!ATTLIST Elementname Attributname Datentyp Standardwerte>
Zum Beispiel: <!ATTLIST buch isbn CDATA #REQUIRED>
Außerdem ist es möglich für Attribute eine Auswahl an möglichen Werten festzulegen. Elemente, die das Attribut verwenden, müssen immer einen der Werte
annehmen.
<!ELEMENT buch (#PCDATA)>
<!ATTLIST buch
typ (Hardcover | Softcover | Flexicover) #REQUIRED
Attribute beziehen sich immer auf das jeweils zugehörige Element. Ein Attribut
besitzt einen Datentyp und einen Standardwert, auf die in den folgenden Abschnitten eingegangen wird.
3.3.1 Datentypen
CDATA heißt Character Data, Zeichendaten. Das Attribut nimmt jede beliebige
Zeichenfolge an, ohne die Zeichen &, <, > oder “, da diese durch gesonderte Named
Entities (&, <, > und ") definiert werden.
ID: Bezeichnet eine eindeutige ID für ein Attribut, beispielsweise eine ISBN. Eine
ID darf innerhalb eines gesamten XML-Dokumentes nur ein einziges Mal vorkommen. IDs dürfen nicht mit einer Ziffer beginnen, wie es bei einer ISBN der
Fall ist. Deshalb wird hier ein Buchstabe oder ein Zeichen (Punkt, Bindestrich,
Unterstrich, Doppelpunkt) verwendet.
IDREF/IDREFS: Um auf die ID eines Elementes zu verweisen (Querverweise), wird
das Attribut IDREF verwendet. Dadurch wird eine eindeutige Zuordnung erzielt.
Der Parser prüft, ob zu jedem IDREF eine ID existiert. Für IDREFS besteht der
Wert aus mehreren Referenzen, getrennt durch ein Leerzeichen.
ENTITY/ENTITIES: Damit können Referenzen innerhalb einer DTD abgebildet
oder häufig vorkommende Textteile ersetzt werden. Nähere Erläuterungen dazu
folgen weiter unten.
NMTOKEN/NMTOKENS: Ist eine Zeichenkette, die im Vergleich zur ID nicht
eindeutig sein muss und die mit einer Ziffer oder einem Sonderzeichen beginnen
darf. Leerzeichen sind nicht erlaubt.
Der Datentyp ist zum Beispiel für Geburtsdaten sinnvoll. NMTOKENS enthalten
mehrere NMTOKEN.
NOTATION:30 Der Datentyp verweist auf eine Notation, zum Beispiel für Bildformate (gif, jpg, png etc.) und wird beispielsweise wie folgt deklariert:
<!NOTATION gif PUBLIC „-//ISBN 0-7923-9432-1::Graphic Notation//NOTATION CompuServe Graphic Interchange Format//EN“>.
3.3.2 Standardwerte
Neben den Datentypen hat jedes Attribut einen Standardwert oder einen festgelegten Attributwert. Die Standardwerte sind:
▶▶ #REQUIRED, das heißt das Attribut muss angegeben werden, sobald das
Element verwendet wird.
▶▶ #IMPLIED bedeutet das Attribut ist optional.
▶▶ #FIXED steht für ein optionales Attribut, das immer den gleichen Wert annimmt sobald es angegeben wird.
▶▶ „Attributwert“: Definiert einen speziellen Standardwert, der automatisch verwendet wird, wenn kein anderer Wert für das Attribut angegeben ist. Dies
bedeutet es wird auf den angegebenen Standardwert zurückgegriffen, wenn das
XML-Dokument zwar das Element aber nicht das Attribut verwendet.
<!ELEMENT buch (#PCDATA)>
<!ATTLIST buch
typ (Hardcover | Softcover | Flexicover) “Hardcover”
Innerhalb der DTDs werden die Element- und Attributdeklarationen mittels Parameter Entities (siehe Punkt 3.4.3) definiert. Das folgende Beispiel zeigt, wie eine
Konstruktion aussehen kann. Das Beispiel ist dem NCBI Book Tag Set entnommen.
Zunächst wird eine Entity mit dem Namen citation-atts deklariert. Die Entity
enthält die verschiedenen Attributdefinitionen und ist quasi als eine Art Container vorstellbar.
<!ENTITY % citation-atts
“id
ID#IMPLIED
publication-type CDATA#IMPLIED
publisher-type
CDATA#IMPLIED
publication-format CDATA#IMPLIED
%might-link-atts;”>
Diese Entity wird dann innerhalb der Attributdeklaration für das Element elementcitation aufgerufen.
<!ELEMENT element-citation (%citation-elements;)+ >
<!ATTLIST element-citation
%citation-atts; >
30 Vgl. SELFHTML: Attribute mit Entity-Wert (z. B. für externe Dateireferenzen).
http://de.selfhtml.org/xml/dtd/attribute.htm#mit_entitywert, Zugriff am 31.08.09.
3.4 Entities
Entities sind Variablen.31 Generell dienen sie dazu, Text, Dokumente oder Dokumentteile in irgendeiner Form zu ersetzen, um einerseits die Übersichtlichkeit zu
erhöhen und andererseits die Arbeit zu erleichtern. Für die modulare Struktur von
DTDs sind Entities unumgänglich. Für die Analyse der DTDs ist es wichtig, das
Prinzip von Entities zu verstehen. Deshalb ist in den folgenden Abschnitten das
Wesentliche zu den verschiedenen Arten von Entities zusammengefasst.
Man unterscheidet zwischen globalen Entities und Parameter-Entities. Darüber
hinaus existieren jeweils interne und externe Entities. Die folgende Skizze gibt
einen Überblick.
Entities
globale Entities
Parameter-Entities
Bezug zwischen DTD und
XML-Dokument
Referenz innerhalb oder
zwischen DTDs
interne
– Zeichenentities
– Ersatztext
externe
– Integration anderer
Dokumente etc.
in XML
interne
– Ersatztext
externe
– Module
– Verweis
externe,
ungeparste
– Integration anderer
Dokumente etc.
in XML
Abb. 2: Überblick über die Entities (Eigene Darstellung)
3.4.1 Globale, interne Entities
Zeichenentities
XML arbeitet mit fünf vordefinierten Zeichenentities: &, <, > '
und ". Diese müssen nicht in der DTD deklariert werden, sondern sind direkt im Dokument anwendbar. Sie stellen Sonderzeichen korrekt dar, die sonst
von der XML-Syntax verboten wären. Zeichenentities beginnen immer mit einem
kaufmännischen „und“ und enden mit einem Semikolon.
Prinzipiell sind alle Zeichen im XML-Dokument direkt ohne Deklaration verwendbar.32 Wenn sie jedoch sehr häufig vorkommen, ist eine Definition in einer
Entity am Anfang des Dokumentes sinnvoll.
31 Vgl. W3 School: DTD – Entities. http://www.w3schools.com/dtd/dtd_entities.asp, Zugriff am
09.05.09.
32 Liste mit gängigen Sonderzeichen auf: http://de.selfhtml.org/html/referenz/zeichen.htm, Zugriff am 09.12.09.
▶▶ Beispiel:
<!ENTITY % ü „ü“> Durch diese Deklaration ist der Buchstabe „ü“ direkt im
XML-Dokument nutzbar und wird korrekt dargestellt.
Die Bedeutung der Zeichenentities nimmt durch die UTF-8 G und UTF-16 G Kodierung ab. Diese Kodierungen sind ausreichend für eine Vielzahl von Unicode GSonderzeichen und können direkt über die Tastatur eingegeben werden. Die Art
der Kodierung wird zu Beginn eines XML-Dokumentes angegeben.
Entities für Ersatztext
Entities eigen sich außerdem für die Darstellung von wiederkehrenden Texten.
Der Text wird einmalig in einer Entity in der DTD definiert und ist anschließend
über den Namen der Entity an mehreren Stellen im XML-Dokument aufrufbar.
Die Deklaration folgt dem Schema:
<!ENTITY Entitätsname „Ersatztext“>
▶▶ Ein Beispiel für eine interne Entity-Deklaration:
In der DTD-Datei:
<!ENTITY writer „Donald Duck.“>
<!ENTITY copyright „Copyright W3Schools.“>
Im XML-Dokument:
<author>&writer;&copyright;</author>
Der Parser erkennt anhand der „&“-Symbole die Entities und ersetzt diese bei der
Verarbeitung des Dokumentes durch den definierten Ersetzungstext.
Ändert sich der Name von „writer“ muss dies nur einmal in der Entity-Deklaration manuell geändert werden und ändert sich automatisch an allen anderen
Stellen, wo writer aufgerufen wird. Dadurch wird viel Zeit gespart und die Fehlerwahrscheinlichkeit minimiert.
Kommen die gleichen Entities innerhalb mehrerer XML-Dokumente vor, sind
die Entity-Deklarationen auch extern in einer separaten Datei speicherbar.
3.4.2 Globale, externe Entitäten
Mit externen Entities ist es möglich umfangreiche Dokumente und andere Dateien
(Bilder) in XML einzubinden. Sie eignen sich dazu jedes Kapitel eines Buches in
einem Masterdokument zusammen zu führen. Dabei bildet jedes Kapitel eine eigene Datei. Diese Unterteilung ist vergleichbar mit der Buchfunktion in InDesign.
Externe Entities werden nach dem Schema:
<!ENTITY Entitätsname SYSTEM „URI/URL“> definiert.
▶▶ Ein Beispiel für eine externe Entity-Deklaration:
In der DTD-Datei: Beispiel mit einer URL
<!ENTITY writer SYSTEM „http://www.w3schools.com/entities.dtd“>
<!ENTITY copyright SYSTEM „http://www.w3schools.com/entities.dtd“>
Im XML-Dokument:
ODER
In der DTD-Datei: Beispiel mit einem URI
<!ENTITY writer SYSTEM „writer.txt“>
<!ENTITY copyright SYSTEM „copyright.txt“>
Im XML-Dokument:
3.4.3 Interne Parameter-Entities
Auch Parameter-Entities sind Variablen, die aber nicht auf die Inhalte in einem
XML-Dokument verweisen, sondern Verweise innerhalb einer DTD sind.33 Parameter-Entities werden verwendet, um bei großen DTDs wiederholt benötigte Ausdrücke durch Makros zu ersetzen.34 Tauchen mehrmals die gleichen Element- oder
Attributlisten auf, wird also ein Parameter definiert, der diese Listen beschreibt
und es wird an entsprechender Stelle in der DTD darauf verwiesen.
In der Syntax unterscheiden sich globale Entities und Parameter-Entities nur
durch ein Prozentzeichen vor dem Entitätsnamen.
Sie werden wie folgt dargestellt:
<!ENTITY % Entitätsname „Ersatztext“>
▶▶ Ein Beispiel ist:
<!ENTITY % Gliederung „kapitel | absatz | zeile“>
Wird in der DTD „% Gliederung“ eingegeben, ruft diese Variable immer die drei
Elemente kapitel, absatz und zeile auf.
▶▶ Aufruf zum Beispiel:
<!ELEMENT dokument (% Gliederung;)*>
3.4.4 Externe Parameter-Entities
Mittels externer Entities wird eine DTD in einzelne DTDs unterteilt. Aus einer
Master-DTD wird auf die Teile anderer DTDs verwiesen. Im Prinzip kann jede
Deklaration eine Datei sein. Dadurch werden große Dokumente viel übersichtlicher. Ein weiterer Vorteil ist die hohe Flexibilität, weil die DTD schnell auf
unterschiedliche XML-Dokumente angepasst werden kann.
▶▶ Beispiel:
<!ENTITY % buecher „buch.dtd“>
Mittels externer und interner Parameter-Entities lassen sich komplex verschachtelte Module bauen. Die DTDs entstehen nach diesem so genannten Baukastenprinzip.
33 Vgl. come2xml: XML Entity-Definitionen – Parameter-Entities. http://www.come2xml.de/ref_
entity_parameter.html, Zugriff am 09.05.09.
34 Vgl. Auer, Jürgen: Entities: Definition und Verwendung. http://www.sql-und-xml.de/xml-lernen/document-type-definition-entities-xml-document.html, Zugriff am 09.05.09.
3.4.5 Geparste und ungeparste Entities
Normalerweise wird bei dem Parsen der Inhalt der Entity durch eine Zeichenkette ersetzt, das bedeutet der Parser verarbeitet diese Entities. Bei Bildern ist dies
jedoch unerwünscht, weshalb dem Parser gesagt werden muss, dass diese nicht
verarbeitet werden sollen. Das Schlüsselwort dafür lautet NDATA (Notation Data)
gefolgt von einem Notationsnamen. Eine nicht zu parsende Entitiy-Deklaration
sieht zum Beispiel folgendermaßen aus.
<!ENTITY ball SYSTEM „ball.gif“ NDATA gif>
3.4.6 Notationen
Die Verwendung von ungeparsten Entities steht mit den Notationen in engem
Zusammenhang. Eine Notation ist ein Verarbeitungshinweis für den Parser.
Wie bereits bei den Attributtypen erwähnt, müssen zum Beispiel Bildformate in
einer Notationsdeklaration definiert werden, damit diese verwendbar sind. Eine
Notation für obiges Beispiel könnte so aussehen:
<!NOTATION gif PUBLIC „+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION
CompuServer Graphic Interchange Format//EN“>
26
II. Darstellung und Analyse der DTD-Schemata
1. Vergleichskriterien
Für die Analyse der Schemata werden verschiedene Kriterien entwickelt, anhand
derer sich ein Vergleich durchführen lässt. Die Vergleichskriterien sind in drei
Kategorien unterteilt, die in den folgenden Abschnitten vorgestellt werden.
1.1 Allgemeine Kriterien
Unter den allgemeinen Kriterien sind jene zusammengefasst, die generelle Informationen über die DTD geben. Die Tabelle gewährt einen Überblick.
Kriterium
Erklärung
Zugänglichkeit
Wo finde ich das Schema? Ist es kostenlos
erhältlich? Inwieweit wurde Barrierefreiheit
umgesetzt?
Verwendungszweck
Beschreibt für welche Anwendungen sich die
DTD besonders eignet.
Lizenzbedingungen
Sie stellen den rechtlichen Rahmen für die Verwendung der DTD dar. Welche Einschränkungen
gibt es eventuell? Was muss bei der Nutzung der
DTD beachtet werden?
Aktualisierung
Beschreibt die Entwicklung und Anpassung des
Schemas. Besonderheiten im Vergleich zu vorherigen Versionen.
Dokumentierung
Wo finde ich die Dokumentation und in welcher
Form (Online, Print, Beides) liegt sie vor? Gibt
es weiterführende Bücher? Welche weitere Hilfe
und Unterstützung wird dem Anwender geboten, z. B. Tutorien, evtl. Mehrsprachigkeit, Blogs,
Nutzerforen usw.
Tab. 1: Allgemeine Kriterien
1.1 DTD bezogene Kriterien
Die unter diesem Punkt dargestellten Kriterien beziehen sich auf die Eigenschaften
der DTD selbst wie beispielsweise die Modularität, die Übersichtlichkeit, vorhandene Subsets etc. Der Vergleich dieser Kriterien dient vor allem den Anwendern,
die sich mit der Modifizierung und der inneren Struktur der DTD beschäftigen
werden.
Vergleichskriterien27
Kriterium
Erklärung
Komplexität
Welche Module sind umfangreich? Wie haben
sich die Module entwickelt? Gründe für die
Komplexität. Zahlenmäßiger Vergleich der Anzahl der Elemente, Attribute und Module.
Modularität
Ist das Schema modular aufgebaut? Wenn ja,
wie? Zusammenhänge zwischen den Modulen.
Inhalt der Module.
Übersichtlichkeit
Wie leicht lassen sich die einzelnen Module
nachvollziehen? Übersichtlichkeit des Schemas
insgesamt.
Namenskonventionen
Welche Prä- und Suffixe gibt es für Elemente,
Attribute und Klassen? Wie werden die Namen
abgekürzt? Konsistenz in der Benennung.
Modifikation
Welche Möglichkeiten hat der Anwender, das
Schema anzupassen? Was ist zu beachten? Gibt
es eventuell schon vorgefertigte Modifizierungen
(Subsets) des Schemas?
Tab. 2: DTD bezogene Kriterien
1.2 DTD-XML bezogene Kriterien
Die folgenden Kriterien vergleichen die XML-Dokumente, die auf Basis der jeweiligen DTD entstanden sind. Verglichen werden wichtige Strukturelemente
und wie jede DTD diese handhabt. Die Umsetzung und die Ergebnisse folgen im
Praxisteil der Arbeit.
Kriterium
Erklärung
Element- und Attributnamen
Besonderheiten in der Benennung von
Elementen und Attributen.
Typografische Auszeichnungen
Welche Elemente bietet die DTD für
die typografische Auszeichnung von Textelementen?
Tabellenmodelle
Darstellung welches Tabellenmodell von der
DTD favorisiert wird und welche weiteren
Tabellenmodelle angeboten werden.
Listen
Welche Listenarten stellt die DTD zur Verfügung?
Besonderheiten
Leistungsumfang des Schemas, z. B. XSLStylesheets, Editoren, Online-Bearbeitung
des Schemas.
Tab. 3: DTD-XML bezogene Kriterien
ISO 1208328
2. ISO 12083
2.1. Allgemeines
Die ISO 12083 mit dem Titel „Information and Documentation – Electronic
Manuscript Preparation and Markup“ ist ein kostenpflichtiger ISO-Standard.
Ursprünglich entwickelte die Association of American Publishers (AAP)
die erste Version im Jahr 1988, die als ANSI-Standard anerkannt wurde. Nach
einigen Änderungen wurde sie durch die International Organisation for
Standardisation (ISO) 1993 zum ISO-Standard erklärt. Heutzutage ist die
Electronic Publishing Special Interest Group (EPSIG) in Kooperation
mit der AAP für die Aufrechterhaltung der DTD verantwortlich.
Die ISO-DTD gilt als stabil und beständig, weil sie keine kurzfristigen Updates
zulässt. Nur alle fünf Jahre ist eine Veränderung der DTD laut Satzung möglich – lediglich Fehlerkorrekturen erfolgen zwischenzeitlich.
2.2 Aufbau und Struktur35
Je nachdem welche der drei DTDs ausgewählt wird, ist das Wurzelelement unterschiedlich. Für die Buch-DTD wäre es book, für die Artikel-DTD article und für
Reihen ist es serial. Ein Buch und ein Artikel unterteilen sich jeweils in die Elemente front, body, appmat und back. Die Teile front und body müssen vorhanden sein,
appmat und back sind optional. Nähere Erläuterungen folgen nach der Abbildung.
book
front
body
appmat?
part+
no? title?
section
subelements*
back?
chapter+
chapter+
no? title?
section
subelements*
subsection1*
Abb. 3: Top-level Struktur der ISO-DTD. 36 (Eigene Darstellung)
Front
Front ist ähnlich dem Impressum eines Buches. Es beinhaltet mindestens den
Autor und Titel eines Buches und kann weitere Metainformationen zu Copyright
usw. enthalten. Darüber hinaus kann es eine Einleitung, Vorwort und ein Inhaltsverzeichnis besitzen.
35 Vgl. ISO 12083:1995 Dokumentation, S. 46ff.
36 Vgl. Payer, Margarete; Payer, Alois: Inhaltliche Strukturierung von Ressourcen. Zum Beispiel:
12083 XML. http://www.payer.de/xml/xml16.htm, Zugriff am 05.08.09.
ISO 1208329
Body
Er bildet den Hauptteil des Buches. Body unterteilt sich in Teile (part) und Kapitel
(chapter).
Ein Teil kann eine Nummerierung (no) und einen Titel (title) enthalten sowie die
section subelements und eventuelle weitere Kapitel. Die section subelements sind
paragraphs oder paragraph subelements. Diese sind zum Beispiel Aufzählungen
(lists), Tabellen (tables), Zitate/Exkurse (block quotations), Abbildungen (figures),
Grafiken (graphics), Formeln (formulas) oder Gedichte (poems). Innerhalb von
body ist die Abschnittstiefe durch die DTD vorgegeben. Maximal sind sechs Unterebenen (subsect1...6) möglich.
Ein Kapitel kann ähnlich wie ein Teil eine Nummerierung enthalten und das
section model. Das section model beinhaltet ein title-Element (optional) und die
oben genannten section subelements sowie ein subsection level 1-Element (optional
und wiederholbar).
Appmat
Appmat steht für appendix matter. Innerhalb dieses Elementes werden ein oder
mehrere Anhänge dargestellt.
Back
Back, kurz für back matter, kann ein Nachwort, Anmerkungen, Lebenslauf,
Glossar, Indizes oder Bibliographien enthalten.
Zugänglichkeit
Da es sich hier um eine ISO-Norm handelt, ist diese kostenpflichtig. Bestellt wird
die ISO 12083 über den Beuth Verlag in Berlin. Sie kostet 312,60 € und beinhaltet
eine Dokumentation und zwei Disketten. Ohne Disketten kostet die Dokumentation 199,90 €.
Die Norm ist nur in der Originalfassung in Englisch und als Übersetzung in
Französisch erhältlich. Es existiert keine deutsche Version. Aus diesem Grund ist
es nicht möglich die ISO 12083 in der Deutschen Nationalbibliothek einzusehen.
Die ISO wurde barrierefrei konstruiert. Sie folgt den Richtlinien des International Committee for Accessible Document Design (ICADD). Diese
ermöglichen die Aufbereitung der Texte für eine fast automatische Konvertierung
in Grade 2 Braille. Darüber hinaus ermöglichen sie die Veröffentlichung als Großdruckausgabe und computer voice-Ausgabe. Des Weiteren wurden so genannte
SDA (SGML Document Access)-Attribute eingeführt, die beschreiben wie jedes
Element auf das ICADD-Tag Set übertragen werden kann. Zu jedem Element
mit Attribut wurden die SDA-Attribute ergänzt. Alle restlichen Elemente ohne
Attribute erhalten zumindest die SDA-Attribute. Letztendlich hat jedes Element
also mindestens ein Attribut. Insgesamt gibt es fünf verschiedene SDA-Attribute
(SDA-Form, -Rule,-Pref,-Suff und -Susp). Um die Braille-Ausgabe zu unterstützen,
wurden weiterhin einige spezielle Element Tag Sets kreiert, u. a. für Tabellen. 37
37 Vgl. ISO 12083:1995 Dokumentation, S. 81ff.
ISO 1208330
Verwendungszweck
Bei der ISO 12083 handelt es sich um eine allgemeine DTD zur Darstellung von
Textstrukturen als elektronisches und/oder gedrucktes Dokument. Sie beinhaltet
die DTDs für folgende drei Publikationsarten38:
▶▶ für Bücher: ISO 12083:1993//DTD Book//EN
▶▶ für einzelne Artikel: ISO 12083:1993//DTD Article//EN
▶▶ für Reihen (z. B. Journale, Zeitschriften; Sammlung von Artikeln):
ISO 12083:1993//DTD Serial//EN.
Die DTD für Reihen schließt die Artikel-DTD ein. Alle drei DTDs enthalten die
Math DTD (ISO 12083:1993//DTD Mathematics//EN). In den folgenden Abschnitten wird hauptsächlich die ISO für Bücher betrachtet.
Im Gegensatz zu anderen DTDs ist die ISO nicht auf eine bestimmte Branche
oder Thematik festgelegt. Die ISO 12083 stellt das Minimum an Elementen für die
Auszeichnung von Texten unterschiedlicher Art dar. Sie ist die kleinste mögliche
Schnittmenge aller DTDs und dient als Basis für eigene individuelle DTD-Entwicklungen. Der Standard eignet sich gleichermaßen für Autoren, Bibliothekare,
Verlage etc.39 Demnach ist die DTD ausreichend flexibel für kleine Modifikationen.
Die DTD liegt als XML- und SGML-Version vor.
Beispielanwendung
Ein Beispiel für eine umfassende Modifizierung innerhalb des Standardrahmens
kommt von der University of California Press. Sie hat die ISO 12083 soweit modifiziert, dass sie für die Erstellung und Archivierung von Texten geeignet ist. Dazu
war es notwendig die verschachtelte Elementstruktur der ISO Norm soweit zu vereinfachen, dass sie auch von einer DTP-Software wie QuarkXPress interpretiert
werden kann. Es entstanden zwei Tag Sets: die ISO 12083 für die Archivierung und
ein eigenes Tag Set für die Strukturierung von Texten. Das eigene Tag Set besitzt
überhaupt keine verschachtelten Elemente und kann deshalb von QuarkXPress
linear ausgelesen und formatiert werden. Die linearen Composition Tags sind mit
den verschachtelten ISO-Tags verknüpft und automatisch von einem in das andere
konvertierbar. Der somit entstandene Workflow ist in der Lage die Editing Tags,
Composition Tags und Archiving Tags je nach Prozessschritt automatisch zu ersetzen. Mit Hilfe dieses Prozesses wurden einige Bücher elektronisch ausgezeichnet.40
Lizenzbedingungen
Das Copyright an der Norm liegt ausschließlich bei der ISO. Vervielfältigung,
Distribution und Ähnliches sind nicht ohne schriftliche Genehmigung durch die
Organisation möglich. Im Falle von Anpassungen der DTD sollte zu Beginn der
Copyright-Hinweis stehen.41
Modifizierungen der ISO sind nach den definierten Regeln für Konformität42
erlaubt. Diese lauten:
▶▶ Verwendung der korrekten ISO-Syntax, wie in der Dokumentation ersichtlich
38 Vgl. Megginson, David: Structuring XML-Documents, S. 47.
39 Vgl. ISO 12083:1995 Dokumentation, S. 1.
40 Vgl. http://quod.lib.umich.edu/cgi/t/text/text-idx?c=jep;view=text;rgn=main;id
no=3336451.0003.407, Zugriff am 02.09.09
42 Vgl. ISO 12083:1995 Dokumentation, S. 2f.
ISO 1208331
▶▶ Deklaration von benutzerdefinierten Elementen ausschließlich in externen
Parameter-Entities
▶▶ Die Benutzung des ISO-Standards als Grundlage für eigene Anwendungen muss
mit dem entsprechenden Public Identifier gekennzeichnet werden.
▶▶ Parameter-Entities sollten überschreiben werden, sobald eine andere Reihenfolge und Häufigkeit oder benutzerdefinierte Elemente und Attribute angegeben
werden.
▶▶ Die nutzerdefinierten Elemente dürfen keine Parallelbezeichnung von bereits
existierenden Elementen sein.
▶▶ Bei der Erstellung neuer Elemente und Attribute müssen die Namenskonventionen zu Beginn der DTD eingehalten werden (siehe Abschnitt “Namenskonventionen”, Seite 33).
▶▶ Die Anwendungen müssen mit der ISO 8879 (Information processing) konform
sein.
Aktualisierungen
Mit Einführung der Norm 1993 wurde festgeschrieben, dass die DTD aus Gründen der Konsistenz frühestens alle fünf Jahre geändert werden darf. Dadurch ist
sie zwar stabil, aber auch unflexibel.
Die ISO 12083 wird derzeit nicht weiterentwickelt.43 Die letzte Änderung erfolgte
1995 durch NISO. Die käuflich zu erwerbende Datei ist die ISO 12083:1994.44
Dokumentierung
Obwohl die Dokumentation eigentlich nur durch Kaufen erhältlich ist, kursiert
im Internet ein öffentliches Dokument (Public Document Type Definition Subset)45,
welches die Buch-DTD abbildet und erläutert. Außerdem findet man eine kostenlose PDF-Dokumentation46 von NISO Press aus dem Jahr 1995 im Internet.
Diese enthält die komplette ISO, dass heißt alle vier DTDs. In der Dokumentation
finden sich nützliche Baumdiagramme zur Darstellung der DTD-Struktur und
Erklärungen zu jedem Element inklusive einer Kurzbeschreibung, Verwendung
und den dazugehörigen Attributen. Allerdings ist das PDF verglichen mit anderen
PDFs nicht besonders interaktiv gestaltet. Es gibt keine internen Verlinkungen mit
Referenzen zu Elementen o. Ä.
Die Analyse im Rahmen dieser Arbeit stützt sich weitestgehend auf die eben
erwähnten Dokumentationen, da die Suche nach geeignetem Material über die
ISO durch veraltete Links und Webseiten zusätzlich erschwert ist. Beispielsweise
sind die meisten Links von coverpages.org zum Thema ISO 12083 nicht mehr gültig
und lassen sich nicht mehr zurückverfolgen.
Die ISO 12083 findet nur am Rande in einigen Büchern Erwähnung. Zum Beispiel in Megginson: Structuring XML Documents.
44 Siehe: http://www.beuth.de, Zugriff am 06.08.09.
45 Vgl. Payer, Margarete; Payer, Alois: Inhaltliche Strukturierung von Ressourcen. Zum Beispiel:
12083 XML. http://www.payer.de/xml/xml16.htm, Zugriff am 05.08.09.
46 Zu finden unter: http://www.techstreet.com/cgi-bin/detail?product_id=52643, Zugriff am
05.08.09.
ISO 1208332
Komplexität
Die ISO 12083 ist verglichen mit anderen DTDs weniger komplex und umfangreich.
Durch individuelle Erweiterungen kann der Umfang der DTD zunehmen. Die
Anzahl der Elemente beträgt 162 47 und die Anzahl der Attribute beträgt rund 20.
Modularität
Die ISO 12083 ist nicht modular aufgebaut. Jede der DTDs (Buch, Artikel, Serie,
Math) ist in einer einzelnen Datei komplett abgebildet. Die Artikel- und BuchDTD sind fast identisch, nur dass an einigen Stellen Elemente oder Attribute
hinzugefügt oder weggelassen wurden.48
Beim Betrachten der Artikel- und Buch-DTD lassen sich bestimmte identische
Inhalte wie die Basic Elements, Models und einige Attribute in separaten Modulen
speichern und über eine Referenz in der DTD aufrufen. Demnach bestünde ein
Potential, die DTD zu modularisieren. Sicher ist es auch möglich, eigene kleine
Module in die DTD einzubinden.
Übersichtlichkeit
Die DTD ist in einem einzigen langen Dokument (etwa 23 Seiten) abgebildet.
Zuerst werden die buchspezifischen Elemente, dann die allgemeinen Elemente,
gefolgt von den Model- und Attributdefinitionen deklariert. In der anschließenden Buchstruktur sind alle Elemente und Attribute definiert und verweisen auf
die zuvor deklarierten Parameter-Entities.
Folgende Skizze veranschaulicht die proportionalen Anteile der Deklarationen
innerhalb der Buch-DTD.
Special Character Entity Sets
Entity Naming Conventions
Specialized Elements
Basic Document Elements
Models
Attribut Definitions
Accessible Document Parameter Entities
Data Content Notations
The Document Structure (front matter, body, appendix
und back matter elements)
Attribut Definition Lists
SDA Attributes
Abb. 4: ISO 12083, Buch-DTD (Eigene Darstellung)
47 ISO 12083:1995 Dokumentation, S. 99–172.
ISO 1208333
Namenskonventionen
Zur Namensgebung der Entities befindet sich zu Beginn der DTD eine kleine
Legende. Die ISO 12083 benutzt Präfixe zur Kennzeichnung wo die Entities auftauchen und Suffixe zur Kennzeichnung des erlaubten Inhaltes. Im Einzelnen
sind diese:
Präfixe49
p.*
in Absätzen (paragraphs) oder innerhalb von Sätzen (phrases) falls das
Suffix .ph ist, z. B. % p.tbl oder % p.em.ph
s.*
in Abschnitten (sections), z. B. % s.zz
i.*
überall im Dokument, z. B. % i.float (floating elements)  Abbildungen,
Fußnoten, Anmerkungen
m.*
Inhaltsmodel oder deklarierter Inhalt, z. B. % m.indx
a.*
Attributdefinition, z. B. % a.types
NONE
die spezielle Benutzung ist in Inhaltsmodellen definiert
Suffixe50
*.ph
Elemente, deren Inhalt % m.ph; ist, z. B. % ade.ph (address elements)
*.d
Elemente, deren Inhalt das gleiche Modell hat wie vorgegeben, z. B.
% bmsec.d (back matter sections)
*.zz
für Unterelemente, z. B. % p.zz (paragraph subelements)
NONE
individuell definierte Elemente
Durch die Prä- und Suffixe lassen sich die Bedeutungen der Parameter-Entities
relativ schnell erfassen. Allerdings bestehen folglich einige Parameter-Entities nur
noch aus Kürzeln, wie z. B. % p.zz.ph, was gewöhnungsbedürftig ist. Außerdem
sind Verwechslungen von Parameter-Entities nicht ausgeschlossen. Es gibt zum
Beispiel % au.rid und % a.rid oder % p.zz und % s.zz.
Werden neue Parameter-Entities definiert, erklären kurze Kommentare den
Element- oder Attributnamen, aber es werden keine genaueren Informationen
über die Funktion des Elementes oder Attributes direkt in der DTD-Datei gegeben.
Erst im Anhang der Dokumentation finden sich die genaueren Erläuterungen zu
den Inhaltsmodellen.
Modifikation
“ISO 12083 in its present form is a Procrustean bed 51 that few books fit into without
distortion or mutilation.” 52
Die ISO macht gewisse Vorgaben zur Modifizierung der DTD, um innerhalb des
Standards zu bleiben. Alles was darüber hinausgeht hat demzufolge nichts mehr
mit der ISO zu tun, obwohl es natürlich erlaubt ist. Dabei gerät man schnell an
die Grenzen eines Standards, denn der Standard als Rahmen bietet keine große
49 Vgl. auch die Legende in der DTD.
50Ebenda.
51 siehe: http://de.wikipedia.org/wiki/Prokrustes
52 Vgl. Hicks, Tony: Should We Be Using ISO 12083? http://quod.lib.umich.edu/cgi/t/text/text-idx?
c=jep;view=text;rgn=main;idno=3336451.0003.407, Zugriff am 05.08.09.
ISO 1208334
Flexibilität. Dadurch hat die ISO 12083 den Nachteil, dass sie weitestgehend so
verwendet werden muss, wie ursprünglich definiert.
Modifizierungen wie das Hinzufügen und Löschen von Elementen oder das
Ändern von Entity-Referenzen sind möglich, sofern sie den genannten Kriterien
für Konformität entsprechen (siehe Abschnitt Lizenzbedingungen).
Subsets der DTD
Wie das Zitat von Tony Hicks bereits besagt, passen nur wenige Bücher in die DTD
ohne Verfälschung der ISO-Norm. Anpassungen im Rahmen der Norm wurden
von einigen Verlagen oder Instituten vorgenommen. DTDs, die von der ISO 12083
abgeleitet sind, heißen beispielsweise AIP (American Institute of Physics), BioOne,
Blackwell (Blackwell Science), Elsevier (Elsevier Science), IEEE (Institute of Electrical and Electronic Engineering), UCP (University of Chicago Press) oder Wiley
(John Wiley & Sons).53
Element- und Attributnamen sind sehr kurz gehalten und nicht immer ohne Referenz zu verstehen.
Die Namensgebung erscheint etwas inkonsistent. Manche Wörter wie z. B. foreword
oder subtitle sind ausgeschrieben, andere sind als cpyrtnme (copyright name) merkwürdig abgekürzt. Auch wird fname (firstname) abgekürzt, aber surname ausgeschrieben, obwohl sie sich von der Länge nicht wesentlich unterscheiden.
Die teilweise zu kurzen Namen (q, msn, bq, san) erschweren das Erfassen des
Inhaltes der DTD. Besonders verschlüsselt sind die vier Attributdefinitionen für
Alphabet, Datum, Hervorhebungen und Listen. Diese enthalten nur Ziffern, deren
Bedeutung in einem Kommentar erläutert ist. Zum Beispiel:

<!ENTITY % e.types “(1 | 2 | 3 | 4 | 5 | 6) #IMPLIED”>
Demzufolge sehen alle Attributdeklarationen für Alphabet, Datum, Hervorhebung und Listen gleich aus. Unterschiedlich sind nur die Elemente, an die sie
geknüpft sind.
Typografische Auszeichnung
Hervorhebungen sind mittels emph (emphasis)-Element möglich, welches das Attribut type besitzt. Die Angabe von type erfolgt mittels Ziffern (1–6). Die Ziffern
stehen für die folgenden sechs Auszeichnungen: bold, italic, bold italic, underline,
non proportional und smallcaps, mit der Möglichkeit weitere Hervorhebungsarten
zu ergänzen.
Tabellenformate
Die ISO-DTD verwendet nicht das komplexe CALS-Tabellenmodell, sondern hat
ein eigenes Tabellenformat, das AAP-Tabellenmodell. Das table-Element enthält
53 http://xml.coverpages.org/ni2002-01-04-a.html, Zugriff am 02.09.09
ISO 1208335
die Elemente no, title und tbody. Das Element tbody unterteilt sich in head, tsubhead und row. Ein row-Element wiederum definiert die Elemente tstub (stub line)
und cell.54
Für komplexere Tabellen steht ein separates base tag set des AAP-Standards
Markup of Tabular Material zur Verfügung.55
Listen
Es gibt verschiedene Listenelemente (Nummern, Bullets) mit wahlweiser Überschrift. Mittels des Attributes type können die sechs verschiedenen Listentypen
ausgewählt werden. Es gibt arabic, upper, alpha, roman, bullet, dash und unlabelled.
Weitere Formate können ergänzt werden.
Besonderheiten
Die ISO 12083 hat keine weiteren Besonderheiten.
Die beispielhafte Auszeichnung zeigt, welche Elemente front und body enthalten
und wie diese verwendet werden. Das Beispiel dient dem Vergleich mit den anderen DTDs.
<?xml version=“1.0“ encoding=“UTF-8“ standalone=“yes“ ?>
<book>
<front>
<titlegrp>
<title>The Adventures of Sherlock Holmes</title>
</titlegrp>
<authgrp>
<author>
<fname>Arthur Conan</fname>
<surname>Doyle</surname>
<role>Sir</role>
</author>
</authgrp>
<pubfront>
<cpyrt>
<date>1892</date>
<cpyrtname>
<orgname>Penguin Group</orgname>
</cpyrtname >
<cpyrtclr>All rights reserved</cpyrtclr>
</cpyrt>
<date>1994</date>
<pubname>Penguin Group</pubname>
ISO 1208336
<location>
<street>80 Strand</street>
<city>London</city>
<country>England</country>
<postcode>WC2R ORL</postcode>
</location>
<isbn>978-0-140-62100-6</isbn>
<edition>1. Auflage</edition>
</pubfront>
</front>
<body>
<chapter>
<no>l</no>
<title>A Scandal in Bohemia</title>
<section>
<title>1. Abschnitt</title>
<p>To<emph type=”1”>Sherlock Holmes</emph> she is always <emph
type=”2”>the</emph> woman. I have seldom heard him mention her under any other name. In his eyes she eclipses and predominates the whole
of her sex. It was not that he felt any emotion akin to love for Irene Adler. All emotions, and that one particularly, were abhorrent to his cold,
precise but admirably balanced mind. He was, I take it, the most perfect
reasoning and observing machine that the world has seen, but as a lover
he would have placed himself in a false position.</p>
</section>
<section>
<subsect1>
<title>2.1 Abschnitt</title>
<p>His manner was not effusive. It seldom was; but he was glad, I
think, to see me. With hardly a word spoken, but with a kindly eye,
he waved me to an armchair, threw across his case of cigars, and
indicated a spirit case and a gasogene in the corner. Then he stood
before the fire and looked me over in his singular introspective
fashion.</p>
<subsect2>
<title>2.1.1 Abschnitt</title>
<p>”Wedlock suits you,” he remarked. “I think, Watson, that
you have put on seven and a half pounds since I saw you.”
</p>
<p>”Seven!” I answered.</p>
<p>”Indeed, I should have thought a little more. Just a trifle more,
I fancy, Watson. And in practice again, I observe. You did not tell
me that you intended to go into harness.”</p>
</subsect2>
</subsect1>
</section>
</chapter>
</body>
</book>
DocBook37
3. DocBook
3.1. Allgemeines
Die DTD wurde 1991 von HaL Computer Systems und O’Reilly entwickelt. Damals
war die Davenport Group für die Entwicklung und Erhaltung des Standards zuständig. Seit 1998 ist DocBook als ein technisches Komitee ein Teil von OASIS.56
DocBook ist ein kostenloser, offener Standard.
OASIS setzt sich aus vielen namenhaften Mitgliedern wie zum Beispiel IBM,
Microsoft, Oracle, Sun Microsystems etc. zusammen. Mitglied kann jeder werden, sei es ein Unternehmen, ein Institut oder eine Einzelperson. Dabei gehen die
Mitglieder keinerlei Verpflichtungen ein. Es bleibt jedem selbst überlassen, ob und
inwieweit er an der Weiterentwicklung von DocBook mitwirkt.
OASIS unterscheidet hierbei zwischen verschiedenen Mitgliedschaften. Es gibt
so genannte „bedeutende Sponsoren“ – überwiegend große bis mittlere Unternehmen oder akademische Einrichtungen –, normale Sponsoren und Mitwirkende.
Von der Art der Mitgliedschaft hängen die Mitgliedsbeiträge ab. Es wird weiterhin
nach Art und Größe des Unternehmens unterschieden.57
Für Einzelpersonen, deren Beiträge einer Subvention durch OASIS würdig sind,
gibt es eine „individuelle Mitgliedschaft“. Sie kostet circa 210 Euro pro Jahr.
Der logische Aufbau eines DocBook XML-Dokumentes gliedert sich wie folgt:
Jedes Dokument besitzt genau ein Wurzelelement. Dieses kann variieren und
beispielsweise set, book, chapter oder article heißen. Dabei ist ein set das höchste
Wurzelement und bezeichnet eine Sammlung von Büchern. Ein book besteht aus
mehreren Kapiteln (chapters), ein Kapitel aus mehreren Abschnitten (sections) usw.
Die Elemente werden weiterhin in meta-information elements (z. B. bookinfo), block
elements und inline elements unterteilt. Einige wichtige Elemente werden weiter
unten näher erläutert.
DocBook unterteilt nicht in front, body und back, weshalb die toplevel-Struktur
sehr breit gefächert ist. Einen reduzierten Überblick über die ersten beiden Ebenen
des Elementes book gibt folgende Grafik.
56 Vgl. Walsh, Norman. DocBook: The Definite Guide, S. 14 f.
57 Vgl. OASIS: Categories and Dues. http://www.oasis-open.org/join/categories.php#dues, Zugriff am 18.09.09.
DocBook38
title
?
subtitle?
titleabbrev?
bookinfo?
dedication
toc
lot
glossary
book
*
beginpage?
docinfo?
appendix
bibliography
title
preface
subtitle?
chapter
titleabbrev?
reference
chapter
partintro?
part
colophon
index
bibliography
appendix
setindex
lot
glossary
article
index
toc
+
article
preface
refentry
reference
Abb. 5: Top-level-Struktur eines DocBook-XML-Dokumentes. (Eigene Darstellung)
Metainformationen
Die Angabe von Metainformationen spielt eine große Rolle bei der Archivierung,
bei bibliografischen Verweisen und dem Wiederfinden von Daten. Zu den Metainformationen zählen Informationen über die beteiligten Personen (Autoren,
Editoren, Herausgeber), zur Publikation selbst (Verlag, ISBN/ISSN, Copyright etc.)
sowie zum Inhalt (Titel, Zusammenfassung, Schlüsselwörter usw.).58
Set
Ein set, also eine Reihe, besteht aus zwei oder mehreren Büchern. Set ist das höchste
Wurzelelement in DocBook. In einer Datei mit dem Wurzelelement set können
beispielsweise alle Bücher stehen, die zu einer Reihe gehören. Die einzelnen Bücher
werden in separaten Dateien gespeichert.
Book
Ein Buch enthält mindestens einen Titel. Darüber hinaus kann es eine Widmung,
ein Inhalts- und Abbildungsverzeichnis, ein Vorwort, ein Kapitel, einen Teil, einen
58 Vgl. Trieloff, Lars: DocBook-XML, S. 67ff.
DocBook39
Artikel, einen Anhang, ein Glossar, einen Index, eine Bibliografie und ein Kolophon enthalten.
Das Element Artikel kann Bestandteil eines Buches sein oder als separates
Dokument mit dem Wurzelelement article vorkommen.
Section
Innerhalb eines Abschnittes (section) sind zwei verschiedene Arten der Unterteilung möglich. Zum einen können die Elemente sect1 bis sect5 entsprechend
der Nummern verschachtelt werden oder beliebig viele section-Elemente werden
verschachtelt. Die erste Variante ist übersichtlicher und restriktiver, aber eine
Restrukturierung des Textes ist aufwendiger als mit der zweiten Variante. Das
Element section wiederum begrenzt die Zahl der Unterabschnitte nicht und kann
somit leicht unübersichtlich werden.59
Außerdem gibt es in DocBook simplesect, bridgehead und refsect1–3. Simplesect
ist ein Abschnitt, der an einer beliebigen Stelle im Dokument auftauchen kann
und keine weiteren Abschnittselemente enthalten darf. Bridgehead ist eine Abschnittsüberschrift ohne beinhaltende Abschnitte. Das Element refsect1–3 darf
nur innerhalb von refentry verwendet werden. Ansonsten wird es analog zum
section-Element verwendet.60
3.3 Analyse der DTD anhand folgender Kriterien
Zugänglichkeit
Die DocBook DTD ist direkt auf der OASIS-Webseite61 erhältlich und kann kostenlos herunter geladen werden.
Auf sourceforge.net steht alles rund um DocBook: ein DocBook Wiki für das
Online-Editieren von DocBook Dokumenten, DocBook XSL-Stylesheets für die
Transformation sowie verschiedene andere Werkzeuge und Konverter.
Verwendungszweck
DocBook eignet sich besonders für die Erstellung von Software- und HardwareDokumentationen, ist aber nicht darauf beschränkt. Das Schema ist vielfältig
verwendbar und bei dem Publizieren von Büchern weit verbreitet. Die DTD lässt
sich beispielsweise für andere Bücher oder Zeitschriften einsetzen, da die softwarespezifischen Elemente optional sind. Solange die DTD den Anforderungen
eines auszuzeichnenden Buches gerecht wird, gibt es keinerlei Einschränkungen,
warum DocBook nicht auch für einen Roman benutzt werden kann.62
Anwender von DocBook
Auf der OASIS-Website sind alle Sponsoren und mitwirkende Unternehmen, Universitäten, Institute und andere aufgelistet. In Deutschland sind dies:
▶▶ die Gesellschaft für technische Telekommunikation e. V.
59
60
61
62
Vgl. Trieloff, Lars: DocBook-XML, S. 63.
Vgl. Walsh, Norman; Mueller, Leonard: DocBook: The Definitive Guide, S. 32 f.
Zu finden unter: http://www.oasis-open.org/docbook, Zugriff am 18.09.09.
Vgl. Trieloff, Lars: DocBook-XML, S. 30 f.
DocBook40
▶▶ das Forschungszentrum Jülich GmbH
▶▶ die Siemens AG
▶▶ SEEBURGER
▶▶ die TU Dortmund
▶▶ die Universität Rostock
▶▶ die Donau-Universität Krems
Aus der Mitgliedsliste lässt sich vermuten, dass die eben genannten Unternehmen
mindestens ein Projekt mit DocBook realisiert haben. Leider ist nicht erwähnt,
welche konkreten Projekte diese umgesetzt haben. Es ist anzunehmen, dass die
Gesellschaft für technische Telekommunikation die Fachzeitschrift technische kommunikation 63 mit DocBook-XML umsetzt. Die Siemens AG könnte DocBook für
die Erstellung von technischen Dokumentationen verwenden.
Lizenzbedingungen
Das Copyright von DocBook ist unter verschiedenen Unternehmen aufgeteilt:
HaL Computer Systems, Inc., O‘Reilly & Associates, Inc., ArborText, Inc., Fujitsu
Software Corporation, Norman Walsh, Sun Microsystems, Inc. und OASIS gehören hierzu.
DocBook und dessen Dokumentation können ohne Einschränkungen benutzt,
kopiert, modifiziert und verbreitet werden, vorausgesetzt die Informationen für
das Copyright sind in jeder Datei angegeben.
Bei Veränderungen der DocBook DTD, die über die Deklaration und die Referenz der üblichen Entities und der Deklaration von Notationen hinausgehen,
müssen die Dateien als Varianten von DocBook gekennzeichnet sein.64
Aktualisierung
Die aktuelle DocBook DTD ist DocBook 5.0.65 Im Gegensatz zu der vorhergehenden Version 4.5 gibt es einige wesentliche Neuerungen, die in den folgenden
Absätzen kurz zusammengefasst sind. Als Erstes ist es wichtig zu erwähnen, dass
Version 5.0 nicht vollständig kompatibel mit vorherigen DocBook-Versionen ist.
Mit DocBook 5.0 tritt die neue XML-Schemasprache Relax NG in Kraft. Relax
NG wurde von OASIS entwickelt und ist inzwischen internationaler Standard
(ISO/IEC 19757-2).66 Die Sprache ermöglicht es beispielsweise, dass ein Element
verschiedene Inhaltsmodelle annimmt – in Abhängigkeit des jeweiligen Kontextes, in dem es steht. DocBook 5.0 ist weiterhin in den bekannten Schemasprachen
W3C XML-Schema, DTD und Schematron verfügbar.
Ein weiterer wesentlicher Unterschied ist, dass in Relax NG keine ParameterEntities mehr vorhanden sind.67 Nur per Referenz ist es weiterhin möglich, Entities
in Relax NG einzubinden und gültige Dokumente zu erzeugen.
63 Vgl. tekom: Fachzeitschrift für Technische Dokumentation und Informationsmanagement.
http://www.tekom.de/index_neu.jsp?url=/servlet/ControllerGUI?action=voll&id=281, Zugriff am
04.09.09.
64 Vgl. Kommentartext zu Beginn einer DocBook-Datei.
65 Vgl. DocBook: http://docbook.org/schemas/5x, Zugriff am 04.09.09.
66 Vgl. Makoto, Murata: Relax NG. http://www.relaxng.org, Zugriff am 04.09.09.
67 Vgl. Stayton, Bob: DocBook XSL: The Complete Guide, S. 40.
DocBook41
Im Vergleich zu den Vorgängerversionen sind in DocBook 5.0 alle Elemente
in einem eigenen Namensraum definiert.68 Der Namensraum und die DocBookVersion müssen im Wurzelelement deklariert werden. Optional kann für alle
DocBook-Elemente der Präfix „d“ (d:book) angegeben werden. Das hat den Vorteil
andere XML-Sprachen wie zum Beispiel MathML ohne Namenskonflikte und
somit unkomplizierter in DocBook zu integrieren.
Eine weitere Neuerung in DocBook 5.0 ist die Verlinkung. In DocBook 4.5 sind
nur spezielle Elemente zur Verlinkung verwendbar, zum Beispiel xref, link, olink
oder ulink. In DocBook 5.0 können fast alle Elemente mit einem link-Attribut
verknüpft werden. Das ist möglich, weil alle Elemente ein in XLinkG definiertes
Attributset haben. Ein Inline-Element kann beispielsweise durch Zuweisen eines
link-Attributes anklickbar sein. Für Blockelemente ist eine solche Verlinkung allerdings nicht sinnvoll und deshalb nicht möglich.69
Des Weiteren hat sich die Handhabung von Metadaten geändert. Zum einen
besitzen jetzt alle Hierarchieelemente und viele Blockelemente einen Metadatencontainer (info) und zum anderen wird nur noch ein einziges info-Element an
Stelle von bookinfo, chapterinfo, setinfo usw. verwendet. Mit Relax NG entfallen
separate Containerelemente, weil das Element info in verschiedenen Inhaltsmodellen vorkommen kann, wenn es in einem anderen Kontext steht.
DocBook wird ständig von dem Technical Committee weiterentwickelt und verbessert. Auf der Webseite sind ebenso die einzelnen Zwischenversionen verfügbar,
welche die folgende Tabelle nicht berücksichtigt.
Version
Jahr
1.0
1992
2.1
Dez. 1993
3.0
Jan. 1997
4.0
Mai 2000
5.0
Aug. 2008
Tab. 4: DocBook-Versionen
Dokumentierung
Zu DocBook erschienen einige Bücher und Online-Dokumentationen. OASIS
bietet mit dem „DocBook: The Definitive Guide“ eine offizielle Dokumentation
sowohl online70 – stets aktuell und interaktiv – als auch als Druckausgabe, die für
den Einstieg sehr gut geeignet ist.
Ein Buch, das sich konkret mit der Weiterverarbeitung von DocBook beschäftigt, ist „DocBook XSL: The Complete Guide“ von Bob Stayton. Dieses ist ebenfalls
online verfügbar.71
Mit dem Auszeichnen von Dokumenten in DocBook-XML beschäftigt sich das
Buch von Lars Trieloff, „DocBook-XML: Einführung und Anwendung“.
68
69
70
71
Vgl. Stayton, Bob: DocBook XSL: The Complete Guide, S. 33.
Vgl. Stayton, Bob: DocBook XSL: The Complete Guide, S. 36.
Zu finden unter: http://www.docbook.org/tdg5/en/html/docbook.html, Zugriff am 04.09.09.
Zu finden unter: http://www.sagehill.net/docbookxsl/index.html, Zugriff am 04.09.09.
DocBook42
Während die offizielle Dokumentation hauptsächlich eine Referenz zu den Elementen und Attributen von DocBook ist, sind die anderen beiden Bücher praxisbezogener. Sie erklären DocBook im Kontext von XML, den Aufbau eines eigenen
Workflows, die Werkzeuge (XML-Editoren, XSLT-ProzessorenG) und beschäftigen
sich ausführlich mit der Modifizierung für verschiedene Ausgabeformen.
Darüber hinaus gibt es eine DocBook Wiki-Seite72, welche über die neuesten
Entwicklungen informiert und die unter anderem Tutorien in verschiedenen
Sprachen anbietet.
Innerhalb der DTD und ihrer Module befinden sich nur wenige erklärende
Kommentare zu den Funktionen der einzelnen Entities, weshalb immer eine
Dokumentation zur Hand sein sollte.
Komplexität
Bei DocBook handelt es sich um eine komplexe DTD. Besonders umfangreich sind
die beiden Module dbhier und dbpool. DocBook hat neben der DTD-Hauptdatei
docbook fünf Grundmodule, drei verschiedene Tabellenmodule (CALS, XML
Exchange Table, HTML) und eine Katalogdatei für die Referenz der DTD und
ISO Entities.
Die Anzahl der Elemente beträgt 351, die der Attribute kann ohne Referenzliste
nicht genau bestimmt werden. Es existieren zwölf globale Attribute (common
attributes), die jedes Element annehmen kann. Diese heißen: arch, conformance,
id, lang, os, remap, role, revision, revisionflag, userlevel, vendor und xreflabel.
Das role-Attribut ist ein Parameter Entity unabhängiges Attribut und dient dazu
ein Element zu klassifizieren. Jedes Element kann das role-Attribut annehmen.73
Da DocBook ursprünglich für technische Dokumentationen konzipiert wurde,
enthält es viele Elemente, die nicht unbedingt für wissenschaftliche Bücher notwendig sind. Beispiele sind die Warnhinweise (caution, note, warning etc.) oder
computerzugehörige Befehle (screenshot, returnvalue, cmdsynopsis, guibutton
usw.). Hier kann es sein, dass der Anwender eine Vielzahl von Elementen, Klassen und Attributen löschen muss bzw. kann. Durch das Entfernen unwichtiger
Elemente wird DocBook überschaubarer.
Modularität
Die fünf Grundmodule sind: dbnotn, dbcent, dbpool, dbhier und dbgenent. In
dieser Reihenfolge bauen die Module aufeinander auf, was bei der Modifizierung
der DTD zu beachten ist.
Das Modul dbnotn deklariert die Notationen; dbcent deklariert und referenziert
die ISO Character Entities; dbpool ist der Informationspool und beinhaltet alle
Elemente, die den Inhalt beschreiben (inline elements, bibliography etc.); dbhier
beschreibt die Elemente, welche die hierarchische DocBook-Struktur (set, book,
chapter usw.) beschreiben und dbgenent enthält die General Entities.
72 Zu finden unter: http://wiki.docbook.org/topic/StartSeite, Zugriff am 04.09.09.
73 Vgl. Walsh, Norman; Mueller, Leonard: DocBook: The Definitive Guide, S. 119ff.
DocBook43
Zusätzlich gibt es in dem Modul dbhier an zwei Stellen Platzhalter für Redeklarationen. Ebenso existiert ein Platzhalter im Modul dbpool.74 Näheres zu dem
Zweck der Platzhalter ist unter dem Punkt „Modifizierung“ zu finden.
Das CALS-Tabellenmodell ist ein externes Modul und lässt sich unabhängig von
DocBook in jede andere DTD per Entity-Deklaration integrieren.75
dbnotn.mod
ISO entity sets
dbcent.mod
cals-tbl.dtd
dbpool.mod
dbpool.redecl
docbook.dtd
intermod.redecl
dbhier.redecl
dbhier.mod
dbhier2.redecl
dbgenent.mod
Abb. 6: Aufbau der DocBook-Module76
Die ISO Entity Sets werden zwar von DocBook mitgeliefert, sind aber keine DocBook-Entwicklung, weshalb sie nur im gepunkteten Rahmen gekennzeichnet sind.
Übersichtlichkeit
Die Struktur der DocBook-Module ist bereits aus der obigen Abbildung ersichtlich.
Bei der Erstellung der Module wird nach verschiedenen strukturellen Gesichtspunkten unterteilt, einerseits nach der allgemeinen Hierarchie und andererseits
nach den Inhaltselementen. Die Module dbhier und dbpool enthalten die Deklarationen für alle Arten von Dokumenten, von technischen Dokumentationen,
Handbüchern, Fachzeitschriften bis hin zu Artikeln, weshalb sie so komplex sind.
Ihre Quelltexte umfassen 40 bzw. 155 Seiten. Innerhalb des Hierarchie-Moduls
sind die Elemente nach der DocBook-Hierarchie definiert, also vom höchsten
zum niedrigsten Element. Dabei ist zuerst die Struktur von set, dann von book
und schließlich von article dargestellt.77
Innerhalb des Information Pool-Moduls sind die Elemente als so genannte Marked
Sections (bedingte Abschnitte) gruppiert und deklariert. Die Befehle „Include“
oder „Ignore“ fügen diese Parameter-Entities gezielt hinzu oder entfernen sie.
Die Elemente sind alphabetisch deklariert und für jedes Element sind das Modul, das Element und die dazugehörigen Attribute definiert.
Durch die Trennung in Hierarchie- und Information Pool-Modul ist es möglich,
die Hierarchie zu ändern und trotzdem die vorhandenen Elemente zu verwenden.
Umgekehrt sind Elemente zu der vorhandenen Hierarchie leicht hinzuzufügen,
ohne Ändern der eigentlichen Hierarchie.
Folgende Darstellung zeigt den Inhalt der DocBook-DTD.
74
75
76
77
Vgl. Walsh, Norman: DocBook – The Definitive Guide, S. 94 f.
Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 319.
Vgl. Walsh, Norman; Mueller, Leonard: DocBook: The Definitive Guide, S. 93.
Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 298ff; S. 327.
DocBook44
Enable SGML features
Notation declarations
ISO character entity sets
DTD modules (Information pool, Redeclaration placeholders,
Document hierarchy)
Other general entities
Abb. 7: DocBook: DocBook-DTD (Eigene Darstellung).
Namenskonvention
Die Namen in der DocBook-DTD sind oft sinngemäß abgekürzt und leicht zu
lesen. Bei Kombinationen mehrerer Elementnamen, zum Beispiel in ParameterEntities, steht ein Punkt dazwischen. Die Namen sind in den DTD-Dateien immer
in Kleinbuchstaben geschrieben. In DocBook gibt es wie auch in anderen DTDs
einige markante Suffixe der Parameter-Entities78.
%*.attlist; Parameter-Entities für Attributdeklarationen
%*.attrib; definiert Attribute; enthält Attributlisten
%*.attval; definiert Attributwerte, z. B. „yes“ oder „no“
%*.class; Elementklassen, in denen ähnliche Elemente gruppiert sind, z. B.
alle Listen in %list.class
%*.content.module; Mittels „Include“ oder „Ignore“ lassen sich diese Gruppen von Elementdefinitionen an- und ausschalten.
%*.element; Parameter-Entities für Elementdeklarationen (Include, Ignore)
%*.module; Parameter-Entities, welche die Elemente und deren Attributlisten
kontrollieren. Sie sind als marked sections angelegt.
%*.content; definiert die Inhaltsmodelle von Elementen
%*.mix; Kombinationen von Klassen, die in Inhaltsmodellen vorkommen.
Elemente der gleichen Klasse treten oft in der gleichen Kombination auf.
Der Präfix %local.*; kennzeichnet Parameter-Entities für einfache lokale Elementerweiterungen. Es gibt %local.*.attrib;, %local.*.class; und %local.*.mix;. Sie sind
Platzhalter und somit in den von OASIS gelieferten DocBook-Dateien leer.
Modifikation79
Die DocBook-DTD ist ein Vorschlag für eine Struktur, die auf viele Anwendungen
passt. Für ein bestimmtes Projekt kann es jedoch erforderlich sein, dass die DTD
modifiziert werden muss – zum Beispiel durch das Hinzufügen oder Entfernen
von Elementen und Attributen, Strukturänderungen oder Erweiterungen der Inhaltsmodelle. Bei einer Modifizierung wie beispielsweise einer Erweiterung der
DTD muss beachtet werden, den Public Identifier in der DOCTYPE-Deklaration
zu ändern. Die neue DTD sollte einen eigenen Identifier erhalten, der durch „Subset“, „Extension“ oder „Variant“ kennzeichnet, dass es sich um eine Abwandlung
DocBook45
der DocBook-DTD handelt. Lediglich zu der Datei dbgenent.mod können Entities
und Notationen ohne Änderung des Public Identifiers hinzugefügt werden.
Ein Nachteil einer Erweiterung ist, dass die daraus entstandene DTD eventuell
nicht mehr mit den üblichen Validierungswerkzeugen oder Transformationsprogrammen verarbeitbar ist.80 Bei der Anpassung der DTD ist es relativ schwer
abzuschätzen, welche Konsequenzen die Änderungen haben. Es lohnt sich, vorher
danach zu suchen, wo ein bestimmtes Element überall auftaucht. Außerdem muss
die Verschachtelung der Parameter-Entities verfolgt werden. Grundsätzlich ist eine
Verkleinerung der DTD kein Problem, insofern als dass sie stabil, austauschbar
und gültig bleibt.
Die DocBook-Dokumentation empfiehlt, für die Modifizierung immer eine eigene
Datei zu erstellen, die entweder alles oder nur Teile der kompletten DTD benutzt.
Bei der Bearbeitung bleiben alle Module unverändert, der Benutzer gestaltet sich
seine eigene Ebene zur Anpassung der DTD. Eine solche Ebene heißt in DocBook
Customization Layer. Die bereits erwähnten Platzhalter (dbpool.redecl, dbhier.
redecl und dbhier2.decl) in den beiden Modulen dbpool und dbhier helfen dabei,
neue Deklarationen in die DTD einzufügen, ohne Einfluss auf vorhergehende
Entities. Die Redeklaration muss vor der zu verändernden Entity vorgenommen
werden. DocBook macht mit diesen Platzhaltern einen Vorschlag dafür, wo man
bestimmte Dinge ändern kann. Dies ist sehr hilfreich, da die einzelnen Module
komplex und lang sind. In der Regel befinden sich die Platzhalter beinahe am Anfang der Module. Bestimmte Dinge, wie das Entfernen kompletter Elementklassen,
sind nur durch die Platzhalter möglich. Denn hier muss nicht nur die Klasse als
Empty definiert werden, sondern auch deren Parameter-Entities. Am Einfachsten
ist es, die betreffenden Entities in einem separaten Dokument anzulegen und dort
jeweils das entsprechende Element zu entfernen.
Bei allen Änderungen in der DTD ist die Reihenfolge zu beachten, das heißt die
Elementklassen müssen vor ihrer Verwendung in dem Elementmix deklariert werden. Das Beispiel81 veranschaulicht das Entfernen eines Elementes aus einem Mix:
▶▶ Entity im Modul dbpool vor dem Entfernen der „Admonitions“:
<!ENTITY % tabentry.mix
“%list.class; | %admon.class;
| %linespecific.class;
| %para.class; | graphic | mediaobject
%forms.hook;
%local.tabentry.mix;“>

<!ENTITY % DocBookDTD PUBLIC “-//OASIS//DTD DocBook V3.1//EN”>
&DocBookDTD;
Wird das oben graumarkierte Element entfernt und danach die DocBook DTD
aufgerufen, erscheint eine Fehlermeldung des Parsers, weil an dieser Stelle Entities referenziert werden, die noch nicht deklariert sind. Wird die DocBook DTD
hingegen davor aufgerufen, ist die Änderung nicht wirksam, weil die Deklaration
80 Vgl. Trieloff, Lars: DocBook-XML, S. 239ff.
81 Vgl. Walsh, Norman; Mueller, Leonard: DocBook: The Definitive Guide, S. 104 ff.
DocBook46
in der DTD zuerst vom Parser gelesen wird. Die Lösung mit den Platzhaltern
wäre wie folgt:
▶▶ In der Modifizierungsdatei bzw. im Customization Layer steht:
<!ENTITY % dbpool.redecl.module “INCLUDE”>
<!ENTITY % rdbpool SYSTEM “rdbpool.mod”> [an dieser Stelle wird die Datei
rdbpool.mod aufgerufen]

<!ENTITY % DocBookDTD PUBLIC “-//OASIS//DTD DocBook V3.1//EN”>
&DocBookDTD;
▶▶ Die Datei rdbpool.mod mit der neu definierten Entity tabentry.mix
<!ENTITY % tabentry.mix
“%list.class; | | %linespecific.class;
| %para.class; | graphic | mediaobject
%forms.hook;
%local.tabentry.mix;“>
Die Datei rdbpool.mod wird also vor der DocBook DTD über das dbpool.redecl.
module aufgerufen und überschreibt damit die Parameter Entity tabentrymix.
Für die Deklaration von eigenen Entities, Elementen und Notationen wird das
Modul dbgenent bereitgestellt. Dieses Modul zeigt, wie Benutzer selbst relativ
einfach ein neues Modul schreiben und in die DTD einbinden können.
Möglicherweise eignen sich die beiden folgenden offiziellen Modifikationen von
DocBook für ein Projekt. Das sollte vor Beginn eigener Anpassungen geprüft werden. Eine weit verbreitete Möglichkeit heißt Simplified DocBook (Version 4.1.2). Es
handelt sich dabei um ein ziemlich kleines Subset der DTD mit 119 Elementen82
und dem Wurzelelement article. Damit lassen sich folglich keine Bücher oder gar
Sammlungen beschreiben. Simplified DocBook-Dokumente sind mittels einer bereitgestellten CSS-Datei direkt im Webbrowser lesbar.83
Ein anderes Subset von DocBook ist DocBook Lite. Hiermit lassen sich längere
Dokumente beschreiben, die weniger umfangreich als die gesamte DocBook DTD
sind und oftmals für Projekte ausreichen. 84
Alle Elemente und Attribute sind in DocBook-XML kleingeschrieben. Zwischen
zusammengesetzten Wörtern (bibliomixed, glossentry, imageobject etc.) steht kein
Leerzeichen. Die Element- und Attributnamen sind nicht zu stark abgekürzt,
so dass sie für den Anwender leicht verständlich sind. Ihre Bedeutung lässt sich
meistens intuitiv erfassen.
82 http://www.docbook.org/schemas/sdocbook, Zugriff am 04.09.09.
83 Vgl.Trieloff, Lars: DocBook-XML, S. 240f.
84 Vgl.Trieloff, Lars: DocBook-XML, S. 241.
DocBook47
Die Elemente für unterschiedliche Listen- oder Absatzarten sind analog benannt. Die möglichen Absatzelemente sind beispielsweise para, simpara (einfacher
Absatz) oder formalpara (Absatz mit einem Titel).
Insgesamt sind die Tagnamen ausreichend eindeutig und unterschiedlich.
Für die Hervorhebung von Wörtern steht das Element emphasis zur Verfügung.
Standardmäßig erscheint der Text dadurch kursiv. Mittels des role-Attributs lässt
sich fetter Text generieren. Mehr ist in DocBook standardmäßig nicht möglich.
Prinzipiell werden Auszeichnungen in DocBook nach der Funktion vorgenommen und weniger nach der typografischen Erscheinung. Zum Beispiel gibt es Unterscheidungen für fremdsprachige Auszeichnungen (foreignphrase), wortwörtliche
Hervorhebungen (markup) oder computergenerierte Daten (computeroutput).
Tabellenmodelle
In DocBook wird für Tabellen das CALS-Tabellenmodell verwendet. Mit diesem
Modell lassen sich nahezu alle denkbaren Tabellen darstellen.85 Nähere Informationen und ein Vergleich mit dem XHTML-Modell erfolgen im Kapitel III,
Abschnitt 2.2, Seite 106.
Darüber hinaus stehen die beiden Tabellenmodelle HTML und XML Exchange
in DocBook zur Verfügung.
Das XML Exchange Tabellenmodell ist eine Teilmenge des CALS-Modells und
wurde für eine bessere Zusammenarbeit mit anderen OASIS-Anwendungen entwickelt.
Tabellenformate sollten innerhalb eines XML-Dokumentes nicht miteinander
vermischt werden.
Listen
Die DTD bietet sieben verschiedene Listenarten: Eine calloutlist ist eine Legende
zu grafischen Abbildungen, glosslist erstellt ein Glossar und eine itemizedlist ist
eine Aufzählung mit Bullet. Weiterhin existieren nummerierte Listen (orderedlist),
horizontale oder vertikale Aufzählungen ohne Bullet (simplelist) und Schlüsselwortlisten (variablelist). Segmentedlist ermöglicht unterteilte Listen bzw. einfache
Tabellen.
Besonderheiten
DocBook bietet die gesamte Palette an Werkzeugen für die Erstellung, Validierung
und Weiterverarbeitung von XML-Dokumenten sowie deren Transformation in
andere Formate. Einige dieser Werkzeuge werden in folgenden Abschnitten kurz
erläutert.
DocBook Wiki86 ist eine Online-Anwendung für die Darstellung und das Editieren von einem oder mehreren DocBook-Dokumenten in einem Browser. Es
unterstützt verschiedene Modi beim Editieren (z. B. Text, XML, LaTeX, HTML,
texi) und die Ausgabe in verschiedenen Sprachen. Das Dokument bleibt bei allen
Änderungen immer im Ausgangsformat DocBook-XML. Nach der Bearbeitung
85 Vgl. Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML, S. 319 f.
86 Vgl. Hoxha, Dashamir: The Features of DocBookWiki. http://doc-book.sourceforge.net/homepage, Zugriff am 05.09.09.
DocBook48
können die Dokumente in verschiedene Ausgabeformate (PDF, RTF, LaTeX) konvertiert werden.
Für die Validierung von DocBook-XML-Dokumenten gibt es zum Beispiel den
kostenlosen Sun Microsystem’s Multi-Schema Validator87. Er ist in der Lage, ein
Dokument gegen mehrere Schemata (z. B. mit verschiedenen Namensräumen) zu
validieren. Er verarbeitet ebenso Relax NG.
Oxygen ist ein kommerzieller XML-Editor, der ebenfalls DocBook 5.0 Dokumente validiert.88 Der Editor verarbeitet die gängigen Schemata (Relax NG, W3C
Schema, Schematron etc.) unter Verwendung des Xerces-Parsers.
Die sourceforge-Webseite stellt die DocBook-Stylesheets für die XSL-Transformation bereit. In einer separaten Dokumentation, die beim Herunterladen der
Datei mitgeliefert wird, sind die Parameterreferenzen und Verarbeitungshinweise
für XSL-FO, HTML sowie andere angegeben.
Der DocBook XSL Configurator enthält Java Anwendungen, die DocBook XSL
Customization Layers (FO, HTML und Manpages) generieren und DocBook-XML
zu einem Output-File transformieren.
<?xml version=“1.0“ encoding=“UTF-8“ standalone=“no“ ?>
<!DOCTYPE book PUBLIC „-//OASIS//DTD DocBook XML V4.5//EN“
„http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd“>
<book lang=“de“>
<bookinfo>
<author>
<honorific>Sir</honorific>
<firstname>Arthur Conan</firstname>
</author>
<publisher>
<publishername>Penguin Group</publishername>
<address>
<othername>Penguin Books Ltd</othername>
<street>80 Strand</street>
<postcode>WC2R ORL</postcode>
<city>London</city>
<country>England</country>
</address>
</publisher>
<pubdate>1994</pubdate>
<isbn>978-0-140-62100-6</isbn>
<copyright>
87 Vgl. java.net: Sun Multi-Schema XML Validator (MSV). https://msv.dev.java.net, Zugriff am
05.09.09.
88 Vgl. Stayton, Bob: DocBook XSL: The Complete Guide, S. 44.
DocBook49
<year>1892</year>
<holder>Penguin Group</holder>
</copyright>
<legalnotice>
<para>All rights reserved</para>
</legalnotice>
</bookinfo>
<chapter>
<sect1>
<para>To<emphasis>Sherlock Holmes</emphasis> she is always
<emphasis>the</emphasis> woman. I have seldom heard him mention her
under any other name. In his eyes she eclipses and predominates the whole
of her sex. It was not that he felt any emotion akin to love for Irene Adler.
All emotions, and that one particularly, were abhorrent to his cold, precise
but admirably balanced mind. He was, I take it, the most perfect reasoning
and observing machine that the world has seen, but as a lover he would have
placed himself in a false position.</para>
</sect1>
<sect1>
<sect2>
<para>His manner was not effusive. It seldom was; but he was glad, I think,
to see me. With hardly a word spoken, but with a kindly eye, he waved me
to an armchair, threw across his case of cigars, and indicated a spirit case
and a gasogene in the corner. Then he stood before the fire and looked
me over in his singular introspective fashion.</para>
<sect3>
<para>“Wedlock suits you,“ he remarked. „I think, Watson, that you
have put on seven and a half pounds since I saw you.“</para>
<para>“Seven!“ I answered.</para>
<para>“Indeed, I should have thought a little more. Just a trifle more,
I fancy, Watson. And in practice again, I observe. You did not tell me
that you intended to go into harness.“</para>
</sect3>
</sect2>
</sect1>
</chapter>
</book>
TEI (Text Encoding Initiative)50
4. TEI (Text Encoding Initiative)
4.1. Allgemeines
Die Text Encoding Initiative (TEI) ist seit 1987 ein Konsortium für die Entwicklung und Erhaltung von Standards für die Darstellung digitaler Texte. Das
TEI-Konsortium ist ein internationaler Zusammenschluss von akademischen
Einrichtungen, Forschungsprojekten und Einzelpersonen.
Mit einer Mitgliedschaft im TEI-Konsortium bieten sich dem Anwender Vorteile
wie eine kostenlose Druckausgabe der Guidelines, 20 % Softwarerabatt für den
Oxygen XML-Editor, die kostenlose Teilnahme an Konferenzen und das Recht
zu wählen u. a. Durch die Mitglieder und den Austausch zwischen verschiedenen
TEI-Anwendern ist eine kontinuierliche Verbesserung von TEI möglich.
Mitglied kann jeder werden, ob Privatperson, Non Profit-Organisation oder
nur für ein Projekt. Die Mitgliedsgebühren richten sich nach der Art des Unternehmens und dem Land. Für deutsche Mitglieder liegen die Gebühren zwischen
ca. 350 Euro bis 3.500 Euro pro Jahr.89
Das Wurzelelement heißt TEI. Ausgehend davon unterteilt sich die TEI-DTD in
die Elemente teiHeader und text.
TeiHeader90
Der teiHeader enthält wichtige Metainformationen, wie bibliografische Angaben
(fileDesc) über den elektronischen und gedruckten Text (sofern vorhanden) und
optional Informationen über die Transkription des Dokumentes (encodingDesc),
die Herkunft (profileDesc) und die bisherige Überarbeitung des Dokumentes (revisionDesc).
Eine Besonderheit von TEI ist, dass die Datei teiHeader separat für Katalogzwecke verteilt werden kann, zum Beispiel an Bibliotheken.
Text91
Das text-Element unterteilt sich wiederum in die Titelei (front), den Anhang
(back) und dazwischen entweder ein body-Element oder ein group-Element (z. B.
für Sammlungen). Titelei und Anhang sind innerhalb von text optional.
Ein group-Element enthält mehrere text-Elemente oder weitere group-Elemente,
jeweils mit Titelei und Anhang.
Die weitere Vertiefung erfolgt durch parts, chapters, sections etc. Abschnitte
werden durch div-Elemente gekennzeichnet. Diese können rekursiv (d. h. keine
bestimmte Tiefe) mittels des Elementes div oder nicht-rekursiv (div0–7) eingesetzt
werden.
89 Vgl. TEI Consortium: Application for Membership in the TEI Consortium. http://www.tei-c.
org/Membership/teimembershipform.pdf, Zugriff am 16.09.09.
90 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. 17.
91 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. 142 f.
tei
teiHeader
fileDesc
text
profileDesc?
encodingDesc?
front matter?
body
group
back matter?
revisionDesc?
div+
div1–7+
Abb. 8: Top-level-Struktur eines TEI-XML-Dokumentes (Eigene Darstellung)
TEI hat besonders viele Inline-Elemente für die Textrecherche92, zum Beispiel
Elemente für Änderungen, Korrekturen, Lücken, Bühnenanweisungen, Datum,
bibliografische Referenzen oder verschiedene Interpretationen von bestimmten
Textstellen.
Zugänglichkeit
Die TEI-DTD ist kostenlos über die sourgeforce-Seite93 erhältlich. Des Weiteren
finden sich dort einige Beispiele und die Dokumentation über die DTD.
Verwendungszweck
TEI wurde speziell für die Darstellung von Literatur- und Forschungsmaterialien
entwickelt. Den Schwerpunkt bilden Richtlinien zur Zeichencodierung von maschinenlesbaren Texten aus den Bereichen der Geisteswissenschaften, Sozialwissenschaften und Linguistik.94 Ursprünglich ging es bei TEI um das Abbilden von
traditionellen gedruckten Texten in digitaler Form. Heutzutage ist TEI gleichermaßen für bereits digital vorliegende Texte einsetzbar.95
Besondere Bedeutung hat TEI bei Bibliotheken, Museen, spezialisierten Verlagen
und Forschern für deren Onlinesuche, das Unterrichten sowie die Erhaltung und
Dokumentation von historischen Texten.
Anwendungsbeispiele
Die TEI-DTD wird besonders im englischsprachigen Raum eingesetzt, beispielsweise in den USA, GB und Kanada. In Deutschland benutzen einige Institute und
Universitäten TEI. Zum Beispiel digitalisierte das Deutsche Literaturarchiv Marbach mittels TEI-Lite die Tagebücher von Harry Graf Kessler.96 Das Institut für
92 Vgl. Megginson, David: Structuring XML Documents. S. 66.
93 Zu finden unter: http://sourceforge.net/projects/tei/files.
94 Vgl. TEI: TEI: Text Encoding Initiative. http://www.tei-c.org/index.xml. Zugriff am 01.07.09.
95 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. xxiii.
96 Vgl. Deutsches Literaturarchiv Marbach: http://www.dla-marbach.de/?id=51618, Zugriff am
24.08.09.
Sprach- und Literaturwissenschaft der Universität Darmstadt verwendet TEI für
die „computergestützte Analyse und Interpretation von Texten“ 97 und Forschung.
Das Deutsche Textarchiv hat ein dreijähriges Projekt zur Digitalisierung von 750
Textbeständen aus den Jahren 1780 bis 1900 durchgeführt.98 Für das Projekt wird
TEI-XML nach der aktuellen Richtlinie P5 angewandt. Wie auf der Website beschrieben, werden die Texte linguistisch annotiert, mit Metadaten angereichert
und in einer nativen XML-Datenbank abgespeichert.
Die Freiburger Universität realisierte das Projekt „Freiburger Anthologie – Lyrik
und Lied“. Das Projekt ist eine Zusammenarbeit der Freiburger und der Mainzer
Universität sowie des Deutschen Volksliedarchivs in Freiburg. Dabei ging es um
den Test verschiedener Editionsverfahren, Kommentierungs- und Dokumentationsleistungen. Hieraus entstanden ist eine Datenbank.99
Auch an der Uni München gab es ein TEI-Projekt: „Der junge Goethe in seiner
Zeit.“100 Das Projekt umfasst zwei Bände und eine CD-ROM.
Lizenzbedingungen
Das Schema ist frei zugänglich und unterliegt der GNU General Public License
(GPL). Diese Lizenz erlaubt es, das Schema gemäß der GNU/GPL zu kopieren, zu
verteilen und zu ändern. Die Verwendung von TEI erfordert die Angabe, dass die
Dokumente der GNU Lizenz unterliegen. Der Lizenztext findet sich auf der TEIWebsite101 oder kann aus den TEI-Dateien in eigene Dateien kopiert werden. Das
Copyright besitzt das TEI-Konsortium.
Aktualisierung102
Auf der Website von tei.org wird allgemein von „Richtlinien (Guidelines) für die
Auszeichnung und den Austausch elektronischer Texte“ gesprochen anstatt von
Schema oder DTD.
Die aktuelle Guideline P5 wurde 2007 veröffentlicht. Der Buchstabe „P“ steht für
proposal, übersetzt Vorschlag. Die letzte Aktualisierung von P5 erfolgte am 20. Juni
2009. Erst nach größeren Überarbeitungen wird eine neue Version herausgegeben.
Zwischenzeitlich gibt es Aktualisierungen der einzelnen Versionen. Ein großer
Sprung geschah beispielsweise zwischen P3 und P4. In dieser Periode wurde TEI
vom SGML Format ins XML Format übertragen, um weiterhin marktfähig zu sein.
Die TEI Guidelines werden in unregelmäßigen Abständen veröffentlicht.
97 Technische Universität Darmstadt: Profil des Instituts für Sprach- und Literaturwissenschaft.
http://www.linglit.tu-darmstadt.de/index.php?id=linglit_profil, Zugriff am 24.08.09.
98 Vgl. Deutsches Textarchiv: http://www.deutsches-textarchiv.de/project/description, Zugriff
am 26.08.09.
99 Universität Freiburg: Freiburger Anthologie - Lyrik und Lied. Digitale Dokumentation von lyrischen Kurztexten. http://www.lyrik-und-lied.de/ll.pl?kat=project.main&start=1, Zugriff am 26.08.09.
100 Vgl. Universität München: TEI-Version der Edition „Der junge Goethe in seiner Zeit“. http://
www.jgoethe.uni-muenchen.de/teireadme.html, Zugriff am 25.08.09.
101 Vgl. TEI: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/COPYING.txt, Zugriff am
17.09.09.
102 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. xxix f.
Version
Jahr
P1
1990
P2
1992
P3
1994
P4
2001
P5
2007
Tab. 5: TEI-Versionen
Dokumentierung
Eine umfassende Dokumentation von 1345 Seiten findet sich unter http://www.teic.org/release/doc/ tei-p5-doc/en/html/index.html. Sie ist ausschließlich in Englisch
vorhanden, obwohl von einer Übersetzung in sechs Sprachen gesprochen wird. Mit
dem Klick auf „Deutsch“ wird der Text jedoch so gut wie nicht übersetzt. Lediglich einige Überschriften und ein paar wenige Passagen (zum Beispiel unter 2. The
teiHeader) sind übersetzt. Wahrscheinlich sind die Übersetzungen noch in Arbeit.
Die Dokumentation beschreibt die Infrastruktur von TEI und dokumentiert das
Vokabular zur Auszeichnung von Texten. Im Anhang befindet sich eine Referenz
zu den einzelnen Muster- und Attributklassen, den Elementen und Attributen
sowie Datentypen und Makros.
In der Dokumentation entsprechen die Kapitel 2 bis 22 jeweils einem TEI-Modul.
Ein Kapitel enthält jeweils eine Beschreibung aller Elemente und Attribute, eine
offizielle XML-Beschreibung und Anwendungsbeispiele des jeweiligen Moduls.103
Die Beispiele sind sehr gut und vielfältig. Der Aufbau der Dokumentation ermöglicht es zudem nur die Informationen von relevanten Modulen auszudrucken.
Das Dokumentations-PDF ist sehr gut verlinkt und mit Lesezeichen für eine
unkomplizierte und schnelle Navigation versehen. Jederzeit sind Klassen, Elemente, Attribute usw. im Text anklickbar und per Referenz erreichbar. Neben
der PDF-Dokumentation befinden sich auf der TEI-Webseite104 Links zu OnlineAnleitungen und Beispielen in verschiedenen Sprachen.
Darüber hinaus besteht die Möglichkeit sich die Dokumentation als Print on
Demand-Broschur für ca. 75 € bei Omnipress105 zu bestellen.
In Bibliotheken wie dem Bibliotheksverbund Bayern, dem Südwestdeutschen
Bibliotheksverbund oder dem HBZ NRW-Verbundkatalog liegt die Vorversion
P4 der TEI Guidelines aus dem Jahr 2002 vor. In Deutschland können die P4
Guidelines über Amazon, Lehmanns Fachbuchhandlung, das ZVAB u. a. bestellt
werden. Das dauert in der Regel 30 Tage, da die Bücher nicht auf Lager sind. Der
schnellste Weg ist per Bestellung bei abebooks in UK. Dort dauert es laut Website
ca. eine Woche.
In der Literatur existieren keine Bücher, die sich ausschließlich mit TEI beschäftigen. TEI findet nur am Rande in einigen Büchern Erwähnung, wie z. B. in
103 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. 1f.
104 Vgl. TEI: Teach Yourself TEI. http://www.tei-c.org/Support/Learn/tutorials.xml, Zugriff am
27.08.09.
105Zu finden unter: http://shop.omnipress.com/index.asp?PageAction=VIEWPROD&Prod
ID=161, Zugriff am 27.08.09.
„Structuring XML Documents“ von David Megginson oder „XML in a Nutshell“
von Elliotte Rusty Harold und W. Scott Means. Obwohl deren Informationen teilweise überholt sind, eignen sie sich für einen ersten Überblick über TEI.
Die Website der TEI-Organisation bietet alle wichtigen Informationen, Unterstützung und Hilfe zentral und aktuell im Internet.
Komplexität
TEI ist auf Grund seiner Bedeutung, nämlich so viele Anwendungen wie möglich
abzudecken, wenig spezifiziert.106 Dank des modularen Aufbaus kann der Umfang
der DTD für jede Anwendung beschränkt werden. Man wählt nur die tatsächlich
benötigten Module aus.
TEI hat insgesamt 21 Module, 513 Elemente, 218 Attribute, 21 Datentypenmakros sowie acht Makros für Inhaltsmodelle. Ursache für den Umfang ist die
große Vielfalt an Texten und Anwendungen, denen durch die vielen Elemente
und Attribute gerecht werden soll.
Da ein Attribut zu mehreren Elementen gehören kann, ergeben sich durch Kombination viele verschiedene logische Einheiten, welche die Komplexität der DTD
erhöhen.
So genannte globale Attribute (att.global) sind für alle Elemente definiert. Diese sind optional verfügbar und lauten: xml:id (identifier); n (number); xml:lang
(language); rend (rendition); rendition (Referenz zu einer rendition) und xml:base
(URI-Referenz).107
Die TEI-DTD hat über 500 verschiedene Elemente. Auf Grund der großen
Menge und der Übersichtlichkeit gibt es verschiedene Elementklassen. Man
unterscheidet zwischen Elementen, die gemeinsame Attribute teilen und einer
Gruppe von Elementen innerhalb eines Inhaltsmodelles.108
Es ist zu beachten, dass die Eigenschaften bzw. Attribute der übergeordneten
Klasse an die untergeordnete Klasse vererbt werden.
Modularität
Es gibt nicht die TEI-DTD, sondern die DTD setzt sich immer aus verschiedenen
Modulen zusammen, je nach Erfordernissen des Projektes. 109 Um ein Projekt in
TEI zu realisieren, werden verschiedene zur Verfügung stehende Module zu einer
neuen Datei kombiniert. Diese Datei entspricht schließlich der TEI-DTD. Das bedeutet, dass das TEI-Konsortium nur die einzelnen Module zur Verfügung stellt,
aus denen ein individuelles Schema entsteht.
Durch die Kombinationsmöglichkeiten wird ein maximaler Gestaltungsspielraum erreicht. Im Internet gibt es Werkzeuge, die bei der Erstellung der TEI-DTD
behilflich sind, Näheres dazu im Abschnitt „Besonderheiten“, Seite 61.
106 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. xxv.
109 Vgl. TEI: Getting Started with P5 ODDs. http://www.tei-c.org/Support/Learn/odds.xml,
Zugriff am 25.08.09.
Ein Modul ist eine Menge von zusammengehörigen Elementdeklarationen. Ein
Element ist jeweils einem Modul zugeordnet. Alle Elementnamen kommen nur
einmalig vor und zwar in einem bestimmten Nutzzusammenhang.
Die Module können beliebig kombiniert und in die DTD ein- oder ausgeschlossen werden. Trotzdem ist zu beachten, dass einige Module auf anderen aufbauen
und diese nicht ausgeschlossen werden sollten. Die meisten TEI-Schemata benötigen wenigstens die vier Hauptmodule: tei (beschreibt Klassen, Makros, Datentypen), core (Elementdeklarationen), header (Metainformationen) und textstructure
(grundlegende Strukturelemente), weil sich andere Module auf deren Elemente
beziehen. Das tei-Modul ist immer erforderlich, da es die Deklarationen für alle
Datentypen, grundlegende Muster- und Attributklassen sowie Makros enthält.110
Ein grober Aufbau des Moduls tei und der verhältnismäßige Anteil kann der
folgenden Grafik entnommen werden.
Liste der Elementnamen
Makros für Datentypendeklarationen
Entity für Start- und Endtags
Moduldeklarationen
vordefinierte Klassen
Attributklassen
Musterklassen/Elementklassen
Rest der Makrodeklarationen
Abb. 9: TEI: tei.dtd
Die Reihenfolge der Deklarationen ist bei der Verwendung von Parameter-Entities
von Bedeutung. Deklarationen von Klassen, die sich auf andere Klassen beziehen,
müssen vor ihnen definiert werden.
Die Einbindung eines Moduls erfolgt über eine einzelne Zeile in der TEI-Spezifikation. Die Spezifikation ist ein übergeordnetes TEI-Dokument, das die TEI-DTD
erstellt. Die Erstellung dieser Spezifikation läuft automatisch im Hintergrund
des Werkzeuges ROMA ab. Dieses Online-Tool wird ausführlicher unter dem
Punkt „Besonderheiten“ erläutert. Es ist allerdings möglich, manuell in die TEISpezifikation einzugreifen und Änderungen vorzunehmen.
Folgendes Beispiel zeigt die Einbindung der vier Hauptmodule in der TEISpezifikation.111
<schemaSpec ident=“TEI-minimal“ start=“TEI“>
<moduleRef key=“tei“/>
<moduleRef key=“header“/>
<moduleRef key=“core“/>
<moduleRef key=”textstructure”/>
</schemaSpec>
Die TEI-Spezifikation definiert sich mittels des Elementes schemaSpec; das Attribut
ident steht für identifier und start bezeichnet den Namen des Wurzelelementes im
späteren XML-Dokument. Jedes einzelne Modul wird über das Element moduleRef
mit dem Attribut key aufgerufen.
Außer den Modulen können in der Schemaspezifikation neue Elemente mittels
elementSpec, Makros mittels macroSpec und Klassen mittels classSpec deklariert
werden.
Die TEI-Spezifikation ist selbst ein TEI-Dokument und erstellt zum einen das
TEI-Schema in einer der drei Schemasprachen XML DTD, RelaxNG und W3C
XML-Schema sowie zum anderen eine Dokumentation zum Schema. Das damit
erzeugte Output-Schema ist die TEI-DTD zur Validierung der XML-Dokumente.
Die folgende Abbildung veranschaulicht den Entwicklungsprozess noch einmal
grafisch.
generiert
Dokumentation
(HTML, PDF)
TEISpezifikation
generiert
(TEI-Dokument)
 Angabe der
Module
 Einfügen oder
Löschen von
Elementen
 Redeklarationen
TEI-DTD
(DTD, Relax NG,
W3C XML Schema)
 sämtliche
Deklarationen für
die Validierung
des XMLDokumentes
validiert
XMLDokument
 mittels Tags
strukturierter
Text
Abb. 10: Erstellung einer TEI-DTD (Eigene Darstellung)
Diese Spezifikation nennt TEI ein ODD-Dokument (One Document Does it all),
weil davon ausgehend alles andere generiert wird. Nähere Informationen zum
ODD-Format finden sich ebenfalls im unteren Abschnitt „Besonderheiten“.
Im Folgenden werden alle Module kurz vorgestellt. Der Überblick erleichtert den
späteren Auswahlprozess für das eine oder andere Modul.
Name des Moduls
Beschreibung
tei
Definiert Element- und Attributklassen, Datentypen
und Makros, die von den anderen Modulen benötigt
werden. Deklariert die Module.
header
Elemente und Attribute für die Auszeichnung von
Metadaten eines Buches (bibliografische Angaben,
Transkriptionen, Herkunft, Überarbeitung).
core
Element- und Attributdeklarationen, die für fast jedes
XML-Dokument benötigt werden, z. B. Absätze,
Listen, Abkürzungen, Hervorhebungen usw.
textstructure
grundlegende Strukturelemente für Bücher u. Ä., die
im Element text enthalten sein können.
analysis
Elemente und Attribute für die Analyse und Interpretation (semantisch, syntaktisch) von Texten.
certainty
Modul für die Angabe der Bestimmtheit, Genauigkeit und Verantwortlichkeit für die Auszeichnung
bestimmter Stellen eines Textes.
corpus
Modul für die Sammlung von sprachwissenschaftlichen Daten eines Textes oder Textfragmentes
(geschrieben, gesprochen etc.).
dictionaries
Elemente und Attribute für ein- oder mehrsprachige
Wörterbücher, Glossare u. Ä.
drama
Modul für die Auszeichnung von Dramen, Drehbüchern und Transkription jeder Art von Aufführungen.
figures
Elemente und Attribute für grafische Elemente wie
Tabellen, Abbildungen und Formeln.
gaiji
Elemente für die Darstellung nicht-standardisierter
Zeichen und Glyphen.
iso-fs
Modul für allgemeine Struktureigenschaften von
Daten (z. B. phonologisch).
linking
Elemente für die Darstellung der Analyse von
Textstrukturen durch Verlinkung, Gruppierung und
Aufteilung.
msdescription
Modul für die detaillierte Wiedergabe und Interpretation handschriftlicher Texte.
namesdates
Modul für die Auszeichnung von Namen, Daten,
Orten, Organisationen, das über die Elemente des
core-Modules hinausgeht.
nets
Elemente für die Darstellung von Netzwerken, Graphen und Strukturbäumen.
spoken
Modul für die Transkription von Sprachen.
Name des Moduls
Beschreibung
tagdocs
Modul für die Dokumentation der XML-Elemente und
Elementklassen und für die automatische Erzeugung
von Schemata entsprechend der Dokumentation.
textcrit
Modul für die Auszeichnung von Varianten, Auslegungen, Zitationen etc. eines Textes; Zeugen eines
Textes.
transcr
Modul für die Darstellung geschriebener Texte, z. B.
Faksimilies.
verse
Elemente und Attribute für die Auszeichnung von
Texten die gänzlich oder zum überwiegenden Teil
aus Versen bestehen, falls die Vers-Elemente des
core-Moduls nicht ausreichend sind.
Tab. 6: TEI-Module und Beschreibung
Übersichtlichkeit
Die Struktur von TEI ist äußerst kompliziert. Ausgehend von dem Kernmodul
tei wird auf die einzelnen Module und deren Moduldeklarationen verwiesen.
Dabei hat jedes Modul eine andere spezielle Aufgabe, wie in der oberen Tabelle
dargestellt. In jedem Modul befinden sich entsprechend unterschiedliche Parameter-Entities mit einer Kurzcharakteristik. Diese können durch „Include“ oder
„Ignore“ eingebunden oder ausgeklammert werden. In der Deklaration steht wie
die Entities aufgelöst werden.
Die vielen Parameter erschweren allerdings den Überblick zu behalten. Es ist
ratsam bei der DTD-Erstellung auf das bereits erwähnte Online-Tool ROMA zurück zu greifen.
Namenskonventionen
In der TEI-DTD gibt es folgende Präfixe für die Deklarationen, die durch einen
Punkt vom Elementnamen abgegrenzt sind.
att.*
Deklaration von Attributklassen
data.*(datatype)
verwendet in Makrodeklarationen; beschreibt den Umfang
von Attributwerten
model.*
bezeichnet Musterklassen
x.model.*
das „x“ steht für extension. Der Typ x.model beschreibt ein
erweiterbares Inhaltsmodell. Standardmäßig sind diese leer.
n.* (name)
Name eines Elementes
Elemente und Musterklassen sind nach Struktureigenschaften gegliedert. Klassen
wie model.divPart, model.addrPart oder model.entryPart gehören semantisch zusammen, weil sie innerhalb des Elementes part vorkommen können.112
Eine Musterklasse wird in TEI mit jeweils unterschiedlichen Suffixen deklariert.
Unterschiedliche Suffixe, lassen die Wahl, wie oft und ob ein Element in einem
Inhaltsmodell vorkommt.
112 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. 10 f.
Die Suffixe sind:113
_sequence Elemente der Klasse müssen als Sequenz angegeben werden, d. h. mit
Komma getrennt.
_sequenceOptional Elemente der Klasse können optional angegeben werden,
dann aber als Sequenz mit dem Indikator ?
_sequenceOptionalRepeatable Elemente der Klasse können optional ein Mal oder
mehrere Male in der Sequenz angegeben werden mit dem Indikator *
_sequenceRepeatable Elemente der Klasse müssen angegeben werden und in
Sequenz stehen, d. h. mit dem Indikator +
Prinzipiell können alle Elemente in allen Varianten auftreten. Hierdurch wird die
DTD erheblich verlängert, aber sehr flexibel. Einschränkungen diesbezüglich sind
durch das Element classSpec mit dem Attribut generate möglich. Beispielsweise
kann eine Deklaration dann wie folgt aussehen:
<classSpec ident=“model.applicationLike“ generateOnly=“sequence“
Mit dieser Deklaration in der TEI-Spezifikation wird für die Elemente der Musterklasse model.applicationLike nur eine Sequenz zugelassen.
Eine andere Art der Gruppierung ist die Verwendung von Like. Zum Beispiel
gruppiert die Klasse model.listLike verschiedene Listenelemente wie list, listBibl,
listEvent etc.
Modifikation
Es ist nicht möglich TEI nicht zu modifizieren oder nicht zu personalisieren. Die
Modifizierung beginnt bereits bei der Auswahl der Module und geht bis hin zur
Änderung einzelner Attribute.
Eine Art der Modifizierung ist die schon erwähnte Kombination der vier Hauptmodule tei, header, core und textstructure. Darüber hinaus können je nach Textart
und Anforderungen des Textes weitere Module dazu genommen werden.
Die TEI-DTD ist komplex, aber ähnlich wie DocBook bietet sie ebenfalls eine
Lite Version. TEI-Lite enthält alle Kernelemente wie die komplette DTD und ist
ausreichend für einfachere Anwendungen. Es wird gesagt, dass TEI-Lite 90% der
Funktion für 90% der Nutzer abdeckt.114
Weitere Subsets sind in der folgenden Liste zusammengefasst. Dabei handelt es
sich um Beispielmodifikationen.115 Diese können für das eine oder andere Projekt
bereits sehr hilfreich und ausreichend sein.
▶▶ tei_bare: TEI Absolutely Bare
▶▶ tei_tite: TEI Tite (A recommendation for off-site text encoding)
▶▶ tei_lite: TEI Lite
▶▶ tei_corpus: TEI for Linguistic Corpora
▶▶ tei_ms: TEI for Manuscript Description
▶▶ tei_drama: TEI with Drama
113 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. 671 ff.
114 Vgl. Burnard, Lou; Sperberg-McQueen, C. M.: TEI Lite: Encoding for Interchange: an introduction to the TEI — Revised for TEI P5 release. http://www.tei-c.org/release/doc/tei-p5-exemplars/html/
teilite.doc.html. Zugriff am 12.07.09.
115 Vgl. ROMA: http://www.tei-c.org/Roma/, Zugriff am 23.07.09.
▶▶ tei_speech: TEI for Speech Representation
▶▶ tei_odds: TEI for authoring ODD
▶▶ tei_allPlus: TEI with maximal setup, plus external additions
▶▶ tei_svg: TEI with SVG
▶▶ tei_math: TEI with MathML
▶▶ tei_xinclude: TEI with XInclude (experimental)
▶▶ tei_dictionaries: TEI for Dictionaries (experimental)
Grundsätzlich ist es möglich, Elemente von Modulen oder Attribute von Elementen auszuschließen, Namen von Elementen und Attributen zu ändern oder neue
Elemente und Attribute zu deklarieren. Das Werkzeug ROMA ist dabei behilflich.
Außerdem ist durch den Einbezug von anderen Elementen über eine Referenz die
Einbindung von XML-Vokabular möglich.
Um eine Modifizierung durchzuführen gibt es drei verschiedene Möglichkeiten:116
1. Das Erstellen einer high-level Spezifikation, um ein Schema oder eine DTD
zu generieren. Dies ist die bevorzugte Variante, weil Änderungen somit nicht
direkt im Modul vorgenommen werden.
2. Veränderungen in den DTD-Modulen selbst durch An- und Ausschalten von
Objekten.
3. Unter Verwendung von Relax NG ein umschließendes Schema schreiben.
Das Motto lautet: Klarheit vor Knappheit. Die Namen wurden wegen der Klarheit
und nicht der Kürze ausgewählt.117
Die Elementnamen sind unterschiedlich lang. Elementnamen wie m für morpheme sind wenig selbsterklärend. Andere Namen wie listPerson erklären sich von
selbst. Wie bei listPerson zu sehen ist, beginnt bei zusammengesetzten Namen der
zweite Name immer mit einem Großbuchstaben. XML-Dokumente sind casesensitive, so dass auf die korrekte Schreibweise geachtet werden muss.
In TEI haben einige Elemente markante Suffixe im Namen, anhand derer sich
ahnen lässt, was das Element bedeutet. Diese sind Part, Like, Desc, Struct, Ref,
Grp, Stmt 118 u. a. Sie unterstützen den Anwender bei der Auswahl von Elementen.
Manchmal dienen Suffixe auch der Unterscheidung mehrerer Elemente. Beispielsweise beim Element list. Dort gibt es listBibl, listEvent, listNym, listOrg, listPerson,
listPlace, listRef und listWit.
In den Standard TEI-Modulen existieren keine ausreichenden Elemente für die
typografische Auszeichnung von Texten. TEI konzentriert sich eher auf die Bedeutung von Wörtern oder Textpassagen. Lediglich das Element hi (highlight)
116 Vgl. TEI: Getting Started with P5 ODDs. http://www.tei-c.org/Guidelines/Customization/odds.
xml, Zugriff am 29.08.09.
117 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. xxvii.
ist zur Kennzeichnung typografisch besonderer Textstellen gedacht. Mittels des
Attributes rend lässt sich die grafische Darstellung bestimmen.
Für die typografische Auszeichnung existiert das nützliche Subset TEI-Tite.
Dieses erweitert TEI um die Elemente für fett, kursiv, unterstrichen, Kapitälchen,
hoch- und tiefgestellt u. a. Diese Auszeichnungen sind gruppiert in der Musterklasse model.hiLike. Das Subset kann ebenfalls in ROMA ausgewählt und modifiziert werden.
Tabellen
Grundsätzlich verwendet TEI ein einfaches Tabellenmodell, das dem der ISO
12083 sehr ähnlich ist.119 Dieses beschreibt eine Tabelle Zeile für Zeile.
Es ist außerdem möglich das CALS-Modell in TEI einzubinden. Dieses Modell
erlaubt das horizontale und vertikale Zusammenfassen mehrerer Zellen sowie
verschiedene Textausrichtungen innerhalb der Zellen. Des Weiteren können
XHTML-Tabellen in TEI verwendet werden.
Listen
Listen werden durch das Element list gekennzeichnet. Das Attribut type bestimmt
die Art der Liste. Es gibt ordered (nummeriert oder beschriftet), bulleted (Aufzählungszeichen), simple (ohne alles; das ist der Standardwert) oder gloss (jedes Element der Liste erläutert einen Begriff, der zuvor im label-Element definiert wurde).
Ein Beispiel für die Verwendung von gloss-Listen ist das Glossar.120
Besonderheiten
ODD – One Document Does it all
Der Name ODD ist eine Besonderheit von TEI. Die TEI-Spezifikation wird ODDDokument genannt, weil ausgehend davon Folgendes generiert wird:121
▶▶ eine Dokumentation über Referenzen für Elemente, Attribute, Elementklassen
▶▶ andere Dokumentationen (tag description lists)
▶▶ Code für XML-Sprachen (Relax NG, W3C Schema)
▶▶ Code für XML-DTD
Mit diesem Format wird eine Möglichkeit der Selbstdokumentation von TEI geboten. Das Modul tagdocs wird für die Dokumentation benötigt. Es ergänzt TEI
um Elemente für die Definition eines neuen Schemas und die Modifizierung von
Elementstrukturen.122
ROMA
ROMA123 heißt eine Online-Anwendung, die es ermöglicht ein TEI-Schema binnen weniger Minuten zu erstellen. ROMA unterstützt den Anwender mit einer
Benutzeroberfläche, auf der durch Auswahl der benötigten Module eine TEISpezifikation und die DTD automatisch im Hintergrund erstellt werden. Die
120 Vgl. TEI: P5: Guidelines for Electronic Text Encoding and Interchange, S. 95ff.
122 Vgl. TEI: Getting Started with P5 ODDs. Writing ODD specifications. http://www.tei-c.org/Guidelines/Customization/odds.xml#tab_modlist, Zugriff am 29.08.09.
123 Vgl. ROMA: http://www.tei-c.org/Roma/, Zugriff am 23.07.09.
Oberfläche gestaltet sich so, dass der Benutzer durch einfaches Anklicken von
Buttons die Module, Elemente und Attribute auswählen und bearbeiten kann. Mit
dieser Möglichkeit lässt sich die Anzahl der Elemente für ein Projekt eingrenzen
und genau festlegen.
Die TEI-Spezifikation (Customization) kann der Nutzer lokal speichern und zu
einem späteren Zeitpunkt weiterbearbeiten; zum Beispiel durch das Hinzufügen
eines neuen Moduls oder Elementes. Dazu wird der Menüpunkt „Open existing
customization“ gewählt (Abb. 11).
Bei der Erstellung des Schemas kann entweder auf bereits vorhandene Templates
zurückgegriffen oder ein neues Schema erstellt werden (Siehe Abb. 11).
Abb. 11: Ein Schema erstellen, modifizieren oder auswählen
Anschließend werden einige Metadaten zur Datei angelegt (Siehe Abb. 12).
Abb. 12: Metadaten für die Datei festlegen
Mit etwas mehr Zeit kann man einzelne Module hinzufügen (siehe Abb. 13) und
sogar für jedes einzelne Element (siehe Abb. 14) und Attribut (siehe Abb. 15) die
Eigenschaften bestimmen.
Abb. 13: Hinzufügen und Entfernen von Modulen
Abb. 14: Hinzufügen und Entfernen von Elementen
Abb. 15: Hinzufügen und Entfernen von Attributen
Besonders wichtig ist es, alle Änderungen über den Button „Save“ am Seitenende
zu speichern, da sonst die Änderungen nicht wirksam werden.
Über den Tab „Documentation“ wird eine Dokumentation des aktuellen Schemas als PDF oder HTML gespeichert. Diese enthält alle verwendeten Makros,
Musterklassen, Attributklassen und Elemente mit einer Beschreibung. Es dient
der Selbstdokumentation des erzeugten Schemas.
Mit dem Werkzeug „Sanity Checker“ werden das Schema überprüft und eventuelle Fehler dokumentiert.
ROMA existiert ebenso als command-line Version „roma“ für die lokale Verwendung auf dem Rechner.124
Weitere Informationen über die Verwendung von ROMA befinden sich auf der
Seite von TEI unter dem Menüpunkt „Tools“.
Stylesheets
Zur weiteren Umgebung von TEI gehören XSL-Stylesheets, die TEI-XML-Dateien
zu HTML, LaTeX oder XSL-FO konvertieren. Diese wurden von Sebastian Rahtz
entwickelt und sind nur für bestimmte TEI-Konvertierungen geeignet. Die Stylesheets werden über die sourceforge.net-Seite125 heruntergeladen. Die Zip-Datei
enthält Ordner mit den jeweiligen Ausgabeformen: common, fo, html und latex.
Common bedeutet, dass die Ausgabeform offen bleibt. In den Ordnern befinden
sich jeweils die XSL-Dateien für die Verarbeitung der Module. Es gibt in jedem
Ordner die Masterdatei tei.xsl. Um ein Stylesheet zu verwenden, entscheidet man
sich für eine Ausgabeform (common, fo, html, latex) und referenziert im XMLDokument die entsprechende tei.xsl-Datei.
Jeder Anwender kann weitere Stylesheets über die TEI Wiki-Seite126 hinzufügen.
Eine Dokumentation zu den Stylesheets findet sich hier: http://wiki.tei-c.org/index.
124 Vgl. TEI: TEI Tools. ROMA. http://www.tei-c.org/Tools, Zugriff am 29.08.09.
125 Zu finden unter: http://sourceforge.net/projects/tei/files.
126 Vgl. TEI Wiki: Category:XSLT. http://wiki.tei-c.org/index.php/Category:XSLT, Zugriff am
29.08.09.
php/Category:XSLT. Außerdem gibt es ein Customization Handbuch unter: http://
www.tei-c.org/Tools/Stylesheets/customize.xml.
Die Stylesheets lassen sich gut mit den XSLT-Prozessoren Saxon, Xalan und
libxslt weiterverarbeiten.127
Für die beispielhafte Auszeichnung eines Textes in TEI-XML wird hier die TEI
Lite-DTD aufgerufen. Ansonsten muss ein eigenes DTD-Schema in ROMA erstellt werden, das per System-ID aufgerufen wird. Auf Grund der Einheitlichkeit
wird jedoch in jedem hier dargestellten Beispiel ein Public Identifier verwendet.
Hieraus erklärt sich die Verwendung von TEI-Lite.
Ein Unterschied zwischen TEI und TEI-Lite ist, dass TEI-Lite nur das div-Element und nicht die Elemente div1 bis div7 zulässt.
In XML kann man Elemente auszeichnen, selbst wenn diese in der Printausgabe
später nicht sichtbar sind. Dazu zählen beispielsweise Textkorrekturen, Interpretationen von Textpassagen oder sprachliche Anmerkungen. Das XML-Dokument
kann folglich mit wesentlich mehr Information angereichert werden, als dies für
die Printausgabe erforderlich sein wird. Dies wird im TEI-XML-Dokument durch
das Element said verdeutlicht.
<!DOCTYPE TEI PUBLIC “-//TEI//DTD TEI Lite XML ver. 1.0//EN”
“http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd”>
<TEI xmlns=“http://www.tei-c.org/ns/1.0“>
<teiHeader>
<fileDesc>
<titleStmt>
<author>Sir Arthur Conan Doyle</author>
</titleStmt>
<editionStmt>
<edition>
<date>1892</date>
</edition>
</editionStmt>
<publicationStmt>
<publisher>Penguin Group</publisher>
<pubPlace>London</pubPlace>
<address>
<addrLine>Penguin Books Ltd, 80 Strand, WC2R ORL, London
</addrLine>
</address>
<date>1994</date>
<idno type=“ISBN“>978-0-140-62100-6</idno>
<availability>
127 Vgl. TEI: XSL stylesheets for TEI XML. http://www.tei-c.org/Tools/Stylesheets, Zugriff am
29.08.09.
<p>All rights reserved</p>
</availability>
</publicationStmt>
<sourceDesc>
<p>digitalised book</p>
</sourceDesc>
</fileDesc>
</teiHeader>
<text>
<body>
<div type=“chapter“>
<head>A Scandal in Bohemia</head>
<div type=“section“>
<head>1. Abschnitt</head>
<p>To <hi rend=“bold“>Sherlock Holmes</hi>she is always
<emph>the</emph> woman. I have seldom heard him mention her
under any other name. In his eyes she eclipses and predominates the
whole of her sex. It was not that he felt any emotion akin to love for
Irene Adler. All emotions, and that one particularly, were abhorrent
to his cold, precise but admirably balanced mind. He was, I take it,
the most perfect reasoning and observing machine that the world has
seen, but as a lover he would have placed himself in a false position.</
p>
</div>
<head>2. Abschnitt</head>
<head>2.1 Abschnitt</head>
fashion.</p>
<head>2.1.1 Abschnitt</head>
<p><said>“Wedlock suits you,“</said>he remarked. <said>“I
think, Watson, that you have put on seven and a half pounds
since I saw you.“</said></p>
<p><said>“Seven!“</said>I answered.</p>
<p><said>“Indeed, I should have thought a little more. Just a
trifle more, I fancy, Watson. And in practice again, I observe.
You did not tell me that you intended to go into harness.“</
said></p>
</div>
</div>
</div>
</div>
</body>
</text>
</TEI>
NCBI Book Tag Set67
5. NCBI Book Tag Set
5.1 Allgemeines
Das NCBI Book Tag Set ist Teil von insgesamt vier Tag Sets mit jeweils verschiedenen Schwerpunkten. Diese wurden vom National Center for Biotechnology
Information (NCBI) of the National Library of Medicine (NLM) unter den Namen „Journal Archiving and Interchange Tag Suite“ zusammengefasst und ab
2003 veröffentlicht.128
Das NCBI wurde 1988 gegründet. Es erstellt öffentliche Datenbanken, betreibt
Forschung, entwickelt Software für mikrobiologische Analysen und verbreitet
biomedizinische Informationen.
Die NLM wurde 1836 gegründet und ist ein Teil der National Institutes of Health
(NIH). NLM ist die weltweit größte biomedizinische Bibliothek.129 Sie ist außerdem
Teil des nationalen Netzwerkes medizinischer Bibliotheken mit 5.600 Mitgliedern
bzw. Partnerinstitutionen und überwiegend in Krankenhäusern und Kliniken
angesiedelt.
Die einzelnen Tag Sets heißen:
▶▶ Archiving and Interchange Tag Set
▶▶ Journal Publishing Tag Set
▶▶ Article Authoring Tag Set
▶▶ NCBI Book Tag Set (inkl. Collection Tag Set)
Für die Arbeit ist vor allem das Book Tag Set130 relevant. Die anderen Tag Sets
finden nur am Rande Erwähnung.
5.2 Aufbau und Struktur 131
Mit dem Book Tag Set lassen sich Metadaten und Buchinhalte oder nur Metadaten
von Büchern und Kapiteln beschreiben. Das Wurzelelement heißt book.
Mit dem Collection Tag Set lassen sich Metadaten für Buchsammlungen und
Informationen über die Bücher der Sammlung darstellen. Das Wurzelelement
heißt demzufolge collection.
128 Vgl. NCBI/NLM: Introduction. http://dtd.nlm.nih.gov, Zugriff am 05.09.09.
129 Vgl. NLM: Fact Sheet – The National Library of Medicine: http://www.nlm.nih.gov/pubs/factsheets/nlm.html, Zugriff am 16.09.09.
130 Für eine bessere Lesbarkeit wird die Abkürzung NCBI des Öfteren weggelassen.
131 Vgl. NCBI: General Introduction – Book and Collection Tag Sets: http://dtd.nlm.nih.gov/book/
tag-library, Zugriff am 30.07.09.
NCBI Book Tag Set68
book
book-meta
book-front?
address* bis verse-group*
body?
sec*
back?
book-part*
back?
(Auswahl verschiedener Elemente)
book-meta?
bookpart-meta?
book-front?
body?
back?
Abb. 16: Top-level-Struktur eines Book Tag Set-XML-Dokumentes (Eigene Darstellung)
Book-meta
Das Book Tag Set kann theoretisch nur die Metainformationen des Buches enthalten, alle anderen Teile sind optional. Dadurch ist es zum Beispiel möglich nur
die Metadaten in XML für ein bereits vorhandenes PDF-Dokument zu erstellen.
Zu den Metainformationen gehört mindestens ein Titel; optional sind eine BuchID, Angaben zur Reihe/zur Werkausgabe, Verlag, ISBN, ein Abstract, Links usw.
Book-front
Zu dem Vorspann eines Buches können ein Vorwort, eine Einleitung, ein Inhaltsverzeichnis, eine Biografie, ein Glossar, Tabellen oder Anmerkungen gehören.
Body
Das Element bezeichnet den optionalen Hauptteil eines Buches. Zu den bodyElementen zählen 28 Elemente, die in obigem Schema nur abgekürzt dargestellt
sind (address bis verse-group). Diese stellen eine Auswahl verschiedener Elemente
dar, die beliebig oft vorkommen können. Des Weiteren unterteilt sich der Hauptteil
in sec (sections), book-part und back.
Back
Der Anhang kann die gleichen Elemente wie book-front enthalten, ergänzt um die
beiden Elemente app-group (Appendix) und ref-list (Referenzliste).
Das Collection Tag Set ist ähnlich wie das Book Tag Set aufgebaut. Es muss
demzufolge auch nur die Metainformationen über die Sammlung enthalten. Optional sind der front matter, body und back matter, welche Beschreibungen über
die Sammlung und deren Bücher enthalten.
NCBI Book Tag Set69
Zugänglichkeit
Alle Versionen der Tag Suite sind über einen FTP-Server132 kostenlos als Zip-File
zugänglich. Es besteht ebenso die Möglichkeit alle DTD-Dateien direkt im Webbrowser anzuschauen.133
Ebenfalls in der Zip-Datei befindet sich die Online-Dokumentation, die nur
mittels Webbrowser lesbar ist.
Die einzelnen Tag Sets wurden nach der vom W3C verfassten Arbeitsrichtline
„Web Content Accessibility Guidelines 2.0“ vom 22. August 2002 entworfen.134
Diese enthält Bestimmungen zum Entwurf und Anwenden der DTD für sehbehinderte Menschen. Ein Beispiel ist das Element long-desc für eine ausführliche
Beschreibung von Bildern und Grafiken.
Verwendungszweck
Der Schwerpunkt der vier Tag Sets liegt auf dem Austausch von Zeitschriftenartikeln zwischen Archiven sowie dem Verfassen und Archivieren von Artikeln.
Weiterhin können Briefe, Bücher und Rezensionen damit ausgezeichnet werden.
Ursprünglich sollte damit nur das elektronische Publizieren unterstützt werden,
aber die DTD eignet sich auch für die Herstellung von Printprodukten.135
Das Book Tag Set wurde speziell für die Beschreibung von Bänden der NCBI
Online-Bibliotheken entwickelt. Es handelt sich dabei um medizinische Fach- und
Lehrbücher mit zahlreichen Fußnoten, Tabellen und Abbildungen.
Lizenzbedingungen136
Die NCBI Tag Sets sind lizenzfrei für jedermann verwendbar. Unternehmen, die
aus dem Tag Set ihr eigenes Schema entwickeln wollen, können dies ohne Genehmigung tun. Die Suite darf jedoch weder direkt modifiziert noch dürfen geänderte
Dateien weiterverbreitet werden. Änderungen sollten immer in einer separaten
Datei vorgenommen werden.
Bei der Erstellung eines neuen Schemas, dass mit der Suite kompatibel sein soll,
muss folgender Satz in der Datei stehen: Created from, and fully compatible with,
the NLM Journal Archiving and Interchange Tag Suite.
Bei Änderung mehrerer Module müssen diese neu benannt und unter einer
neuen Version gespeichert werden. Zusätzlich sollte folgender Satz in den Dateien
stehen: Based in part on, but not fully compatible with, the NLM Journal Archiving
and Interchange Tag Suite.
132 Download unter: ftp://ftp.ncbi.nih.gov/pub/archive_dtd, Zugriff am 30.07.09.
133 Zu finden unter: http://dtd.nlm.nih.gov/book/tag-library/n-tk72.html, Zugriff am 30.07.09.
134Vgl. NCBI: General Introduction. http://dtd.nlm.nih.gov/book/tag-library/, Zugriff am
30.07.09.
135 Vgl. NCBI/NLM: Introduction. http://dtd.nlm.nih.gov, Zugriff am 05.09.09.
136 Vgl. NCBI/NLM: Introduction – Using the Suite. http://dtd.nlm.nih.gov, Zugriff am 05.09.09.
NCBI Book Tag Set70
Dokumentierung
Die Dokumentationen für die verschiedenen Tag Sets sind räumlich und farblich
voneinander getrennt. Jedes Tag Set hat eine eigene Website, die immer identisch
aufgebaut ist. Dadurch bleibt alles sehr übersichtlich. Die Dokumentation ist ausschließlich als Ansicht im Webbrowser und nur in Englisch verfügbar.
Alle Elemente, Attribute und Parameter-Entities sind in verschiedenen Ansichten dargestellt. Zum einen in XML-Syntax mit jeweils einem Inhaltsmodell,
einem erweiterten Inhaltsmodell und einer Erklärung, wie die Elemente verwendet
werden. Man benötigt so gut wie keine Kenntnisse, um die Inhaltsmodelle zu verstehen und zu benutzen. Zum anderen gibt es eine übersichtliche Baumstruktur,
welche die Dokumentstruktur eines Buches oder einer Sammlung sichtbar macht.
Grundsätzlich sind bei der Book-DTD die verschiedenen Darstellungen der
Beziehungen zwischen Elementen sehr gut aufbereitet: ob als einfache alphabetische Liste, als Baumstruktur oder als Kontexttabelle. Eine kleine Verbesserung
wäre die Verlinkung aus den Parameter-Entities auf die einzelnen Elemente, dies
ist momentan jedoch nicht möglich. Bei den Kontexttabellen sind hingegen alle
Elemente verlinkt.
Sehr gut dokumentiert ist auch die Verwendung der Module, Elemente und Attribute in den DTD-Dateien selbst. Jeweils zu Beginn eines Modules befinden sich
neben gängigen Metainformationen Angaben zum Zweck und Inhalt des Modules.
Diese kurzen Erklärungen ersparen oft das Nachschlagen in einer Dokumentation
und die Informationen sind dort, wo man sie benötigt.
Zur Dokumentation gehört eine umfassende Beispielauszeichnung eines Buches
in XML.137
Da diese DTD ziemlich neu ist, gibt es keine Bücher darüber. Sie findet höchstens Erwähnung in medizinischen Fachbüchern wie „XML for Bioinformatics“
von Ethan Cerami oder „E-Journals Access and Management“ von Wayne Jones.
Aktualisierung138
Nach dem Erscheinen der ersten Tag Suite 2003 wurde jedes Jahr eine verbesserte Version herausgebracht. Einige wesentliche Verbesserungen und Änderungen
enthalten die jeweiligen Versionen 1.0, 2.0 und 3.0. Die Zwischenversionen sind
nur Fehlerkorrekturen bzw. kleinere Veränderungen.
In Version 1.0 gibt es zunächst nur die beiden Tag Sets Archiving and Interchange
und Journal Publishing. Seit Version 2.0 gibt es dann das NCBI Book Tag Set, das
aus den anderen beiden Tag Sets hervorgegangen ist.
Seit Version 2.1 ist das Tag Set Article Authoring verfügbar. Seitdem kamen keine
weiteren Tag Sets hinzu.
Es sei darauf hingewiesen, dass Version 3.0 definitiv nicht mehr mit vorherigen Versionen kompatibel ist. Die Struktur hat sich durch die Einführung neuer
Containerelemente verändert und sie ist strikter, d. h. sie lässt nicht mehr direkte
Child-Elemente und Containerelemente gleichzeitig zu. Außerdem ist die Namensgebung konsistenter und die Verschlagwortung verbessert. Aus der so genannten
137 Vgl. NCBI: Full Book Sample. http://dtd.nlm.nih.gov/book/tag-library, Zugriff am 05.09.09.
138 Vgl. NCBI: Tag Suite Versions. http://dtd.nlm.nih.gov, Zugriff am 04.08.09.
NCBI Book Tag Set71
Tag Library139 sind nun alle derzeitigen Elemente, Attribute und Parameter-Entities
ersichtlich.140
Ab Version 3.0 haben die Module Versionsnummern im Dateinamen, z. B. bookpart3.ent.141
Version
Jahr
1.0
März 2003
1.1
Nov. 2003
2.0
Dez. 2004
2.1
Nov. 2005
2.2
Juni 2006
2.3
März 2007
3.0
Nov. 2008
Tab. 7: Book Tag Set-Versionen
Komplexität
Das Book and Collection Tag Set dient in erster Linie dazu die Bestände der NLM
zu digitalisieren bzw. mit Metainformationen zu versehen. Die Entwicklung einer
DTD wurde vom NCBI initiiert und seitdem kontinuierlich weiterentwickelt. Das
geht zum einen aus der Entwicklungsgeschichte hervor und zum anderen aus der
DTD selbst. In den Tag Sets befindet sich ein gleicher Stamm an Modulen, weil das
eine oder andere Set aus einem anderen hervorgegangen ist. Beispielsweise ging
das Journal Publishing Tag Set aus dem Archiving and Interchange Tag Set hervor.
Durch die Unterteilung in die vier Tag Sets bleibt jedoch jedes Schema übersichtlich. Es lässt sich leicht nachvollziehen, welche Module in dem Schema aufgerufen
werden und was sie bewirken.
Die einzelnen Module sind meist nicht komplex und mit zahlreichen nützlichen
Kommentaren versehen. Lediglich einige der gemeinsam genutzten Module wie
common.ent, articlemeta.ent, references.ent sind etwas umfangreicher.
Die Book DTD hat 36 Module (davon neun buchspezifische), 239 Elemente und
140 Attribute. Die komplette Tag Suite umfasst 427 Elemente.
Modularität
Das Book and Collection Tag Set wurde als modulare DTD geschrieben. Innerhalb
jedes Tag Sets befinden sich jeweils eine Haupt-DTD (zum Beispiel book3.dtd)
und die dazugehörigen Module. Kein einzelnes Modul ist eine komplette DTD,
sondern mehrere Module bilden zusammen die DTD. Die Haupt-DTD ruft alle
anderen Module auf.
139 Zu finden unter: http://dtd.nlm.nih.gov/book/tag-library, Zugriff am 12.12.09.
140NCBI: Change Report: Version 3.0. http://dtd.nlm.nih.gov/book/tag-library/3.0/index.html?
chap=chg-rpt, Zugriff am 16.08.09.
141 Vgl. NCBI: Modul Name Changes. http://dtd.nlm.nih.gov/book/tag-library/3.0/index.html?
chap=chg-rpt, Zugriff am 04.08.09.
NCBI Book Tag Set72
Das NCBI Book and Collection Tag Set wurde aus Modulen des Authoring and
Interchange Tag Sets und des Journal Publishing Tag Sets entwickelt und um einige
buchspezifische Tags erweitert. Deshalb befinden sich im Ordner des Book Tag
Sets Dateien mit dem Namen articlemeta und journalmeta.
Das Tag Set unterscheidet zwischen buchspezifischen und allgemeinen Modulen
(aus Archiving and Interchange und Journal Publishing). Die allgemeinen Module
sind in allen vier Tag Sets identisch, wohingegen die buchspezifischen Module für
Bücher und Sammlungen gedacht sind. Beispielsweise benötigt man für ein Buch
andere Elemente als für eine Zeitschrift oder einen Artikel.
bookcustom-modules.ent
modules.ent
bookcustom-classes.ent
default-classes.ent
related-object.ent
bookcustom-mixes.ent
default-mixes.ent
section.ent
bookcustom-models.ent
common.ent
XHTMLtablesetup.ent
articlemeta.ent
xhtml-table-1.mod
backmatter.ent
xhtml-instyle-1.mod
display.ent
oasis-tablesetup.ent
format.ent
oasis-exchange.ent
funding.ent
xmlspecchars.ent
journalmeta.ent
chars.ent
link.ent
mathmlsetup.ent
list.ent
mathml-qname.mod
math.ent
mathml.dtd
para.ent
ent-mmlextra
phrase.ent
ent-mmlalias
references.ent
notat.ent
bookimagemaps.ent
bookmeta.ent
bookmultilink.ent
bookpart.ent
nlmcitation.ent
Tag Suite Modules
Bookspecific
Element Modules
Customization
Modules
book.dtd
Abb. 17: Übersicht über alle Module des Book Tag Sets (Eigene Darstellung).
Im Folgenden einige Erläuterungen zum Inhalt der Module:142
Die Datei book.dtd ruft als Erstes die beiden Module bookcustom-modules143
und modules auf. Danach folgen alle anderen Module. Bei der Reihenfolge ist zu
beachten, dass die Customization Modules immer vor den Tag Suite Modulen aufgerufen werden. Grund dafür ist, dass die vier Customization Modules teilweise
die Element- und Attributdeklarationen der Suite überschreiben. Das Modul bookcustom-classes muss beispielsweise vor default-classes stehen. Ansonsten würde
der Parser bookcustom-classes nicht lesen, da er immer die erste Deklaration liest.
142 Entnommen aus den Kommentartexten der DTD-Module (elektronische Dateien).
143 Die Endung .ent wird zu Gunsten einer besseren Lesbarkeit im Text weggelassen.
NCBI Book Tag Set73
Weithin sind in der Datei book.dtd die Inhaltsmodelle von book,book-meta,
book-front, body und back deklariert.
Es wird zwischen verschiedenen Arten von Modulen unterschieden.144 Die Datei
modules beschreibt die Module, um andere Module zu benennen und um neue
Tag Sets zu bauen. Module wie references oder links definieren nur die Elemente
für Referenzen bzw. interne oder externe Links.
Das Modul default-classes enthält die Hauptklassen für die gesamte Tag Suite
und ist demzufolge äußerst umfangreich. Dieses Modul wird teilweise von den
Deklarationen in bookcustom-classes überschrieben und um neue buchtypische
Elemente ergänzt. Analog dazu überschreibt bookcustom-mixes das Modul defaultmixes.
Die fünf Bookspecific Element Modules fügen neue Elemente und Attribute
speziell für Bücher hinzu.
Die Module ent-mmlextra und ent-mmlalias dienen der Weiterverarbeitung
von MathML.
Die Module oasis-tablesetup und oasis-exchange für das CALS-Tabellenmodell
stehen zwar zur Verfügung, werden aber in dem aktuellen Book Tag Set nicht
verwendet. Eine Einbindung in die DTD ist über einen Verweis möglich. Die
beiden oasis-Module haben einen eigenen Namensraum, um Konflikte mit dem
Tabellenformat XHTML zu vermeiden.
Die Module section.ent oder phrase.ent beschreiben die Klassen und deren Elemente, die innerhalb eines Abschnittes oder eines Satzes vorkommen können. Ein
Modul wie common.ent gruppiert Elemente und Attribute, die in Inhaltsmodellen
anderer Klassenelemente vorkommen.
Das Collection Tag Set ist ähnlich dem Book Tag Set aufgebaut, nur dass es einige
spezielle Elemente für die Beschreibung einer Sammlung enthält. Es leitet sich aus
dem Book Tag Set ab. Ansonsten verwenden das Book Tag Set und das Collection
Tag Set alle Module gemeinsam.
Die Tag Sets liegen als XML-DTD, W3C XML-Schema und Relax NG vor, aber
nur für die XML-DTD ist eine Weiterentwicklung geplant, da sich mit der XMLDTD die modulare Struktur am besten darstellen lässt.145
Übersichtlichkeit
Die Struktur innerhalb der Book oder Collection DTD ist sehr übersichtlich und
klar gegliedert. Die Dateien sind durch Überschriften und Erklärungen in kurze
einzelne Abschnitte unterteilt. Es wird außerdem darauf hingewiesen, welche Module vor anderen Modulen aufgerufen werden müssen. Von der DTD ausgehend
schlüsselt sich die Struktur in kleinere Einheiten auf, ähnlich einer Baumstruktur.
Die einzelnen Inhaltsmodelle lassen sich gut verfolgen.
144 Vgl. NCBI: Learn the DTD Structure. http://dtd.nlm.nih.gov/book/tag-library, Zugriff am
16.08.09.
145 Vgl. NCBI/NLM: NLM Journal Archiving and Interchange Tag Suite. http://dtd.nlm.nih.gov/,
NCBI Book Tag Set74
Module of Modules
Customization Modules
Common (shared) Elements Module
DTD Suite Class Elements
Rest of DTD Suite
Parameter Entities for Attribute Lists
Book-Specific Elements
Book Elements
Book Metadata
Book Textual Front Matter
Book Elements
Back Matter Elements
Abb. 18: NCBI Book Tag Set: Book-DTD (Eigene Darstellung)
Namenskonventionen
Module, Klassen, Elemente und Attribute sind immer an der angehängten Endung
identifizierbar. Parameter-Entities mit dem Suffix elements definieren Elemente,
mit dem Suffix atts Attribute, mit dem Suffix model Inhaltsmodelle usw. Die Beispiele verdeutlichen dies:
<!ENTITY % address-link.class
“email | ext-link | multi-link | uri“>
Als Klasse wird eine Auswahl von Elementen bezeichnet, die als so genannte „ORGruppe“ auftreten. (Wahlmöglichkeit, dargestellt durch den vertikalen Strich | )
<!ENTITY % institution-elements
“ | %break.class; | %emphasis.class; | %phrase-content.class; | %subsup.class;“>
Hierbei handelt es sich um einen Mix, d. h. eine OR-Gruppe von Klassen. Mixes
können erst nach der Klassendeklaration gebildet werden. Mixes haben kein festgelegtes Suffix. Es kann -mix oder -elements heißen. Das Suffix ist elements, wenn
die Inline Parameter-Entities mit #PCDATA in einem gemischten Inhaltsmodell
vorkommen. Im Fall des Elementes institution sieht das Inhaltsmodell wie folgt aus:
<!ELEMENT institution (#PCDATA %institution-elements;)*>
Parameter-Entities mit dem Suffix -model überschreiben ein komplettes Inhaltsmodell.
<!ENTITY % title-group-model
“(title, subtitle*, trans-title-group*,
alt-title*, fn-group?)”>
Ein Beispiel für eine Attributdeklaration:
<!ENTITY % issn-atts
“pub-type CDATA #IMPLIED
primary (yes | no) #IMPLIED
content-type CDATA #IMPLIED“>
NCBI Book Tag Set75
Anhand der Modulnamen lässt sich erkennen, ob es sich um ein Tag Set spezifisches Modul (Präfix bookcustom oder book) oder um ein Tag Suite Modul handelt.
Jedem DTD-Modul ist ein fpi (formal public identifier) zugeordnet.146
Modifikation147
Grundsätzlich gibt es die Möglichkeit neue Tag Sets aus den vorhandenen Modulen zu erstellen, Änderungen in den Modulen vorzunehmen oder neue Module
zu entwickeln. Die Verwendung von internen und externen Parameter-Entities
bildet die Grundlage für eine einfache, konsistente und flexible Modifizierung.
Um ein neues Tag Set zu erstellen benötigt man:
▶▶ die DTD (book.dtd) selbst, um neue top-level-Elemente zu definieren
▶▶ ein spezifisches Modul, das die anderen Module benennt (z. B. bookcustommodules)
▶▶ ein spezifisches Modul, das neue Klassen definiert und die vorgegebenen Klassen überschreibt (z. B. bookcustom-classes)
▶▶ ein spezifische Modul, das neue Element- und Klassenmixe beschreibt (z. B.
bookcustom-mixes)
▶▶ ein spezielles Modul, um Inhaltsmodelle zu überschreiben (z. B. bookcustommodels)
▶▶ ein Modul für neue Element- und Attributdeklarationen (z. B. bookpart) und
▶▶ beinahe alle Module der Tag Suite.148
Zuerst sollten die verschiedenen Element- und Attributkombinationen sowie Inhaltsmodelle mittels der Parameter-Entities gebaut werden. Anschließend werden
die Module gewählt, welche die benötigten Elemente deklarieren und zu einem
neuen Tag Set kombiniert.
In der Dokumentation findet sich eine sehr gute Anleitung zur Anpassung oder
Erstellung von Tag Sets. Sie beschreibt schrittweise das Vorgehen, z. B. mit welchen
Modulen man sich als erstes auseinandersetzen sollte, um die Zusammenhänge
und Strukturen der Module zu verstehen.
Alle XML-Elemente und Attribute sind in Kleinbuchstaben geschrieben. Bei der
Kombination mehrerer Wörter wird ein Bindestrich für eine bessere Lesbarkeit
eingesetzt.
Namen können in Zusammensetzungen abgekürzt vorkommen. Stehen die
Elemente allein, sind sie ausgeschrieben. Beispielsweise ist das Attribut display
ausgeschrieben, aber es wird als Attributkombination disp-level abgekürzt. Wieder andere Namen wie group sind nie abgekürzt; übliche Abkürzungen wie fig für
146 Vgl. NCBI: Implementing These Tag Sets – Tag Set and Suite Naming Conventions. File Naming
Conventions. http://dtd.nlm.nih.gov/book/tag-library, Zugriff am 16.08.09.
147 Vgl. NCBI: How To Build a New Custom Tag Set. http://dtd.nlm.nih.gov/book/tag-library,
148 Vgl. NCBI: Implementing These Tag Sets. http://dtd.nlm.nih.gov/book/tag-library, Zugriff am
04.08.09.
NCBI Book Tag Set76
figure sind hingegen immer abgekürzt. Typografische Hervorhebungen wie bold
und italic sind immer ausgeschrieben.149
Etwas verwirrend sind die beiden Attribute pub-type und publication-type. Das
Attribut pub-type beschreibt nur, ob es sich um eine Printausgabe oder eine elektronische Ausgabe o. Ä. handelt und hängt mit dem Datum der Veröffentlichung
zusammen. Das Attribut publication-type definiert die Publikationsform, z. B.
Buch, Zeitschrift, Brief, Bericht etc. Diese beiden können durch ihre ähnlichen
Namen jedoch leicht verwechselt werden.
Für die Hervorhebungen von Begriffen steht standardmäßig eine Reihe von Auszeichnungen zur Verfügung. Die Elemente sind in der emphasis.class gruppiert
und heißen: bold, italic, monospace, overline, overline-start, overline-end, roman,
sans-serif, sc, strike, underline, underline-start und underline-end.
Tabellen
Das Book Tag Set bietet die drei Tabellenmodelle CALS (von OASIS entwickelt),
XHTML und HTML. Standardmäßig verwendet das Tag Set das XHTML-Tabellenmodell. Das CALS-Modell wird dennoch mitgeliefert und kann an Stelle des
oder ergänzend zum XHTML-Modell eingesetzt werden. In der Dokumentation150
ist erklärt, wie das CALS-Tabellenmodell in die DTD eingebaut wird.
Besonderheiten
Auf dem FTP-Server151 finden sich Stylesheets für die Konvertierung von früheren Versionen zur aktuellen, nicht rückwärtskompatiblen Version 3.0. Außerdem
existiert ein Stylesheet (XSL-FO) für das Journal Publishing Tag Set inklusive
Dokumentation für die Benutzung und Erweiterung. Direkt für das Book und
Collection Tag Set existiert kein Stylesheet für die Verarbeitung.
Die Dokumentation bietet als kleinen Bonus die Erläuterung verschiedener
Auszeichnungsverfahren (tagging) für Schlüsselbegriffe, Referenzen, Grafiken,
Tabellen, Zugehörigkeiten und Alternativen.
Die Verschlagwortung ist zum Beispiel die Grundlage für die Erstellung eines
Indexes sowie das Wiederauffinden von Begriffen. Die Auflistung der Schlüsselwörter oder Themengruppen folgt als Gruppe und kann nach unterschiedlichen
Gesichtspunkten gegliedert sein, z. B. Personen oder Abkürzungen.152
Mehrere Begriffe kann man problemlos unter einem Schlagwort unterbringen.
Hierfür wird der Befehl compound-kwd und für die untergeordneten Begriffe der
Befehl compound-kwd-part genutzt.
Umfassend sind die Erläuterungen für die Referenzierung von Werken. Es werden
die verschiedensten Zitierweisen von Büchern, Autoren, Artikeln usw. dargestellt.
149 Vgl. NCBI: Implementing These Tag Sets – Tag Set and Suite Naming Conventions. XML Component Naming Conventions. http://dtd.nlm.nih.gov/book/tag-library, Zugriff am 04.08.09.
150 Vgl. NCBI/NLM: OASIS Open Exchange CALS Table Model (XML Version). http://dtd.nlm.nih.
gov/options/OASIS/tag-library/19990315/index.html, Zugriff am 12.12.09.
151 Zu finden unter: ftp://ftp.ncbi.nih.gov/pub/archive_dtd, Zugriff am 09.09.09.
152 Vgl. NCBI: Common Tagging Practice. http://dtd.nlm.nih.gov/book/tag-library, Zugriff am
04.08.09.
NCBI Book Tag Set77
Ein Überblick über die verschiedenen Zitierweisen der unterschiedlichen Texttypen geben die Beispiele in der Dokumentation.
<!DOCTYPE book PUBLIC „-//NLM//DTD Book DTD v3.0 20080202//EN“
„ftp://ftp.ncbi.nih.gov/pub/archive_dtd/books/3.0/“>
<book xml:lang=“de“>
<book-meta>
<book-id>Novel</book-id>
<book-title-group>
<book-title>The Adventures of Sherlock Holmes</book-title>
</book-title-group>
<series>Penguin Popular Classics</series>
<contrib-group>
<contrib contrib-type=“author“>
<name>
<given-names>Arthur Conan</given-names>
<prefix>Sir</prefix>
</name>
</contrib>
</contrib-group>
<publisher>
<publisher-name>Penguin Group</publisher-name>
<publisher-loc>
<addr-line>Penguin Books Ltd, 80 Strand, WC2R ORL, London
</addr-line>
</publisher-loc>
</publisher>
<isbn>978-0-140-62100-6</isbn>
<pub-date>
<year>1994</year>
</pub-date>
<permissions>
<copyright-statement>All rights reserved</copyright-statement>
<copyright-year>1892</copyright-year>
<copyright-holder>Penguin Group</copyright-holder>
</permissions>
</book-meta>
<body>
<book-part book-part-type=“chapter“ book-part-number=“1.“>
<book-part-meta>
<title-group>
NCBI Book Tag Set78
</title-group>
</book-part-meta>
<body>
<sec>
<p>To <bold>Sherlock Holmes</bold>she is always <italic>the</italic>
woman. I have seldom heard him mention her under any other name.
In his eyes she eclipses and predominates the whole of her sex. It was
not that he felt any emotion akin to love for Irene Adler. All emotions,
and that one particularly, were abhorrent to his cold, precise but admirably balanced mind. He was, I take it, the most perfect reasoning
and observing machine that the world has seen, but as a lover he would
have placed himself in a false position.</p>
</sec>
<sec>
<sec>
fashion.</p>
<sec>
<p>“Wedlock suits you,“ he remarked. „I think, Watson, that
you have put on seven and a half pounds since I saw you.“</p>
<p>“Seven!“ I answered.</p>
<p>“Indeed, I should have thought a little more. Just a trifle
more, I fancy, Watson. And in practice again, I observe. You
did not tell me that you intended to go into harness.“</p>
</sec>
</sec>
</sec>
</body>
</book-part>
</body>
</book>
http://docbook.org/schemas/5x
http://www.beuth.de
Das Copyright liegt bei der
ISO.
Vervielfältigung, Distribution
und Ähnliches sind nicht ohne
schriftliche Genehmigung von
ISO möglich.
Modifizierungen sind nach
den definierten Regeln der
ISO erlaubt.
Zugang/Erwerb
Lizenzbedingungen
Das Copyright haben verschiedene Unternehmen wie
O’Reilly & Associates, HaL
Computer Systems, OASIS,
Norman Walsh etc.
DocBook kann ohne Einschränkungen benutzt,
modifiziert und verbreitet
werden – vorausgesetzt, dass
die Informationen zum Copyright in jeder Datei angegeben
sind (siehe dazu den entsprechenden Text zu Beginn einer
DocBook-Datei).
Varianten von DocBook müssen auch als solche gekennzeichnet sein.
Organization for the Advancement of Structured Information Standards
http://www.oasis-open.org
International Organisation for
Standardization (ISO)
http://www.iso.org
Zuständigkeit
offener Standard, kostenlos
DocBook
ISO-Standard, kostenpflichtig,
ca. 200 Euro
ISO 12083
Art des Standards
und Kosten
Kriterium
6.1. Vergleichstabelle
6. Vergleich der DTDs
Das Copyright hat das TEI
Consortium.
Verwendung des Schemas
nur unter der GNU General
Public License.
Diese Lizenz erlaubt es, das
Schema zu kopieren, verteilen und zu ändern – immer
unter der Angabe, dass die
Dokumente der GNU Lizenz
unterliegen. Der Lizenztext
findet sich auf der TEI-Website.
http://sourceforge.net
Text Encoding Initiative
http://www.tei-c.org
TEI
Die NCBI Tag Sets sind
lizenzfrei für jedermann verwendbar.
Unternehmen, die aus dem
Tag Set ihr eigenes Schema
entwickeln wollen, können
dies ohne Genehmigung tun.
Um mit der Suite kompatibel
zu sein, sollte folgender Satz
in der DTD stehen: Created
from, and fully compatible with
the NLM Journal Archiving and
Interchange Tag Suite.
oder:
Based in part on, but not fully
compatible with the NLM Journal Archiving and Interchange
Tag Suite.
http://Schemata.nlm.nih.
gov/#id48861
National Center for Biotechnology Information (NCBI)
National Library of Medicine
(NLM)
http://Schemata.nlm.nih.gov/
NCBI Book Tag Set
Vergleich der DTDs79
ISO 12083:1994, letztes Update 1995 durch NISO
PDF:
http://www.techstreet.com/cgibin/detail?product_id=52643
Beim Kauf der ISO 12083
auch in gedruckter Form
erhältlich.
Schema für die Strukturierung
von Büchern, Artikeln und
Reihen. Der Standard ist bewusst allgemein gehalten und
muss für spezielle Anwendungen angepasst werden. Er
dient nur als Basis für andere
Projekte.
Viele Schemata wurden von
der ISO 12083 abgeleitet, z.
B. von Verlagen wie Elsevier,
Blackwell und Wiley.
DTD
Dokumentierung
Verwendung
Subsets
Schemasprachen
ISO 12083
aktuelle Version
Kriterium
DTD, W3C XML Schema,
Relax NG und Schematron
DocBook Lite (gekürzte Version von DocBook)
Simplified DocBook (sehr
kurze Version nur für Artikel)
Besonders geeignet für
Software- und technische
Dokumentationen, aber auch
für andere Publikationen wie
Artikel, Bücher und Reihen.
Online:
http://docbook.org/tdg5/
Buch: Walsh, Norman. DocBook – The Definitive Guide.
DocBook 5.0
DocBook
DTD, W3C XML Schema und
Relax NG
TEI Lite (gekürzte Version
von TEI)
TEI Tite (ergänzt TEI um typografische Elemente) uvm.
Schwerpunkt auf der originalgetreuen Texterfassung, weniger auf der Textkreation.
Markup für die rhetorischen
und linguistischen Textmerkmale, weniger für die typografischen.
Unterstützung aller Materialien, die für die Forschung von
Interesse sein könnten.
Online oder als PDF:
http://www.tei-c.org/Guidelines/
P5
Printversion auf Bestellung im
Omnipress E-Shop.
Guideline P5
TEI
DTD, W3C XML Schema und
Relax NG
Das Book Tag Set ist bereits ein Subset der Tag Sets
Archiving and Interchange und
Journal Publishing.
Vier Tag Sets für Artikel,
Bücher, Zeitschriften oder
Archivierung.
Spezialisiert auf Zeitschriftenartikel.
Auch für sehr kleine Dokumente wie Briefe oder Rezensionen geeignet.
Online:
http://Schemata.nlm.nih.gov/
book/tag-library
Außerdem Herunterladen
der Dokumentation für eine
Browseransicht (offline)
möglich.
Version 3.0
NCBI Book Tag Set
Das ISO-Schema ist nicht
modular aufgebaut und wenig
flexibel einsetzbar.
Struktur eines Dokumentes
und Deklaration der Elemente sind nicht separat getrennt.
Abschnittsunterteilungen
explizit mittels subsect1–6.
Nein
Modularität und Aufbau
XSL-Stylesheets
Tab. 8: Vergleich der DTDs
AAP-Tabellenformat
ISO 12083
Tabellenmodelle
Kriterium
Ja, unter: http://sourceforge.net/
projects/docbook/
DocBook trennt in strukturelles (dbhier) und inhaltsbezogenes (dbpool) Markup.
DocBook ist modular aufgebaut und damit sehr flexibel.
Bei der Abschnittsunterteilung wird entweder eine
explizite (sect1–5) oder eine
implizite (section) Unterteilung gewählt.
CALS (Standard), HTML,
XML Exchange
DocBook
Ja, unter: http://sourceforge.net/
projects/tei/files
Ein hohes Maß an Flexibilität
und Erweiterbarkeit von TEI
wurde u. a. durch die Auszeichnung verschiedener Ansichten (views) auf den Text;
alternative Auszeichnungen
für ein und denselben Text
sowie durch den modularen
Aufbau umgesetzt.
Je nach dem welches Modul
aktiv ist, stehen andere Elemente zur Verfügung.
Es ist nicht eindeutig festgelegt wie oft ein bestimmtes
Element in einem Inhaltsmodell vorkommen muss.
Abschnittsunterteilungen entweder explizit (div1–7) oder
implizit (div).
TEI-eigenes Modell (Standard), CALS, XHTML
TEI
Nur sehr eingeschränkt
unter: ftp://ftp.ncbi.nih.gov/pub/
archive_dtd/tools/
Alle vier Tag Sets sind modular aufgebaut. Die Struktur
des Book Tag Sets ist in der
Datei book festgelegt.
Es wird zwischen Modulen
für die gesamte Suite und den
buchspezifischen Tag Sets
unterschieden.
Die Abschnittsunterteilungen
sind nur implizit mittels secElement möglich.
XHTML (Standard), CALS
NCBI Book Tag Set
6.3 Zusammenfassung der Kriterien
Bei der Analyse der vier Schemata ISO 12083, DocBook 4.5, TEI und dem NCBI
Book Tag Set, stellte sich heraus, dass die ISO-Norm in ihrer Entwicklung und
Benutzerfreundlichkeit deutlich hinter den anderen drei DTD-Schemata liegt.
In den folgenden Abschnitten werden die wesentlichen Gemeinsamkeiten und
Unterschiede verglichen.
6.3.1 Zugänglichkeit
Alle DTDs außer der ISO sind kostenlos zugänglich. Dadurch haben die kostenlosen Standards bereits einen Wettbewerbsvorteil. Nicht jedes Unternehmen kauft
sich die ISO-Norm, um nur ein einziges Projekt zu realisieren.
Die ISO-Norm ist die älteste DTD. Sie wurde noch vor den 1990er Jahren entwickelt und bildet die Grundlage für andere Schemata. Jeder, der ein neues Schema
entwickeln wollte, musste sich zunächst mit der ISO-Norm auseinandersetzen. Anfang der 1990er Jahre kamen DocBook und TEI auf den Markt; erst mehr als zehn
Jahre später das NCBI Book Tag Set. Insofern war die ISO ein wichtiger und erster
Standard auf dem Gebiet der Schemata. Die anderen drei Schemata verdanken dem
ISO-Standard, dass sie ebenfalls als internationale Standards anerkannt wurden.
6.3.2 Dokumentierung
Die kostenlosen DTDs sind zumindest im Internet grundsätzlich sehr gut dokumentiert. Da DocBook eine populäre DTD ist, wurden einige Bücher darüber veröffentlicht. Diese sind jedoch meist eine identische Printausgabe der Onlineinhalte
(siehe: „DocBook – The Definitive Guide“; „DocBook XSL – The Complete Guide“).
Zu allen anderen Schemata finden sich keine Bücher. Die DTD-Entwickler bieten
jedoch ihre Dokumentation in gebundener Form an.
Unterschiede zeigen sich in der Aufbereitung der Dokumentationen: Die ISODokumentation ist ein weniger dynamisches PDF mit Lesezeichen. Positiv an
dieser Dokumentation sind die vielen Baumstrukturen zu allen Parameter-Entities und Elementen, die bei DocBook und TEI fehlen – aber sehr hilfreich wären.
Andererseits sind DocBook und TEI ähnlich gut dokumentiert. Die PDFs und
Onlinereferenzen sind sehr gut verlinkt. Es gibt Erklärungen zu den einzelnen
Parameter-Entities, Elementklassen, Attributen usw. Bei Elementen ist immer
angegeben in welchen Modulen sie auftreten, was die Kind- und Elternelemente
sowie die Attribute sind. Außerdem ist die Verwendung an einem Beispiel dargestellt. Das NCBI Book Tag Set erklärt zusätzlich das erweiterte Inhaltsmodell.
Besonders hilfreich sind bei diesem Schema die unterschiedlichen Ansichten der
Struktur als Baumdiagramm oder Kontexttabelle. Eine Verlinkung der ParameterEntities wäre vorteilhaft.
6.3.3 Entwicklung und die Umsetzung der Schemata in Modulen
Die ISO 12083 wird seit 1995 nicht mehr aktualisiert. Alle anderen drei Standards
werden kontinuierlich von Non-Profit Organisationen weiterentwickelt, korrigiert
und verbessert, das heißt sie reagieren auf aktuelle Entwicklungen wie die neue
Schemasprache Relax NG.
Jedes Schema ist bedingt durch seine Entstehungsgeschichte und seinen Zweck
unterschiedlich komplex bzw. aufgebaut: TEI ist wohl das komplexeste Schema mit
vier umfangreichen Standardmodulen. DocBook hat immerhin zwei umfangreiche
Module, während die NCBI Book Tag Set verhältnismäßig überschaubar bleibt.
Die ISO ist nicht in dem Maße modularisiert wie die anderen Standards, denn
alle Deklarationen stehen in einer einzigen fortlaufenden Datei.
Ferner unterteilt sich TEI nicht mehr in Base Tag Sets und Additional Tag Sets,
dafür sind die vier Hauptmodule (tei, header, core und textstructure) für viele Anwendungen unerlässlich. Diese definieren die grundlegenden Elemente, Klassen,
Makros und Datentypen sowie allgemeine Strukturelemente. In spezielle Module
ausgelagert wird alles andere, was nur für bestimmte Textarten (Wörterbuch, Gedicht, Drama, Transkription usw.) gilt. Außerdem sind die Element- oder Attributklassen, die jedes dieser Module mit sich bringt, in einer separaten Datei mit dem
Namen *.decl definiert. Dadurch lassen sich die Module sehr gut für verschiedene
Projekte zusammenfügen und die Struktur der DTD bleibt übersichtlich.
Ähnlich ist diese Stückelung beim NCBI Book Tag Set. Dort existieren Module, die
für alle Tag Sets benötigt werden sowie spezielle Module für Bücher. Die Module
sind einerseits nach verschiedenen Textarten (Artikel, Zeitschrift, Buch) unterteilt
und andererseits nach Strukturelementen (Abschnitt, Absatz, Satz, Link, Grafik,
Tabelle usw.).
Bei DocBook hingegen sind die Module eher allgemein gehalten und nicht so
fein unterteilt wie bei TEI oder dem Book Tag Set. DocBook trennt zwischen der
Struktur und dem Inhalt eines Textes. In DocBook ist es beispielsweise denkbar,
alle computerbezogenen Elemente in einem eigenen Modul zu deklarieren oder
andere Teile in weitere Module auszugliedern. Des Weiteren gibt es Simplified DocBook und DocBook Lite als Untermengen von DocBook, die sich eher auf Artikel
und Bücher konzentrieren.
Ähnlichkeiten zwischen Modulen jeder DTD existieren. Das DocBook-Modul
dbpool lässt sich mit dem TEI-Modul core und dem NCBI-Modul common vergleichen, denn dort sind alle Elemente deklariert, die auch von anderen Modulen
benötigt werden. Das DocBook-Modul dbhier kann man mit dem TEI-Modul
textstructure und dem NCBI-Modul book vergleichen.
Ein Nachteil modularer Systeme wie DocBook, TEI und dem NCBI Book Tag
Set ist zu Beginn der höhere Lernaufwand.153 Durch die Verwendung zahlreicher
Parameter ist nicht immer problemlos nachvollziehbar, in welchen Modulen
welche Elemente definiert sind und wie diese zusammenhängen.
Deshalb ist die Darstellung des erweiterten Inhaltsmodells hilfreich, wie bei TEI,
DocBook und dem NCBI Book Tag Set.
6.3.4 Umfang
Der Umfang an Modulen, Elementen und Attributen sagt wenig über das jeweilige
Schema aus. Entscheidend sind der logische Aufbau und die Nachvollziehbarkeit
durch den Anwender.
153 http://Schemata.nlm.nih.gov/book/tag-library, Zugriff am 02.08.2009.
Bei TEI liegt der Schwerpunkt auf einer originalgetreuen Wiedergabe von Texten. Viele Elementtypen dienen der Darstellung von semantischen Auszeichnungen, Randbemerkungen, dem Hinzufügen von allgemeinen Hinweisen, Informationen über das Aussehen des physischen Textes oder handschriftlichen Quellen.
Aus diesem Grund hat TEI wesentlich mehr Elemente als alle anderen Schemata.
DocBook ist ein DTD-Schema für technische Dokumentationen und besitzt
ebenfalls viele Elemente, jedoch etwa 200 weniger als TEI. Das NCBI Book Tag Set
besteht aus etwa der Hälfte an Elementen und Attributen wie TEI; der ISO-Standard setzt sich aus 100 Elementen weniger als das NCBI Book Tag Set zusammen.
Die Anzahl der Elemente soll nur einen visuellen Vergleich verdeutlichen. Es
wäre falsch zu schlussfolgern, dass das Schema mit den wenigsten Elementen am
Einfachsten zu verstehen sei. Außerdem müssen niemals alle Elemente gelernt oder
bekannt sein, diese können in den Referenzen nachgeschlagen werden.
6.3.5 Benutzerfreundlichkeit
Entscheidend für die Benutzerfreundlichkeit eines Schemas ist ebenso die Benennung der Elemente. Ist das System für den Anwender verständlich definiert, kann
er sich leichter in die Struktur hineinversetzen. Zudem ist es dadurch einfacher
eigene Elemente hinzuzufügen, die den Namenskonventionen der Schemata entsprechen. Kurze Namen der Elemente sind der Selbsterklärung weniger hilfreich
als längere Namen. Insgesamt verwenden alle vier Standards ähnliche Elementnamen bzw. ähnliche Abkürzungen für Namen, wie fig, ack, abbrev – teilweise aber
nur mit ein bis zwei Buchstaben mehr oder weniger: DocBook verwendet abbrev,
TEI benutzt abbr.
Unterschiedlich ist die Schreibweise bei der Zusammensetzung von Elementnamen. ISO verwendet nur kleingeschriebene Elementnamen. TEI verwendet
Groß- und Kleinschreibung (z. B. addName, className). DocBook verwendet
ausschließlich kleingeschriebene Namen, auch bei Elementzusammensetzungen.
Das NCBI Book Schema schreibt Elementzusammensetzungen klein und mit Bindestrich (z. B. article-title). Letztere sind besonders leicht lesbar.
Für das Auge ist es vorteilhaft, wenn die meisten Elementnamen eine mittlere Länge von sechs bis acht Buchstaben haben, wie dies bei allen vier Standards
der Fall ist. Hilfreich sind außerdem farbige Hervorhebungen durch den Editor.
Allgemein hängt es besonders von dem verwendeten XML-Editor ab, wie komfortabel sich XML-Dokumente erstellen und ändern lassen. Es empfiehlt sich der
Oxygen XML-Editor.
In Bezug auf die Namensgebung innerhalb der DTD benutzen alle Schemata Präund/oder Suffixe zur Kennzeichnung von Element- und Attributklassen, Inhaltsmodellen, Modulen und Mixes. Unterschiedlich ist hierbei deren Verwendung. Sie
sollten nicht so kurz sein wie bei der ISO 12083. Der ISO-Standard besitzt dadurch
zu wenig ausdrucksstarke Namen.
TEI wirkt durch die Verwendung von Prä- und Suffixen unübersichtlicher. Auf
Grund von Suffixen wie sequenceOptionalRepeatable sind die Namen teilweise
sehr lang und die DTD wirkt unüberschaubar. Die ausschließliche Verwendung
von Präfixen oder Sufffixen ist somit vorteilhafter, wie das bei dem NCBI Book
Tag Set und DocBook der Fall ist – beide verwenden nur Suffixe.
Des Weiteren spielt die Erfahrung des Anwenders in Bezug auf Abkürzungen in
Auszeichnungssprachen eine bedeutende Rolle. Anwendern mit Vorkenntnissen
in HTML wird es leichter fallen, Elemente wie tr, th, hr, ulink usw. zu verstehen
und intuitiv zu nutzen. Aus diesem Grund sollten Abkürzungen durch alle Schemasprachen hinweg konstant verwendet werden.
6.3.6 Typografische Auszeichnungen
Für typografische Auszeichnungen bieten nur die ISO 12083 und das NCBI Book
Schema die gängigen Hervorhebungen (fett, kursiv, Kapitälchen usw.), wobei das
Book Tag Set zusätzliche Markierungsmöglichkeiten bietet wie Durchstreichung,
Unterstreichung oder Monospace.
TEI hat nur das hi-Element für typografische Hervorhebungen. Wird jedoch das
Subset TEI Tite in das Schema eingebunden, stehen mehr Elemente zur Verfügung.
DocBook bietet kaum typografische Auszeichnungen, lediglich fett und kursiv,
es existieren keine Erweiterungen in dieser Richtung.
6.3.7 Möglichkeiten zur Anpassung der DTD an eigene
Anwendungen
Für die Modifizierung der Struktur benutzen alle Schemata ähnliche Mittel. In
erster Linie sind es die Parameter-Entities, die einen flexiblen modularen Aufbau gewährleisten. Obwohl die ISO 12083 keine Module besitzt, benutzt sie viele
Parameter-Entities, um sich die Wiederholungen von Ausdrücken zu sparen. Der
ISO-Standard kann nur unter Einhaltung genannter Kriterien modifiziert werden,
um weiterhin als ISO-Standard zu existieren.
Ein anderes Instrument sind die local.*-Klassen (DocBook) bzw. x.model-Klassen (TEI). Diese sind Platzhalter, in die neue Elemente zu bereits existierenden
Entities hinzugefügt werden können. In DocBook existieren weiterhin drei Platzhaltermodule für das Einfügen eigener Module. Mit dem Modul dbgenent können
beispielsweise eigene Entities deklariert werden.
Des Weiteren benutzen die Schemata eine eigene Ebene für alle Modifizierungen.
In DocBook sind es die customization layers und im NCBI Book Tag Set die customization modules. In TEI wird die TEI-Spezifikation erstellt, welche anschließend
die Module aufruft.
6.3.8 Besonderheiten der Schemata
In der Analyse wurden bereits die einzelnen Besonderheiten vorgestellt. Dabei
bieten TEI und DocBook den größten Leistungsumfang. Sie liefern Tools für die
Validierung sowie umfangreiche XSL-Stylesheets für die Weiterverarbeitung.
DocBook Wiki ist beispielsweise ein Tool für die Browserdarstellung von XMLDokumenten. TEI und DocBook sind standardmäßig im XML-Editor Oxygen
integriert.
ROMA ist ein Tool für die Erstellung der TEI-Schemata. Wichtig ist ebenfalls,
dass die Verwendung der Werkzeuge dokumentiert ist – wie bei DocBook und TEI.
Das NCBI Book Schema bietet nur ein XSL-FO Stylesheet für das Journal Publishing Tag Set und Stylesheets für die Konvertierung von Version 2.0 zu 3.0.
6.4 Zwischenfazit
Zusammenfassend wird festgehalten, dass die Wahl des Standards immer davon
abhängt, wofür das Schema benötigt wird. Grundsätzlich hat jede DTD ihren
eigenen Charakter: TEI hat einen „Forschungs- und Textaufbereitungscharakter“, DocBook einen technischen Software-Handbuch-Charakter und das NCBI
Book Tag Set einen naturwissenschaftlichen. Der Anwender muss für jedes Projekt entscheiden, mit welcher DTD die Struktur eines Buches am Eindeutigsten
beschrieben wird. Dabei muss zwischen den verschiedenen Kriterien abgewogen
werden: Welche Textart liegt vor? Bietet die DTD alle notwendigen Elemente?
Welche speziellen Module sind nötig etc.
Des Weiteren muss der Anwender entscheiden, ob und inwieweit Änderungen
in der DTD vorgenommen werden sollen. Beispielsweise eignet sich DocBook für
ein Projekt besonders gut, aber es fehlen die Elemente für typografische Auszeichnungen. Hierbei bietet es sich an, diese manuell in die DTD einzubauen und das
Schema zu modifizieren. Dabei spielen die Kriterien Modifikation, Modularität
und Dokumentierung der DTD eine bedeutende Rolle. Der Anwender sollte mit
Hilfe der Dokumentation in der Lage sein Änderungen selbst vorzunehmen. Der
Erfolg hängt im Wesentlichen von der Aufbereitung der Dokumentation des Standards ab. Die Dokumentation sollte so übersichtlich und verständlich wie möglich
gestaltet sein, da sie meist der erste Zugang zu einer Schemasprache ist. Außerdem
besitzen Faktoren wie die Unterteilung in Module und die Namensgebung einen
Einfluss darauf wie schnell die Strukturen der DTD insgesamt verstanden werden.
Bei der Modifikation kommt es darauf an die korrekten Prä- und Suffixe für die
Deklaration von Klassen, Mixes etc. zu kennen und zu wissen in welchem Modul
Anpassungen vorgenommen werden müssen.
87
III. UMSETZUNG DER BÜCHER IN XML UND
INDESIGN-IMPORT
1. Strukturanalyse der Bücher
Nachdem in dem vergangenen Kapitel ausführlich die vier DTD-Schemata ISO
12083, DocBook, TEI und NCBI Book Tag Set vorgestellt wurden, erfolgt in diesem Teil die praktische Umsetzung. Dazu werden zwei Bücher unterschiedlichen
Genres in ihrer Struktur analysiert und die wesentlichen Strukturelemente in
einem DTD-XML-Dokument ausgezeichnet. Die Dateien mit den erstellten XMLDokumenten liegen der Arbeit als CD bei.
Die Wahl der DTDs wird unter dem Aspekt des automatischen Satzes in InDesign betrachtet. Obwohl alle DTDs über Elemente für die Auszeichnung von
interaktiven XML-Dokumenten (Links auf Webseiten, Verweise in PDFs) verfügen, wurden die XML-Dokumente auf die Printausgabe beschränkt und Verweise
zwischen Fußnoten und bibliografischen Verweisen nicht weiter berücksichtigt.
Für ein Buch werden mindestens zwei als geeignet erachtete DTDs getestet. Eine
Auszeichnung mittels ISO 12083 wird nicht getestet, da die DTD-Dateien für diese
Arbeit nicht käuflich erworben wurden.
1.1 Vorstellung der Bücher
Als praktisches Beispiel und zum Test der Schemata dienen zwei verschiedene
Bücher; ein geisteswissenschaftliches Buch und ein medizinisches Fachbuch.
Die Bücher stellen jeweils unterschiedliche Anforderungen an eine DTD. Das
geisteswissenschaftliche Buch hat zahlreiche (lange) Fußnoten, Anmerkungen,
Exkurse, Gliederungen und Zitate. Es enthält unterschiedliche Schriftzeichen
(hier: Griechisch und Hebräisch). In diesem speziellen Fall treten viele Bibelverse,
-gesänge und -zitate mit teilweise mehreren Gliederungsebenen und Versnummern auf.
Das medizinische Fachbuch beinhaltet Aufzählungen, verschiedene Tabellen
und Abbildungen. Es enthält weiterhin Abkürzungen, Fachbegriffe (in Deutsch
und anderen Sprachen), Merksätze (Boxen) und eventuell Formeln.
1.2 Geisteswissenschaftliches Buch
Die folgende Tabelle zeigt die Struktur der Blockelemente des geisteswissenschaftlichen Buches. Es werden nur die Strukturelemente des Hauptteiles des Buches
berücksichtigt. Weitere Erklärungen zu den Elementen folgen nach der Tabelle.
Die Inline-Elemente werden anschließend aufgezählt.
In der Tabelle sind von oben nach unten die Hierarchieebenen eingetragen. Jeweils daneben steht die Überschrift, die das höchste Element einer Hiearchieebene
Strukturanalyse der Bücher88
darstellt. Unter jeder Überschrift sind die Strukturelemente aufgelistet, die jede
Ebene gemäß der Analyse des Buches enthalten kann.
Blockelemente
Hierarchieebene
Strukturelement
1
Ü0
Absatz, Vers, Zitat (griechisch)
Fußnote
2
Ü1
Absatz, Vers, Exkurs, Tabelle, Gliederung
der Autorin, Abbildung
Fußnote
3
Ü2
Absatz, Vers, Exkurs
Fußnote
4
Ü3
Absatz, Vers
Fußnote
Tab. 9: Blockelemente geisteswissenschaftliches Buch,
Überschriften (Ü0 bis Ü3)
Die Überschriften Ü0 und Ü1 sind normal gesetzt, Ü2 und Ü3 jeweils kursiv. Die
Überschriften sind nummeriert. Ü0 hat eine römische Nummerierung, alle anderen besitzen eine arabische Nummerierung.
Absatz
Ein Absatz enthält als einzige Blockelemente Fußnoten. Alle anderen Blockelemente stehen neben einem Absatz, zum Beispiel Exkurs, Vers oder Tabelle. Darüber
hinaus enthalten die Absätze des Buches zahlreiche Inline-Auszeichnungen, wie
in der unten abgebildeten Liste (Seite 89) aufgezählt.
Für das vorliegende Buch ist besonders auf die korrekte Wiedergabe der griechischen und hebräischen Zeichen zu achten. Bei der Verarbeitung des XMLDokumentes mit UTF-8 Kodierung sollten jedoch keine Probleme auftauchen.
Die Sonderzeichen müssen ausgezeichnet sein, damit beim Import in InDesign
gegebenenfalls ein eigenes Zeichenformat zugewiesen werden kann. Außerdem
lassen sich somit die Textstellen leichter identifizieren.
Vers
Optisch sind alle Verse im Buch mit einem linken und rechten Einzug sowie einem
Abstand davor und danach vom Text abgehoben. Die Verse stehen parallel zum
jeweiligen Absatz.
Im Text gibt es zahlreiche Verse unterschiedlicher Art: ohne und mit Nummerierung, eine Kombination aus Zahlen und Buchstaben, mit Fußnoten oder
ohne, Verse mit Bezügen zu Textstellen im Alten Testament sowie einzeilige und
mehrzeilige Verse. Inhaltlich handelt es sich nicht immer um Bibelverse, sondern
teilweise um Gesänge, Zitate, Übersetzungen oder Interpretationen. In den folgenden Abschnitten wird vereinfachend von Versen gesprochen.
Innerhalb der Verse kommen viele griechische oder hebräische Sonderzeichen
vor, die teilweise verschiedenartig unterstrichen sind – durchgezogen oder gestrichelt.
Weiterhin gibt es spezielle Gliederungen von Versen, die eine Interpretation
der Autorin darstellen. Es bietet sich an diese als Tabelle oder Liste darzustellen.
Zitat
Den Abschluss des Buches bildet ein griechisches, einzeiliges Zitat. Das Zitat ist
ähnlich einem einzeiligen Vers gesetzt.
Exkurs
Ein Exkurs kennzeichnet sich durch das vorangestellte Wort „Exkurs“ und einer
Überschrift wie Ü3. Er enthält Absätze, Verse und Fußnoten. Ein Exkurs unterbricht den Fließtext und steht neben dem Absatz auf einer Ebene. Deshalb erhalten Exkurse später eine andere Formatierung und müssen separat ausgezeichnet
werden. In den Exkursen finden sich alle Inline-Elemente des Absatzes wieder.
Tabelle
Das Buch enthält eine querseitige Tabelle, die mit einem DTD-Tabellenformat
umgesetzt werden muss. Die Tabelle besteht aus Tabellenüberschrift, Tabellenkopf
und Tabellentext. Weiterhin gibt es griechische Sonderzeichen im Tabellentext.
Fußnoten
Eine Fußnote besteht aus einem Referenzzeichen (Fußnotenzeichen) und einem
oder mehreren Absätzen. Der Absatz hat einen anderen Stellenwert als ein normaler Absatz unter einer Überschrift oder ein Absatz innerhalb eines Exkurses.
Die Fußnoten des vorliegenden Buches sind teilweise sehr umfangreich und
besitzen eine komplexe Inline-Struktur. Sie enthalten zahlreiche Sonderzeichen
und typografische Auszeichnungen.
Inline-Elemente
Folgende Inline-Elemente tauchen im Buch auf:
▶▶ Kapitälchen
▶▶ Kursivstellungen
▶▶ Unterstreichungen (durchgezogen oder gestrichelt)
▶▶ Hochstellungen (Versnummern)
▶▶ Abkürzungen
▶▶ Fußnotenzeichen
▶▶ in Fußnoten: Kapitälchen, Kursivstellungen, Hoch- und Tiefstellungen,
Abkürzungen, Griechisch, Hebräisch, Französisch
▶▶ Zeichensätze/Sonderzeichen: Bibelgriechisch, Hebräisch bzw. Hebraismen
Aus der Strukturanalyse des Buches ergeben sich folgende Anforderungen an die
DTD:
1. Sie muss mindestens vier Hierarchieebenen besitzen.
2. Auf jeder Ebene muss es möglich sein, die oben genannten Strukturelemente
unter Berücksichtigung der Hierarchien zu verwenden.
3. Die erwähnten Inline-Elemente und Fußnoten müssen für jedes Strukturelement verfügbar sein. Zum Beispiel Fußnoten in Versen, Zitaten und Exkursen.
4. Die DTD sollte ein für InDesign geeignetes Tabellenformat unterstützen – bestenfalls das CALS-Tabellenformat. Falls ein anderes Tabellenformat, z. B.
XHTML verwendet wird, sollte eine Transformation in das CALS-Modell
geprüft werden.
5. Die DTD muss geeignete Elemente für die Auszeichnung von Fremdsprachen
zur Verfügung stellen.
6. Eine umfassende Anzahl an Tags für die typografischen Auszeichnungen und
andere Inline-Elemente wie Abkürzungen sollte gewährleistet sein.
7. Die Auszeichnung der Elemente muss eindeutig sein, das bedeutet die Elementnamen sollten den Inhalten entsprechen.
1.2.3 Test: TEI
Es wird untersucht, ob die TEI-DTD allen Anforderungen gerecht werden kann.
Die Grafik zeigt wie das Dokument als TEI-XML gegliedert werden könnte.
div1
head
div2
div3
div4
Abb. 19: Aufbau des TEI-XML-Dokumentes
Begründung für TEI
Die erste Wahl fiel auf die TEI-DTD, weil sich der Inhalt des Buches bzw. das Genre
(geisteswissenschaftliches Buch) besonders dafür zu eignen scheint.
Die TEI-DTD hat standardmäßig nur das Element hi (highlight) für die typografische Hervorhebung und das Element emph für die sprachliche Betonung bzw.
Hervorhebung eines Wortes. Durch Einbinden der TEI-Tite-Spezifikation in die
TEI-DTD, stehen wesentlich präzisere Elemente für die typografische Auszeichnung zur Verfügung. Die folgenden Ausführungen beziehen sich immer auf die
TEI-DTD inklusive TEI-Tite Subset.
TEI hat Elemente für die Auszeichnung von Versen und sogar ein verse-Modul,
das unter Umständen hilfreich sein könnte. Vor Beginn der Arbeit wurde geprüft,
welche Module für die Auszeichnung des Buches in Frage kommen könnten. Generell kann man in TEI immer alle Module verwenden. Es bietet sich jedoch an
eine Auswahl je nach Dokumentanforderungen zu treffen, um so die Anzahl der
Elemente und Attribute zu reduzieren. Es wurden die Module tei, header, core,
text, benutzt.
Aufbau des XML-Dokumentes
Der Hauptteil des Buches gliedert sich in Kapitel und Abschnitte. In TEI gibt es
nur das Element div bzw. div1–div7 mit dem Attribut type für die Darstellung
unterschiedlicher Hierarchieebenen. Es gibt keine buchtypischen Elemente wie
book-part oder chapter.
Umgang mit Sonderzeichen
Im vorliegenden Buch sind die zahlreichen hebräischen und griechischen Sonderzeichen auffällig, die in der DTD entsprechend ausgezeichnet werden müssen. Dies
geschieht durch einen Hinweis auf eine andere Sprache im XML-Dokument als
die Standardsprache. Das globale TEI-Attribut xml:lang steht für jedes Element
zur Verfügung und wird zur Identifizierung der Sprache benutzt. Für das Taggen
der Sonderzeichen und Phrasen wird das Element foreign benutzt. Des Weiteren
gibt es die Möglichkeit, allgemeine Angaben über die verwendeten Sprachen im
TEI header durch die Elemente langUsage und language vorzunehmen.
Umgang mit Versen
Als weiterer wichtiger Punkt muss der Umgang der DTD mit Versen betrachtet
werden. Nicht alle DTDs bieten genügend Elemente für die Auszeichnung von
Versen. Bei TEI stellt das Modul core die Elemente l (line), lb (line break) und lg
(linegroup) zur Verfügung. Diese Elemente können nur für den Fall verwendet
werden, dass alle Verse neben einem Absatz stehen; innerhalb eines Absatzes
verbietet die DTD diese Elemente. Für das vorliegende Buch können jedoch alle
Verse als separate Einheit zum Absatz betrachtet werden.
Das überprüfte Modul verse wird nicht benötigt, weil es nur Elemente und Attribute für die Analyse von Gedichten enthält, wie zum Beispiel Rhythmus, Versmaß
und Zäsur. Diese Elemente sind für die vorliegenden Bibelverse nicht notwendig.
Die Gliederung der Autorin wird mit dem list-Element umgesetzt.
Bestimmte Anordnungen von Versen werden mit dem table-Element ausgezeichnet.
Umgang mit Exkursen
In TEI können Exkurse mit dem Element floatingText gekennzeichnet werden.
FloatingText ist eine Art separater Text mit einem eigenen front, body und backElement, das den Textfluss unterbricht. Für die Auszeichnung eines Exkurses ist
dieses Element bestens geeignet.
Umgang mit Fußnoten
Die Fußnoten werden innerhalb des Absatzes durch das Element note gekennzeichnet. Mittels verschiedener Attribute wie n (number), anchored, place lässt
sich das Fußnotenzeichen, die Verankerung im Text und die Positionierung im
Dokument bestimmen.
Umgang mit Abbildungen
Obwohl es im Buch keine Abbildungen gibt ist, wäre es für die Struktur sinnvoll
eine grafische Abbildung einzufügen.
In TEI werden Abbildungen mit dem Element figure oder graphic gekennzeichnet. Das figure-Element enthält neben der Abbildungsunterschrift und einer möglichen Beschreibung das graphic-Element, das die Quelle des Bildes enthält.
Das graphic-Element kann ebenso unabhängig vom figure-Element verwendet
werden, falls die Abbildung keine Bildunterschrift besitzt.
Umgang mit Tabellen
TEI verwendet standardmäßig ein eigenes Tabellenmodell in Anlehnung an das
ISO 12083 AAP-Tabellenmodell. Das TEI-Tabellenmodell hat die Elemente table
(mit den Attributen rows und cols), row und cell. Die Elemente row und cell können
die Attribute role, rows und cols enthalten. Je nachdem für welches Element (row
oder cell) diese Attribute verwendet werden, lassen sich damit Spalten, Zeilen und
Zellen verbinden. Das role-Attribut bestimmt, ob es sich um den Tabellenkopf
handelt (role=“label“) oder um eine Tabellenzelle (role=“data“).
Es ist nicht möglich, Text zu rotieren. Für die Umsetzung der querseitigen Tabelle ist dieses Tabellenformat dennoch ausreichend.
Außer der TEI-DTD wurde die Eignung von DocBook und dem NCBI Book Tag
Set für die Auszeichnung des Buches getestet und anschließend verglichen.
1.2.4 Test: DocBook
Unter Verwendung der DocBook-DTD sieht der grobe Aufbau des XML-Dokumentes wie in der folgenden Abbildung dargestellt aus. Nach der Grafik folgen
konkrete Angaben zu den jeweils verwendeten Auszeichnungstags für die zuvor
definierten Strukturelemente.
chapter
title
sect1
sect2
sect3
Abb. 20: Aufbau des DocBook-XML-Dokumentes
Der Hauptteil des Buches gliedert sich in Kapitel und Abschnitte. Eine Verschachtelung ist in DocBook entweder durch die Elemente part (= Einleitung),
chapter (= 1.), sect1 (= 1.1) oder durch chapter (= Einleitung), sect1 (= 1.), sect2
(= 1.1) möglich. In der Umsetzung wurde letztere Variante bevorzugt, damit die section-Verschachtelung mit der Nummerierung übereinstimmt, d. h.
1. entspricht sect1, 1.1 entspricht sect2 usw. Im Buch wird zwischen einer römischen
und einer arabischen Nummerierung unterschieden. Demzufolge entsprechen die
römischen Zahlen der Kapitelnummer (chapter) und die arabischen Zahlen der
Abschnittsnummer (section).
Die Markierung der Textpassagen mit griechischen und hebräischen Sonderzeichen wurde durch das Element foreignphrase mit dem Attribut lang vorgenommen.
Umgang mit Versen
Die DocBook DTD ist typischerweise nicht für die Auszeichnung von Versen geeignet. Trotzdem ist es eine Überlegung die Verse als eine Art Liste oder Tabelle
abzubilden. Dazu muss gewährleistet sein, dass die Elemente Fußnoten enthalten
dürfen und nicht zwingend einen Titel benötigen.
Die in Frage kommende Liste ist die simplelist. Für Verse ohne Nummerierung
eignet sich auch die itemizedlist ohne Aufzählungszeichnen. Für die Darstellung
von einigen Versen kann das CALS-Tabellenmodell genutzt werden. Die Elemente
heißen table und informaltable, mit und ohne Überschrift.
Bibelzitate über mehrere Zeilen, die links und rechts eingezogen sind, können
in Docbook durch das Element blockquote vom Haupttext abgehoben werden.
Die Gliederung der Autorin wurde ebenfalls mit einer Liste (variablelist) umgesetzt.
Umgang mit Exkursen
Exkurse können ebenfalls durch das Element blockquote gekennzeichnet werden.
Tauchen in einem Exkurs zusätzlich mehrzeilige, beidseitig eingerückte Verse oder
Zitate auf, wird das Element blockquote verschachtelt.
In DocBook heißt das Element für Fußnoten footnote. Es enthält einen oder
mehrere Absätze, die den Fußnotentext beinhalten. Normalerweise erfolgt die
Nummerierung der Fußnoten automatisch. Mit dem Attribut label kann man das
Fußnotenzeichen beeinflussen und die automatische Nummerierung überschreiben. Das Fußnotenzeichen wird bei der Transformation automatisch vom System
an der Stelle des Verweises und vor dem Fußnotentext eingefügt.
In DocBook gibt es die Elemente figure und informalfigure. Während figure einen
Titel besitzt, bezeichnet informalfigure eine Abbildung ohne Titel. Mit dem Attribut label lässt sich hier ebenso die automatische Nummerierung überschreiben.
Weitere Attribute von Abbildungen sind pgwide (0 = die Abbildung wird in die
Spalte eingepasst; 1 = die Abbildung geht über die gesamte Breite der Seite) und
float (0 = verankert; 1= verschiebbar).
Umgang mit Tabellen
DocBook verwendet standardmäßig das CALS-Tabellenformat, mit dem sich die
querseitige Tabelle ohne Probleme darstellen lässt. Näheres dazu im Abschnitt
2.2.1, Seite 106.
Wird das Book Tag Set verwendet, gliedert sich das Buch in die Containerelemente
body, book-part, book-part-meta sowie body und sieht ähnlich der folgenden Grafik
aus:
body
book-part
book-part-meta
title
body
sec
sec
sec
Abb. 21: Aufbau des Book Tag Set XML-Dokumentes
Die Verwendung der Elemente book-part und sec ist nicht eindeutig voneinander
abgegrenzt. Beide Elemente können ein Kapitel darstellen. Für das vorliegende
Buch wurde das Element book-part für die römische Nummerierung und das
Element sec für die arabische Nummerierung gewählt.
Die griechischen und hebräischen Sonderzeichen können mit dem Element
named-content ausgezeichnet werden. Das Element erlaubt jedoch nicht das
xml:lang-Attribut. Deshalb wurde das Attribut content-type benutzt.
Umgang mit Versen
Das Book Tag Set hat die zwei Elemente verse-group und verse-line für die Auszeichnung von Gedichten u. Ä. Leider erlaubt verse-line keine Fußnoten, so dass es
nur für Verse ohne Fußnoten verwendbar ist. Für Verse mit Fußnoten muss man
auf das list-Element zurückgreifen. Für einfache Verse kann auch das Element
disp-quote innerhalb oder neben einem Absatz benutzt werden.
Mit dem Element array werden innerhalb des Textflusses tabellenähnliche Inhalte ausgezeichnet, die aus einfachen Spalten und Zeilen bestehen. Meist besitzen
solche Elemente einen Abstand zum vorherigen und nachfolgenden Absatz und
sind im Text verankert. Innerhalb von array wird entweder das tbody-Element von
XHTML-Tabellen benutzt oder das graphic-Element, um den Inhalt als Abbildung
einzufügen. Im XML-Dokument wurde array insbesondere für die Darstellung
der Übersetzungen von Versen benutzt.
Ähnlich wie bei TEI wurde die Gliederung der Autorin mit zwei verschachtelten
list-Elementen umgesetzt.
Umgang mit Exkursen
Das Element disp-quote eignet sich für die Hervorhebung von kurzen Texten oder
Zitaten vom Haupttext. Dieses Element kann sowohl für die Exkurse, als auch für
einfache Verse ohne Fußnoten verwendet werden. In jedem Fall deutet das Element
disp-quote daraufhin, dass die entsprechende Textpassage vom umfließenden Text
abgehoben wird.
Die Fußnoten sind durch das Element fn gekennzeichnet. Es enthält das Element
label für das Fußnotenzeichen und p für den Fußnotentext.
Das NCBI Book Tag Set hat die vier Elemente graphic, graphic-inline, fig (figure)
und fig-group für Abbildungen. Für das vorliegende Buch sind vor allem die beiden Elemente graphic und fig interessant. Das Element graphic wird verwendet,
wenn das Bild keine weiteren Informationen wie Titel, Abbildungsnummer, Beschreibung usw. enthält. Graphic enthält lediglich den Pfad zum Ort des Bildes
und kann bei Bedarf ein label und eine Bildunterschrift enthalten.
Das Element fig umfasst Abbildungen oder Textelemente mit Bildunterschrift,
wie z. B. Listen, Gleichungen oder Zitate. Oftmals wird demzufolge das Element
graphic (Link zum Bild) innerhalb von fig (Informationen rund um das Bild) benutzt. Ein Element fig kann zum Beispiel drei Elemente graphic enthalten.
Mit dem Attribut position (Werte: anchor, float, margin) wird festgelegt, ob die
Abbildungen im Text an einer bestimmten Stelle verankert sind oder mit dem
Text zum Beispiel auf die nächste Seite übergehen.
Grundsätzlich lässt sich das geisteswissenschaftliche Buch mit allen drei DTDs
auszeichnen, jedoch mit unterschiedlicher Eindeutigkeit. Keine der getesteten
DTDs erfüllt die gestellten Anforderungen zu 100 Prozent. Bei allen drei DTDs
muss teilweise bei der Wahl der Elemente improvisiert werden.
TEI
Die TEI-DTD hat sehr starke Elemente wie die div1–div7 Verschachtelung, floatingText für Exkurse, foreign für Fremdsprachen im Text und lg und l für Verse. Unter
Zuhilfenahme des Subsets TEI-Tite sind in TEI alle benötigten Inline-Elemente
für die typografische Auszeichnung vorhanden. Ein kleiner Nachteil von TEI ist,
dass die DTD nur ein sehr einfaches Tabellenformat verwendet und die Einbindung des CALS-Modells nicht dokumentiert und daher schwierig ist. Da TEI ein
einfaches Tabellenformat verwendet, wird die gesamte Formatierung in InDesign
mit Tabellenformaten vorgenommen – beispielsweise die Textausrichtung. Diese
neutrale Auszeichnung in TEI kann folglich auch vorteilhaft sein. Alle zweispaltigen Verse können als Tabelle dargestellt werden. Für komplexere Gliederungen
von Versen bieten sich entweder Tabellen oder verschachtelte Listen an.
DocBook
Die DocBook-DTD ist eine starke DTD, weil sie das CALS-Tabellenformat standardmäßig unterstützt und weiterhin verschiedene Listenarten sowie das Element
blockquote für Exkurse und das Element foreignphrase für Abweichungen von der
Standarddokumentsprache anbietet. Mit DocBook kann man ein Buch sehr gut
in Kapitel und Abschnitte unterteilen. Nachteilig sind die fehlenden Elemente für
die typografische Auszeichnung, die für das getestete Buch benötigt werden. In
DocBook werden alle Hervorhebungen mit dem Element emphasis markiert. Dadurch kann später nicht mehr unterschieden werden, ob es sich um Kapitälchen
oder eine Unterstreichung handelt.
Ein weiterer Nachteil ist die erzwungenermaßen uneinheitliche Auszeichnung
von Versen (simplelist, informaltable, blockquote, variablelist).
NCBI Book Tag Set
Im Gegensatz zu DocBook beinhaltet das NCBI Book Tag Set standardmäßig alle
Elemente für die typografische Auszeichnung. Ähnlich wie bei TEI hat das Tag
Set die Elemente verse-group und verse-line für Verse und ein Element array für
tabellenähnliche Inhalte (zweispaltige Verse). Für bestimmte Versstrukturen muss
auf das list-Element zurückgegriffen werden, denn vers-line darf keine Fußnoten
enthalten. Für Exkurse gibt es das Element disp-quote. Das Tag Set ist weniger
restriktiv als TEI in Bezug auf das Inhaltsmodell eines Absatzes.
Abstriche müssen bei dieser DTD bei der Auszeichnung der Fremdsprachen gemacht werden und beim Tabellenformat. Es wird das XHTML-Modell verwendet.
Außerdem konnten nicht alle Elemente einheitlich ausgezeichnet werden (dispquote für Verse und Exkurse).
Entscheidend für die Wahl der DTD ist, dass alle Elemente, die vom gewöhnlichen Textfluss abweichen, durch eine eindeutige und einheitliche Auszeichnung
gekennzeichnet sind und auf der richtigen Hierarchieebene stehen. Dadurch kann
XSLT die Abschnitte entsprechend anders behandeln als den Fließtext und beim
Import in InDesign verschiedene Absatzformate zuweisen.
Ein weiteres Kriterium für die Wahl der DTD sind die vorhandenen Stylesheets.
Sowohl TEI als auch DocBook liefern XSL-Stylesheets für die Verarbeitung des
XML-Dokumentes; das Book Tag Set dagegen nur sehr eingeschränkt.
Das Fazit lautet, dass sich für das geisteswissenschaftliche Buch folglich am
besten die TEI-DTD inklusive TEI-Tite eignet.
1.3 Medizinisches Fachbuch
Die folgende Tabelle zeigt die Strukturelemente eines medizinischen Fachbuches.
Dabei wird nur der Hauptteil des Buches berücksichtigt.
In der folgenden Tabelle sind die Blockelemente zusammengefasst. Weitere Erklärungen zu den Elementen folgen nach der Tabelle. Die Inline-Elemente werden
anschließend aufgezählt.
In der Tabelle sind von oben nach unten die Hierarchieebenen angegeben. Unter
jeder Überschrift sind die Strukturelemente dargestellt, die jede Ebene gemäß der
Analyse des Buches enthalten kann.
Blockelemente
Hierarchieebene
Strukturelement
1
Ü1
Autor(en), Abstract, Fußnote
2
Ü2
Absatz, Box_2, Box_3, Abbildung, Tabelle
Aufzählung (Bullets)
3
Ü3
Absatz, Box_1, Box_2, Box_3, Abbildung,
Tabelle
Aufzählung (Bullets, Numbers)
4
Ü4
Absatz, Box_1, Box_2, Abbildung, Tabelle
5
Ü5
Absatz, Box_2
Aufzählung (Bullets)
2–5
Zusammenfassung (Beiträge 1, 4, 5, 6, 8)
Absatz, Box_1, Abbildung, Tabelle
Anhang
Literatur (Anhang zum Beitrag)
Bibliografie
Tab. 10: Blockelemente
Überschriften (Ü1 bis Ü5)
Jeder Beitrag hat eine Beitragsüberschrift (Ü1) und gegebenenfalls weitere Unterüberschriften (Ü2 bis Ü5). Die Überschriftenhierarchien Ü1 bis Ü3 sind mit
arabischen Ziffern nummeriert, Ü4 und Ü5 sind ohne Nummerierung.
In Überschriften gibt es fette und kursive Auszeichnungen. Weiterhin ist es
möglich, dass Überschriften Fußnoten und Sonderzeichen enthalten.
Autor
Dieses Strukturelement bezieht sich nur auf die Beitragsüberschrift und kennzeichnet den Autor oder die Autoren eines Beitrages.
Absatz
Ein Absatz kann Verweise auf Tabellen, bibliografische Verweise und verschiedene
Aufzählungen beinhalten, die entweder innerhalb eines Absatzes vorkommen oder
aus diesem herausgelöst sind. Alle Inline-Elemente finden sich im Strukturelement
Absatz wieder.
Abstract
Ein Abstract ist wie ein Absatz, das heißt er kann sämtliche Absatz- und Zeichenformate enthalten. Lediglich durch die Kennzeichnung eines Absatzes als Abstract
ist es möglich ihm später eine andere Formatierung zuzuweisen.
Abbildungen
Zu einer Abbildung zählen die Abbildung selbst und die Abbildungsunterschrift.
Abbildungen können Fotos, Grafiken oder Formeln sein.
Tabellen
Die Tabellen des Buches sind unterschiedlich aufgebaut. Hier muss ein Tabellenformat gefunden werden, dass die Darstellung der verschiedenen Tabellen unterstützt. Zu dem Strukturelement Tabelle gehören eine Tabellenüberschrift, ein
Tabellenkopf, eventuell eine Tabellenvorspalte, Tabellentext und Tabellenfußnoten.
Aufzählungen
Aufzählungen können ein Bestandteil von Absätzen, Tabellen und Boxen sein
oder gleichberechtigt neben einem Absatz stehen. Die Aufzählungszeichen sind
entweder Bullets oder eine Nummerierung.
Boxen
Im Buch gibt es drei unterschiedliche Boxenarten: Box_1 entspricht einem Merksatz, Box_2 einem Hinweis und Box_3 vermittelt Hintergrundwissen. Jede Box
kann eine Boxüberschrift und einen oder mehrere Absätze enthalten. Ein weiteres
Strukturelement der Boxen sind Aufzählungen mit Bullets. Die Boxen enthalten
teilweise die Inline-Elemente kursiv, fett, tiefgestellt, Abkürzungen, bibliografische
Verweise, Verweise auf Tabellen und Sonderzeichen (Pfeil; Kleiner-gleich-Zeichen).
Die Boxen stehen immer neben einem Absatz als separate Einheit mit Textbezug.
▶▶ Box_1 = Boxüberschrift, Absatz_Box
▶▶ Box_2 = Boxüberschrift, Absatz_Box oder Absatz_Box mit Aufzählung_Box
(Bullets)
▶▶ Box_3 = Boxüberschrift, Absatz_Box, Aufzählung_Box (Bullets)
Zusammenfassung
Die Zusammenfassung enthält die Elemente Absatz, Tabellen, Abbildungen und
Boxen. Sie steht am Ende des Beitrages und fasst die Hierarchieebenen Ü2 bis Ü5
zusammen.
Literatur
Unter der Überschrift „Literatur“ finden sich die ausführlichen bibliografischen
Angaben zum jeweiligen Beitrag. Das Literaturverzeichnis steht am Ende jedes
Beitrages nach der Zusammenfassung und kann als eine Art Anhang zum jeweiligen Beitrag betrachtet werden. „Bibliografie“ enthält keine spezifischen Auszeichnungen.
Fußnoten
Eine Fußnote besteht aus einem Referenzzeichen (Fußnotenzeichen) und einem
Absatz. Der Absatz hat einen anderen Stellenwert als ein normaler Absatz unter
einer Überschrift. Im Buch kommt nur eine Fußnote in einer Überschrift vor. Es
ist möglich, dass Tabellen Fußnoten oder Legenden besitzen.
Inline-Elemente
Folgende Inline-Elemente tauchen im Buch auf:
▶▶ fett
▶▶ Kursivstellungen
▶▶ Spitztitel
▶▶ Verweise auf Abbildungen und Tabellen
▶▶ bibliografische Verweise
▶▶ Abkürzungen
▶▶ Hoch- und Tiefstellungen (chemische Formeln)
▶▶ Fußnotenzeichen
▶▶ Sonderzeichen
Aus der Strukturanalyse des Buches ergeben sich folgende Anforderungen an die
DTD:
1. Sie sollte mindestens fünf Hierarchieebenen bieten.
2. Auf jeder Ebene muss es möglich sein die oben genannten Strukturelemente
unter Berücksichtigung der Hierarchien zu verwenden.
3. Die erwähnten Inline-Elemente und Fußnoten müssen für jedes Strukturelement verfügbar sein, zum Beispiel Fußnoten in Überschriften und Tabellen.
4. Um Tabellen abzubilden sollte die DTD bestenfalls das CALS-Tabellenformat
unterstützen.
5. Die Auszeichnung der Elemente sollte immer eindeutig sein.
Begründung für das NCBI Book Tag Set
Die erste Wahl fiel auf das Book Tag Set, weil sich der Inhalt des Buches bzw. das
Genre (medizinisches Fachbuch) besonders dafür zu eignen scheint. Nach einer
ersten Überprüfung der vorhandenen Elemente, könnte diese DTD alle benötigten
Strukturelemente für die Auszeichnung bieten. Darunter zählen Boxen, Tabellen,
typografische Auszeichnungen und Formeln.
In der folgenden Grafik ist der Aufbau des XML-Dokumentes zu sehen. Die
gestrichelt gekennzeichnete sec ist der Abschnitt „Zusammenfassung“, der nur in
einigen Beiträgen vorkommt.
body
book-part
book-part-meta
title
back
body
sec
sec
sec
sec
sec
Abb. 22: Aufbau des Book Tag Set XML-Dokumentes
Die erste Überlegung war es, jeden Beitrag des Buches entweder mit dem sec-Element oder dem book-part-Element auszuzeichnen. Die Entscheidung fiel letztlich
auf das book-part-Element, weil dieses das benötigte Element abstract erlaubt.
Innerhalb von sec wäre es nur möglich das Element p für einen normalen Absatz
zu verwenden. Demzufolge hätte der Abstract keine spezielle Auszeichnung. Das
book-part-Element besitzt weiterhin den Vorteil, dass es mit zahlreichen Metainformation angereichert werden kann sowie einen body (Hauptteil) und ein backElement (Anhang) umfasst.
Obwohl das Element abstract meist nur ein bis zwei Absätze umfasst, erlaubt
das NCBI Book Tag Set, falls diese Elemente notwendig sein sollten weitere Strukturelemente wie Tabellen, Abbildungen, Boxen, Aufzählungen usw.
Das NCBI Book Tag Set besitzt die vier Elemente graphic, graphic-inline, fig (=
figure) und fig-group für Abbildungen. Für das vorliegende Buch sind vor allem
die beiden Elemente graphic und fig interessant. Das Element graphic sollte verwendet werden, wenn das Bild keine weiteren Informationen enthält wie Titel,
Abbildungsnummer, Beschreibung usw. Graphic enthält lediglich den Pfad zum
Ort des Bildes sowie bei Bedarf ein label und eine Bildunterschrift.
Das Element fig umfasst Abbildungen oder Textelemente, die eine Bildunterschrift besitzen, wie z. B. Listen, Gleichungen oder Zitate. Oftmals wird demzufolge das Element graphic innerhalb von fig benutzt. Ein Element fig kann z. B. drei
Elemente graphic enthalten.
Mit dem Attribut position (Werte: anchor, float, margin) wird festgelegt, ob die
Abbildungen im Text an einer bestimmten Stelle verankert sind oder mit dem
Text zum Beispiel auf die nächste Seite übergehen.
Umgang mit Formeln
Für chemische Formeln gibt es chem-struct-wrap, ein umfassendes Element für
chemische Formeln, Gleichungen, Reaktionen usw. mit Überschrift, Text und
Abbildungen. Das Element chem-struct enthält die eigentliche chemische Formel
als Text oder Bild.
Für mathematische Formeln heißt das Element disp-formula. Es eignet sich für
die Darstellung von mathematischen Gleichungen, Ausdrücken und Formeln.
Dabei kann es die Formel als Text oder Bild enthalten. Möglich sind ASCI II,
MathML, TeX und LaTeX. Für mathematische Formeln innerhalb des Textes gibt
es das Element inline-formula.
Umgang mit Boxen
Alle drei Boxarten werden im Book Tag Set mit dem Element boxed-text gekennzeichnet. Das Attribut content-type bestimmt dabei, ob es sich um eine Box_1,
Box_2 oder Box_3 handelt.
Umgang mit Verweisen
Das Element xref wird für jede Art von internen Verweisen verwendet. Auf jedes
Element mit einem Attribut id kann verwiesen werden. Das Attribut ref-type
enthält die Information um welche Art von Verweis es sich handelt – z. B. einen
bibliografischen Verweis oder eine Abbildung. Um auf eine ID eines Elementes
(Tabelle, Abbildung) zu verweisen, wird das Attribut rid (= reference to id) im
Verweis verwendet. ID und rid müssen den gleichen Wert besitzen.
Umgang mit Tabellen
Das NCBI Book Tag verwendet standardmäßig das XHTML-Tabellenmodell. Das
CALS-Tabellenmodell lässt sich zwar integrieren, aber nicht ohne Weiteres. Ein
zusätzlicher Namespace und Änderungen in den Modulen sind dazu notwendig.
Das Element table-wrap ist ein Container für die gesamten Informationen zu
einer Tabelle. Es umfasst die Tabellenüberschrift, die Tabelle selbst sowie Tabellenfußnoten und Beschreibungen. Das Element caption erlaubt zudem mehrzeilige
Tabellenüberschriften. Für Fußnoten oder die Legende einer Tabelle eignet sich
sehr gut das table-wrap-foot Element.
Bibliografische Angaben
Ein kleines Literaturverzeichnis steht jeweils am Ende (back) eines Beitrages und
ist mit dem Element ref-list gekennzeichnet. Das Element ref-list ist ein Container
für mehrere ref-Elemente, welche die einzelnen bibliografischen Angaben enthalten. Darin wird zwischen element-citation und mixed-citation unterschieden.
Element-citation darf nur aus anderen Elementen in einer willkürlichen Reihenfolge bestehen. Mixed-citation erlaubt Interpunktionen und Leerzeichen zwischen
den Elementen, die ebenfalls in einer willkürlichen Reihenfolge auftreten können.
Im XML-Dokument wurde element-citation verwendet, um später die Interpunktionszeichen und Abstände individuell und layoutabhängig festzulegen.
1.3.4 Test: DocBook
Des Weiteren wird getestet inwieweit sich DocBook für die Auszeichnung des
medizinischen Fachbuches eignet. DocBook hat eine wesentlich flachere Struktur als das NCBI Book Tag Set, da es nicht in front, body und back unterteilt. Die
Grafik verdeutlicht dies.
chapter
chapterinfo
title
abstract
sect1
sect1
bibliography
sect2
sect3
sect4
Abb. 23: Aufbau des DocBook-XML-Dokumentes
Die einzelnen Beiträge des Buches können entweder als Kapitel oder Artikel betrachtet werden. Beide Inhaltsmodelle sind in DocBook annähernd identisch. Sie
unterscheiden sich nur in Metainformation und Anhang etwas voneinander. Für
das medizinische Fachbuch wurde eine Unterteilung in Kapitel gewählt, um den
Buchcharakter zu unterstreichen.
DocBook verwendet in ähnlicher Art und Weise wie das Book Tag Set die beiden Elemente figure und graphic: Das Element figure enthält ein leeres Element
graphic, das den Verweis auf die Bildquelle beinhaltet. Das Attribut float für das
Element figure kann die Werte 0 oder 1 annehmen. Null bedeutet, dass das Bild
an der Position im Text verankert ist und Eins bedeutet, dass das Element je nach
Textfluss verschoben werden darf.
Das Element graphic wird in Zukunft (Version 5.0) durch das Element mediaobject ersetzt. Dieses Element umfasst Bilder, Audiodateien oder Videos. Des Weiteren kann mediaobject eine alternative Textbeschreibung des Bildes enthalten, die
vorher nicht möglich war.
Umgang mit Formeln
In DocBook existieren keine speziellen Elemente für die Auszeichnung von chemischen Formeln. Folglich können diese nicht separat ausgezeichnet werden.
Umgang mit Boxen
In DocBook gibt es fünf Auszeichnungen für Ermahnungen, wie sie typischerweise in technischen Dokumentationen (z. B. Bedienungsanleitungen) vorkommen. Diese sind: caution, warning, note, important und tip. Damit lassen sich die
drei unterschiedlichen Boxen wie folgt vom Text abheben: Box_1 bekommt das
Element important zugewiesen, Box_2 das Element tip und Box_3 das Element
note. Diese Zuordnung entspricht in etwa der jeweiligen Bedeutung der Box.
Umgang mit Verweisen
Das Element xref ist ein leeres Element mit den Attributen linkend und endterm.
Linked verweist aus dem Text heraus auf ein Element (z. B. Abbildung, Tabelle).
Das Element, auf das verwiesen wird, muss in seinem id-Attribut den gleichen
Wert wie das linkend-Attribut von xref enthalten, damit eine Verbindung besteht.
Das System generiert automatisch den Text, der an der Stelle des Verweises steht.
Endterm verweist auf ein Element, dessen Inhalt an der Stelle des Verweises
verwendet werden soll.
Des Weiteren lässt sich der xref-Inhalt durch ein xreflabel-Attribut am Element
(Abbildung, Tabelle) beeinflussen. Das xreflabel-Attribut legt fest, welcher Text
an der Stelle des Verweises erscheint und überschreibt den Text, der automatisch
erzeugt werden würde (siehe DocBook XML-Dokumente).
Für bibliografische Verweise im Text gibt es das Element citation, welches ein
xref-Element enthalten kann. Außerdem existiert das Element biblioref für Querverweise.
Umgang mit Tabellen
DocBook verwendet standardmäßig das CALS-Tabellenmodell, mit dem sich alle
Arten von Tabellen auszeichnen lassen. Näheres dazu im Abschnitt 2.2.1, Seite 106.
Bibliografische Angaben
Das Literaturverzeichnis zum Beitrag ist im Element bibliography gruppiert. Wie
beim NCBI Book Tag Set erfolgt die Wahl zwischen bibliomixed (mit Interpunktionen) und biblioentry (ohne Interpunktionen). Für das Buch wurde das Element
biblioentry gewählt.
Die Auszeichnung bibliografischer Angaben ist etwas komplizierter als bei dem
Book Tag Set. Durch das Element biblioset mit dem Attribut relation werden die
bibliografischen Angaben in artikel- und journalbezogene Angaben unterteilt.
Damit existieren zwei title-Elemente in der Bibliografie: ein Element für den Titel
des Artikels und ein Element für den Titel der Zeitschrift.
Prinzipiell lässt sich sowohl das NCBI Book Tag Set als auch DocBook für die
Umsetzung des Buches in XML verwenden. Die Vor- und Nachteile sollen im
Folgenden zusammengefasst werden.
NCBI Book Tag Set
Der inhaltliche Schwerpunkt der DTD liegt in der Auszeichnung naturwissenschaftlicher Bücher. Deshalb passen viele Elemente sehr gut zu den Strukturelementen des vorliegenden Buches, sowohl namentlich als auch inhaltlich. Dazu
zählen boxed-text, table-wrap, table-wrap-foot, chem-struct und die zahlreichen
Inline-Elemente für die typografische Auszeichnung.
Das Tag Set gliedert den Hauptteil des Buches sehr übersichtlich in book-partmeta, body und back. Die Struktur gliedert sich tiefer als bei DocBook.
Etwas nachteilig ist die Tatsache, dass das CALS-Tabellenmodell nicht standardmäßig eingebaut ist. Eine Transformation des XHTML-Tabellenmodells in CALS
muss noch geprüft werden, falls das CALS-Modell nicht erfolgreich in die DTD
eingebaut werden kann. Ein anderer Nachteil sind die fehlenden XSL-Stylesheets
für die Weiterverarbeitung. Es gibt lediglich ein Stylesheet für die Journal Publishing DTD für Version 2.3, auf das man unter Umständen zurückgreifen könnte.
Für die aktuelle Version 3.0 ist ein Stylesheet in Arbeit.
Der XML-Workflow in InDesign104
DocBook
Der inhaltliche Schwerpunkt der DTD liegt in der Auszeichnung von Softwarehandbüchern. Deshalb entsprechen einige Elemente nicht genau den Strukturelementen des Buches und es muss improvisiert werden. Im Falle der Boxen
bietet DocBook nur sehr spezielle Elemente für Warnungen, die in Büchern oft mit
entsprechenden Symbolen versehen sind. Durch die Verwendung der Elemente
important, tip und note ist eine Alternative zu boxed-text (NCBI) gefunden.
In DocBook gibt es keine Elemente für die Kennzeichnung von chemischen
und mathematischen Formeln. Des Weiteren fehlen in DocBook mehrere InlineElemente für die typografische Auszeichnung. In DocBook kann nur das Element
emphasis für jegliche Hervorhebung benutzt werden.
Die DTD hat eine wesentlich flachere Struktur als das Book Tag Set und gliedert
sich übersichtlich in Kapitel.
Das Positive an DocBook ist das CALS-Tabellenmodell, das ohne NamespacePräfix verwendet wird und die Übersichtlichkeit der Tabellen erleichtert. Ein
weiterer Vorteil sind XSL-Stylesheets, die für die Transformation des DocBook
XML-Dokumentes nutzbar sind.
Insgesamt eignet sich das NCBI Book Tag Set besser für die Auszeichnung eines
medizinischen Fachbuches. Ausschlaggebend dafür sind die Möglichkeiten der
eindeutigen typografischen Auszeichnung sowie der Auszeichnung von Boxen,
Tabellen und Formeln.
2. Der XML-Workflow in InDesign
Zu Beginn des Abschnittes werden kurz die verwendeten Arbeitsmittel (XMLEditor und InDesign) vorgestellt. In den danach folgenden Punkten wird konkret
der InDesign XML-Workflow sowie das Zusammenspiel von XML, DTD und
InDesign beleuchtet. Zuerst wird die Problematik vorgestellt und anschließend
ein Lösungsweg gezeigt. Als Testdokumente werden die zuvor erstellten XMLDateien benutzt. Im Rahmen des Importtestes der XML-Dokumente in InDesign
werden entstandene Schwierigkeiten aufgezeigt und Hinweise für das Beheben
von Problemen gegeben.
2.1 Arbeitsmittel
2.1.1 XML-Editoren
Prinzipiell lassen sich XML-Dokumente in jedem Texteditor erstellen. Der manuelle Aufwand für das Schreiben der Tags und die Syntaxfehler sind jedoch sehr
hoch. Aus diesem Grund empfiehlt es sich einen kostenlosen oder kommerziellen
XML-Editor zu verwenden, welcher die Unterstützung für die richtige Schreibweise von Elementen und Attributen bietet. In den meisten Fällen sind diese Editoren
eine komplette Entwicklungsumgebung für XML inklusive Stylesheet-Erstellung
und -Validierung.
Einige bekannte Editoren heißen Altova XML-Spy, XMetal, Oxygen, XML Writer und Arbortext Epic. Im Rahmen der vorliegenden Arbeit wird der kostenlose,
javabasierte Texteditor jEdit inklusive Xerces-Parser genutzt. Durch die Einbindung verschiedener Plugins lässt sich jEdit als XML-Editor konfigurieren.154 Er
ist ausreichend, wenn es um die Erstellung, Validierung und die XSLT-Transformation von Dokumenten geht. Beispielsweise können XML-Dokumente in der
übersichtlichen Baumansicht betrachtet oder eine DTD auf der Grundlage eines
XML-Dokumentes erstellt werden.
Oxygen ist ein kommerzieller XML-Editor, der alle gängigen Schemata (Relax
NG, W3C Schema, Schematron, DTD etc.) unter Verwendung des Saxon XSLTProzessors verarbeitet. Oxygen macht bereits bei der Eingabe von Tagnamen Vorschläge für Elemente, die gemäß DTD erlaubt sind. Komfortabel ist die Arbeit
mit Oxygen, weil der Editor beim Ändern eines Starttags gleichzeitig den Endtag
anpasst. Dadurch wird die Erstellung eines wohlgeformten XML-Dokumentes
unterstützt.
Der Editor bietet standardmäßig eine Unterstützung für TEI- und DocBookDTDs. Das bedeutet beispielsweise, dass die Erklärungen zu den Elementnamen
direkt im Editor angezeigt werden und beim Erstellen eines neuen Projektes Templates zur Verfügung stehen.
2.1.2 InDesign
Für den Importtest von Dokumenten wird die aktuelle InDesign Version CS4 verwendet. In InDesign besteht die Möglichkeit, ein InDesign-Dokument als XML zu
exportieren oder ein vorhandenes XML-Dokument in InDesign zu importieren.
Die grundlegenden Werkzeuge für die Arbeit mit XML in InDesign sind das
Strukturfenster (Ansicht  Struktur  Struktur einblenden) sowie die Tagpalette
(Fenster  Tags). Außerdem ist die Skriptpalette (Fenster  Automatisierung 
Skripten) für automatisches Taggen wichtig.
Im Strukturfenster wird die XML-Struktur des Dokumentes angezeigt. Sowohl
aus der XML-Struktur als auch aus dem getaggten InDesign-Dokument heraus
wird das jeweilige Strukturelement per Rechtsklick („Gehe zu Objekt“ oder „In
Struktur markieren“) im Strukturbaum oder Dokument angezeigt. Im Strukturfenster sind weiterhin eine Reihe von Funktionen möglich, wie zum Beispiel das
Laden einer DTD, das Hinzufügen und Entfernen von Elementen und Attributen
sowie das Überprüfen der Struktur.
Tags werden entweder manuell per Anlegen neuer Tags, automatisch durch das
Laden einer DTD oder automatisch durch das Taggen eines InDesign-Dokumentes
per Skript in die Tagpalette geladen.
2.2 Tabellenformate
Da nicht jede DTD als Standard das CALS-Tabellenmodell von OASIS verwendet,
wird an dieser Stelle ein Vergleich mit dem XHTML-Tabellenmodell vorgenommen. Es ist zu überprüfen, ob alle Elemente des XHTML-Modells in das CALSModell passen. Erst dann ist eine Transformation von XHTML in CALS möglich.
154 Vgl. Trieloff, Lars. DocBook-XML. S. 263.
2.2.1 OASIS Open Exchange CALS Table Model (XML)
Die Abkürzung CALS steht für: Continous Acquisition and Life-Cycle Support.155
Die Organisation OASIS ist für die Erhaltung des Standards zuständig.
In DocBook wird für Tabellen standardmäßig das CALS-Tabellenmodell verwendet. Mit diesem Modell lassen sich nahezu alle denkbaren Tabellen darstellen.156 Dabei wird jede Zelle einzeln definiert und in Zeilen zusammengefasst.
Das Modell erlaubt eine Rotation des Textes oder der gesamten Tabelle. Eine Verschachtelung von Tabellen ist durch das Element entrytbl möglich. Das Element
table ist ein Containerelement für den Tabellenkopf (thead), einen oder mehrere
Tabelleninhalte (tgroup) und den Tabellenfuß (tfoot).
Die Elemente des Modells heißen: table, tgroup, colspec, spanspec, thead, tfoot,
tbody, row, entrytbl und entry. Im Einzelnen enthalten die Elemente zusätzlich zu
den common attributes in DocBook folgende Attribute:
155Vgl. http://www.originalab.se/advent/html/de/prd_3B2_tables_cals-in-depth.html, Zugriff
am 17.11.09.
156 Vgl. Wittenbrink, Heinz; Köhler, Werner et al.: XML, S. 319f.
entry
entry-t bl
x
x
x
x
char
x
x
x
x
x
charoff
x
x
x
x
x
x
x
colname
x
cols
colsep
row
spanspec
x
thead,
tfoot,
tbody
colspec
align
Attribut

table
tgroup
Element 
x
x
x
x
x
colnum
x
colwidth
x
frame
x
label
x
x
x
morerows
x
x
nameend
x
x
x
namest
x
x
x
orient
x
pgwide
x
rotate
x
rowsep
x
shortentry
x
x
spanname
tabstyle
x
x
x
x
x
x
x
x
tgroupstyle
tocentry
x
x
x
x
valign
x
x
x
Tab. 11: Elemente und Attribute des CALS-Modells
2.2.2 XHTML
Das XHTML-Tabellenmodell wurde im Zuge von XML entwickelt und basiert
auf HTML-Tabellen. Es ist ein Format um HTML-Tabellen in XML abzubilden.
abbr
th
td
thead,
tfoot,
tbody, tr
Attribut

col
colgroup
Element 
table
Bei der Entwicklung von XHTML wurde besonders auf die Kompatibilität mit
Webbrowsern Wert gelegt. 157
Die Elemente des Modells heißen: table, col, colgroup, thead, tfoot, tbody, tr, th
(table header cell), und td (table data cell). Im Einzelnen enthalten die Elemente
folgende Attribute:
x
align
x
x
axis
x
x
border
x
cellpadding
x
cellspacing
x
char
x
x
x
charoff
x
x
x
colspan
x
content-type
x
frame
x
x
x
headers
x
x
id
x
rules
x
x
x
x
rowspan
x
scope
x
span
x
style
x
summary
x
valign
width
x
x
x
x
x
x
x
x
Tab. 12: Elemente und Attribute des XHTML-Modells
157 Vgl. SELFHTML: Unterschiede zwischen XHTML und HTML. http://de.selfhtml.org/html/
xhtml/unterschiede.htm#xml_deklaration, Zugriff am 17.11.09.
2.2.3 Zuordnung der Elemente
XHTML
CALS
table
table
colgroup
tgroup
col
colspec
thead
thead
tfoot
tfoot
tbody
tbody
tr
row
td, th
entry
Tab. 13: Zuordnung der Elemente von XHTML zu CALS
Aus der Zuordnungstabelle wird ersichtlich, dass sich das XHTML-Modell in das
CALS-Modell übertragen lässt. Ein Teil der Elementnamen ist sogar identisch.
Das Element colgroup ist ein Containerelement für die Spaltenbeschreibung und
kann in das CALS-Element tgroup transformiert werden. Die Elemente th und td
entsprechen einem entry-Element in CALS, weil in diesem nicht zwischen Zellen
des thead und tbody unterschieden wird. In CALS heißen alle Zellen entry.
Einige wichtige Attribute wie align, valign, char, charoff und frame können ebenfalls von dem einen in das andere Modell übernommen werden. Das rules-Attribut
ist beispielsweise ähnlich dem colsep- und rowsep-Attribut in CALS.
Werden beide Tabellenformate gleichzeitig in einer DTD verwendet, benötigt ein
Tabellenmodell einen zusätzlichen Namespace und ein Namespace-Präfix.
2.3 Von XML zu InDesign
2.3.1 Problematik
Bei der Erstellung eines XML-Dokumentes in einem XML-Editor prüft ein Parser,
ob ein Dokument wohlgeformt (entspricht den XML-Regeln) und valide (entspricht einer DTD) ist. Für den Import des XML-Dokumentes in InDesign kommt
als weiteres Kriterium hinzu, dass InDesign die XML-Struktur verstehen muss.
Die Frage ist hierbei: Wie muss das Ausgangs-XML aussehen, damit InDesign
die Struktur versteht und richtig interpretiert? Erst dann ist man in der Lage mit
einem entsprechenden XSLT-Stylesheet die Transformation von Ausgangs-XML
zu InDesign-XML vorzunehmen.
2.3.2 Herangehensweise
Um die eben dargestellte Problematik zu lösen, hat sich folgendes Vorgehen als
geeignet erwiesen:
Das InDesign-Dokument für ein bereits gesetztes Buch wird in InDesign geöffnet und per Skript automatisch getaggt. Die Tagnamen entsprechen dabei den
Namen der Absatz- und Zeichenformate des Dokumentes, da jedes Textelement in
der Regel ein Absatz- und/oder Zeichenformat hat. Für Textteile ohne besondere
Formatierung definiert InDesign automatisch den Tagnamen Ohne.
Die InDesign-XML-Struktur kann im Strukturfenster angesehen werden. Anschließend wird das getaggte InDesign-Dokument als XML exportiert. Als Output
wird ein InDesign XML-Dokument erzeugt, welches im XML-Editor geöffnet
werden kann. Das somit erhaltene InDesign XML-Dokument wird benötigt, um
festzustellen welche Strukturanforderung InDesign an ein XML-Dokument stellt,
zum Beispiel wie eine Tabelle dargestellt wird. Es dient als Referenzdokument.
Parallel dazu wird in einem XML-Editor ein XML-Dokument auf der Basis der
Buchstruktur erstellt. Dieses XML-Dokument bildet die Struktur des Buches ab
unter Berücksichtigung der jeweiligen DTD. Es ist das so genannte XML-Ausgangsdokument für den XML-Import in InDesign. Ziel ist das XML-Ausgangsdokument mit der von InDesign geforderten XML-Struktur in Übereinstimmung zu
bringen. Dazu muss die Struktur beider XML-Dokumente analysiert und verglichen werden oder es müssen zumindest die Anforderungen von InDesign bekannt
sein. In diesem Fall wurden diese Anforderungen mittels Test (Trial and Error)
herausgefunden. Dazu wird das valide XML-Dokument so oft in InDesign importiert bis alle Fehlermeldungen beseitigt sind. Erst dann kann davon ausgegangen
werden, dass InDesign die Struktur versteht. Welche Probleme konkret auftreten,
wird im Abschnitt 2.3.5 erläutert. Zunächst folgen Erläuterungen gesetzt dem Fall
eines erfolgreichen und problemlosen XML-Importes.
2.3.3 Validierung mittels DTD
Ein valides und wohlgeformtes XML-Dokument ist Voraussetzung für den weiteren Arbeitsablauf. Es gibt zwei Stellen im Workflow, das XML-Dokument gegen
eine DTD zu validieren: 1. Im XML-Editor, vor dem InDesign-XML-Import.
2. Nach dem XML-Import in InDesign. Beide Möglichkeiten sollten genutzt werden, denn ein im Editor valides Dokument bedeutet noch nicht, dass InDesign
die Struktur versteht und als gültig bezeichnet.
Angenommen das XML-Dokument ist im Editor wohlgeformt und valide, wird
anschließend über die Funktion „XML importieren“ getestet, ob sich das XMLDokument in InDesign importieren lässt. Bei dem Import ist zu beachten, dass
InDesign keine Public-IDs in den XML-Dokumenten versteht und das System-IDs
oft eine Fehlermeldung über ein fehlendes Modul anzeigen. In anderen Fällen wird
die DTD nur unvollständig geladen. Dies ist bei modular aufgebauten DTDs der
Fall. Um diese Probleme zu umgehen, ist es am günstigsten die DTD noch einmal
manuell in InDesign aufzurufen. Dazu wird im Strukturfenster der Befehl „DTD
laden“ gewählt. Die DTD ist damit in InDesign eingebettet. Bei Änderungen in
der DTD muss diese neu geladen werden.
Über den Befehl „DTD Optionen“ wird das Element ausgewählt, ab dem validiert werden soll. In den meisten Fällen ist dies das Wurzelelement. Nachdem
InDesign das XML-Dokument validierte erscheint entweder die Meldung „Keine
bekannten Fehler“ oder eine Fehlermeldung. Meistens schlägt InDesign Lösungen
zu dem Beheben des Problems vor. Kleine Anpassungen, wie das Hinzufügen,
Ändern, Entfernen und Verschieben von Attributen und Elementen, können direkt in InDesign vorgenommen werden.
2.3.4 Formatzuordnung158
Ausgangsbasis ist zunächst ein valides XML-Dokument, das den Anforderungen
der InDesign XML-Schnittstelle entspricht. Parallel dazu sind in InDesign die
benötigten Absatz-, Zeichen-, Tabellen- und Zellenformate definiert.
An dieser Stelle existieren zwei Möglichkeiten für die automatische Formatzuordnung.
Tags zu Formaten zuordnen
Damit InDesign die XML-Tags automatisch den Formatvorlagen zuordnet, sollten
die Namen der Formatvorlagen mit den Namen der XML-Elemente übereinstimmen (Groß- und Kleinschreibung beachten).
Nach erfolgreichem XML-Import werden alle XML-Elemente im Strukturfenster aufgelistet. Mit dem Befehl: „Tags zu Formaten zuordnen“ werden die Elemente
mit dem passenden Format versehen. An dieser Stelle zeigt sich, warum man die
Elementnamen und Formatvorlagennamen identisch benennen sollte: Mit Klick
auf den Button „Nach Name zuordnen“ wird mühsames manuelles Auswählen
umgangen.
Diese Variante funktioniert nur, wenn jedes Element genau einem Kontext in
dem XML-Dokument entspricht. Ansonsten ist keine eindeutige Zuordnung gewährleistet. Beispielsweise würde ein title-Element auf unterschiedlichen Hierarchieebenen demzufolge immer gleich formatiert werden – weil nicht geprüft wird,
wo dieses Element in der Struktur steht.
Zuordnung mittels Namensraumattribut
Eine andere Möglichkeit der Formatzuordnung ist das Anreichern der XMLStruktur mit den InDesign-Namensraumattributen für Formate. Für die vier
Formatvorlagenarten gibt es vier Namensraumattribute für Elemente:
▶▶ aid:pstyle für Absatzformate
▶▶ aid:cstyle für Zeichenformate
▶▶ aid5:tablestyle für Tabellenformate
▶▶ aid5:cellstyle für Zellenformate
Beispielsweise könnte ein Element folgendermaßen mit einem Absatzformat angereichert werden:
<title aid:pstyle=“Buchtitel“>Handbuch der Printmedien</title>
<title aid:pstyle=“Überschrift_1“>Offsetdruck</title>
Wird ein mit diesen Informationen angereichertes XML-Dokument in InDesign
importiert, weist InDesign automatisch während des Importes die Absatzformate zu.
Mit dieser Variante können alle title-Elemente in Abhängigkeit ihrer Hierarchieebene ein eigenes Format erhalten. Das bedeutet, dass ein title-Element innerhalb
eines table-Elementes eine andere Formatierung bekommt, als ein title-Element
innerhalb einer sect1.
In ähnlicher Weise wie mit Text verfährt InDesign mit Tabellen. Damit
InDesign die Tabellenstruktur korrekt umsetzt und formatiert, wird die Tabelle
158 Vgl. Technical Reference, Adobe InDesign CS3 and XML. S. 18ff.
mit Attributen angereichert, welche Informationen zum Aussehen der Tabelle
enthalten. Die Attribute sind in der folgenden Tabelle zusammengefasst:
Attribute
Value
Description
aid:table
table
cell
Specifies a table-type element. A value of table indicates the container table element; a value of cell
indicates a cell element.
aid:trows
Numeric
Specifies the number of rows in the table. Used
only in the Table element.
aid:tcols
Numeric
Specifies the number of columns in the table. Used
only in the Table element.
aid5:tablestyle
Text
Specifies the table’s style. Equivalent to the pstyle
attribute for paragraphs.
aid:theader
Empty
If present, the theader attribute indicates that the
current cell is part of a table header row.
aid:crows
Numeric
Specifies how many rows the current cell spans.
The default is 1.
aid:ccols
Numeric
Specifies how many columns the current cell spans.
The default is 1.
aid:ccolwidth
Numeric
Specifies the width, in points, of the current cell.
aid5:cellstyle
Text
Specifies the style of the current cell. Similar to the
cstyle attribute for character styles.
aid:tfooter
Empty
If present, the tfooter attribute indicates that the
current cell is part of a table footer row.
Tab. 14: InDesign Tabellenattribute159
Die Listen mit den Absatz- und Zeichenformaten für das geisteswissenschaftliche
Buch und das medizinische Fachbuch befinden sich in dem Gliederungspunkt
2.4, ab Seite 114.
2.3.5 Probleme und Anmerkungen zum InDesign-XML-Import
Public und System IDs
Wie bereits erwähnt versteht InDesign grundsätzlich keine Public IDs und hat
Probleme mit dem Umgang von System IDs bei modular aufgebauten DTDs.
Die Public und System IDs können lediglich für die Validierung im XML-Editor
benutzt werden. Vor dem XML-Import in InDesign werden diese besser auskommentiert. Andernfalls erscheinen zahlreiche Warnungen über Module, die nicht
aufgerufen werden können.
Deshalb wird die DTD noch einmal manuell nach dem Import in InDesign
aufgerufen und das Dokument validiert, wie im Abschnitt 2.3.3 beschrieben.
159 Vgl. Technical Reference, Adobe InDesign CS3 and XML. S. 21
Prozessor und Parser
Nach der Validierung wird InDesign in den meisten Fällen das XML-Dokument
für ungültig erklären. Einerseits kann das XML-Dokument tatsächlich ungültig
sein, andererseits fehlen InDesign wohlmöglich Informationen, um die Struktur
zu verstehen.
Um auszuschließen, dass das Dokument ungültig ist, sollten der XML-Editor
und InDesign den gleichen XSLT-Prozessor und Parser für die Überprüfung der
XML-Dokumente verwenden. Von der Wahl des XSLT-Prozessors hängt auch der
Parser ab, der das XML-Dokument validiert. InDesign und der Oxygen XMLEditor benutzen beide Saxon. Bei der Verwendung unterschiedlicher XSLT-Prozessoren kann es passieren, dass ein XML-Dokument im Editor als fehlerfrei gilt,
aber beim Import in InDesign Fehler gemeldet werden.
InDesign Namensraum
Um ein XML-Dokument mit Informationen über Absatz-, Zeichen-, Tabellenund Zellenformate anzureichern, hat InDesign einen eigenen Namensraum. Dieser heißt aid (Adobe InDesign) für Absatz- und Zeichenformate und aid5 für
Tabellen- und Zellenformate. Für einen erfolgreichen XML-Import in InDesign
sollte das Namensraumattribut im XML-Dokument nach der Validierung im
XML-Editor ergänzt werden. Die Namensräume werden im Wurzelelement des
XML-Dokumentes wie folgt deklariert:
xmlns:aid=“http://ns.adobe.com/AdobeInDesign/4.0/“
xmlns:aid5=“http://ns.adobe.com/AdobeInDesign/5.0/“
Ebenso sollte der Namensraum der jeweiligen DTD im Wurzelelement deklariert
werden. Dadurch weiß InDesign, dass alle Elemente ohne Präfix automatisch zu
dem Namensraum der DTD gehören.
Wird nach erfolgreichem XML-Import gegen eine in InDesign geladene DTD
validiert, sollte es keine weiteren Fehlermeldungen geben, außer dass das xmlnsAttribut nicht in der DTD deklariert ist. Möglichkeiten das Problem zu beheben
sind das Hinzufügen dieses Attributes zur DTD oder den Fehler zu ignorieren,
sofern das Dokument zuvor gegen eine DTD validiert wurde.
Tabellen
Ein Problem ergibt sich möglicherweise beim Importieren von Tabellen. Es kann
passieren, dass InDesign die Tabellen gar nicht importiert. Das hängt wiederum
mit dem Namensraum zusammen. Sobald alle Namensräume angegeben wurden,
tritt dieses Problem nicht mehr auf. Außerdem muss geprüft werden, welches
Tabellenformat im XML-Dokument verwendet wird.
InDesign kann mit zwei Tabellenmodellen umgehen; alle anderen müssen zuvor
in eines der beiden transformiert werden. Das so genannte InDesign-Tabellenmodell verwendet ein relativ simples Tabellenformat mit den Elementen table und
cell. Im table-Element steht die Anzahl der Spalten und Zeilen. Innerhalb dieses
Elementes wird jede Zelle einzeln definiert. Das System muss erkennen wie viele
Zellen in eine Zeile passen.
InDesign akzeptiert weiterhin das CALS-Tabellenmodell und transformiert dieses bei XML-Import in das InDesign-Tabellenmodell, sofern die Funktion „CALSTabellen als InDesign-Tabellen importieren“ in den Importoptionen angewählt ist.
2.4 Liste der Absatz- und Zeichenformatvorlagen
XSLT bildet das Bindeglied zwischen XML-Ausgangsdokument und InDesign
XML-Dokument. Ein entsprechendes XSLT-Stylesheet muss das XML-Ausgangsdokument in den Namensraum von InDesign transformieren und dabei mit allen
notwendigen Informationen anreichern. Wie die Attributdefinitionen aussehen,
wurde im vorherigen Abschnitt besprochen. Die Regeln für die Formatierung der
Elemente sind in den folgenden Abschnitten am Beispiel der Bücher zusammengefasst. Die Regeln entstanden aus der theoretischen Überlegung wie XSLT die
Struktur abfragen könnte, um jedem XML-Element ein eindeutiges InDesignFormat zuzuordnen. Die Erstellung eines XSLT-Dokumentes ist nicht Gegenstand
dieser Arbeit.
Die Namen der Absatz- und Zeichenformate sind den Element- und Attributnamen der DTD angeglichen. Dadurch lassen sich die Strukturelemente einfach
in der DTD auffinden und identifizieren.
2.4.1 Geisteswissenschaftliches Buch
In der unten abgebildeten Tabelle sind die Regeln für die XSLT-Transformation
zusammengefasst und den Formatnamen gegenüber gestellt. Eine verbale Formulierung der Regeln folgt nach der Tabelle.
TEI-Element
InDesign-Formatvorlage
Blockelement
Absatzformat
Überschriften
div1 + head @type=part + p
head_0
[div1 + head @type=part] + [div2 + head
@type=chapter]
head_0_1
div2 + head @type=chapter + p
head_1
[div2 + head @type=chapter] + [div3 + head
@type=chapter]
head_1_2
head_2
[div3 + head @type=chapter] + [div4 + head
@type=chapter]
head_2_3
head_3
Absatz
p (div1–4)
p
head + p
p_woi
l+p
p_woi
[list @type=simple + item] + p
p_woi
[list @type=ordered + item ]+ p
p_woi
TEI-Element
Blockelement
Absatzformat
Exkurse
floatingText
---
floatingText @type=exkurs + head
floatingText_head
floatingText @type=exkurs + head + p
floatingText_p_woi
floatingText @type=exkurs + p + p
floatingText_p
floatingText @type=exkurs + p +[l] + p
floatingText_l_single
floatingText @type=exkurs + p+[l + l]
floatingText_l_first
floatingText @type=exkurs + l + l
floatingText_l_middle
floatingText @type=exkurs +[l] + p
floatingText_l_last
floatingText @type=exkurs +p + [quote]
floatingText_quote_ibs
floatingText @type=exkurs +p + [quote] + p
floatingText_quote_last_ibs
Verse
lg
---
l
l_single
p+l
l_first
l+l
l_middle
l+p
l_last
p + quote
quote_ibs
p + quote + p
quote_last_ibs
Tabellen
table
---
table + head
table_title
row @role=label+ cell
table_header
row
---
row @role=data + cell
table_text
Listen
p + [list @type=simple + item] + p
listS_item_single
p + [list @type=simple + item + item]
listS_item_first
list @type=simple + item +item
listS_item_middle
[list @type=simple + item] + p
listS_item_last
TEI-Element
Blockelement
Absatzformat
p + [list @type=ordered + item + item]
listO_item_first
list @type=ordered + item + item
listO_item_middle
[list @type=ordered + item ]+ p
listO_item_last
Abbildungen
figure
---
graphic
--Fußnoten
note
note
Tab. 15: Absatzformatvorlagen für geisteswissenschaftliches Buch
TEI-Element
Inline-Element
Zeichenformat
smcap
smcap
i
i
b
b
ul @rend=line
ul
ul @rend=dots
ul_dotted
sup
sup
emph
emph
Verweise
ref
--Fremdsprachen
foreign @xml:lang=he
hebrew
foreign @xml:lang=el
greek
note + foreign @xml:lang=he
hebrew_note
note + foreign @xml:lang=el
greek_note
floatingText + foreign @xml:lang=he
hebrew_floatingText
floatingText + foreign @xml:lang=el
greek_floatingText
l + foreign @xml:lang=he
hebrew_l
TEI-Element
Inline-Element
Zeichenformat
l + foreign @xml:lang=el
greek_l
list + item + foreign @xml:lang=he
hebrew_list
list + item + foreign @xml:lang=el
greek_list
Sonderzeichen
abbr
1/8 Geviert einfügen
g
g (Glyph)
Tab. 16: Zeichenformatvorlagen für geisteswissenschaftliches Buch
Regeln für die XSLT-Transformation
1. Alle Überschriften, auf die ein Absatz folgt, bekommen in Abhängigkeit
von dem jeweiligen div-Container ein entsprechendes Überschriftenformat
(head_0, head_1, head_2 etc.) zugewiesen.
2. Folgen zwei div-Container mit jeweils einem head-Element unmittelbar aufeinander, wird der zweiten Überschrift ein anderes Format zugeordnet, nämlich
ohne Abstand davor (head_0_1, head_1_2 etc.).
3. Jeder Absatz innerhalb von div und nach einer Überschrift erhält ein Absatzformat ohne Einzug (p_woi  paragraph without indent). Dies gilt ebenfalls
für Absätze nach Listen, Versen und der Gliederung der Autorin.
4. Die restlichen Absätze innerhalb der div-Container erhalten ein Format mit
Einzug (p).
5. Exkurse werden mit dem Element floatingText ausgezeichnet. Innerhalb des
Elementes ist zu prüfen, ob es eine Überschrift gibt. Falls ja, dann wird ihr
das Format floatingText_head zugewiesen. (Alle Exkurse sind in der Regel
mit einer einzigen Überschrift überschrieben).
6. Folgt nach der Exkurs-Überschrift ein Absatz, so erhält dieser das Absatzformat ohne Einzug (floatingText_p_woi).
7. Verse mit beidseitigem Einzug innerhalb von floatingText und div sind mit dem
Element quote gekennzeichnet und erhalten das Format floatingText_quote_ibs (indent both sides) bzw. das Format quote_ibs. Dazu wird von XSLT
überprüft, ob nach einem Absatz ein Element quote folgt. Normalerweise
steht nur ein quote-Element zwischen zwei Absätzen. Bei zwei aufeinander
folgenden quote-Elementen bekommt das zweite das Format quote_last_ibs.
8. Für Listen, Verse und Gliederungen innerhalb eines Exkurses muss überprüft
werden, ob es danach einen Absatz gibt. Wenn dies zutrifft, bekommt der
Absatz das Format ohne Einzug (floatingText_p_woi).
9. Allgemein muss für Listen überprüft werden, ob vor einem Listeneintrag (item)
ein Absatz oder eine Überschrift steht. Falls das bejaht wird, ist es der erste
Eintrag in einer Liste und diesem wird das Format list_item_first zugewiesen.
10. Falls nach dem ersten Listeneintrag direkt ein Absatz oder eine Überschrift
folgt, erhält der Listeneintrag das Format list_item_single.
11. Weiterhin wird überprüft was auf den Listeneintrag folgt. Folgen zwei weitere
Listeneinträge, so bekommt der Erstere das Format list_item_middle.
12. Folgt nach mindestens zwei Listeneinträgen ein Absatz wird dem Eintrag das
Format list_item_last zugewiesen.
Diese Abfragen (9–12) gelten gleichermaßen für Verszeilen (l oder list) und
Gliederungen (ebenfalls durch das list-Element abgebildet). In der oberen
Tabelle sind diesen Elementen je nach Auftreten innerhalb der Struktur verschiedene Absatzformate zugewiesen. Beispielsweise wird berücksichtigt, ob
ein Vers innerhalb des Fließtextes oder innerhalb eines Exkurses vorkommt.
13. Taucht innerhalb des Textes eine Tabelle auf, so ist die erste Zeile mit dem
Attribut role=“label“ der Tabellenkopf (table_header), die restlichen Zeilen
mit dem Attribut role=“data“ sind table_cell.
14. Besitzt eine Tabelle eine Überschrift erhält diese das Format table_head. Außerdem ist das Vorhandensein eines head-Elementes innerhalb einer Tabelle ein Indiz dafür, dass es sich um eine „echte“ Tabelle handelt. Es ist auch
möglich, dass eine Gliederung oder eine bestimmte Anordnung von Versen
als Tabelle in XML ausgezeichnet wird.
15. Die Elemente ref, figure und graphic werden in InDesign nicht gekennzeichnet.
Sie sind lediglich eine Referenz.
16. Fußnoten erhalten ein spezielles Fußnotenformat. XSLT erkennt Fußnoten im
XML-Dokument am Element note. XSLT muss außerdem mitgeteilt werden,
wo diese Fußnoten platziert werden: am Seitenende oder als Endnoten.
17. Die Inline-Elemente für typografische Auszeichnungen werden eins zu eins
zugewiesen, da sie nur ein Zeichenformat darstellen und unabhängig von der
Schriftgröße sind. Die Tags sind eindeutig und bedürfen keiner komplizierten
Abfrage. Lediglich bei dem Element ul wird mittels rend-Attribut unterschieden, ob der Text mit einer Line oder gepunktet unterstrichen wird.
18. Das Element emph dient der sprachlichen Betonung. In InDesign wird dafür
ein separates Zeichenelement angelegt, welches das zu betonende Wort beispielsweise kursiv wiedergibt.
19. In gleicher Weise werden Glyphen mit einem separaten Zeichenelement g für
Glyph ausgezeichnet.
20. Abkürzungen, die im XML-Dokument mit abbr gekennzeichnet sind, können
per XSLT den speziellen Leerzeichenabstand 1/8-Geviert erhalten.
21. Für die fremdsprachigen Zeichensätze wird für jede Schriftgröße (Fließtext,
Fußnote, Exkurs) ein entsprechendes Format zugewiesen, weil diese Zeichen
oftmals eine andere x-Höhe besitzen als der umgebende Text. Hier muss überprüft werden, innerhalb welches Elementes sich das Inline-Element foreign
befindet. Dies wurde in der oben abgebildeten Tabelle unterschieden.
2.4.2 Medizinisches Fachbuch
In der unten abgebildeten Tabelle sind die Regeln für die XSLT-Transformation
zusammengefasst und den Formatnamen gegenüber gestellt. Eine verbale Formulierung der Regeln folgt nach der Tabelle.
NCBI-Element
Blockelement
InDesignFormatvorlage
Absatzformat
BOOK-PART-META
title
title_1
contrib @contrib-type=author
title_1_author
abstract + p
abstract_p
BODY
sec @id=no.X.X + title
title_2
[sec @id=no.X.X + title] + [ sec @id=no.X.X.X + title]
title_2_3
sec @id=no.X.X.X + title
title_3
[sec @id=no.X.X.X + title] + [ sec @id=no.X.X.X.X + title]
title_3_4
sec @id=no.X.X.X.X + title
title_4
[sec @id=no.X.X.X.X + title] + [ sec @id=no.X.X.X.X.X +
title]
title_4_5
sec @id=no.X.X.X.X.X + title
title_5
Absatz
p
p
title + p
p_woi
[list] + p
p_woi
[fig] + p
p_woi
[table] + p
p_woi
[boxed-text] + p
p_woi
Boxen
[boxed-text @content-type=Merksatz] + title
box_1_title
[boxed-text @content-type=Merksatz] + p
box_1_p
[boxed-text @content-type=Hinweis] + title
box_2_title
[boxed-text @content-type=Hinweis] + p
box_2_p
[boxed-text @content-type=Hinweis] + p + p
box_2_p_last
[boxed-text @content-type=Hinweis] + [p (list (list-item))]
box_2_list
[boxed-text @content-type=Hinweis] + [p (list (list-item
(last)))]
box_2_list_last
NCBI-Element
Blockelement
Absatzformat
[boxed-text @content-type=Hintergrundinfo] + title
box_3_title
[boxed-text @content-type=Hintergrundinfo] + [list (title)]
box_3_title
[boxed-text @content-type=Hintergrundinfo] + p
box_3_p
[boxed-text @content-type=Hintergrundinfo] + [list
(list-item)]
box_3_list
Listen
p + [list @list-type=bullet (list-item)]
list_bullet
p + [list @list-type=bullet (list-item (last))] + p
list_bullet_last
[p (list @list-type=bullet (list-item))]
list_bullet
[p (list @list-type=bullet (list-item (last oder single)))] + p
list_bullet_last
p + [list @list-type=order (list-item)]
list_number
p + [list @list-type=order (list-item (last))] + p
list_number_last
Tabellen
table-wrap + title
table_title
th
table_header
td
table_text
td (list @list-type=bullet)
table_list_bullet
td (list @list-type=simple)
table_list_simple
table-wrap-foot (p)
table_foot
Fußnote
fn
footnote_text
Abbildungen
fig (label + caption (p))
figure_title
graphic
--Zusammenfassung
sec @id=sumX + title
summary_title
sec @id=sumX + title + p
summary_text
BACK
Literaturverzeichnis
ref-list + title
biblio_title
NCBI-Element
Blockelement
Absatzformat
ref
biblio_text
Tab. 17: Absatzformatvorlagen für medizinisches Fachbuch
NCBI-Element
Inline-Element
Zeichenformat
bold
bold
italic
italic
sc
sc
sub
sub
sup
sup
Listen
list @list-type=order +p (bold (first sentence))
Spitzmarke
list + label
bullets_numbers
Fußnoten
fn + label
footnote_sign
Verweise und Abkürzungen
xref @ref-type
---
abbrev
1/8 Geviert Zeichenabstand
Tab. 18: Zeichenformatvorlagen für medizinisches Fachbuch
Regeln für die XSLT-Transformation
Book-part-meta
1. Das title-Element innerhalb des Containers book-part-meta ist die Beitragsüberschrift und erhält das Absatzformat title_1.
2. Das contrib-Element mit dem Attribut contrib-type=“author“ ist der Autor
eines Beitrages. Der Inhalt des Tags erhält das Format title_1_author. Bei zwei
Autoren werden die Elemente per XSLT mit dem Wort „und“ verknüpft. Anschließend wird die Formatierung zugewiesen.
3. Enthält book-part-meta ein Element abstract, so wird allen darin enthaltenen
Absätzen das Format abstract_p zugewiesen.
Body
1. Alle Überschriften innerhalb des sec-Elementes, auf die ein Absatz folgt, bekommen in Abhängigkeit von dem jeweiligen sec-ID-Attribut das Format
title_2, title_3 etc.
Die Nummerierung der Überschriften erfolgt entweder automatisch durch
XSLT; durch Auslesen des label-Elementes oder per Absatzformatdefinition.
2. Folgen zwei sec-Elemente mit jeweils einem title-Element unmittelbar aufeinander, wird der zweiten Überschrift ein anderes Format zugeordnet, nämlich
mit weniger Abstand davor (title_1_2, title_2_3 etc.). Die Nummerierung der
Überschriften erfolgt entweder automatisch durch XSLT; durch Auslesen des
label-Elementes oder per Absatzformatdefinition.
3. Alle Absätze innerhalb eines sec-Elementes erhalten zunächst ein Format mit
Einzug (p).
4. Jeder Absatz innerhalb von sec nach einer Überschrift erhält ein Absatzformat ohne Einzug (p_woi = paragraph without indent). Dies gilt ebenfalls für
Absätze nach Listen, Abbildungen, Tabellen und allen Boxen.
5. Es existieren drei verschiedene Boxen. Im XML-Dokument sind diese durch
das Element boxed-text gekennzeichnet. Unterschiedlich sind die drei Attributwerte des Attributes content-type (Merksatz, Hinweis, Hintergrundinfo).
Anhand dieses Attributes ist XSLT in der Lage, das jeweilige Überschriften- und Textformat (box_1_title und box_1_p für Box_1) auszuwählen und
zuzuordnen.
6. Enthält eine Box wie beispielsweise Box_2 mehrere Absätze, so wird dem
letzten Absatz das Format box_2_p_last zugeordnet.
7. Taucht eine Liste direkt im Absatz auf, erhalten alle Listenelemente mit Ausnahme des Letzten das Format box_X_list (X = Ziffer der Box). Das letzte
Element einer Liste innerhalb eines Absatzes in einer Box erhält das Format
box_X_list_last.
8. Enthält eine Liste in einer Box ein oder mehrere title-Elemente, so wird diesen
Elementen ebenfalls das Format box_X_title zugewiesen.
9. Listen bekommen unabhängig davon, ob sie parallel zu einem Absatz oder in
einem Absatz stehen das Format list_bullet bzw. list_number. Die Entscheidung, ob es sich um eine list_bullet oder eine list_number handelt wird durch
das Attribut list-type getroffen.
10. Folgt nach einem list-item ein neuer Absatz, so handelt es sich um den letzten
Listeneintrag. Ihm wird das Absatzformat list_bullet_last/list_number_last
zugeordnet.
11. Bei nur einem einzigen Listeneintrag innerhalb einer Liste wird ebenfalls das
Element list_bullet_last zugewiesen.
12. Alle Inhalte einer Tabelle sind in dem XML-Dokument übersichtlich in dem
Element table-wrap und table-wrap-foot zusammengefasst. Tritt innerhalb von
table-wrap ein title-Element auf, so handelt es sich um die Tabellenüberschrift.
Dieser wird das Format table_title zugewiesen.
13. Das Tabellenelement th innerhalb eines row-Elementes kennzeichnet immer
den Tabellenkopf mit dem Format table_header.
14. Analog dazu kennzeichnet das Element td innerhalb eines row-Elementes
immer den Tabelleninhalt, formatiert durch table_text.
15. Legenden von Tabellen stehen im Element table-foot-wrap. Die darin enthaltenen Absätze (p) bekommen das Format table_foot.
16. Taucht innerhalb eines td-Elementes ein list-Element auf, so wird in Abhängigkeit von dem Attribut entweder das Format table_list_bullet oder
table_list_simple zugewiesen.
17. Eine Fußnote erhält unabhängig davon wo sie auftaucht das Format footnote_
text. Per XSLT wird bestimmt, wo der Fußnotentext im Buch abgebildet wird.
18. Abbildungen enthalten in dem analysierten Buch immer ein label (Abb.X) und
eine Abbildungsüberschrift. Das label- und caption-Element müssen per XSLT
zusammengefasst und mit dem Format figure_title ausgezeichnet werden.
19. Die Zusammenfassung eines Beitrages ist optional. Falls XSLT ein Element
sec mit dem Attribut id=“sumX“ findet, erhalten die Überschriften das Format
summary_title und die Absätze das Format summary_text.
Back
20. Ähnliches gilt für das Literaturverzeichnis. Es steht separat in dem Element
back und damit parallel zu book-part und body. Enthält das Element back eine
Referenzliste (ref-list), die wiederum ein title-Element enthält, so ist dieses die
Überschrift mit dem Format biblio_title.
21. Alle im Element ref enthaltenen Elemente werden von XSLT ausgelesen und
fortlaufend, ergänzt durch Interpunktionen, mit dem Format biblio_text
formatiert.
Inline-Elemente
22. Die Inline-Elemente für typografische Auszeichnungen werden unabhängig
von der Schriftart zugewiesen. Eine Zuordnung der Tagnamen zu Formatnamen ist in InDesign direkt nach Name möglich oder per XSLT.
23. Spitzmarken tauchen im Buch nur innerhalb einer nummerierten Liste auf.
Hier kann XSLT die nummerierte Liste finden und in jedem list-item nach
einem bold-Element zu Beginn des Absatzes suchen. Diese Hervorhebung entspricht dann der Spitzmarke. Das Zeichenformat Spitzmarke kann innerhalb
eines verschachtelten Formates für diese Liste verwendet werden.
24. Listen mit einem Element label erhalten das Zeichenformat bullets_numbers
für das Aufzählungszeichen.
25. Ein label-Element innerhalb von fn steht für das Fußnotenzeichen im Text
und erhält das Zeichenformat footnote_sign.
Das Format footnote_sign wird außerdem innerhalb des Absatzformates footnote_text benötigt. Dort wird es in einem verschachtelten Format zur Kennzeichnung des Zeichens verwendet.
26. Die Elemente xref und graphic werden in InDesign nicht gekennzeichnet. Sie
sind lediglich eine Referenz.
27. Abkürzungen, die im XML-Dokument mit abbrev gekennzeichnet sind, können per XSLT den speziellen Leerzeichenabstand 1/8-Geviert erhalten.
2.5 Zwischenfazit
Anhand der Regeln für die XSLT-Transformation wird deutlich, warum eine eindeutige Auszeichnung des XML-Dokumentes sehr wichtig ist und die Wahl der
DTD nicht willkürlich sein sollte. Die DTD muss garantieren, dass die Elemente
und Attribute konstant innerhalb eines Dokumentes verwendet werden. So ist
XSLT in der Lage, die Struktur zu verstehen und die Strukturelemente richtig
umzusetzen.
Die Systematik für die Benennung der Absatz- und Zeichenformate richtet sich
nach den Tagnamen der DTD. Diese können jedoch nicht eins zu eins übertragen
werden. Grund dafür ist, dass ein Elementname einer DTD mehrere oder differenziertere Absatzformate in InDesign benötigt (Beispiel title-Element). Umgekehrt
kann auf mehrere Fallbeispiele dasselbe Absatzformat zutreffen. Dies ist beispielsweise bei Absätzen nach Listen, Boxen, Abbildungen, Tabellen etc. der Fall, indem
dem Absatz ein Format ohne Einzug zugewiesen wird.
Des Weiteren ist die Systematik so angelegt, dass alle Elemente (Titel, Absatz,
Liste etc.) mit dem entsprechenden Elementnamen beginnen. Das bedeutet, dass
das spezifischere Strukturelement über dem Allgemeinen steht – zum Beispiel:
table_title, list_title an Stelle von title_table, title_list. Damit wird gewährleistet,
dass die Absatzformate zu einem Strukturelement (z. B. einer Tabelle) bei der
alphabetischen Sortierung in InDesign immer zusammenstehen.
Die Liste der Absatz- und Zeichenformate dient dem Benutzer als Orientierung für eine ungefähre Anzahl an Formatvorlagen. Die erstellte Tabelle ist eine
Gegenüberstellung der Elemente der DTD und möglicher Absatzformate. Für
verschachtelte Formate oder Aufzählungen können weitere Zeichenformate hinzukommen.
125
IV. Fazit
Auf den zurückliegenden Seiten wurden ausführlich die vier DTDs ISO 12083,
DocBook, TEI und das NCBI Book Tag Set vorgestellt und miteinander verglichen.
Mit Hilfe vom Diplomanden entwickelten Vergleichskriterien ist der Anwender
in der Lage, eine Auswahl hinsichtlich einer geeigneten DTD zu treffen. Im praktischen Teil der Arbeit wurde die Umsetzung anhand von zwei Beispielbüchern
(geisteswissenschaftliches Buch, medizinisches Fachbuch) gezeigt. Dabei fiel auf,
dass abhängig vom Genre des Buches eine entsprechende DTD gewählt werden
sollte. Für das geisteswissenschaftliche Buch eignet sich TEI und für das medizinische Fachbuch das NCBI Book Tag Set.
Abschließend wurde darauf eingegangen, wie InDesign und XML zusammen
wirken. Des Weiteren wurde dargestellt, wie DTDs in InDesign zur Validierung
und Zuordnung zu Formatvorlagen genutzt werden.
Insbesondere für Reihentitel, lohnt es sich eine DTD in den Workflow zu integrieren, um wiederkehrende Strukturelemente und Hierarchien abzufragen. Obwohl
für die Arbeit nur ein Buch untersucht wurde, lässt sich dennoch schlussfolgern,
dass Elemente wie Abstract, Tabellen, Aufzählungen, Abbildungen und Merksätze in medizinischen Fachbüchern die tragenden Elemente sind und unbedingt
durch die DTD abgebildet werden müssen. Aus diesem Grund wurde das Book
Tag Set gewählt. Zudem sind wissenschaftliche Texte stark untergliedert, was eine
einheitliche, konsistente und logische Verwendung der Überschriftenhierarchien
erfordert.
Der Gebrauch einer DTD leistet einen kleinen Beitrag zur Qualitätssicherung
innerhalb des komplexen XML-Workflows in Verlagen, der weiter untersucht
werden müsste. Die genannten Unternehmen haben im Ergebnis der Arbeit eine
geeignete DTD für ihren Workflow vorliegen. Die Verwendung des Book Tag Set
für ein medizinisches Fachbuch und von TEI für das geisteswissenschaftliche
Buch sind Vorschläge, die in der Praxis anhand mehrerer Bücher weiter getestet
werden müssen.
Neben den vier vorgestellten Standard-DTDs existieren über 900 weitere IndustrieStandard-DTDs.160 Beispiele sind PRISM für Zeitschriften, NewsML für Nachrichten, OASIS Dita, MathML, SVG DTD, DTD für HTML, DTD für XHTML etc.
Große Verlage wie Elsevier, Blackwell und Wiley mit vielen Reihentiteln besitzen
verlagseigene DTDs. Für kleine Verlage lohnt sich die Investition meistens nicht
und die kostenlosen Standard-Schemata sind ohnehin ausreichend, sofern sie alle
benötigten Elemente enthalten.
Zusammenfassend lässt sich feststellen, dass die Schemasprache DTD neben allen anderen Schemasprachen (XML-Schema, RelaxNG etc.) trotz ihrer Nachteile
(siehe Kapitel 1, Abschnitt „W3C XML Schema“) ein wichtiges Werkzeug für die
dokumentorientierte Überprüfung von Strukturen bleibt. Eine DTD ist gegen160 Stylus Studio: Document Type Definition (DTD) Tools. http://www.stylusstudio.com/dtd.html,
Fazit126
über einem XML-Schema leichter zu erstellen, besser lesbar und sie ist vielen
Anwendern vertrauter. Für die Überprüfung von Strukturen ist eine DTD mehr
als ausreichend.
Letztlich hängt die XML-Validierung von der Qualität der definierten Regeln
ab und damit von dem verwendeten Standard. Je strikter eine DTD konzipiert ist,
desto konsistenter sind die XML-Dokumente. Allerdings besteht weniger Flexibilität in der Inhaltserstellung. Die Verwendung von DTDs stellt eine Gratwanderung zwischen Vielseitigkeit und Genauigkeit dar. Deshalb sollte für mehrere
gleichartige Bücher geprüft werden, welche Elemente relevant sind und wo diese
innerhalb der Struktur vorkommen. Erst dann kann entschieden werden, welche
DTD geeignet ist.
In Zukunft könnte eine weitere Schemasprache namens CAM (Content Assembly Mechanism) hinzukommen. Diese wird von OASIS seit Anfang des Jahres
2009 entwickelt. Bei CAM wird das XML-Dokument gegen ein CAM-Template
hinsichtlich seiner Struktur und Semantik getrennt überprüft. Alle bisherigen
Schemasprachen prüfen entweder nur die Struktur (DTD) oder Struktur und Semantik zusammen (Schematron, XML Schema). Das Konzept ist eine kontextbasierte Validierung der XML-Dokumente. Des Weiteren wird für die Entwicklung
der Regeln eine WYSIWYG-Methode verwendet.161 Ob sich dieser neue Standard
durchsetzen wird, bleibt abzuwarten.
161 Sorens, Michael: Taking XML Validation to the Next Level: Introducing CAM. http://www.
devx.com/xml/Article/41066, Zugriff am 21.12.09.
127
Anhang
128
Glossar
CSS: Cascading Stylesheet. CSS ist eine Formatierungssprache, die hauptsächlich die
Struktur von HTML-Dateien optisch (Aussehen, Format, Position) für das Internet
aufbereiten hilft. CSS ist nicht XML basiert.
XLink: XML Linking Language. Ist eine attributbasierte Syntax mit der man Links zu
einem XML-Dokument hinzufügen kann.
Dabei sind sowohl die üblichen HTML-Links
als auch komplizierte Verlinkungen zwischen
Quellen möglich.
XML-Parser Ein XML-Parser ist ein Programm, das die Wohlgeformtheit eines XMLDokumentes überprüft. Für den Parser ist die
erste Zeile eines XML-Dokumentes wichtig:
<?xml version=“1.0“ encoding=“UTF-8“?>.
Hier wird dem Parser mitgeteilt, dass es sich
um ein XML-Dokument handelt, welche Version des Standards relevant ist und in welchem Zeichensatz die Datei kodiert ist. Ein
bekannter XML-Parser heißt Xerces.
XPath: XML Path Language. Die Sprache
dient dazu Teile eines XML-Dokumentes
unter Verwendung eines Datenmodells zu
identifizieren. Das Datenmodell bildet die
Struktur eines XML-Dokumentes als Baum
(Knoten und Kanten) ab. Mit Hilfe von XPath
wird also der Weg zu einem bestimmten Element oder Attribut innerhalb der Struktur als
Pfad angegeben.
XQuery: XML Query Language. Es handelt
sich um eine Abfragesprache für XML-Dokumente. XQuery benutzt für die Adressierung
von Knoten die Sprache XPath.
XSL: eXtensible Stylesheet Language. Ein
Konzept für die Verarbeitung und Nutzung
von XML-Daten bzw. -Dokumenten. Es wurde vom W3C 2001 als Norm publiziert und
besteht aus zwei Teilen: 1. Einer Sprache für
die Transformation von XML-Dokumenten
(XSLT). 2. Einem XML-Vokabular zur Spezifizierung von Formatvorgaben (XPath und
XSL-FO). Ein XSL-Stylesheet definiert die
Darstellung eines XML-Dokumentes unter
Verwendung der Formatvorgaben.
XSL-FO: XSL-Formatting Objects. Ein
Vokabular, das die Darstellung von XMLDokumenten auf einem seitenorientierten
Ausgabemedium beschreibt, zum Beispiel
PDF. Mit XSL-FO wird die Formatierung
(Layout und Typografie) eines Dokumentes
gesteuert. Damit übernimmt XSL-FO vereinfacht gesagt die Funktion von Satzprogrammen wie InDesign.
XSLT: eXtensible Stylesheet Language
Transformations. Dient der Transformation
eines XML-Dokumentes (DocBook-XML) in
ein anderes XML-Dokument (XHTML) mittels eines Stylesheets.
XSLT-Prozessor: Ein XSLT-Prozessor
führt die in einem XSLT-Stylesheet beschriebene Transformation durch und wendet sie
auf das zu transformierende XML-Dokument
an. Bekannte XSLT-Prozessoren heißen Saxon, Xalan oder xsltproc.
Unicode: Unicode ist ein System, in dem
die Zeichen oder Elemente aller bekannten
Schriftkulturen und Zeichensysteme festgehalten werden. Die Zeichen werden nach
Klassen katalogisiert und erhalten eine Zeichennummer (Code).
URI: Uniform Resource Identifier. Der URI
wird verwendet für die Bezeichnung von
Webseiten u. a. Die Angabe eines Namensraumes ist ein Beispiel für einen URI: <TEI
xmlns=“http://www.tei-c.org/ns/1.0“>.
UTF-8/UTF-16: Ist ein Standardzeichensatz für die internationale Kodierung von
XML-Dokumenten auf Basis von Unicode.
Dabei wird jedem Unicode-Zeichen eine
speziell kodierte Bytekette (1 bis 4) variabler
Länge zugeordnet. Die Kodierung eines Bytes
erfolgt mit 8 Bits.
UTF-16: siehe UTF-8. Die Kodierung eines
Bytes erfolgt hier jedoch mit 16 Bits.
W3C: World Wide Web Consortium. Das
Konsortium ist eine internationale Community, dessen Aufgabe die Entwicklung
von Webstandards ist. Daran beteiligt sind
Mitgliedsorganisationen, Angestellte und die
Öffentlichkeit. Die Prinzipien lauten „Web
for All“ und „Web for Everything“. Wichtige
Standards sind XML, XSLT, XPath, XQuery
und XSL-FO.
129
Quellenverzeichnis
Print
Dykes, Lucinda; Tittel, Ed: XML für Dummies. 3. Aufl., Weinheim: Wiley-VCH
Verlag, 2006.
Eckstein, Rainer; Eckstein, Silke: XML und Datenmodellierung. In: xml.bibliothek. Heidelberg: dpunkt.verlag, 2004.
Goldfarb, Charles F.: The SGML Handbook. Oxford: Clarendon Press, 1990.
Goldfarb, Charles F.; Prescod, Paul: The XML Handbook. New Jersey: Prentice
Hall PTR, 1998.
Göbel, Stephan: Digitales Wissenschaftliches Publizieren. Fernwald: litblockin
Verlag, 2004.
Kränzler, Christine: XML, XSL für Buch und Web. München: Markt+Technik
Verlag, 2002.
Krüger, Manfred: XSL-FO verstehen und anwenden, In: xml.bibliothek. Heidelberg: dpunkt.verlag, 2006.
Maler, Eve; Andaloussi, El Jeanne: Developing SGML DTDs: From Text to Model
to Markup. 2. Aufl., New Jersey, USA: Prentice Hall PTR, 1996.
Megginson, David: Structuring XML Documents. 2. Aufl., New Jersey: Prentice
Hall PTR, 1998.
Pineda, Manuel Montero; Sieben, Jürgen: Professionelle XML-Verarbeitung mit
Word. Heidelberg: dpunkt.verlag, 2007.
Rothfuss, Gunther; Ried, Christian: Content Management mit XML. 2. Aufl.,
Berlin, Heidelberg: Springer-Verlag, 2003.
Skulschus, Marco; Wiederstein, Marcus: XML Schema. Bonn: Galileo Press
GmbH, 2004.
Stayton, Bob: DocBook XSL: The Complete Guide. Fourth Edition, Santa Cruz:
Sagehill Enterprises, 2007.
Tidwell, Doug: XSLT. Sebastopol: O’Reilly & Associates, 2001.
Trieloff, Lars: DocBook-XML: Einführung und Anwendung. Bonn: mitp-Verlag,
2005.
Vonhoegen, Helmut: Einstieg in XML: Grundlagen, Praxis, Referenzen. 4., aktualisierte Aufl., Bonn: Galileo Press, 2007.
Walsh, Norman; Mueller, Leonard: DocBook: The Definitive Guide. Sebastopol:
O’Reilly & Associates, 1999.
Wittenbrink, Heinz; Köhler, Werner (Hrsg.): XML. Berlin: TEIA Lehrbuch
Verlag GmbH, 2003.
Online
3B2: Was sind CALS-Tabellen? http://www.originalab.se/advent/html/de/prd_3B2_
tables_cals-in-depth.html, Zugriff am 17.11.2009.
Adobe Systems Inc.: Adobe InDesign CS3 and XML: A Technical Reference. http://
wwwimages.adobe.com/www.adobe.com/products/indesign/scripting/pdfs/
indesign_and_xml_technical_reference.pdf, Dokumentation, Zugriff am
21.12.2009.
ANSI/NISO/ ISO 12083: http://www.techstreet.com/standards/NISO_ISO/12083?
product_id=52643, Dokumentation, Teil 12083-a bis Teil 12083-i, Zugriff am
05.08.2009.
Auer, Jürgen: Entities: Definition und Verwendung. http://www.sql-und-xml.de/
xml-lernen/document-type-definition-entities-xml-document.html, Zugriff
am 09.05.2009.
Auer, Jürgen: Namespace-Deklarationen in Kombination mit der Validierung bezüglich der externen DTD. http://www.sql-und-xml.de/xml-lernen/namespace-parameter-entities-validierung.html, Zugriff am 03.09.2009.
Beuth Verlag GmbH: http://www.beuth.de, Zugriff am 05.08.2009.
Bingham, Harvey: CALS Table Model Document Type Definition. http://www.
oasis-open.org/specs/a502.htm, Zugriff am 27.10.2009.
Biron, Paul V., et al.: XML Schema Part 2: Datatypes Second Edition. http://www.
w3.org/TR/xmlschema-2, Zugriff am 08.12.202009.
Bray, Tim et al: Extensible Markup Language (XML) 1.0 (Fifth Edition). http://
www.w3.org/TR/xml, Zugriff am 30.08.2009.
Bruvik, Tone Merete: Yesterday‘s Information Tomorrow: Die Text Encoding Initiative. http://www.onb.ac.at/sichtungen/beitraege/bruvik-tm-1a.html, Zugriff
am 17.09.2009.
Burnard, Lou; Sperberg-McQueen, C. M.: TEI Lite: Encoding for Interchange:
an introduction to the TEI — Revised for TEI P5 release. http://www.tei-c.org/
release/doc/tei-p5-exemplars/html/teilite.doc.html. Zugriff am 12.07.2009.
Clark, James: Comparison of SGML and XML. http://www.w3.org/TR/NOTEsgml-xml-971215.html, Zugriff am 07.12.2009.
come2xml: XML Entity-Definitionen – Parameter-Entities. http://www.come2xml.
de/ref_entity_parameter.html, Zugriff am 09.05.2009.
Cover, Robin: Core standards: XML Schemas. http://xml.coverpages.org/schemas.
html, Zugriff am 08.12.2009.
Deutsches Literaturarchiv Marbach: http://www.dla-marbach.de/?id=51618, Zugriff am 24.08.2009.
Deutsches Textarchiv: http://www.deutsches-textarchiv.de/project/description,
DocBook: http://www.docbook.org, Zugriff am 04.09.2009.
DTD/Schema Validator: http://www.validome.org/grammar
Dünckel, Björn et al.: Über die Eignung von Schema-Sprachen zur Prüfung von
XML-Dokumenten. http://it-republik.de/php/artikel/Ueber-die-Eignung-vonSchema-Sprachen-zur-Pruefung-von-XML-Dokumenten-2459.html, Zugriff
am 21.09.2009.
Herpers, Franz-Josef: XML-Namensräume und Validierung. http://aktuell.
de.selfhtml.org/artikel/xml/namensraeume, Zugriff am 09.12.2009.
Hicks, Tony: Should We Be Using ISO 12083? http://quod.lib.umich.edu/cgi/t/
text/text-idx?c=jep;view=text;rgn=main;idno=3336451.0003.407, Zugriff am
05.08.2009.
Hoxha, Dashamir: The Features of DocBookWiki. http://doc-book.sourceforge.
net/homepage, Zugriff am 05.09.2009.
ISO: http://www.iso.org, Zugriff am 05.08.2009.
java.net: Sun Multi-Schema XML Validator (MSV). https://msv.dev.java.net, Zugriff am 05.09.2009.
Kasdorf, Bill: The Power of XML. http://www.dclab.com/kasdorf.asp, Zugriff
am 30.08.2009.
Kennedy, Dianne: Minutes: EPSIG Meeting: Barcelona, May 12, 1997. http://xml.
coverpages.org/kennedyEPSIGBarcel.html, Zugriff am 14.08.2009.
Makoto, Murata: Relax NG. http://www.relaxng.org, Zugriff am 04.09.2009.
Mertz, David: XML Matters: Getting comfortable with the DocBook XML dialect.
http://www.ibm.com/developerworks/library/x-matters4.html, Zugriff am
04.10.2009.
NCBI/NLM: NLM Journal Archiving and Interchange Tag Suite. http://dtd.nlm.
nih.gov, Zugriff am 05.09.2009.
NCBI-DTD-Download via FTP: ftp://ftp.ncbi.nih.gov/pub/archive_dtd, Zugriff
am 30.07.2009.
NLM: Fact Sheet – The National Library of Medicine. http://www.nlm.nih.gov/
pubs/factsheets/nlm.html, Zugriff am 16.09.2009.
OASIS: http://www.oasis-open.org/, Zugriff am 18.09.2009.
Omnipress: Text Encoding Initiative: P5 Guidelines. http://shop.omnipress.com/
index.asp?PageAction=VIEWPROD&ProdID=161, Zugriff am 27.08.2009.
Payer, Margarete; Payer, Alois: Inhaltliche Strukturierung von Ressourcen. http://
www.payer.de/xml/xml16.htm, Zugriff am 05.08.2009.
Schematron: How is Schematron used? http://www.schematron.com, Zugriff am
26.09.2009.
SELF HTML: Dokumenttyp-Definitionen (DTDs). http://de.selfhtml.org/xml/dtd/
index.htm, Zugriff am 03.09.2009.
SELFHTML: Attribute mit Entity-Wert (z. B. für externe Dateireferenzen). http://
de.selfhtml.org/xml/dtd/attribute.htm#mit_entitywert, Zugriff am 31.08.2009.
SELFHTML: HTML-Zeichenreferenz. http://de.selfhtml.org/html/referenz/zeichen.htm, Zugriff am 09.12.2009.
SELFHTML: Unterschiede zwischen XHTML und HTML. http://de.selfhtml.org/
html/xhtml/unterschiede.htm#xml_deklaration, Zugriff am 17.11.2009.
Sorens, Michael: Taking XML Validation to the Next Level: Introducing CAM.
http://www.devx.com/xml/Article/41066, Zugriff am 21.12.2009.
Sourceforge: http://sourceforge.net, Zugriff am 01.07.09.
Sourceforge: The DocBook Project. http://docbook.sourceforge.net, Zugriff am
18.10.2009.
Stylus Studio: Document Type Definition (DTD) Tools. http://www.stylusstudio.
com/dtd.html, Zugriff am 18.12.2009.
Technische Universität Darmstadt: Profil des Instituts für Sprach- und Literaturwissenschaft. http://www.linglit.tu-darmstadt.de/index.php?id=linglit_profil,
TEI Wiki: Category:XSLT. http://wiki.tei-c.org/index.php/Category:XSLT, Zugriff
am 29.08.2009.
TEI: TEI: Text Encoding Initiative. http://www.tei-c.org/index.xml. Zugriff am
01.07.2009.
TEIA: Aufbau der DocBook DTD. http://www.teialehrbuch.de/Kostenlose-Kurse/
XML/7780-Aufbau-der-DocBook-DTD.html, Zugriff am 10.09.2009.
Thompson, Henry S., et al.: XML Schema Part 1: Structures Second Edition. http://
www.w3.org/TR/xmlschema-1, Zugriff am 08.12.2009.
Ulrich Media GmbH: http://blogs.ulrich-media.ch/search/label/XML, Zugriff
am 21.12.2009.
Universität Freiburg: Freiburger Anthologie - Lyrik und Lied. Digitale Dokumentation von lyrischen Kurztexten. http://www.lyrik-und-lied.de/ll.pl?kat=project.
main&start=1, Zugriff am 26.08.2009.
Universität München: TEI-Version der Edition „Der junge Goethe in seiner Zeit“.
http://www.jgoethe.uni-muenchen.de/teireadme.html, Zugriff am 25.08.2009.
Vlist, Eric van der: Relax NG. http://books.xmlschemata.org/relaxng/page2.html,
W3 School: DTD – Entities. http://www.w3schools.com/dtd/dtd_entities.asp,
W3 Schools: XML Validation. http://www.w3schools.com/XML/xml_dtd.asp,
W3C: Understanding the Four Principles of Accessibility. http://www.w3.org/TR/
UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head,
Walsh, Norman: A Technical Introduction to XML. http://www.xml.com/pub
/a/98/10/guide0.html, Zugriff am 14.09.2009.
Walsh, Norman: Converting a SGML DTD to XML. http://www.xml.com/
pub/a/98/07/dtd/index.html. Zugriff am 30.08.2009.
Walsh, Norman: DocBook XSL Stylesheets: Reference Documentation. file://
localhost/E:/DA/DTD/DocBook/DocBook_XSL/docbook-xsl-snapshot/doc/
index.html, Zugriff am 18.10.2009.
Walsh, Norman; Mueller, Leonard: DocBook 5.0 : The Definitive Guide. http://
www.docbook.org/tdg5/en/html/docbook.html, Zugriff am 04.09.09.
Walsh, Norman; Mueller, Leonard: DocBook: The Definitive Guide. http://www.
docbook.org/tdg/en/html/docbook.html, Zugriff am 04.09.2009.
Zippel, Uwe: Entities und Notationen. http://www.uzi-web.de/xml/xml_entities.
htm, Zugriff am 09.05.2009.
Diplomarbeiten
Hartz, Ivo: Strukturiertes Publizieren mit XML für Verlage. Leipzig: HTWK –
Hochschule für Technik, Wirtschaft und Kultur, Diplomarbeit, 2004.
Präsentationen
Kasdorf, Bill: Books are Messy. PDF-Präsentation. Stand Dezember 2008. Zur
Verfügung gestellt von Herrn Andreas Selignow, Selignow Verlagsservice.
Kasdorf, Bill: XML Models for Books. http://assets.en.oreilly.com/1/event/19/
XML in Practice_ Formats, Tools, and Techniques Presentation 3.pdf. PDFPräsentation. Zugriff am 31.08.2009.
Lausen, Georg: XML-Technologien: Definition von Dokumenttypen (DTD). http://
download.informatik.uni-freiburg.de/lectures/DB2/2007SS/Slides/03_02_
XMLTechnologien_4auf1.pdf. PDF-Präsentation. Zugriff am 14.11.2009.
Wilde, Erik: XML Schemasprachen: Übersicht und Einordnung. http://dret.net/
netdret/docs/wilde-jax2003-1.pdf. PDF-Präsentation. Zugriff am 03.08.2009.
133
Selbstständigkeitserklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig und ohne
Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt habe.
Alle Stellen, die wörtlich oder sinngemäß veröffentlichten oder nicht veröffentlichten Quellen entnommen wurden, sind als solche kenntlich gemacht.
Andrea Heidrich
Leipzig, den 24. Februar 2010
134
Danksagung
An dieser Stelle möchte ich mich bei Herrn Andreas-Martin Selignow für seinen
Themenvorschlag, die konstruktiven Hinweise und seine Geduld bedanken.
Weiterhin danke ich Ivo Hartz und Silvio Patzner vom Unternehmen eScriptum
GmbH & Co.KG für die angenehme Zusammenarbeit und Unterstützung. Insbesondere möchte ich Silvio Patzner für seine zahlreichen Tipps und seiner auf mich
überspringenden Begeisterung für dieses Thema Danke sagen.
Nicht zuletzt danke ich Christine Baumgart und Jana Görsdorf für deren Korrekturen und nützliche Anmerkungen.
Abschließend danke ich von ganzem Herzen meiner Mama und meinem Bruder
Nico für den Rückhalt und die Unterstützung während meiner Schwangerschaft
und der Diplomarbeitsendphase mit meiner kleinen Tochter.
Vielen, vielen Dank.
Andrea Heidrich
135
Thesen zur Diplomarbeit
1. Die Struktur eines Dokumentes bestimmt hauptsächlich die Wahl der DTD
und umgekehrt nimmt die DTD Einfluss auf die Struktur eines Dokumentes,
indem sie beispielsweise bestimmte Strukturelemente zulässt oder nicht. Aus
diesem Grund ist eine Strukturanalyse des Dokumentes die Ausgangsbasis
für die Wahl der DTD.
2. Des Weiteren können für die Wahl einer DTD verschiedene Kriterien herangezogen werden. Diese sind zum Beispiel die Zugänglichkeit und die Qualität der Dokumentation einer DTD, die Modularität sowie die Möglichkeiten
zur Modifikation. Die Gewichtung der einzelnen Kriterien ist von Projekt zu
Projekt unterschiedlich.
3. Für jede Textart sollte eine andere DTD verwendet werden. Es existiert eine
Vielzahl an kostenlosen DTDs, die für eigene Projekte genutzt werden können.
Das Erstellen einer verlagseigenen DTD ist daher nicht notwendig.
4. Die Verwendung von DTDs im XML-Workflow sichert die Qualität von XMLDokumenten. Ein Dokument ist gültig, wenn es den Regeln einer DTD entspricht. Sowohl ein XML-Editor als auch InDesign bieten Möglichkeiten für
die Validierung.

Vergleich von Buch-Schemata unter Berücksichtigung des

Transcription

Similar documents

Geodatenanwendungen

2. Übung

einführung in dos 3

XML XPath XSLT - i-d-e.de

XML - Jeckle

Semistrukturierte Daten - XML

XML Schema Schulung / Seminar / Training

XML Schemasprachen