Freestyle Markup Language - E-LIB

Transcription

Freestyle Markup Language
Spezifikation einer polyhierarchischen Auszeichnungssprache
Denis Pondorf
DISSERTATION
Informatik
Prof. Dr. Hans-Jörg Kreowski
Dr. Andreas Witt
Universität Bremen
Fachbereich 3
11. Juli 2011
© Copyright 2011 Denis Pondorf
Alle Rechte vorbehalten
ii
Erklärung
Hiermit erkläre ich an Eides statt, daß ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfaßt, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen
Stellen als solche gekennzeichnet habe.
Denis Pondorf
Hamburg, am 11. Juli 2011
iii
Die Sprache ist eine ungeheure fortwährende
Aufforderung zur Höherentwicklung.
Christian Morgenstern1
1
In contradictio zum Nihilismus der Sprachkritik des Prager Sprachphilosophen Fritz
Mauthner in [99], 1909. [65]
iv
Inhalt
Kurzfassung
xii
Abstract
xiii
Prolog
xiv
1 Einleitung
1
2 Anforderungen
17
3 Architektur
42
4 Freestyle Dokument
44
5 Freestyle Graph
55
6 Freestyle Konzepte
65
7 Transformation
82
8 XML-Repräsentation
86
9 Implementierung
90
10 Integrität
97
11 Sekundärtechnologien
118
12 Vergleichsanalyse
125
13 Epilog
133
Literaturverzeichnis
138
A Beispiel-Szenario A
158
v
B Beispiel-Szenario B
164
C Spezifikation ’FML’
170
D Compiler
171
E Konvertierungsleitfaden XML → FML
174
F fml-graph.gxl.xsd
178
G fml.xml.xsd
183
H xml2fml.xslt
188
I
194
UML-Klassendiagramm
J Relationales FML-Datenbankschema
196
K Umfrage
198
L FML-Internetressourcen
206
Glossar
208
Stichwortverzeichnis
222
vi
Inhaltsverzeichnis
Kurzfassung
xii
Abstract
xiii
Prolog
xiv
1 Einleitung
1.1 Zielsetzung .
1.2 Grundlagen .
1.3 Relevanz . . .
1.4 Potenziale . .
1.5 Organisation
1.6 Qualifikation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Anforderungen
2.1 Grammatik . . . . . . . .
2.2 Kompatibilität . . . . . .
2.3 Monohierarchie . . . . . .
2.4 Interferenz . . . . . . . . .
2.5 Identifizierung . . . . . . .
2.6 Kongruenz . . . . . . . . .
2.7 Independenz . . . . . . . .
2.8 Segmentierung . . . . . .
2.9 Fragmentierung . . . . . .
2.10 Wildcard . . . . . . . . .
2.11 Vererbung . . . . . . . . .
2.12 Graphrepräsentation . . .
2.13 Transformation . . . . . .
2.14 Eindeutigkeit . . . . . . .
2.15 Entropie . . . . . . . . . .
2.16 Ergonomie . . . . . . . . .
2.17 Internationalisierung . . .
2.18 Referenzimplementierung
2.19 Spezifikation . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
8
10
11
16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
18
19
21
23
24
26
27
28
28
29
32
32
33
35
38
38
40
3 Architektur
42
4 Freestyle Dokument
4.1 Komponenten . . . . . . . . .
4.1.1 Dokument . . . . . . .
4.1.2 Inhalt . . . . . . . . .
4.1.3 Markup . . . . . . . .
4.1.4 Prolog . . . . . . . . .
4.1.5 Tag . . . . . . . . . .
4.1.6 Kommentar . . . . . .
4.1.7 Processing Instruction
4.1.8 Wildcard . . . . . . .
4.2 Grammatik . . . . . . . . . .
4.3 Gültigkeit . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
44
45
45
46
46
47
48
48
49
49
54
5 Freestyle Graph
5.1 Knoten . . . . . . . . . . . .
5.1.1 Dokument . . . . . . .
5.1.2 Perspektive . . . . . .
5.1.3 Inhalt . . . . . . . . .
5.1.4 Element . . . . . . . .
5.1.5 Attribut . . . . . . . .
5.1.6 Kommentar . . . . . .
5.1.7 Processing Instruction
5.1.8 Wildcard . . . . . . .
5.2 Kanten . . . . . . . . . . . . .
5.3 Eigenschaften . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
56
58
58
60
60
61
62
62
63
6 Freestyle Konzepte
6.1 Annotieren . . .
6.2 Deklarieren . . .
6.3 Tagging . . . . .
6.4 Attribuieren . . .
6.5 Interferenz . . . .
6.6 Identifizieren . .
6.7 Kongruenz . . . .
6.8 Independenz . . .
6.9 Segmentieren . .
6.10 Fragmentieren . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
67
68
69
71
72
74
75
78
80
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Transformation
82
7.1 Graphkomposition . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2 Graphdekomposition . . . . . . . . . . . . . . . . . . . . . . . 85
viii
8 XML-Repräsentation
86
8.1 XML Schema Definition . . . . . . . . . . . . . . . . . . . . . 86
8.2 FML → XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.3 XML → FML . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9 Implementierung
9.1 Deserialisierung . . . .
9.2 Serialisierung . . . . .
9.3 XML-Transformation .
9.3.1 FML → XML .
9.3.2 XML → FML .
9.4 Datenmodell . . . . .
9.5 Ausnahmebehandlung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
90
90
92
92
92
92
93
96
10 Integrität
10.1 Grammatik . . . . . . . .
10.2 Kompatibilität . . . . . .
10.3 Monohierarchie . . . . . .
10.4 Interferenz . . . . . . . . .
10.5 Identifizierung . . . . . . .
10.6 Kongruenz . . . . . . . . .
10.7 Independenz . . . . . . . .
10.8 Segmentierung . . . . . .
10.9 Fragmentierung . . . . . .
10.10Wildcard . . . . . . . . .
10.11Vererbung . . . . . . . . .
10.12Graphrepräsentation . . .
10.13Transformation . . . . . .
10.14Eindeutigkeit . . . . . . .
10.15Entropie . . . . . . . . . .
10.16Ergonomie . . . . . . . . .
10.17Internationalisierung . . .
10.18Referenzimplementierung
10.19Spezifikation . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
97
97
99
99
100
101
101
102
103
103
103
104
105
106
106
110
114
116
116
117
.
.
.
.
.
.
.
.
118
. 118
. 119
. 120
. 120
. 121
. 122
. 123
. 124
.
.
.
.
.
.
.
11 Sekundärtechnologien
11.1 Freestyle Schema . . . . . .
11.2 Freestyle Instanz Schemata
11.3 Freestyle Query . . . . . . .
11.4 Freestyle Transformation . .
11.5 Freestyle Kompression . . .
11.6 Freestyle Datenbank . . . .
11.7 Freestyle Editor . . . . . . .
11.8 Freestyle Implementierung .
.
.
.
.
.
.
.
.
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12 Vergleichsanalyse
12.1 GODDAG . . . . . .
12.2 LMNL . . . . . . . .
12.3 MCT . . . . . . . . .
12.4 MuLaX/XCONCUR
12.5 MultiX . . . . . . . .
12.6 NITE . . . . . . . .
12.7 SGF/XStandoff . . .
12.8 SGML/XML . . . .
12.9 TEI . . . . . . . . .
12.10TexMECS . . . . . .
12.11Zusammenfassung .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
125
125
126
126
126
126
127
127
127
128
128
13 Epilog
13.1 Ergebnisse . .
13.2 Integration .
13.3 Perspektiven
13.4 Nachspiel . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
133
133
134
136
137
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A Beispiel-Szenario A
A.1 Szenario . . . . .
A.2 FML-Dokument .
A.3 FML-Graph . . .
A.4 Résumé . . . . .
B Beispiel-Szenario B
B.1 Szenario . . . . .
B.2 FML-Dokument .
B.3 FML-Graph . . .
B.4 Résumé . . . . .
138
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
158
158
160
161
162
.
.
.
.
.
.
.
.
.
.
.
.
164
. 164
. 166
. 167
. 168
C Spezifikation ’FML’
170
D Compiler
171
E Konvertierungsleitfaden XML → FML
174
E.1 Notwendige Maßnahmen . . . . . . . . . . . . . . . . . . . . . 174
E.2 Empfohlene Maßnahmen . . . . . . . . . . . . . . . . . . . . . 177
E.3 Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
F fml-graph.gxl.xsd
178
G fml.xml.xsd
183
x
H xml2fml.xslt
188
I
194
UML-Klassendiagramm
J Relationales FML-Datenbankschema
K Umfrage
K.1 Intention . . . . . . . .
K.2 Fragebögen . . . . . .
K.2.1 Interferenz . .
K.2.2 Kongruenz . .
K.2.3 Independenz .
K.2.4 Segmentierung
K.3 Ergebnisse . . . . . . .
K.3.1 Interferenz . .
K.3.2 Kongruenz . .
K.3.3 Independenz .
K.3.4 Segmentierung
K.4 Résumé . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
196
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
198
198
199
199
200
201
202
203
204
204
204
205
205
L FML-Internetressourcen
206
Glossar
208
222
xi
Kurzfassung
In dieser Arbeit wird mit der Freestyle Markup Language (FML) eine neue
Generation einer Auszeichnungssprache vorgestellt. Es werden die Anforderungen an die Sprache erarbeitet, es wird eine grammatikalische Definition
und ein korrespondierender Objektgraph präsentiert, sowie eine Referenzimplementierung vorgestellt. Das Ergebnis dieser Arbeit ist eine vollständige
Spezifikation der FML.
Die Extensible Markup Language (XML) hat sich heute als standardisertes Serialisierungsformat und universelle Transfersyntax auf breiter Front
durchgesetzt. XML erlaubt die Auszeichnung von Inhalten gemäß den Wohlgeformtheitskriterien (’properly nested’) nur in streng hierarchische Strukturen, – die Auszeichnung in nicht-hierarchische oder multi-hierarchische
Strukturen ist nicht sprachinhärent vorgesehen: Dieses Defizit ist ausreichend dokumentiert, und problematisch für viele Anwendungsszenarien. Darüber hinaus existieren weitere Restriktionen, welche in der Praxis einen uneingeschränkten Einsatz von XML erschweren, ein intuitives ’freihändiges’
Auszeichnen unterbinden.
Die Tatsache, dass Auszeichnungssprachen nicht mehr nur im ursprünglichen Sinne im typographischen Betrieb, sondern in der Überzahl und zunehmend für beliebige Datenstrukturen Anwendung finden, bekräftigt die
Notwendigkeit der Weiterentwicklung bisheriger markup-Standards, analog
zur Evolution von Datenstrukturen von Listen über Tabellenrelationen und
Bäumen, bis hin zu Graphen.
Die deskriptive Auszeichnungssprache FML konsolidiert bisherige Defizitdiskurse, Diskussionen und Lösungsansätze und wird ein ’freihändiges Auszeichnen’ über rein hierarchische Strukturen hinaus ermöglichen.
xii
Abstract
This paper provides a new generation of a markup language by introducing
the Freestyle Markup Language (FML). Demands placed on the language
are elaborated, a grammatical definition and a corresponding object graph
are presented and a reference implementation is introduced. The result of
this paper is a complete specification of FML.
Today, the Extensible Markup Language (XML) is broadly accepted as a
standardized serialization format and universal transfer syntax. XML allows the markup of content according to the well-formedness constraints
(’properly nested’) only in strict mono-hierarchical structures – markup in
non-hierarchical or multi-hierarchical structures is not inherently provided
in the language: This deficit is sufficiently commented and represents a problem for many application scenarios. Moreover, further restrictions exist
that complicate an unlimited use of XML in practice and prohibit an intuitive ’freestyle’ markup. The fact that markup languages are not only used
in the original sense in the typographic field but mostly and increasingly for
any data structures confirms the necessity to further develop present markup standards, in analogy to the evolution of data structures from lists via
table relations and trees up to graphs.
The descriptive markup language FML consolidates deficit discourses, discussions as well as solution approaches and will offer a ’freestyle markup’
beyond purely hierarchical structures.
xiii
Prolog
Die vorliegende Dissertationsschrift ist mit viel Sorgfalt und Herzblut entwickelt worden und fußt auf mehreren Jahren praktischer Erfahrung und
gründlicher konzeptioneller Vorarbeit. Sie ist das theoretische Fundament
angestrebter Weiterentwicklungen und soll über eine Promotion hinaus den
Fortschritt von Auszeichnungssprachen anregen.
Für akademische Unterstützung spreche ich folgenden Personen meinen herzlichen Dank aus:
• Prof. Dr. Hans-Jörg Kreowski, Bremen
• Dr. Andreas Witt, Mannheim
• Konrad Haase, Leipzig
• Dr. Ulrike Pondorf, Leipzig
• Manfred Jäger, Rotenburg (Wümme)
• Karina Worlton, Chicago, IL, USA
Für wirtschaftliche Förderung spreche ich folgenden Institutionen und Personen meinen herzlichen Dank aus:
• INFO AG, Hamburg
• Reemtsma Cigarettenfabriken GmbH , Hamburg
• Dr. Ulrike Pondorf, Leipzig
• Klaus-Frieder Landschulz, Merseburg
• Dr. Achim Klumbies, Jena
• Julia Walch, Bad Soden am Taunus
• Dr. Dirk Neubert, Leipzig
• Dr. Klaus-Dieter Matz, Leipzig
xiv
Kapitel 1
Einleitung
Aus kleinem Anfang
entspringen alle Dinge.
Marcus Tullius Cicero
106 v. Chr. – 43 v. Chr.
Die Fragestellung der Arbeit wird durch eine präzise Zieldefinition erläutert,
inhaltliche Grundlagen werden erörtert und es erfolgt eine Begründung der
Relevanz des Themas durch Darlegung seiner Potenziale. Konzeption, Vorgehen und Gliederungsaspekte der Arbeit werden vorgestellt, die persönliche
Beziehung zur Thematik wird eröffnet.
1.1
Zielsetzung
Das Ziel dieser Arbeit ist die Entwicklung der neuen Auszeichnungssprache
Freestyle Markup Language (FML)
Alle Anforderungsaspekte an die Sprache sollen identifiziert und erläutert,
eine grammatikalische Sprach- und Graphdefinition sowie ein Transformationsregelwerk zwischen beiden Repräsentationsformen erstellt werden. Auch
eine bidirektionale Abbildung in die die gegenwärtigen Systemlandschaften dominierende Sprache XML, auf der FML aufsetzt, soll erarbeitet werden. Mit der Intention, über eine theoretische Sprachdefinition hinaus eine
praktische Verwendung und unmittelbare physische Integration zu ermöglichen, soll eine valide Referenzimplementierung der Sprache FML in der
populären Programmiersprache Java entwickelt werden. Zwecks Sicherung
der Integrität der präsentierten neuen Auszeichnungssprache sollen alle Anforderungen als korrespondierende Eigenschaften von FML verifiziert werden. Darüber hinaus sollen primär relevante Sekundärtechnologien reflektiert werden, Vergleichsanalysen gegenüber dem aktuellen Forschungsstand
1
vorgenommen und zuletzt quintessenziell Ergebnisse, Integrationsmöglichkeiten und Perspektiven erörtert werden. Letztlich mündet dieser geplante
Lösungsweg in einer vollständigen und korrekten Spezifikation der neuen
Auszeichnungssprache FML.
Das Ziel besteht nicht darin, eine beliebige neue Auszeichnungssprache, derer
sich unendlich viele ad libitum konstruieren ließen, zu konstatieren, sondern
vielmehr, aktuelle Entwicklungen von Markup-Standards, kritische Reflexionen und öffentliche Diskurse wie [87] sowie perönlichen Erfahrungswerte
ergebnisorientiert in einer substanziellen Lösung intersubjektiven Fortschrittes zu konsolidieren.
Eine Erfüllung des Anspruches an Kommunikabilität und Veröffentlichungsgebot einer wissenschaftlichen Arbeit [70] soll überdies durch explizite Ergebnispräsentation in Form publizierter Sprachspezifikation und Implementierung auf einer auch postgradual gepflegten FML-Online-Plattform gefördert werden.
1.2
Grundlagen
Für ein umfassendes Verständnis der Intention, Realisierung und des Nutzwertes der gemäß Zielsetzung zu entwickelnden Sprache FML sind Kenntnisse von Konzept und Methodik von Auszeichnungssprachen, dem Themengebiet dieser Arbeit, notwendig. Die Arbeit baut auf etablierte formale
Sprachen – insbesondere der Sprache XML1 – auf und grenzt sich durch
eine Neuentwicklung, die in ihren Anforderungen bestehende Diskussionen
und Defizitdiskurse berücksichtigt, von anderen Ansätzen ab. Alle Inhalte
lassen sich in der theoretischen Informatik und Computerlinguistik in das
Fachgebiet formale Grammatiken einordnen. Es finden Methoden aus den
Spezialgebieten Compilerbau, Lexer, Parser und Graphersetzungssysteme
Anwendung.
Im Folgenden werden die Grundlagen von Auszeichnungssprachen im Allgemeinen und XML im Speziellen dargestellt.
Der Begriff Auszeichnen (Markup) meint die Betonung eines Textes durch
Änderungen im Erscheinungsbild [44] bzw. in der Satzherstellung das Hervorheben von Textteilen durch Unterstreichen, Sperren oder andere Schriftgrade oder -schnitte, Farbe und Negativdarstellung [137]. Tatsächlich dominierten Drucksatz und DTP-Anwendungen die Forschungslandschaft, und
die Erkenntnis “Markup has nothing to do with publishing“ [128] musste
lange reifen. Neben der typographischen Interpretation des Begriffes Auszeichnen kann man – allgemeiner formuliert – das Auszeichnen auch als ein
Markieren von Inhalten begreifen. Jede Markierung ist mit einer Semantik
1
Das Akronym XML findet in dieser Arbeit bezeichnenderweise ganze 448 mal Verwendung.
2
behaftet und wird mittels Tags (Markierungszeichen [19]) in ein Dokument
eingebettet. Einbettung und Separierbarkeit von Markup sind nach [126]
die beiden generellen Charakteristika für die Datenrepräsentationsform einer Auszeichnungssprache.
Die Evolution von Markup beginnt weit vor unterstützender Informationverarbeitung mit Computern und findet ihren Ursprung in der Typographie
und in Drucksatzsystemen, in der Integration von Verarbeitungsinstruktionen in Textdokumente durch Satz- bzw. Seitenbeschreibungssprachen.
Eine Sprachtaxonomie wurde erstmalig in [31] aufgestellt. Für Auszeichnungssprachen identifizieren sich – chronologisch geordnet – folgende Abgrenzungen:
1. Prozedurales Markup
2. Präsentations-Markup
3. Analytisches Markup
4. Generalisierendes Markup
5. Deskriptives Markup
Generalisierendes Markup [55] kennzeichnet sich durch Unabhängigkeit gegenüber einer Applikation oder eines konkreten Formatierungssystems aus
und wird durch deskriptive Ansätze gemeinhin impliziert. Im Gegensatz
wird das dokumentenzentrische Präsentations-Markup von Textverarbeitungssystemen als Basistechnologie für WYSIWYG-Ansätze zur Drucksatzvisualisierung verwendet. Analytisches Markup – ein historischer Begriff ohne
aktuelle Verwendung – untersucht Ontologien, zumeist linguistische. Durch
Auszeichnungen werden Texte und Daten semantisch strukturiert (deskriptiver Ansatz) oder Verarbeitungsinstruktionen eingebettet (prozeduraler Ansatz). Man unterscheidet heute primär lediglich die prozeduralen (PML)
von den deskriptiven (DML) Auszeichnungssprachen, wobei die prozeduralen Markup-Konzepte – die für diese Arbeit irrelevant sind – in ihrem
Verwendungsgrad deutlich in den Hintergrund getreten sind. Die deutliche
Entwicklungstendenz zu deskriptiven Auszeichnungssprachen wird von verschiedenen Informationsextraktionssystemen [163] unterstützt.
Deskriptive Auszeichnungssprachen sind als Datenbeschreibungssprachen konzipiert worden, damit Dokumente von Plattformen unabhängig sind und
zwischen verschiedenen Anwendungen bewegt werden können [1]. In der
Tat waren die Plattform-, Sprachen- und Herstellerunabhängigkeit Schlüsselkriterien für den Erfolg des De-Facto-Standards XML.
Anhand des folgenden Auszuges aus dem Synonymwörterbuch [104] – angereichert um eine Textunterstreichung – läßt sich das deklarative MarkupPrinzip gut veranschaulichen:
3
Reduziert man nun in einer abstrakten Betrachtung der Textpräsentation
die zu untersuchenden Eigenschaften auf die makrotypographischen Gestaltungsmerkmale
1. Schriftauszeichnung Fettschrift
2. Schriftauszeichnung Kursivschrift
3. Schriftauszeichnung U nterstreichen
und definiert die semantisch korrespondierenden Tags <bold>, <italic> und
<underline>, so gestaltet sich ein Markup-Dokument (in XML- und – um
vorzugreifen – FML-Notation) folgendermaßen:
01
02
03
04
05
06
07
08
09
10
11
12
13
<markup-document>
<bold>
1 markieren,
</bold>
anzeichnen,[...], märken
<italic>
(
<underline>
österr.
</underline>
),
</italic>
</markup-document>
Tags werden in das Dokument eingebettet und markieren Beginn und Ende
einer Schriftauszeichnung. Die sich hieraus ergebende hierarchische Dokumentenstruktur [50] wird durch die vorgenommenen Einrückungen illustrativ: Der Text “österr.“ ist Child von <underline>, welches Child von
<italic> ist, welches wiederum Child der Dokumentenwurzel (Root) <markupdocument> ist.
Auszeichnungssprachen wurden historisch primär durch den Einfluss der
• Typographie (beispielsweise [55])
• Linguistik (beispielsweise [108])
• EDI - und DTP-Systeme (beispielsweise [64])
in ihrer Entwicklung gestaltend geprägt und erlauben die Abgrenzung von
zwei Anwendungsperspektiven:
4
• Dokumentenzentrische Sicht
Verarbeitung semistrukturierter (Text-)Daten
• Datenzentrische Sicht
Verarbeitung semistrukturierter ERM -Daten
Primäres Motiv aller Auszeichnungssprachen war ursprünglich die Repräsentation von Dokumentstrukturen [5], die Unterstützung von Gestaltung und
Herstellung verschiedener Medien für einen betrachtenden Menschen. Populärstes Beispiel der Gegenwart ist HTML. [131] untersucht in einer Umfrage,
wie fundamental Textverarbeitungs-Software den traditionellen Prozess der
Buchherstellung [94] verändert hat. Aus diesem Bereich sind heute Auszeichnungssprachen nicht mehr wegzudenken. Sie bedienen in der dokumentenzentrischen Sicht als abstrakte Basistechnologie sehr lebendige Ergebnisse,
wie folgende Collage verschiedener Typographien aus [58] bekundet.
Mit Lancierung der generalisierenden Sprache XML vergrößerte sich signifikant das Einsatzspektrum. XML fungiert als Schnittstellen-Transfersyntax
und Serialisierungsformat auch für Daten ohne typographischen Hintergrund.
5
Beliebige Informationen werden ausgezeichnet, Markup ist nicht mehr nur
“Druck-Vorstufe“, sondern allgemeiner Datencontainer.
Dokumente sind Daten. Für eine generalisierende Auszeichnungssprache
impliziert der datenzentrische den historisch gewachsenen dokumentenzentrischen Ansatz. Ein typographisches Sprach-Schema wäre eine konkrete
FML-Anwendung, die nicht Gegenstand dieser Arbeit ist.
Der Gesamtbestand2 der Deutschen Nationalbibliothek liegt bei 25.343.348.
(Diese päzise Zahl täuscht allerdings Genauigkeit nur vor, da unvollständige Publikationen, mehrbändige Werke, unselbstständige Literatur, Sammelbände, Sitzungsprotokolle, etc. sehr differenziert für eine Bestandsquantifizierung bewertet werden und historisch wechselhaft bewertet wurden.)
Diesem Bestand an Druck-Unikaten seit dem Jahre 1913 stehen 13.578.487
.de-Domains3 seit dem Jahr 1989 gegenüber. Unterstellt man jeder Domain,
eine Online-Publikation auf Basis der Seitenbeschreibungssprache HTML zu
sein, so wird in diesem stark vereinfachten Vergleich deutlich, welchen Stellenwert Auszeichnungssprachen erlangt haben. Die auf Markup basierenden
elektronischen Medien, so unbeständig sie auch erscheinen, sind zumindest
im Volumen dem klassische Druck-Medium nahezu ebenbürtig. Die Anzahl
generierter datenzentrischer XML-Dokumente lässt sich nur sehr unscharf
abschätzen. So könnte man beispielsweise jedem einer ermittelten Anzahl
von Servern [88] ein Mindestmaß, vermutlich tausende, an Generierungsvorgängen täglich unterstellen. Es ist offensichtlich, dass das gigantische
Volumen datenzentrischer elektronischer Dokumente jeden Vergleich überflüssig erscheinen lässt.
2
3
Stand vom 31.12.2009, http://www.d-nb.de.
Stand vom 09.04.2010, http://www.denic.de.
6
Im Zeitalter computergestützten Satzes war nach verschiedenen proprietären
Formaten die Sprache GML der erste nennenswerte Versuch, einen übergreifenden Standard zu etablieren.
GML
Scribe
SGML
HTML
XML
1998
FML
2010
1991
1986
1978
1973
Während GML noch dem dokumentenzentrischen Ansatz folgte und Textverarbeitungsprogramme unterstütze, war der darauf folgende Standard
SGML universeller einsetzbar. Die bekannteste SGML-Anwendung ist
HTML, die lingua franca des Internets. Die ursprüngliche Kernintention
von SGML ist es, keinerlei prozedurale Verarbeitungsinformationen in Dokumente und Daten einzubauen, um sicherzustellen, dass diese Inhalte zeitinvariant die stets im Wandel befindlichen und kurzlebigeren verarbeitenden Anwendungen überleben. Akzeptanzprobleme ließen diesen für viele
Anwendungsbereiche zu komplexen Standard durch die Sprache XML, einer
Weiterentwicklung und strengen Untermenge von SGML, ablösen.
Unmittelbar nach Veröffentlichung der Spezifikationen des W3C [186] konnte
sich XML bereits 1999 als Transfersyntax für den Austausch von Daten im
Rahmen von EDI -Systemen behaupten [171]. XML hat sich als offener Standard zur führenden Technologie für den Datenaustausch zwischen Informationssystemen etabliert. Eine neue Generation serviceorientierter Architektur, die auf den XML-Transferprotokollen SOAP und WSDL [192] basiert,
verdankt ihren Durchbruch diesem Standard. Offene XML-basierte Dokumentenformate für Textverarbeitungen befinden sich in lebhafter Enwicklungsphase [135] und erhalten eine dokumentenzentrische Perspektive [59].
Software-Technologien mit hoher Systemintegration und Reife basieren auf
deklarativer XML-Programmierung [167]. Die Tatsache “Plattformunabhängige Standards wie XML sind bei allen Editoren im Programm“ [110]
kennzeichnet den hohen Grad an Anwendungsintegration. Und nicht zuletzt
XHTML – die essenzielle Beschreibungssprache für Internetpublikationen
mit einem gegebenen Verwendungsgrad von 58,1%4 – bestätigt Akzeptanz
und Erfolg der W3C -Spezifikationen.
XML zeichnet sich nach nunmehr zehn Jahren als Standard durch einen sta4
Stand vom 11.09.2009, W3Techs.
7
bilen Reifegrad aus, hat viele Technologien elementar angeregt und durchdrungen, ist Schlüsselqualifikation in der IT [102]. Da FML technologisch
auf der Sprache XML basiert, deren verzichtbare Konstrukte eliminiert, diese
um in Diskussionen gefragte Funktionalitäten ergänzt und gleichzeitig die
Anforderung weitestgehender XML-Kompatibilität aufstellt, ist eine Auseinandersetzung mit dem Sprachstandard XML einem umfassenden Verständnis dieser Arbeit sehr förderlich.
Für eine fundamentale Einführung in Intention, Möglichkeiten und Grenzen von Auszeichnungssprachen empfiehlt sich [126]. Für einen Einstieg
in die Sprache XML und ihre Sekundärtechnologien aus datenzentrischer
Sicht eignet sich [18], für ein pragmatisches Referenzhandbuch [60], für
eine anwendungsbezogene Lektüre aus dokumentenzentrischer Sicht [107]
und für fortgeschrittene Analytiker [204] und [101]. Mit der Arbeit von
XML-Prozessoren beschäftigt sich [52]. Der fulminante ökonomische, politische und kulturelle Einfluss von Auszeichnungssprachen im Allgemeinen
und XML im Speziellen wird ergiebig in [147] diskutiert.
1.3
Relevanz
Eine aktuelle Hommage [11] an 10 Jahre XML fasst den Status quo zusammen:
[. . . ]hat die Sprache in den vergangenen zehn Jahren Einlass in
fast alle wirtschaftlichen und technischen Zweige gefunden. [. . . ]
Für die Zukunft ist noch einiges zu erwarten. Ob digitale Signaturen oder Datenbanksysteme, Webservices oder Formulare,
überall steckt XML drin[. . . ]
Gleichsam deutlich die Beurteilung der Firma IBM [147]:
What started out as a simple standard for electronic publishing
has matured into one of the most important an widely used paradigms in distributed computing. The impact and influence of
the standard and the conceptual base are visible in every area of
computing today.
Da FML auf XML aufsetzt und diese Sprache funktional erweitert, ist die
technologische Relevanz von FML folglich gleich der gegenwärtigen von
XML.
Die Software AG, im Jahr 2000 weltweiter Marktführer für XML-Datenbanken, geht in ihrem Unternehmensbericht [149] auf die ökonomische Relevanz
des damals noch sehr jungen Standards XML ein:
The interest and the willingness to invest in professional IT solutions based on the new Internet standard XML is constantly
8
growing. According to a new study by International Data Corporation (IDC), the market for XML databases will expand at
an annual growth rate of over 100% and will amount to around
EUR 700 million in 2004 worldwide.
Noch fulminanter die Bewertung allein eines Anwendungsfalles von MarkupStandards aus [82]: Der ökonomische Nutzwert von HL7 für den medizinischen Datenaustausch kumuliert sich durch gesteigerte Interoperabilität auf
weltweit jährlich US$ 80 Milliarden.
Neben der technologischen und ökonomischen Frage stellt sich die nach der
intentionalen und inhaltlichen Relevanz der in dieser Arbeit konstruierten
Sprache FML: Warum bedarf es neben XML einer neuen Auszeichnungssprache? Sind die Ergebnisse ein Beitrag zum Stand der Wissenschaft?
Die Sprache XML feiert gerade ihr zehnjähriges Bestehen. Als Transfersyntax und Serialisierungsformat hat sie sich erfolgreich über alle Bereiche –
insbesondere im Web-Umfeld – als offener Standard durchgesetzt.
Dennoch eröffnen sich bei kritischer Reflexion und während der praktischen Entwicklungsarbeit über verschiedene Anwendungsszenarien gravierende Limitierungen der Sprachspezifikation. Überlegungen bzgl. Erweiterung und Verbesserung dieses Sprachstandards sind gerechtfertigt und
nach zehn Jahren XML auch geboten. Entgegen der Evolution der Datenstrukturen [41] von primitiven Datentypen über einfache und verkettete
Arrays, Stacks, Queues über hierarchische Strukturen bis hin zu einfachen
und komplexen Graphen verharrt die Auszeichnungssprache XML auf einer
inhärenten Strukturebene der einfachen Hierarchie. Datenzentrische Markup-Anwendungen müssen ebenso verharren. Auch Dokumentenzentrische
Anwendungen können sich unter Hierarchiezwang nicht frei entfalten, da
sich – nach den Untersuchungen in [207] – Dokumente in einen Kontext
von Verbindungen, die miteinander interferieren, einreihen und sich erst in
dem Wissensmodell eines Rhizoms [61] von hierarchischen Machtstrukturen
befreien können. Betrachtungen über die komplexen Ordnungssysteme in
Dokumenten werden lebendig von [54] geführt:
These pieces won’t halt: the boundary of a book is less than air to
them. These pieces wink at each other, they shnoogle sighingly,
they meet to confer, they part, they wave adieu and zip toward
different mental planet zones, they reproduce, they tease us with
coherence, they grimace and coil about and finagle, they repeat
one another, they flaunt, they taunt, they sail away. Maybe only
a deity – if deities exist – explains (or is) these splinters’ unity.
Für eine strenge Ordnungsrestriktion in Auszeichnungssprachen besteht technologisch keine zwingende Rechtfertigung, und es ist perspektivisch unwahrscheinlich, dass diesbezüglich alles so bleiben wird, wie es jetzt ist.
9
Mehrere vergleichbare wissenschaftliche Arbeiten (s. Kap. 12), jünger als
XML, setzen sich insbesondere mit diesem Defizit auseinander, aber auch
mit weiteren Limitierungen, die zum allergrößten Teil in dieser Arbeit berücksichtigt werden können.
Gegenwärtig geht die Forschung nicht über theoretische Diskurse und Absichtserklärungen hinaus. Eine konkrete alternative Sprachspezifikation und
Referenzimplementierung existiert nicht bzw. wurde nicht stringent zu einer ergebnisorientierten Lösung geführt. Insofern ist der Zeitpunkt günstig,
hier mit Blick auf künftige weitere Entwicklungen die Rolle des Protagonisten jetzt im wissenschaftlichen Wettbewerb zu besetzen.
1.4
Potenziale
XML ist ein erfolgreicher Standard. FML würde weitestgehend alle Anforderungen erfüllen können, denen auch XML gerecht werden kann, aber
darüber hinaus Limitierungen aufheben und Erweiterungen anbieten, die
XML auch absehbar nicht wird leisten können, da es durch die Anforderung
der SGML-Kompatibilität gebunden ist, obgleich kaum noch praktische Anwendungen des obsoleten Standards SGML existieren. Durch diese Schranke
der Abwärtskompatibilität kann selbst progressivste Weiterentwicklung nur
zu einem reaktionären Ergebnis führen. Insofern ergeben sich für die in dieser Arbeit begründet konstatierte neue Sprache FML die Potenziale eines
breiten Anwendungsspektrums: Alle Szenarien, die die rein hierarchische
Sprache XML nicht ohne Einschränkungen verwenden können, profitieren
von einer schöpferischen Neuentwicklung. Anwendungen und Entwickler,
die sich indolent mit dem Status quo arrangiert haben, werden zur Optimierung angeregt.
Es lassen sich vielfältige Anwendungsbereiche benennen, die von der innovativen und neuen Sprache FML profitieren würden: Wissensrepräsentation,
Informationsstrukturierung und Transfersyntax, redundanzfreies Serialisierungsformat für verschiedene Perspektiven innerhalb eines Dokumentes, native typographische Editoren etc. Praktischer Bezug und reale Nutzbarkeit
sind – obgleich auf Ebene einer abstrakten Basistechnologie – gegeben.
Eine klare Vision mit einer technischen Umsetzung stellt natürlich noch
nicht die Etablierung einer neuen Technologie sicher. Hierfür sind verschiedene Faktoren wie Akzeptanz, Verfügbarkeit, Anwendungsszenarien,
Einarbeitungs- und Migrationsaufwand, Kompatibilität, Integrationsfähigkeit, Standardisierung, Wartung, Produktunterstützung relevant.
Mit dieser Arbeit wird der Grundstein für eine Diskussion und Weiterentwicklung einer neuen Auszeichnungssprache, deren Potenziale begründet
vorhanden sind, gelegt.
10
1.5
Organisation
Begriffsklärung
Der Arbeitstitel “Freestyle Markup Language“ setzt sich zusammen aus den
Begriffen “Freestyle“ (Freistil) und “Markup Language“ (Auszeichnungssprache). Der Begriff “Freestyle“ wurde gewählt, um den Anspruch der Sprache,
ein intuitiv-freihändiges Auszeichnen zu ermöglichen, zu kennzeichnen. Das
Freistil-Auszeichnen überwindet als Weiterentwicklung des Standards XML
dessen Restriktionen: Im Arbeitstitel werden insbesondere die restringierenden Wohlgeformtheitskriterien von XML, die ein ’freihändiges’ Auszeichnen
unterbinden (s. Kap. 2.4 und 2.7), angesprochen.
Im Untertitel “Spezifikation einer polyhierarchischen Auszeichnungssprache“ wird, obgleich auch von Entwicklung, Evaluierung, Implementierung
etc. gesprochen werden könnte, bewusst der Begriff “Spezifikation“ verwendet, da eine konsistente Spezifikation (s. Anhang C) gemäß Zielsetzung (s.
Kap. 1.1) das wesentliche Ergebnis der Arbeit ist.
Viele verschiedene Merkmale kennzeichnen die Sprache FML, dennoch wird
im Untertitel ausschließlich die Eigenschaft “polyhierarchisch“ – die in Kapitel 2.7 behandelt wird – betont, da diese ein viel diskutiertes prägnantes Schlüsselmerkmal aktueller Relevanz darstellt. Mit synonymer Bedeutung finden in der Linguistik und Informatik auch die Begriffe “multihierarschisch“, “mehrfach strukturiert“, “mehr-“ und “multidimensional“ und “multipel annotiert“ Verwendung.
Konvention
Es werden neben der Standardtextformatierung drei weitere verwendet:
• Glossareintrag:
Deutsch- und englischsprachige Fachbegriffe, technische Abkürzungen,
relevante Eigennamen, akademische Einrichtungen und Wirtschaftsinstitutionen. Für die für diese Arbeit relevanten Begriffe existieren
korrespondierende Einträge im Glossar.
• Betonung:
Markante Erkenntnisse, Aussagen oder Textfragmente.
• Source:
Wörter bzw. Quelltexte der technischen Sprachen SGML, XML, FML
und Java in Form von Definitionen, Erklärungen und Beispielen.
• http://www.freestyle-markup.org:
URI zur Lokalisierung eines Referenz-Dokumentes im Internet.
Teilweise können sich diesen Formatierungen auch überlagern – die Sprachanforderung Interferenz (s. Kap. 2.4) veranschaulichend.
11
Dieses Dokument wurde selbst mit einer Auszeichnungssprache, mit LaTeX , verfasst, mittels MiKTeX 2.7 und TeXnicCenter 1.0 konsistent in
das plattformunabhängige Format PDF comiliert und ist, wie im Anhang L
beschrieben, unter http://www.freestyle-markup.org/thesis.pdf publiziert. Es
ist garantiert, dass das Dokument fehler- und warnungsfrei compiliert und
stilistisch homogen ist und für das elektronische PDF -Dokument alle Hyperlinks5 für interne (Literatur-, Kapitel- und Glossarverweise) und externe
(Literatur-, Institutions- und Plattformverweise) Referenzen vollständig und
zum 11. Juli 2011 korrekt sind.
Die für Markup-Szenarien angewendeten Beispieltexte sind allesamt [105]
entnommen.
Es wird konsistent die für Universitäten verbindliche neue deutsche Rechtschreibung mit Stand vom 1. August 2006 verwendet.
Gliederung
Alle Gliederungspunkte isolieren Inhalte, grenzen sich voneinander ab und
bauen aufeinander auf. Es wird empfohlen, die Kapitel in Reihenfolge der
Gliederungsordnung zu lesen. Wo notwendig sind im Text Gliederungsreferenzen vorgesehen.
Das Gliederungskonzept erklärt sich durch folgende Kurzbeschreibung der
Kapitelinhalte:
Kapitel 1: Einleitung Intention, Motivation und Benefits der Arbeit
werden einleitend erörtert. Ziel ist es, den Leser mit Grundlagen, Inhalt
und Aufbau der Arbeit vertraut zu machen, ihn zu befähigen, die Thematik
in die Forschungslandschaft inhaltlich und technologisch einzuordnen, das
Fundament für ein gutes Verständnis aller folgenden Kapitel zu bilden.
Kapitel 2: Anforderungen Darlegung der verschiedenen Anforderungen an Auszeichnungssprachen im Allgemeinen und an die Sprache FML im
Speziellen. Da diese Forderungen nach erfolgter Sprachdefinition gleich der
Spracheigenschaften sein werden, wird in derselben Untergliederungsstruktur in Kapitel 10 beweisführend hierauf Bezug genommen. Schwerpunkt
dieses Kapitels sind die präzise Identifizierung, Evaluation und anschauliche
Begründung aller geforderten FML-Spracheigenschaften. Nicht zuletzt die
hohe Literaturreferenzdichte dieses Kapitels 2 signalisiert breite und tiefgründige vorbereitende konzeptionelle Vergleichsanalysen (s. Kap. 12) und
Erfahrungswerte, die zur Sprachdefinition im Kapitel 4 führen.
5
Verifiziert für Adobe Acrobat Reader, Version 9.3.
12
Kapitel 3: Architektur
Sprache FML.
Skizzierung der technologischen Architektur der
Kapitel 4: Freestyle Dokument Die Sprache FML wird syntaktisch,
terminologisch und semantisch konstatiert. Dieses Kapitel wird gekennzeichnet durch formale Prägnanz und ist Vorläufer der Spezifikationen im
Anhang C. Auf eine aus den in Kapitel 2 beschriebenen Anforderungen
folgende konzeptionelle Entwicklung, die zu dieser Sprachdefinition führt,
wird nicht eingegangen. Alle in Kapitel 2 erarbeiteten Anforderungen werden uneingeschränkt berücksichtigt, wie später in Kapitel 10 gezeigt wird:
Die konzeptionelle Substanz dieser konstituierenden as-is-Sprachdefinition
verifiziert sich somit erst mit der Beurteilung der Sprachintegrität (s. Kap.
10).
Kapitel 5: Freestyle Graph Der aus den Komponentenbeziehungen aus
Kapitel 4 resultierende Graph wird in seinen Eigenschaften beschrieben.
Hiermit wird insbesondere die Anforderung einer Graphrepräsentation (s.
Kap. 2.12) bedient. Dieser Graph baut auf der Sprachdefinition im Kapitel
4 auf und ist elementare Voraussetzung für das folgende Kapitel 7 sowie
Grundlage für das Klassendiagramm im Kapitel 9.
Kapitel 6: Freestyle Konzepte Die wesentlichen Konzepte des Auszeichnens mit der FML werden erläutert und mit Beispielszenarien illustriert. Sowohl die Sprachdefinition von FML-Dokumenten (s. Kap. 4)
als auch der FML-Graph (s. Kap. 5) finden Anwendung.
Kapitel 7: Transformation Die Transformation zwischen einem FMLDokument und einem FML-Graphen wird untersucht. Die Ergebnisse von
Kapitel 4 und Kapitel 5 werden somit durch ein Regelwerk zur vollständigen und eindeutigen bidirektionalen Transformation vereint: Zu jedem
FML-Dokument existiert ein korrespondierender FML-Graph (Graphkomposition, Kapitel 7.1), und zu jedem FML-Graph existiert ein korrespondierendes FML-Dokument (Graphdekomposition, Kapitel 7.2). Dieses Kapitel
bereitet die Implementierungsprozesse der Serialisierung und Deserialisierung in Kapitel 9 vor.
Kapitel 8: XML-Repräsentation Eine Repräsentation eines FML-Dokumentes im XML-Serialisierungsformat wird erarbeitet. Dieser Entwicklungsschritt dient der Kompatibilitätsanforderung (s. Kap. 2.2).
Kapitel 9: Implementierung Die Anforderung aus Kapitel 2.18 wird
mit der Präsentation einer Referenzimplentierung, basierend auf der FML-
13
Spezifikation und den in Kapitel 7 beschriebenen Ergebnissen, bedient. Theoretische Vorarbeit wird zur Praxistauglichkeit geführt.
Kapitel 10: Integrität Alle in Kapitel 2 erarbeiteten Anforderungen
werden hier in derselben Gliederungsstruktur und auf Grundlage der Erkenntnisse aus den Kapiteln 4 – 9 als Eigenschaften einer integeren Sprache
FML beschrieben.
Kapitel 11: Sekundärtechnologien Für die weitere Entwicklung notwendige Technologien werden identifiziert. Nachfolgende und aufbauende
wissenschaftliche Arbeiten setzen hier an.
Kapitel 12: Vergleichsanalyse Wissenschaftliche Arbeiten, die einer
vergleichbaren Zielsetzung (s. Kap. 1.1) folgen, werden analysiert, Spracheigenschaften (s. Kap. 10) verglichen.
Kapitel 13: Epilog Die Kapitel 2 – 12 werden in diesen Schlussbemerkungen zusammengefasst und alle Ergebnisse dieser Arbeit der Zielsetzung
(s. Kap. 1.1) gegenübergestellt.
Anhang A: Beispiel-Szenario A Ein dokumentenzentrisches Szenario
wird beispielhaft exerziert. Alle Arbeitsergebnisse vorangegangener Kapitel
fließen in dieses Exempel anschaulich ein. Die Sprachaspekte aus Kap. 10
werden sondiert.
Anhang B: Beispiel-Szenario B Ein datenzentrisches Szenario wird
beispielhaft exerziert. Alle Arbeitsergebnisse vorangegangener Kapitel fließen in dieses Exempel anschaulich ein. Die Sprachaspekte aus Kap. 10
werden sondiert.
Anhang C: Spezifikation ’FML’ Gemäß der Anforderung aus Kapitel
2.19 ist hier die vollständige Spezifikation der Sprache FML, vorbereitend
einer externen separaten Anwenderpublikation, ausgelagert. Alle Ergebnisse der Kapitel 2 – 12 fließen hier mit ein, besonders hoch jedoch ist die
inhaltliche Deckungsgleichheit zur Sprachdefinition (s. Kap. 4).
Anhang D: Compiler Ein Konfigurationsskript zur Generierung eines
FML-Scanners und -Parsers wird präsentiert.
Anhang E: Konvertierungsleitfaden XML → FML Migrationsrichtlinien und -empfehlungen für eine erfolgreiche Konvertierung von XMLDokumenten in die Technologie FML werden in Form konkreter Handlungsanweisungen zusammengefasst dargestellt.
14
Anhang F: fml-graph.gxl.xsd Der in Kapitel 5 definierte FML-Graph
wird mittels der Graphbeschreibungssprache GXL in einem Schemadokument formal beschrieben.
Anhang G: fml.xml.xsd Ein XSD-Dokument, ausgelagert aus Kapitel
8, das die XML-Repräsentation eines FML-Dokumentes formal beschreibt
und validiert.
Anhang H: xml2fml.xslt Dieses XSLT -Dokument, bei dem es sich um
einen aus Kapitel 8 ausgelagerten Anhang handelt, konvertiert die XMLRepräsentation eines FML-Dokumentes zurück in das ursprüngliche FMLDokument.
Anhang I: UML-Klassendiagramm In UML-Notation wird das Modell
der FML-Implementierung dokumentiert und visualisiert.
Anhang J: Relationales FML-Datenbankschema Gemäß den Ausführungen bzgl. einer notwendigen Sekundärtechnologie Freestyle Datenbank
(s. Kap. 11.6) wird ein relationales Datenbankschema zur Persistierung von
FML-Instanzen präsentiert.
Anhang K: Umfrage Intention und Ergebnis einer Umfrage zur Evaluation der Freestyle-Kernkonzepte der Sprache FML werden dargelegt. Alle
Dokumente der Befragung werden veröffentlicht.
Anhang L: FML-Internetressourcen Die dieser Dissertationsschrift
fortdauernde Online-Publikationsplattform wird mit ihren gegenwärtigen
und perspektivischen Inhalten und ihrer Intention vorgestellt.
Zu Beginn eines jeden Kapitels und Anhanges wird stets einleitend der Inhalt zusammengefasst.
15
1.6
Qualifikation
Da die Entwicklung einer modernen Auszeichnungssprache Kompetenz und
Erfahrung erfordert, ist die Frage nach meiner persönlichen Motivation und
fachlichen Qualifikationen als Autor berechtigt.
Bereits während des Studiums der Informatik habe ich mich mit Auszeichnungssprachen beschäftigt und im Rahmen meiner Diplomarbeit [120] mit
den Standards XML [186] und XSD [179] intensiv auseinandergesetzt. Verschiedene Beiträge und Diskussion wie [87] oder [205] über Möglichkeiten
und Restriktionen von Auszeichnungssprachen und ihrer Weiterentwicklung
verfolge ich bereits seit Jahren mit großem Interesse.
Beruflich arbeite ich branchenübergreifend an Konzeption, Entwicklung und
Wartung verschiedener Enterprise-Applikationen zur Generierung von Dokumentationen und Komissionierformularen (Lettershop) in den Bereichen
Customer Relationship Management und Business Continuity Management.
Im Berufsalltag bin ich gegenüber verschiedenen Lösungsanforderungen somit neben den Standardtechnologien XML [186], XSD [179], XPath [183]
und XSLT [185] insbesondere mit den typographischen Beschreibungssprachen XSL-FO [181] und XHTML [176] konfrontiert.
Die erworbenen Zertifikate “Software AG Certified XML Engineer“, “Sun
Certified Java Programmer“ (SCJP6 ) und “OMG Certified UML Professional“ (OCUPF ) sind insbesondere einer professionellen Umsetzung der
Referenzimplementierung förderlich.
16
Kapitel 2
Anforderungen
Die Erfahrungen sind wie die
Samenkörner, aus denen die
Klugheit emporwächst.
Konrad Adenauer
1876 – 1967
Alle Forderungen an die Sprache FML werden benannt, erörtert und insbesondere durch die Anführung relevanter Defizite des gegenwärtigen Standards XML begründet. Das somit erstellte Profil divergenter Anforderungen
ist verbindlich für alle folgenden Entwicklungsschritte, führt letztlich zu den
Eigenschaften der Sprache und mündet in einer Sprachspezifikation gemäß
Zielsetzung dieser Arbeit. FML muss allen hier erarbeiteten Ansprüchen
gerecht werden.
2.1
Grammatik
Natürliche Sprachen beruhen auf Vereinbarungen, Annäherungen, Nachahmungen und Analogien und sind stetem Wandel unterworfen. Im Gegensatz
dazu sind konstruierte Sprachen – im Speziellen formale Sprachen – frei von
Zweifelsfällen und temporären Veränderungen und basieren auf einer erzeugenden formalen Grammatik.
Für die Syntax der Sprache FML muss ein präzises Regelwerk definiert werden. Nur eine klare Sprachgrammatik ermöglicht eine maschinelle Auswertung von Sprachinstanzen. Analog zur XML-Spezifikation [186], die zur
Syntaxbeschreibung eine EBNF präsentiert, benötigt auch FML eine formale Grammatik. Jedes FML-Dokument muss durch Ableitungsfolgen syntaktisch konstruiert sowie durch einen Automaten als wohlgeformt erkannt
werden können.
17
2.2
Kompatibilität
Für Akzeptanz und Migration der neuen Technologie FML ist Aufschluss
über Kompatibilität gegenüber dem präpotenten Standard XML entscheidend.
Mit FML werden neue Markup-Konstrukte, die XML weder vorgesehen
hat noch vorbereiten konnte, eingeführt. Auch werden kritische XMLKonstrukte, insbesondere diejenigen, die wider ihrer Gebrauchstauglichkeit
oder ihres faktisch geringen Einsatzgrades durch den SGML-Kompatibilitätsanspruch erhalten werden mussten, zugunsten der Anforderungen Entropie (s. Kap. 2.15) und Ergonomie (s. Kap. 2.16) ungerührt abgerissen.
Andererseits bleiben in FML anerkannte und bewährte XML-Muster erhalten. So gibt es nicht den geringsten Anlass, transparentes In-Line-Markup
um komplexe Stand-Off-Konstrukte (s. Kap. 12.11) anzureichern, oder
die etablierten Begrenzungssymbole für eingebettetes Markup (’<’ und ’>’)
durch andere zu ersetzen. Wohl aber gibt es beispielsweise Anlass [188] [40],
die obsoleten und Unsicherheit stiftenden CDATA-Sections zu eliminieren.
Somit kann ein wohlgeformtes FML-Dokument ein wohlgeformtes XMLDokument sein, muss es aber nicht. Ebenso kann ein wohlgeformtes XMLDokument ein wohlgeformtes FML-Dokument sein, muss es aber nicht. Es
kann nicht der Anspruch nach Kompatibilitätsgarantie – weder für Aufwärtsnoch für Abwärtskompatibilität – gestellt werden!
Entscheidend für die Kompatibilitätsanforderung ist, dass klar identifiziert
werden kann, welche XML-Komponenten und -Methoden übernommen werden können und welche nicht. Ein detailierter Migrationsleitfaden soll für
notwendige und empfohlene Konvertierungsmaßnahmen Handlungskompetenz gewährleisten.
Der technologische Abstand zu XML ist durch Aufstellung einer XMLRepräsentation für FML-Dokumente mitsamt bidirektionalem Transformationsleitfaden zu verkürzen.
Zudem ist ein verbindliches Konzept für eine Kompatibilität zwischen FMLDokumenten konform zu dieser ersten Spezifikation und perspektivisch folgenden Versionen festzulegen.
2.3
Monohierarchie
Obgleich in [36], wie auch in zahlreichen anderen computerlinguistischen
Diskussionen, festgestellt werden konnte
[. . . ]we now know that the breaking of strict hierarchies is the
rule, rather than the exception
18
muss es auch einer neuen polyhierarchischen Sprache selbstverständlich nach
wir vor möglich sein, Monohierarchien1 in gewohnter Weise zu strukturieren.
Polyhierarchie impliziert Monohierarchie, insofern ist die aufgestellte Anforderung nicht sonderlich spektakulär. Jedoch ist das heutige Denken durch
das von [35] geprägte Akronym OHCO und mereologischer Wissensrepräsentation derart durchdrungen, dass man allein aus Akzeptanz- und Kompatibilitätsgründen der unvollständigen Annahme
[. . . ] we can describe a text as an “ordered hierarchy of content
objects“
explizit Rechnung tragen muss:
FML soll in einer zu SGML/XML vergleichbaren Art und Weise Hierarchien
kodieren und interpretieren. Falls ein FML-Dokument eine monohierarchische Struktur aufzeigt, so muss dieser Zustand durch ein Zustandsmerkmal
gekennzeichnet werden.
2.4
Interferenz
Die Anforderung Interferenz, die unter den Begriffen Crossover-Markup,
Concurring-Markup und Overlapping-Markup diskutiert wird, spricht eine
der problematischsten Limitationen der streng hierarchisch orientierten Sprache XML an. Das Defizit wird von [37] auf den Punkt gebracht:
Markup under any SGML/XML convention is unable to easily
represent arbitrary structures or to represent overlapping or concurrent structures.
Entgegen früherer Thesen zeigte [130], dass Text nicht uneingeschränkt als
eine Hierarchie von Inhaltsbausteinen interpretiert werden darf. [136] fasst
diese Tatsache zusammen:
Indeed, it is now generally recognised that literary and linguistic texts frequently or even predominantly exhibit overlapping
structures.
Die Elemente eines Dokumentes müssen sich nicht in einer hierarchischen
Ordnung befinden. In [125] werden die Anforderungen an eine logische Dokumentenstruktur untersucht. Fazit: Komponenten eines Dokumentes können – im Gegensatz zu denen eines Softwareprogramms – nicht ausschließlich
in einer Baumstruktur repräsentiert werden. Jahre vor der Etablierung von
XML wurde bereits die Bedeutung einer perspektivischen Lösung des Interferenzproblems erkannt2 :
1
In einem monohierarchischem Graphen ist ein Knoten entweder Root und hat keine
Parents oder er ist nicht Root und hat genau ein Parent.
2
David Durand in Google Group comp.text.sgml, Mai 1993.
19
In my opinion this sort of non-hierarchical tagging is the next
frontier for markup systems. There are things that just don’t fit
well into the single-stream hierarchical model of SGML.
Mit dieser Thematik setzen sich insbesondere [200], [203] und [33] auseinander. In [34] werden bestehenden Lösungsansätzen (s. Kap. 12) Evaluationskriterien gegenübergestellt. Da Interferenz eine Implikation der Independenz (s. Kap. 2.7) ist, werden oftmals beide Anforderung in derselben
Problemstellung zusammengefasst.
Nimmt man – um ein illustratives Beispiel anzubringen – die Aussage „Nur
eines darf man nicht [. . . ] wenn ein Pichador den anderen überrollt, also auf
eine Originalmarkierung etwas anderes sprüht, [. . . ] fehlender Respekt, das
darf auf keinen Fall sein. [. . . ] seine eigenen Stellen finden [. . . ]“ von Djan
Ivson da Silva aus [169] für bare Münze, schreiben die hierarchisch in Gangs
organisierten Pichadores aus Brasilien („São Paulo ist vollgeschmiert - Typographien, Logos, Tags.“) ihrem Ehrenkodex getreu Graffitis stets nur auf
freie Flächen, andere Künstler respektierend. In einer Abstraktion, die den
Sachverhalt auf das Verhältnis zwischen Gruppierung, Autor und Zeichenuntergrund reduziert, ergibt sich demnach folgende Annahme: Jeder mm2
einer Hausfassade ist stets das Child maximal eines Künstlers, ein Künstler
das Child maximal einer Gruppierung. Mehrere Künstler können in einer
Parent-Child-Beziehung nicht dieselbe Fläche beanspruchen, mehrere Gangs
nicht denselben Künstler.
Gewiss existieren auf synthetischer Modellierung und starker Abstraktion
basierende rein hierarchische Szenarien. Auch ist die Suche nach genormten
monohierarchischen Ordnungsstrukturen, wie in [53] und [208], multidisziplinar ein Anreiz für jeden Ordnungssinn. Jedoch kann die Semantik eines
auszuzeichnenden Dokumentes auch deutlich komplexer und eine Strukturreduktion auf eine Monohierarchie nicht ohne Informationsverlust möglich
sein. Die Übersetzung einer Struktur in eine schwächere führt zwangsläufig
zu einem Abbildungskonflikt.
Der Inhalt eines Beispieldokumentes sei folgende Zeichensequenz:
A man, a plan, a canal: Panama!
Eine Anreicherung des Inhaltes um die beiden typographischen Merkmale
italic und blue
führt zu der neuen Dokumentstruktur
italic
blue
20
Kodiert man nun Start und Ende der Auszeichnungen italic (Tag-Name: i)
und blue (Tag-Name: b) mit XML-Notation3 in den Inhalt an die entsprechende Start- und Endposition, so ergibt sich folgendes Markup-Dokument:
A man, a plan, a canal: Panama!
Ein Interferenzkonflikt entsteht hier aus der Tatsache, dass ein Inhaltsfragment sowohl das Merkmal italic als auch blue besitzt, canal Child von zwei
sich überlagernden Auszeichnungen ist, die natürliche Dokumentstruktur
sich nicht mehr ohne Umbrüche in einer Monohierarchie darstellen lässt.
In HTML/XHTML würde man denselben Sachverhalt strukturell wie folgt
fragmentiert kodieren4 :
A man, a plan, a canal: Panama!
Diese Fragmentierung liefert zwar eine Monohierarchie und erfüllt den XMLStrukturanspruch, spiegelt jedoch nicht den realen Sachverhalt, der sich
hieraus nur unsicher rekonstruieren ließe, wider. Das Einfügen von Inhalt
zwischen und ist äußerst kritisch: Eine ’Formatierungslücke’
kann Inkonsistenzen entstehen lassen. Fragmentierung ist eine unsichere
und umständliche Hilfskonstruktion. Dasselbe gilt auch für andere Lösungsansätze (s. Kap. 12) wie das Meilenstein-Verfahren, dessen umständliche
Handhabung in [48] illustriert wird.
Für FML sind bestehende Workarounds wie Fragmentierung als gängige
Praxis für HTML-Dokumente indiskutabel, da sie den Kriterien Entropie
(s. Kap. 2.15) und Ergonomie (s. Kap. 2.16) widersprechen, nicht die
Realität abbilden und unsicher oder schwer zu interpretieren sind. Auch
virtuelle Konstruktionen, Stand-Off-Ansätze und Redundanzkodierung sind
keine Lösung.
Markup-Interferenz muss in FML natürlich und intuitiv durch eingebetteten
Code sprachinhärent umgesetzt werden können. Zugunsten Transparenz,
Wartungsaufwand und Zuordnungssicherheit sollen alle Inhalte unmittelbar
in einem Dokument konsolidiert verwaltet werden können.
2.5
Identifizierung
Entscheidend für die Interpretation eines FML-Dokumentes ist die Identifizierung korrespondierender Start- und End-Tags. Jedem Start-Tag muss
ein5 korrespondierendes End-Tag folgen, jedem End-Tag ein korrespondie3
Start-Tag: <Tag-Name>, End-Tag: </Tag-Name>
In HTML/XHTML würden andere Tag-Namen verwendet werden.
5
Infolge der Anforderung Fragmentierung (s. Kap. 2.9) werden in einem FML-Dokument auch isolierte Start- oder End-Tags erlaubt sein. Dieser Umstand kann jedoch
hier übergangen werden, da fehlende korrespondierende Tags während der Transformation
(s. Kap. 7.1) in einen FML-Graphen ergänzt werden.
4
21
rendes Start-Tag vorangehen. Ein öffnendes und ein schließendes Tag gehören genau dann zusammen und formen ein Element, wenn sie denselben
Namen haben (und denselben Namensraum und dieselbe Perspektive teilen).
Existieren neben einem öffnenden und einem schließenden Tag noch weitere
Tags mit demselben Namen, so bestehen natürlich auch mehrere Möglichkeiten einer Zuordnung.
So lässt das FML-Dokument
А роза упала на лапу Азора.
die typographischen6 Interpretationsvarianten V1 und V1 zu:
А роза упала на лапу Азора
V1
V2
Überlagerndes gleichnamiges Markup (Self-Overlapping-Markup), ein Sonderfall der Interferenz (s. Kap. 2.4), kann also nicht eindeutig interpretiert
werden. Diese Unsicherheit widerspricht der Anforderung nach Eindeutigkeit (s. Kap. 2.14), ist nicht zulässig und führt zu einer Identifizierungsanforderung:
Öffnende Tags (Start-Tags TS ) und schließende Tags (End-Tags TE ) korrespondieren () in einem FML-Dokument in derselben Perspektive pi und im
selben Namensraum nsj durch ihren Tag-Namen tnk :
TS [pi ] [nsj ] [tnk ] TE [pi ] [nsj ] [tnk ]
Es kann unterstellt werden, dass in Konsequenz der Anforderung Fragmentierung (s. Kap. 2.9) die Anzahl nijk verfügbarer Start-Tags gleich der
Anzahl assoziierter End-Tags ist:
nijk = |TS [pi ] [nsj ] [tnk ]| = |TE [pi ] [nsj ] [tnk ]|
Für die Anzahl möglicher Assoziationen ijk gilt
1 ≤ |ijk | ≤ nijk !
Ist |ijk | > 1, so wird die eindeutige Konstruktion von Tag-Paaren7 TS/E
durch strikte Zuordnung von außen nach innen nach dem MatrjoschkaPrinzip (konzentrisch ineinander geschachtelte Anordnung) sichergestellt.
6
Die Semantik des Tags u sei unterstrichen.
Ein Tag-Paar, also ein Start-Tag und dessen korrespondierendes End-Tag, wird im
Zuge der Transformation (s. Kap. 7.1) in ein Element in einem FML-Graphen interpretiert.
7
22
Dieses Vorgehen wird infolge der Anforderung Kompatibilität (s. Kap. 2.2)
gewählt.
Wo diese Default-Zuordnung nicht gewünscht ist, Self-Overlapping-Markup
erzwungen werden soll, muss FML einen Mechanismus anbieten, um |ijk |
zu dekrementieren:
Eine ID-Zuweisung wird eingeführt, die auf ein Start- und ein End-Tag
angewendet werden darf, um Tag-Paare sicher zu konstruieren. Hierbei darf
nijkl = |TS [pi ] [nsj ] [tnk ] [IDl ]| = |TE [pi ] [nsj ] [tnk ] [IDl ]|
erneut vorausgesetzt werden. Die IDs müssen in
TS/E [pi ] [nsj ] [tnk ] disjunkt
vergeben werden, so dass stets nijkl = 1 bzw. TS/E [pi ] [nsj ] [tnk ] [IDl ] = 1
und |ijkl | = 1.
2.6
Kongruenz
So wie man einem Nebeneinanderbestehen gleichberechtigter Strukturen in
der Realität begegnet, so muss auch bei der Auszeichnung von Dokumenten
das pluralistische Prinzip anwendbar sein: Parallele Auszeichnungen sollen
möglich sein, Parent-Child-Beziehungen zwischen Tags dürfen nicht mehr
erzwungen werden für Strukturen, die in keiner hierarchischen Ordnung stehen.
In folgendem Beispiel wird Inhalt um die Auszeichnungen bold (Tag-Name:
b), italic (Tag-Name: i) und red (Tag-Name: r) angereichert:
Cigar? Toss it in a can. It is so tragic.
bold
italic
red
In XML kann dieser Sachverhalt sprachinhärent und ohne virtuelle Workaround-Konstrukte nur durch eine der beiden folgenden Varianten ausgezeichnet werden:
Cigar? Toss it in a can. <r>It is so tragic.</r>
Cigar? Toss it in a can. <r>It is so tragic.</r>
Dieses Markup stellt eine Überspezifikation dar, denn weder ist b Child von i
noch ist b Parent von i. Das Inhaltsfragment Cigar? Toss it in a can. ist
∩
schlicht b i. Diese Repräsentationsform schafft also neue unbeabsichtigte
Strukturen und spiegelt nicht die Realität wider. Die Nachteile des Strukturwandels werden deutlich, wenn man sich die Konsequenzen des Editierens
im XML-Dokument veranschaulicht: Durch Einfügen von Zeichen zwischen
23
den Tags und wird Inhalt erzeugt, der b ist, aber nicht i.
Einfügungen zwischen und <r> erzeugen Inhalt, der gar keiner Semantik mehr unterliegt. Dieser Mangel an Möglichkeiten zur Repräsentation
kongruenten Markups kann also zum einen zu Inkonsistenzen während der
Dokumentpflege führen, zum anderen lässt sich die ursprüngliche kongruente Struktur allein aus dem Markup nicht mehr rekonstruieren.
FML muss neben Parent-Child-Beziehungen auch deckungsgleiches Markup
ermöglichen, um kongruente Semantik realitätsnäher auszeichnen zu können
und Sicherheit während der Dokumentpflege zu gewährleisten.
2.7
Independenz
Heterogene Perspektiven sollen konsolidiert in einem FML-Dokument redundanzfrei strukturiert werden können: Eine semantische Inhaltsinterpretation
darf unabhängig neben anderen existieren. Implizite Interferenzen (s. Kap.
2.4) zwischen den Auszeichnungen verschiedener Perspektiven dürfen keinem
restringierenden Strukturzwang unterliegen.
Diese Anforderung wird unter den Termini Perspektiven, Ebenen, Sichten,
Levels, Layers, Interpretationen, Multi-Hierarchien, multiples Markup und
multiple Annotationen von der Wissenschaftsgemeinschaft in verschiedenen
Kontexten diskutiert. Für ein Verständnis der Independenzanforderung sind
die Ausführungen in [95], [159] und [202] empfehlenswert.
Natürlich existieren genauso viele konkrete Perspektiven wie semantische
Interpretationsmöglichkeiten, also Auszeichnungsvarianten, auf beliebigen
Dokumenten: unendlich viele. Anwendungsfälle lassen sich folgendermaßen
klassifizieren:
1. Typographische Perspektive
Die Betrachtung von Druck- und Online-Medien nach gestalterischen
Gesichtspunkten führt zu den verbreitetsten Anwendungsfällen für
Markup. Graphische und textuelle Darstellungsinformationen werden
in ein Dokument eingebettet. Vielfalt und Beschränkung über die verschiedenen typographischen Struktursysteme [39] sind durch eine Vielzahl an Optionen und Variationen begründet: Layout, Anordnung,
Positionierung, Satzspiegel, Interaktion mit graphischen Elementen,
Ausrichtung, Schreibrichtung, Zeilenumbruch, Zeilenabstand, Wortund Buchstabenlaufweite, Worttrennung, Schriftschnitt, Schrifttyp,
Schriftgröße, Farbgestaltung etc. Beispiele für primär typographische Auszeichnungssprachen des dokumentenzentrischen Ansatzes sind
HTML/XHTML, XSL-FO, LaTeX , DocBook [190] [144], IDML und
FictionBook. Auch populäre rein graphische Sprachen wie SVG und
24
X3D kann man hier einordnen, zumal sie häufig in Dokumenten eingebettet vorliegen.
2. Linguistische Perspektive
Die graphemische, phonemische, morphologische, syntaktische, semantische, pragmatische, akustische, phonetische und prosodische Ebene
[118] sind Perspektiven auf natürliche Sprachen. Diese verschiedenen
linguistischen Strukturen der Lautsprache und der geschriebenen Sprache können mittels Auszeichnungssprachen dargestellt werden. Populäre Beispiele für dieses Anwendungsgebiet sind LMF [47], SISR und
VoiceXML [116]. Mit der multiplen Markup-Annotation linguistischer
Informationen in kontrollierten Sprachen setzt sich insbesondere [199]
auseinander.
3. Daten-Perspektive
Die Auszeichnung von Informationen außerhalb inhaltlicher Interpretation erfolgt im datenzentrischen Ansatz. Inhalt wird nüchtern als
Zeichensequenz wahrgenommen, nur der Strukturkontext ist von Interesse. Diese Anschauung wird typischerweise von Datenbanken eingenommen. XML-Serialisierung, also eine Übersetzung von ERM s in
XML-Schemas (XSD), bieten im Allgemeinen relationale Datenbanken an. Mit XSD lassen sich Schemata zur hierarchischen Strukturierung beliebiger Daten definieren. Tamino Schema Definition [150]
erweitert XSD und ist ein Beispiel für eine Schemasprache zur Beschreibung komplexer Datenstrukturen zwecks Persistierung in einer
Datenbank. Die Menge möglicher Strukturen und Inhalte ist hierbei
natürlich unendlich. Semantik der Daten ist für den datenzentrischen
Ansatz irrelevant. Insofern ist die Daten-Perspektive eine Generalisierung von 1. und 2.
Independenz, für das XML kein sprachinhärentes Lösungskonzept anbietet,
ist nicht nur in akademischen Diskursen eine der wichtigsten Anforderungen
überhaupt. Die Umsetzung vieler realer Anwendungsfälle der Gegenwart
wird durch dieses Defizit massiv beeinträchtigt.
So werden die sieben Markup-Perspektiven des American National Corpus 8 [75] derzeit hochgradig redundant mittels dem Stand-Off -Workaround
(s. Kap. 12.11) über sieben isolierte Dokumente heterogen verwaltet. Mit
einem Lösungskonzept für Markup-Independenz könnte dieser Korpus konsolidiert in einem integren Dokument das Editieren, Suchen oder Analysieren
weitaus sicherer und einfacher gestalten. In [122] wurde dargelegt, dass die
Verwendungsvielfalt von Dokumentinhalten zwangsläufig zu verschiedenen
Strukturebenen führen muss.
8
Projekt zur Verwaltung des Korpus des Amerikanischen Englisch (z.Z. 22 Mio. Wörter). Siehe http://www.anc.org.
25
Bereits [12] erkannte, dass im Zeitalter digitaler Dokumente verschiedene
Versionen desselben Textes zweckmäßig verwaltet werden müssen. Heute,
im Zeitalter häufig geforderter Revisionssicherheit, ist dieser Anspruch von
großer Relevanz. Markup-basierte Lösungen dokumentinhärenter Versionierung, eines von vielen potenziellen Aufgabengebieten der Independenz, befinden sich in aktueller Entwicklung [136].
Ein anderes illustratives Einsatzgebiet ist die multihierarchische Dokumentenauszeichnung auf Bildern beschädigter historischer Manuskriptseiten [83]:
Die Perspektiven geometrische und räumliche Deformationen, Illuminationen, Beschädigungen, Restaurationen, paläographische Eigenschaften und
Text als eine Sequenz von Zeichen oder Linien sind zu verwalten. Vergleichbar auch [62]: Richtlinien für ein konsolidiertes Markup mittelalterlicher
Schriften für die verschiedenen Interpretationsperspektiven von Linguisten,
Historikern und Literaten werden angestrebt.
Nicht zuletzt ergeben sich moderne Anwendungsszenarien im Rahmen elektronischer Buchpublikationen: Mehrere der in [8] vorgestellten Formate für
verschiedene E-Book-Betrachter sind in einem redundanzfreien Dokument
über verschiedene independente Perspektiven zu konsolidieren.
Nachdem also die Anforderung Independenz zwei Jahrzehnte intensiver Diskussionsgegenstand war, muss FML hierfür ein substanzielles Lösungskonzept anbieten, das keine der anderen Anforderungen verdrängt: Ein Dokument darf nicht nur über verschiedene semantische Perspektiven ausgezeichnet werden, sondern muss auch über ein und dieselbe Perspektive mehrfach ausgezeichnet werden können. Zum Beispiel könnte ein Dokument
mit derselben Seitenbeschreibungssprache über verschiedenartige typographische Annotationsebenen, die jeweils ein Cross-Media-Publishing-Format
für ein Druck-, Online- oder Handy-Medium repräsentieren, ausgezeichnet
sein.
Die Auswahl von Perspektiven muss FML-Anwendungsfällen freigestellt sein:
Es erfolgen keinerlei semantische Vorbelegungen oder Strukturvorgaben wie
Hierarchiezwang, die ein “freihändiges“ Auszeichnen behindern. Jedes Element muss sich eindeutig einer Perspektive oder Default-Perspektive zuordnen lassen.
Eine Implementierung der Sprache FML muss es ermöglichen, die bidirektionale Transformation zwischen einem FML-Dokument und einem FMLGraphen (s. Kap. 2.13) optional durch Inklusion oder Exklusion auf relevante Perspektiven zu reduzieren.
2.8
Segmentierung
Ein FML-Element soll über verteilt geordnete Segmente zu einem neuen Element geführt werden können. Somit werden virtuelle Elemente durch Segmentkonsolidierung möglich, und das Prinzip Wiederverwendbarkeit wird
26
unterstützt. Hierzu müssen die partizipierenden Segmente eines konstruierten Elementes im Inhalt identifiziert und nach einem eindeutigen Positionsindex [0]...[n] geordnet werden.
Ein neues Element bedient sich aus dem Zeichenvorrat des Inhaltes eines
FML-Dokumentes und kapselt somit neuen virtuellen Inhalt aus einer Teilmenge des Inhaltes :
risetovotesir
[0] [1] [2]
eve
So könnte man mit dem Sprachmerkmal Segmentierung in einem Dokument,
dessen Inhalt aus einer Sequenz aller Buchstaben des Alphabetes [139]
aAäÄbBcCdDeEfFgGhHiIjJkKlLmMnNoOöÖpPqQrRsSßtTuUüÜvVwWxXyYzZ
besteht, alle deutschsprachigen Wörter (ca. 120 000) über Segmentierungskompositionen zusammenstellen.
Lösungsansätze für die Anforderung Segmentierung wurden bereits unter
dem Begriff Discontinuous Structures in [153] diskutiert.
2.9
Fragmentierung
Auch ein Fragment eines wohlgeformten FML-Dokumentes muss ein wohlgeformtes FML-Dokument sein. Diese Fragmentierungsanforderung9 erlaubt
das Trennen eines FML-Dokumentes in mehrere modulare Teildokumente,
Dokumenten-Extrakte. Trennstellen dürfen nur im Inhalt, nicht im Markup
sein. In einem optionalen Prolog eines FML-Dokumentes sollen Fragmente
als solche identifizierbar sein, um externen Prozessoren die Zusammenstellung verteilt distribuierter Dokumente zu ermöglichen.
Eine Implikation dieser Sprachanforderung ist, dass korrespondierende TagPaare “zerrissen“ sein können. Ein End-Tag kann physisch in einem ganz
anderen Dokument vorliegen als das korrespondierende Start-Tag. Somit
können in einem Dokument die Strukturinformationen unvollständig sein.
Ein FML-Dokument muss demnach auch dann wohlgeformt sein, wenn isolierte Tags kein korrespondierendes Tag lokalisieren können. Bei der Interpretation eines Dokumentes ist also die Annahme zu berücksichtigen, dass
etwaige fehlende Start- oder End-Tags vor bzw. nach den Dokumentgrenzen
9
Die Anforderung Fragmentierung, genauer Dokumentfragmentierung, ist nicht zu verwechseln mit der Elementfragmentierung (s. Kap. 12.11) als ein Workaround zur Repräsentation interferenter Strukturen in XML.
27
vorliegen.
Auch wenn FML einen Inklusionsmechanismus zur Zusammenstellung fragmentierter Dokumente nur vorbereitet, aber nicht anbietet, so bestätigt die
intentional vergleichbare Technologie XInclude [180] die Berechtigung der
Fragmentierungsanforderung:
Many programming languages provide an inclusion mechanism
to facilitate modularity. Markup languages also often have need
of such a mechanism.
2.10
Wildcard
Oftmals lassen sich in einem Dokument semantische Einheiten, Strukturbrüche oder relevante Positionen in der Text- bzw. Datensequenz identifizieren
bevor anzuwendende adäquate Markup-Mittel bekannt sind oder festgesetzt
werden sollen. So möchte beispielsweise ein Autor in Entwicklungsphase –
in der Details und Schema-Wahl noch unsicher oder unbekannt sind – lokalisierte Referenzpunkte für Glossareinträge, Fußnoten o. dgl. unkompliziert
im Dokument kennzeichnen.
Hier bietet sich das Wildcard-Konzept an: Ein Platzhalter markiert die Position für Markup und kann zu gegebenem Zeitpunkt durch zweckmäßige
Markup-Komponenten substituiert werden.
Das Einbetten von Wildcards muss überall im Inhalt eines FML-Dokumentes
und außerhalb von Markup möglich sein und jeden der drei Gültigkeitszustände wohlgeformt, geschachtelt, valide (s. Kap. 4.3) erhalten. Eine Wildcard ist ein Platzhalter unbestimmbaren Zweckes und darf nicht darüber
hinaus interpretiert werden, z. B. als Start-Tag, obwohl es später auch ein
schließendes Tag oder ein Kommentar werden könnte.
2.11
Vererbung
Die Eigenschaften von Sprachelementen sollen auf deren Children vererbt
werden. Getreu J. W. v. Goethe:
Was Du ererbt von Deinen Vätern hast, erwirb es, um es zu
besitzen!
Zeichnet man das typographische Beispiel
able was i ere i saw elba
hinsichtlich des durch Kursiv- bzw. Fettschrift hervorgehobenen Textes aus,
so wird anschaulich, dass natürlich auch das innere Formatelement (Zeile 6)
über die Eigenschaft italic="true" implizit verfügen muss.
28
01
02
03
04
05
06
07
08
09
10
11
<palindrome>
able
<format italic="true">
was i
<format bold="true">
ere
</format>
i saw
</format>
elba
</palindrome>
Dieser Mechanismus entspricht dem objektorientierten Paradigma der Vererbung [43] sowie den Beobachtungen von [29] an der menschlichen Wissensstruktur und semantischen Netzwerken.
Für FML soll Vererbung nach den Grundsätzen der Merkmalsvererbung in
hierarchischen Strukturen [10] erfolgen:
• Die einem Knoten zugeordneten Merkmale gelten auch für alle Unterbegriffe des Knotens.
• Attribute der Unterbegriffe dominieren die der Oberbegriffe.
• Suchprozesse verlaufen effizient von den Eigenschaften eines Unterbegriffes in Richtung aller Oberbegriffe.
Erbt ein Element von mehreren Parents dasselbe Merkmal mit verschiedenen Merkmalsbeschreibungen (Mehrfachvererbung), so soll es das Merkmal
annehmen und alle Beschreibungen verlustfrei konsolidieren.
Ein Sprachelement vermag somit über weitaus umfangreichere Eigenschaften verfügen, als es selbst deklariert.
2.12
Graphrepräsentation
Die XML-Spezifikation [186] trifft keinerlei Aussage bzgl. einer Graphrepräsentation für XML-Dokumente. Erst das Document Object Model (DOM )
[178] und das XQuery and XPath Data Model (XDM ) [184] geben XML
ein Datenmodell. Zum einen sind die beiden Datemodelle sehr verschieden, zum anderen wird auf Visualisierungsaspekte lediglich unverbindlich
exemplarisch eingegangen:
29
Das ist zu wenig! FML muss ein inhärentes, eindeutiges und konsistentes
Datenmodell mitsamt graphischer Darstellungsform feststetzen. Es bedarf
neben dem grammatikbasierten Ansatz zur Beschreibung von FML-Dokumenten (s. Kap. 2.1) eines formalen Modells zur Beschreibung einer FMLInstanz in einem FML-Graphen: Jedes wohlgeformte FML-Dokument soll in
einem semantisch korrespondierendem Graphen abgebildet werden können.
Ziel ist die visualisierende Repräsentation einer FML-Instanz als Grundlage
für Graphoperationen sowie als Modellvorstufe für eine Referenzimplementierung (s. Kap. 2.18).
30
In [57] wird über Ergebnisse der psychologischen Forschung gezeigt, wie
wichtig der Einsatz von graphischen Methoden zur Unterstützung von Denkprozessen beim Menschen ist. Die Aussage: “Es ist eine empirische Tatsache,
dass sich komplexe Probleme durch Verwendung graphischer Hilfsmittel sehr
oft überschaubarer repräsentieren lassen.“ trifft für XML zweifelsfrei zu und
wird in noch höherem Maße für FML zutreffen, da hier die restriktionsfreie
Anordnung von Tags weitaus komplexere Strukturen, die ungleich schwieriger zu erfassen sind, schaffen kann. Gefordert ist eine allgemein vereinbarte
Graph-Notation, die suggestiv ist und keine Unschärfe in ihrer Interpretation erlaubt.
In [145] werden acht Datenmodelle für XML vergleichend evaluiert10 . Bemerkenswert auch [136]: Das präsentierte Modell (Variant Graph) für eine
redundanzfreie Versionsverwaltung von Dokumenten erfüllt die Anforderungen Interferenz (s. Kap. 2.4) und Independenz (s. Kap. 2.7). Jedoch kann
der Variant Graph zugunsten konkurrierender Anforderungen nicht übernommen werden. Inspiriert durch die bestehenden Ansätze für XML sind
Struktur und Semantik eines FML-Graphen als eine neben einem FMLDokument gleichwertig bestehende Darstellungsform einer FML-Instanz zu
entwickeln und in die gemäß Zielsetzung zu erstellende FML-Spezifikation
zu integrieren.
Zukunftsorientiert und in gemäß der Sprachanforderungen Interferenz und
Independenz soll der FML-Graph inhärent eine mächtigere Datenstruktur,
als es die auf Monohierarchien beschränkte Auszeichnungssprache XML erlaubt, verkörpern. Die Evolution schreitet voran [76]:
Long, long ago, people stored data in lists, because that was all
that was available. Then, someone came up with the idea of
storing data in tables. So relational databases came along and
people moved up the ladder to tables. A few years ago, XML
came along so data moved up again to trees. Can you guess what
10
Vier Jahre später ist noch XDM hinzugekommen.
31
will happen next? The Semantic Web folks want us to move to
using graphs. Should we move to graphs? Seems to be the next
logical step in information evolution. What’s holding us back?
Well, it’s probably too soon. The world is still in the tree phase.
Der Evolution von Datenstrukturen folgend wird für FML eine polyhierarchische Repräsentationsform erwartet.
2.13
Transformation
Es ist ein Transformationsregelwerk zur Übersetzung zwischen dem grammatikbasierten Dokument und der Graphrepräsentation einer FML-Instanz,
zwischen einem FML-Dokument und einem FML-Graphen zu erstellen. Diese
Transformation muss bidirektional möglich sein, vollständig und verlustfrei
verlaufen und stets integer von einer Darstellungsform einer FML-Instanz
zu der anderen führen.
FML-Dokument ⇌ FML-Graph
Optional muss es möglich sein, eine Transformation – entweder durch Inklusion oder durch Exklusion von Perspektiven (s. Kap. 2.7) – in beide
Übersetzungsrichtungen auf die für einen konkreten Anwendungsfall relevanten Perspektiven zu begrenzen, irrelevante Perspektiven ignorierend.
2.14
Eindeutigkeit
Ambivalenzen, Mehrdeutigkeiten, Zweifelsfälle in der Sprache FML dürfen
für einen sicheren Informationsaustausch nicht zulässig sein. Eine FMLInstanz muss eindeutig sein. Das bedeuted, dass jedes FML-Dokument
in seiner semantischen Interpretation durch einen FML-Graphen eindeutig
sein muss, folglich auch die Transformation zwischen Dokument-Syntax und
Graph.
Die Eindeutigkeitsforderung konkretisiert sich folgendermaßen:
1. Die syntaktisch identifizierbaren Funktionseinheiten (Komponenten)
eines FML-Dokumentes müssen eindeutig korrespondierenden Knoten
in einem FML-Graphen zuzuordnen sein.
2. Alle Knoten eines FML-Graphen müssen korrespondierenden Komponenten zuzuordnen sein.
3. Alle von Knoten des attributierten FML-Graphen gekapselten Informationen müssen sich in der Grammatik des FML-Dokumentes eindeutig zuordnen lassen.
32
4. Die bidirektionale Transformation zwischen FML-Dokument und FMLGraph (s. Kap. 2.13) muss eindeutig sein.
5. FML-Dokument und FML-Graph müssen sich ohne Informationsverlust ineinander transformieren lassen. Jede Änderung an einer der
beiden Repräsentationsformen der FML-Instanz führt gleichsam zu
einer Änderung an der anderen.
Mit der vergleichbaren SGML-Anforderung der widerspruchsfreien Übereinstimmung einer Dokumenteninstanz mit einem Inhaltsmodell setzt sich
intensiv [20] auseinander. Für XML wird diese Anforderung in [186] mit
den Begriffen unambiguous markup und deterministic content model explizit angesprochen. Eindeutigkeit garantiert Integrität und Konsistenz von
FML-Instanzen, Interpretationssicherheit sowie Zuverlässigkeit für den Informationsaustausch mit FML.
2.15
Entropie
Eine generalisierende Auszeichnungssprache hat keinerlei Einfluss auf die
von ihr zu strukturierenden Inhalte. Wohl aber auf die Strukturmittel, auf
das syntaktische Regelwerk ihres Markups, das in einem Dokument beliebig
oft angewendet werden darf. Intensives Auszeichnen führt zu mehr Dokumentvolumen. Der eigentliche Inhalt kann so zu einem Bruchteil des Gesamtdokumentes schrumpfen.
Die FML-Sprachdefinition muss die Anforderung nach syntaktischer Sparsamkeit nicht für Inhalte, wohl aber für alle eingebetteten Markup-Komponenten berücksichtigen. In der Terminologie der Informationstheorie, die auf
Claude Shannon [146] zurückgeht, formuliert sich die Entropie-Anforderung
folgendermaßen: hohe Entropie und hoher Informationsgehalt der Zeichen,
geringe Vorhersagbarkeit, geringer innerer Ordnungszustand, minimale Redundanz.
William Ralph Bennett, Professor der Physik, Yale Universität, war der
erste Wissenschaftler, der 1976 die Entropie des Voynich-Manuskriptes maschinell berechnete [13] und mit der anderer Sprachen verglich11 . Bei einem
Vergleich der Entropie zwischen anderen Auszeichnungssprachen und FML
sollte letztere über eine signifikant höhere Markup-Zeichen-Entropie verfügen, FML sollte weniger Redundanz aufweisen.
So ist beispielsweise offensichtlich, dass in der XML-Syntax für Kommentare
<! − −comment −− >
11
Die Wortentropie gleicht mit ca. 10 Bit/Wort der von Latein oder Englisch. Alle
Bemühungen einer Dekodierung oder semantischen Interpretation der unikaten VoynichSprache sind jedoch bislang ergebnislos geblieben. Es handelt sich wohl um eine aufwändige Scherzschrift des 15. Jahrhunderts.
33
sehr verschwenderisch mit Markup (7 Zeichen) umgegangen wird. Derartige
Kodierungen folgen nicht primär dem Gebot hoher Entropie und sind in
FML unbedingt zu vermeiden.
Neben dem Ressourcenaspekt erhebt nach [78]
The utility of a language as a tool of thought increases with
the range of topics it can treat, but decreases with the amount
of vocabulary and the complexity of grammatical rules which
the user must keep in mind. Economy of notation is therefore
important. Economy requires that a large number of ideas be
expressible in terms of a relatively small vocabulary.
auch die Frage nach Nutzbarkeit und Wirtschaftlichkeit Anspruch auf niedrige Sprachkomplexität, minimale Regeldichte und geringes Zeichenvolumen.
Dieser Notationsminimalismus darf andererseits jedoch nicht zum Mittel extensiver Zeichenüberladung führen. [138, S. 165ff.] warnt hiervor und empfiehlt ein psychologisches Optimum.
Die Entropie-Anforderung interferiert v. a. mit den beiden Anforderungen
1. Kompatibilität (s. Kap. 2.2) und
2. Ergonomie (s. Kap. 2.16)
und muss einen zweckmäßigen und ausgeglichenen Kompromiss gemäß dem
sogenannten Falschen Zipfschen Gesetz aus der Sprachwandelforschung [209]
finden. Dieses Gesetz besagt, dass Äußerungen in einer Sprache immer aus
einem Kompromiss zwischen zwei entgegengesetzten Tendenzen im Sprecher
entstehen:
• einerseits der Wunsch, eine Information möglichst verständlich zu vermitteln, was zu Wiederholung (Redundanz) und Ausführlichkeit führt,
• andererseits Sparsamkeit, dem Bedürfnis, möglichst wenig physische
und geistige Energie bei der Sprachproduktion aufzuwenden.
Zusammengefasst lässt sich folgende konkrete Anforderung aufstellen:
Jedes FML-Dokument sollte unter Berücksichtigung der Kompatibilitätsanforderung und ergonomischer Vertretbarkeit möglichst frei von MarkupRedundanzen sein und nur einen notwendigen und minimalen Anteil des
Informationsgehaltes für Steuerungszeichen verwenden.
34
2.16
Ergonomie
Der bedeutendste Prozessor von Dokumenten ist – historisch betrachtet –
der schreibende und lesende Mensch [45].
Vorab elektronischer Unterstützung, deren historische Entwicklung und deren Anforderungen in [148] und [155] erörtert werden, bedeuteten Auszeichnungen die längste Zeit vor allem Dokumentdekoration, wie diese Dekretale
des Papstes Gregor IX. [117] illustriert:
35
Das Markup “rote Schriftfarbe“ wie auch alle anderen angewandten Stilmittel zeichnet neben gestalterischen Aspekten eine spezielle Semantik des
Textes aus.
Verschiedene Markup-Konventionen werden angewandt:
• Interpunktions-Markup
Satzzeichen, Diakritika und Leerschritte zur Wort- und Satztrennung
vermitteln Informationen über Struktur, Aussprache, Betonung, Klang
oder Akzent eines Textes. Die Symbole dieser Auszeichnungskategorie
werden gemeinhin als Teil des Inhalts und des Alphabets betrachtet
[197].
• Dekoratives Markup
Künstlerische Ausschmückung und graphische Gestaltung des Inhaltes
durch verschiedene Stilmittel. Charakteristische Anwendungsbereiche
sind klerikale Schriften, Plakate, Flugblätter, Illustrierte, Werbepublikationen und Webpräsenzen.
• Strukturierungs-Markup
Gliederungszuordnung von Inhaltsabschnitten zwecks Strukturierung,
zumeist in Hierarchien. Gebräuchlich bei wissenschaftlichen Texten,
Referenzhandbüchern oder Nachschlagewerken.
• Orientierungs-Markup
Kopf- und Fußzeilen, Paginas, Zeilennummern, Rubriken und Verzeichnisse helfen dem Leser, sich im Text zu orientieren.
• Informatives Markup
Graphisches Hervorheben von Inhaltsabschnitten zur Vermittlung ergänzender Informationen wie Referenzverweis, Betonung, Relevanz oder
sonstige Semantik.
• Kommentierendes Markup
Marginalien, Fußnoten, Endnoten, Annotationen und andere Metainformationen für Leser und Editoren. Die frühmittelalterlichen Griffelglossen [162] oder die Novelle von [54]12 sind markante Beispiele für
diese Kategorie.
• Druck-Markup
Eingebettete mikro- und makrotypographische Informationen für Drucksatz und Herstellung.
Bei der Zuordnung eines Markups zu den genannten Anwendungskategorien
kann Mehrdeutigkeit vorliegen. In vielen Dokumenten finden verschiedene
12
57% des Gesamttextes sind Anmerkungen in Endnoten [210].
36
der angeführten Markup-Varianten Anwendung und können den eigentlichen
Inhalt mitunter erheblich in den Hintergrund treten lassen. Gemein ist allen
historischen Markups die Intention, den natürlichen Prozess des Lesens zu
fördern.
FML ist eine generalisierende und keine typographische Auszeichnungssprache, behandelt nicht nur Texte als Inhalt, sondern folgt auch dem datenzentrischen Ansatz. Wohl kann man schöpferisch ein Freestyle Instanz Schema
(s. Kap. 11.2) für die Dokumentgestaltung spezifizieren. Diese Aufgabe
ist jedoch nicht Gegenstand der FML-Spezifikation. Dennoch lässt sich der
historisch verankerte ergonomische Anspruch übertragen.
Es ist davon auszugehen, dass ein FML-Dokument an einem Computer entwickelt, verarbeitet und gelesen wird. Obgleich FML für die hierfür notwendigen Editoren und Prozessoren außerhalb einer Referenzimplementierung
(s. Kap. 2.18) keine Lösungen anbieten kann, leiten sich aus den Grundlagen
der Software-Ergonomie [63] auch Aspekte für die Mensch-FML-Interaktion
ab. Kriterien für Gebrauchstauglichkeit und Benutzerfreundlichkeit können
auch auf die menschlichen Arbeit mit einer Basistechnologie wie FML angewandt werden.
Folgende konkrete ergonomische Anforderungen an die neue Sprache FML
und die Referenzimplementierung werden aufgestellt:
1. Angemessenheit
Bereitstellung erforderlicher und Minimierung entbehrlicher Funktionalität
2. Bedienbarkeit
hohe Nutzungsqualität und Leistungsmöglichkeit
3. Verständlichkeit
Transparenz, Übersichtlichkeit und Eindeutigkeit der Technologie
4. Lesbarkeit
lesbare und nachvollziehbare Dokumente und Modelle
5. Erlernbarkeit
minimale Einarbeitungszeit
6. Erwartungskonformität
deterministische Handlungsergebnisse
7. Selbstbeschreibungsfähigkeit
Verständlichkeit durch Rückmeldungen
8. Fehlertoleranz
Unterstützung des Benutzerziels durch Fehlerhinweise und Korrekturanleitung
37
9. Dokumentation
Deckung des erforderlichen Informationsbedarfs des Nutzers
Alle Kriterien zeichnen sich durch die übergreifende Anforderung der Einfachheit aus: keine unnötige Komplexität um ihrer selbst willen, alle Lösungen sollten so einfach wie möglich sein, aber auch nicht einfacher. Die
Sprache FML in ihren Konzepten, ihrer Grammatik und Spezifikation im
Vergleich zu XML signifikant einfacher zu gestalten ist eine grundsätzliche
Primäranforderung.
Neben diesen Ergonomiekriterien sei ein weiteres aufgestellt – das FreestyleKriterium: Der Begriff Freistil besagt, dass der Ausführende einer Tätigkeit
die Art und Weise der technischen Ausführung in hohem Maße selbst bestimmen kann und dabei weitgehend unabhängig von einschränkenden Regeln
ist [196]. Dieses allgemeine Definition soll auch zutreffen, wenn der Ausführende ein FML-Dokument-Autor und die Tätigkeit das Entwickeln eines
FML-Dokumentes ist.
2.17
Internationalisierung
Internationalisierung bedeutet in der Softwareentwicklung, ein Programm
so zu gestalten, dass es leicht und ohne den Quellcode ändern zu müssen, an
andere Sprachen und Kulturen angepasst werden kann. Dementsprechend
sollten natürlich die einer Software zugrunde liegenden Protokolle und Formate die mehrsprachige Kodierung beherrschen.
Eine grundsätzliche Unterstützung aller Weltsprachen sowohl für Inhalte als
auch für Markup-Bezeichner – das ist die Internationalisierungsanforderung
an FML. Diese Anforderung impliziert nicht nur die Möglichkeit des Gebrauches verschiedener Alphabete, sondern auch die der Verwendung zweier
Schreibrichtungen. Die sekundäre Schreibrichtung ist unveränderlich senkrecht, von oben nach unten. Die primäre Schreibrichtung ist waagerecht,
jedoch muss zwischen dextrograder (rechtsläufiger) und sinistrograder (linksläufiger) Schrift unterschieden werden können. Durch diese Trennung wird
neben der lateinischen insbesondere die Schreibrichtung semitischer Schriften unterstützt.
2.18
Referenzimplementierung
Es ist eine Referenzimplementierung bereitzustellen, die folgenden Ansprüchen gerecht wird:
1. Sprache
Wahl einer Programmiersprache, die verbreitet, akzeptiert, transparent und leicht übertragbar ist
38
2. Objektorientierung
Einsatz zeitgemäßer objektorientierter Paradigmen
3. Langlebigkeit
Verzicht auf kurzlebige Frameworks und Designstrategien
4. Erweiterbarkeit
Aufsetzen spezifischer Implementierungen ermöglichen
5. Konformität
strikte Einhaltung der FML-Spezifikation
6. Schnittstelle
Definition einer implementierungsunabhängigen und übertragbaren Zugriffsschnittstelle
7. Leistung
performanceorientierte Implementierung
8. Deserialisierung
Transformation FML-Dokument → FML-Graph
(Inklusion/Exklusion von Perspektiven)
9. Serialisierung
Transformation FML-Graph → FML-Dokument
(Inklusion/Exklusion von Perspektiven)
10. XML-Repräsentation
Übersetzung eines FML-Dokumentes in eine XML-Milestone-Repräsentation
11. Objektmodell
Abbildung des FML-Graphen zur Interpretation einer FML-Instanz
12. Zugriff
Lesender und schreibender Zugang zu allen in Knoten und Kanten des
attributierten FML-Graphen gekapselten Informationen
13. Navigation
Aggregationspfade zwischen allen Knoten eines FML-Graphen entlang
dessen Kanten
14. Manipulation
Graphtransformation mittels Manipulationsfunktionen auf einem FMLGraphen
15. Dokumentation
Source-Code-Annotationen für Software-Entwickler
39
16. Ergonomie
Auswahl selbstbeschreibender Bezeichner für Funktionen und Variablen
17. Einsatzbereitschaft
Verfügbarkeit für unmitelbaren Einsatz in Software-Projekten
2.19
Spezifikation
Eine präzise Spezifikation einer Auszeichnungssprache garantiert Verlässlichkeit in der Interpretation von Sprachinstanzen, erlaubt unmissverständliche
Austauschbarkeit von Daten zwischen Sender und Empfänger, ermöglicht
die sichere Entwicklung von die Sprache FML verwendender Tools und reduziert den Einarbeitungsaufwand. Vor allem aus ökonomischer Perspektive
sind Spezifikationen und Standards von großer Relevanz [195].
In dem heterogenem Umfeld sprachlichen Informationsaustausches ist eine
standardisierte Kommunikation notwendig, wie auch der Erfolg von XML
nicht zuletzt auf eine transparente Spezifikation13 [186] zurückzuführen ist.
Und da auch der Weg einer Innovation zu öffentlicher Akzeptanz oder zu
einem Standard oder einer Norm einer technischen Spezifikation bedarf [81],
soll diese Bestandteil der Sprachanforderungen sein: Die technische Spezifikation Freestyle Markup Language (s. Anhang C) soll die Realisierungskonzepte aller anderen Anforderungen dieses Kapitels konsolidiert beschreiben
und jedem FML-Autor oder -Anwender Referenzhandbuch sein. Die Spezifikation muss folgenden Ansprüchen gerecht werden:
• Inhalt
Die Sprachdefinition muss korrekt in die Spezifikation übertragen werden: Inhaltsbestandteile sind alle Sprachkomponenten, ihre Beziehungen untereinander, die formale Syntax und die Beschreibung der logischen Strukturkonzepte. Sprachgrammatik und Sprachsemantik müssen korrekt, vollständig, redundanzfrei und widerspruchsfrei beschrieben sein. Dass FML als Weiterentwicklung verstanden werden soll,
muss auch durch Vergleich und Abgrenzung zu XML-Konzepten sowie
durch einen expliziten Migrationsleitfaden für XML-Dokumente klar
zum Ausdruch kommen.
• Konformität
Eine strukturelle und stilistische Übereinstimmung mit der XML-Spezifikation [186] ist erwünscht, um den Umstellungsaufwand des Lesers
auf inhaltliche Änderungen gegenüber dem Standard XML zu begrenzen. Insgesamt soll auch ein Wiedererkennungseffekt die Akzeptanz
13
Das W3C bevorzugt hier den Begriff Recommendation, de facto handelt es sich aber
um Spezifikation und Standard.
40
erleichtern. Vergleichsreferenzen zu Kapiteln und Abschnitten der
XML-Spezifikation sollen den Prozess der Migration unterstützen.
• Lesbarkeit
Da die Spezifikation für einen Anwender zugleich Dokumentation und
Referenzdokument sein soll, muss diese einen Grad an Lesbarkeit erfüllen, der Leser und FML-Autoren auch fachbereichsübergreifend befriedigen kann. Jedes Sprachkonzept muss durch anschauliche Beispiele beschrieben und ggf. graphisch visualisiert werden. Darüber
hinaus muss die Spezifikation neben der deutschen auch in englischer
Sprache vorliegen sowie neben einer reinen Druckversion auch in einer
XHTML-Version, die einem modernen Anspruch an Ergonomie und
Navigierbarkeit gerecht wird.
• Erreichbarkeit
Die Spezifikation muss unter einer konstanten URI für alle Leser als
Internet-Publikation sowohl zum Download als Druckmedium als auch
als Hypertext-Medium stets erreichbar sein.
Insgesamt soll die Spezifikation Freestyle Markup Language gleichermaßen
formale, informale und exemplarische Spezifikation sein und für die Zielgruppe der FML-Leser, -Autoren und -Entwickler alle Informationen für ein
hinreichendes Verständnis und Anwendung der Sprache konsolidieren.
41
Kapitel 3
Architektur
Handle, bevor die Dinge da sind.
Ordne sie, bevor die Verwirrung
beginnt.
Laotse
6. Jh. v. Chr.
Die technologische Architektur der Sprache FML wird skizziert, das Zusammenwirken der verschiedenen Funktionseinheiten illustriert.
42
Jede FML-Instanz besitzt zwei Repräsentationsformen von äquivalentem Informationsgehalt: Das FML-Dokument (s. Kap. 4) und den FML-Graphen
(s. Kap. 5). Diese Repräsentationsformen, die den Kern der FML-Spezifikation (s. Anhang C) bilden, sind bidirektional ineinander überführbar
(s. Kap. 7).
Transformation, Manipulation und Abfrage steuert ein Controller aus der
Implementierungsebene (s. Kap. 9). Ein FML-Dokument wird in einen
FML-Graphen deserialisiert, ein FML-Graph in ein FML-Dokument serialisiert. Den Informationsgehalt einer FML-Instanz verwaltet der Controller in
einem aggregierten Objektmodell, das strukturell identisch zu einem FMLGraphen ist.
Zugunsten technologischer Abwärtskompatibilität ermöglichen darüber hinaus ein festgesetztes XSD-Schema und Transformationsrichtlinien die verlustfreie Persistierung eines FML-Dokumentes in einem XML-Dokument
(s. Kap. 8).
Verschiedene skizzierte Sekundärtechnologien (s. Kap. 11) setzen auf die
FML-Instanz auf.
43
Kapitel 4
Freestyle Dokument
Man muss etwas Neues machen,
um etwas Neues zu sehen.
Georg Christoph Lichtenberg
1742 – 1799
Es erfolgt eine formale Definition von Syntax und Semantik der Sprache
FML. Die Sprachkonstituenten, ihr Terminus und ihre Merkmale sowie ihre
Beziehungen untereinander werden festgesetzt. Diese Definition hat rein
postulativen Charakter. Es wird in diesem Kapitel weder ein vergleichender Bezug zu anderen Sprachen vorgenommen noch werden Konzeption,
Argumentation, Evaluation vorgelegt. Das Ergebnis ist eine vollständige
Definition der Auszeichnungssprache FML ohne Zweifelsfälle.
4.1
Komponenten
Ein FML-Dokument setzt sich aus verschiedenen in streng monohierarchischer Relation stehenden Funktionseinheiten zusammen, sogenannten Komponenten:
44
4.1.1
Dokument
Die Komponente Dokument repräsentiert das vollständige FML-Dokument
und korrespondiert mit dem Root-Knoten vom Typ fml.node.document in
einem FML-Graphen. Physisch besteht das Dokument aus einer geordneten
Sequenz distinkter Komponenten des Typs
• Inhalt und
• Markup
in beliebiger Verteilung und Anzahl.
Grammatik: FML
4.1.2
Inhalt
Die Komponente Inhalt beinhaltet die eigentliche Substanz eines FML-Dokumentes vorab jeder Auszeichnung: eine beliebige UTF-8 -Zeichensequenz.
Die für XML gebräuchliche Sonderbehandlung von Formatierungssymbolen
wird nicht auf Ebene der Grammatik unterstützt: Alle Symbole, auch Zwischenräume, Tabulatoren und Umbrüche, sind Bestandteil der Inhaltssequenz.
Lediglich das eine Markup-Komponente einleitende bzw. beendende Begrenzungssymbol sowie das Maskierungszeichen selbst sind zu maskieren:
• “<“ → “\<“,
• “>“ → “\>“,
• “\“ → “’\\“.
Grammatik: content
45
4.1.3
Markup
Alles, was nicht Inhalt ist, jede Form von eingebettetem Code, ist eine Komponente vom Typ Markup. Markup ist somit ein Oberbegriff für die Komponenten
• Prolog
• Tag
• Kommentar
• Processing Instruction
• Wildcard
Jede Markup-Komponente grenzt sich vom Inhalt durch das einleitende Symbol < und durch das abschließende Symbol > ab.
Grammatik: prolog, startTag, endTag, emptyTag, multiTag, comment, pi,
wildcard
4.1.4
Prolog
Der optionale Prolog eines FML-Dokumentes kapselt bis zu drei Deklarationen:
1. Dokument-Deklaration
globale Dokumentinformationen mit den Attributen
• fml.name: Name des Dokumentes
• fml.uri: eindeutige URI des Dokumentes
• fml.description: Dokumentbeschreibung
• fml.version: FML-Versionsnummer (default=“1.0“)
• fml.fragment: Fragmentidentifizierung
• fml.schema: physische URI eines validierenden Schemas
• fml.trim = “true“ | “false“: Parserinstruktion für den Umgang
mit Formatierungssymbolen in Knoten des Typs fml.node.content
• fml.writing-direction = “lr“ | “rl“: Angaben zur Schreibrichtung zur Berücksichtigung in externen Prozessoren
2. Perspektive-Deklaration
globale Informationen für im Dokument mögliche Perspektiven mit den
Attributen
• fml.perspective.name: eindeutiger Name der Perspektive (zur
Anwendung als Präfix in Markup-Komponenten)
46
• fml.perspective.uri: eindeutige URI der Perspektive
• fml.perspective.description: Perspektivenbeschreibung
• fml.perspective.schema: physische URI eines validierenden Schemas für diese Perspektive (überschreibt die globale Schema-Zuordnung)
3. Namensraum-Deklaration
globale Informationen für im Dokument mögliche Namensräume mit
den optionalen Attributen
• fml.namespace.name: eindeutiger Name des Namensraumes (zur
Anwendung als Tag-Namenspräfix)
• fml.namespace.uri: eindeutige URI des Namensraumes
• fml.namespace.description: Namensraumbeschreibung
Alle Attribute außer *.name sind optional.
Diese Angaben unterstützen Leser, Autoren und externe Prozessoren dabei,
die für das Parsen, die Validierung oder sonstige Verarbeitungen wichtigen
Dokumenteigenschaften zu erkennen.
Grammatik: prolog
4.1.5
Tag
Tags sind das primäre Strukturierungsinstrument für FML-Dokumente. Es
existieren vier verschiedene Typen von Tags:
1. Öffnendes Tag
Das öffnende Tag beginnt eine Auszeichnung und bildet mit einem
korrespondierenden schließenden Tag rechts von sich ein Element.
2. Schließendes Tag
Das schließende Tag beendet eine Auszeichnung und bildet mit einem
korrespondierenden öffnenden Tag links von sich ein Element.
3. Leeres Tag
Das leere Tag steht autark in der Inhaltssequenz und umfasst keinen
Inhalt.
4. Multiples Tag
Das multiple Tag vereint mehrere Komponenten vom Typ öffnendes,
schließendes oder leeres Tag in irrelevanter Reihenfolge und erlaubt
keinen Inhalt dazwischen.
Das öffnende und das leere Tag verfügen über eine beliebige Anzahl geordneter Attribute, die wiederum eine beliebige Anzahl geordneter Wertbelegungen, eine Datenliste, besitzen. Diese Attributierung ist auch für die
47
öffnenden und leeren Tags in einem multiplen Tag anwendbar. Der Name
zugeordneter Attribute muss jeweils eindeutig sein. Sprachinhärente Attribute sind
• fml.trim: Instruktion an Parser zur Behandlung von Formatierungssymbolen während der Dokumentinterpretation
• fml.segment.id: ID des Segmentes, an dem ein Tag optional partizipiert (s. Kap. 6.9)
• fml.segment.pos: Position innerhalb des Segmentes
Die optionalen Attribute fml.segment.id und fml.segment.pos dürfen nur
gemeinsam und für ein Tag nur genau ein Mal verwendet werden. Eine verkürzte Schreibweise erlaubt die alternative und inhaltlich äquivalente Kodierung der Segmentierungsangaben als Tag-Suffix:
%{fml.segment.id}%{fml.segment.pos}
Jedes Tag ist eindeutig einem Namensraum zugeordnet. Der Name des
Namensraumes steht dem Namen des Tags als Präfix voran. Ist kein Namensraum zugewiesen, so befindet sich das Tag im Default-Namensraum.
Auch ist jedes Tag eindeutig genau einer Perspektive zugeordnet bzw. der
Default-Perspektive.
Dem öffnenden und dem schließenden Tag können als Namenssuffix IDs zugewiesen sein (s. Kap. 6.6). IDs müssen in derselben Perspektive pi , im
selben Namensraum nsj und für denselben Tag-Namen tnk in der Menge
öffnender Tags TS [pi ] [nsj ] [tnk ] eindeutig sein und müssen in der Menge
schließender Tags TE [pi ] [nsj ] [tnk ] eindeutig sein.
Grammatik: startTag, endTag, emptyTag, multiTag
4.1.6
Kommentar
Der Kommentar ist eine Markup-Komponente zur Repräsentation einer Dokumentation, hat kein Strukturierungsmotiv und erzeugt keine semantischen
Abhängigkeiten. Ein Kommentar kann nicht explizit einer Perspektive zugeordnet werden, sondern ist direktes oder indirektes Child aller Perspektiven.
Grammatik: comment
4.1.7
Processing Instruction
Processing Instructions werden von externen Prozessoren angesprochen und
haben kein Strukturierungsmotiv und auch keine relevante Semantik für die
Sprache FML. Es handelt sich um ein prozedurales Relikt in einer deklarativen Auszeichnungssprache. Eine Processing Instruction kann explizit einer
anderen als der Default-Perspektive zugeordnet werden.
48
In einer Processing Instruction werden zwei Literale gekapselt: target zur
Identifizierung des externen Prozessors und instruction als Kommando an
diesen Prozessor.
Grammatik: pi
4.1.8
Wildcard
Eine Wildcard ist ein Platzhalter für eine spätere Substitution in eine Komponente vom Typ Tag, Kommentar oder Processing Instruction. Vor einer
Substitution geht von diesem Platzhalter kein Strukturierungsmotiv aus,
lediglich eine Absichtserklärung. Wildcards können explizit einer anderen
als der Default-Perspektive zugeordnet werden.
Grammatik: wildcard
4.2
Grammatik
Formale Grammatik von FML-Dokumenten in EBNF -Notation mit 40 Produktionsregeln:
(* DOCUMENT *)
FML = { content | markup }.
(* COMPONENTS *)
markup = markupStart
markupEnd.
( prolog | startTag | endTag | emptyTag |
multiTag | pi | comment | wildcard )
prolog = '@' (prologDocument | prologPerspective | prologNamespace).
prologDocument = ( "fml.name=" '"' attributeValue '"' )
[ blank "fml.uri=" '"' attributeValue '"' ]
[ blank "fml.description=" '"' attributeValue '"' ]
[ blank "fml.version=" '"' attributeValue '"' ]
[ blank "fml.fragment=" '"' attributeValue '"' ]
[ blank "fml.schema=" '"' attributeValue '"' ]
[ blank "fml.trim=" '"' ( "true" | "false" ) '"' ]
[ blank "fml.writing-direction=" '"' ( "lr" | "rl" ) '"' ].
49
prologPerspective =
( "fml.perspective.name=" '"' attributeValue '"' )
[ blank "fml.perspective.uri=" '"' attributeValue '"' ]
[ blank "fml.perspective.description=" '"' attributeValue '"' ]
[ blank "fml.perspective.schema=" '"' attributeValue '"' ].
prologNamespace = ("fml.namespace.name=" '"' attributeValue '"' )
[ blank "fml.namespace.uri=" '"' attributeValue '"' ]
[ blank "fml.namespace.description=" '"' attributeValue '"' ].
content = contentChar { contentChar }.
multiTag = markupStart
markupEnd.
( startTag | endTag | emptyTag )
( startTag | endTag | emptyTag )
{ startTag | endTag | emptyTag }
startTag = [ perspective '|' ]
[ namespace ':' ]
name
[ '∼' tagId ]
[ '%' segmentId '%' segmentPos ]
{ blank attributeName '=' '"' attributeValue '"' { ','
'"' attributeValue '"' } }.
endTag = [ perspective '|' ]
'/'
[ namespace ':' ]
name
[ '∼' tagId ].
emptyTag = [ perspective '|' ]
[ namespace ':' ]
name
[ '%' segmentId '%' segmentPos ]
{ blank attributeName '=' '"' attributeValue '"' { ','
'"' attributeValue '"' } } '/'.
pi = [ perspective '|' ] '?' piTarget blank piInstruction.
comment = '!'
commentChar { commentChar } '!'.
wildcard = [ perspective '|' ].
50
(* CHARSEQUENCES *)
perspective = perspectiveChar { perspectiveChar }.
namespace = namespaceChar { namespaceChar }.
name = nameChar { nameChar }.
tagId = tagIdChar { tagIdChar }.
segmentId = segmentIdChar { segmentIdChar }.
segmentPos = segmentPosChar { segmentPosChar }.
attributeName = attributeNameChar { attributeNameChar }.
attributeValue = attributeValueChar { attributeValueChar }.
piTarget = piTargetChar { piTargetChar }.
piInstruction = piInstructionChar { piInstructionChar }.
(* CHARS *)
UTF8Char = 'U+0000'..'U+FFFF'.
blank = 'U+0020'.
markupStart = '<'.
markupEnd = '>'.
contentChar = UTF8Char - '<' - '>' - '\'.
perspectiveChar = UTF8Char - '<' - '>' - '\' - '|' - '?' - '∼'
- '%' - '=' - '@' - ':' - '!'.
namespaceChar = UTF8Char - '<' - '>' - '\' - '|' - '?' - '∼'
- '%'- '=' - '@' - ':' - '/'.
nameChar = UTF8Char - '<' - '>' - '\' - '|' - '?' - '∼' - '%'
- '=' - '@' - ':' - '/' - '!' - ' '.
tagIdChar = UTF8Char - '<' - '>' - '\' - ' ' - '!'
51
- '%' - '='.
segmentIdChar = UTF8Char - '<' - '>' - '\' - ' ' - '!'
- '%' - '='.
segmentPosChar = '0'+'1'+'2'+'3'+'4'+'5'+'6'+'7'+'8'+'9'.
attributeNameChar = UTF8Char - '<' - '>' - '\' - ' ' - '!'
- '%' - '=' - '?'.
attributeValueChar = UTF8Char - '"'.
piTargetChar = UTF8Char - ' '.
piInstructionChar = UTF8Char - '>'.
commentChar = UTF8Char - '!'.
Grundlage für die Erstellung eines FML-Dokument-Parsers in einer höheren
Programmiersprache ist eine EBNF -Grammatik. Parser werden im Allgemeinen nicht individuell entwickelt, sondern generiert. Dieses Vorgehen hat
sich als deutlich zuverlässiger und sparsamer erwiesen. Als Konfigurationsskript wird in Anhang D eine ohne Informationsverlust leicht abgewandelte
Form (geringerer Substitutionsgrad, höhere Redundanz, schlechtere Lesbarkeit) der Grammatik präsentiert. FML-Dokumente können, da der gewählte
Parser Coco/R1 [106] ein reiner LL(1)-Parser ist, somit durch eine deterministische LL(1)-Grammatik beschrieben werden. FML ist somit auch eine
LL(1)-Sprache. Coco/R hat die Grammatik aus Anhang D strengen Prüfungen unterzogen und als LL(1)-Grammatik verifiziert.
Es wurde bei der Gestaltung der Grammatik bewußt auf Lookahead= 1
Wert gelegt, da der Analyseaufwand exponentiell von der Anzahl der Vorausschauzeichen abhängt: FML-Dokumente lassen sich deterministisch und
vor allem hochperformant parsen.
Die Grammatik zeigt, dass – ganz im Gegensatz zu XML – nur wenige Bedingungen für die lexikalische Gestaltung von Namensbezeichnern aufgestellt
werden. In der Tat erlaubt diese Grammatik die Verwendung von äußerst
kryptischen Namen, die sich optisch für einen Leser nur schwer als solche
identifizieren lassen dürften. Dieser Umstand ist gewollt und entspricht dem
Selbstverständnis der Sprache FML: maximaler Freiheitsgrad und minimale
Restriktion. Selbstverständlich sind Richtlinien für eine vertretbare Auswahl aus dem UTF-8 -Zeichenpool und für einen ergonomischen Einsatz der
Grammatik angebracht, setzen jedoch in zweiter Instanz auf diese erst auf.
Mit Hilfe des Maskierungskonzeptes kann jedes gewünschte Zeichen an je1
Prof. H. Mössenböck, Johannes Kepler Universität Linz, Institut für Systemsoftware,
http://www.ssw.uni-linz.ac.at/Research/Projects/Coco
52
der Position im Dokument verwendet werden, auch wenn die Grammatik
hier Einschränkungen vorsieht. Das Prinzip ist simpel und setzt eine Vorverarbeitung (Preprocessing) vor der Dokumentanalyse voraus: Jedes dem
Makierungszeichen “\“ unmittelbar rechts nachfolgende Zeichen wird in eine
hexadezimale UCS-Zeichenreferenz übersetzt und übernommen. Siehe [186,
Kap. 4.1 Character and Entity References]. Die Syntax der Zeichenreferenz gleicht der von XML bekannten, und es gibt keine Schnittmenge
zwischen ihr und den von der FML-Grammatik restriktiv verwendeten Token-Startsymbolen. Eine native Darstellungsform eines Zeichens in UTF-8 ,
dasselbe Zeichen maskiert, die dezimale und hexadezimale Kodierung sind
außerhalb des grammatikalischen Kontextes semantisch vorerst identisch.
So kapseln die Kodierungen
<
≡
\<
≡
<
≡
<
alle dasselbe Zeichen. Jedoch ergeben sich im Dokumentkontext zwei gänzlich verschiedene Interpretationen, da das Zeichen < einem lexikalischen
Scanner indiziert, ob ein content-Token beendet ist und markup beginnt.
Eine zusätzliche Regel wird aufgestellt: Namen und Identifikatoren dürfen
nicht mit “fml.“ beginnen! Dieses Literal ist grundsätzlich reserviert für
sprachinhärente Semantik. Ein Parser muss diese Anforderung, die nicht
Bestandteil der Grammatik ist, im Anschluss an die lexikalische Dokumentanalyse (Postprocessing) überprüfen.
53
4.3
Gültigkeit
Es werden drei Gültigkeitszustände für eine FML-Instanz abgegrenzt:
1. wohlgeformt (engl.: wellformed)
2. geschachtelt (engl.: nested)
3. valide (engl.: valid)
Definition 1
Entspricht ein FML-Dokument syntaktisch der Grammatik der Sprachspezifikation, so ist es wohlgeformt und besitzt einen korrespondierenden FMLGraphen.
Definition 2
Ist ein FML-Dokument wohlgeformt und sind die Element-Knoten des korrespondierenden FML-Graphen streng hierarchisch unter genau einer Element-Root strukturiert, so ist es geschachtelt.
Definition 3
Ist ein FML-Dokument wohlgeformt und entspricht der Strukturbeschreibung eines FML-Schemas, so ist die Sprachinstanz gegenüber dem Schema
valide.
Der Gültigkeitszustand valide impliziert wohlgeformt, aber nicht zwingend
geschachtelt, geschachtelt impliziert zwingend wohlgeformt.
Das Zustandskriterium geschachtelt beantwortet die Frage, ob die neuen
– Hierarchiezwang aufhebenden – Freestyle-Konzepte Interferenz (s. Kap.
10.4), Kongruenz (s. Kap. 10.6), Independenz (s. Kap. 10.7) und Segmentierung (s. Kap. 10.8) verwendet wurden oder strukturelle XMLKompatibilität besteht.
54
Kapitel 5
Freestyle Graph
Das Ganze ist mehr als die
Summe seiner Teile.
Aristoteles
384 v. Chr. – 322 v. Chr.
Zu jedem wohlgeformten FML-Dokument existiert ein korrespondierender
FML-Graph, der insbesondere der Visualisierung eines FML-Dokumentes
und der Objektrepräsentation im Rahmen einer Implementierung dient, sowie Grundlage für Modelltransformationen ist. In diesem Kapitel wird dieser
Graph definiert, semantisch interpretiert und in seinen graphentheoretischen
Eigenschaften beschrieben.
5.1
Knoten
Alle Knoten des polyhierarchischen FML-Graphen werden in ihren Eigenschaften definiert: Typ, Darstellungsform für eine Visualisierung, korrespondierende Komponente des FML-Dokumentes, mögliche Children und Parents
ˆ Darstellungstext1 ).
sowie gekapselte Informationen (unterstrichen =
5.1.1
Dokument
Knoten-Typ: fml.node.document
Funktion: Virtueller Root-Knoten des polyhierarchischen FML-Graphen. Er
repräsentiert das korrespondierende FML-Dokument im Ganzen und kapselt
alle globalen Deklarationen des Prologs.
1
Die graphische Beschriftung ist für alle Knoten optional und darf durch beliebige
’. . . ’-Substitution verkürzt werden.
55
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Trapez (symmetrisch)
#07F9FC
#03022F
Possessa [58] | Courier New
fml.name | ’FML’
Komponenten: Dokument (s. Kap. 4.1.1), Prolog (s. Kap. 4.1.4)
Parent-Knoten: keine
Child-Knoten: fml.node.perspective+
Informationen:
• fml.node-type = ’fml.node.document’
• fml.name?
• fml.uri?
• fml.description?
• fml.version?
• fml.fragment?
• fml.schema?
• fml.trim? = ’true’ | ’false’
• fml.writing-direction? = ’lr’ | ’rl’
• (fml.perspective.name, fml.perspective.uri,
fml.perspective.description, fml.perspective.schema)∗
• (fml.namespace.name, fml.namespace.uri,
fml.namespace.description)∗
5.1.2
Perspektive
Knoten-Typ: fml.node.perspective
Funktion: Virtueller Root-Knoten unterhalb des Dokument-Knotens zur Unterordnung aller Markup-Komponenten einer bestimmten Perspektive. Nicht
56
die Perspektiven aus den globalen Deklarationen des Prologs finden hier Anwendung, sondern ausschließlich die tatsächlich im Dokument verwendeten
Perspektiven: Alle identifizierbaren Perspektiven aus Markup-Komponenten
werden disjunkt zu Knoten des Typs fml.node.perspective. Die Zuordnung zu globalen Deklarationen von Perspektiven im Prolog erfolgt über den
Namen (fml.perspective.name). Eine Zuordnung muss jedoch nicht zwingend gegeben sein.
Ein Sonderfall ist die Default-Perspektive. Ihr ordnen sich alle MarkupKomponenten unter, die von der optionalen Perspektivenzuordnung keinen
Gebrauch machen. Ein Dokument ohne jede Verwendung des Konzeptes
der Perspektiven wird also genau eine Perspektive besitzen: eine DefaultPerspektive mit dem Namen fml.default.
Für alle Perspektiven gilt: Keine Inhalts-Komponente darf exkludiert werden, die Blätter des Knotens vom Typ fml.node.perspective umfassen
vollständig alle Knoten vom Typ fml.node.content.
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Trapez (symmetrisch)
#000000
#FFFFFF
Courier New
fml.perspective.name | ’fml.default’
Komponente: Dokument (s. Kap. 4.1.1)
Parent-Knoten: fml.node.document
Child-Knoten:
• fml.node.content∗
• fml.node.element∗
• fml.node.comment∗
• fml.node.pi∗
• fml.node.wildcard∗
Informationen:
• fml.node-type = ’fml.node.perspective’
• fml.perspective.name?
57
5.1.3
Inhalt
Knoten-Typ: fml.node.content
Funktion: Die UTF-8 -Zeichensequenz zwischen zwei Markup-Komponenten
bildet einen Inhaltsknoten. Diese Sequenz kann auch leer (∅) oder ausschließlich mit Formatierungssymbolen besetzt sein (∼). Die Knoten vom
Typ fml.node.content stellen somit den eigentlich Inhalt eines FML-Dokumentes exklusive Markup dar und sind stets Blätter in einem FML-Graphen.
Darüber hinaus werden auch die Wertbelegungen von Attributen durch Inhaltsknoten repräsentiert.
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Rechteck (abgerundete Ecken)
#000000
#FFFFFF
Arial
fml.content | ’∅’ | ’∼’
Komponente: Inhalt (s. Kap. 4.1.2)
Parent-Knoten:
• fml.node.perspective∗
• fml.node.attribute?
Child-Knoten: keine
Informationen:
• fml.node-type = ’fml.node.content’
• fml.content
5.1.4
Element
Knoten-Typ: fml.node.element
Funktion: Elemente sind das primäre Strukturierungsinstrument zur Gestaltung eines polyhierarchischen FML-Graphen. Zwei korrespondierende
Tag-Komponenten (bzw. ein leeres Tag) formen einen Knoten vom Typ
fml.node.element. Dieser Knoten untersteht direkt oder indirekt genau
einer Perspektive, kann Child mehrerer Elemente und selbst Parent beliebig
58
vieler Elemente sein. Darüber hinaus können Element-Knoten durch Attribut-Children verfeinert werden.
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Rechteck
#03022F
#07F9FC
Courier New
fml.element.name
Komponente: Tag (s. Kap. 4.1.5)
Parent-Knoten:
• fml.node.perspective?
Child-Knoten:
• fml.node.content∗
• fml.node.attribute∗
• fml.node.comment∗
• fml.node.pi∗
• fml.node.wildcard∗
Informationen:
• fml.node-type = ’fml.node.element’
• fml.element.namespace.name?
• fml.element.name
• fml.element.id?
• fml.element.autocompleted? = ’start-tag’ | ’end-tag’
• fml.element.trim? = ’true’ | ’false’
59
5.1.5
Attribut
Knoten-Typ: fml.node.attribute
Funktion: Das Attribut reichert als Child genau eines Knoten vom Typ
fml.node.element diesen um Informationen, eine geordnete Liste von Inhalten, an.
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Rechteck
#03022F
#FFFFFF
Courier New
fml.attribute.name
Komponente: Tag (s. Kap. 4.1.5)
Parent-Knoten: fml.node.element
Child-Knoten: fml.node.content+
Informationen:
• fml.node-type = ’fml.node.attribute’
• fml.attribute.name
5.1.6
Kommentar
Knoten-Typ: fml.node.comment
Funktion: Kommentar repräsentiert Dokumentation und hat kein Strukturierungsmotiv.
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Hexagon
#000000
#C8FFCC
Arial
fml.comment.content
60
Komponente: Kommentar (s. Kap. 4.1.6)
Parent-Knoten:
Child-Knoten: keine
Informationen:
• fml.node-type = ’fml.node.comment’
• fml.comment.content
5.1.7
Knoten-Typ: fml.node.pi
Funktion: Processing Instruction wird von externen Dokument-Prozessoren
angesprochen und hat kein Strukturierungsmotiv.
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Parallelogramm
#05ED04
#000000
Courier New
fml.pi.target
Komponente: Processing Instruction (s. Kap. 4.1.7)
Parent-Knoten:
Child-Knoten: keine
Informationen:
• fml.node-type = ’fml.node.pi’
• fml.pi.target
• fml.pi.instruction
61
5.1.8
Wildcard
Knoten-Typ: fml.node.wildcard
Funktion: Wildcard ist ein Platzhalter für eine spätere Substitution in einen
Knoten vom Typ fml.node.element, fml.node.comment oder fml.node.pi.
Darstellung:
Geometrische Form:
Vordergrund:
Hintergrund:
Schrift:
Text:
Raute
–
#CC0E1C
–
–
Komponente: Wildcard (s. Kap. 4.1.8)
Parent-Knoten:
Child-Knoten: keine
Informationen: fml.node-type = ’fml.node.wildcard’
5.2
Kanten
Die Kantenmenge des FML-Graphen besteht ausschließlich aus gerichteten
Kanten zwischen zwei Knoten, die in hierarchischer Beziehung stehen:
n
Parent −→ Child
Mit Ausnahme von fml.node.document besitzt jeder Knoten mindestens
eine eingehende Kante. fml.node.content, fml.node.comment, fml.node.pi
und fml.node.wildcard haben niemals ausgehende Kanten.
Ein FML-Graph hat genau einen Knoten vom Typ fml.node.document, alle
anderen können in beliebiger Häufigkeit auftreten. Ein leeres FML-Dokument wird durch einem Knoten vom Typ fml.node.document repräsentiert.
Jede Kante ist mit n ∈ ℕ beschriftet. Die Wertbelegungen für alle ausgehenden Kanten eines Knotens entsprechen einer lückenlos aufsteigenden
Nummerierung, beginnend bei 0. Dieser Wert markiert die Position der
62
korrespondierenden Komponente in der linearen Inhaltssequenz eines Dokumentes.
Beziehungen zwischen den verschiedenen Knoten-Typen sind durch gerichtete Kanten mit folgenden Kardinalitäten2 möglich:
5.3
?∗
?∗
?∗
wildcard
∗∗
∗?
?∗
∗1
pi
∗?
∗∗
∗∗ 1∗
∗∗
∗∗
∗∗
attribute
perspective
∗∗
?∗
∗∗
comment
1+
+
1
element
document
perspective
content
element
attribute
comment
pi
wildcard
content
fml.node.
document
fml.node.
∗?
∗?
∗?
∗∗
∗∗
∗∗
Eigenschaften
Für einen FML-Graphen sind folgende Eigenschaften charakteristisch:
• azyklisch
Es existiert kein Rundweg.
• gerichtet
Jede Kante ist eine Parent−→Child - Beziehung.
• einfach
Es existieren keine Mehrfachkanten.
• zusammenhängend
Von Wurzelknoten aus existiert mindestens ein gerichteter Weg zu jedem anderen Knoten.
• kantengewichtet
Kanten sind numerisch beschriftet.
• attributierten Knoten
Knoten können Attribut-Wert-Paare zugeordnet werden.
2
Notation: UML-Multiplizität [68, S. 98ff.] mit 0..1 =’?’, 1..∗ =’+’, 0..∗ =’∗’
63
• Root
Der Wurzelknoten hat keinen Parent-Knoten, jeder andere mindestens
einen. Die Wurzel wird stets durch die Komponente Dokument repräsentiert.
• Blätter
Inhalts-Knoten haben keine Children.
• Pfadeinschränkung
Ein Knoten darf über mehrere indirekte Pfade Child eines anderen
Knotens sein. Jedoch dürfen ein indirekter und ein direkter Pfad zwischen zwei Knoten in einer Parent-Child-Beziehung niemals gleichzeitig existieren: Redundante Pfade schließen direkte Kantenverbindungen zwischen zwei Knoten aus.
• polyhierarchisch
Eine Polyhierarchie (auch Polytree [127] oder Multitree) ist ein DAG
und eine hierarchische Struktur, in der Knoten auch mehrere übergeordnete Knoten (Parents) haben dürfen. Jeder Knoten ist durch
mindestens einen gerichteten Pfad von der Wurzel aus erreichbar. Polyhierarchien sind selbstähnlich: Jeder Teilgraph ist gleichsam eine
Polyhierarchie.
Folgender Beispielgraph visualisiert eine Polyhierarchie und entspricht den
graphentheoretischen Anforderungen:
In der Sprache GXL [198] können beliebige Graphen beschrieben und ausgetauscht werden. Auch können Klassen von Graphen in einem GXL-Schema,
das selbst wiederum durch ein Metaschema validiert wird, definiert werden. In Anhang F wird ein GXL-Schema präsentiert, das FML-Graphen
im Allgemeinen beschreibt und konkrete FML-Graphen als GXL-Instanzen
validieren [84] kann. Dieses Schema ist somit eine formale Spezifikation von
FML-Graphen in der Syntax der fundierten Auszeichnungssprache GXL.
64
Kapitel 6
Freestyle Konzepte
Alles sollte so einfach wie
möglich sein – aber nicht
einfacher.
Albert Einstein
1879 – 1955
Die wesentlichen Konzepte und Methoden für das Auszeichnen mit FML
werden vorgestellt und in illustrativen Beispielszenarien mit FML-Dokumenten und FML-Graphen veranschaulicht. Autoren und Modellierer gewinnen mit diesem Kapitel die Handlungskompetenz für eine ausschöpfende
Nutzung aller Sprachpotenziale.
6.1
Annotieren
Markup ist gemäß [126]
[. . . ] simultaneously embedded and separable [. . . ] part of the
text, yet distinguishable from it.
So werden auch für FML alle Markup-Komponenten (Prolog, Tag, Kommentar, Processing Instruction und Wildcard) in den Inhalt eingefügt. Die
Position in der Inhaltssequenz ist relevant. Veränderungen der Position eingebetteter Annotationen führen zu einer gänzlich neuen Interpretation eines
FML-Dokumentes in einem FML-Graphen.
Markup wird durch die Begrenzungssymbole < und > identifiziert. Eine
Verwendung beider Symbole außerhalb dieser Separierungsfunktion muss
durch ein vorangestelltes Maskierungszeichen (den üblichen Backslash ’\’)
erfolgen.
Folgendes Beispielszenario illustriert die Verwendung aller Markup-Komponenten (exkl. Prolog) in einem FML-Dokument und aller Knotentypen in
einem korrespondierenden FML-Graphen.
65
Inhalt:
able was i ere i saw elba
FML-Dokument 1 :
01
02
03
04
05
06
07
08
09
<?palindrome start>
able was i
<!Bonaparte!>
e
<>
re i saw
<island latin="ilva">
elba
</island>
FML-Graph:
1
Alle folgenden Dokumente wurden mit Coco/R gegenüber der FML-Grammatik
(s. Kap. 4.2) als wohlgeformt verifiziert.
66
Das leere FML-Dokument wird durch folgenden FML-Graphen repräsentiert:
6.2
Deklarieren
Zu Beginn eines FML-Dokumentes können Informationen über das Dokument selbst, Perspektiven und Namensräume deklariert werden. Diese Deklarationen sind optional und für Autoren, Editoren und externe Prozessoren eine Unterstützung für die Bewertung des Dokumentes. Die Attribute
jeder Deklaration sind selbstbeschreibend und für alle Anwendungsfälle einer
deklarativen Auszeichnungssprache relevant. Alle deklarierten Informationen werden für die Dokumentinterpretation verlustfrei in die attributierte
Wurzel des FML-Graphen, ein Knoten des Typs fml.node.document, übernommen.
In folgendem Beispiel sind alle der optionalen Deklarationen mit allen möglichen Attributen enthalten.
FML-Dokument:
<@fml.name="important institutions" fml.uri="http://www.freestyle-markup.org"
fml.description="institutions relevant to FML" fml.version="1.0" fml.fragment="f1"
fml.schema="temp.fsd" fml.trim="true" fml.writing-direction="lr">
<@fml.perspective.name="org"
fml.perspective.uri="http://de.wikipedia.org/wiki/Organisation"
fml.perspective.description="organisations" fml.perspective.schema="org.fsd">
<@fml.perspective.name="geo"
fml.perspective.uri="http://de.wikipedia.org/wiki/Geographie"
fml.perspective.description="geographic inf." fml.perspective.schema="geo.fsd">
<@fml.namespace.name="iso31661"
fml.namespace.uri="http://de.wikipedia.org/wiki/ISO_3166"
fml.namespace.description="iso country codes">
<org|university>Universität Bremen<org|/university>,
<geo|iso31661:DE>Bremen<geo|/iso31661:DE>
<org|institute>Institut für Deutsche Sprache<org|/institute>,
67
<geo|iso31661:DE>Mannheim<geo|/iso31661:DE>
<org|conference>Balisage Conference<org|/conference>,
<geo|iso31661:CA>Montréal<geo|/iso31661:CA>
6.3
Tagging
Das primäre Strukturierungsmittel für FML-Dokumente sind Tags, neben
dem leeren Tag insbesondere das Tag-Paar, bestehend aus einem öffnenden
Start- und einem korrespondierenden schließenden End-Tag. Ein Start-Tag
und ein End-Tag korrespondieren und bilden ein Element, wenn beide in derselben Perspektive und im selben Namensraum denselben Namen vorweisen.
Die Sequenz zwischen zwei korrespondierenden Tags wird dem Element als
Child untergeordnet.
Das Auszeichnen mit Tags und die Interpretation von Tags in ElementBeziehungen entsprechen grundsätzlich dem Vorgehen in XML/SGML. Als
generalisierende Auszeichnungssprache hat FML keinen Einfluss auf die Semantik von Tags. In folgendem Beispiel werden drei Aspekte ausgezeichnet.
Inhalt 2 :
Fix Schwyz quäkt Jürgen blöd vom Paß!
FML-Dokument:
<cheer>
Fix
<canton>
Schwyz
</canton>
</cheer>
quäkt Jürgen blöd vom Pa
<orthography1903/>
ÿ!
2
Einziges bekanntes echtes Pangramm in deutscher Sprache.
68
FML-Graph:
6.4
Attribuieren
Attribute verfeinern Tags, reichern diese um zusätzliche Informationen an.
In öffnenden oder leeren Tags eines FML-Dokumentes wird diese Spezialisierung durch Deklaration einer beliebig langen geordneten Liste von Attributen
mit eindeutigem Namen erzielt. Somit können Elemente eine unbegrenzte
Anzahl von direkten Children, Knoten vom Typ fml.node.attribute, besitzen. Jedes Attribut wiederum verfügt über eine nichtleere geordnete Werteliste.
Gemäß dem objektorientierten Vererbungungsparadigma bietet FML einen
Mechanismus zur Attribut-Vererbung an: Ein Element 1 erbt von einem
Element 0 , wenn es direktes oder indirektes Child von 0 ist. Dieses Konzept hat weder syntaktische Auswirkungen für ein FML-Dokument noch
beeinflusst es die Transformation in einen FML-Graphen. Vielmehr spiegelt sich das Konzept der Vererbung auf der Implementierungsebene wider:
Mittels der Methode
Attribut[] Element.getAttributes(boolean enableInheritance)
können Element-Attribute je nach Parameterwert enableInheritance unter
oder ohne Anwendung des Vererbungskonzeptes abgerufen werden.
Folgendes Szenario illustriert Konzept und Anwendung der Vererbung.
Inhalt: Die Auszeichnung des Inhaltes
A slut nixes sex in Tulsa
69
über die typographischen Merkmale kursiv, schwarz, rot, unterstrichen und
MAJUSKELSCHRIFT wird mittels allgemeinen Formatierung-Tags f∗ und
der spezialisierenden Attribute style, color und ucase realisiert. Mögliche Wertbelegungen für style sind i für kursiv und u für unterstrichen.
Mögliche Wertbelegungen für color sind b für schwarz und r für rot. Mögliche Wertbelegungen für ucase sind t und f. Vier über diese Merkmale
vorgenommene Auszeichnungen erzeugen folgende Dokumentstruktur:
A
s
l
u
t
n i x
E
S
S
E
x
i
f0 style=u color=r
f1 color=b
f2 ucase=t
f3 style=i
FML-Dokument:
01
02
03
04
05
06
07
08
09
10
11
12
13
A
<f0 style="u" color="r">
s
<f1 color="b">lut n</f1 >
i
<f3 style="i">
x
<f2 ucase="t">es se</f2 >
</f0 >
</f3 >
x
in Tuls
a
FML-Graph:
70
n
T
u
l
s
a
Implementierung:
f0 .getAttributes(false):
f0 .getAttributes(true):
style="u", color="r"
style="u", color="r"
color="b"
color="b", style="u"
ucase="t"
ucase="t", style="i","u", color="r"
style="i"
style="i"
6.5
Interferenz
Die Auszeichnung interferenter Strukturen unterliegt in FML – im Gegensatz
zu XML – keinerlei Restriktion und bedarf keiner besonderen Aufmerksamkeit. Die Start- und Endpositionen von semantischen Inhaltsabschnitten
werden jeweils separat und unabhängig voneinander ausgezeichnet. Entstehende Überschneidungen vorgenommener Auszeichnungen sind uneingeschränkt zulässig und werden im Rahmen der Transformation eines FMLDokumentes in einen FML-Graphen berücksichtigt: Ein Inhaltssegment, das
in den Auszeichnungsbereich von n Tag-Paaren fällt, wird in der Repräsentationsform FML-Graph direkt oder indirekt gleichsam Child von n Elementen
sein.
Folgendes Beispielszenario illustriert den Umgang mit der 2– bis 3fachen
Überschneidung von Inhalt durch semantische – aus Gründen der Anschaulichkeit typographische – Auszeichnungen:
redrumsirismurder
über die typographischen Eigenschaften kursiv, fett und rot
redrumsirismurder
erzeugt folgende Dokumentstruktur (kursiv=i, fett=b, rot=r):
redrumsirismurder
i
b
r
r
i
FML-Dokument:
r e d <r> r u m </r> s i r i s <r> m u r </r> d e r
71
FML-Graph:
6.6
Identifizieren
Das Konzept der Identifizierung dient der sicheren Bestimmung korrespondierender Tags. Grundsätzlich korrespondieren ein Start-Tag und ein EndTag, wenn beide in derselben Perspektive und im selben Namensraum denselben Namen vorweisen. Sobald in einem Dokument jedoch mehrere gleichnamige Start-Tags oder mehrere gleichnamige End-Tags vorhanden sind,
gestaltet sich die Identifizierung korrespondierender Tags für die ElementKomposition ambivalent. Diese Interpretationsunsicherheit wird durch das
Identifizierungskonzept aufgelöst: Die Zuordnung eines eindeutigen Identifikationsschlüssels IDi (mittels Tag-Namenssuffix ∼IDi ) zu beiden Komponenten eines Tag-Paares verschweißt diese und gewährleistet Korrespondenz.
Zweckmäßig ist dieses Konzept insbesondere für Szenarien, in denen komplexe Strukturen mit interferierenden Auszeichnungen (s. Kap. 6.5) auftreten und die Tag-Menge, das zur Verfügung stehende Tag-Vokabular, eine
hohe semantische Überladung aufweist.
Folgendes Beispiel illustriert die Anwendung des Interferenzkonzeptes an einem typographischen Szenario:
Inhalt: Für die Auszeichnung des Inhaltes
redrumsirismurder
redrumsirismurder
72
steht genau ein Formatierungselement (Tag-Name: f) zur Verfügung. Die
Spezialisierung von f erfolgt mittels des Attributes style und dessen möglichen Wertbelegungen i für kursiv, b für fett und r für rot. Die resultierende
Dokumentstruktur ist folgende:
r
e
d
r
u
m
s
i
r
f style=i
i
s
m
u
r
d
e
r
f style=b
f style=r
f style=r
f style=i
Erfolgt für dieses Szenario die Auszeichnung der interferenten Strukturen
ohne Anwendung des Identifizierungsmechanismus
r <f style=i> e d <f style=r> r u </f> m </f> s i r <f style=b>
i s <f style=r> m <f style=i> u </f> r </f> d e </f> r
so erfolgt die Bestimmung korrespondierender Tags von außen nach innen,
gleich dem monohierarchischem Properly-Nested-Prinzip von XML. Dieses
FML-Dokument würde demnach in einem FML-Graphen wie folgt interpretiert werden:
Diese Default-Interpretation des Dokumentes spiegelt jedoch nicht das reale
Szenario wider, in der die Zuordnung von Tags zu korrespondierenden TagPaaren eine andere ist. Die Frage, welches <f> mit welchem </f> zusam73
men ein Element bildet3 , muss entscheidbar sein. Unter Anwendung des
einfachen und intuitiven Konzeptes der Identifizierung kann das richtige Ergebnis erzielt werden:
FML-Dokument:
r <f ∼i1 style=i> e d <f ∼r1 style=r> r u </f ∼i1> m </f ∼r1>
s i r <f ∼b1 style=b> i s <f ∼r2 style=r> m <f ∼i2 style=i>
u </f ∼b1> r </f ∼r2> d e </f ∼i2> r
FML-Graph:
6.7
Kongruenz
Die Auszeichnung kongruenter Strukturen wird in FML mittels unzerlegbarer multipler Tags realisiert. Ein multiples Tag fasst beliebig viele StartTags, End-Tags und leere Tags in irrelevanter Reihenfolge zusammen und
erlaubt keinen Inhalt dazwischen.
Das Konzept der Kongruenz gewährleistet Struktursicherheit und Konsistenz. Bei der Aneinanderreihung von Tags wie in XML entstehen unbeabsichtigte hierarchische Beziehungen sowie Möglichkeiten des Aufbrechens
der Kongruenz durch Einfügen von Inhalt zwischen den einzelnen Tags.
Folgendes Beispielszenario illustriert das Auszeichnen kongruenter Strukturen:
3
Es sind 2! + 3! = 8 Elementanordnungen möglich. Das Dokument kann also in acht
verschiedenen Varianten interpretiert werden.
74
erzeugt folgende Dokumentstruktur (kursiv=i, fett=b, rot=r):
b
i
r
FML-Dokument:
<>Cigar? Toss it in a can. <<r>>It is so tragic.</r>
FML-Graph:
6.8
Independenz
FML erlaubt die konsolidierte Auszeichnung heterogener Perspektiven in
ein redundanzfreies Dokument. Eine Perspektive repräsentiert eine identifizierte Annotationsebene. Die Komponenten Tag, Processing Instruction
und Wildcard können optional genau einer Perspektive zugeordnet werden.
Die Zuordnung zu einer Perspektive Pi mit dem eindeutigen Namen Pi name
erfolgt durch Einfügen des Präfixes Pi name| vor der Kernformulierung in
75
jeder Markup-Komponente und nach dem (das Markup einleitende) Begrenzungssymbol <. Dieses Zuordnungskonzept ist nur auf Komponentenebene
anwendbar, nicht zum Beispiel auf Attributebene oder für die einzelnen Tags
in einem multiplen Tag.
Die verschiedenen Perspektiven teilen sich alle Inhalte im Dokument. Komponenten, die nicht explizit einer Perspektive zugeordnet sind, unterstehen
der Default-Perspektive. Somit besitzt jedes FML-Dokument mindestens
eine Perspektive.
Perspektiven können optional im Prolog deklariert werden. Weder müssen
deklarierte Perspektiven im Dokument verwendet werden noch müssen die
im Dokument verwendeten Perspektiven im Prolog deklariert sein. Für eine
Dokumentinterpretation in einem FML-Graphen werden alle tatsächlich im
Dokument verwendeten Perspektiven mit Informationen einer Deklaration
gegebenenfalls verknüpft und in Knoten vom Typ fml.node.perspective
transformiert. Optional dürfen während der Transformation beliebige Perspektiven inkludiert oder exkludiert werden.
Folgendes Beispielszenario illustriert die Anwendung des Independenzkonzeptes für zwei unabhängige Annotationsebenen auf derselben Inhaltssequenz:
Inhalt: Die Auszeichnung des Inhaltes4
Lewd did I live & evil I did dwel
über die typographischen Eigenschaften fett und rot wird von zwei unabhängigen Illustratoren I1 und I2 verschiedenartig vorgenommen:
I1 : Lewd did I live & evil I did dwel
I2 : Lewd did I live & evil I did dwel
und resultiert in folgenden Dokumentstrukturen (fett=b, rot=r):
Lewd did I live & evil I did dwel
I1 :
b
r
b
I2 :
r
FML-Dokument I1 :
Lewd <i1|b>did I live<i1|/b> & <i1|r>evil<i1|/r> I did dwel
4
Erster bekannter Palindromsatz in englischer Sprache von John Taylor (1580 – 1653 ).
76
FML-Graph I1 :
FML-Dokument I2 :
Lewd did I <i2|b>live & <i2|r>evil<i2|/b> I did<i2|/r> dwel
FML-Graph I2 :
FML-Dokument I1 ∪ I2 :
Lewd <i1|b>did I <i2|b>live<i1|/b> & <i2|r><i1|r>evil
<i1|/r><i2|/b> I did<i2|/r> dwel
77
FML-Graph I1 ∪ I2 :
6.9
Segmentieren
Das mächtige Konzept der Segmentierung ermöglicht die Komposition neuer
Inhalte aus Segmenten des bestehenden Inhaltes. Ein virtuelles Element
kapselt die Inhalte partizipierender Tags und wird mit der konstanten Position -1 dem entsprechenden Perspektivknoten (fml.node.perspective) in
einem FML-Graphen als direktes Child unterstellt. Da mittels der sprachinhärenten Tag-Attribute
fml.segment.id
fml.segment.pos
neben Position und Lauflänge auch die Anzahl und Ordnung beteiligter Segmente frei wählbar ist, ergeben sich unbegrenzte Kompositionsmöglichkeiten
aus dem Zeichenvorrat der linearen Inhaltssequenz eines Dokumentes.
Eine intensive Nutzung dieses Konzeptes verringert die Lesbarkeit des Dokumentes, für den rein maschinellen Betrieb jedoch ergeben sich fulminante
Möglichkeiten5 .
5
Der Wortschatz einer Sprache kann unter Anwendung des Segmentierungskonzeptes
allein über das Alphabet der Sprache redundanzfrei vollständig ausgezeichnet werden.
78
In folgendem Beispiel wird
eve
aus
risetovotesir
zusammengestellt.
FML-Dokument:
ris
<s1 fml.segment.id="eve" fml.segment.pos="0">
e
</s1>
to
v
</s2>
ot
e
</s3>
sir
FML-Graph:
79
6.10
Fragmentieren
In FML ist auch ein Fragment eines wohlgeformten FML-Dokumentes ein
wohlgeformtes FML-Dokument. Infolge dieser Anforderung können StartTags oder End-Tags auch außerhalb der Dokumentgrenzen liegen. Wenn ein
Start-Tag kein korrespondierendes End-Tag finden kann, so darf unterstellt
werden, dass es bis zum Dokumentende auszeichnet. Das fehlende EndTag wird dann für die Dokumentinterpretation am Dokumentende eingefügt.
Wenn ein End-Tag kein korrespondierendes Start-Tag finden kann, so darf
unterstellt werden, dass es vom Dokumentanfang auszeichnet. Das fehlende
Start-Tag wird dann für die Dokumentinterpretation am Dokumentanfang
eingefügt. Sind mehrere Tags zu Beginn oder zum Ende eines Dokumentes
zu ergänzen, so werden diese in multiplen Tags zusammengefasst.
Diese automatische Ergänzung erfolgt im Zuge der Transformation eines
FML-Dokumentes in einen FML-Graphen (s. Kap. 7). Das Attribut
fml.element.autocompleted = ’start-tag’ | ’end-tag’
indiziert für einen FML-Graph-Knoten vom Typ fml.node.element, dass
die automatische Ergänzung für dieses Element angewendet wurde. Die
Rückübersetzung in das FML-Dokument wird das fragmentierte Urspungsdokument mit isolierten Tags wiederherstellen.
Der Nutzen dieses Konzeptes besteht darin, dass Dokumente fragmentiert
serialisiert und ausgetauscht werden können und dass zugunsten der Dokumententropie eine sparsamere Kodierung möglich ist.
In folgendem Beispiel ist FML-Dokument 1 mit vier Tags ausgezeichnet worden. Jedes dieser Tags ist isoliert. Automatische Ergänzung (Zeile 01 und
03) führt zu FML-Dokument 2 , das sodann in einem FML-Graphen interpretiert werden kann.
80
FML-Dokument 1 :
si<t1 ∼IDX>t on a po<t2>tato p<t3>an ot</t1>is
FML-Dokument 2 :
01 <t1>
02 si<t1∼IDX>t on a po<t2>tato p<t3>an ot</t1>is
03 </t1∼IDX /t2 /t3>
FML-Graph:
81
Kapitel 7
Transformation
Es fürchtet jemand die
Umwandlung? Was kann denn
ohne Umwandlung geschehen?
Was denn ist der Natur des Alls
lieber und vertrauter?
Mark Aurel
121 – 180
Es wird gezeigt, wie mittels Methoden des Compilerbaus und der Graphtransformation FML-Dokumente und FML-Graphen bidirektional ineinander konvertiert werden. Durch die verlustfreie und eindeutige Konvertierung zwischen den beiden Darstellungsformen einer FML-Instanz werden ein
FML-Dokument und dessen korrespondierender FML-Graph in ihrer Ausdruckskraft äquivalent.
7.1
Graphkomposition
Aufgabe der Graphkomposition ist es, das Markup eines wohlgeformten
FML-Dokumentes in die Knoten eines FML-Graphen zu verwandeln sowie Parent-Child-Beziehungen zwischen den Knoten herzustellen. MarkupKomponenten können Prolog-, Tag-, Kommentar-, Processing Instructionoder Wildcard-Komponenten sein (s. Kap. 4.1).
Prolog-, Kommentar-, Processing Instruction-, Wildcard- und leere TagKomponenten stehen atomar und autonom für sich, sind in keine komplexen
Bestandteile zerlegbar, stehen in keinerlei beziehungsreichen Abhängigkeit.
Ganz anders verhält es sich mit öffnenden, schließenden und multiplen Tags.
In einem Dokument signalisieren diese mit ihrem Auftreten zunächst ganz
allgemein einen strukturellen Umbruch. Viel mehr als die Tatsache, dass
eine strukturelle Einheit mit einem bestimmten Namen in einem Namensraum und in einer Perspektive beginnt oder aber endet, lässt sich in einem
82
Dokument vorerst nicht feststellen. Erst ein öffnendes zusammen mit einem
korrespondierenden schließenden Tag bilden ein Element. Diese zusammengehörenden Einheiten müssen identifiziert, ggf. ergänzt und reorganisiert,
sowie in polyhierarchische Relationen überführt werden: Transformationsprozesse, die für zweifelsfreie Ergebnisse in komplexen Dokumenten nur regelbasiert maschinell ausgeführt werden können.
Im Detail erfolgt die Transformation FML-Dokument → FML-Graph über
folgende geordnete Validierungen, Arbeitsschritte und Produktionsregeln:
1. Zeichenkodierung
Das Dokument muss in der Kodierung UTF-8 vorliegen bzw. in diese
konvertiert werden.
2. Demaskierung
Jedes Maskierungszeichen (Backslash ’\’) und dessen rechts folgendes
Zeichen χ werden durch die UCS-Kodierung von χ substituiert.
Beispiel: ’\<’ → ’<’
3. Scannen
Das FML-Dokument wird auf Grammatikkonsens überprüft, die lexikalische Analyse zerlegt die Zeichensequenz in eindeutig identifizierte
Tokens.
4. Parsen
Das FML-Dokument wird in einen Dokumentgraphen (Abstract Syntax
Graph [ASG]), konform Grammatik (s. Kap. 4.2)1 , überführt.
5. Filter
Perspektiven können mit dem Parameter excludeOrIncludePerspective
inkludiert oder exkludiert werden.
6. Attribut-Knoten
Alle Attribute aus Prolog- und Tag-Tokens werden extrahiert und gemäß Graphdefinition (s. Kap. 5.1.5) in Attribut- und untergeordnete
Inhaltsknoten transformiert.
7. Reservierte Bezeichner
Namen und Identifikatoren dürfen nicht mit “fml.“ beginnen:
• Perspektive (EBNF -Regel perspective)
• Namensraum (EBNF -Regel namespace)
• Tag (EBNF -Regel name)
• Attribut (EBNF -Regel attributeName)
1
Der Compiler Coco/R verwendet die LL(1)-Grammatik aus Anhang D.
83
8. Validierung der Perspektive-Namen
Die Werte der Dokument-Prolog-Attribute fml.perspective.name müssen eindeutig sein.
9. Validierung der Namensraum-Namen
Die Werte der Dokument-Prolog-Attribute fml.namespace.name müssen eindeutig sein.
10. Die optionalen Attribute
“fml.segment.id“ und “fml.segment.pos“
dürfen nur gemeinsam verwendet werden! Die verkürzte Alternativschreibweise
%{fml.segment.id}%{fml.segment.pos}
darf nur alternativ verwendet werden!
11. Segmentposition
Für eine Segment-ID dürfen keine Positionsduplikate existieren.
12. Prolog
Alle Prolog-Deklarationen sind geordnet an den Dokumentanfang zu
verschieben.
13. Identifizierung
Korrespondierende Tag-Paare sind zu bestimmen.
14. ID-Eindeutigkeit
Tag-ID’s dürfen gemäß der in Kapitel 4.1.5 beschriebenen Anforderung nur disjunkt verwendet werden.
15. Ergänzung
Fehlende öffnende oder schließende Tags werden gemäß der Anforderung Fragmentierung (s. Kap. 2.9) in multiplen Tags vorangestellt
bzw. an das Dokumentende gesetzt.
16. Tag → Element
Korrespondierende Tags werden in Elemente umgewandelt.
17. Reorganisation
Verschiedene Reorganisationsschritte sind für die Transformation in
einen konsistenten FML-Graphen konform Graphdefinition (s. Kap. 5)
anzuwenden. Diese Transformationsschritte sind diffizil, zahlreich und
Gegenstand erst folgender Forschungsarbeiten. Entscheidend ist, dass
84
alle Reorganisationsschritte für die Graphdekomposition reversibel anzuwenden sind, ohne Informationverlust verlaufen und eindeutig vollzogen werden können. Dieser Transformationsbaustein wird als weiterführendes Forschungsthema und wissenschaftliche Arbeit im Jahr
2011 an eine andere akademische Instanz delegiert.
18. Segment-Knoten
Virtuelle Segment-Knoten sind zugunsten der Anforderung Segmentierung (s. Kap. 2.8) anzuwenden und mit der Kardinalität −1 den
Perspektive-Knoten unmittelbar zu unterstellen.
19. Root-Knoten
Ein Dokument-Knoten (s. Kap. 5.1.1) mit Child-Beziehungen zu allen
verwendeten, nicht zwingend deklarierten Perspektiven ist dem FMLGraphen als Root voranzustellen.
20. Zeichensubstitution
Die Übersetzung aller UCS-Zeichen in Inhalten und Knoten-Literalen
in natives UTF-8 ist vorzunehmen.
Falls eine der Validierungsprüfungen negativ ist oder ein Transformationsschritt nicht integer realisiert werden kann, so ist das initiale FML-Dokument als nicht wohlgeformt zu bewerten.
Es wird unterstellt, nicht formal bewiesen, dass die Graphkomposition strukturell und inhaltlich verlustfrei und eindeutig realisiert werden kann.
7.2
Graphdekomposition
Die Graphdekomposition ist die Umkehrung der Graphkomposition.
Falls eine der Validierungsprüfungen negativ ist oder ein Transformationsschritt nicht integer realisiert werden kann, so ist der FML-Graph inkonsistent und kann nicht in ein wohlgeformtes FML-Dokument transformiert
werden.
Es wird unterstellt, nicht formal bewiesen, dass die Graphdekomposition
strukturell und inhaltlich verlustfrei und eindeutig realisiert werden kann.
85
Kapitel 8
XML-Repräsentation
Man kehrt immer zu seiner
ersten Liebe zurück.
Charles-Guillaume Etienne
1778 – 1845
Wie kann ein FML-Dokument verlustfrei in einem XML-Serialisierungsformat
repräsentiert werden? Und wie kann dieses wieder vollständig zurück in das
ursprüngliche FML-Dokument transformiert werden? Für diese Fragestellungen, die entscheidend sind für eine Integration von FML in bestehende
XML-Systemlandschaften (Datenbanken, Transferprotokolle, Dienste, Abfragesprachen, Applikationen etc.) und für das Akzeptanzpotential wird
eine Lösung angeboten.
8.1
XML Schema Definition
Jedes wohlgeformte FML-Dokument kann durch ein wohlgeformtes XMLDokument repräsentiert werden, das im Namensraum
http://www.freestyle-markup.org
Instanz des Schemas fml.xml.xsd (s. Anhang G) ist. Dieses Schema1 bietet ein Inhaltsmodell zur vollständigen und geordneten Serialisierung aller
FML-Komponenten an, und es ist gemäß den Gestaltungsrichtlinien aus [120]
global typisiert, erweiterbar und schwach restringierend modelliert, um flexibel gegenüber perspektivischen Änderungen der FML-Sprachspezifikation
zu sein. Alle FML-Komponenten wurden mit ihren Merkmalen berücksichtigt, und der Name des in der XSD deklarierten Elementes ist identisch
mit dem Namen der Grammatikregel einer korrespondierenden Komponente (s. Kap. 4.2).
1
Verifiziert für Apache Xerces 2.10.0 .
86
Das Schema fml.xml.xsd ist somit eine konsistente eindeutige Beschreibungsvorschrift für XML-Instanzen, die (ausschließlich) wohlgeformte FMLDokumente abbilden.
8.2
FML → XML
Da zum gegenwärtigen Zeitpunkt noch keine Transformationssprache für
FML vorliegt, kann auch die Übersetzung eines wohlgeformten FML-Dokumentes in eine XML-Instanz konform zu dem XML-Schema fml.xml.xsd
(s. Kap. 8.1) noch nicht automatisiert bzw. formal standardisiert erfolgen. Jedoch sind die Transformationsschritte einfach, deterministisch und
intuitiv:
1. Ein XML-Dokument wird dem Schema fml.xml.xsd zugewiesen und
mit dem Wurzelelement document aus dem Namensraum http://www.
freestyle-markup.org initialisiert:
01 <?xml version="1.0" encoding="UTF-8"?>
02 <fml:document xmlns:fml="http://www.freestyle-markup.org"
03
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
04
xsi:schemaLocation="fml ./fml.xml.xsd">
05
06 </fml:document>
Dokumentanreicherungen erfolgen ausschließlich in Zeile 05.
2. Das FML-Dokument wird als eine geordnete Sequenz von Komponenten vom Typ Inhalt oder Markup aufgefasst. Diese lineare Folge ist
als Eingabestrom für die XML-Transformation von links nach rechts
abzuarbeiten.
3. Für jede identifizierte FML-Komponente ist dem XML-Dokument ein
korrespondierendes Element gemäß XSD hinzuzufügen:
FML-Komponente
Inhalt
Dokument-Deklaration
Perspektive-Deklaration
Namensraum-Deklaration
Öffnendes Tag
Schließendes Tag
Leeres Tag
Multiples Tag
Kommentar
PI
Wildcard
87
XML-Element
fml:content
fml:prolog.document
fml:prolog.perspective
fml:prolog.namespace
fml:tag.start
fml:tag.end
fml:tag.empty
fml:tag.multiple
fml:comment
fml:pi
fml:wildcard
4. Alle Merkmale der FML-Komponenten werden jeweils als Children der
korrespondierenden XML-Elemente serialisiert. Beispielsweise führen
die beiden obligatorischen Merkmale target und instruction einer
Komponente vom Typ Processing Instruction zu zwei Child-Elementen
des XML-Elementes pi: pi.target und pi.instruction. Die Namen der jeweiligen FML-Grammatikregel sind identisch mit den XSDElement-Namensdeklarationen. Somit kann die Zuordnung eindeutig
erfolgen.
5. Da ausnahmslos alle FML-Komponenten-Merkmale als XML-ElementInhalte (s. EBNF -Regel 14: CharData [186]) serialisiert werden2 , bedarf die Übertragung der Zeichen ’<’ und ’&’ besonderer Aufmerksamkeit: Eine Substitution beider Zeichen durch eine dezimale oder hexadezimale Zeichenrepräsentation (s. EBNF -Regel 66: CharRef [186])
ist notwendig für die Erstellung eines wohlgeformten XML-Dokumentes.
Folgendes Beispiel veranschaulicht das Abbildungsprinzip über alle FMLKomponententypen:
FML-Dokument
01
02
03
04
05
06
07
08
09
10
11
12
< @fml.name="fml document"
fml.uri="http://www.freestyle-markup.org/xml/document.fml"
fml.description="fml example document">
<?palindrome start>
able was i
<!Bonaparte! >
e
<>
re i saw
<island latin="ilva">
elba
</island>
XML-Dokument
02 <fml:document xmlns:fml="http://www.freestyle-markup.org"
03
04
xsi:schemaLocation="fml ./fml.xml.xsd">
05
<fml:prolog.document>
06
<fml:name>fml document</fml:name>
07
<fml:uri>http://www.freestyle-markup.org/xml/document.fml</fml:uri>
08
<fml:description>fml example document</fml:description>
09
</fml:prolog.document>
10
<fml:pi>
11
<fml:pi.target>palindrome</fml:pi.target>
12
<fml:pi.instruction>start</fml:pi.instruction>
13
</fml:pi>
14
<fml:content>able was i</fml:content>
15
<fml:comment>Bonaparte</fml:comment>
2
Durch dieses Vorgehen beschränkt sich der Maskierungsaufwand auf ein Minimum.
88
16
<fml:content> e</fml:content>
17
<fml:wildcard/>
18
<fml:content>re i saw </fml:content>
19
<fml:tag.start>
20
<fml:tag.name>island</fml:tag.name>
21
<fml:attribute>
22
<fml:attribute.name>latin</fml:attribute.name>
23
<fml:attribute.value>ilva</fml:attribute.value>
24
</fml:attribute>
25
</fml:tag.start>
26
<fml:content>elba</fml:content>
27
<fml:tag.end>
28
<fml:tag.name>island</fml:tag.name>
29
</fml:tag.end>
30 </fml:document>
Zuordnung3
Dokument-Deklaration
PI
Inhalt
Kommentar
Inhalt
Wildcard
Inhalt
Öffnendes Tag
Inhalt
Schließendes Tag
8.3
FML-Dokument
01 – 03
04
05
06
07
08
09
10
11
12
XML-Dokument
05 – 09
10 – 13
14
15
16
17
18
19 – 25
26
27 – 29
XML → FML
Der De-facto-Standard für die Transformation von XML-Dokumenten in beliebige Zieldokumente ist die Sprache XSLT . Mittels dem XSLT -Dokument
xml2fml.xslt4 (s. Anhang H) kann eine XML-Repräsentation5 eines FMLDokumentes verlustfrei und eindeutig zurück in das ursprüngliche FML-Dokument transformiert werden.
Die Substitution von bestehenden, durch dezimale oder hexadezimale Referenzen maskierten Zeichen in native UTF-8 -Zeichen wird automatisch vorgenommen.
3
Zeilennummern im jeweiligen Dokument
Verifiziert für Saxon 9.2 .
5
Valide gegenüber dem Schema fml.xml.xsd (s. Kap. 8.1).
4
89
Kapitel 9
Implementierung
Auch aus Steinen, die einem in
den Weg gelegt werden, kann
man Schönes bauen.
Johann Wolfgang von Goethe
1749 – 1832
Die Schnittstellenbeschreibung einer Referenzimplementierung wird in der
plattformunabhängigen Programmiersprache Java 1 präsentiert. Die vollständige Programmierschnittstelle (API ) dient der sicheren Anbindung einer Implementierung an FML verwendende Applikationen. Komponentenmodell, Transformationsverarbeitung und Ausnahmebehandlung werden berücksichtigt.
9.1
Deserialisierung
Der Prozess der Deserialisierung, der je nach Anwendungskontext auch als
Scannen, Parsen, Lesen, Analysieren oder Compilieren bezeichnet werden
kann und umfassend in [109] als computerlinguistische Analyse einer sprachlichen Äußerung gemäß einer gegebenen Grammatik beschrieben wird, umfasst für die strukturelle Transformation eines FML-Dokumentes in einen
FML-Graphen zwei Arbeitsschritte:
1. Lexikalische Analyse (Scannen/Parsen)
FML-Dokument → Dokument-Graph
2. Dokumenttransformation
Dokument-Graph → FML-Graph
Ein FML-Dokument ist zu Beginn der Deserialisierung zunächst einmal
nichts anderes als eine einfache Zeichenfolge. Für diesen Text muss mittels
1
Java™ Platform, Standard Edition 6 (JSE6)
90
der gegebenen FML-Grammatik durch Ermittlung des Ableitungsbaumes
die syntaktische Struktur analysiert werden. Für das lexikalische Scannen
wird ein LL-Parser [91] verwendet, der wiederum mit dem Parser-Generator
Coco/R [106] erzeugt worden ist. Die Verarbeitungsrichtung des Scanners
ist von links nach rechts, die Analyserichtung von unten nach oben. Das
Ergebnis des ersten Deserialisierungsschrittes ist eine Graphrepräsentation
des Dokument-Textes. Dieser Zwischengraph modelliert – basierend auf der
FML-Grammatik – die diese Sprachinstanz erzeugenden Ableitungen und
bereitet den zweiten Arbeitsschritt vor. Nach dem in Kapitel 7.1 skizzierten
Regelwerk wird der FML-Graph als Dokumentinterpretation erzeugt. Die
Frage, ob ein gegebenes Dokument Teil der Sprache FML – also wohlgeformt
– ist, wird mit dem Arbeitsschritt der Dokumenttransformation abschließend
beantwortet.
Die Implementierung der Spezifikation (s. Anhang C) und aller erarbeiteten Konzepte (s. Kap. 6) bedürfen einer gut dokumentierten objektorientierten Programmierschnittstelle (API ), die eine sichere und transparente
rechentechnische Anwendung aller Programmbibliotheken der Sprache FML
ermöglicht. Folgende Methoden der Schnittstelle IController ermöglichen
die Deserialisierung eines FML-Dokumentes:
package fml;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.URI;
import org.w3c.dom.Document;
import fml.exception.IOException;
import fml.exception.InvalidXMLException;
import fml.exception.WellformednessException;
import fml.model.IDocument;
import fml.model.IPerspective;
public interface IController {
public void init(InputStream inputStream) throws IOException;
public void init(URI file) throws IOException;
public void init(String document);
public IDocument parse() throws WellformednessException;
public IDocument parse(boolean excludeOrIncludePerspective,
IPerspective... perspective)
throws WellformednessException;
public String serialize() throws IOException;
public IDocument getDocument();
public IDocument setDocument(IDocument document);
public boolean isWellformed() throws WellformednessException;
}
91
9.2
Serialisierung
Der Prozess der Serialisierung transformiert einen FML-Graphen in ein FMLDokument und ist die Umkehrung der Deserialisierung (s. Kap. 9.1).
Die überladene Methode serialize realisiert in der Schnittstelle IController
die Serialisierung eines FML-Graphen:
public void serialize(OutputStream outputStream) throws
WellformednessException, IOException;
public void serialize(URI file) throws
WellformednessException, IOException;
public String serialize() throws IOException;
9.3
XML-Transformation
9.3.1
FML → XML
Die Transformation eines FML-Dokumentes in ein XML-Repräsentationsformat (s. Kap. 8.2) wird durch die Methode transformToXML realisiert:
public Document transformToXML() throws
WellformednessException;
9.3.2
XML → FML
Die Retransformation einer XML-Repräsentation eines FML-Dokumentes
(s. Kap. 8.3) wird durch die Methode transformFromXML realisiert:
public IDocument transformFromXML(Document document) throws
InvalidXMLException, WellformednessException;
92
9.4
Datenmodell
Das Datenmodell repräsentiert das interpretierte FML-Dokument, den FMLGraphen, und erlaubt uneingeschränkte Navigation, Selektion und Manipulation.
Knoten eines FML-Graphen:
package fml.model;
import java.util.List;
public interface INode {
public List<INode> getChildren();
public INode getChild(int index);
public void setChildren(List<INode> child);
public void setChild(INode child, int index);
public List<INode> getParents();
public INode getParent(int index);
public void setParents(List<INode> parents);
public void setParent(INode parent, int index);
}
FML-Dokument:
package fml.model;
import java.util.List;
public interface IDocument extends INode {
public String getName();
public void setName(String name);
public URI getURI();
public void setURI(URI uri);
public String getDescription();
public void setDescription(String description);
public float getVersion();
public void setVersion(float version);
public String getFragment();
public void setFragment(String fragment);
public URI getSchema();
public void setSchema(URI schema);
public boolean getTrim();
public void setTrim(boolean trim);
public enum WritingDirection {
lr, rl
}
public WritingDirection getWritingDirection();
93
}
public void setWritingDirection(WritingDirection writingDirection);
public List<IPerspective> getPerspectives();
public void setPerspectives(List<IPerspective> perspectives);
public List<INamespace> getNamespaces();
public void setNamespaces(List<INamespace> namespaces);
Perspektive:
package fml.model;
public interface IPerspective extends INode {
public URI getSchema();
public void setSchema(URI schema);
}
Namensraum:
package fml.model;
public interface INamespace {
}
Inhalt:
package fml.model;
public interface IContent extends INode {
public String getContent();
public void setContent(String content);
}
94
Element:
package fml.model;
public interface IElement extends INode {
public IPerspective getPerspective();
public void setPerspective(IPerspective perspective);
public INamespace getNamespace();
public void setNamespace(INamespace namespace);
public String getId();
public void setId(String id);
public enum Autocompleted { StartTag, EndTag }
public Autocompleted getAutocompleted();
public void setAutocompleted(Autocompleted autocompleted);
public boolean getTrim();
public void setTrim(boolean trim);
}
Attribut:
package fml.model;
public interface IAttribute extends INode {
}
Kommentar:
package fml.model;
public interface IComment extends INode {
public String getContent();
public void setContent(String content);
}
Processing Instruction:
package fml.model;
public interface IPi extends INode {
public String getTarget();
public void setTarget(String target);
public String getInstruction();
public void setInstruction(String instruction);
}
95
Wildcard:
package fml.model;
public interface IWildcard extends INode {
}
9.5
Ausnahmebehandlung
Alle möglichen Ausnahmen lassen sich drei Fehlerklassen zuordnen:
1. IOException extends java.io.IOException
Diese Fehlerklasse fängt alle physikalischen und sicherheitstechnischen
Ein- und Ausgabekonflikte eines Ressourcenzugriffs ab.
2. InvalidXMLException extends Throwable
Syntaktische, strukturelle und logische Verarbeitungs- und Validierungsfehler werden von dieser Klasse behandelt. Beim Parsen, Serialisieren oder Transformieren eines nicht wohlgeformten Dokumentes
wird definitiv diese Exception ausgelöst.
3. WellformednessException extends Throwable
Wenn die XML-Repräsentationsform eines FML-Dokumentes nicht valide gegenüber dem Schema fml.xml.xsd (s. Anhang G) ist, dann
erfüllt die WellformednessException ihre Zuständigkeit.
96
Kapitel 10
Integrität
Die Grenzen meiner Sprache
bedeuten die Grenzen meiner
Welt.
Ludwig Wittgenstein
1889 – 1951
Die Eigenschaften der Sprache FML werden durch Prüfung der Einhaltung
der verschiedenen korrespondierenden Sprachanforderungen untersucht. Diese
Evaluierung und Leistungsbewertung unterstreicht die Fehlerfreiheit und
Korrektheit der Sprachspezifikation hinsichtlich aller geforderten Aspekte
und validiert somit die Integrität der Sprache.
10.1
Grammatik
Im Vergleich zur Sprache XML, die exklusive aller Konstrukte der integralen
DTD-Schemasprache ca. 50 [186] Produktionsregeln verwendet, erscheint
FML in seiner Sprachdefinition übersichtlicher und wird der Aussage von [22]
gerecht:
By relieving the brain of all unnecessary work, a good notation
sets it free to concentrate on more advanced problems, and in
effect increases the mental power of the race.
Die FML-Grammatik enthält nur 13 zentrale EBNF -Produktionsregeln. Weitere 27 Regeln dienen ausschließlich der Zeichen- und Zeichensequenzdefinition.
Zugunsten der Aspekte Entropie (s. Kap. 10.15), Ergonomie (s. Kap. 10.16)
und nur eingeschränkt notwendiger XML-Kompatibilität (s. Kap. 10.2) konnten viele obsolete SGML-Konstrukte, Redundanzen und praktisch irrelevante Relikte ausgesondert werden. Die Sprache FML konzentriert sich auf
97
das Wesentliche, das polyhierarchische Auszeichnen von Texten und Daten.
Auch im Kontext der anderen Sprachanforderungen ist eine Grammatik (s.
Kap. 4.2) als formales Fundament der Sprache ausgearbeitet worden.
Die Chomsky-Typ-2-Grammatik – dargestellt durch die EBNF – ist charakterisiert durch Produktionsregeln P der Form
P ⊂ { ϕ −→ ψ | ϕ ∈ VN , ψ ∈ (VN ∪ VT )∗ }
Auf der rechten Seite einer Regel steht eine beliebige Folge von Symbolen
(ψ) aus der Menge der terminalen (VT ) und nicht-terminalen (VN ) Symbole,
auf der linken Seite steht genau ein nicht-terminales Symbol (ϕ). Durch
wiederholte Ableitung (Anwendung einer Grammatikregel) lassen sich FMLDokumente konstruieren.
FML kann als Typ-2-Sprache durch eine kontextfreie Grammatik erzeugt
und durch einen nichtdeterministischen Kellerautomaten erkannt werden.
Wortproblem und Wortanalyse [134] sind lösbar.
Die Tests der in Anhang D aufgestellten implementierungsnahen Grammatik
durch den Parser-Generator Coco/R verifizieren gemäß [106] zusätzliche
Eigenschaften der Grammatik:
• Vollständigkeit: Es existiert eine Produktionsregel für jedes nichtterminale Symbol.
• Redundanzfreiheit: Es existieren keine Produktionsregeln für vom StartSymbol ausgehende, durch Ableitung nicht erreichbare nicht-terminale
Symbole.
• Ableitbarkeit: Es existieren keine nicht-terminalen Symbole die sich
nicht in eine Sequenz von terminalen Symbolen ableiten lassen.
• Zirkularitätsfreiheit: Es existieren keine zirkulären Produktionsfolgen. Nicht-terminale Symbole sind weder in einem noch über mehrere
Schritte zu sich selbst ableitbar.
• Eindeutigkeit: Alle Token sind eindeutig und unterscheidbar. Ableitungsalternativen sind stets eindeutig entscheidbar.
• Inhalt: Außer dem Startsymbol, das in einem Schritt in ein leeres
Dokument abgeleitet werden kann, existieren keine anderen nichtterminalen Symbole, die nicht zu einer nicht-leeren Sequenz von terminalen Symbolen führen.
98
10.2
Kompatibilität
FML berücksichtigt einerseits die hohe Akzeptanz von XML, andererseits
gänzlich neue Anforderungen. Bzgl. der Kompatibilität zu XML ist somit
ein Kompromiss entstanden: Größtmögliche, aber nicht vollständige Kompatibilität wird gewährleistet.
Die Terminologien, die Spachsyntax, die Interaktion der verschieden Komponenten und deren Interpretation sind sehr ähnlich, der Einarbeitungsaufwand von XML nach FML ist entsprechend gering.
Das namespace-Konzept bleibt grundsätzlich erhalten, jedoch wird zugunsten ergonomischer Anforderungen (s. Kap. 2.16) das komplexe und sowohl von Autoren als auch von Implementierungen ambivalent interpretierte
XML-Verfahren der Namensraum-Definition und -Zuordnung demontiert.
Hier entsteht eine deutliche Kompatibilitätseinschränkung.
Die für die DTD-Einbettung und heute vor allem für RSS verwendeten
CDATA-Sections werden ersatzlos eliminiert. Es gibt zu viele berechtigte
Gründe dieses obsolete und vor allem kritische Konstrukt [188] in einer neuen
Auszeichnungssprache nicht weiter zu unterstützen:
The idea of escaping markup goes against the fundamental grain
of XML. If this hack spreads to other vocabularies, we’ll very
quickly find ourselves mired in the same bugward-compatible
tag soup from which we have struggled so hard to escape.
Ein detailierter Migrationsleitfaden (s. Anhang E) gewährleistet Handlungskompetenz gegenüber notwendigen und empfohlenen Konvertierungsmaßnahmen.
Eine vorgestellte XML-Repräsentation für FML-Dokumente mitsamt bidirektionalem Transformationsleitfaden (s. Kap. 8) erleichtert die Interoperabilität zwischen den beiden ähnlichen Sprachen.
Der Anspruch auf Kompatibilität zwischen dieser und etwaigen folgenden
Versionen der Sprache FML wird durch eine einfache Regel gelöst: Syntax
und Interpretaion bleiben unveränderlich. Lediglich die reservierten Element- und Attribut-Bezeichner, beginnend mit fml., können einer sprachinhärenten Semantik zugeordnet werden. Eine einmal erfolgte semantische
Belegung eines reservierten Bezeichners darf in Folgeversionen weder entfernt noch verändert werden.
10.3
Monohierarchie
Ein XML-Dokument ist streng hierarchisch aufgebaut (Wohlgeformtheitskriterium in [186]: “[. . . ]for each non-root element C in the document, there
99
is one other element P in the document such that C is in the content of P,
but is not in the content of any other element that is in the content of P. P
is referred to as the parent of C, and C as a child of P“1 ). Diese Eigenschaft
wird von der Sprache FML bewusst zugunsten Interferenz (s. Kap. 10.4),
Kongruenz (s. Kap. 10.6), Independenz (s. Kap. 10.7), Segmentierung
(s. Kap. 10.8) und Fragmentierung (s. Kap. 10.9) nicht aufrechterhalten.
Jedoch existiert ein Gültigkeitszustand für FML-Dokumente (s. Kap. 4.3),
der die etwaige strukturelle Kompatibilität einer FML-Sprachinstanz bzgl.
dieses restriktiven XML-Kriteriums bewertet.
Auf der Suche nach korrespondierenden Tags wird ein Dokument von außen
nach innen (Matrjoschka-Prinzip) ausgewertet. Dieses Vorgehen der Element-Konstruktion wird der hierarchischen XML-Element-Verschachtelung
gemäß dem ’properly nested’-Kriterium gerecht. Die Element-Hierarchie
eines XML-Dokumentes wird somit stets gleichermaßen in den ElementParent-Child-Beziehungen eines FML-Graphen abgebildet.
Gemäß der Typologie von [38] sind folgende zwei Interaktionsszenarien für
monohierarchisches Markup relevant:
1. “No overlap“: <a>...</a>...
2. “One element contained within the other“: <a>.........</a>
Beide Varianten werden von FML und XML gleichwertig kodiert und interpretiert.
10.4
Interferenz
So wie sich das World Wide Web zu einem Medium zur Veröffentlichung von
strukturierten Daten wandelt und so wie die semistrukturierte Topologie des
Linked Data Web stetig komplexer wird [15], so sollte auch die Struktur der
allem als Basistechnologie zugrunde liegenden Markup-Sprachen nicht stagnieren. Vor allem die Interferenzanforderung führt zu einer fundamentalen
strukturellen Weiterentwicklung: Polyhierarchie statt Monohierarchie.
Komponenten dürfen in einem FML-Dokument nahezu beliebig angeordnet
werden, es gibt keine ’properly nested’-Restriktionen. Überlagernde Elemente, jeweils gebildet aus korrespondierenden Tag-Paaren, sind uneingeschränkt zulässig. Das Interferenzproblem wurde durch eingebetteten Code
sprachinhärent gelöst. Die Positionen der Tags wandern beim Editieren mit
dem schrumpfenden oder sich ausdehnenden Inhalt mit.
1
Das W3C meidet die angebrachten graphentheoretischen Begriffe Baum und Hierarchie. Erstaunlicherweise nur in dieser Spezifikation.
100
Gemäß der Typologie von [38] ist folgendes Interaktionsszenario für interferentes Markup relevant
“Classic overlap“: <a>......</a>...
und wird von FML in derselben Form kodiert und interpretiert.
10.5
Identifizierung
In der Anforderungsbeschreibung (s. Kap. 2.5) wurde die Notwendigkeit
eines ID-Zuweisungsmechanismus begründet:
TS/E [pi ] [nsj ] [tnk ] [IDl ] = 1, |ijkl | = 1
Die Umsetzung erfolgt in FML mittel des optionalen Tag-Namenspräfix
’∼’ tagId
Öffnende Tags (Start-Tags TS ) und schließende Tags (End-Tags TE ) korrespondieren () genau dann in einem FML-Dokument, wenn sie in derselben
Perspektive pi und in demselben Namensraum nsj denselben Tag-Namen
tnk besitzen und dieselbe IDl :
TS [pi ] [nsj ] [tnk ] [IDl ] TE [pi ] [nsj ] [tnk ] [IDl ]
Ist pi nicht explizit angegeben, so befindet sich das Tag in der DefaultPerspektive. Ist nsj nicht deklariert, so ist das Tag dem Default-Namensraum unterstellt.
Falls IDl nicht verfügbar ist, findet das Identifizierungskonzept (s. Kap. 6.6)
keine Anwendung und die Identifizierung korrespondierender Tags erfolgt
nach dem Matrjoschka-Prinzip von außen nach innen.
Die Anforderungsumsetzung ist dem “co-indexing scheme“ aus [72] sehr ähnlich.
10.6
Kongruenz
Gemäß der Typologie von [38] sind folgende vier Interaktionsszenarien für
kongruentes Markup relevant:
1. “Elements share one end/start point“: <a>...</a b>...
2. “Elements share start point“: <a b>...</a>...
3. “Elements share end point“: <a>......</a /b>
4. “Elements share both start and end points“: <a b>...</a /b>
101
Alle vier Szenarien werden vom Kongruenzkonzept (s. Kap. 6.7) unterstützt. Die Kodierung in FML ist augenscheinlich ähnlich, die Interpretation die erwartete.
Das multiple Tag kapselt mindestens zwei Tags vom Typ Start, Ende oder
leer und erlaubt keinerlei Inhalt dazwischen. Die Reihenfolge der gekapselten Tags ist für die Kodierung im Dokument grundsätzlich irrelevant, für
die Konstruktion eines Graphen, für die Dokumentinterpretation jedoch gilt:
Schließende Tags werden vor öffnenden Tags ausgewertet.
Obige Szenarien werden in FML wie folgt kodiert:
1. <a>...<</a>>...
2. <<a>>...</a>...
3. <a>......<</a>>
4. <<a>>...<</a>>
Die syntaktische Abweichung gegenüber den Skizzen aus [38] ist erforderlich,
da nur so die FML-Grammatik von einem performant arbeitenden und leicht
zu implementierenden LL(1)-Parser angewendet werden kann. Andernfalls
bedürfte es eines größeren Lookaheads oder umfangreicher grammatikalischer Restriktionen.
10.7
Independenz
Unbestritten ist, dass sich Texte und Daten aus verschiedenen independenten Perspektiven interpretieren lassen. Diese über viele Diskussionen anerkannte Tatsache wird treffend von [201] resümiert:
It is obvious that there is, at least potentially, more than one
view for a given text. [. . . ] more markup implies that it becomes
more likely to encounter multiple hierarchies.
Bislang erarbeitete Lösungskonzepte (s. Kap. 12) für eine Umsetzung der
Independenz-Anforderung beurteilt [201]
[. . . ] all of these techniques are workarounds
und schließt berechtigt den CONCUR/XCONCUR-Ansatz von dieser pauschalen Bewertung aus. Gleichsam kann auch das präsentierte FML-Lösungskonzept (s. Kap. 6.8) für die Auszeichnung independenter Strukturen
nicht als Workaround bezeichnet werden. Die Kodierung von Perspektiven im Markup ist bis auf eine sparsamere Syntax zugunsten der EntropieAnforderung (s. Kap. 2.15) dem SGML-CONCUR-Konzept sehr ähnlich
und erlaubt eine intuitive, transparente und vor allem inhärente Zuordnung
102
von Markup zu einer gewünschten Annotationsebene.
Alle Markup-Komponenten außer Prolog und Kommentar unterstehen entweder der Default-Perspektive oder werden explizit einer Perspektive zugeordnet:
'<' perspective '|' ...
10.8
Segmentierung
Beliebige Inhaltskompositionen können in FML in virtuellen Elementen gekapselt werden. Partizipierende Start-Tags oder leere Tags müssen hierfür
jeweils zwei Informationen bereitstellen, entweder mit den reservierten Attributen
fml.segment.id und fml.segment.pos
oder aber alternativ unter Anwendung der Kurznotation
'%' segmentId '%' segmentPos
Das Konzept der Segmentierung (s. Kap. 6.9) stellt ein äußerst mächtiges gestalterisches Instrument dar, das die gegebene Ordnung der Inhaltssequenz aufhebt und Wiederverwendbarkeit ermöglicht. Die Anforderung (s. Kap. 2.8) ist gelöst.
10.9
Fragmentierung
FML-Dokumente können auch Fragmente von FML-Dokumenten sein. Als
Implikation können Tags isoliert im Dokumentextrakt stehen und werden
für die Elementinterpretation in einem FML-Graphen ergänzt:
fml.element.autocompleted = ’start-tag’ | ’end-tag’
Das Konzept der Fragmentierung (s. Kap. 6.10) löst die Anforderung
(s. Kap. 2.9) und ermöglicht die verteilte Distribution von Dokumenten und
unterstützt ein sparsame Kodierung, da auf Tags zum Dokumentanfang oder
-ende vollkommen verzichtet werden kann.
10.10
Wildcard
Ein Platzhalter ist als eine eigenständige FML-Komponente (s. Kap. 4.1.8)
definiert und darf an jeder Position der Inhaltssequenz außerhalb von Markup in ein FML-Dokument eingebettet werden und optional einer Perspektive zugeordnet sein:
'<' [ perspective '|' ] '>'
103
Eine Wildcard kann bei der Transformation des Dokumentes in einen FMLGraphen nicht ignoriert werden, da andernfalls die Transformation verlustbehaftet wäre und das ursprüngliche FML-Dokument nicht rekonstruiert
werden könnte. Da jede Interpretation über eine spätere Verwendung nur
spekulativ wäre, wird eine Wildcard behandelt wie ein Kommentar und steht
somit autark im Dokument. Die bestehende Dokumentstruktur wird nicht
korrumpiert, eine Wildcard korrespondiert mit keiner anderen (wie es bei
Tags möglich ist). Folglich wird auch der Gültigkeitszustand (s. Kap. 4.3)
des Dokumentes nicht beeinflusst, genauso wie ein Kommentar für die Feststellung der Korrektheit, Wohlgeformtheit und Validität eines Dokumentes
irrelevant ist.
Substituiert werden darf eine Wildcard zu gegebenem Zeitpunkt durch folgende FML-Markup-Komponenten:
• Tag (s. Kap. 4.1.5)
Öffnendes, schließendes, leeres und multiples Tag.
• Kommentar (s. Kap. 4.1.6)
• Processing Instruction (s. Kap. 4.1.7)
• Wildcard (s. Kap. 4.1.8)
Eine Wildcard einer anderen Perspektive.
Nach einer Substitution in die Komponenten öffnendes, schließendes oder
multiples Tag werden die Blätter eines FML-Graphen – die eigentlichen Inhalte – bzgl. ihrer Parent-Element-Zuordnung neu strukturiert. Wildcards
stehen also neutral im Dokument, können allerdings nach Konkretisierung
massive Änderungen der Dokumentstruktur bewirken.
10.11
Vererbung
Das Konzept der Vererbung (s. Kap. 6.4) erlaubt einen lesenden Zugriff auf
die Eigenschaften von Elementen und die Eigenschaften der direkten und
indirekten Parent-Elemente. Elementeigenschaften werden durch die Wertbelegung einer geordneten Attributliste definiert. Vererbung konsolidiert
diese Eigenschaften mit allen Parent-Attributen. Das Konsolidierungsprodukt wird erzeugt durch Ergänzung und Anreicherung, nicht aber durch
Überschreibung. Informationsverlust ist unzulässig. Hieraus und durch andere Motive leitet sich auch die neue Datenstruktur von Attributwerten ab:
eine ebenfalls geordnete Liste von Inhalten, separiert durch Kommata.
Der Zugriff auf die über Element-Vererbungshierarchien konsolidierten Attribute erfolgt ausschließlich auf Implementierungsebene (s. Kap. 9):
Attribut[] Element.getAttributes(true)
104
10.12
Der FML-Graph (s. Kap. 5) ist eine Repräsentationsform einer FMLInstanz und bildet ein FML-Dokument eindeutig (s. Kap. 10.14) und vollständig ab.
Neben Struktur und Semantik des Graphen sind auch graphische Notationsdetails (s. Kap. 10.16) fixiert.
Ein Transferformat und Informationsmodell, das deutlich über einen Monographen hinausgeht, wird unter anderem auch von [123] gefordert:
Unfortunately there is a large gap between the XML tree model
and the models traditionally used in software engineering[. . . ]
Markup-based models revolve around order and hierarchy whereas the more popular graph-based data models revolve around
linking relationships and roles. A linked data structure (directed
graph) can more directly express sophisticated information than
can a simple tree.
Diesen berechtigten Anspruch berücksichtigt FML: Eine polyhierarchische
Datenstruktur ist mächtiger als eine monohierarchische. Für viele Anwendungsszenarien ist diese Struktur ausreichend. Multiple Inhaltszuordnung,
Überlagerung, verschiedene Dokumentperspektiven lassen sich sprachinhärent repräsentieren. Ein geforderter und weiterführender Evolutionsschritt
ist somit gelungen.
Vermutlich lassen sich noch breitere Datenstrukturen sprachinhärent durch
eingebettetes Markup nicht direkt umsetzen, sondern verlangen nach progressiven Konzepten basierend auf virtueller Referenzierung wie zum Beispiel realisiert mit der Sekundärstrukturierung von XStandoff (s. Kap. 12.7).
105
10.13
Transformation
Die Sprache FML wurde durch eine kontextfreie Grammatik beschrieben
(s. Kap. 4.2). Jede Ableitungsfolge führt demnach zu einer Monohierarchie. Der FML-Graph jedoch ist eine Polyhierarchie. Die verlustfreie
und eindeutige Transformation zwischen beiden Repräsentationsformen einer FML-Instanz wurde erarbeitet (s. Kap. 7).
Alle notwendigen Transformationsschritte wurden skizziert, jedoch nicht
durch Instruktionen ein vollständiges Graphtransformations-Regelwerk formal definiert. Diese umfangreiche und komplexe Entwicklungsaufgabe, die
eine Vorbedingung für jede pragmatische Implementierung sein sollte, wird
in dieser Arbeit nicht erbracht, ist aber als Forschungsprojekt bereits an
andere Instanzen delegiert worden.
10.14
Eindeutigkeit
Eine FML-Instanz wird gleichermaßen durch FML-Dokument und FMLGraph repräsentiert. Entscheidend ist, dass beide Repräsentationsformen
bzgl. ihres strukturellen und inhaltlichen Informationsgehaltes äquivalent
sind.
Folgende Übersicht enthält alle Komponenten und alle Produktionsregeln
des FML-Dokumentes (s. Kap. 4) sowie alle Knoten des FML-Graphen und
alle von Knoten gekapselten Informationen (s. Kap. 5). Die tabellarische
Gegenüberstellung drückt Zugehörigkeit und Korrespondenz aus.
FML-Dokument
FML-Graph
Komponente
Grammatik
Knoten
Information
Dokument
FML
Dokument
fml.node-type=fml.node.document
Prolog
prologDocument
fml.name
Dokument
fml.name
Prolog
prologDocument
fml.uri
Dokument
fml.uri
106
Prolog
prologDocument
fml.description
Dokument
fml.description
Prolog
prologDocument
fml.version
Dokument
fml.version
Prolog
prologDocument
fml.fragment
Dokument
fml.fragment
Prolog
prologDocument
fml.schema
Dokument
fml.schema
Prolog
prologDocument
fml.trim
Dokument
fml.trim
Prolog
prologDocument
fml.writing-direction
Dokument
fml.writing-direction
Prolog
prologPerspective
fml.perspective.name
Dokument
Prolog
prologPerspective
fml.perspective.uri
Dokument
fml.perspective.uri
Prolog
prologPerspective
fml.perspective.description
Dokument
fml.perspective.desciption
Prolog
prologPerspective
fml.perspective.schema
Dokument
fml.perspective.schema
107
Prolog
prologNamespace
fml.namespace.name
Dokument
fml.namespace.name
Prolog
prologNamespace
fml.namespace.uri
Dokument
fml.namespace.uri
Prolog
prologNamespace
fml.namespace.desription
Dokument
fml.namespace.desciption
*
distinct(*.perspective)
Perspektive
fml.node-type=fml.node.perspective
*
*.perspective
Perspektive
Inhalt
content, *Tag.attributeValue
Inhalt
fml.node-type=fml.node.content
Inhalt
content
Inhalt (Parent: Element oder Perspektive)
fml.content
Tag
*Tag.attributeValue
Inhalt (Parent: Attribut)
fml.content
Tag
emptyTag
Element (ohne Children)
fml.node-type=fml.node.element
Tag
startTag + endTag
Element (mit Children)
fml.node-type=fml.node.element
Tag
*Tag.namespace
Element
fml.element.namespace.name
Tag
*Tag.name
Element
fml.element.name
108
Tag
*Tag.tagId
fml.element.id
Tag (isoliert)
fml.element.autocompleted
Tag
*Tag.attributeName
fml.element.trim
Element
fml.element.trim
Tag
*Tag.attributeName
Attribut
fml.node-type=fml.node.attribute
Tag
*Tag.attributeName
Attribut
fml.attribute.name
Kommentar
comment
Kommentar
fml.node-type=fml.node.comment
Kommentar
comment
Kommentar
fml.comment.content
pi
fml.node-type=fml.node.pi
piTarget
fml.pi.target
piInstruction
fml.pi.instruction
Wildcard
wildcard
Wildcard
fml.node-type=fml.node.wildcard
109
Aus der Gegenüberstellung leiten sich folgende Aussagen ab:
1. Jede Komponente ist eindeutig einem korrespondierenden Knoten in
einem FML-Graphen zugeordnet.
2. Jeder Knoten in einem FML-Graphen ist eindeutig einer korrespondierenden Komponente zugeordnet.
3. Alle von Knoten des FML-Graphen gekapselten Informationen lassen
sich Produktionsregel-Tokens des FML-Dokumentes eindeutig zuordnen.
Darüber hinaus wurde in Kapitel 7 unterstellt, dass
1. die bidirektionale Transformation zwischen FML-Dokument und FMLGraph eindeutig ist und
2. die Transformation zwischen FML-Dokument und FML-Graph ohne
Informationverlust vollzogen wird.
Die Eindeutigkeitsforderung (s. Kap. 2.14) ist somit erfüllt.
10.15
Entropie
Die Sprache FML gibt den Rahmen für Informationsauszeichnung vor. Keinen Einfluss hat sie jedoch auf die auszuzeichnenden Inhalte. Diese können
bei Texten beliebig mit Tautologien, Pleonasmen, Epimonen oder sonstigen
Stil- oder Rhetorikmitteln mit semantischer oder syntaktischer Redundanz
durchsetzt sein. Für Inhaltsdaten im Allgemeinen kann eine generalisierende
Auszeichnungssprache keine Vorschriften aufstellen, Dokumententropie und
Redundanzfreiheit entziehen sich für Inhalte jeder Kontrolle.
Folgende Dokumentbestandteile sind frei wählbar:
• Inhalte
1. Inhalt außerhalb von Markup
EBNF -Regel: content
2. Attribut-Inhalt
EBNF -Regel: attributeValue
3. Processing Instruction - Instruktion
EBNF -Regel: piInstruction
4. Kommentar
EBNF -Regel: comment
110
5. Prolog-Beschreibung
EBNF -Regel: fml.description,
fml.perspective.description,
fml.namespace.description
• Bezeichner, Namen, Identifikatoren, URI s, Schema-URI s, Versionsnummern, Fragmentkennungen, Positionsangaben
1. Dokument - Name
EBNF -Regel: fml.name
2. Dokument - URI
EBNF -Regel: fml.uri
3. Dokument - Version
EBNF -Regel: fml.version
4. Dokument - Fragment
EBNF -Regel: fml.fragment
5. Dokument - Schema
EBNF -Regel: fml.schema
6. Perspektive - Name
EBNF -Regel: fml.perspective.name
7. Perspektive - Präfix
EBNF -Regel: perspective
8. Perspektive - URI
EBNF -Regel: fml.perspective.uri
9. Perspektive - Schema
EBNF -Regel: fml.perspective.schema
10. Namensraum - Name
EBNF -Regel: fml.namespace.name
11. Namensraum - Präfix
EBNF -Regel: namespace
12. Namensraum - URI
EBNF -Regel: fml.namespace.uri
13. Tag - Name
EBNF -Regel: fml.tag-name
14. Tag - ID
EBNF -Regel: tagId
15. Tag - Segment-ID
EBNF -Regel: segmentId
16. Tag - Segment-Position
EBNF -Regel: segmentPos
111
17. Attribut - Name
EBNF -Regel: attributeName
18. Processing Instruction - Ziel
EBNF -Regel: piTarget
Entropiekodierung mit variabler Codelänge auf Bit-Ebene wie die HuffmannKodierung [69] oder das Prinzip des Morsealphabetes kann nicht angewendet
werden, da eine statische UTF-8 -Kodierung für jedes FML-Dokument festgesetzt ist (s. Kap. 10.17). Entropiekodierung auf Wortebene ist ebenso
indiskutabel, da ein UTF-8 -Zeichen weitaus mehr Zustände erlaubt als benötigt werden.
Unangetastet bleibt aus Gründen der Kompatibilität (s. Kap. 10.2) und
Ergonomie (s. Kap. 10.16) auch das bewährte Prinzip der Kennzeichnung
eingebetteter Markup-Codes: Beginn und Ende einer Auszeichnung markieren in der Inhaltssequenz die Symbole < und >.
Somit stehen nur wenige Steuerungssymbole, die für typische Dokumente
einen Bruchteil des Gesamtvolumens ausmachen, zur Disposition. Diese
aber sind mit dem Ziel redundanzminimierender Sprachgestaltung und unter Berücksichtigung der Aspekte Lesbarkeit und Kompatibilität definiert.
Mit neuen Auszeichnungskonzepten und neuen Produktionsregeln garantiert
FML eine sparsamere Kodierung als XML. Somit ist ein ressourcenreduzierender Einsatz gewährleistet, der einer späteren etwaigen Kompression
(s. Kap. 11.5) zuarbeitet.
Die folgende tabellarische Gegenüberstellung untersucht für alle MarkupKomponenten (s. Kap. 4.1) und Freestyle-Konzepte (s. Kap. 6) durch einen
“Proof by Example“, vergleichend2 für XML und FML, die Sparsamkeit3 in
der Verwendung von Markup-Symbolen4 :
2
Relevante Komponenten oder Konzepte, die nur in einer der beiden Sprachen definiert sind, werden mit der anderen Sprache jeweils mit den zweckmäßigsten Alternativen
verglichen.
3
Alle Markup-Symbole werden gezählt. Das Zeichenvolumen der Platzhalter c∗ (Inhalt)
und i∗ (Bezeichner) ist unbekannt und wird für jedes Auftreten pauschal mit 1 bewertet.
4
Es wird jeweils die sparsamste Kodierung angewandt.
112
FML
Dokument (leer)
XML
Δ
<?xml version="1.0"?>
00-25=-25
Dokument (Inhalt)
c
<?xml version="1.0"?>c
01-29=-28
Inhalt
c
c
01-01= 00
Prolog
<@i="c">
c
08-08= 00
Tag-Paar
c
c
08-08= 00
Empty-Tag


04-04= 00
Multi-Tag
<<i1 ><i2 >>c<</i1 ></i2 >>
<i1 ic ="i2 "><i2 >c</i2 ></i1 >
19-21=-02
Kommentar
<!c!>

05-08=-03
PI
<?i c>
<?i c?>
06-07=-01
Wildcard
<>
c
02-08=-06
CDATA1
c
<![CDATA[c]]>
01-13=-12
CDATA2
<!c!>
<![CDATA[c]]>
05-13=-08
CDATA3
<?CDATA c>
<![CDATA[c]]>
10-13=-03
Annotieren
<*>
<*>
03-03= 00
Deklarieren
<@i="c">
<?xml i="c"?>
08-13=-05
Tagging
<i1 >c</i1 ><i2 />
<i1 >c</i1 ><i2 />
12-12= 00
Attribuieren
<i1 iA ="c"><i2 /></i1 >
<i1 iA ="c"><i2 iA ="c"/></i1 >
17-23=-06
Interferenz
<i1 >c1 <i2 >c2 </i1 >c3 </i2 >
<i1 >c1 </i1 ><i2 ><i1 >c2 </i1 >c3 </i2 >
17-24=-07
Identifizieren
<i1 I1 ><i1 I2 ></i1 I1 ></i1 I2 >
<i1 ></i1 ><i2 ><i1 ></i1 ></i2 >
22-21= 01
Kongruenz
<<i1 ><i2 >>c<</i1 ></i2 >>
<i1 ic ="i2 "><i2 >c</i2 ></i1 >
19-21=-02
Independenz
<iP |*>
<iP ><*></iP >
05-10=-05
Segmentieren
<i%iS %iSP />
<iS ></iS >
08-11=-03
Fragmentieren
</i1 ><i2 >
<i1 ></i1 ><i2 ></i2 >
07-14=-07
Die FML-Kodierung erfolgt im Vergleich zu XML insgesamt sparsamer5 .
Sparpotenzial:
Minimum:
Maximum:
Median:
Durchschnitt:
- 5 %
+ 100 %
+ 26 %
+ 32 %
Darüber hinaus ergeben sich weitere Einsparpotenziale durch Kodierung und
Maskierung: FML erlaubt signifikant mehr unmaskierte Zeichen als die restriktivere XML-Syntax [186, Kap. 2.3: Common Syntactic Constructs] und
kodiert mit dem alternativen Backslash-Verfahren (s. Anhang E.1, Punkt 3)
Maskierungen deutlich sparsamer als XML, das ausschließlich mit der UCSMaskierung arbeitet.
5
Die tatsächlich gegebene Sparratio ist für jede Sprachinstanz individuell auszuwerten.
113
10.16
Ergonomie
Die Sprache FML erfüllt die ergonomischen Anforderungen:
1. Angemessenheit
FML zeichnet sich einerseits durch funktionale Vollständigkeit, andererseits durch Sprachpurismus aus. Erforderliche Funktionalität wird
bereitsgestellt, entbehrliche Funktionalität ausgeschlossen.
2. Bedienbarkeit
Für Autorentätigkeiten, Informationsstrukturierung, Datentransfer, Serialisierung und Modelltransformation sind hohe Nutzungsqualitäten
und Leistungsmöglichkeiten gewährleistet.
3. Verständlichkeit
Die Technologie FML ist transparent und frei von Zweifelsfällen.
4. Lesbarkeit
Auf Inhalte oder Bezeichner hat FML gemäß Spachdefinition keinen
Einfluss. Die Lesbarkeit von Auszeichnungen indes ist gegeben. Markup kann in einem FML-Dokument von einem lesenden Auge klar
durch die Begrenzungssymbole < und > identifiziert werden. Der
konkrete Komponententyp erschließt sich leicht durch die Steuerungssymbole , /, @, ! und ?. Eine die Orientierung im Dokument unterstützende Formatierung eines Dokumentes durch Zeilenumbrüche und
Leerschritte wird nicht seitens der Spachdefinition integriert, sondern
einem FML-Editor übertragen (s. Kap. 11.7).
Die für die Visualisierung eines FML-Graphen erarbeiteten typographischen Merkmale
Form
Schrift
Vordergrund
Hintergrund
Dokument
Possessa [58]
#03022F
#07F9FC
Perspektive
Courier New
#000000
#FFFFFF
Arial
#000000
#FFFFFF
Element
Courier New
#07F9FC
#03022F
Attribut
Courier New
#03022F
#FFFFFF
Arial
#000000
#C8FFCC
Courier New
#05ED04
#7C8176
–
–
#CC0E1C
Inhalt
Kommentar
PI
Wildcard
114
entsprechen ergonomischen Anforderungen und sind in ihrer gestalterischen Umsetzung professionell6 verifiziert worden.
Dokument und Modell sind somit lesbar und nachvollziehbar.
5. Erlernbarkeit
Die Einarbeitungszeit ist im Vergleich zu XML als gering zu bewerten,
da die Spezifikation (s. Anhang C) ein vielfach geringeres Volumen
besitzt und der Kompatibilitätsgrad (s. Kap. 10.2) sehr hoch ist.
6. Erwartungskonformität
Die Dokumentinterpretation erfolgt spezifikationskonform determininistisch und größtenteils analog zur Interpretation eines Dokumentes
der Sprache XML.
7. Selbstbeschreibungsfähigkeit
Die Implementierung liefert verständliche und aussagekräftige Rückmeldungen, die auch im Fehlerfall Handlungskompetenz ermöglichen.
8. Fehlertoleranz
Der Benutzer wird durch Fehlerhinweise und Korrekturanleitungen
(s. Kap. 9.5) unterstützt.
9. Dokumentation
Der Informationsbedarf eines Nutzers der Sprache FML ist durch eine
Sprachdokumentation (s. Anhang C) vollständig abgedeckt.
Der übergreifenden Anforderung der Einfachheit und Komplexitätsminimierung fallen verschiedene aus XML bekannte Konstrukte zum Opfer. So
bleiben von dem XML-Namensraum-Konzept und den komplexen und oft
missverstandenen Kodierungsrichtlinien nur die ergonomisch vertretbaren
Konstrukte erhalten. Transparenz und Lesbarkeit für Definition und Zuordnung von namespaces ist bei FML gegeben. Gleichsam wurde das Konstrukt
der CDATA Sections, das bei Autoren und Entwicklern in der Praxis häufig
zu Irritationen und Fehlern führt, eliminiert.
Das in Kap. 2.16 aufgestellte Freestyle-Kriterium wird mittels der Konzepte Interferenz (s. Kap. 10.4), Kongruenz (s. Kap. 10.6), Independenz
(s. Kap. 10.7) und Segmentierung (s. Kap. 10.8) erfüllt.
Umfragen (s. Anhang K) bestätigen insgesamt, dass das Auszeichnen mit
FML verständlich ist, instinktiv erfolgt, leicht realisierbar sowie beherrschbar und angemessen ist.
6
TYPOGRAFIE & HERSTELLUNG WALCH, Bad Soden/Ts.
115
10.17
Für jedes FML-Dokument ist die Kodierung strikt festgesetzt: UTF-8 .
Der aktuelle Verwendungsgrad von UTF-8 beträgt für HTML/XHTMLWebseiten 61,3 %7 , die Tendenz ist anhaltend steigend. Der Unicode-Zeichensatz deckt alle bekannten und sinntragenden Zeichen weltweit ab und
wird der Anforderung Internationalisierung gerecht. Alternativen zu dieser
anerkannten, von der Internet Engineering Task Force (IETF ) geförderten
und von dem Unicode Consortium und der ISO normierten Kodierung sind
nicht zulässig.
Damit folgt FML der grundsätzlichen Kodierungsempfehlung des W3C [49]
[. . . ]to provide an unambiguous encoding of the content of plain
text, ultimately covering all languages in the world, but also major text-based notational systems for science, technology, music,
and scholarship.
Infolge der gegebenen Abwärtskompatibilität von UTF-8 werden auch 7-BitASCII-Zeichensatz-Dokumente korrekt verarbeitet [206], was sparsamer Kodierung (s. Kap. 10.16) und Migration (s. Anhang E) zuträglich ist.
Sinistrograde Schriften, deren Stellenwert und Integrationsmöglichkeiten für
XML in [77] untersucht werden, unterstützt FML durch das Prolog-Attribut
fml.writing-direction = ”lr”|”rl”
10.18
Eine Referenzimplementierung (s. Kap. 9) wurde erarbeitet. Diese Schnittstellenbeschreibung ist in der objektorientierten Sprache Java, abwärtskompatibel zur Version 1.5, verfasst und somit transparent und leicht portierbar
auf andere Sprachplattformen.
Die Kernfunktionalitäten der FML-Implementierung sind
• Deserialisierung FML-Dokument → FML-Graph
• Serialisierung FML-Graph → FML-Dokument
• Lesezugriff auf die Graphstruktur und alle Grapheigenschaften
• Schreibzugriff auf alle Grapheigenschaften und Graphmaniplation.
7
Stand vom 05.03.2011, W3Techs.
116
Das Datenmodell der Implementierung (s. Anhang I) repräsentiert den
FML-Graphen als Interpretation eines FML-Dokumentes. Jeder Knoten in
einem FML-Graphen, implizit jede Komponente eines FML-Dokumentes,
kann alle Elternknoten erreichen. Somit kann jeder Knoten über evtl. mehrere Elternbeziehungen auch den virtuellen Wurzelknoten (Root) erreichen.
Vice versa kann jeder Knoten alle Children und somit über evtl. mehrere
Stufen alle Blätter seines Hierarchiebaumes ansprechen. Die Anforderung
der komponentenübergreifenden Navigierbarkeit ist als erfüllt zu betrachten: Jeder FML-Graph-Knoten kann über Aggregationspfade jeden beliebigen anderen Knoten referenzieren.
Für die implementierungsunabhängige, übertragbare und erweiterbare Zugriffsschnittstelle wurde auf kurzlebige Frameworks und Designstrategien
verzichtet. Stattdessen basiert die Implementierung auf jahrelang bewährten und für jeden Entwickler nachvollziehbaren objektorientierten Basisstrategien wie Kapselung, lose Kopplung, starke Kohäsion.
Die FML-Spezifikation wurde strikt eingehalten. Verfügbarkeit der API ist
gegeben (s. Anhang L).
10.19
Spezifikation
Eine Spezifikation der Sprache
ist in Anhang C verfügbar.
Die Spezifikation ist inhaltlich korrekt und vollständig, fachbereichsübergreifend verständlich und lesbar, multimedial und zweisprachig als InternetPublikation verfügbar.
117
Kapitel 11
Sekundärtechnologien
Wenn der Mensch nicht über das
nachdenkt, was in ferner
Zukunft liegt, wird er das schon
in naher Zukunft bereuen.
Konfuzius
551 v. Chr. – 479 v. Chr.
Analog zu den zahlreichen auf XML aufbauenden Technologien wären auch
für FML weiterführende flankierende Lösungen einem erfolgreichen Einsatz
und einer breiten Anwendungsperspektive zuträglich. Im Folgenden werden
Sekundärtechnologien, die jedoch nicht Bestandteil dieser Arbeit, vielmehr
Gegenstand weiterführender Forschungen sind, sortiert nach Akzeptanzrelevanz betrachtet.
11.1
Freestyle Schema
Die FML-Spezifikation, die Essenz dieser Arbeit, beschreibt Syntax und
strukturelle Interpretation der Sprache. Die Menge der zur Sprachdefinition
konformen und wohlgeformten FML-Instanzen ist unendlich. Semantische
Interoperabilität bedarf jedoch eines wohldefinierten Vokabulars für den Datenaustausch. Hierfür muss ein Schema-Mechanismus zur Einschränkung
dieser Menge, eine Schema-Sprache zur Validierung von FML-Dokumenten
geschaffen werden.
Ein Freestyle Schema muss, entweder durch Inklusion oder durch Exklusion,
im Rahmen einer Validierung die Zulässigkeit und Eigenschaften mindestens
folgender Komponenten und Kriterien berücksichtigen können:
1. Hierarchiezustand
2. Perspektiven und Namensräume
118
3. Elemente und Attribute
4. syntaktische Regeln für Inhalte
5. Anordnung und Reihenfolgen
6. Beziehungen und Kardinalitäten
Ein einzusetzendes Schema-Dokument sollte in Anlehnung an die Prinzipien von XSD selbst ein wohlgeformtes FML-Dokument sein, also gleichsam
einem Meta-Schema unterliegen, und sprachinhärent von effektiven Paradigmen Gebrauch machen: Typisierung, Vererbung und Ableitung durch
Erweiterung oder Einschränkung, Gruppierung, Schema-Komposition durch
Inklusion, Überschreibung und Verfeinerung.
Die anzuwendenden Schemata werden einer FML-Instanz durch Deklaration der physikalischen Schema-URI s im Attribut fml.schema innerhalb
der Dokument-Prolog-Komponente (s. Kap. 4.1.4) des FML-Dokumentes
zugeordnet. Erfüllt die FML-Instanz alle Strukturbeschreibungen referenzierter Schemata, so wird sie als valide bezeichnet.
Dieser Zuordnungsmechanismus ist grundsätzlich vorbereitet. Was nunmehr
fehlt, ist die Definnition einer konkreten Schema-Sprache. Der gegenwärtige De-Facto-Standard XSD [173] ist nur bedingt übertragbar, da er lediglich die ausdrucksschwächeren Monohierarchien behandeln kann, CrossoverMarkup jedoch nicht. Dennoch sollte eine Neuentwicklung Akzeptanz und
Erfolg von XSD berücksichtigen sowie auch alternative Schema-Dialekte [93]
für XML. Elementare Ansätze zur Validierung polyhierarchischen Markups
wie [165], [143] oder [151] werden aktuell bereits diskutiert.
11.2
Freestyle Instanz Schemata
Per se hat FML neben strukturellen Informationen keinerlei inhärente Semantik, jedoch bietet diese Sprache die Infrastruktur, um eine anwendungsbezogene Verwendung zu eröffnen. Basierend auf Freestyle Schema kann eine
Semantik für FML-Instanzen festgesetzt werden. Durch eine Standardisierung derartiger Dokumentdefinitionen werden Instanzen, die allgemein als
problembezogene Umsetzungen von Konstrukten, Modellen und Methoden
verstanden werden [97], übergreifend interpretierbar und validierbar. Der
praktische Einsatz von FML in konkreten Anwendungsszenarien ist auf entsprechende Schemata angewiesen. Die Menge denkbarer Freestyle Instanz
Schemata ist ebenso unendlich wie die der Anwendungsfälle, jedoch muss
für einen präzisen Fall auch ein konkretes Schema zementiert werden, damit
die Kommunikation zwischen mehr als einem Nutzer semantisch zweifelsfrei
verlaufen kann.
Welche Freestyle Instanz Schemata wären also zu definieren? Zum einen
119
die reine Übersetzung bestehender XML-Standards (Übersicht aller XMLInitiativen: [32]) im Sinne einer Migration gemäß Anhang E, zum anderen
neue Anwendungsfallbeschreibungen, die von den neuen Möglichkeiten einer erweiterten Sprachfunktionalität profitieren, Defizite der insuffizienten
Sprache XML aufhebend. Beispielsweise typographische Sprachen, ähnlich
zu XSL-FO oder XHTML, die Überlagerungen verschiedener Hervorhebungen ohne verklärende Manipulation zugunsten eines Hierarchiezwanges nativ
bewältigen können.
11.3
Freestyle Query
Entwicklung, Analyse und Verarbeitung von FML-Instanzen bedürfen einer
formalen Abfragesprache zur selektiven Adressierung von Knoten in einem
FML-Graphen. Diese Abfragesprache sollte auf Ebene der Graphrepräsentation und nicht auf der des FML-Dokumentes operieren, da v. a. die im
Rahmen der Transformation vorgenommene Interpretation von freien Tags
in strukturierte Elemente Voraussetzung ist.
Eine Freestyle-Query - Abfragesprache dient der Suche, Lokalisierung und
Identifizierung von Informationen in FML-Instanzen sowie der Navigation
und Datenfilterung. Ergebnis einer Abfrage an einen FML-Graphen ist eine
Teilmenge desselben bzw. eine Leermenge.
Umsetzungskonzepte und Leistungskriterien können sich an dem gemeinhin
akzeptierten De-Facto-Standard [183] und an Vergleichsanalysen für XMLQuery-Sprachen wie [16] und [96] orientieren und von dem Konzept [74] für
Abfragen auf polyhierarchische Datenstrukturen inspirieren lassen.
11.4
Freestyle Transformation
Nicht zuletzt die begründeten Erkenntnisse “Alles ist ’Graph’ in der Softwaretechnik“ [57] und “Softwareentwicklung ist Transformation“ bestätigen die
Notwendigkeit einer Technologie für die Umwandlung einer FML-Instanz.
Die Transformation kann gleichermaßen angewendet werden auf den FMLGraphen bzw. dessen korrespondierende FML-Dokument. Ziel der Konvertierung ist eine neue FML-Instanz des selben oder eines anderen Freestyle
Schemas oder aber eine beliebige Inhaltskomposition für weiterverarbeitende
Applikationen außerhalb von FML.
Lösungskonzepte können sich an dem sehr populären regelbasierten Skriptansatz XSLT [185] oder an einer hierauf aufbauenden graphbasierten Modelltransformation wie [164] orientieren. Für eine Neuentwicklung kann auch
auf Erfahrungswerte der Technologien DSSSL [42] und OmniMark [160] zurückgegriffen werden. Die notwendige selektive Identifizierung von Knoten der Quellinstanz als Einstieg für rekursive und iterative Verarbeitungsinstruktionen erfordert die Integration der Sekundärtechnologie Freestyle
120
Query (s. Kap. 11.3).
11.5
Freestyle Kompression
Ein FML-Dokument, bestehend aus Inhalten mit eingebettetem Markup,
ist nüchtern betrachtet eine Sequenz von UTF-8 -Zeichen. Wie jeder Text
und jede textuelle Auszeichnungssprache enthält auch ein FML-Dokument
redundante Informationen. Hieraus ergibt sich die Notwendigkeit ressourcenreduzierender Kompressionstechnologien. Mittels Kompression können
Daten effizienter gespeichert und übertragen werden. Das Ziel sind minimale Redundanz und maximale Entropie durch verlustfreie und reversible
Komprimierung.
Zum einen kann man etablierte Algorithmen der Kategorien Lauflängenkodierung, Transformation, statistische und wörterbuchbasierte Verfahren, die
nahezu vollständig und umfassend im Lehrwerk [133] beschrieben werden,
anwenden. Die praktisch erzielbaren Kompressionsgrade liegen je nach Informationsgehalt des Inhaltes bei 50 – 80% [194]. Zum anderen lassen sich
spezifische Verfahren für FML entwickeln, die noch höhere Wirkungsgrade
versprechen.
Markup reichert ein Dokument zunächst um zusätzliche Zeichen an. Jedoch
können wider gestiegenem Zeichenvolumen die Strukturinformationen der
Tags für günstigere Kompressionsgrade verwendet werden. Der philosophische Grundsatz [172]
That which shrinks
Must first expand
läßt sich übertragen: Gleiche Tags kapseln zumeist semantisch und syntaktisch ähnliche Inhalte, die sich zusammengefasst günstiger komprimieren
lassen als verteilt. Auch sind identische Sub-Bäume in einem semistrukturierten Dokument eine häufige Redundanzquelle. Und für gegebene SchemaInformationen lassen sich Tag-sensitive spezialisierte Kompressionsalgorithmen partiell anwenden.
Anregung für die Entwicklung von FML-Kompressionsalgorithmen verspricht
neben dem jüngsten Ansatz [103] und den bestehenden für XML, die in [113]
und [6] umfassend objektiv bewertet und in [21] in einer Vergleichsanalyse
in drei adäquate Kategorien einsortiert werden, auch Sequitur [112]. Dieser
Ansatz basiert auf der Herleitung kontextfreier Grammatiken aus Textsequenzen und ist im Besonderen geeignet für semistrukturierte Texte [111],
also implizit für Markup-Dokumente.
121
11.6
Freestyle Datenbank
Eine Verbindung zwischen den weit verbreiteten relationalen Datenbanken und FML, analog zu bestehenden Synthesen zwischen Datenbanken
und XML [26], ist in zweifacher Hinsicht von hohem Stellenwert: die Darstellung relationaler Daten in FML für eine Weiterverarbeitung mit FMLAnwendungen sowie die Datenbankspeicherung von FML-Daten zwecks Anwendung relationaler Verarbeitungstechniken („[. . . ] attempts to merge
XML and relational technology provided XML views of relational data or
relational storage of XML data.“ [147]).
Für Ersteres muss ein Freestyle Instanz Schema für das relationale Datenmodell definiert werden. Die in [174] beschriebene Lösung zur Repräsentation
von Tabellen hat sich heute gemeinhin, auch über den Anwendungsbezug
HTML hinaus, durchgesetzt. Jedoch erfolgt diese Form der Übersetzung von
Relationen in ein streng hierarchisches Modell weder verlust- noch redundanzfrei. Auch bei FML bleibt das Problem der Übersetzung zwischen zwei
ganz und gar verschiedenen Datenstrukturen natürlich bestehen, es ergeben
sich aber insbesondere durch die neuen Spracheigenschaften Interferenz 1 (s.
Kap. 10.4) und Segmentierung 2 (s. Kap. 10.8) nativere Möglichkeiten für
ein Relationenmodell innerhalb einer Auszeichnungssprache.
Für Letzteres muss ein verbindliches ER-Modell [27] geschaffen werden. An
bestehenden Lösungen für XML wie [124] und [7] kann man sich nur bedingt
orientieren, da die mögliche Datenstruktur eines FML-Dokumentes in Folge
der neuen Freestyle-Konstrukte Interferenz (s. Kap. 10.4), Kongruenz (s.
Kap. 10.6), Independenz (s. Kap. 10.7), Segmentierung (s. Kap. 10.8) und
Fragmentierung (s. Kap. 10.9) weitaus irregulärer ist. Im Anhang J ist ein
relationales Datenbankschema vorgestellt, das mit dem Anspruch inhaltlicher Vollständigkeit und hohen Normalisierungsgrades entworfen worde und
dafür verwendet werden kann, jede beliebige FML-Instanz verlust- und redundanzfrei in einer relationalen Datenbank zu persistieren.
Auch bedarf es über diese bidirektionale Strukturtransformation zwischen
Datenbank und Auszeichnungssprache hinaus der Übersetzung der unterschiedlichen Abfragetechniken SQL und Freestyle Query.
Neben dem relationalen wären auch Lösungen für das objektrelationale Paradigma, das nach [161] perspektivisch die Führungsrolle unter den vier
Datenverwaltungssystemen übernehmen wird, zu untersuchen. Wie serialisieren sich, analog [17], Objektgraphen aus einer OO-Datenbank in die neue
Auszeichnungssprache? Wie persistiert man FML-Instanzen in einer OODatenbank? Orientieren kann man sich hierbei an Lösungen bestehender
nativen XML-Datenbanken, die in [85] untersucht werden.
1
2
Ein value könnte gleichermaßen Child zweier Parents, Zeile und Spalte, sein.
Die Tupeldefinition kann durch verteilte Komposition erfolgen.
122
11.7
Freestyle Editor
In der FML-Sprachdefinition (s. Kap. 4) wurde bewusst auf eine Sonderbehandlung von Formatierungssymbolen verzichtet (vgl.: White Space Handling in XML mit dem Attribut xml:space). Jedes Symbol ist Bestandteil der
Inhaltssequenz, auch die Unicode-Formatierungssymbole U+0020, U+2000U+200B, U+3000, U+00A0, U+0009, U+000D und U+000A für Zwischenräume,
Tabulatoren und Umbrüche. Fügt ein Autor diese lediglich mit der Absicht einer besseren Leseorientierung in den Inhalt eines Dokumentes ein, so
hat er auch den Inhalt gleichsam manipuliert. Für externe Dokumentprozessoren und die Interpretation eines Dokumentes in einem FML-Graphen
jedoch kann auf globaler Ebene oder auf Elemente das Attribut fml.trim
angewendet werden. Ist fml.trim=true so sind alle Formatierungssymbole für untergeordneten Inhalte zu ignorieren.
Grundsätzlich kann ein FML-Dokument in jedem beliebigen UTF-8 -Editor
gelesen und bearbeitet werden. Aus Gründen der Lesbarkeit sollte jedoch
ein spezieller FML-Editor angewandt werden, der einem Leser und Autor
ein Dokument über eine interne Repräsentationsschicht formatiert anbieten
kann. Ein solcher Editor könnte entweder mit einer separaten Formatserialiserung arbeiten oder aber mit exklusiven Unicode-Steuerungszeichen wie
den Noncharacters3 U+FFFE und U+FFFF.
Folgende Formatierungsrichtlinien werden empfohlen:
• Zeilenumbruch vor jeder Markup-Komponente vor deren Begrenzungssymbol ’<’ – vorangestellte Maskierungszeichen ’\’ beachten!. Ausgenommen ist das Markup, das als erste Komponente im Dokument
auftritt.
• Zeilenumbruch vor jeder Inhalts-Komponente die einer Markup-Komponente nach deren Begrenzungssymbol ’>’ (Vorangestellte Maskierungszeichen ’\’ beachten!) folgt
• Zeilenumbruch an einer konfigurierbaren konstanten horizontalen Position zwecks Begrenzung der Bildlaufaktivität. Auf die dem Umbruch
folgende Zeile ist die horizontale Einrückung der vorangehenden Zeile
anzuwenden.
• horizontale Einrückungen (Anordnung in Spalten durch Tabulatoren)
von Komponenten in einer konfigurierbaren Positionslänge proportional zu ihren Knotentiefen (Anzahl übergeordneter Knoten in dem korrespondierenden polyhierarchischen FML-Graphen)
3
“These codes are intended for process-internal uses, but are not permitted for interchange“: Unicode Standard, Version 5.2, http://www.unicode.org/charts/PDF/UFFF0.pdf.
123
• Syntaxhervorhebung durch unterschiedliche Schriftarten, -stile und
Farben
Für die Entwicklung eines Editors, der über eine UTF-8 -Zeichenverwaltung
hinaus eine anwenderbezogene Oberfläche anbieten kann, versprechen zahlreiche existierende Programme zur Erstellung und Bearbeitung von SGML
und XML Anregung. Die Faktoren Ergonomie und Akzeptanz für eine Benutzerschnittstelle eines Markup-Editors werden in [46] untersucht.
Neben der Bearbeitungsfunktionalität für FML-Dokumente soll ein Editor
auch den korrespondierenden FML-Graphen visualisieren können. Die Knoten für leeren (∅) und für reinen Formatierungsinhalt (∼) sollten in einem
Grapheditor zugunsten der Übersichtlichkeit optional ausgeblendet werden
dürfen. Für eine effektive Bearbeitung von FML-Instanzen ergeben sich
durch die ergonomische Realisierung eines Graphmanipulationswerkzeuges
vielversprechende Möglichkeiten. Voraussetzung hierfür ist die Implementierung der bidirektionalen Transformation (s. Kap. 7) zwischen beiden
Repräsentationsformen einer FML-Instanz.
11.8
Freestyle Implementierung
Die vorgestellte Referenzimplementierung (s. Kap. 9) basiert auf der erarbeiteten Spezifikation (s. Anhang C) und gibt für andere Implementierungen den Referenzrahmen vor: Jede Implementierung der Sprache FML muss
alle Schnittstellenvorgaben (API ) erfüllen und darf die Spezifikation nicht
verletzen. Es steht jeder Implementierung frei, erweiterte Funktionalität
anzubieten, höhere Performance zu erzielen und in beliebigen objektorientierten Programmiersprachen zu operieren.
Darüber hinaus bietet jede der in diesem Kapitel angesprochenen Sekundärtechnologien vielseitige Implementierungsaufgaben, die weit über die Referenzimplementierung hinausgehen. Und so, wie sich sehr viele auf XML
basierende Konzepte wie beispielsweise JAXB [86] finden, wäre auch deren
Umsetzung mit der erweiterten Datenstruktur von FML vielversprechend
und würde neue Einsatzszenarien ermöglichen.
124
Kapitel 12
Vergleichsanalyse
Es lohnt sich, die Entdeckungen
anderer zu studieren, dass für
uns selbst eine neue Quelle für
Erfindungen entspringt.
Gottfried Wilhelm Leibniz
1646 – 1716
Es wird eine Analyse des aktuellen Forschungsstandes durch Identifizierung
der in der Zielsetzung zu FML vergleichbaren Alternativen, Technologien
und Initiativen vorgenommen. Diese Betrachtungen münden in einem zusammenfassenden objektiven Vergleich über alle FML-Eigenschaften und
garantieren das Prinzip der Wertfreiheit.
12.1
GODDAG
Modell zur Repräsentation von Markup-Strukturen mit überlagernden Auszeichnungen. GODDAG [152] ist strukturell dem FML-Graphen (s. Kap.
5.3) sehr ähnlich und bezieht sich insbesondere auf Modellierung von und
Transformation zu MECS. Mehrere experimentelle Weiterentwicklungen wie
[73] nehmen auf GODDAG-Strukturen Bezug.
12.2
LMNL
Diese Auszeichnungssprache wurde in [166] präsentiert und mit dem primären Ziel, unbeschränkt Markup-Überlagerungen in einem redundanzfreien
Dokument zu ermöglichen, entwickelt. Das XML-Wohlgeformtheitskriterium wird mit einer neuen Grammatik, ähnlich der von TexMECS, aufgehoben. LMNL stellt Syntax, Datenmodell und prototypische Implementierung für Abfrage und Analyse bereit. In [119] wird LMNL um eine XMLRepräsentation weiterentwickelt.
125
12.3
MCT
MCT [80] erweitert das XML-Datenmodell um Knotenfärbungen: Eine Farbe
repräsentiert eine Annotationsebene, eine Hierarchie, und die Zuordnung einer oder mehrerer Farben zu einem Knoten ordnet einem Knoten Hierarchien zu. Dieser Lösungsansatz arbeitet mit XML-konformen Dokumenten,
redundanter Kodierung und virtuellen dokumentübergreifenden Referenzen.
Neben einem logischen Datenmodell wird ein physisches Datenmodell, basierend auf der nativen XML-Datenbank TIMBER [79], eingesetzt. Schwerpunkt von MCT sind Abfragesprache (MCXQuery) und Datenbankserialisierung.
12.4
MuLaX/XCONCUR
Die Sprache MuLaX wurde in [66] entwickelt und in [67] kompakt präsentiert. MuLaX führt eine neue Dokumentsyntax, die nicht XML-kompatibel
ist, ein und ermöglicht mit einem an SGML-CONCUR angelehnten Mechanismus Markup über verschiedene Annotationsebenen (Layers) in demselben
Dokument. Elemente werden einem Layer durch eine ID zugewiesen, einem
Layer wiederum kann eine Schemadeklaration zugewiesen werden. Der Arbeit von [140] folgend wurde der Begriff XCONCUR, der den Begriff MuLaX
ersetzte, lanciert. Mit der Validierung von XCONCUR-Dokumenten setzt
sich [143] und [141] auseinander, eine API wird in [142] entwickelt.
12.5
MultiX
Die Serialisierung mehrerer Strukturebenen desselben Dokumentes wird mit
MultiX [25] durch virtuelle Referenzkomposition erzielt. Hierfür werden alle
disjunkten Fragmente der Inhaltssequenz in einer indizierten base structure
organisiert, aus der sich spezifische Dokumentstrukturen gemeinsam bedienen können. Dokumentinhalt, Ebenen und Assoziationen werden in einem
MultiX -Dokument konsolidiert. MultiX arbeitet mit XML-konformer Syntax, basiert auf dem Multi-Structure Document Model [24] und bietet eine
angepasste XQuery-Implementierung an.
12.6
NITE
NITE [23], eine Technologie zur Verwaltung verschiedener Annotationsebenen innerhalb desselben Dokumentes, bietet eine XML-Datenstruktur zur
Modellierung mehrdimensionaler Semantik über eine Datensequenz. Motivation des Projektes NITE ist insbesondere die Beziehungsanalyse auf Ebene
des NITE Object Models (NOM [156]). NITE ist geprägt durch starken Anwendungsbezug zur linguistischen Textanalyse. Projektbestandteil ist auch
126
eine Java-Bibliothek für Lesezugriff, Abfrage, Manipulation und Serialisierung. NITE befindet sich unter der Projektbezeichnung NXT in aktueller
Entwicklung und Anwendung.
12.7
SGF/XStandoff
Schwerpunkt von SGF [157] ist die Verwaltung multipler Annotationsebenen
(multi-rooted trees), deren Validierung, Abfrage, Analyse und Serialisierung.
SGF hat einen starken linguistischen Anwendungsbezug, basiert auf der logischen linguistischen Struktur von [14], arbeitet XML-konform mit virtueller
Elementkonstruktion (SGML-Referenzierungsmechanismus ID/IDREF (S))
aus einer über Zeichenpositionsangaben segmentierten Inhaltssequenz. Die
Weiterentwicklung von SGF erfolgt aktuell unter dem Term XStandoff [158].
12.8
SGML/XML
SGML [3], mehr noch XML [186], eine strikte syntaktische und konzeptionelle Teilmenge von SGML, sind die gegenwärtigen De-Facto-Standards für
Auszeichnungssprachen. Allein aus diesem Grund suchen viele der vorgestellten Vergleichsansätze eine XML-Kompatibilität. FML berücksichtigt
diesen berechtigten Anspruch (s. Kap. 2.2), kann eine absolute Kompatibilität jedoch nicht anbieten, da die Erfüllungsgrade gegenüber anderen
Anforderungen sonst zu niedrig wären und sich FML nur als ein weiteres
“Workaround“ einreihen würde. SGML bietet das optionale Feature CONCUR, das “multiple concurrent structural views“ [3] ermöglicht, an. Somit
ermöglicht SGML Independenz, XML nicht. Beide Technologien zeichnen
sich insbesondere durch einen hohen Reife- und Akzeptanzgrad, granulare
Spezifikationen und breite Unterstützung durch sekundäre Technologien aus.
Die für FML evaluierten Anforderungen leiten sich in erster Linie aus den –
wider dem etablierten Status – bestehenden Defiziten der Sprache XML ab.
12.9
TEI
TEI ist eine Initiative, die sich unter starkem linguistischen Anwendungsbezug mit der XML-basierten Kodierung von Texten auseinandersetzt und
ist Herausgeber eines umfassenden Kompendiums [154] mit Empfehlungen
für Text-Markup. In der Essenz ist die TEI eine Dokumentation für XMLInstanzen, die Texte nach lingustischen Aspekten auszeichnen. Für Beschreibung und Validierung dieser Instanzen wird eine XSD und DTD herausgegeben. Darüber hinaus geht TEI auch auf bestehende Workarounds für das
Auszeichnen nicht-hierarchischer Strukturen ein.
127
12.10
TexMECS
TexMECS [72] basiert syntaktisch und konzeptionell auf MECS [71] und
setzt sich schwerpunktmäßig mit der Kodierung interferenter Strukturen
(overlapping elements) auseinander. Konzeptionell ist diese Technologie
stark an einer Transformation der präsentierten Grammatik hin zu einer
GODDAG-Struktur orientiert. Die verwendete Syntax ist nicht konform zu
SGML/XML, die neu eingeführte Notation ist einfach und intuitiv. Die
Sprache TexMECS befindet sich im experimentellen Entwicklungsstadium
und gleicht in ihrer Intention sehr der Freestyle-Anforderung der Interferenz
(s. Kap. 2.4).
12.11
Zusammenfassung
Alle vorgestellten Technologien wirken einer Stagnation in der Entwicklung
von Auszeichnungssprachen entgegen und sind (exkl. Kap. 12.8) durch einen
Verbesserungsfokus auf die dominierende Technologie XML oder schlicht
Workaround-Pragmatismus geeint. Sie unterscheiden sich jedoch in der Behandlung bestehender XML-Defizite.
Schwerpunkt aller Vergleichskonzepte sind interferierende Auszeichnungen
(s. Kap. 2.4) und der Umgang mit independenten Interpretationen desselben Inhaltes (s. Kap. 2.7). Wohlgemerkt kann Interferenz als eine Implikation der Independenzanforderung aufgefasst werden.
In Anlehnung an die in [154, Kap. 20] vorgenommene und von [201] erweiterte Kategorisierung lassen sich Interferenz- und Independenz-Lösungen
(zzgl. Freestyle) folgendermaßen abgrenzen:
1. Freestyle
Restriktionsfreie Anordnung von Tags und Interpretation von korrespondierenden Tags in Elemente im Zuge der Transformation des
FML-Dokumentes in einen FML-Graphen.
2. CONCUR
Mittels Zuordnung von Tags zu Hierarchien lassen sich multiple Annotationsebenen in einem Dokument kodieren. Die Zuordnung erfolgt
durch einen syntaktischen Präfix im Tag.
3. Meilensteine
Diese Technologie, erstmals vorgeschlagen in [9], verwendet zur Darstellung polyhierarchischer Ordnungen leere Tags zur Markierung von
Element-Grenzen.
4. Fragmentierung
Elemente werden über mehrere Tag-Paare fragmentiert. Somit kann
128
eine Monohierarchie für komplexere Strukturen erzwungen werden.
Dieses Konzept wurde eingeführt von einer frühen Version von [154].
5. Virtuelle Elemente
Virtuelle Element-Konstruktion aus Sequenzfragmenten durch Integration spezieller Join-Elemente und -Attribute (result, target, start,
end, pos, etc.) in die bestehende Primärhierarchie eines Dokumentes.
6. Stand-Off
Auch Out-Of-Line-Annotation. Vgl. 5, mit der Erweiterung, dass
neue Hierarchien auch gänzlich außerhalb referenzierter Dokumente
virtuell und oft physisch separat erstellt werden können. Das Konzept
“separating markup from the material marked up“ wurde von [168]
vorgestellt, von [100] weiterentwickelt und findet insbesondere bei der
Verarbeitung linguistischer Daten Anwendung.
7. Redundanzkodierung
Mehrere hierarchische Annotationsebenen werden über mehrere Dokumente mit derselben Inhaltssequenz ausgezeichnet. Die resultierenden
multiplen Dokumente sind hochgradig redundant. Individuelle hierarchische Perspektiven sind auf Kosten des Wartungsaufwandes bei
Inhaltsänderungen transparent und einfach zu verarbeiten.
Meilensteine
Fragmentierung
Virtuelle Elemente
Redundanzkodierung
Die tabellarische Klassifikation gewährt einen grundsätzlichen Überblick, täuscht eine
absolute Zuordnung jedoch nur vor: An sich ist jeder Vergleichsansatz individuell zu
differenzieren.
129
XML
TexMECS
TEI
SGML
Stand-Off
1
SGF/XStandoff
CONCUR
NITE
MultiX
MuLaX/XCONCUR
LMNL
MCT
GODDAG
Freestyle
FML
Diese Lösungskonzepte, für die in [34, S. 3] Evaluationskriterien aufgestellt
und Bewertungen vorgenommen werden, lassen sich den vorgestellten Vergleichsansätzen wie folgt zuordnen1 :
Mit [98] wurde ein komplexes Framework zur Konvertierung zwischen den
verschiedenen Vergleichsansätzen initiiert.
Die Evaluation der Anforderungen und die Spezifikation der Sprache FML
wurden durch alle vorgestellten Vergleichsansätze geprägt. Die bestehenden Interferenz- und Independenz-Lösungsansätze konnten nicht unmittelbar übernommen werden, da sie Workarounds auf eine insuffiziente Sprache
sind und kein In-Line-Markup ermöglichen, keine Redundanzfreiheit versprechen oder Kriterien der Ergonomie oder Entropie widersprechen (s. Kap.
2.2, 2.4, 2.15, 2.16). Jedoch haben die skizzierten Vergleichsansätze, deren
Problemstellung und Anwendungsszenarien die lösungsorientierte Realisierung der Sprache FML über alle Anforderungen inspiriert und nachhaltig
beeinflusst: Es wurde versucht, das Beste von allem in etwas Neuem zu konsolidieren.
Folgende Übersicht veranschaulicht die chronologische Ordnung aller vorgestellten Vergleichsansätze2 :
TEI
XML
TexMECS
LMNL
NITE
GODDAG
MCT
XCONCUR
MuLaX
MultiX
SGF
XStandoff
FML
2010
2009
2008
2007
2005
2004
2003
2002
2001
1998
1987
2
Datierung verweist auf das Publikationsjahr einer ersten relevanten wissenschaftlichen
Veröffentlichung.
130
Alle FML-Eigenschaften werden den in diesem Kapitel vorgestellten Vergleichstechnologien in der folgenden tabellarischen Zusammenfassung gegenübergestellt. Es wird jeweils beurteilt, mit welchen Anforderungen sich eine
Technologie grundsätzlich auseinandersetzt. Bezieht eine Technologie einen
FML-Anforderungsaspekt lösungsorientiert in ihre Konzeption oder Realisierung mit ein (+) oder befindet sich dieser Aspekt gänzlich außerhalb
ihrer Forschungen (–)? Für eine über diese binäre Fallunterscheidung hinausgehende weiterführende Differenzierung der Umsetzungskonzepte und
eine Evaluation von Erfüllungsgraden müssen die für jede Vergleichstechnologie identifizierten Referenzdokumente vertiefend studiert werden. Irrelevante oder implizite Aspekte (wie Grammatik oder Kompatibilität für
XML-Instanzen) werden negativ bewertet.
Einige FML-Anforderungen wie Wildcard stehen in keinerlei Bezug zu einem
der Vergleichsansätze, sondern sind aus pragmatischen Gesichtspunkten und
Praxiserfahrung entstanden.
Diese Bewertung soll wohlgemerkt keineswegs einer Beurteilung gleichen,
sondern prägnant den Forschungsschwerpunkt aus der Teilmenge jeweils relevanter Anforderungen ausdrücken.
131
132
FML
GODDAG
LMNL
MCT
MuLaX /XCONCUR
MultiX
NITE
SGF /XStandoff
TEI
TexMECS
XML*
Grammatik
+
–
+
–
+
–
–
–
–
+
+
Kompatibilität
+
–
+
+
+
–
–
+
–
–
+
Monohierarchie
+
+
+
+
+
+
+
+
+
+
+
Interferenz
+
+
+
–
–
–
–
–
+
+
–
Identifizierung
+
–
–
–
–
–
–
–
–
+
–
Kongruenz
+
–
–
–
–
–
–
–
–
–
–
Independenz
+
–
–
+
+
+
+
+
+
–
–
Segmentierung
+
–
–
–
–
–
–
–
–
+
–
Fragmentierung
+
–
–
–
–
–
–
–
–
–
–
Wildcard
+
–
–
–
–
–
–
–
–
–
–
+
–
–
–
–
–
–
–
–
–
–
Vererbung
Technologie
Anforderung
+
+
+
+
+
–
+
+
–
+
+
Transformation
+
+
–
–
+
–
+
–
–
+
+
Eindeutigkeit
+
–
–
–
+
–
+
–
–
–
+
Entropie
+
–
–
–
–
–
–
–
–
–
–
Ergonomie
+
–
–
–
–
–
–
–
–
–
–
+
–
–
–
–
–
–
–
–
–
+
+
–
–
+
+
–
+
–
–
–
+
+
–
–
–
+
–
+
–
+
–
+
Spezifikation
Kapitel 13
Epilog
Mehr als das Blei in der Flinte
hat das Blei im Setzkasten die
Welt verändert.
Georg Christoph Lichtenberg
1742 – 1799
Dieses Kapitel fasst die Arbeit zusammen. Alle Ergebnisse werden gegenüber der ursprünglichen Zielsetzung diskutiert und in den aktuellen Stand
der Forschung eingeordnet, Integrationsmöglichkeiten in bestehende Systemlandschaften reflektiert, mögliche Perspektiven und Entwicklungspotenziale
dargelegt.
13.1
Ergebnisse
Gemäß Zielsetzung (s. Kap. 1.1) ist eine neue Sprache lanciert:
Sie erweitert funktional XML und befreit – als primäre Vergleichseigenschaft
– das Auszeichnen von Dokument- und Datenstrukturen von restringierenden Root- und Hierarchie-Zwängen, ermöglicht ein intuitiv-freihändiges Auszeichnen.
Für diese Auszeichnungssprache wurden im Ergebnis der Arbeit eine Grammatik (s. Kap. 4.2), ein Graphmodell (s. Kap. 5) und eine Referenzimplementierung (s. Kap. 9) festgesetzt, quintessenziell ihre Eigenschaften
(s. Kap. 10) dargelegt, eine Spezifikation wird in Anhang C veröffentlicht. Zuvor werden vergleichbare Ansätze analysiert (s. Kap. 12) und 17
verschiedene Sprachanforderungen (s. Kap. 2) begründet. Zwei Beispiele
(s. Anhang A und B) illustrieren Realitätsbezug sowie die gegebene Einsatzbereitschaft der präsentierten Basistechnologie. Plausibilität und Akzeptanz wesentlicher und das ergonomische Freestyle-Kriterium bedienender
133
Spracheigenschaften wurden mit einer Umfrage (s. Anhang K) unter Technologieunternehmen untermauert.
Die mittels FML in Dokumenten ausgezeichneten Informationen können in
einem typischen Anwendungsprozess nicht nur serialisiert und deserialisiert
werden (s. Kap. 7), sie werden auch validiert, transformiert, durchsucht, extrahiert, bearbeitet, angereichtert, dargestellt, komprimiert, transportiert,
archiviert sowie beliebig weiterverarbeitet. Die Situation ist vergleichbar
mit anderen Grundlagenentwicklungen wie Codd’s RDBMS: “relational databases required hundreds of thousands algorithmic innovations to make it
work well“ [115]. Die für derartige Sekundärprozesse wichtigsten notwendigen Technologien wurden skizziert (s. Kap. 11) und bieten Anregungen für
weiterführende Forschungen.
Insofern wurden in dieser Arbeit keineswegs mehr Probleme aufgewiesen als
gelöst, vielmehr ist das Fundament für eine neue Auszeichnungssprache gelegt, nachfolgende Entwicklungen sind identifiziert. Über diese Anregungen
hinaus bleiben keine Fragen oder Widersprüche offen: Die aufgestellten Ansprüche der einleitenden Zielsetzung sind gelöst.
Die Arbeit ist in ihrer Intention vergleichbar mit der von Brian K. Reid,
welcher 1980 in seiner Dissertationsschrift [129] schöpferisch eine neue deskriptive Auszeichnungssprache – Scribe – lancierte, auf bestehende Ansätze
aufbaute und Weiterentwicklungen, wie GML, SGML und HTML, inspirierte.
13.2
Integration
FML, eine maßgeblich von XML, dem De-Facto-Standard für heterogenen
Datenaustausch über alle Arten von Informationen, inspirierte Weiterentwicklung, berücksichtigt in seiner Spezifikation sowohl verschiedene Erfahrungswerte und Defizitdiskurse über die letzten zehn Jahre Erfolgsgeschichte
der populären Auszeichnungssprache als auch relevante Vergleichsansätze.
Insofern ordnet sich diese Arbeit in den Stand der Forschung umsichtig und
zeitgemäß ein, neue Entwicklungen anregend.
Wie aber kann eine Integration in bestehende Systemlandschaften erfolgen?
Die Frage nach Systemintegration verlangt eine Identifizierung relevanter
Anwendungsszenarien und konkrete Anleitungen für praktische Handlungskompetenz, auch verlangt sie nach einer Antwort über die unternehmerischen Aspekte Integrationsvorteil und -aufwand.
Relevante Szenarien für einen Einsatz von FML als Transfersyntax und Serialisierungsformat ergeben sich im Allgemeinen in Systemen, in denen
• eine transparente Basistechnologie für einen sicheren Datenaustausch
gefordert ist,
• verschiedene Perspektiven über dasselbe redundanzfreie Dokument und
134
• semistrukturierte Daten auszuzeichnen sind.
Prädestiniert für ein Zusammenwirken sind folgende Anwendungsbereiche:
• Wissensdatenbanken,
• typographische Beschreibungssprachen,
• Dokumentendigitalisierung,
• CMP-Anwendungen, CMSe und EDMSe,
• Mehrautorensysteme,
• Kollaborationssoftware,
• Versionsverwaltungssysteme,
• Kommunikationsprotokolle,
• Persistenzmedien.
Die technische Verarbeitung gestaltet sich im Vergleich zu XML grundsätzlich aufwändiger, wie auch eine polyhierarchische Struktur komplexer
als eine einfach hierarchische ist. So ließe sich beispielsweise ein XMLDokument nur sehr bedingt mit dem ereignisorientierten Vorgehen eines
SAX -Parsers erfassen. Es bedarf einer vollständigen Dokumentenprüfung,
um einen FML-Graphen zu konstruieren. Mit der hierfür präsentierten Referenzimplementierung in Verbindung mit einem aus der Spezifikation resultierenden sicheren Sprachverständnis vermag man jedoch bereits FML-Dokumente zu schreiben, im Objektmodell einer FML-Instanz zu navigieren,
zu manipulieren, abzufragen sowie zwischen FML-Instanz und FML-Dokument zu serialisieren und deserialisieren. Für simple Anwendungen bereits
hinreichende Funktionalität. Neben diesem Fundament wäre für eine weiterführende Implementierungsintegration jedoch an die in Kapitel 11 identifizierten Sekundärtechnologien anzuknüpfen.
Der primäre Integrationsvorteil besteht insbesondere in einer vergleichsweisen Ressourcenschonung in Folge der Möglichkeit einer redundanzfreien Dokumentenkonsolidierung. Auch das Freestyle-Auszeichnen von Texten und
Daten – wo bislang semistrukturierte Inhalte in das Prokrustesbett einer
Hierarchie gezwängt werden mussten – ist für Verfasser und Modellierer
überzeugend.
Im Vergleich zu XML können sich FML-Dokumente strukturell weitaus komplexer gestalten, gleichsam schwieriger lesend zu erfassen und auch zu parsen sein. Dieser Umstand wird jedoch neutralisiert durch den hohen Freiheitsgrad der Autoren, Dokumente ohne synthetische Konstrukte nativ auszeichnen zu können. Die Interpretation wird transparenter, Strukturbrüche
135
müssen nicht zurückgebaut werden, eine Manipulation bestehender Dokumente ist deutlich ungefährlicher. Durch den hohen Kompatibilitätsgrad
zu XML dürfte sich der Integrationsaufwand bei Migrationsprojekten unter Berücksichtigung des Konvertierungsleitfadens (s. Anhang E) erheblich
vereinfachen.
13.3
Perspektiven
Die Zukunft von Auszeichnungssprachen ist unbestreitbar [4]. Grundsätzlich hat FML das Entwicklungspotenzial, Grundlage einer neuen In-praxiLösung für das Erstellen, Verarbeiten, Transformieren und Transportieren
beliebiger Informationen zu werden. Für eine Perspektive muss jedoch der
Vergleich mit der dominierenden Technologie XML bestanden werden.
FML ist deutlich leichter zu erlernen, präzise in seiner Spezifikation, intuitiv verwendbar, den restriktionsfreien Einsatz freihängen Auszeichnens
versprechend. Profitierende Anwendungen finden sich bereichsübergreifend
allerorten, insbesondere dort, wo der Umgang mit semistrukturierten Daten
polyhierarchischer Ordnung bewältigt werden muss.
Die Basistechnologie FML ist universal den organisch wachsenden
Anforderungen von Anwendungsszenarien einer mehrdimensional
vernetzten und inhomogen strukturierten Zukunft jenseits obsoleter Dokumenthierarchien sehr viel näher als gegenwärtige inkonvergente Auszeichnungskonventionen.
FML kann nicht für sich allein verwendet werden. Für erfolgreiche Integrationsperspektiven ist ein Ausbau von Sekundärtechnologien (s. Kap. 11)
zwingend erforderlich. Die Perspektive von FML ist somit gleich der Motivation der Wissenschaftsgemeinschaft zur Weiterentwicklung flankierender
Technologien. Zu deren Förderung werden nicht nur die Ergebnisse dieser
Arbeit online (s. Anhang L) veröffentlicht, sondern auf derselben gewarteten Plattform auch alle Weiterentwicklungen zur Verfügung gestellt.
Die Diskussionen werden weiter gehen.
Ein Paradigma gilt so lange als anerkannt, bis Phänomene auftreten, die
mit der bis dahin gültigen Lehrmeinung nicht vereinbar sind. Bezogen auf
XML wurden in dieser Arbeit dessen Defizite identifiziert und in einer neuen
Sprachspezifikation weitestgehend gelöst. FML hat somit das Potenzial zur
Anregung eines Paradigmenwechsels, der nach [90] stattfindet, sobald sich
eine neue Lehrmeinung durchsetzen kann.
136
13.4
Nachspiel
Die Dissertationsschrift klingt mit einem illustrativen Exempel1 – eine typographisch gestaltete Komposition der relevantesten Termini – aus.
Dem dokumentenzentrischen Ansatz folgend setzt sich der Inhalt aus Texten zusammen, und ergänzend könnte Markup jedes der 147 gewichteten
Literale um Informationen zu Schrift, -farbe, -größe, -position oder Dokumentreferenzen auszeichnen.
So wird abschließend eine gegenständliche Verbindung zwischen Arbeitsthematik und Anwendung hergestellt.
1
Erstellt mit Wordle™.
137
[1] Computer Lexikon mit Fachwörterbuch deutsch-englisch, englischdeutsch. Microsoft Press Deutschland, Unterschleißheim, 7. Auflage,
2003.
[2] 24613:2008, ISO: Language resource management - Lexical markup
framework (LMF), Mär. 2008. http://www.tagmatica.fr/lmf/iso_tc37_
sc4_n453_rev16_FDIS_24613_LMF.pdf.
[3] 8879, ISO: Information processing - Text and Office Systems - Standard Generalized Markup Language (SGML). International Organization for Standardization, Genf, Schweiz, 1986. http://www.iso.org/
cate/d16387.html.
[4] Adler, Sharon C.: Why is Markup Still Important after 30 years
and Will it Still be Important in Another 30. In: XML Prague
2010 - Conference Proceedings, Prag, Tschechische Republik, Mär.
2010. Institute for Theoretical Computer Science, Charles University,
Jiri Kosek. http://www.xmlprague.cz/2010/presentations/Sharon_C_
Adler_Why_is_Markup_Still_Important_after_30_years_and_Will_
it_Still_be_Important_in_Another_30.pdf.
[5] Andre, J., R. Furuta und V. Quint: Structured Documents. Cambridge University Press, Cambridge, Großbritannien, 1989.
[6] Augeri, Christopher J., Dursun A. Bulutoglu, Barry E.
Mullins, Rusty O. Baldwin und Leemon C. Baird, III: An analysis of XML compression efficiency. In: ExpCS ’07: Proceedings of
the 2007 workshop on Experimental computer science, Seite 7, New
York, NY, USA, 2007. https://www.usenix.org/events/expcs07/papers/
7-augeri.pdf.
[7] Bagui, Sikha: A formal definition for translating XML documents
to the entity relationship model. Int. J. Metadata Semant. Ontologies,
Inderscience Publishers, 2(1):54–66, 2007.
138
[8] Barczok, Achim: Das universelle Buch - Mobiles Lesen mit E-Books
und E-Book-Readern. c’t magazin für computer technik, 25:134–137,
Nov. 2009.
[9] Barnard, David, Ron Hayter, Maria Karababa, George Logan und John McFadden: SGML-based markup for literary texts:
two problems and some solutions. Computers and the Humanities,
22(4):265–276, 1988.
[10] Batori, Istvan S. und etc. (Herausgeber): Computational Linguistics: An International Handbook on Computer Oriented Language
Research and Applications. Walter de Gruyter & Co, Sep. 1989.
[11] Behme, Henning: Zehn Jahre XML. iX, 102, Mär. 2008. http:
//www.heise.de/ix/artikel/Mit-spitzer-Feder-506861.html.
[12] Bender, Todd K.: Literary Texts in Electronic Storage: The Editorial Potential. In: Computers and the Humanities, Band 10, Seiten
193–199, 1976.
[13] Bennett, William Ralph: Scientific and Engineering Problemsolving with the Computer. Prentice Hall, Aug. 1976.
[14] Bird, Steven und Mark Liberman: A Formal Framework for
Linguistic Annotation. Speech communication, 33(1-2):23–60, 2001.
ftp://ftp.cis.upenn.edu/pub/sb/sact/bird/annotation.pdf.
[15] Bizer, Christian und Christian Becker: Semantische Mashups
auf Basis des Linked Data Web. In: Hengartner, Urs und Andreas
Meier (Herausgeber): Web 3.0 & Semantic Web: HMD - Praxis der
Wirtschaftsinformatik, Band 271, Seiten 59–69. dpunkt Verlag, Heidelberg, 1. Auflage, Jan. 2010.
[16] Bonifati, Angela und Stefano Ceri: Comparative analysis of five
XML query languages. SIGMOD Rec., 29(1):68–79, 2000. http://dns2.
icar.cnr.it/angela/pubs/sigrec00.pdf.
[17] Bosworth, Adam: Serializing Graphs of Data in XML. In: XML
Europe ’99 Conference, Seiten 27–38. Granada, Spanien, 1999. http:
//www.infoloom.com/gcaconfs/WEB/granada99/bos.HTM.
[18] Box, Skonnard und Lam: Essential XML. Addison-Wesley, 1. Auflage, Feb. 2001.
[19] Bürger, Erich (Herausgeber): Technik-Wörterbuch. Data Processing. Computers. Office Machines - Datenverarbeitung. Rechner. Büromaschinen. VEB Verlag TECHNIK, 1969.
139
[20] Brüggemann-Klein, Anne: Formal Models in Document Processing. Habilitation, Institut für Informatik, Universität Freiburg,
Freiburg, 1993. ftp://ftp.informatik.uni-freiburg.de/documents/papers/
brueggem/habil.ps.
[21] Böttcher, Stefan, Rita Hartel und Christian Heinzemann:
BSBC: Towards a Succinct Data Format for XML Streams. In:
Cordeiro, Jose, Joaquim Filipe und Slimane Hammoudi
(Herausgeber): WEBIST 2008, Proceedings of the Fourth International Conference on Web Information Systems and Technologies, Volume 1, Seiten 13–21, Madeira, Portugal, Mai 2008. INSTICC Press. http://www.cs.uni-paderborn.de/fileadmin/Informatik/
AG-Boettcher/Lehre/WS_08_09/dbis1/Papers/Webist88.pdf.
[22] Cajori, Florian: Cajori’s A History of Mathematical Notations:
Notations in Elementary Mathematics., Band 1. Open Court, 1928.
[23] Carletta, Jean, Jonathan Kilgour, Timothy J. O’Donnell,
Stefan Evert und Holger Voormann: The NITE Object Model
Library for Handling Structured Linguistic Annotation on Multimodal Data Sets. In: Proceedings of the EACL Workshop on Language
Technology and the Semantic Web (3rd Workshop on NLP and XML,
NLPXML-2003), Apr. 2003. http://www.ims.uni-stuttgart.de/projekte/
corplex/paper/evert/CarlettaEtal2003.pdf.
[24] Chatti, Noureddine, Sylvie Calabretto und Jean-Marie Pinon: Vers un environnement de gestion de documents à structures
multiples. In: 20ème Journées BDA, Seiten 47–64, Montpellier, Frankreich, Okt. 2004.
[25] Chatti, Noureddine, Souha Kaouk, Sylvie Calabretto und
Jean-Marie Pinon: MultiX: an XML-based formalism to encode
multi-structured documents. In: Proceedings of Extreme Markup Languages 2007, Montréal, Kanada, Aug. 2007. http://citeseerx.ist.psu.
edu/viewdoc/download?doi=10.1.1.115.1525&rep=rep1&type=pdf.
[26] Chaudhuri, Surajit und Kyuseok Shim: Storage and Retrieval of
XML Data Using Relational Databases. In: VLDB ’01: Proceedings
of the 27th International Conference on Very Large Data Bases, Seite
730, San Francisco, CA, USA, 2001. Morgan Kaufmann Publishers
Inc.
[27] Chen, Peter Pin-Shan: The entity-relationship model—toward a
unified view of data. ACM Trans. Database Syst., 1(1):9–36, 1976.
[28] Codd, E. F.: The Relational Model for Database Management: Version 2. Addison Wesley Publishing Company, Apr. 1990.
140
[29] Collins, A. und M. Quillian: Retrieval time from semantic memory. Journal of Verbal Learning and Verbal Behavior, 8(2):240–247,
Apr. 1969.
[30] Comte, Auguste: Plan des travaux scientifiques necessaires pour
reorganiser la societe. Les Éditions Aubier-Montaigne, Paris, Frankreich, Okt. 1822. http://classiques.uqac.ca/classiques/Comte_auguste/
plan_des_travaux/plan_des_travaux.pdf.
[31] Coombs, James H., Allen H. Renear und Steven J. DeRose:
Markup systems and the future of scholarly text processing. Commun.
ACM, 30(11):933–947, 1987. http://www.fdi.ucm.es/profesor/jlsierra/
e-learning/primera-sesion/MarkupSystems.pdf.
[32] Cover, Robin: XML Applications and Initiatives. OASIS Cover
Pages, Apr. 2005. http://xml.coverpages.org/xmlApplications.html.
[33] Daniela Goecke, Harald Lüngen, Dieter Metzing
Maik Stührenberg: Different views on concurrent markup.
Distinguishing levels and layers. In: Metzing, Dieter und Andreas Witt (Herausgeber): Linguistic Modeling of Information and
Markup Languages. Contributions to Language Technology. Series
Text, Speech and Language Technology, Dordrecht, Niederlande, 2009.
Springer.
[34] DeRose, Steven J.: Markup Overlap: A Review and a Horse. In:
Extreme Markup Languages, Aug. 2004. http://xml.coverpages.org/
DeRoseEML2004.pdf.
[35] DeRose, Steven J., David G. Durand, Elli Mylonas und Allen H. Renear: What is text, really? Journal of Computing in
Higher Education, 1(2):3–26, Dez. 1990. http://antonietta.philo.unibo.
it/IUcorso2006-07/risorse/ohco.pdf.
[36] Durand, David G., Elli Mylonas und Steven J. Derose:
What Should Markup Really Be? Applying theories of text to
the design of markup systems, 1996. http://xml.coverpages.org/
DurandWhatShouldTextBe-ALLC1996.pdf.
[37] Durusau, Patrick und Matthew Brook O’Donnell: Coming
down from the trees. Next step in the evolution of markup? In: Extreme
Markup Languages Conference, Montréal, Kanada, Aug. 2002.
[38] Durusau, Patrick und Matthew Brook O’Donnell: Concurrent Markup for XML Documents. In: Proceedings of XML Europe, Atlanta, GA, USA, 2002. https://ssl.bnt.com/idealliance/papers/xmle02/
dx_xmle02/papers/03-03-07/03-03-07.pdf.
141
[39] Elam, Kimberly: Typografische Systeme: Regeln zur Organisation
von Schrift. Princeton Architectural Press, 1. Auflage, Jun. 2009.
[40] English, Joe: CDATA Confusion, Sep. 1997. http://www.flightlab.
com/~joe/sgml/cdata.html.
[41] Ernst, Daniel J., Daniel E. Stevenson und Paul J. Wagner:
Hybrid and custom data structures: evolution of the data structures
course. SIGCSE Bull., 41(3):213–217, 2009. http://www.cs.uwec.edu/
~ernstdj/Papers/hybrid.pdf.
[42] Farreres, Javier: The DSSSL Book: An XML/SGML Programming Language. Springer, 1. Auflage, Sep. 2003.
[43] Firesmith, Donald: Inheritance Guidelines. JOOP - Journal of
Object-Oriented Programming, 8(2):67–72, 1995.
[44] Fischer, Peter und Peter Hofer: Lexikon der Informatik. Springer, Berlin, 14. Auflage, Okt. 2007.
[45] Fischer, Steven Roger: A History of Writing. Reaktion Books,
Apr. 2004.
[46] Flynn, Peter: Why writers don’t use XML. The usability of editing
software for structured documents. In: Extreme Markup Languages
Conference, Montréal, Kanada, Aug. 2009. http://www.balisage.net/
Proceedings/vol3/html/Flynn01/BalisageVol3-Flynn01.html.
[47] Francopoulo, Gil, Nuria Bel, Monte George, Nicoletta
Calzolari, Monica Monachini, Mandy Pet und Claudia Soria: Lexical Markup Framework (LMF) for NLP multilingual resources. In: MLRI ’06: Proceedings of the Workshop on Multilingual
Language Resources and Interoperability, Seiten 1–8, Morristown, NJ,
USA, 2006. Association for Computational Linguistics.
[48] Freese, Eric: Multi-channel eBook production as a function of diverse target device capabilities. In: Proceedings of Balisage: The Markup Conference, Montréal, Kanada, Aug. 2010. http://www.balisage.
net/Proceedings/vol5/html/Freese01/BalisageVol5-Freese01.html.
[49] Freytag, Asmus und Martin Dürst: Unicode in XML and other
Markup Languages. W3C Note, W3C, Mai 2007. http://www.w3.org/
TR/2007/NOTE-unicode-xml-20070516.
[50] Furuta, R.: Concepts and models for structured documents. Seiten
7–38, 1989.
[51] Gehle, Christian: EDI in Industrie und Handel. GRIN Verlag,
2000.
142
[52] Geneves, Pierre: Logics for XML. VDM Verlag, Sep. 2009.
[53] Gettert, Hans: Syntax zwischen Hierarchie und Linearität. Shaker
Verlag, Aachen, Apr. 1998.
[54] Goldbarth, Albert: Pieces of Payne: A Novel. Graywolf Press, 1.
Auflage, Apr. 2003.
[55] Goldfarb, C. F.: A generalized approach to document markup. SIGPLAN Not., 16(6):68–73, 1981.
[56] Gribov, Dmitry: FictionBook 2.0 Specification. Technischer Bericht,
Mai 2004. http://www.gribuser.ru/xml/fictionbook/index.html.en.
[57] Göttler, Herbert: Graphgrammatiken in der Softwaretechnik: Theorie und Anwendungen, Band 178 der Reihe InformatikFachberichte. Springer, Berlin, 1. Auflage, Sep. 1988.
[58] Guitton, Pedro: A homage to Typography. Gingko Press, Barcelona, Spanien, Apr. 2010.
[59] Harold, Elliotte Rusty: The future of XML. How will you
use XML in years to come?, Feb. 2008. http://www.ibm.com/
developerworks/library/x-xml2008prevw.html.
[60] Harold, Elliotte Rusty und W. Scott Means: XML in a Nutshell. Deutsche Ausgabe. O’Reilly, 3. Auflage, Jan. 2005.
[61] Hartmann, Frank: Medienphilosophie. UTB, Stuttgart, Jan. 2000.
[62] Haugen, Odd Einar: Parallel Views: Multi-level Encoding of Medieval Nordic Primary Sources. Literary and Linguistic Computing,
19(1):73–Ű91, 2004.
[63] Herczeg, Michael: Software-Ergonomie. Grundlagen der MenschComputer-Kommunikation. Oldenbourg, 2. Auflage, 2005.
[64] Herwijnen, Eric Van: Practical SGML. Springer, Berlin, 4. Auflage, Jan. 1994.
[65] Hiebel, Friedrich: Christian Morgenstern, Wende und Aufbruch
unseres Jahrhunderts. A. Francke Verlag, Bern, Schweiz, 1957.
[66] Hilbert, Mirco: MuLaX - Ein Modell zur Verarbeitung mehrfach
XML-strukturierter Daten. Diplomarbeit, Technische Fakultät, Universität Bielefeld, Jan. 2005.
143
[67] Hilbert, Mirco, Andreas Witt und Oliver Schonefeld: Making CONCUR work. In: Extreme Markup Languages 2005, Montréal,
Kanada, Aug. 2005. http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.104.634&rep=rep1&type=pdf.
[68] Howe, David: Data Analysis for Database Design. ButterworthHeinemann, 3. Auflage, Jun. 2001.
[69] Huffman, D. A.: A Method for Construction of Minimum Redundancy Codes. In: Proc. of the IEEE, Band 40, Seiten 1098–1101, 1952.
[70] Hug, Theo: Wie kommt Wissenschaft zu Wissen?, 4 Bde., Bd.4,
Einführung in die Wissenschaftstheorie und Wissenschaftsforschung,
Seite 121. Schneider Verlag Hohengehren, 2001.
[71] Huitfeldt, Claus: MECS: a multi-element code system. In: Working Papers from the Wittgenstein Archives at the University of Bergen, Bergen, Norwegen, 1992. http://helmer.hit.uib.no/claus/mecs/
mecs.htm.
[72] Huitfeldt, Claus und C. M. Sperberg-McQueen: TexMECS:
An experimental markup meta-language for complex documents, Jan.
2001. http://decentius.aksis.uib.no/mlcd/2003/Papers/texmecs.html.
[73] Iacob, Ionut Emil und Alex Dekhtyar: Parsing concurrent
XML. In: WIDM ’04: Proceedings of the 6th annual ACM international workshop on Web information and data management, Seiten 23–30,
Washington, DC, USA, Nov. 2004. http://eppt.org/~emil/publications/
WIDM04.pdf.
[74] Iacob, Ionut Emil und Alex Dekhtyar: Towards a Query Language for Multihierarchical XML: Revisiting XPath. In: Doan, AnHai, Frank Neven, Robert McCann und Geert Jan Bex (Herausgeber): WebDB: Proceedings of the Eight International Workshop
on the Web & Databases, Seiten 49–54, Baltimore, MD, USA, Jun.
2005. http://webdb2005.uhasselt.be/webdb05_eproceedings.pdf.
[75] Ide, Nancy und Keith Suderman: Integrating linguistic resources:
The american national corpus model. In: Proceedings of the 6th International Conference on Language Resources and Evaluation, 2006.
http://www.cs.vassar.edu/~ide/papers/ANC-LREC06.pdf.
[76] Idehen, Kingsley Uyi: Data Structures and RDF. http://www.
openlinksw.com-WEBLOG, OpenLink Software, Inc., Lexington, MA,
USA, Mai 2003.
144
[77] Ishida, Richard:
Authoring HTML: Handling Right-to-left
Scripts.
W3C Note, Sep. 2009.
http://www.w3.org/TR/2009/
NOTE-i18n-html-tech-bidi-20090908.
[78] Iverson, Kenneth E.: Notation as a Tool of Thought. Commun. ACM, 23(8):444–465, 1980. http://www.jdl.ac.cn/turing/pdf/
p444-iverson.pdf.
[79] Jagadish, H. V., Shurug Al-Khalifa, Adriane Chapman, Laks
V. S. Lakshmanan, Andrew Nierman, Stelios Paparizos, Jignesh M. Patel, Divesh Srivastava, Nuwee Wiwatwattana,
Yuqing Wu und Cong Yu: TIMBER: A native XML database. The
VLDB Journal, 11(4):274–291, Dez. 2002. http://www.comp.nus.edu.
sg/~cs5220/papers/timber.pdf.
[80] Jagadish, H. V., Divesh Srivastava, Laks V. S. Lakshmanan,
Monica Scannapieco und Nuwee Wiwatwattana: Colorful
XML: One hierarchy isnt enough. In: Proceedings of the 2004 ACM
SIGMOD International Conference on Management of Data. Paris,
France, Seiten 251–262, Jun. 2004. http://www.eecs.umich.edu/db/
timber/files/mct.pdf.
[81] Jakobs, Kai: IT Normen und Standards - Grundlage der Informationsgesellschaft. http://www-i4.informatik.rwth-aachen.de/~jakobs/
Papers/VDI.pdf, 2002. RWTH Aachen, Informatik IV.
[82] Jan Walker, Eric Pan, Douglas Johnston Julia AdlerMilstein David W. Bates Blackford Middleton: The Value Of
Health Care Information Exchange And Interoperability. Health Affairs, 10.1377, Jan. 2005. http://content.healthaffairs.org/cgi/reprint/
hlthaff.w5.10v1.pdf.
[83] Jaromczyk, J. W. und N. Moore: Geometric data structures for
multihierarchical XML tagging of manuscripts. In: Proc. 18th European Workshop on Computational Geometry, Sevilla, Spanien, Mär.
2004.
[84] Kaczmarek, Alexander: GXL-Validator. Validierung von GXLDokumenten auf Instanz-, Schema, und Metaschema-Ebene. Studienarbeit, Universität Koblenz, Koblenz, Sep. 2003. http://www.
uni-koblenz.de/~ist/documents/kaczmarek2003sa.pdf.
[85] Klettke, Meike und Holger Meyer: XML & Datenbanken. Konzepte, Sprachen und Systeme. Dpunkt Verlag, 1. Auflage, Nov. 2002.
[86] Koller, Micha: Java Architecture for XML Binding. Studienarbeit, Hochschule Esslingen, 2008. http://ww2624.awi2.de/jaxb/
studienarbeit.pdf.
145
[87] Konferenz: Balisage - The Markup Conference. http://www.
balisage.net, 2009. Mulberry Technologies Inc., Montréal, Canada.
[88] Kremp, Matthias: Wer die meisten Server hat. Online, Apr.
2010. http://www.spiegel.de/netzwelt/gadgets/0,1518,689123,00.html,
[Online; Stand 15.10.2010].
[89] Kreowski, Hans-Jörg, Renate Klempien-Hinrichs und Sabine
Kuske: Some Essentials of Graph Transformation. In: Ésik, Zoltán, Carlos Martín-Vide und Victor Mitrana (Herausgeber):
Recent Advances in Formal Languages and Applications, Band 25
der Reihe Studies in Computational Intelligence, Seiten 229–254.
Springer, 2006. http://www.sfb637.uni-bremen.de/pubdb/repository/
SFB637-A4-06-002-IA.pdf.
[90] Kuhn, Thomas S.: Suhrkamp Taschenbücher Wissenschaft, Nr.25,
Die Struktur wissenschaftlicher Revolutionen. Suhrkamp, Jan. 2002.
[91] Kunert, Andreas: LR(k)-Analyse fĺur Pragmatiker. HumboldtUniversität - Institut fĺur Informatik, Berlin, Apr. 2008. http://www2.
informatik.hu-berlin.de/~kunert/papers/lr-analyse/lr.pdf.
[92] Lamport, Leslie: Das LaTeX-Handbuch. Addison-Wesley, 3. Auflage, Jun. 1995.
[93] Lee, Dongwon und Wesley W. Chu: Comparative analysis of six
XML schema languages. SIGMOD Rec., 29(3):76–87, 2000. http:
//wam.inrialpes.fr/people/roisin/mw2004/Lee.pdf.
[94] Lee, Marshall: Book making: The illustrated guide to design and
production. Bowker, 1966.
[95] Lüngen, H. und A. Witt: Multi-dimensional markup: N-way relations as a generalisation over possible relations between annotation
layers. Oulu, Finnland, 2008.
[96] Luk, Robert W. P., Hong Va Leong, Tharam S. Dillon, Alvin
T. S. Chan, W. Bruce Croft und James Allan: A survey in
indexing and searching XML documents. Journal of the American
Society for Information Science and Technology (JASIST), 53(6):415–
437, 2002.
[97] March, S. und G. Smith: Design and Natural Science Research on
Information Technology. Decision Support Systems, 15:258, 1995.
[98] Marinelli, Paolo, Fabio Vitali und Stefano Zacchiroli: Towards the unification of formats for overlapping markup. New Review
of Hypermedia and Multimedia, 14:57–94, Jan. 2008. http://upsilon.
cc/~zack/research/publications/nrhm-overlapping-conversions.pdf.
146
[99] Mauthner, Fritz: Beiträge zu einer Kritik der Sprache. J.G. Cotta
Verlag, Stuttgart, 1902.
[100] McKelvie, D., C. Brew und H. S. Thompson: Using SGML as a
Basis for Data-Intensive Natural Language Processing. In: Computers
and the Humanities, Band 31, Seiten 367–388, 1999. http://ww2.cs.
mu.oz.au/acl/A/A97/A97-1034.pdf.
[101] Megginson, David: Imperfect XML: Rants, Raves, Tips, and Tricks
... from an Insider (illustrated edition). Addison-Wesley Longman,
Amsterdam, Feb. 2005.
[102] Mintert, Stefan: Schlüsselqualifikation – XML jenseits des Mainstream. iX, 0935-9680:48–51, Aug. 2005. http://www.heise.de/kiosk/
archiv/ix/2005/8/48.
[103] Müldner, Tomasz, Christopher Fry, Jan Krzysztof Miziolek und Scott Durno: XSAQCT: XML Queryable Compressor. In:
Proceedings of Balisage: The Markup Conference 2009. Balisage Series on Markup Technologies, Band 3 der Reihe Balisage Series on
Markup Technologies, Montréal, Kanada, Aug. 2009.
[104] Müller, Wolfgang (Herausgeber): Duden: Die sinn- und sachverwandten Wörter: 8 - Die Sinn- Und Sachverwandten Worter. Bibliographisches Institut, Mannheim, 2. Auflage, Okt. 1997.
[105] Morice, Dave Morice: The Dictionary of Wordplay. Teachers &
Writers Collaborative, 1. Auflage, Jan. 2001.
[106] Mössenböck, Hanspeter: The Compiler Generator Coco/R. Johannes Kepler University, Linz, Österreich, 2006. http://www.ssw.
uni-linz.ac.at/Research/Projects/Coco/Doc/UserManual.pdf.
[107] Musciano, Chuck und Bill Kennedy: HTML & XHTML: The
Definitive Guide. O’Reilly Media, 6. Auflage, Okt. 2006.
[108] Myers, Greg und Geoffrey N. Leech: Spoken English on Computer: Transcription, Mark-Up, and Application. Longman, Jul. 1995.
[109] Naumann, Sven und Hagen Langer: Parsing. Eine Einführung in
die maschinelle Analyse natürlicher Sprache. Teubner Verlag, 1994.
[110] Nebelo, Ralf: Text-Maschinen - Elf Editoren für Programmierer
und Autoren. c’t magazin für computer technik, 23:138–145, Okt.
2009.
[111] Nevill-Manning, Craig, Ian und I. Witten: Compression
and Explanation using Hierarchical Grammars. Computer Journal,
40:103–116, 1997. http://eprints.kfupm.edu.sa/31233/1/31233.pdf.
147
[112] Nevill-Manning, Craig G.: Inferring Sequential Structure. Doktorarbeit, University of Waikato, Mai 1996. http://www.sequitur.info/
Nevill-Manning.pdf.
[113] Ng, Wilfred, Wai Yeung Lam und James Cheng: Comparative
Analysis of XML Compression Technologies. World Wide Web, 9(1):5–
33, 2006.
[114] Noltemeier, Hartmut: Graphentheoretische Konzepte und Algorithmen. B.G. Teubner Verlag, Mai 2005.
[115] Orlowski, Andrew: Bruce Lindsay on Codd’s relational legacy. The
Register, Apr. 2003. http://www.theregister.co.uk/2003/04/25/bruce_
lindsay_on_codds_relational.
[116] Parfitt, Rick: VoiceXML. Manning Publications, Jun. 2002.
[117] Parma, Bernardo da: Apparatus ad Decretales Gregorii IX. (glossa
ordinaria). Universität Bologna, Bologna, Italien, 1300–1315. Sprache:
Latein.
[118] Pfister, Beat und Tobias Kaufmann: Sprachverarbeitung:
Grundlagen und Methoden der Sprachsynthese und Spracherkennung.
Springer, 1. Auflage, Mär. 2008.
[119] Piez, Wendell: Half-steps toward LMNL. In: Extreme Markup Languages Conference, Montréal, Kanada, Aug. 2004. http://www.piez.
org/wendell/papers/LMNL-halfsteps.pdf.
[120] Pondorf, Denis: Entwicklung eines XSD-Generators. Diplomarbeit,
Universität Bremen, Mai 2003.
[121] Porter, Brad, Scott McGlashan, David Burke, Daniel C.
Burnett, Emily Candell, RJ Auburn, Paolo Baggia, Jerry
Carter, Ken Rehor, Matt Oshra, Michael Bodell und Alex
Lee: Voice Extensible Markup Language (VoiceXML) 2.1. W3C
Recommendation, W3C, Dez. 2009. http://www.w3.org/TR/2009/
WD-voicexml30-20091203.
[122] Poullet, Line, Jean-Marie Pinoin und Sylvie Calabretto:
Semantic Structuring Of Documents. Basque International Workshop
on Information Technology, Seite 118, 1997.
[123] Prescod, Paul: From markup to object model. The XML abstraction problem and XML property objects. In: XML EUROPE 2000, Paris, Frankreich, Jun. 2000. ISOGEN Inc. http://www.gca.org/papers/
xmleurope2000/pdf/s12-02.pdf.
148
[124] Psaila, Giuseppe: From XML DTDs to Entity-Relationship Schemas. In: Lecture Notes in Computer Science, Band 2814/2003, Seiten
378–389. Springer Berlin / Heidelberg, Sep. 2003.
[125] Quint, Vincent, Marc Nanard und Jacques André: Towards
Document Engineering. In: Furuta, R. (Herausgeber): Proceedings of
the International Conference on Electronic Publishing, Document Manipulation & Typography, Gaithersburg, Maryland, September 1990,
Seiten 17–29, New York, NY, USA, 1990. Cambridge University Press.
[126] Raymond, D. R. und F. W Tompa: Markup reconsidered. Technischer Bericht 356, Department of Computer Science, The University of Western Ontario, 1993. Presented at the First International
Workshop on the Principles of Document Processing, Washinton DC,
October 21-23 1992, http://www.oasis-open.org/cover/raymmark.ps.
[127] Rebane, George und Judea Pearl: The Recovery of Causal PolyTrees from Statistical Data. In: UAI, Seiten 175–182, Los Angeles, CA, USA, 1987. http://ftp.cs.ucla.edu/tech-report/198_-reports/
870031.pdf.
[128] Reid, Brian: 20 years of abstract markup - Any progress? In: Markup
Technologies ’98 Conference, Nov. 1998. http://www.reid.org/~brian/
markup98.ppt.
[129] Reid, Brian K.: Scribe: A Document Specification Language and its
Compiler. Doktorarbeit, Carnegie Mellon University, Pittsburgh, PA,
USA, Okt. 1980.
[130] Renear, Allen, Elli Mylonas und David Durand: Refining our
Notion of What Text Really Is: The Problem of Overlapping Hierarchies. In: Ide, N. und S. Hockey (Herausgeber): Research in
Humanities Computer, Oxford, Großbritannien, 1993. Oxford University Press. http://www.ideals.illinois.edu/bitstream/handle/2142/9407/
RefiningOurNotion.pdf.
[131] Riehm, Ulrich, Knud Böhle, Ingrid Gabel-Becker und Ingrid
Gabel-Becker: Elektronisches Publizieren. Eine kritische Bestandsaufnahme. Springer Verlag, Berlin, 1992.
[132] Ritter, Joachim (Herausgeber): Historisches Worterbuch der Philosophie. Schwabe & Co, Basel, Schweiz, 1974.
[133] Salomon, David: Data Compression: The Complete Reference.
Springer, Berlin, 4. Auflage, Dez. 2006.
149
[134] Sander, Peter, Wolffried Stucky und Rudolf Herschel:
Grundkurs Angewandte Informatik, in 4 Bdn., Bd.4, Automaten,
Sprachen, Berechenbarkeit. Vieweg+Teubner, 2. Auflage, 1995.
[135] Schüler, Peter: Schriftwechsel mit Format. c’t magazin für computer technik, 21:154–156, Sep. 2009.
[136] Schmidt, Desmond und Robert Colomb: A data structure for representing multi-version texts online. Int. J. Hum.-Comput. Stud.,
67(6):497–514, 2009. http://www.itee.uq.edu.au/~schmidt/_articles/
elsevier.pdf.
[137] Schneider, Hans-Jochen (Herausgeber): Lexikon der Informatik
und Datenverarbeitung. R.Oldenbourg Verlag, München, 3. Auflage,
1991.
[138] Schneider, Hans-Jürgen: Problemorientierte Programmiersprachen. B. G. Teubner, Stuttgart, 1981.
[139] Scholze-Stubenrecht, Werner (Herausgeber): Der Duden, Band
1: Die deutsche Rechtschreibung. Bibliographisches Institut, Mannheim, 22. Auflage, Jul. 2000.
[140] Schonefeld, Oliver: Mascarpone und XML-CONCUR. Ein Editor
und ein Verarbeitungsmodell für multi-strukturierte Daten. Diplomarbeit, Universität Bielefeld, Sep. 2005. http://www.xconcur.org/papers/
diplomarbeit-final.pdf.
[141] Schonefeld, Oliver:
XCONCUR and XCONCUR-CL: A
constraint-based approach for the validation of concurrent markup. In:
Rehm, Georg, Andreas Witt und Lothar Lemnitzer (Herausgeber): Datenstrukturen für linguistische Ressourcen und ihre Anwendungen: Proceedings of the Biennial GLDV Conference, Seiten 347–
356. Tübingen Verlag, 2007.
[142] Schonefeld, Oliver: An event-centric API for processing concurrent markup. In: Proceedings of Balisage: The Markup Conference,
Montréal, Kanada, Aug. 2008. http://dx.doi.org/10.4242/BalisageVol1.
Schonefeld01.
[143] Schonefeld, Oliver und Andreas Witt: Towards validation of
concurrent markup. In: Proceedings of Balisage: The Markup Conference, Montréal, Kanada, Aug. 2006. http://citeseerx.ist.psu.edu/
viewdoc/download?doi=10.1.1.104.1796&rep=rep1&type=pdf.
[144] Schraitle, Thomas: DocBook-XML: Medienneutrales und plattformunabhängiges Publizieren. Millin, 2. Auflage, Aug. 2009.
150
[145] Sengupta, Arijit und Sriram Mohan: Formal and Conceptual
Models for XML Structures — The Past, Present, and Future. Technischer Bericht 137-1, Indiana University, Information Systems Department, Bloomington, IN, USA, Apr. 2003. http://www.ag-nbi.de/
archiv/www.indiana.edu/_isdept/research/papers/tr137-1.pdf.
[146] Shannon, Claude E. und Warren Weaver: Mathematical Theory
of Communication 1st Edition. UNIV OF IL AT URBA, 1949.
[147] Sharon Adler, Roberta Cochrane, John F. Morar Alfred Spector: Technical context and cultural consequences of
XML. IBM SYSTEMS JOURNAL ’Celebrating 10 Years of XML’,
45(2):207–223, Jun. 2006.
http://www.research.ibm.com/journal/
sj45-2.html.
[148] Shillingsburg, Peter L.: From Gutenberg to Google: Electronic
Representations of Literary Texts. Cambridge University Press, 1.
Auflage, Sep. 2006.
[149] Software-AG: INTERIMREPORT, Jun. 2000.
http://www.
softwareag.com/corporate/images/e_hgb_tcm16-5750.pdf.
[150] Software AG: Tamino XML Schema Reference Guide. Spezifikation
Version 8.0, Darmstadt, Nov. 2009. http://documentation.softwareag.
com/webmethods/wmsuite8_ga/Tamino/print/tslref.pdf.
[151] Sperberg-McQueen, C. M.: Rabbit/duck grammars: a validation
method for overlapping structures. In: Proceedings of Balisage: The
Markup Conference, Montréal, Kanada, Aug. 2006.
[152] Sperberg-McQueen, C. M. und Claus Huitfeldt: GODDAG: A
Data Structure for Overlapping Hierarchies. In: King, Peter R. und
Ethan V. Munson (Herausgeber): DDEP/PODDP, Seiten 139–160.
Springer, Sep. 2000. http://decentius.aksis.uib.no/mlcd/2000/Papers/
Goddag.pdf.
[153] Sperberg-McQueen, C. M. und Claus Huitfeldt: Markup Discontinued: Discontinuity in TexMecs, Goddag structures, and rabbit/duck grammars. In: Proceedings of Balisage: The Markup Conference, Montréal, Kanada, Aug. 2008. http://dx.doi.org/10.4242/
BalisageVol1.Sperberg-McQueen01.
[154] Sperberg-McQueen, C. Michael und Lou Burnard: TEI P5:
Guidelines for Electronic Text Encoding and Interchange. Technischer
Bericht, The Text Encoding Initiative Consortium, Jul. 2009. http:
//www.tei-c.org/release/doc/tei-p5-doc/en/Guidelines.pdf.
151
[155] Sperberg-McQueen, C.M.: Textual Criticism and the Text Encoding Initiative. In: Finneran, R.J. und Ann Arbor (Herausgeber):
The Literary Text in the Digital Age, Seiten 37–61, Ann Arbor, MI ,
USA, 1996. University of Michigan Press.
[156] Stefan Evert, Jean Carletta, Timothy J. O’Donnell Jonathan Kilgour Andreas Vögele Holger Voormann: The
NITE Object Model (Version 2.1), Universität Stuttgart, Mär. 2003.
http://www.ltg.ed.ac.uk/NITE/documents/NiteObjectModel.v2.1.pdf.
[157] Stührenberg, Maik und Daniela Goecke: SGF - An integrated model for multiple annotations and its application in a linguistic domain. In: Proceedings of Balisage: The Markup Conference,
Montréal, Kanada, Aug. 2008. http://dx.doi.org/10.4242/BalisageVol1.
Stuehrenberg01.
[158] Stührenberg, Maik und Daniel Jettka: A toolkit for multidimensional markup: The development of SGF to XStandoff. In:
Proceedings of Balisage: The Markup Conference, Montréal, Kanada,
Aug. 2009. http://dx.doi.org/10.4242/BalisageVol3.Stuhrenberg01.
[159] Stührenberg, Maik, Andreas Witt, Daniela Goecke, Dieter Metzing und Oliver Schonefeld: Multidimensional Markup
and Heterogeneous Linguistic Resources. In: Proceedings of the 5th
Workshop on NLP and XML (NLPXML-2006): Multi-Dimensional
Markup in Natural Language Processing. April 4, 2006., Seiten 85–88,
Trient, Italien, Apr. 2006. http://acl.ldc.upenn.edu/eacl2006/ws11_
nlpxml.pdf.
[160] Stilo International PLC: The OmniMark Content Processing
Platform. DATASHEET, Swindon, Großbritannien, Jun. 2008. http:
//www.stilo.com/Portals/0/Omnimark_Data_sheet_Final.pdf.
[161] Stonebraker, Michael und Dorothy Moore: Object-Relational
DBMSs, Second Edition (The Morgan Kaufmann Series in Data Management Systems). Morgan Kaufmann, 2. Auflage, Aug. 1998.
[162] Stricker, Rolf Bergmann; Stefanie (Herausgeber): Katalog Der
Althochdeutschen Und Altsächsischen Glossenhandschriften. Walter
De Gruyter Inc, Berlin, New York, Aug. 2005.
[163] Strohmaier, Christian: XML-Strukturakquisition. Informatik
Spektrum, August 2002:1–4, 2002. http://www.cis.uni-muenchen.de/
people/strohmaier/Publications/1m0242_schlag.1.pdf.
[164] Taentzer, Gabriele und Giovanni Toffetti Carughi: A
Graph-Based Approach to Transform XML Documents. In: Fundamental Approaches to Software Engineering, Band 3922 der
152
Reihe LNCS, Seiten 48–62, Berlin, Heidelberg, Mär. 2006.
Springer. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.
91.6006&rep=rep1&type=pdf.
[165] Tennison,
Jeni:
Creole:
Validating overlapping markup.
In: XTech 2007:
The ubiquitous web conference,
2007.
http://assets.expectnation.com/15/event/1/Creole_
ValidatingOverlappingMarkup_PrincePDFversion_.pdf.
[166] Tennison, Jeni und Wendell Piez: The Layered Markup and Annotation Language (LMNL). In: Extreme Markup Languages Conference, Montréal, Kanada, Aug. 2002. http://xml.coverpages.org/
LMNL-Abstract.html.
[167] Teufel, Marc: XWT - Deklarative UIs mit Eclipse. Eclipse Magazin, 2.10:19–24, Feb. 2010.
[168] Thompson, Henry S. und David McKelvie: Hyperlink semantics
for standoff markup of read-only documents. In: Proceedings of SGML
Europe ’97: The Next Decade - Pushing the Envelope, Barcelona, Spanien, Mai 1997. http://www.ltg.ed.ac.uk/~ht/sgmleu97.html.
[169] Thurau, Carsten: Grafitti-Gangs in São Paulo. ZDF auslandjournal (Video: 04:48), Jan. 2010. http://www.zdf.de/ZDFmediathek/
beitrag/video/944090.
[170] Tichelen, Luc Van und David Burke:
Semantic Interpretation for Speech Recognition (SISR) Version 1.0.
Recommendation, W3C, Apr. 2007.
http://www.w3.org/TR/2007/
REC-semantic-interpretation-20070405.
[171] Tim Weitzel, Ralf Kronenberg, Frank Ladner Peter Buxmann: Die Rückkehr der EDI-Ritter, XML als Alternative zu traditionellem EDI. iX, 0935-9680:127, Jul. 1999. http://www.heise.de/kiosk/
archiv/ix/1999/7/127.
[172] Tzu, Lao: Tao Te Ching. Authorhouse, Okt. 2009.
[173] Vlist, Eric van der: XML Schema. O’Reilly, 1. Auflage, Jan. 2003.
[174] W3C: HyperText Markup Language Version 4.01. Specification REChtml401-19991224, Dez. 1999. http://www.w3.org/TR/html4.
[175] W3C: Web Services Description Language (WSDL) 1.1. Submission
Request NOTE-wsdl-20010315, Mär. 2001. http://www.w3.org/TR/
2001/NOTE-wsdl-20010315.
153
[176] W3C: Extensible HyperText Markup Language Version 1.0. Recommendation REC-xhtml1-20020801, Aug. 2002. http://www.w3.org/
TR/xhtml1.
[177] W3C: Scalable Vector Graphics (SVG) 1.1 Specification. Recommendation REC-SVG11-20030114, Jan. 2003. http://www.w3.org/TR/
SVG11.
[178] W3C: Document Object Model (DOM) Level 3 Core Specification Version 1.0. Recommendation REC-DOM-Level-3-Core-20040407, Apr.
2004. http://www.w3.org/DOM.
[179] W3C: XML Schema Part 0: Primer Second Edition. Recommendation REC-xmlschema-0-20041028, Okt. 2004. http://www.w3.org/
XML/Schema.
[180] W3C: XML Inclusions (XInclude) Version 1.0 (Second Edition). Recommendation REC-xinclude-20061115, Nov. 2006. http://www.w3.
org/TR/xinclude.
[181] W3C: XSL Formatting Objects (XSL-FO) Version 1.1. Recommendation REC-xsl11-20061205, Mai 2006. http://www.w3.org/TR/xsl.
[182] W3C: SOAP Version 1.2 Part 0: Primer (Second Edition). Recommendation REC-soap12-part0-20070427, Apr. 2007. http://www.w3.
org/TR/2007/REC-soap12-part0-20070427.
[183] W3C: XML Path Language (XPath) Version 2.0. Recommendation
REC-xpath20-20070123, Jan. 2007. http://www.w3.org/TR/xpath20.
[184] W3C: XQuery 1.0 and XPath 2.0 Data Model (XDM). Recommendation REC-xpath-datamodel-20070123/, Jan. 2007. http://www.w3.
org/TR/xpath-datamodel.
[185] W3C: XSL Transformations (XSLT) Version 2.0. Recommendation
REC-xslt20-20070123, Jan. 2007. http://www.w3.org/TR/xslt20.
[186] W3C: Extensible Markup Language (XML) 1.0 (Fifth Edition). Recommendation REC-xml-20081126, Nov. 2008. http://www.w3.org/
TR/xml.
[187] Wagner, Philipp: Business-to-Business-Integration von EDI hin zu
XML. Diplomarbeiten Agentur diplom.de, Jan. 2002.
[188] Walsh, Norman: Escaped Markup Considered Harmful. xml.com,
Aug. 2003. http://www.xml.com/pub/a/2003/08/20/embedded.html.
154
[189] Walsh, Norman: The DocBook Schema Version 5.0. Specification,
OASIS, Aug. 2008. http://docbook.org/specs/docbook-5.0-spec-cs-01.
html.
[190] Walsh, Norman und Leonard Muellner: DocBook: The Definitive Guide. O’Reilly Media, Inc., Okt. 1999.
[191] Wang, Xinxin und Derick Wood: Tabular Abstraction for Tabular Editing and Formatting. In: Proceedings of 3rd International
Conference for Young Computer Scientists, Seiten 17–29. Tsinghua
University Press, 1993. http://www.cs.ust.hk/faculty/dwood/tables/..
/preprints/table.ps.gz.
[192] Weerawarana, Sanjiva, Francisco Curbera, Frank Leymann, Tony Storey und Donald F. Ferguson: Web Services
Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing,
WS-BPEL, WS-Reliable Messaging, and More. Prentice Hall PTR,
Apr. 2005.
[193] Weitzel, Tim, Thomas Harder und Peter Buxmann: Electronic
Business und EDI mit XML. Dpunkt Verlag, 2001.
[194] Werner, Martin: Information und Codierung: Grundlagen und Anwendungen. Vieweg+Teubner, 2. Auflage, Sep. 2008.
[195] Wessel, Robert van: Realizing Business Benefits from Company IT
Standardization. Doktorarbeit, Universiteit van Tilburg, Nov. 2008.
http://arno.uvt.nl/show.cgi?fid=81118.
[196] Wikipedia: Freistil — Wikipedia, Die freie Enzyklopädie. Online, 2009. http://de.wikipedia.org/w/index.php?title=Freistil&oldid=
58624703, [Online; Stand 6.10.2009].
[197] Williams, William Proctor und Craig S. Abbott: An Introduction to Bibliographical and Textual Studies. Modern Language Association of America, 4. Auflage, Mai 2009.
[198] Winter, Andreas, Bernt Kullbach und Volker Riediger: An
Overview of the GXL Graph Exchange Language. Lecture Notes in
Computer Science, 2269:324–337, 2002. http://www.gupro.de/GXL/
Publications/winter+2002.pdf.
[199] Witt, Andreas: Multiple Informationsstrukturierung mit Auszeichnungssprachen. XML-basierte Methoden und deren Nutzen für die
Sprachtechnologie. Doktorarbeit, Universität Bielefeld; Fachbereich
Linguistik – Fakultät für Linguistik und Literaturwissenschaft, Nov.
2001. http://bieson.ub.uni-bielefeld.de/volltexte/2003/402/pdf/0007.
pdf.
155
[200] Witt, Andreas: Meaning and interpretation of concurrent markup. In: ALLC/ACH 2002, New directions in humanities computing.
The 14th Joint International Conference of the ALLC and ACH., Seiten 145–147. Tübingen, 2002. http://xml.coverpages.org/Witt-allc2002.
html.
[201] Witt, Andreas:
Multiple hierarchies:
new aspects of an
old solution.
In: Proceedings of Extreme Markup Languages,
2004. http://conferences.idealliance.org/extreme/html/2004/Witt01/
EML2004Witt01.html.
[202] Witt, Andreas: Guideline: Multiple Hierarchies. In: Burnard,
Lou, Milena Dobreva, Norbert Fuhr und Anke Lüdeling
(Herausgeber): Digital Historical Corpora - Architecture, Annotation,
and Retrieval, Nummer 06491 in Dagstuhl Seminar Proceedings, Dagstuhl, 2007. Internationales Begegnungs- und Forschungszentrum für
Informatik (IBFI). http://drops.dagstuhl.de/volltexte/2007/1040/pdf/
06491.WittAndreas.Paper.1040.pdf.
[203] Witt, Andreas, Harald Lüngen, Daniela Goecke und Felix
Sasaki: Unification of XML Documents with Concurrent Markup.
Literary and Linguistic Computing 20(1), Seiten 103–116, 2005.
[204] Witt, Andreas und Dieter Metzing (Herausgeber): Linguistic
Modeling of Information and Markup Languages: Contributions to
Language Technology (Text, Speech and Language Technology). Springer, 1. Auflage, Dez. 2009.
[205] Workshop: NLPXML: Multi-dimensional Markup in Natural Language Processing. http://ilps.science.uva.nl/nlpxml2006, 2006. European Association for Computational Linguistics.
[206] Yergeau, F.: UTF-8, a transformation format of ISO 10646, Jan.
1998. http://www.ietf.org/rfc/rfc2279.txt.
[207] Zemanek, Evi, Daniella Jancsó, Mary Ann Snyder-Körber,
Karin Peters, Johanna Schumm und Boris Previsic: Literatur
der Jahrtausendwende: Themen, Schreibverfahren und Buchmarkt um
2000. Transcript, 1. Auflage, Okt. 2008.
[208] Ziegler, Arne und Gabriel Altmann: Denotative Textanalyse.
Edition Praesens, 2002.
[209] Zipf, George Kingsley: Human Behavior and the Principle of
Least Effort. Addison-Wesley Publishing Co. Inc, 1949.
156
[210] Zubarik, Sabine: Paratexte: Fußnoten und Anmerkungen als textkonstituierende Bestandteile neuerer Erzählliteratur. Magisterarbeit,
Universität Erfurt, Erfurt, Mär. 2005. http://www.db-thueringen.de/
servlets/DerivateServlet/Derivate-6712/zubarik.pdf.
157
Anhang A
Beispiel-Szenario A
Ein dokumentenzentrisches Markup-Exempel wird vorgestellt. Das Szenario
wird beschrieben und die beiden korrespondierenden FML-Instanzen FMLDokument und FML-Graph werden präsentiert.
A.1
Szenario
Gegenstand des Exempels ist ein Bleiletterdruck-Unikat1 , in dem dekorative
Auszeichnungen verstärkt Anwendung finden.
Aus den vielfachen typographischen Gestaltungsmitteln wie Schriftart, -schnitt
oder -grad werden folgende ausgezeichnet:
1. Schriftfarbe rot (Tag-Name r)
2. Majuskelschrift (Tag-Name m)
3. Unterstreichung (Tag-Name u)
4. Schriftart “Handschrift“ (Tag-Name h)
5. Dokumentgrenzen (Tag-Name document)
1
Typowerkstatt Bodoni-Museum, Berlin. Erworben am 13.03.2009, Buchmesse Leipzig.
Nachträglich angereichert mit einer Unterstreichung.
158
159
A.2
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
FML-Dokument
<@fml.namespace.name="fc" fml.namespace.description="font-color">
<@fml.namespace.name="fs" fml.namespace.description="font-style">
<@fml.namespace.name="fd" fml.namespace.description="font-decoration">
<@fml.namespace.name="ff" fml.namespace.description="font-family">
<document><fs:m>i</fs:m>m
<fs:m>wunderschönen
monat m</fs:m>ai
<fs:m>a</fs:m>ls alle <fs:m>k</fs:m>nospen sprangen
<fs:m>d</fs:m>a ist <fd:u>in meinem <fs:m>herz</fd:u>en</fs:m>
<fc:r rgb="FF0000"><ff:h>die <fs:m>l</fs:m>iebe</ff:h></fc:r> aufgegangen
<fs:m>i</fs:m>m wunderschönen
<fs:m>monat m</fs:m>ai
<fs:m>a</fs:m>ls alle <fs:m>v</fs:m>ögel sangen,
<fs:m>d</fs:m>a
hab ich
ihr
<fs:m>ge</fs:m>stan<fs:m>den</fs:m>
<fs:m>m</fs:m>ein <fs:m>s</fs:m>ehnen
und <fs:m>v</fs:m>er-
lange
<<fc:r><fs:m>>n<</fc:r><fs:m>>
160
A.3
FML-Graph
161
A.4
Résumé
Anhand dieses Beispiels lassen sich mehrere Eigenschaften der Sprache FML
(s. Kapitel 10) prüfen:
1. Grammatik (s. Kap. 10.1)
Das FML-Dokument ist wohlgeformt gegenüber der FML-Grammatik 2 .
2. Kompatibilität (s. Kap. 10.2)
Der Grad der Ähnlichkeit gegenüber XML-Annotationen ist evident.
3. Monohierarchie (s. Kap. 10.3)
Monohierarchisches Markup wird wie in XML kodiert: Zeile 10.
4. Interferenz (s. Kap. 10.4)
Interferenzen werden intuitiv ausgezeichnet: Zeile 09.
5. Identifizierung (s. Kap. 10.5)
Die Identifizierung korrespondierender Tags erfolgt von links nach
rechts und von außen nach innen. Tag-IDs finden keine Anwendung.
6. Kongruenz (s. Kap. 10.6)
Kongruentes Markup wird erwartungsgemäß kodiert: Zeile 22.
7. Independenz (s. Kap. 10.7)
Es existiert genau eine Annotationsebene: die Default-Perspektive.
8. Segmentierung (s. Kap. 10.8)
Das Konzept der Segmentierung findet keine Anwendung.
9. Fragmentierung (s. Kap. 10.9)
Das End-Tag des Elementes document wird automatisch ergänzt.
10. Wildcard (s. Kap. 10.10)
Es existiert keine Wildcard im Dokument.
11. Vererbung (s. Kap. 10.11)
Die Elemente m und h erben das Attribut rgb von r: Zeile 10.
12. Graphrepräsentation (s. Kap. 10.12)
Ein korrespondierender Graph ist modelliert worden.
13. Transformation (s. Kap. 10.13)
Das Dokument kann in einen polyhierarchischen Graphen transformiert werden.
14. Eindeutigkeit (s. Kap. 10.14)
Die Abbildung des Szenarios in Dokument und Graph ist eindeutig.
2
verifiziert durch Coco/R
162
15. Entropie (s. Kap. 10.15)
Das Dokument ist mit sparsamer Markup-Kodierung ausgezeichnet.
Verständlichkeit, Lesbarkeit, Erlernbarkeit, Erwartungskonformität und
Selbstbeschreibungsfähigkeit sind gegeben.
17. Internationalisierung (s. Kap. 10.17)
Das Dokument ist mit UTF-8 kodiert.
18. Referenzimplementierung (s. Kap. 10.18)
Auf Dokument und Graph kann sicherer Zugriff durch die Referenzimplementierung erfolgen.
19. Spezifikation (s. Kap. 10.19)
Dokument und Graph sind spezifikationskonform.
163
Anhang B
Beispiel-Szenario B
Ein datenzentrisches Markup-Exempel wird vorgestellt. Das Szenario wird
beschrieben und die beiden korrespondierenden FML-Instanzen FML-Dokument und FML-Graph werden präsentiert.
B.1
Szenario
Gegenstand des Exempels ist ein Auszug aus einer Sportergebnistabelle1 :
In diesem datenzentrischen Beispiel interessieren nur Inhalte. Die Tabelle
kann also um alle graphischen Aspekte reduzieren werden. Zugunsten der
Übersichtlichkeit werden nur die Daten der Spalten 4, 5 und 9 berücksichtigt
und auch die Spaltenüberschriften ignoriert. Im Ergebnis ist das Szenario
eine zweidimensionale 3 × 3 - Matrix:
Canada
Australia
United States
BILODEAU Alexandre
BEGG-SMITH Dale
WILSON Bryon
26.75
26.58
26.08
Es besteht eine heterogene Relation zwischen der Menge der Zeilen Z ={1,2,3},
der Menge der Spalten S ={1,2,3} und der Inhaltsmenge
I ={Canada,BILODEAU Alexandre,26.75,Australia,BEGG-SMITH
Dale,26.58,United States,WILSON Bryon,26.08}
1
Freestyle Skiing – Men’s Moguls Final. Olympische Winterspiele, Vancouver, Kanada,
14.02.2010. Screenshot aus http://www.vancouver2010.com.
164
Da jedes Element aus Z × S zu genau einem Element von I in Relation
steht und kein Element aus Z × S mehr als einen Partner in I hat, kann
diese linkstotale und rechtseindeutige Relation auch als binäre Verknüpfung
zwischen Z × S und I mit einer Funktion f beschrieben werden:
f :Z ×S →I
f
f
f
f
f
f
f
f
f
: (1,1) → Canada,
: (1,2) → BILODEAU Alexandre,
: (1,3) → 26.75,
: (2,1) → Australia,
: (2,2) → BEGG-SMITH Dale,
: (2,3) → 26.58,
: (3,1) → United States,
: (3,2) → WILSON Bryon,
: (3,3) → 26.08
Dieser funktionalen Interpretation einer tabellarischen Struktur ist FML
sehr viel näher als der relationale Ansatz [28] oder die in Auszeichnungssprachen gängige und durch HTML [174] geprägte Baumdarstellung2 des
Szenarios:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
<table>
<tr>
</tr>
<tr>
</tr>
<tr>
</table>
</tr>
<td>Canada</td>
<td>BILODEAU Alexandre</td>
<td>26.75</td>
<td>Australia</td>
<td>BEGG-SMITH Dale</td>
<td>26.58</td>
<td>United States</td>
<td>WILSON Bryon</td>
<td>26.08</td>
Dieses HTML-Dokument ist übrigens auch ein wohlgeformtes FML-Dokument.
Das linear strukturierte Markup ist uninterpretiert nur eine Sequenz von
Wörtern, also vergleichbar mit der Datenstruktur eines eindimensionalen
Arrays. Eine Tabelle hingegen fußt auf der mächtigeren Datenstruktur eines zweidimensionalen Arrays. Wie also stellt man eine komplexe Struktur
in einer einfachen dar? Diese Frage wird in [126] und [191] reflektiert. Am
weitesten ist die Strukturübersetzung in eine Hierarchie verbreitet, angewandt von Datenbank-Exportfunktionen und allen HTML-Applikationen.
2
Originaldokument http://www.vancouver2010.com, gekürzt um irrelevante Informationen.
165
Der “Tabellenbaum“ wird von FML ebenso unterstützt, jedoch bietet sich
darüber hinaus eine weitere Möglichkeit: Mittels der neuen Funktionalität der Segmentierung (s. Kap. 10.8) lassen sich alle Tabellenliterale spachimmanent jeweils einer Zeile und einer Spalte durch eine Child-ParentBeziehung zuordnen, eine strukturelle Übersetzung muss nicht mehr erfolgen.
B.2
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
FML-Dokument
<<cell%Rank1%1><cell%Country%1>>
Canada
<<cell/></cell><cell%Rank1%2><cell%Name%1>>
BILODEAU Alexandre
<<cell/></cell><cell%Rank1%3><cell%Score%1>>
26.75
<<cell/></cell><cell%Rank2%1><cell%Country%2>>
Australia
BEGG-SMITH Dale
26.58
<<cell/></cell><cell%Rank3%1><cell%Country%3>>
United States
WILSON Bryon
26.08
<<cell/></cell>>
166
B.3
FML-Graph
167
B.4
Résumé
Anhand dieses Beispiels lassen sich mehrere Eigenschaften der Sprache FML
(s. Kapitel 10) prüfen:
1. Grammatik (s. Kap. 10.1)
Das FML-Dokument ist wohlgeformt gegenüber der FML-Grammatik 3 .
2. Kompatibilität (s. Kap. 10.2)
Der Grad der Ähnlichkeit gegenüber XML-Annotationen ist evident.
3. Monohierarchie (s. Kap. 10.3)
Monohierarchisches Markup besteht lediglich zwischen kongruenten
Tags (Multi-Tags) und Inhalten.
Interferentes Markup findet keine Anwendung.
5. Identifizierung (s. Kap. 10.5)
Die Identifizierung korrespondierender Tags erfolgt von links nach
rechts und von außen nach innen. Tag-IDs finden keine Anwendung.
Kongruentes Markup wird erwartungsgemäß kodiert: Zeile 01.
Es existiert genau eine Annotationsebene: die Default-Perspektive.
8. Segmentierung (s. Kap. 10.8)
Jedes Multi-Tag bis Zeile 17 enthält zwei Start-Tags, die das Segmentierungskonzept anwenden: Drei virtuelle Elemente für die Tabellenzeilen (rank1, rank2, rank3) sowie drei für die Tabellenspalten (name,
country, score) werden erzeugt.
9. Fragmentierung (s. Kap. 10.9)
Das Konzept der Fragmentierung findet keine Anwendung.
10. Wildcard (s. Kap. 10.10)
Es existiert keine Wildcard im Dokument.
11. Vererbung (s. Kap. 10.11)
Es existieren keine Attribute, somit findet das Konzept der Vererbung
keine Anwendung.
12. Graphrepräsentation (s. Kap. 10.12)
Ein korrespondierender Graph ist modelliert worden.
3
verifiziert durch Coco/R
168
13. Transformation (s. Kap. 10.13)
Das Dokument kann in einen polyhierarchischen Graphen transformiert werden.
14. Eindeutigkeit (s. Kap. 10.14)
Die Abbildung des Szenarios in Dokument und Graph ist eindeutig.
15. Entropie (s. Kap. 10.15)
Das Dokument ist mit sparsamer Markup-Kodierung ausgezeichnet.
Verständlichkeit, Lesbarkeit, Erlernbarkeit, Erwartungskonformität und
Selbstbeschreibungsfähigkeit sind gegeben.
17. Internationalisierung (s. Kap. 10.17)
Das Dokument ist mit UTF-8 kodiert.
18. Referenzimplementierung (s. Kap. 10.18)
Auf Dokument und Graph kann sicherer Zugriff durch die Referenzimplementierung erfolgen.
19. Spezifikation (s. Kap. 10.19)
Dokument und Graph sind spezifikationskonform.
169
Anhang C
Spezifikation ’FML’
Spezifikation der Sprache FML, wie sie Anwendern, Autoren, Entwicklern
und Dozenten als Skriptum zur Verfügung gestellt wird: kompakte Referenz
auf Sprachdefinition und -eigenschaften, ergebnisorientierte Konzentration
auf das Wesentliche.
Da die Inhalte der Spezifikation eine reine Teilmenge der vorliegenden Arbeit sind, sie also keinen Informationsgewinn bieten, sondern vielmehr eine
restrukturierte Inhaltszusammenfassung, die konsolidierte Essenz aus den
Kapiteln 4 und 5 sind, verlagert sich deren Publikation:
http://www.freestyle-markup.de/Spezifikation.pdf
http://www.freestyle-markup.org/Specification.pdf
170
[deutsch]
[englisch]
Anhang D
Compiler
Dieses Konfigurationsskript initialisiert den Coco/R-Compiler1 [106] für die
Generierung eines LL(1)-Parsers für FML-Dokumente.
COMPILER FML
CHARACTERS
blank = '\u0020'.
markupStart = '<'.
markupEnd = '>'.
contentChar = ANY - '<' - '>' - '\'.
perspectiveChar = ANY - '<' - '>' - '\' - '|' - '?' - ' ' - '
namespaceChar = ANY - '<' - '>' - '\' - '|' - '?' - ' ' - '
nameChar = ANY - '<' - '>' - '\' - '|' - '?' - ' ' - '
tagIdChar = ANY - '<' - '>' - '\' - ' ' - '!' - '
segmentIdChar = ANY - '<' - '>' - '\' - ' ' - '!' - '
segmentPosChar = "0123456789".
attNameChar = ANY - '<' - '>' - '\' - ' ' - '!' - '
attValueChar = ANY - '"'.
piTargetChar = ANY - ' '.
piInstructionChar = ANY - '>'.
commentChar = ANY - '!'.
1
Prof. H. Mössenböck, Johannes Kepler Universität Linz, Institut für Systemsoftware,
http://www.ssw.uni-linz.ac.at/Research/Projects/Coco
171
TOKENS
prologDocument = markupStart '@'
("fml.name=" '"' attValueChar {attValueChar} '"')
[blank "fml.uri=" '"' attValueChar {attValueChar} '"']
[blank "fml.description=" '"' attValueChar {attValueChar} '"']
[blank "fml.version=" '"' attValueChar {attValueChar} '"']
[blank "fml.fragment=" '"' attValueChar {attValueChar} '"']
[blank "fml.schema=" '"' attValueChar {attValueChar} '"']
[blank "fml.trim=" '"' ("true"|"false") '"']
[blank "fml.writing-direction=" '"' ("lr"|"rl") '"']
markupEnd.
prologPerspective = markupStart '@'
("fml.perspective.name=" '"' attValueChar {attValueChar} '"')
[blank "fml.perspective.uri=" '"' attValueChar {attValueChar} '"']
[blank "fml.perspective.description=" '"' attValueChar {attValueChar} '"']
[blank "fml.perspective.schema=" '"' attValueChar {attValueChar} '"']
markupEnd.
prologNamespace = markupStart '@'
("fml.namespace.name=" '"' attValueChar {attValueChar} '"')
[blank "fml.namespace.uri=" '"' attValueChar {attValueChar} '"']
[blank "fml.namespace.description=" '"' attValueChar {attValueChar} '"']
markupEnd.
content = contentChar {contentChar}.
startTag = markupStart
[perspectiveChar {perspectiveChar} '|']
[namespaceChar {namespaceChar} ':']
nameChar {nameChar}
[' ' tagIdChar {tagIdChar}]
['%' segmentIdChar {segmentIdChar} '%' segmentPosChar {segmentPosChar}]
{blank attNameChar {attNameChar} '=' '"' attValueChar {attValueChar} '"'
{',' '"' attValueChar {attValueChar} '"'}}
markupEnd.
endTag = markupStart
'/'
nameChar
{nameChar}
[' ' tagIdChar {tagIdChar}]
markupEnd.
172
emptyTag = markupStart
nameChar
{nameChar}
['%' segmentIdChar {segmentIdChar} '%' segmentPosChar {segmentPosChar}]
{blank attNameChar {attNameChar} '=' '"' attValueChar {attValueChar} '"'
{',' '"' attValueChar {attValueChar} '"'}}
'/'
markupEnd.
pi = markupStart
'?' piTargetChar {piTargetChar} blank piInstructionChar {piInstructionChar}
markupEnd.
comment = markupStart '!' commentChar {commentChar} '!' markupEnd.
wildcard = markupStart [perspectiveChar {perspectiveChar} '|'] markupEnd.
PRODUCTIONS
FML = { content | markup }.
markup = prolog | startTag | endTag | emptyTag | multiTag | pi | comment | wildcard.
multiTag = "<" (startTag | endTag | emptyTag)
(startTag | endTag | emptyTag)
{startTag | endTag | emptyTag}
">".
prolog = prologDocument | prologPerspective | prologNamespace.
END FML.
173
Anhang E
Konvertierungsleitfaden
XML → FML
Welche Richtlinien und Empfehlungen sind für eine erfolgreiche Konvertierung von XML-Dokumenten in FML-Dokumente einzuhalten? Durch konkrete Instruktionen befähigt dieser Leitfaden Entwickler zu technologischem
Wandel, zu einer semantisch verlustfreien Migration der Sprachtechnologie.
E.1
Notwendige Maßnahmen
Folgende Arbeitsschritte sind zur Konvertierung eines wohlgeformten XMLDokumentes in ein wohlgeformtes FML-Dokument zwingend notwendig:
1. UTF-8 Konvertierung
Das XML-Dokument ist mit der Zeichenkodierung UTF-8 und dem
Dateisuffix “.fml“ zu speichern. Empfehlung: Je nach verwendetem Dokumenteditor kann es hilfreich sein, die Kodierungsdirektive
im XML-Prolog hierfür einmalig auf encoding=“UTF-8“ umzustellen.
Diese Anweisung wird während der nächsten Persistierung zumeist automatisch umgesetzt.
2. Demaskierung
Sogenannte Escaped-Entities (vordefinierte Entitäten oder numerische
Zeichenreferenzen) sind in native UTF-8 -Zeichen aufzulösen.
Für eine Substitution von Zeichen, die nicht auf der landestypischen
Tastatur verfügbar sind, in native UTF-8 -Zeichen bieten die Betriebssysteme integrierte Zeichentabellen mit einfacher Copy & Paste - Funktion an. Alternativ kann man sich verschiedener externer Programme
wie Unibook™Character Browser, Gucharmap oder BabelMap bedienen.
174
XML
\
<
>
&
'
"
FML
\\
<
>
&
’
“
Dezimale (&#nnnn;) oder hexadezimale (&#xhhhh;) UCS-Zeichenreferenzen
sind in FML äquivalent zu nativen UTF-8 -Zeichen, sollten also zugunsten Lesbarkeit und Sparsamkeit substituiert werden, müssen aber
nicht zwingend ersetzt werden.
3. Maskierung
Die gemäß der FML-Syntax (s. Kap. 4.2) nicht erlaubten Zeichen sind
durch ein vorangestelltes ’\’ – dem üblichen Backslash – zu maskieren.
Die Möglichkeit einer Maskierung durch dezimale oder hexadezimale
UCS-Zeichenreferenzen wie in XML besteht alternativ: Diese Referenzen werden nach einer lexikalischen Dokumentanalyse und nach der
Transformation in einen FML-Graphen in den Knotenattributwerten
in native UTF-8 -Zeichen substituiert.
4. Deformatierung
Alle Formatierungssymbole (Zwischenräume, Tabulatoren und Umbrüche) werden nicht exklusiv behandelt und sind zu entfernen, insofern sie nicht zu Bestandteilen der Inhaltssequenz erklärt werden
sollen. So würde beispielsweise ein vor einer Inhaltszeichensequenz eingefügter Zeilenumbruch mit folgenden Einrückungen Präfix und Teil
dieses Inhaltes sein. Alle Formatierungen sollen richtlinienkonform
automatisch von einem Freestyle Editor (s. Kap. 11.7) vorgenommen
werden und müssen somit nicht Teil des Inhaltes sein.
5. XML Deklaration
Die optionale XML-Deklaration
<?xml version=“1.0“?>
zu Beginn eines XML-Dokumentes ist entweder zu entfernen oder aber
zu ersetzen durch die optionale FML-Dokument-Deklaration
<@fml.name=“document“ fml.version=“1.0“>
175
6. XML DOCTYPE
Vollständig entfernen. FML verfügt in Version 1.0 über keinerlei vergleichbaren Mechanismus einer Dokument-Typ-Deklaration.
7. XML Schema
Zuweisungen für Schemata wie XSD, Schematron oder RELAX NG
sind vollständig zu entfernen. FML verfügt in Version 1.0 noch über
keinerlei Schema- oder Validierungmechanismus.
8. CDATA-Sections
Dieses SGML/XML-Konstrukt wird in FML nicht unterstützt, Auflösung ist erforderlich. Entweder CDATA-Sections werden unter Informationsverlust vollständig gelöscht oder sie bleiben durch Umwandlung in Kommentare oder Processing Instructions oder durch Dokumentintegration über Elemente oder Inhalte erhalten.
9. Namensraum Deklaration
Alle XML-Namensraum-Deklarationen sind in einem FML-Namensraum-Prolog (s. Kap. 4.1.4) globalisiert zusammenzufassen.
10. Processing Instructions
Die verkürzte FML-Syntax (s. Kap. 4.2) ist anzuwenden.
11. Kommentare
Die verkürzte FML-Syntax (s. Kap. 4.2) ist anzuwenden.
12. Reservierte Bezeichner
Alle Elemente und Attribute, deren Name mit “fml.“ beginnt, müssen
umbenannt werden. Das Präfix-Literal “fml.“ ist reserviert für FMLinterne Meta-Informationen.
176
E.2
Empfohlene Maßnahmen
Die Anwendung folgender neuer FML-Sprachkonzepte bietet sich im Rahmen der Konvertierung eines wohlgeformten XML-Dokumentes in ein wohlgeformtes FML-Dokument an:
4. Segmentieren (s. Kap. 6.9)
5. Fragmentieren (s. Kap. 6.10)
E.3
Hinweise
Bestehende XML-Anwendungen werden das neue FML-Dokument entweder gar nicht oder anders interpretieren. Entsprechend sind nach erfolgter Migration die das konvertierte Dokument weiterverarbeitenden Prozesse
gleichsam anzupassen bzw. durch FML-Prozessoren zu ersetzen.
177
Anhang F
fml-graph.gxl.xsd
Dieses Schema-Dokument, konform GXL-Spezifikation, beschreibt und validiert alle GXL-Dokumente, die im Namensraum
http://www.gupro.de/GXL/gxl-1.0.dtd
Instanzen eines FML-Graphen abbilden.
001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
<?xml version="1.0"?>


<gxl xmlns="http://www.gupro.de/GXL/gxl-1.0.dtd"
xsi:schemaLocation=
"http://www.gupro.de/GXL/gxl-1.0.dtd gxl-1.0-schema.xsd"
xmlns:xlink="http://www.w3.org/1999/xlink">
<graph id="fml-graph" edgeids="true"
edgemode="directed" hypergraph="false">
<type xlink:href="gxl-1.0-metaschema.gxl#gxl-1.0"/>
<node id="fml.node.document">
<type xlink:href="gxl-1.0-metaschema.gxl#GraphClass"/>
<attr name="fml.node-type" kind="required">
<string>fml.node.document</string>
</attr>
<attr name="fml.name" kind="optional">
<string/>
</attr>
<attr name="fml.uri" kind="optional">
<locator/>
</attr>
<attr name="fml.description" kind="optional">
178
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
<string/>
</attr>
<attr name="fml.version" kind="optional">
<float>1.0</float>
</attr>
<attr name="fml.fragment" kind="optional">
<string/>
</attr>
<attr name="fml.schema" kind="optional">
<locator/>
</attr>
<attr name="fml.perspective.name"
kind="multiple-set.perspective">
<string/>
</attr>
<attr name="fml.perspective.uri"
<locator/>
</attr>
<attr name="fml.perspective.description"
<string/>
</attr>
<attr name="fml.perspective.schema"
<locator/>
</attr>
<attr name="fml.namespace.name"
kind="multiple-set.namespace">
<string/>
</attr>
<attr name="fml.namespace.uri"
<locator/>
</attr>
<attr name="fml.namespace.description"
<string/>
</attr>
</node>
<node id="fml.node.perspective">
<type xlink:href="gxl-1.0-metaschema.gxl#NodeClass"/>
<string>fml.node.perspective</string>
179
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099
100
101
102
103
104
105
106
107
108
109
110
111
112
</attr>
<attr name="fml.perspective.name" kind="optional">
<string/>
</attr>
</node>
<node id="fml.node.content">
<string>fml.node.content</string>
</attr>
<attr name="fml.content" kind="required">
<string/>
</attr>
</node>
<node id="fml.node.element">
<string>fml.node.element</string>
</attr>
<attr name="fml.element.namespace.name" kind="optional">
<string/>
</attr>
<attr name="fml.element.name" kind="required">
<string/>
</attr>
<attr name="fml.element.id" kind="optional">
<string/>
</attr>
<attr name="fml.element.autocompleted" kind="optional">
<enum>start-tag;end-tag</enum>
</attr>
</node>
<node id="fml.node.attribute">
<string>fml.node.attribute</string>
</attr>
<attr name="fml.attribute.name" kind="required">
<string/>
</attr>
</node>
<node id="fml.node.comment">
180
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
<string>fml.node.comment</string>
</attr>
<attr name="fml.comment.content" kind="required">
<string/>
</attr>
</node>
<node id="fml.node.pi">
<string>fml.node.pi</string>
</attr>
<attr name="fml.pi.target" kind="required">
<string/>
</attr>
<attr name="fml.pi.instruction" kind="required">
<string/>
</attr>
</node>
<node id="fml.node.wildcard">
<string>fml.node.wildcard</string>
</attr>
</node>
<edge id="fml.node.document2fml.node.perspective"
from="fml.node.document" to="fml.node.perspective">
<type xlink:href="gxl-1.0-metaschema.gxl#EdgeClass"/>
</edge>
<edge id="fml.node.perspective2fml.node.content"
from="fml.node.perspective" to="fml.node.content">
</edge>
<edge id="fml.node.perspective2fml.node.element"
from="fml.node.perspective" to="fml.node.element">
</edge>
<edge id="fml.node.perspective2fml.node.comment"
from="fml.node.perspective" to="fml.node.comment">
</edge>
<edge id="fml.node.perspective2fml.node.pi"
from="fml.node.perspective" to="fml.node.pi">
</edge>
181
157
<edge id="fml.node.perspective2fml.node.wildcard"
158
from="fml.node.perspective" to="fml.node.wildcard">
159
160
</edge>
161
<edge id="fml.node.element2fml.node.content"
162
from="fml.node.element" to="fml.node.content">
163
164
</edge>
165
<edge id="fml.node.element2fml.node.element"
166
from="fml.node.element" to="fml.node.element">
167
168
</edge>
169
<edge id="fml.node.element2fml.node.attribute"
170
from="fml.node.element" to="fml.node.attribute">
171
172
</edge>
173
<edge id="fml.node.element2fml.node.comment"
174
from="fml.node.element" to="fml.node.comment">
175
176
</edge>
177
<edge id="fml.node.element2fml.node.pi"
178
from="fml.node.element" to="fml.node.pi">
179
180
</edge>
181
<edge id="fml.node.element2fml.node.wildcard"
182
from="fml.node.element" to="fml.node.wildcard">
183
184
</edge>
185
<edge id="fml.node.attribute2fml.node.content"
186
from="fml.node.attribute" to="fml.node.content">
187
188
</edge>
189
</graph>
190 </gxl>
182
Anhang G
fml.xml.xsd
Dieses Schema-Dokument, konform Spezifikation [179], beschreibt und validiert alle XML-Dokumente, die im Namensraum
verlustfrei Struktur und Inhalt von FML-Dokumenten abbilden.
002 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
003
xmlns:fml="http://www.freestyle-markup.org"
004
targetNamespace="http://www.freestyle-markup.org">
005
006
<xs:annotation><xs:documentation>
007 This XSD specifies XML-instances for representing FML-documents.
008
</xs:documentation></xs:annotation>
009
010
<xs:element name="document">
011
<xs:complexType mixed="false">
012
<xs:sequence>
013
<xs:group ref="fml:prolog" minOccurs="0" maxOccurs="1"/>
014
<xs:choice minOccurs="0" maxOccurs="unbounded">
015
<xs:element ref="fml:content"/>
016
<xs:element ref="fml:markup"/>
017
</xs:choice>
018
</xs:sequence>
019
</xs:complexType>
020
</xs:element>
021
022
<xs:group name="prolog">
023
<xs:sequence>
024
<xs:element ref="fml:prolog.document" minOccurs="0"/>
183
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
<xs:element ref="fml:prolog.perspective" minOccurs="0"/>
<xs:element ref="fml:prolog.namespace" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="prolog.document">
<xs:sequence>
<xs:element name="name" form="qualified"/>
<xs:element name="uri" minOccurs="0" form="qualified"/>
<xs:element name="description" minOccurs="0"
form="qualified"/>
<xs:element name="version" minOccurs="0" form="qualified"/>
<xs:element name="fragment" minOccurs="0" form="qualified"/>
<xs:element name="schema" minOccurs="0" form="qualified"/>
<xs:element name="trim" minOccurs="0" form="qualified">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="writing-direction" minOccurs="0"
form="qualified">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="lr"/>
<xs:enumeration value="rl"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="prolog.perspective">
<xs:sequence>
form="qualified"/>
<xs:element name="schema" minOccurs="0" form="qualified"/>
184
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099
100
101
102
103
104
105
106
107
108
109
110
111
112
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="prolog.namespace">
<xs:sequence>
form="qualified"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="content">
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:element>
<xs:element name="markup" abstract="true"/>
<xs:element name="tag" abstract="true" substitutionGroup="fml:markup"/>
<xs:element name="tag.start" substitutionGroup="fml:tag">
<xs:sequence>
<xs:element ref="fml:perspective.name" minOccurs="0"/>
<xs:element ref="fml:namespace.name" minOccurs="0"/>
<xs:element name="tag.name" type="xs:string"
form="qualified"/>
<xs:element name="tag.id" type="xs:string"
form="qualified" minOccurs="0"/>
<xs:group ref="fml:segment" minOccurs="0"/>
<xs:element name="attribute" type="fml:attribute"
form="qualified" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="tag.end" substitutionGroup="fml:tag">
<xs:sequence>
185
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
form="qualified"/>
<xs:element name="tag.id" type="xs:string"
form="qualified" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="tag.empty" substitutionGroup="fml:tag">
<xs:sequence>
form="qualified"/>
<xs:group ref="fml:segment" minOccurs="0"/>
<xs:element name="attribute" type="fml:attribute"
form="qualified" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="tag.multiple" substitutionGroup="fml:tag">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element ref="fml:tag.start"/>
<xs:element ref="fml:tag.end"/>
<xs:element ref="fml:tag.empty"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:complexType name="attribute" mixed="false">
<xs:sequence>
<xs:element name="attribute.name" type="xs:string"
form="qualified"/>
<xs:element name="attribute.value" type="xs:string"
form="qualified" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:group name="segment">
186
157
<xs:sequence>
158
<xs:element name="segment.id" form="qualified"
159
type="xs:string"/>
160
<xs:element name="segment.pos" form="qualified"
161
type="xs:integer"/>
162
</xs:sequence>
163
</xs:group>
164
165
<xs:element name="comment" substitutionGroup="fml:markup"
166
type="xs:string"/>
167
168
<xs:element name="pi" substitutionGroup="fml:markup">
169
170
<xs:sequence>
171
172
<xs:element name="pi.target"
173
type="xs:string" form="qualified"/>
174
<xs:element name="pi.instruction"
175
type="xs:string" form="qualified"/>
176
</xs:sequence>
177
</xs:complexType>
178
</xs:element>
179
180
<xs:element name="wildcard" substitutionGroup="fml:markup">
181
182
<xs:sequence>
183
184
</xs:sequence>
185
</xs:complexType>
186
</xs:element>
187
188
<xs:element name="perspective.name" type="xs:string"/>
189
<xs:element name="namespace.name" type="xs:string"/>
190
191 </xs:schema>
187
Anhang H
xml2fml.xslt
Dieses XSLT -Dokument, konform Spezifikation [185], konvertiert im Namensraum
die XML-Repräsentation eines FML-Dokumentes verlustfrei zurück in das
ursprüngliche FML-Dokument.
02 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
03
version="1.0" xmlns:fml="http://www.freestyle-markup.org">
04
<xsl:output omit-xml-declaration="yes" encoding="UTF-8" indent="no"/>
05
<xsl:variable name="fml-prefix">fml.</xsl:variable>
06
<xsl:variable name="markup-start"><</xsl:variable>
07
<xsl:variable name="markup-end">></xsl:variable>
08
09
<xsl:template match="fml:document">
10
<xsl:apply-templates mode="fml" select="*"/>
11
</xsl:template>
12
13
<xsl:template match="fml:prolog.document" mode="fml">
14
<xsl:call-template name="prolog-content-handler"/>
15
</xsl:template>
16
17
<xsl:template match="fml:prolog.perspective" mode="fml">
18
19
</xsl:template>
20
21
<xsl:template match="fml:prolog.namespace" mode="fml">
22
23
</xsl:template>
188
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
<xsl:template name="prolog-content-handler" mode="fml">
<xsl:value-of select="$markup-start" disable-output-escaping="yes"/>
<xsl:text>@</xsl:text>
<xsl:for-each select="child::*">
<xsl:value-of select="$fml-prefix"/>
<xsl:value-of select="local-name()"/>
<xsl:text>="</xsl:text>
<xsl:value-of select="./text()" disable-output-escaping="yes"/>
<xsl:text>"</xsl:text>
<xsl:if test="following-sibling::*">
<xsl:text> </xsl:text>
</xsl:if>
</xsl:for-each>
<xsl:value-of select="$markup-end" disable-output-escaping="yes"/>
</xsl:template>
<xsl:template match="fml:content" mode="fml">
<xsl:value-of select="."/>
</xsl:template>
<xsl:template match="fml:tag.start" mode="fml" name="tag.start">
<xsl:param name="multipleElement" select="false()"/>
<xsl:if test="$multipleElement=false()">
</xsl:if>
<xsl:if test="./fml:perspective.name">
<xsl:value-of select="./fml:perspective.name"/>
<xsl:text>|</xsl:text>
</xsl:if>
<xsl:if test="./fml:namespace.name">
<xsl:value-of select="./fml:namespace.name"/>
<xsl:text>:</xsl:text>
</xsl:if>
<xsl:value-of select="./fml:tag.name"/>
<xsl:if test="./fml:tag.id">
<xsl:text>∼</xsl:text>
<xsl:value-of select="./fml:tag.id"/>
</xsl:if>
<xsl:if test="./fml:segment.id">
<xsl:text>%</xsl:text>
<xsl:value-of select="./fml:segment.id"/>
</xsl:if>
<xsl:if test="./fml:segment.pos">
189
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
<xsl:value-of select="./fml:segment.pos"/>
</xsl:if>
<xsl:for-each select="./fml:attribute">
<xsl:call-template name="attribute-handler"/>
</xsl:for-each>
</xsl:if>
</xsl:template>
<xsl:template match="fml:tag.end" mode="fml" name="tag.end">
</xsl:if>
</xsl:if>
<xsl:text>/</xsl:text>
</xsl:if>
<xsl:if test="./fml:tag.id">
<xsl:text>∼</xsl:text>
<xsl:value-of select="./fml:tag.id"/>
</xsl:if>
</xsl:if>
</xsl:template>
<xsl:template match="fml:tag.empty" mode="fml" name="tag.empty">
</xsl:if>
190
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
</xsl:if>
</xsl:if>
<xsl:if test="./fml:segment.id">
<xsl:value-of select="./fml:segment.id"/>
</xsl:if>
<xsl:if test="./fml:segment.pos">
<xsl:value-of select="./fml:segment.pos"/>
</xsl:if>
<xsl:for-each select="./fml:attribute">
<xsl:call-template name="attribute-handler"/>
</xsl:for-each>
<xsl:text disable-output-escaping="yes">/</xsl:text>
</xsl:if>
</xsl:template>
<xsl:template match="fml:tag.multiple" mode="fml">
<xsl:for-each select="*">
<xsl:if test="local-name()='tag.start'">
<xsl:call-template name="tag.start">
<xsl:with-param name="multipleElement" select="true()"/>
</xsl:call-template>
</xsl:if>
<xsl:if test="local-name()='tag.end'">
<xsl:call-template name="tag.end">
</xsl:if>
<xsl:if test="local-name()='tag.empty'">
<xsl:call-template name="tag.empty">
191
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
</xsl:if>
</xsl:if>
</xsl:for-each>
</xsl:template>
<xsl:template name="attribute-handler" mode="fml">
<xsl:value-of select="./fml:attribute.name"/>
<xsl:text>=</xsl:text>
<xsl:for-each select="./fml:attribute.value">
<xsl:value-of select="text()"/>
<xsl:text>,</xsl:text>
</xsl:if>
</xsl:for-each>
</xsl:template>
<xsl:template match="fml:comment" mode="fml">
<xsl:text>!</xsl:text>
<xsl:value-of select="."/>
<xsl:text>!</xsl:text>
</xsl:template>
<xsl:template match="fml:pi" mode="fml">
<xsl:text>?</xsl:text>
</xsl:if>
<xsl:value-of select="./fml:pi.target"/>
<xsl:value-of select="./fml:pi.instruction"/>
</xsl:template>
192
200
201
<xsl:template match="fml:wildcard" mode="fml">
202
203
204
</xsl:template>
205 </xsl:stylesheet>
193
Anhang I
UML-Klassendiagramm
Das FML-Datenmodell der Implementierung (s. Kap. 9) beinhaltet alle
Transformationsfunktionen und repräsentiert den FML-Graphen als Interpretation eines FML-Dokumentes. Das folgende Klassendiagramm1 visualisiert in UML-Notation das Modell der FML-Implementierung mit allen
Methoden für die Transformationssteuerung und allen Zugriffsfunktionen
für Selektion und Manipulation.
Schnittstellenklassen:
• fml.IController
• fml.model.IAttribute
• fml.model.IComment
• fml.model.IContent
• fml.model.IDocument
• fml.model.IElement
• fml.model.INamespace
• fml.model.INode
• fml.model.IPerspective
• fml.model.IPi
• fml.model.IWildcard
• fml.exception.InvalidXMLException
• fml.exception.IOException
• fml.exception.WellformednessException
1
erstellt mit Sybase™ PowerDesigner Version 15
194
195
Anhang J
Relationales
FML-Datenbankschema
Dieses Relationenschema (ER-Diagramm1 ) mit hohem Normalisierungsgrad
dient der verlust- und redundanzfreien Persistierung von FML-Instanzen in
einer relationalen Datenbank.
Entitäten:
• Document
• Perspective
• DocumentPerspective
• Namespace
• DocumentNamespace
• Node
• DocumentNode
• Content
• Comment
• PI
• Element
• Attribute
• ElementAttribute
• AttributeValue
• Value
1
erstellt mit Sybase™ PowerDesigner Version 15
196
197
Anhang K
Umfrage
Die Evaluation wesentlicher Sprachanforderungen wurde durch Umfragen1
unter Technologieunternehmen und -institutionen zu den Freestyle-Kernkonzepten von FML unterstützt. Umfrageintention, alle Fragebögen und Auswertungen werden im Folgenden dargelegt.
K.1
Intention
Ziel der Umfrage ist es, die Umsetzung von FML-Sprachanforderungen zu
evaluieren. Gegenstand der Befragung sind die dem Freestyle-Kriterium
zuspielenden Aspekte
• Interferenz (s. Kap. 2.4),
• Kongruenz (s. Kap. 2.6),
• Independenz (s. Kap. 2.7),
• Segmentierung (s. Kap. 2.8),
die mittels vier prägnanter Fragebögen diskutiert werden. Den Diskussionspartnern werden in abgrenzendem Vergleich zu XML Anforderungslösungen
präsentiert und zur Bewertung angeboten.
Alle Gesprächsergebnisse regen die Lösungsfindung an und untermauern
die Umsetzung der mit den Anforderungen korrespondierenden Spracheigenschaften (s. Kap. 10.4, 10.6, 10.7 und 10.8).
Als Disskussionsteilnehmer werden ausschließlich Unternehmen und Institutionen, deren Produkt- oder Know-how-Spektrum die Technologie XML
einschließt, gewählt. Auch werden die jeweiligen Ansprechpartner mit kurzen Fachfragen auf ein fundamentales Markup-Verständnis überprüft. Somit
ist sichergestellt, dass nur Fachkräfte mit notwendiger Urteilskompetenz an
der Umfrage teilnehmen.
1
Informationstechnik-Messe CeBIT, Hannover, 5./6. März 2010.
198
K.2
Fragebögen
K.2.1
Interferenz
199
K.2.2
Kongruenz
200
K.2.3
Independenz
201
K.2.4
Segmentierung
202
K.3
Ergebnisse
Folgende Unternehmen und Institutionen unterstützten mit genau einem
Mitarbeiter die Umfrage:
• Adobe Systems GmbH
• Baden-Württemberg International
• Bibliographisches Institut AG
• DATEV eG
• e-Spirit AG
• Fraunhofer-Gesellschaft e.V.
• Graphische Informationstechnik Beratungsgesellschaft mbH
• IBM Deutschland GmbH
• KRISPIN Marketing Management
• LuraTech Europe GmbH
• META-LEVEL Software AG
• Microsoft Deutschland GmbH
• MINX Software und Service GbR
• MS-Consult EDV-Management und Systemberatung GmbH
• Noxum GmbH
• SAP AG
• SCAI Systemberatung & Software-Entwicklung GmbH
• SDS Software
• SFIRM Development GmbH
• Software AG
• Sun Microsystems GmbH
• Technische Informationsbibliothek
• Universität Hamburg – Department Informatik
• Zentrum für Informatik ZFI AG
203
K.3.1
Interferenz
Umfrageergebnisse des Fragebogens Interferenz:
1. Ich verstehe Markups und Modelle für das Interferenz-Szenario!
100% (24/24)
2. Die FML-Variante erscheint mir plausibel!
100% (24/24)
3. Die FML-Auszeichnung bildet das Szenario besser ab!
83% (20/24)
4. Als unparteiischer Autor/Leser bevorzuge ich die FML-Auszeichnung!
50% (12/24)
5. Die FML-Variante hat Akzeptanzpotenzial!
67% (16/24)
K.3.2
Kongruenz
Umfrageergebnisse des Fragebogens Kongruenz:
1. Ich verstehe Markups und Modelle für das Kongruenz-Szenario!
100% (24/24)
2. Die FML-Variante erscheint mir plausibel!
100% (24/24)
3. Die FML-Auszeichnung bildet das Szenario besser ab!
71% (17/24)
4. Als unparteiischer Autor/Leser bevorzuge ich die FML-Auszeichnung!
67% (16/24)
5. Die FML-Variante hat Akzeptanzpotenzial!
79% (19/24)
K.3.3
Independenz
Umfrageergebnisse des Fragebogens Independenz:
1. Ich verstehe Markup und Modell für das Independenz-Szenario!
96% (23/24)
2. Das Independenz-Konzept erscheint mir plausibel!
91% (22/24)
3. Ich erachte die Independenz-Funktionalität für sinnvoll!
79% (19/24)
204
4. Das Independenz-Konzept hat Akzeptanzpotenzial!
63% (15/24)
K.3.4
Segmentierung
Umfrageergebnisse des Fragebogens Segmentierung:
1. Ich verstehe Markup und Modell für das Segmentierungs-Szenario!
88% (21/24)
2. Das Segmentierungs-Konzept erscheint mir plausibel!
71% (17/24)
3. Ich erachte die Segmentierungs-Funktionalität für sinnvoll!
54% (13/24)
4. Das Segmentierungs-Konzept hat Akzeptanzpotenzial!
13% (3/24)
K.4
Résumé
Für die Evaluation der vier Freestyle-Sprachanforderungen Interferenz, Kongruenz, Independenz und Segmentierung wurden insgesamt 24 XML-fachkundige Personen befragt. Deren Erfahrungen, Interessen, und Wünsche
fließen in die Umfrage ein.
Die Mehrzahl der Umfrageteilnehmer zeigte sich sehr interessiert an die über
ihre Erfahrungswerte mit XML hinausführenden Konzepte. Szenario, Markup und Modell konnten zumeist innerhalb weniger Minuten erfasst und
verstanden werden. Die primären Gründe für negative Bewertungen waren
fehlende Konformität zu XML und mangelnde Vorstellung von profitierenden realistischen Anwendungsszenarien. Das Akzeptanzpotenzial des Segmentierungs-Konzeptes wurde aus genau diesen beiden Gründen mit 13%
mit Abstand am schwächsten bewertet. Alle anderen Szenarien und Kriterien wurden mit 50 – 100% mehrheitlich positiv bewertet. Ablehnenden
Bewertungen von Anwendern, denen Vergleich oder Skepsis die Sicht auf
Neues verhindert, sind jedoch nicht zuviel Bedeutung beizulegen, da es sich
bei den untersuchten Freestyle-Konzepten um rein optionale Spracheigenschaften handelt.
Jede einzelne positive Umfragebewertung bestätigt bestehende Defizite der
Sprache XML und rechtfertigt Weiterentwicklung, nicht zuletzt die Entwicklung der Sprache FML.
205
Anhang L
FML-Internetressourcen
Aus dieser Arbeit resultierende Publikationen, durch deren Veröffentlichung
die Technologie FML auch nach finalem Status dieser Dissertationsschrift
in ihrer Weiterentwicklung Bestand haben soll, werden zusammengefasst.
Alle Forschungsergebnisse sollen somit der Wissenschaft, Autoren- und Entwicklergemeinde durch Online-Publikationen zur Diskussion angeboten werden.
1. http://www.freestyle-markup.org/thesis.pdf
Dissertationsschrift ’Freestyle Markup Language’
2. http://www.freestyle-markup.org
[englisch]
http://www.freestyle-markup.de
[deutsch]
Projekt-Seite für die Technologie ’Freestyle Markup Language’ und
Plattform zur Publikation weiterer Entwicklungen
3. http://www.freestyle-markup.de/Spezifikation.pdf
http://www.freestyle-markup.org/Specification.pdf
FML-Spezifikation
[deutsch]
[englisch]
4. http://www.freestyle-markup.org/balisage2010
Konferenz Balisage 2010: Veröffentlichung
5. http://www.freestyle-markup.org/balisage2010/presentation.pdf
http://www.freestyle-markup.org/balisage2010/presentation.ppt
Konferenz Balisage 2010: Präsentation
6. http://www.freestyle-markup.org/intro.fml
einführendes FML-Beispieldokument
http://www.freestyle-markup.org/documentcentricSample.fml
dokumentenzentrisches FML-Beispieldokument
http://www.freestyle-markup.org/datacentricSample.fml
datenzentrisches FML-Beispieldokument
206
7. http://www.freestyle-markup.org/fml-grammar.ebnf
EBNF -Grammatik von FML-Dokumenten
8. http://www.freestyle-markup.org/fml-grammar.coco.atg
Coco/R-Konfigurationsskript zur Generierung von Scanner/Parser für
FML-Dokumente
9. http://www.freestyle-markup.org/fml.jar
10. http://www.freestyle-markup.org/concepts/annotation.fml
http://www.freestyle-markup.org/concepts/declaration.fml
http://www.freestyle-markup.org/concepts/tagging.fml
http://www.freestyle-markup.org/concepts/attribution.fml
http://www.freestyle-markup.org/concepts/interference.fml
http://www.freestyle-markup.org/concepts/identification.fml
http://www.freestyle-markup.org/concepts/congruence.fml
http://www.freestyle-markup.org/concepts/independence.fml
http://www.freestyle-markup.org/concepts/segmentation.fml
http://www.freestyle-markup.org/concepts/fragmentation.fml
FML-Dokumente der Kapitel 6.1 – 6.10
11. http://www.freestyle-markup.org/gxl/fml-graph.example.gxl
GXL-Instanz des FML-Graphen aus Kap. 6.1
http://www.freestyle-markup.org/gxl/fml-graph.schema.gxl
GXL-Schema für FML-Graphen
http://www.freestyle-markup.org/gxl/gxl-1.0-schema.xsd
GXL-Schema
http://www.freestyle-markup.org/gxl/gxl-1.0-metaschema.gxl
GXL-Metaschema
12. http://www.freestyle-markup.org/xml/fml.xml.xsd
XSD der XML-Repräsentation eines FML-Dokumentes (s. Kap. 8.1)
http://www.freestyle-markup.org/xml/xml2fml.xslt
XSLT -Transformationsskript zur Konvertierung der XML-Repräsentation
eines FML-Dokumentes in das FML-Dokument (s. Kap. 8.3)
http://www.freestyle-markup.org/xml/document.fml
FML-Dokument (s. Kap. 8.2)
http://www.freestyle-markup.org/xml/document.xml
XML-Dokument (s. Kap. 8.2)
207
Glossar
API
Application Programming Interface. Programmierschnittstelle zur Anbindung anderer Programme bzw. Bibliotheken an ein Softwaresystem.
ASG
Abstract Syntax Graph. DAG, der einem Compiler als interne Repräsentation einer Eingabesequenz dient. Syntaktisch interpretierte
Instanz einer Grammatik, ähnlich dem EBNF -Ableitungsbaum.
Attribut
Eigenschaft von Tags, denen genau ein Wert oder in Form einer Liste
mehrere durch Komma getrennte Werte zugeordnet werden.
Auszeichnung
Siehe Markup.
Auszeichnungssprache
Syntaktisches Regelwerk zur Strukturierung und semantischen Kennzeichnung (bzw. Betonung, Hervorhebung, Markierung oder Auszeichnung) von Dokumenteninhalten.
Child
Untergeordnetes Element in einer Hierarchie. Antonym: Parent.
CMP
Siehe Cross Media Publishing.
CMS
Content-Management-System. Verwaltungssystem für medienneutrale
Dokumente zwecks kollaborativer Inhaltsbearbeitung.
Coco/R
LL(1)-Parser, Johannes Kepler Universität Linz: Fundiert, erprobt,
beliebt, verbreitet.
208
Compiler
Programm für die Übersetzung eines Eingabedokumentes in ein semantisch interpretierbares Zielformat. Verwendet wenigstens Scanner
und Parser zur Erzeugung eines Graphen.
CONCUR
Mechanismus zur Kodierung multipler Hierarchien mittels Tag-Präfixe.
Optionales Feature von SGML.
Concurring-Markup
Siehe Interferenz.
Cross Media Publishing
Übergreifende Inhaltserstellung für verschiedene Publikationsformate
auf Grundlage medienneutraler Daten aus einer redundanzfreien Datenbasis. Prinzip der XSLT - und XSL-FO-Technolgie.
Crossover-Markup
Siehe Interferenz.
DAG
Directed Acyclic Graph. Gerichteter azyklischer Graph.
Descriptive Markup Language
Auszeichnungssprache, welche Informationen beschreibt, aber keine
Prozessorinstruktionen verwendet. Gegenteil der PML, auch wenn die
Abgrenzung unscharf ist: Die Sprache XML als populärster Vertreter
der DMLs integriert das obsolete prozedurale Konzept der Processing
Instructions.
Deserialisierung
Im Allgemeinen eine Konvertierung einer persistenzfähigen sequenziellen Darstellungsform in eine Objektstruktur. Im Kontext von FML
eine Transformation eines FML-Dokumentes in einen FML-Graphen.
Umkehrung der Serialisierung.
DML
Siehe Descriptive Markup Language.
DocBook
Mediumneutrales Format für die strukturelle Auszeichnung technischer Dokumentationen. Offener XML-Standard der OASIS. Spezifikation: [189].
Dokument
Markup-Komponente. Repräsentiert das vollständige FML-Dokument
und bildet die Root in einem FML-Graphen. Siehe Kap. 4.1.1.
209
DOM
Document Object Model. Objektorientierte Schnittstellen für den lesenden und schreibenden Zugriff auf ein XML-Dokument. DOM ermöglicht Navigation und Manipulation in einem hierarchischen Datenmodell des korrespondierenden XML-Dokumentes. Spezifikation:
[178].
DSSSL
Document Style Semantics and Specification Language. Skriptbasierte
Transformationssprache für SGML mit massgeblichem Einfluss auf die
Entwicklung von XSLT . ISO/IEC-Standard 10179:1996.
DTD
Document Type Definition. Beschreibungssprache für SGML- und
XML-Dokumente. Bestandteil der XML-Spezifikation, obgleich bzgl.
Akzeptanz und Verbreitung überholt von XSD.
DTP
Desktop Publishing. Rechnergestützter Dokumentendrucksatz.
EBNF
Erweiterte Backus-Naur-Form. Sprache zur Spezifikation kontextfreier
Grammatiken. Von der ISO standardisiert unter der Nummer ISO/IEC
14977:1996(E).
EDI
Electronic Data Interchange. Kopplung und Austausch zwischen heterogenen Systemen unabhängig von Anwendung, Branche, Protokoll
oder Transferformat. EDI erzielt für zumeist automatisierbare Geschäftsfälle eine Informationsintegration beteiligter Systeme verschiedener Institutionen. Gemeinhin erfolgt eine unscharfe Abgrenzung
zwischen traditionellem EDI [51] seit den 1960er Jahren und EDI mit
dem Transferformat XML [187] [193] seit 1999.
EDMS
Elektronisches Dokumentenmanagementsystem. Verwaltung elektronischer Dokumente in einem Computersystem zwecks Gewährleistung
von Revisionssicherheit, Langlebigkeit, Indizierung und Anwendungsintegration.
Element
Knoten in einem FML-Graphen. Kapselt den Inhalt zwischen einem
öffnenden und einem korrespondierend schliessenden Tag bzw. repräsentiert ein leeres Tag. Primäres Strukturierungsmittel.
210
ER-Modell
Entity-Relationship-Modell. Gegenstands-Beziehungs-Modell zur Modellierung von Struktur und Semantik mittels Abstraktion und Visualisierung. Designgrundlage für relationale Datenbanken.
ERM
Siehe ER-Modell.
FictionBook
Offenes XML-Format für eine Digitalisierung und strukturelle Auszeichnung des Mediums Buch zwecks Präsentation und Weiterverarbeitung. Spezifikation: [56].
FML
Freestyle Markup Language. Neue deskriptive Auszeichnungssprache,
die verschiedene kritische Restriktionen der XML aufhebt, um ein ’freihändiges Auszeichnen’ von Texten in breitere Datenstrukturen zu ermöglichen. Gegenstand dieser Arbeit.
FML-Dokument
Eine persistenzfähige sequenzielle Darstellungsform einer FML-Instanz,
syntaktisch komform zur FML-Grammatik.
FML-Grammatik
Syntaktisches Regelwerk in EBNF zur Erzeugung und Sprachdefinition von FML-Dokumenten.
FML-Graph
Spezieller Graph, Graphrepräsentation und Objektmodell eines FMLDokumentes und Darstellungsform einer FML-Instanz.
FML-Instanz
Ein konkretes Exemplar der Sprache FML mit den korrespondierenden
Darstellungsformen FML-Dokument und FML-Graph.
Fragmentierung
FML-Spracheigenschaft. FML-Konzept, das eine verteilte Distribution eines FML-Dokumentes unterstützt: Ein Fragment eines wohlgeformten FML-Dokumentes ist ebenfalls ein wohlgeformtes FML-Dokument.
Freestyle
Bezeichnung für Markup-Konzepte, die sich – in Abgrenzung zu XML
– durch die Restriktionsfreiheit eines aufgehobenen Hierarchiezwanges
charakterisieren: Interferenz, Kongruenz, Independenz, Segmentierung
und Wildcard.
211
geschachtelt
Zustand einer FML-Instanz: Ist eine FML-Instanz wohlgeformt und
entspricht dem primären XML-Wohlgeformtheitskriterium (genau eine
Root und streng monohierarchische Element-Verschachtelung), so befindet sie sich im Zustand geschachtelt.
GML
Generalized Markup Language (sowie ursprünglich Vornamensinitialen der Entwickler Charles Goldfarb, Edward Mosher und Raymond
Lorie). Eine in den 1960ern von IBM entwickelte und 1973 der Öffentlichkeit vorgestellte Auszeichnungssprache zur Beschreibung von
Textdokumenten. Grundlage der Entwicklung von SGML.
GODDAG
General Ordered-Descendant Directed Acyclic Graph. DAG zur Repräsentation von Interferenz-Markup.
Graph
Menge von Knoten (Vertices) und gerichteten oder ungerichteten Kanten (Edges) als Knotenpaare zur universellen Repräsentation und Modellierung verschiedener Datenstrukturen [114]. Im Kontext dieser Arbeit ist der FML-Graph gemeint.
Graphdekomposition
Siehe Serialisierung.
Graphkomposition
Siehe Deserialisierung.
Graphtransformation
Konstruktion neuer Graphen durch Anwendung von Ersetzungsregeln
einer Graph-Grammatik [89].
GXL
Graph eXchange Language. XML-basierte Sprache zur Beschreibung
von Graphen. Projektseite: http://www.gupro.de/GXL.
Hierarchie
Baumartige Ordnung zwischen Parents und Children. Seit Comte [30]
ein geläufiger Terminus über den klerikalen Ursprung hinaus zur Kennzeichnung von Rangordnung, Abstufung und des Verhältnisses der
Über- und Unterordnung [132]. Datenstruktur von XML (siehe DOM
und XDM ) ist eine ∼.
HL7
Standardisierte XML-Anwendungen für den internationalen Datenaustausch im Gesundheitswesen. Spezifikationen: http://www.hl7.org.
212
HTML
HyperText Markup Language. SGML-Anwendung, typographische
Beschreibungssprache und Publikationsstandard für Browser im World
Wide Web. Spezifikation: [174].
Identifizierung
FML-Konzept zur sicheren Verknüpfung zweier korrespondierender Tags,
die sich in derselben Perspektive und im selben Namensraum befinden
und durch denselben Tag-Namen gekennzeichnet sind. Dieser Mechanismus findet Anwendung in einem FML-Dokument, wenn interferente
Strukturen mit gleichnamigen Elementen auszuzeichnen sind.
IDML
InDesign® Markup Language. Offener XML-Standard für professionelle Publikationen mit Adobe InDesign CS5 .
Independenz
FML-Spracheigenschaft. Freestyle-Konzept, das die Auszeichnung heterogener Perspektiven in einem redundanzfreien Dokument ermöglicht. Impliziert die Anwendung von Crossover-Markup und überwindet einen Hierarchiezwang.
Inhalt
FML-Komponente. Repräsentiert den eigentlichen Inhalt eines FMLDokumentes ausserhalb von Markup und besetzt verteilt ausschliesslich die Blätter eines FML-Graphen. Auch die Wertbelegungen von
Attributen sind Inhalte. Siehe Kap. 4.1.2.
Interferenz
FML-Spracheigenschaft. Freestyle-Konzept, das überlagernde Auszeichnungen (auch Crossover-Markup, Concurring-Markup oder Overlapping-Markup) ermöglicht und zugunsten restriktionsfreier und intuitiver Markups einen Hierarchiezwang überwindet.
Java
Populäre plattformunabhängige objektorientierte Programmiersprache
der Firma Sun Microsystems.
Komponente
Oberbegriff für alle abzugrenzenden Einheiten in einem FML-Dokument: das Dokument selbst, Inhalte und Markups (Prolog, Tags, Kommentare, Processing Instructions und Wildcards).
Kommentar
Markup-Komponente. Dokumentation im Inhalt. Siehe Kap. 4.1.6.
213
Kongruenz
FML-Spracheigenschaft. Freestyle-Konzept, das gleichberechtigte Auszeichnungen ermöglicht und einen Hierarchiezwang überwindet.
LaTeX
Lamport Textsatzsystem. Primär prozedurale Auszeichnungssprache
(PML). Autoren-Dokumentation: [92].
LL(1)-Parser
Ein deterministischer LL-Parser der während der Abarbeitung der
Eingabe von links nach rechts genau ein Token vorausschauen kann
(Lookahead=1).
LL-Parser
Ein Abwärtsparser zur Analyse formaler Sprachen, die auf kontextfreien Grammatiken basieren. Ziel ist die Rekonstruktion des Ableitungsbaumes der geparsten Zeichenfolge.
LMF
Lexical Markup Framework. Computerlinguistisches Modell als Grundlage für XML-Dokumente zur Repräsentation von Wortschätzen im
Rahmen der natürlichen Sprachverarbeitung. Spezifikation: [2].
LMNL
Layered Markup and Annotation Language. Auszeichnungssprache
mit eigenständiger Grammatik, die interferente Strukturierung ermöglicht. Projektseite: http://www.piez.org/wendell/LMNL/lmnl-page.html.
Lookahead
Anzahl der Token, die ein Parser vorausschauen kann. Aufwandsindikator.
Markup
Markierung (oder das Markieren) von Inhalten, Text oder Daten in
strukturelle und semantische Einheiten mittels typographischer Dekoration oder durch Tags. In einem FML-Dokument wird jeder eingebettete Code als Markup bezeichnet, somit ist Markup der Oberbegriff
für die FML-Komponenten Prolog, Tag, Kommentar, Processing Instruction und Wildcard.
MCT
Multi-Colored Trees. Lösungsansatz für die Anforderung Independenz.
Element-Hierarchie-Zuordnung mittels Knotenfärbung. Datenmodell,
Implementierung und Abfragesprache.
214
MuLaX
Multi-Layered XML. Auszeichnungssprache, die als Schnittmenge der
Sprache XML und dem SGML-CONCUR-Mechanismus multiple Annotationen ermöglicht. Datenmodell, Implementierung und Editor.
MultiX
Technologie zur Serialisierung mehrfach strukturierter Dokumente mittels Fragmentierung und virtueller Elemente. Datenmodell und Abfragesprache.
Namensraum
Klassifikationsmechanismus durch frei wählbare Bezeichner, konventionsgemäss URI s, die Elementen und Attributen zugeordnet werden, diese in Kontextmengen zusammenführen, voneinander abgrenzen. Ziel ist neben semantischer Gruppierung die Unterbindung von
Namenskonflikten durch Bezeichnerduplikate. Deklaration eines Namensraumes erfolgt im Prolog eines FML-Dokumentes.
namespace
Siehe Namensraum.
NITE
Technologie zur Verwaltung von Dokumenten über verschiedene (linguistische) Annotationsebenen mittels Stand-Off-Markup. Datenmodell, Abfragesprache und Implementierung. Projektseite: http://groups.
inf.ed.ac.uk/nxt.
NXT
NITE XML Toolkit. Siehe NITE.
OASIS
Organization for the Advancement of Structured Information Standards. Institution, die die Entwicklung offener Standards in den Formaten SGML und XML fördert.
OHCO
Ordered Hierarchy of Content Objects. Eine im Jahr 1990 aufgestellte
und bis heute prägende Interpretation von Text als eine monohierarchische Komposition.
OmniMark
Applikation der Stilo International PLC, veröffentlicht 1990, zur Konvertierung zwischen beliebigen Datenformaten im Allgemeinen und
SGML/XML-Instanzen im Speziellen. Besticht im Vergleich zu XSLT
durch hohe Performance. Projekt-Seite: http://developers.stilo.com.
215
Overlapping-Markup
Siehe Interferenz.
Parent
Übergeordnetes Element in einer Hierarchie. Antonym: Child.
Parser
Werkzeug zur syntaktischen Analyse von Dokumenten. Erzeugt aus
den Ergebnissen eines Scanners einen hierarchischen Ableitungsbaum
(Parse-Tree) dessen Knoten den Nichtterminalsymbolen bzw. Tokens
einer EBNF -Grammatik entsprechen.
Perspektive
Begriff des Freestyle-Konzeptes Independenz und konkrete semantische Interpretation eines FML-Dokumentes. Perspektiven können im
Prolog deklariert werden. Jedes Tag ist mindestens einer Perspektive
zugeordnet bzw. der default-Perspektive. Die Transformation eines
FML-Dokumentes in einen FML-Graphen kann auf relevante Perspektiven begrenzt werden.
PML
Siehe Procedural Markup Language.
Procedural Markup Language
Auszeichnungssprache, die prozedurale Anweisungen, zumeist typographische Darstellungsinstruktionen, in Dokumente integriert. Gegenteil
der DML. Vertreter ist LaTeX .
Markup-Komponente. Identifiziert und instruiert einen externen Prozessor. Konzept der Procedural Markup Languages. Siehe Kap. 4.1.7.
Prolog
Markup-Komponente. Dokument-, Perspektive- und Namensraum-Deklarationen zu Beginn eines FML-Dokumentes. Alle Prolog-Informationen
werden vom Root-Knoten (fml.node.document) eines FML-Graphen
gekapselt. Siehe Kap. 4.1.4.
RDBMS
Relational Database Management System. Verwaltungssystem für mathematische Relationen (Tabellen) zwecks Speicherung, Abfrage und
Manipulation von Daten. Entwickelt von Codd [28].
Root
Wurzel-Knoten in einem polyhierarchischen FML-Graphen. Kann Children
besitzen, aber keine Parents. In FML stellt stets document-node die
216
Root. Voraussetzung für den Zustand geschachtelt ist eine ElementRoot-Komponente, die alle anderen Elemente umfasst.
RSS
Rich Site Summary. RDF Site Summary. Really Simple Syndication.
Akronym als Überbegriff für XML-basierte Dateiformate zur Bereitstellung von Publikationsinhalten.
SAX
Simple API for XML. Programmierschnittstelle für einen XML-Parser,
der beim Lesen eines XML-Dokumentes als sequentiellen Datenstrom
Ereignisfunktionen zur Strukturauswertung auslöst. Spezifikation: http:
//www.saxproject.org.
Scanner
Mittel der ersten Arbeitsphase eines Compilers, der lexikalischen Analyse, für die Zerlegung der Zeichensequenz eines Dokumentes in eine
geordnete Liste von Tokens.
Scribe
Typographische DML mitsamt Compiler von Brian Reid’s [129]. Erste
Auszeichnungssprache, die eine klare Trennung zwischen Struktur und
Präsentation vornahm. Beeinflusste die Entwicklung von GML und
ist konzeptioneller Vorläufer von HTML.
Segmentierung
FML-Spracheigenschaft. Freestyle-Konzept, das eine Element-Montage
über verteilt geordnete Segmente ermöglicht. Synthetische Konstruktion beliebiger Elemente aus der Inhaltssequenz eines Dokumentes.
Self-Overlapping-Markup
Überlagernde interpretationsunsichere Auszeichnungen durch Tags mit
denselben Namen. Spezialfall der Interferenz.
Serialisierung
Im Allgemeinen eine Konvertierung von Objekten auf eine persistenzfähige sequenzielle Darstellungsform. Im Kontext von FML eine Transformation eines FML-Graphen in ein FML-Dokument. Umkehrung der
Deserialisierung.
SGF
Sekimo Generic Format. XML-basiertes Format zur Verwaltung multipler Annotationsebenen. Vorläufer von XStandoff . Projektseite:
http://www.text-technology.de/sekimo.
217
SGML
Standard Generalized Markup Language. 1986 als ISO-Standard angenommene und auf GML basierende Auszeichnungssprache für Textdokumente, von der die funktionale Teilmenge XML abgeleitet wurde.
Geringe Akzeptanz durch zu hohe Komplexität. Spezifikation: [3].
SISR
Semantic Interpretation for Speech Recognition. XML-Anwendung
zur Unterstützung regelbasierter Spracherkennung. Empfehlung des
W3C . Spezifikation: [170].
SOAP
Simple Object Access Protocol. Netzwerkprotokoll für Datenaustausch
basierend auf einer XML-Transfersyntax. W3C -Empfehlung. Spezifikation: [182].
SQL
Structured Query Language. Sprache zur Instruktion eines RDBMS
zwecks Datendefinition, -abfrage und -manipulation.
SVG
Scalable Vector Graphics. XML-Anwendung zur Beschreibung zweidimensionaler Vektorgraphiken. Empfehlung des W3C . Spezifikation:
[177].
Tag
Markup-Komponente. Definiert Start- und/oder Endposition einer Inhaltsmarkierung und erzeugt somit Struktur im Dokument und Semantik für die Hervorhebung. Von Tags leiten sich die Elementknoten
in einem FML-Graphen ab. Es werden öffnende, schliessende, leere
und multiple Tags unterschieden. Siehe Kap. 4.1.5.
TEI
Text Encoding Initiative. Herausgeber einer Tag-Menge und eines
Kompendiums für das Auszeichnen linguistischer Daten mit XML.
Projektseite: http://www.tei-c.org.
TexMECS
Tex Multi-Element Code System. Auszeichnungssprache mit eigenständiger Grammatik, die interferente Strukturierung ermöglicht und
auf Transformation zu GODDAG-Strukturen zielt.
Token
Fragment einer Zeichensequenz als elementarer Baustein für den Prozess der lexikalischen Analyse von Dokumenten.
218
UCS
Universal Character Set. Eine gegenüber UTF-8 synchrone und praktisch gleichwertige Zeichenkodierung. Definiert in der internationalen
Norm ISO/IEC 10646.
UML
Unified Modeling Language. 1996 veröffentlichte Sprache für die Modellierung von Softwaresystemen. Standardisiert von der Object Management Group und ISO (ISO/IEC-Standard 19501). Spezifikation:
http://www.omg.org/spec/UML.
URI
Lokalisiert als Ressourcenbezeichner eindeutig eine physische oder abstrakte Identität. Verwendung bei Namensraum-Deklarationen.
UTF-8
8-bit Unicode Transformation Format. Kodierung zur Darstellung von
Schriftzeichen. Standardisiert von Internet Engineering Task Force,
Unicode Consortium und ISO. Spezifikation: http://tools.ietf.org/html/
rfc3629.
valide
Gültigkeitszustand für eine FML-Instanz. Entspricht eine FML-Instanz
der Strukturbeschreibung eines FML-Schemas, so ist die Sprachinstanz
gegenüber dem Schema als valide zu bezeichnen.
VoiceXML
XML-Anwendung zur Beschreibung von Abläufen in einem Sprachdialogsystem. Empfehlung des W3C . Spezifikation: [121].
W3C
. Institution, die sich mit der StanWorld Wide Web Consortium
dardisierung von verschiedenen für das World Wide Web relevanten
Technologien, insbesondere XML, auseinandersetzt.
Wildcard
Markup-Komponente. Platzhalter für Auszeichnungen mit unvorhersehbaren oder unbekannten Details. Siehe Kap. 4.1.8.
wohlgeformt
Ein linguistisch geprägtes Kriterium für die Erfüllung von Grammatikregeln. Gültigkeitszustand für ein FML-Dokument, der die grammatikalische Korrektheit einer Sprachinstanz verlangt. Entspricht ein
FML-Dokument syntaktisch der Grammatik der Sprachspezifikation,
so ist es wohlgeformt. XML-Dokumente sind wohlgeformt, wenn sie
den Produktionsregeln der Sprachspezifikation [186] entsprechen.
219
WSDL
Web Service Description Language. Auf XML-Transfersyntax basierende Beschreibungssprache für Netzwerkdienste zum Datenaustausch.
W3C -Vorschlag. Spezifikation: [175].
WYSIWYG
What You See Is What You Get. Begriff für eine Klasse von Textverarbeitungssystemen, in denen ein Autor bereits während des Dokumenterstellungsprozesses das finale Druckergebnis vor Augen hat.
X3D
eXtensible 3D. XML-Anwendung zur Beschreibung von 3D-Modellen.
ISO/IEC-Standard 19775:2004.
Spezifikation: http://www.web3d.org/x3d/specifications.
XCONCUR
XML-CONCUR. Weiterentwicklung der Sprache MuLaX . Schwerpunkt:
Validierung und Implementierung.
XDM
XQuery und XPath Data Model. Hierarchisches Datenmodell eines
XML-Dokumentes für standardisierte XPath-Zugriffspfade bei Dokumentabfragen und -transformation mittels XSLT . Spezifikation: [184].
XHTML
Extensible HyperText Markup Language. Weiterentwicklung des HTMLStandards mit dem Primäranspruch der vollständigen XML-Kompatibilität. Spezifikation: [176].
XInclude
XML Inclusions. XML-Konzept zur Modularisierung und Inklusion
von Dokumenten. Spezifikation: [180].
XML
Extensible Markup Language. Auf SGML basierende und 1998 vom
W3C empfohlene Auszeichnungssprache, die sich als Transfersyntax
und Serialisierungsformat durchgesetzt hat und heute allgemein akzeptierter Standard ist. Spezifikation: [186].
XPath
XML Path Language. Abfragesprache zur Adressierung von Knoten
innerhalb des Objektmodells (siehe DOM und XDM ) eines XMLDokumentes. Erlaubt die Navigation durch die XML-Baumstrukur
und stellt verschiedene Funktionen zur Manipulation der Abfrageergebnisse bereit. Spezifikation: [183].
220
XSD
XML Schema Definition. Eine Sprache zur syntaktischen und semantischen Beschreibung und Validierung von XML-Dokumenten. Diese
2001 vom W3C ratifizierte Meta-Sprache ist selbst wiederum eine
durch eine XSD validierte XML-Instanz. Neben anderen Schemasprachen (Schematron, DTD, RELAX NG) hat sich die XSD hinsichtlich
Akzeptanz und Verbreitung als De-Facto-Standard etabliert. Spezifikation: [179].
XSL-FO
Extensible Stylesheet Language - Formatting Objects. XML-Anwendung und typographische Beschreibungssprache für medien-unabhängige Publikationen (Cross Media Publishing). Agiert in aller Regel im
Zusammenwirken mit XSLT . Spezifikation: [181].
XSLT
Extensible Stylesheet Language Transformations. Sprache zur regelbasierten Transformation einer XML-Instanz einer XSD in eine Instanz
einer anderen XSD bzw. zur Transformation einer Quellbaumstruktur
(konform XDM ) in eine Zielbaumstruktur (konform XDM ). Ursprünglich zur Erzeugung von XSL-FO entwickelt, heute jedoch für beliebige
Zieldokumente gebräuchlich. Spezifikation: [185].
XStandoff
Weiterentwicklung von SGF .
221
API, 90, 91, 117, 124, 208
ASG, 83, 208
Attribut, 60, 208
Auszeichnung, 208
Auszeichnungssprache, 1, 4, 5, 8–
10, 12, 16, 24, 33, 37, 67,
121, 128, 134, 136, 208
deklarativ, 209
prozedural, 216
Element, 58, 210
ER-Modell, 122, 196, 211
ERM, 211
FictionBook, 24, 211
FML, 211
Anforderungen, 17
Architektur, 42
Beispiel, 158, 164
Compiler, 171
Datenbankschema, 196
Dokument, 44
Graph, 55
Implementierung, 90
Integrität, 97
Klassendiagramm, 194
Konzepte, 65
Potenziale, 10
Ressourcen, 206
Sekundärtechnologien, 118
Spezifikation, 170
Umfrage, 198
Vergleichsanalyse, 125
Zielsetzung, 1
FML-Dokument, 44, 211
FML-Grammatik, 97, 102, 211
FML-Graph, 55, 211
FML-Instanz, 43, 54, 105, 106, 135,
211
Fragmentierung, 80, 211
Freestyle, 11, 38, 129, 133, 135,
198, 205, 211
Balisage, 2, 16, 206
Child, 208
CMP, 135
CMS, 135, 208
Coco/R, 52, 66, 83, 91, 98, 162,
168, 171, 207, 208
Compiler, 83, 171, 209
CONCUR, 102, 126, 127, 129, 209
Concurring-Markup, 209
Cross Media Publishing, 26, 209
Crossover-Markup, 209
DAG, 64, 209
Deserialisierung, 90, 209
DML, 3, 209
DocBook, 24, 209
Dokument, 45, 55, 209
DOM, 29, 210
DSSSL, 120, 210
DTD, 99, 210
DTP, 2, 4, 210
EBNF, 17, 49, 52, 97, 98, 207, 210
EDI, 4, 7, 210
EDMS, 135, 210
geschachtelt, 19, 28, 54, 212
GML, 7, 134, 212
GODDAG, 125, 128–130, 212
222
Graph, 13, 55, 212
Graphdekomposition, 85, 212
Graphkomposition, 82, 212
Graphtransformation, 39, 82, 106,
212
GXL, 64, 178, 207, 212
OmniMark, 120, 215
Overlapping-Markup, 216
Parent, 216
Parser, 2, 14, 48, 52, 53, 91, 98,
102, 135, 171, 207, 216
Perspektive, 22, 24–26, 46–48, 56–
58, 67, 72, 75, 83, 84, 94,
101, 103, 118, 216
PML, 3, 216
Processing Instruction, 48, 61, 216
Prolog, 46, 55, 216
Hierarchie, 19, 36, 54, 100, 118,
133, 212
HL7, 9, 212
HTML, 5–7, 21, 24, 116, 122, 134,
165, 213
RDBMS, 134, 216
Root, 19, 45, 54, 55, 64, 117, 216
RSS, 99, 217
Identifizierung, 72, 213
IDML, 24, 213
Independenz, 75, 213
Inhalt, 45, 58, 213
Interferenz, 71, 213
SAX, 135, 217
Scanner, 14, 53, 83, 90, 207, 217
Scribe, 7, 134, 217
Segmentierung, 78, 217
Self-Overlapping-Markup, 22, 23,
217
Serialisierung, 92, 217
SGF, 127, 129–131, 217
SGML, 10, 18, 33, 102, 126, 127,
129, 134, 176, 218
SISR, 25, 218
SOAP, 7, 218
SQL, 122, 218
SVG, 24, 218
Java, 1, 90, 116, 127, 213
Kommentar, 48, 60, 213
Komponente, 44, 213
Kongruenz, 74, 214
LaTeX, 12, 24, 214
LL(1)-Parser, 52, 83, 102, 171, 214
LL-Parser, 91, 214
LMF, 25, 214
LMNL, 125, 129, 130, 214
Lookahead, 52, 102, 214
Markup, 2, 3, 6, 9, 45, 65, 214
MCT, 126, 129–131, 214
MuLaX, 126, 129–131, 215
MultiX, 126, 129–131, 215
Tag, 47, 58, 218
TEI, 127, 129–131, 218
TexMECS, 125, 128–131, 218
TIMBER, 126
Token, 53, 83, 98, 110, 218
Namensraum, 22, 47, 48, 67, 68,
72, 82–84, 86, 94, 99, 101,
111, 118, 176, 215
namespace, 215
NITE, 126, 129–131, 215
NXT, 127, 215
UCS, 53, 83, 85, 113, 175, 219
UML, 194, 219
URI, 219
UTF-8, 45, 52, 53, 58, 83, 85, 89,
116, 121, 123, 124, 174,
175, 219
OASIS, 215
OHCO, 19, 215
valide, 28, 54, 119, 219
223
VoiceXML, 25, 219
W3C, 7, 100, 116, 219
Wildcard, 49, 62, 219
wohlgeformt, 17, 54, 99, 219
WSDL, 7, 220
WYSIWYG, 3, 220
X3D, 25, 220
XCONCUR, 102, 126, 129–131, 220
XDM, 29, 31, 220
XHTML, 7, 21, 24, 116, 120, 220
XInclude, 28, 220
XML, 1, 17, 18, 31, 73, 86, 92, 99,
127, 133, 135, 136, 174,
198, 220
XPath, 29, 120, 220
XSD, 25, 43, 86, 119, 176, 178,
183, 221
XSL-FO, 24, 120, 221
XSLT, 89, 120, 188, 221
XStandoff, 105, 127, 129–131, 221
224

Freestyle Markup Language - E-LIB

Transcription

Similar documents

Jetzt alle pCon.planner Funktionen ansehen

756 - Verlag der Zeitschrift für Naturforschung

Benutzeradaptive Web-Informationssysteme

Völser Zeitung Mai-Juni 2010

Ausgabe 08/2016 als PDF

Food Innovation - KErn

Druckfeste Gehäuse

wat war lass?

Brochüre „Hermes Superabrasives - CBN

Professionelles Management von Stiftungen