XML in der Praxis. Professionelles Web-Publishing mit der Extensible Markup Language, 2.Auflage GERMAN

Henning Behme Stefan Mintert

XML in der Praxis Professionelles Web-Publishing mit der Extensible Markup Language

An imprint of Pearson Education München • Boston • San Francisco • Harlow, England Don Mills, Ontario • Sydney • Mexico City Madrid • Amsterdam

Bitte beachten Sie: Der originalen Printversion liegt eine CD-ROM bei. In der vorliegenden elektronischen Version ist die Lieferung einer CD-ROM nicht enthalten. Alle Hinweise und alle Verweise auf die CD-ROM sind ungültig.

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Ein Titeldatensatz für diese Publikation ist bei der Deutschen Bibliothek erhältlich.

Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar. Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig. Falls alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden. Umwelthinweis: Dieses Buch wurde auf chlorfrei gebleichtem Papier gedruckt. Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus umweltfreundlichem und recyclingfähigem PE-Material.

10 9 8 7 6 5 4 3 2 1 03 02 01 00 ISBN 3-8273-1636-7 © 2000 by Addison-Wesley Verlag, ein Imprint der Pearson Education Deutschland GmbH, Martin-Kollar-Straße 10–12, D-81829 München/Germany Alle Rechte vorbehalten Einbandgestaltung: atelier für gestaltung, niesner & huber, Wuppertal Lektorat: Sylvia Hasselbach, [email protected] Korrektorat: Annette Lennartz, Bonn Herstellung: Elisabeth Egger, [email protected] Satz: reemers publishing services gmbh, Krefeld Druck und Verarbeitung: Schoder, Gersthofen XML-Processing: Stefan Mintert Printed in Germany

Für Kersten. H. B. Für Martin, Michaela und Ute S. M.

Nichts ist mächtiger als eine Idee, deren Zeit gekommen ist. Victor Hugo

Inhaltsverzeichnis Vorwort

17

1 Einführung

21

1.1

Warum mehr weniger ist

24

1.2

Warum mehr mehr ist

25

1.3

Wohin die Reise geht

27

2 Was sind Dokumente?

33

2.1

Eine kurze Geschichte der Textverarbeitung

33

2.2

Bestandteile eines Dokumentes

34

2.3

Die neue, alte Idee: Strukturorientiert schreiben

35

2.4

Die Entwicklung des Hypertextes

38

2.5

Textformate im Web

41

2.6

Das SGML-Konzept: Generic Markup

41

2.7

Dokumente versus Daten

44

3 XML im Web

47

3.1

XML bei der Verwaltung von Websites

48

3.2

Clientseitige XML-Interpretation

50

3.2.1

XML mit CSS

3.2.2

XML mit XSL(T)

50 50

3.3

XML auf dem Server

51

3.4

Linking-Möglichkeiten von XML

52

3.5

XML als Datenaustauschformat

52

4 XML Quick Start 4.1 4.2

Dokumenttyp-Definition (DTD) und Instanzen

53 53

Verarbeitung der Dokumente

56

4.2.1

Beispiel: Verarbeitung mit Cost/TCL

56

4.2.2

Beispiel: Verarbeitung mit XSLT

59

4.2.3

Beispiel: XML/XSLT im Internet Explorer

61

4.2.4

Fazit

63

9

Inhaltsverzeichnis

5 XML-DTDS: Die verständliche Beschreibung 5.1

Ein Wort zur Notation

65

5.2

Dokumente

66

5.3

Elemente

68

5.4

Zeichen, Namen und Zeichendaten

70

5.5

Kommentare

72

5.6

Processing Instructions

74

5.7

Wo bleibt »Multimedia«?

75

5.8

Dokumenttyp-Definition (DTD)

76

5.8.1

77

Elementtyp-Deklaration

5.8.2

Attributlisten-Deklaration

79

5.8.3

Möglichkeiten, die DTD zu gestalten und zu gliedern

81

5.8.4

Notation-Deklaration

84

6 Namensräume in XML

87

7 XPath: Adressierung von XML-Dokumentteilen

91

7.1

Zu Grunde liegendes Datenmodell

92

7.2

Zugriff auf den Datenbaum

93

7.3

Hilfe von Operatoren

97

7.4

Kernfunktionen für den Datenzugriff

98

8 XML: Linking

103

8.1

Notwendige Begriffe

8.2

XLink: einfache und erweiterte Links

105

8.2.1

Einfache Verweise

105

8.2.2

Erweiterte Links

109

8.2.3

XLink in der Praxis

8.3

9.1

104

115

XPointer: Verweise in Dokumente hinein

115

8.3.1

119

XPath-Erweiterungen in XPointer

9 Überblick über Stylesheet-Sprachen

10

65

123

Cascading Style Sheets

126

9.1.1

127

Wertzuweisungen

9.1.2

Formatierungsmodell

129

9.1.3

CSS und XML

130

9.1.4

Ein Beispiel: XML im Mozilla

131

Inhaltsverzeichnis

9.2

9.3

Document Style Semantics and Specification Language

134

9.2.1

Flow Objects

136

9.2.2

Verarbeitungs-Modus

138

9.2.3

DSSSL praktisch

140

9.2.4

Langer Marsch von DSSSL nach HTML

143

Extensible Stylesheet Language (XSLT und XSL)

147

9.3.1

Verhältnis von XSLT zu XSL

147

9.3.2

Formatierung mit XSL

148

10 XSL-Transformationen

149

10.1 Grundsätzliches über Templates

150

10.2 Ergänzungen zum Datenmodell von XPath

154

10.3 Struktur von XSLT-Stylesheets

154

10.4 Den Ergebnisbaum erzeugen

160

10.4.1

Diverse Basiselemente

160

10.4.2

Formatierte Nummerierung

165

10.4.3

Schleifen und bedingte Verarbeitung

167

10.4.4

Sortieren

170

10.4.5

Variable und Parameter

170

10.4.6

Zusätzliche Funktionen

173

10.4.7

XSLT-Erweiterungen

175

10.4.8

message, output

175

11 XSLT in Web-Anwendungen 11.1

179

XSLT im Internet Explorer

179

11.2

Linklisten erzeugen

182

11.3

Details einer Literaturgeschichte

190

11.3.1

Sortierte Überblicksseiten

191

11.3.2

Kalender: einzelne Tage ausgeben

197

12 XML-Editoren

205

12.1 Übersicht

205

12.1.1

Emacs + PSGML (mit XML-Unterstützung)

206

12.1.2

XML Notepad

206

12.1.3

XML Spy

206

12.1.4

XMetal

206

11

Inhaltsverzeichnis

12.1.5

Epic

206

12.1.6

MarkupKit (für MS Word)

207

12.1.7

WordPerfect Office2000

207

12.3 XML-Notepad

209

12.4 XML Spy

209

12.5 XMetal

210

12.6 Epic

213

12.7 MarkupKit (für MS Word)

214

12.8 WordPerfect Office2000

216

12.9 Fazit

219

13 Entwicklung einer DTD

221

13.1 Auswahl einer Mehrzweck-DTD

221

13.2 Entwurf einer DTD

222

13.2.1

Dokumentanalyse

223

13.2.2

Tipps und Tricks

227

13.3 Instanzen ohne DTD

236

14 Herstellung dieses Buches

237

14.1 Zielsetzung und Randbedingungen

237

14.2 Definition der DTD

238

14.2.1

Schritt 1: Die Grobstruktur

238

14.2.2

Schritt 2: Elemente auf Zeichenebene

239

14.2.3

Schritt 3: Die Details

240

14.3 Formatieren des Manuskriptes

241

14.3.1

Konvertierung in HTML

241

14.3.2

Aufbereitung für den Ausdruck

243

14.4 Erfahrungen mit der zweiten Auflage 15 Anwendungsbeispiel Literatur

12

207

12.2 Emacs und PSGML (mit XML-Unterstützung)

245 247

15.1 Vorüberlegungen

249

15.2 En détail: die Autoren in der DTD

251

15.3 Wie die Daten ins Web gelangen

256

15.3.1

Inhaltsverzeichnis generieren

257

15.3.2

Ausgabe der Autorendaten

261

Inhaltsverzeichnis

15.4 Vollständige Listings

266

15.4.1

DTD für die Literaturgeschichte

266

15.4.2

DSSSL-Listing: Inhaltsverzeichnis

268

15.4.3

DSSSL-Listing: Ausgabe eines einzelnen Autors

271

15.4.4

Perl-Code für Ausgabe einzelner Autoren

277

16 Verteilte Softwareverwaltung mit XML

279

16.1 Aufgabenbeschreibung

279

16.2 XML als Datenbasis

281

16.3 Bilden von DTD-Hierarchien

286

16.4 Zusammentragen von verteilten XML-Fragmenten

287

16.5 Fazit

288

16.6 Stylesheet zur Transformation in HTML

289

17 E-Commerce mit XML 17.1 B2B-E-Commerce 17.1.1

Die Rolle von XML

17.1.2

Technische Aspekte

295 295 295 297

17.2 BMEcat

297

17.3 Electronic Business xml (ebXML)

298

17.3.1

Arbeitsgruppen

299

17.3.2

Zeitplan des Projekts

300

17.4 XML und EDIFACT 18 XML und Apache 18.1 XML-Transformation per CGI

300 303 304

18.1.1

Konfiguration des Servers

18.1.2

CGI-Skript: xmlhandler.cgi

305

18.1.3

Beispiel: von HTML nach HTML mit DSSSL oder XSLT

310

18.2 Cocoon

304

317

18.2.1

Extensible Server Pages (XSP)

320

18.2.2

Beispiel: Formatierung in PDF mit XSL

342

18.2.3

Beispiel: Simuliertes XLink mit Dynamic HTML/JavaScript

349

18.2.4

Installation

354

13

Inhaltsverzeichnis

19 XHTML: Neues HTML 4 – erweiterbar

357

19.1 Status quo: HTML neu definiert

357

19.2 Modulare Zukunft

361

20 Transformation von XML in WML und HTML 20.1 Erzeugen der WML-Dateien

366

20.2 Erzeugen der HTML-Dateien

374

21 Ausblick

379

21.1 XML Schema

379

21.2 Programmierung mit XML-Daten

381

21.3 XML und Java

382

21.4 Resource Description Framework

383

21.5 Die Zukunft

384

A Extensible Markup Language (XML) 1.0 A.1

A.2

A.3

14

363

387

Einleitung

388

A.1.1

Herkunft und Ziele

389

A.1.2

Terminologie

390

Dokumente

391

A.2.1

Wohlgeformte XML-Dokumente

392

A.2.2

Zeichen

392

A.2.3

Allgemeine syntaktische Konstrukte

393

A.2.4

Zeichendaten und Markup

394

A.2.5

Kommentare

395

A.2.6

Processing Instructions

395

A.2.7

CDATA-Abschnitte

396

A.2.8

Prolog und Dokumenttyp-Deklaration

396

A.2.9

Standalone-Dokumentdeklaration

399

A.2.10

Behandlung von Leerraum

400

A.2.11

Behandlung des Zeilenendes

401

A.2.12

Identifikation der Sprache

401

Logische Strukturen

403

A.3.1

Start-Tags, End-Tags und Leeres-Element-Tags

404

A.3.2

Elementtyp-Deklarationen

405

A.3.3

Attributlisten-Deklaration

407

A.3.4

Bedingte Abschnitte

411

Inhaltsverzeichnis

A.4

Physikalische Strukturen

412

A.4.1

413

A.4.2

Entity-Deklarationen

415

A.4.3

Analysierte Entities

417

A.4.4

Behandlung von Entities und Referenzen durch einen 419 XML-Prozessor

A.4.5

Konstruktion des Ersetzungstextes von internen Entities

422

Vordefinierte Entities

422

A.4.6

A.5

Zeichen- und Entity-Referenzen

A.4.7

Notation-Deklarationen

423

A.4.8

Dokument-Entity

424

Konformität

424

A.5.1

Validierende und nicht-validierende Prozessoren

424

A.5.2

Benutzen von XML-Prozessoren

424

A.6

Notation

425

A.7

Anhang A: Referenzen

427

A.7.1

Normative Referenzen

427

A.7.2

Weitere Referenzen

427

A.8

Anhang B: Zeichenklassen

428

A.9

Anhang C: XML und SGML (nicht normativ)

432

A.10 Anhang D: Expansion von Entity- und Zeichenreferenzen (nicht normativ)

432

A.11 Anhang E: Deterministische Inhaltsmodelle (nicht normativ)

433

A.12 Anhang F: Automatische Erkennung von Zeichenkodierungen (nicht normativ) 434 A.13 Anhang G: XML-Arbeitsgruppe des W3C (nicht normativ)

436

B Verknüpfen von Style Sheets mit XML-Dokumenten Version 1.0

439

B.1

Die xml-stylesheet-Processing-Instruction

440

B.2

Anhang A: Referenzen

443

B.3

Anhang B: Begründung

443

C Verhältnis von XML zu SGML und HTML

445

C.1

XML und SGML

445

C.2

XML und HTML

453

15

Inhaltsverzeichnis

D Übersichten D.1

Cascading Style Sheets

455

D.1.1

CSS-Eigenschaften und -Werte

455

D.1.2

CSS-Muster

457

D.2

DSSSL: Flow Objects

458

D.3

Syntax der XSLT-Elemente

464

D.4

DTD-Fragment für XSLT-Stylesheets (nicht normativ)

469

D.5

D.6

16

455

Relevante Spezifikationen und Organisationen

477

D.5.1

International Organization for Standardization

477

D.5.2

World Wide Web Consortium

478

D.5.3

Organization for the Advancement of Structured Information Standards

478

D.5.4

Internet Society und Internet Engineering Task Force

479

D.5.5

ISO-639-Sprachcodes

479

D.5.6

ISO-3166-Ländercodes

480

D.5.7

Zeichensatz ISO-Latin-1

481

D.5.8

Sonderzeichen

XML-1.0-Regeln

485 487

Bibliographie

491

Glossar

497

Stichwortverzeichnis

507

Vorwort Dass diese Zeilen mit »Vorwort« überschrieben sind, ist aus Sicht der Autoren unzutreffend. Denn tatsächlich haben wir das »Vorwort« nicht vor Beginn unserer Arbeit geschrieben, sondern nach deren Beendigung. Zugegeben, die Überschrift »Nachwort« hätte wohl eine gewisse Verwunderung bei Ihnen, der Leserin, dem Leser, ausgelöst. Nicht nur bei der Wahl dieser Überschrift haben wir uns nach Ihnen gerichtet; wir haben versucht, das Buch auf Ihre Bedürfnisse auszurichten. Wie schwierig das ist, werden Sie hoffentlich nicht feststellen – sonst wäre es uns wohl nicht gut gelungen. Aber zum Glück gibt es ja das Vor/Nachwort. Hier können wir einige Worte darüber verlieren, was in welchem Kapitel steht; und vielleicht hilft es Ihnen dabei, herauszufinden, an welcher Stelle Sie mit der Lektüre beginnen. Denn obwohl »der Kunde König ist«, mussten doch wir eine Reihenfolge festlegen. XML ist es, wofür Sie und wir uns entschieden haben. Wir haben es aus Spaß und Interesse an der Sache getan, was waren Ihre Gründe? – Wenn Sie es noch nicht genau wissen, dann wird Ihnen vielleicht das erste Kapitel eine Antwort geben. Dort finden Sie auch die Gründe, warum das Web eine neue Sprache braucht. Dass vieles davon gar nicht so neu ist, zeigt das zweite Kapitel. Neben den Wurzeln von Hypertext und XML geht es dort auch um die Frage, woraus (Text-)Dokumente eigentlich bestehen. In Kapitel 3 betrachten wir die Anwendung von XML im Web von einer etwas höheren Warte, um Ihnen einen Überblick zu geben.

Das folgende Kapitel 4 wird dann konkret. Falls Sie noch niemals mit SGML oder XML gearbeitet haben, zeigt Ihnen unser Schnelleinstieg, wie XML praktisch aussehen kann. Wer eine vorsichtige Annäherung an ein komplexes Thema als langatmiges Gerede empfindet, sollte den Sprung in's kalte Wasser wagen und dort beginnen. Es schließt sich die Beschreibung der XML-Syntax (die so genannten DTDs) an. Wir haben versucht, diesen auf den ersten Blick schwierigen Teil möglichst einfach zu erklären; genannt haben wir es »Die verständliche Beschreibung«. Einen der spannendsten Aspekte von XML enthält das Kapitel 8: die gegenüber HTML erweiterten HyperlinkFeatures. Leider beherrscht dies noch kein Web-Browser. Die Verarbeitung von XML, zum Beispiel die Formatierung, ist ein wichtiger Punkt, dem gleich mehrere Kapitel gewidmet sind. Den Anfang macht unser Stilkapitel 9. Dort erfahren Sie einiges zu CSS, DSSSL und natürlich XSL(T). Wie man mit XMLDTDs Daten strukturiert, klärt das Kapitel 13. Seit dem Frühjahr 1998, als wir die erste Auflage abschlossen, ist XML noch mehr zum Hype-Thema geworden, als es damals war. Gleichzeitig haben aber auch zunehmend Webmaster und Firmen die Einsatzmöglichkeiten von XML erkannt und versucht umzusetzen. Dies vor allem in einem Bereich,

17

Vorwort

der ursprünglich nicht im Vordergrund des Interesses derer stand, die XML als »SGML for the Web« propagierten: als Datenaustauschformat im Geschäftsleben. Mehr dazu in Kapitel 17. Gleichzeitig haben die am World Wide Web Consortium Beteiligten die zum XML-Umfeld gehörenden Standards weiter »vorangetrieben«: die Spezifikation für die Formatierung von XML-Dokumenten ist ebenso wenig verabschiedet wie die beiden zum Linking (XLink und XPointer). Aber andere sind in der Zwischenzeit fertig geworden, darunter mit XPath und XSLT zwei für die Verarbeitung von XML-Dokumenten zentrale W3C-Empfehlungen. Zeitlich parallel dazu haben Einzelpersonen, Gruppen und Firmen Software entwickelt, die die Verarbeitung von XML unterstützt. Parser existieren u.a. in Java und C++, mehrere XSLT-Implementierungen sind frei verfügbar, und Bemühungen wie die Java-API für XML bei Sun sowie das Projekt der Apache-Gruppe sprechen eine deutliche Sprache, was die Bedeutung von XML angeht. Natürlich hatte diese Entwicklung Konsequenzen für diese zweite Auflage. Wir haben einerseits den neuen Standards Kapitel eingeräumt (7, 10), andererseits aber auch den Bereich der Anwendung deutlich erweitert (16, 12, 19). Schließlich haben wir mehr an Beispielen aufgenommen (11, 20). Einschränkend muss hier leider gesagt werden, dass auch diese Auflage nicht das sämtliche möglichen XML-Themen abdeckende Buch ist. Es muss noch Platz für andere sein... Mehrere Anhänge sollen das Nachschlagen erleichtern und Zusatzinformationen bieten. An erster Stelle ist die deutsche Übersetzung der Syntax-Spezifikation zu nennen, die denjenigen, die solch technische Texte lieber in deutscher Sprache lesen, den Zugang erleichtern soll. Und natürlich finden Sie dort ein Register und ein Glossar mit den wichtigsten Begriffen. Die Icons in diesem Buch Als Teil der net.com-Reihe besitzt dieses Buch de-

ren typische Gestaltung. Dazu gehören auch einige Icons, die Ihnen den Umgang mit dem Text erleichtern sollen. Folgende Icons sind vorhanden: Beispiele Kein Praxisbuch könnte ohne Beispiele auskommen. Deshalb wird Ihnen dieses Icon besonders häufig begegnen.

Hinweise Mit diesem Symbol möchten wir Sie auf Textstellen hinweisen, die

Ihre besondere Aufmerksamkeit verdienen.

Tipps und Tricks XML ist nicht schwer. Dennoch kann es nicht schaden, praktische Tipps zu bekommen.

18

Vorsicht! Auch XML hat einige Tücken. Mit diesem Symbol warnen wir Sie

rechtzeitig. Aktuelle Informationen Es ist unvermeidlich: Die Halbwertszeit von Com-

puterliteratur ist geringer als bei den meisten anderen Themen. Über aktuelle Entwicklungen sollten Sie sich im Web informieren. Wir versuchen, Sie dabei mit relevanten Links zu unterstützen. Besuchen Sie uns im Web unter der Adresse http://www.mintert.com/xml/. Außerdem sprechen beide Autoren häufig als Gastreferenten bei Konferenzen und Kongressen über neue Trends und Techniken. Auch darüber finden Sie im Web Informationen. Die CD-ROM zum Buch Da sich CDs in kürzerer Zeit produzieren lassen als Bücher, haben wir die CD zum Zeitpunkt, zu dem wir dieses Vorwort schreiben, noch nicht vorliegen. Aus diesem Grund steht noch nicht ganz genau fest, was die CD enthalten wird. In jedem Fall werden wir Beispiele und freie Software zur Verfügung stellen. Des weiteren versuchen wir, Testversionen von kommerziellen Produkten zu bekommen. Ob und welche Sie auf der CD finden, hängt davon ab, wie die Hersteller uns unterstützen. Eine genaue Inhaltsangabe und gegebenenfalls aktuelle Informationen finden Sie auf der CD selbst. Danksagung Für das mühevolle Korrekturlesen der Erstauflage bedanken wir uns bei Kersten Auel, Stefan Borggraefe, Rainer Stoll und Jens Thiemann. Für die Bugfixes zum Apache-Kapitel der aktuellen Auflage danken wir Kerstin Göker. Die Menschen bei Addison-Wesley, allen voran unsere Lektorin Sylvia Hasselbach, haben mit ihrer Unterstützung dafür gesorgt, dass das Buch entstanden ist. Ein Wort des Dankes gebührt auch all den Lesern beider Geschlechter, die die erste Auflage nicht nur gelesen, sondern uns auch über darin leider enthaltene Fehler informiert haben, sodass sie hoffentlich in dieser Ausgabe nicht mehr enthalten sind. Es muss noch Platz für andere sein...

Zum Schluss ein persönlicher Dank der beiden Autoren: Vor allem möchte ich Kersten Auel danken, die es mir mit Rat, Tat und Geduld möglich gemacht hat, dieses Buch mitzuschreiben. Und schließlich wäre dieses Projekt nicht realistisch gewesen, hätte ich nicht hauptberuflich in der iX-Redaktion von vornherein mit diesem Themenbereich zu tun gehabt.

Henning Behme Ich danke allen Menschen, die mich während der letzten Wochen unterstützt haben: meiner Familie und meinen Freunden. In besonderer Weise gilt dies für Martin & Michaela Koch und Ute Haupt. Abschließend für meine einzige wahre Droge: Thanks always to Jackson Browne for The Music.

Stefan Mintert Hannover/Dortmund, März 2000

19

1

Einführung

In here, thi trik is thinkin rite. Thas all u 1/2 2 do. U 1/2 2 think rite. U 1/2 2 b dairing & koshis, u 1/2 2 b ver sensibil & totily mad. Moast ov ol u 1/2 2 b cluvir, u 1/2 2 b ingenius. U 1/2 2 b abil 2 use whatevir is aroun u, & thass whot it reely cums doun 2; [...] so iss up 2 u reely what yoos u make ov it aftir that; iss ol about injinooty [...]1

Iain M. Banks So schwer verständlich wie dieses Motto, das einem britischen ScienceFiction-Roman2 entnommen ist, auf den ersten Blick wirkt, wird sich die Lektüre dieses Buches – hoffentlich – nicht gestalten. Denn wer dieses Buch liest, weiß aller Wahrscheinlichkeit nach zumindest, was die Hypertext Markup Language ist beziehungsweise wofür das Kürzel HTML steht. Im günstigen Fall haben potenzielle Leserinnen3 schon einmal selbst Hand an eine HTML-Datei gelegt, entweder mit einem WYSIWYG-Werkzeug oder gar im Quelltext. Letzteres wäre insofern eine ideale Voraussetzung, als dieses Buch naturgemäß viele Beispiele enthält, die in keinem WYSIWYG-Editor zu sehen sind, da es sich um Quelltexte handelt. Viele davon sind mit etwas HTML-Kenntnissen lesbar. Selbst die Beschreibungen von Dokumentstrukturen, die Dokumenttyp-Definitionen (DTD), mit denen man sich in HTML nie herumschlagen muss, sind so leicht verdaulich wie handelsübliche Prosa4. In jedem Fall wollen wir lieber eine Erläuterung zu viel als eine zu wenig vorsehen. Und das fängt bei den drei Buchstaben XML an. Die Extensible Markup Language, wie diese neue Sprache bei aufgelöstem Akronym heißt, ist nicht als Ersatz für HTML gedacht – das zur Beruhigung aller, die die Web-Auszeichnungssprache gerade gelernt haben. Sie ist mehr als HTML, weil sie erlaubt, etwas zu tun, das man bislang im Web nur mit zusätzlichen Werkzeugen – und in geringem Umfang – tun konnte: beliebige

XML:

erweiterbare Auszeichnungssprache

1. Diese Sprache ist nicht wirklich übersetzbar, aber wenigstens ein Versuch in einem Deutsch, das dem Original nacheifert, muss sein: Hia drin is der Trik: richtich denkn. Das alles, wassu machn muss. Dumus richtich denkn. Mus waagemuutich un voorsichtich sein, mus seer sänsibel und völich verük sein. Vor allem mussu klewwa sein – und ährfinnungsreich. Du mus als nuzn könn, was um dich rum soda ist, das eintlich als; [...] is dein Bier, wassu damit anfengs; als nua Finnungsgeiß [...] 2. Er heißt Feersum Endjinn, stammt aus dem Jahre 1994 und enthält auch Passagen in »normalem« Englisch. 3. Dass es sich auch um männliche Vertreter dieser Gattung handeln darf, versteht sich von selbst. 4. Hier sei dahingestellt, ob die DTD-Prosa eher Trivialliteratur oder THOMAS MANNs Zauberberg entspricht; letzteres wäre natürlich mehr als anmaßend.

21

1 Einführung

Elemente verwenden5. In der Objektorientierung hieße das Äquivalent abstrakte Datentypen (selbst geschaffene, wie Person et cetera, im Gegensatz zu den vorgegebenen, wie »int« oder »char«), und diese beliebigen Elemente werden sich als roter Faden durch das gesamte Buch ziehen. Um an dieser Stelle noch nicht allzu tief in XML einzudringen, sei nur ein winziges Beispiel angeführt: In HTML gibt es die – und nur die – in der HTMLDTD vorgesehenen Elemente wie H1 oder BLOCKQUOTE. In XML dagegen kann sich jede(r) beliebig viele eigene Elemente definieren: von REZEPT über URLAUBSERINNERUNG bis hin zu STRASSE, etwa in einem privaten Adressbuch. So enthielte eine Beschreibung der Struktur (d.i. die oben genannte Dokumenttyp-Definition) für ein Adressbuch wahrscheinlich außer einem Element wie ADRESSBUCH (das das gesamte Dokument einschließt, wie das Element HTML in Web-Dokumenten) weitere Elemente wie VORWAHL, TELNR und PLZ, die innerhalb einer ADRESSE6 hierarchisch geschachtelt wären (und sein müssen). Grenzen von HTML

HTML ist mittlerweile eine recht komplizierte Sprache geworden. Version 4 [RAGG98] beinhaltet wesentlich mehr, als TIM BERNERS-LEE sich Ende der achtziger, Anfang der neunziger Jahre hätte träumen lassen. Dennoch hat HTML gewisse Grenzen. Da ist zum einen der eingeschränkte Vorrat an Elementtypen (von HTML selbst bis zu P und EM), zum anderen besteht die Gefahr, dass der vielbeschworene Standard allmählich auseinander driftet. Dem war natürlich etwas entgegenzusetzen. Womit wir bei XML sind – und ob respektive wie dieser neue Standard dieses Auseinandertreiben verhindern kann.

Hinter fremden Dingen kann sich Spaß verbergen. Das oben zitierte Motto steht hier unter anderem dafür – und natürlich hat es inhaltlich mit dem zu tun, was in diesem und den nächsten Kapiteln folgt. Denn angemessenes (Nach-)Denken (»thinkin rite«) kann bei beliebig tief strukturierten Dokumenten – um die geht es schließlich – nicht verkehrt sein; vor allem dann, wenn sie (auf unterschiedliche Weise) beim Leser beziehungsweise Surfer ankommen sollen. Um das Motto noch ein wenig zu strapazieren: Ein Dokument bedeutet das, was diejenigen, die es verfassen (und diejenigen, die es rezipieren), darin lesen wollen beziehungsweise können. Erfindungsreichtum (»injinooty«) ist gefragt. Das hat mit dem Thema dieses Buches insofern viel zu tun, als die Extensible Markup Language (XML) andere Fähigkeiten erfordert als die bisherige Sprache des Web (HTML). Neben dem reinen Markup kommen eine formale Beschreibung der Dokumentstruktur sowie Formatvorgaben für die 5. Gemeint ist hier, dass einige Werkzeuge dem festen Satz an HTML-Elementen neue hinzufügen, die vor der Ausgabe an den Browser ein Programm wandeln beziehungsweise bearbeiten. Als Beispiel sei das Element gtext genannt, das nur der Web-Server Roxen kennt und der so markierten Text als grafische Zeichen ausgibt. 6. ADRESSBUCH wäre hier gewissermaßen die Bezeichnung für die Art des Dokuments, wohingegen die einzelnen Adressen dessen Inhalt bilden. Genauer: Ein Adressbuch enthält beliebig viele Adressen, diese wiederum Namen und Straßenbezeichnungen et cetera.

22

Ausgabe im Web und anderswo hinzu. Formatvorgaben kennen Sie vielleicht über die Cascading Style Sheets (CSS) in HTML. In Kleinbetrieben etwa dürfte die Strukturbeschreibung des Dokuments (eine Dokumenttyp-Definition) entweder jemand außer Haus erledigen, oder der bisherige HTML-Autor muss anfangen, sich damit zu beschäftigen, wie man derlei zu Wege bringt. In Kapitel 13 ist dazu Einführendes zu lesen. Bevor es ins Detail geht, soll ein Schaubild den Zusammenhang, in dem sich das Folgende bewegt, deutlich machen. Abbildung 1.1 zeigt, dass auf der linken Seite SGML, XML und HTML in eine Reihe gehören.

formatiert

Abbildung 1.1: Zusammenhang von SGML, XML, HTML, CSS und DSSSL

DSSSL

HTML

SGML definiert XML

formatiert

CSS

XHTML

beeinflusst

Metasprachen

& transformiert

formatiert & transformiert

XSL XSLT

Auszeichnungssprachen Formatierungs- und Transformationssprachen

ist eine Teilmenge von SGML. Für beide gilt, dass DSSSL-Stylesheets auf sie anwendbar sind. XML-Daten lassen sich allerdings auch in Verbindung mit CSS, Level 2, anzeigen. HTML schließlich ist eine SGML-Anwendung, eine Dokumenttyp-Definition. Mit ein paar Veränderungen hat das World Wide Web Consortium (W3C) Anfang 2000 HTML als eine Anwendung von XML umgesetzt. Das heißt, das Konsortium hat HTML in XML (statt SGML) neu definiert. Nur für HTML waren ursprünglich die Cascading Style Sheets gedacht, die sich jetzt auch auf XHTML anwenden lassen. XML

XSL schließlich soll die Stilsprache für XML werden; sie entspricht von den Funktionen her der Online-Variante von DSSSL – beziehungsweise die Tools, die XSL »sprechen«, werden diese Eigenschaften dem Anwender zur Verfügung stellen. Dabei handelt es sich erstens um die Formatierobjekte (XSL-FO), die aus XML-Dokumenten zum Beispiel Adobes Portable Document Format (PDF) erzeugen, und zweitens die Transformationen (XSLT), die es ermöglichen, XML-Dokumente von einer Struktur in eine andere zu wandeln (beispielsweise ein Adresssbuch in HTML).

23

1 Einführung

1.1

Warum mehr weniger ist

Schon HTML kann kompliziert sein

Schön, dass es HTML gibt – nur sieht selbst diese Sprache für Anfänger gelegentlich ähnlich rätselhaft aus wie das anfängliche Motto; vor allem dann, wenn der Web-Meister sich mit Tabellen, unsichtbaren GIFs und herstellereigenen Zusätzen ausgetobt hat. Allerdings: Ganz so kompliziert, wie das Motto beim ersten Lesen vielleicht gewirkt hat, ist diese einfache Auszeichnungssprache namens Hypertext Markup Language nicht – nicht einmal dann, wenn man die oben erwähnten Cascading Style Sheets als Sprachergänzung zur Formatierung von Dokumenten hinzunimmt. Denn es handelt sich insgesamt um circa 70 Elementtypen – oft ungenau Tags genannt7 –, die eine Basisstruktur von Texten (Überschriften, Absatz, Zitate, Listen, Tabellen) abbilden. Darüber hinaus enthält HTML Anweisungen für Stilarten (Betonung) – bis hin zu solchen, die festlegen sollen, ob ein Wort (oder mehrere) kursiv oder fett gedruckt zu sein habe. Vom Blinken, das Netscape leider eingeführt hat, soll hier nicht die Rede sein.

Trennung von Markup und Formatierung

Eigentlich waren schon diese auf das Display bezogenen Elemente (I und B) eine Abweichung von der reinen Lehre des strukturierten Markup. Aber sie waren nichts gegen das, was danach kam. Was wiederum damit zu tun hatte, dass nach dem ersten Internet-Boom (1994) die Anwender – diejenigen, die WWW-Dokumente erstellen wollten – mehr an Gestaltungsmöglichkeiten suchten; und sie bekamen sie: Tabellen, blinkende Strings... Was bleibt, ist die Tatsache, dass HTML in den letzten Jahren eine stürmische Entwicklung genommen hat – getragen von Erweiterungen, wie sie im Wesentlichen Netscape (durch Frames, die HTML ergänzende Scriptsprache JavaScript sowie Layers) und Microsoft (VB-Integration und Dynamic HTML) eingeführt haben. Datenbankanbindungen über Perl sowie kommerzielle (Zusatz-)Produkte von DBMS-Anbietern runden das Wirrwar ab. Soweit es denn als Wirrwar empfunden wird. Nicht zu vergessen die oben angedeutete Erweiterung der HTML-Elemente durch Software, die die Web-Dokumente durchgeht (parsing) und nach einer bestimmten Markierung sucht (und daraufhin Aktionen durchführt).

Gefahr der Aufsplittung des Web durch proprietäre Erweiterungen

Mehr ist in diesem Zusammenhang tatsächlich weniger, weil die fortlaufende Ergänzung einer Sprache durch von Industrie und Autoren gewünschte oder von Herstellern erahnte Tools und Elemente schnell ins Web-Chaos führen könnte. Der Versuch, die eigenen Datenbankinhalte ins Web zu bringen, ist schon heute davon abhängig, mit welchem DBMS man arbeitet, denn dessen (proprietäre) Web-Lösung wird man nutzen müssen, wenn man sich nicht auf die Möglichkeiten von Perl oder anderen Programmiersprachen beschränkt beziehungsweise konzentriert.

7. Elementtypen sind die aus HTML bekannten P und H3. Sie haben, wenn man HTML »richtig« schreibt, jeweils ein Start- (

) und ein End-Tag (

). In der SGML-DTD für HTML ist für eine Reihe von Elementen vorgesehen, dass man ihr End-Tag oder gar beide einfach weglassen kann (Tag-Minimization). Damit ist es in XML vorbei: OMITTAG=NO

24

Warum mehr mehr ist

All dies heißt, dass die Gefahr bestand (und ansatzweise immer noch besteht), dass das World Wide Web auseinanderdriftet. Dem woll(t)en viele entgegenwirken. In den Worten von Jim Cape, aus einem Posting in der Newsgruppe »comp.infosystems.www.authoring.html« (übersetzt nach dem Zitat in [CONN97A]): »Sie [XML, d. A.] wurde entwickelt, um ein für alle Mal die von Microsoft und Netscape propagierten Tag-Suppenkriege zu beenden.« Der Erfolg des Web und seiner Sprache wurde von denjenigen, die ihn erst möglich gemacht hatten, sowohl mit Interesse als auch mit Neid verfolgt. Gemeint ist hier natürlich die SGML-Gemeinde. Natürlich deshalb, weil HTML eine Anwendung der Standard Generalized Markup Language ist: eine Dokumenttyp-Definition8. In ihr hat ursprünglich Tim Berners-Lee vom CERN, dem spätestens seitdem weltberühmten Hochenergie-Physik-Institut in der Schweiz, festgeschrieben, welche Elemente die Hypertext Markup Language ausmachen, das heißt, mit welchen ich meine Texte auszeichnen kann.

1.2

Warum mehr mehr ist

Schade, dass es nur HTML gibt9. Denn was könnte man nicht alles mit Dokumenten im World Wide Web anstellen, wenn die Grenzen von HTML (=feststehender Satz an Elementen) nicht für alle Dokumente gälten. Wobei hiermit gemeint ist, dass man sich eben nicht eigene Elemente definieren kann. Die Zeit, in der es »nur« HTML gab, ist zwar vorbei; das allein klärt aber nicht die Frage, was man mit Dokumenten im Web machen kann. Schließlich hat eine Reihe von Firmen mit den bisherigen Mitteln (vor XML) auch schon vieles gemacht, wovon »normale« HTML-Autoren nur träumen (Softwareverteilung, E-Commerce etc.). Diese Möglichkeiten haben weder die SGML-Anhänger noch das World Wide Web Consortium (meist W3C genannt) ruhen lassen. Eine Arbeitsgruppe hat sich jetzt fast drei Jahre lang damit beschäftigt, wie man das Problem der nicht vorhandenen Erweiterbarkeit von HTML beseitigen kann. 1996 war es soweit, dass ein erster Vorschlag zur Extensible Markup Language (XML) vorgestellt wurde; übrigens im Rahmen einer SGML-Veranstaltung. Ein gutes Vierteljahr später (April 1997) war XML neben dem eigentlichen Hauptthema – Erreichbarkeit/Verwendbarkeit (accessability) von Web-Dokumenten –

XML: SGML

fürs Web

8. Auch heute noch, da die Definition von HTML in XML unter dem Namen XHTML fertig ist, basiert das Web nach wie vor auf der SGML-Version von HTML, weil sie in den Browsern implementiert ist. 9. Wenn hier gelegentlich der Eindruck entsteht, dass HTML »schlecht« sei, dann stimmt das, wenn auch nur insofern, als jetzt, da wir uns an das Web gewöhnt haben, die Nachteile einer festen DTD ins Auge springen. Ohne Tim Berners-Lees Arbeit aber würden wir heute wahrscheinlich nicht über etwas besseres als HTML diskutieren können. Schon deshalb gebührt ihm Dank.

25

1 Einführung

dasjenige Thema, über das auf der World Wide Web Conference 1997 am meisten diskutiert wurde. Aus Sicht der SGML-Anhänger war es mit XML endlich soweit, dass SGML indirekt ins Web kam. Die Erweiterbarkeit (Englisch: extensibility) von Auszeichnungssprachen für Dokumente, die im World Wide Web zur Veröffentlichung kommen sollen, ist der wichtigste Aspekt dieses Buches. Alle noch so technischen Abschnitte sind immer nur die Voraussetzung dafür, dass es in XML darum geht, Beschreibungen für eigene Dokumente zu entwickeln. Nur am Rande – siehe Kapitel 19 – soll es um die erweiterbare Version von HTML (XHTML) gehen. Vielmehr wird es sich um davon unabhängige Dokumentstrukturen handeln. Um das Motto dieses Kapitels zum vorletzten Mal aufzugreifen: Die Beteiligten der genannten Arbeitsgruppe mussten sowohl wagemutig (daring) als auch vorsichtig (cautious) bei ihrem Vorhaben sein. Auf der einen Seite musste schnell etwas geschehen, damit das Web sich nicht innerhalb eines Jahres in zueinander inkompatiblen Teil-Webs entwickelt, auf der anderen ging es darum, das für das Web viel zu komplizierte SGML zu vereinfachen. Dazu mussten Aspekte über Bord geworfen werden, von denen sich mancher ungern trennte. Dennoch war das notwendig, denn nur so war es möglich, innerhalb kurzer Zeit einen Kompromiss zu finden, mit dem alle zufrieden sein konnten. Der Erfolg, den XML nun schon seit zwei Jahren hat, ist an Anwendungen ablesbar, die im Laufe dieser Zeit entstanden sind. Auch die Aktivitäten, die Tools betreffen, sowie beim W3C eingereichte weitere Vorschläge sind Belege dafür. Mittlerweile hat man fast das Gefühl, dass im Web und in der Softwareentwicklung nichts mehr ohne XML geht. Im Vergleich zu HTML bietet XML deshalb mehr Möglichkeiten, weil es eine Metasprache ist. HTML ist, wie oben erwähnt, eine Strukturbeschreibung für Web-Dokumente. XML hingegen ist als Teilmenge von SGML eine Sprache, in der sich wiederum beliebig viele Sprachen wie HTML definieren lassen. XML ist SGML für das Web; aber nicht nur. »Eigentlich reicht HTML doch völlig aus«, könnte der eine oder die andere sagen respektive fragen, was denn an XML besser sei. Ohne den vielen Details, die in späteren Kapiteln folgen, vorzugreifen, lässt sich dazu einiges sagen. XML-Dokumente kann man – beispielsweise über Stylesheets10 – verändern. Um das klassische Beispiel eines Buches (das Buch selbst) zu benutzen: Aus einem Dokument lässt sich ein Inhaltsverzeichnis generieren, das entweder am Anfang steht oder eigenständig ist. Etwas allgemeiner: Aus einem einzigen XML-Dokument kann ich im Prinzip fast beliebig viele WebDokumente machen, etwa eine konkrete Adresse aus einem Adressbuch heraussuchen. Und natürlich ist es möglich, aus XML-Quellen HTML-Dateien zu erzeugen, die ein gemeiner Browser anzeigen kann. Dabei gehen zwar Informationen verloren, aber immerhin bewirkt eine solche Konvertierung generelle Verfügbarkeit. 10. Gemeint sind hier nicht die erwähnten CSS, sondern eine »neue« Sprache, die unter anderem funktionale Elemente enthält und es dadurch erlaubt, den Inhalt von Dokumenten zu bearbeiten, bevor ein Browser sie anzeigt. Siehe dazu vor allem Kapitel 9.

26

Wohin die Reise geht

Ähnlich wie HTML lassen sich XML-Daten »on the fly« aus Datenbankbeständen erzeugen. Allerdings eignet sich diese Auszeichnungssprache besser zur Speicherung in Datenbanken – vor allem in objektorientierten, die eine komplexe Elementstruktur leichter abbilden können als relationale. Die Elemente in XML-Dokumenten müssen strikt ineinander geschachtelt sein. Daher kann man sie als Einheiten (Objekte) betrachten, die sich – samt ihrer Struktur – in einem objektorientierten Datenbanksystem abbilden lassen. Mit HTML-Daten ist das ebenfalls möglich, allerdings entfällt durch die feste Menge an Elementen die Freiheit, eigene Datenstrukturen vorschreiben zu können. Für XML aus Datenbanksystemen gilt natürlich noch mehr, was im vorigen Absatz steht: Datenbankbestände auf unterschiedliche Art und Weise auszugeben, versteht sich fast von selbst. »Wiederverwendbarkeit« ist das dazugehörige Schlagwort. Mittlerweile sind die ersten Produkte auf dem Markt, die als XML-Server bezeichnet werden.

XML und ODBMS: Dokumente aus Datenbankbeständen generieren

Hat sich jemand in XML ein kleines Adressbuch geschaffen, heißt Wiederverwendbarkeit in diesem Maßstab, dass aus den (einmal vorhandenen) Daten Übersichten, Teilansichten und einzelne Adressen als Web-Dokumente werden können; etwas, das mit HTML ohne Datenbankanbindung nicht geht. Mit Dokumenten, die statt in HTML in XML verfasst oder aus Datenbeständen generiert sind, lässt sich auch deshalb viel mehr machen, weil in den Elementnamen und selbst definierten Attributen beziehungsweise deren Werten Information über die eigentlichen Daten enthalten ist. Auf diese so genannten Metadaten kann man ebenfalls zugreifen. Insofern ist mehr wirklich mehr.

Metadaten in den Elementnamen

Schließlich ist da noch der Traum vieler, die XML propagieren: mit XML ein einheitliches (universelles) Datenformat zu besitzen, das sowohl maschinenlesbar als auch für menschliche Augen verständlich ist11. Und: Eine solche Sprache ist auch eine, die Menschen schreiben können.

1.3

Wohin die Reise geht

Otto Web-Normalverbrauchers Homepage wird auf lange Sicht in HTML geschrieben sein. So äußerten sich die Experten noch im April 1997; und sie dürften Recht behalten. Für eine Homepage oder zwei, drei Seiten für Freunde und Verwandte lohnt sich der Aufwand, XML zu lernen, nicht12. Deswegen richtet sich dieses Buch eher an diejenigen, die HTML kennen und bislang schon intensiv damit gearbeitet haben oder planen, das demnächst zu tun.

11. Nein, damit ist nicht gemeint, alle proprietären Datenformate (Textverarbeitungen, Datenbanken) abzuschaffen – obwohl das auch nicht schlecht wäre. 12. In Form von XHTML werden es Webautoren mittelfristig auf jeden Fall mit einer XMLAnwendung zu tun bekommen.

27

1 Einführung

Manchem dürfte XML, vor allem wenn es um die Erstellung der eingangs genannten DTDs geht, wie die scheinbare Unlesbarkeit des Mottos vorkommen. In beiden Fällen gilt: Iss up 2 u reely whot yoos u make ov it aftir that; iss ol about injinooty. Im Ernst: XML ist keine Auszeichnungssprache wie HTML. Als Teilmenge von SGML13 ist es eben eine Spezifikation für die Schaffung beliebig vieler Auszeichnungssprachen. Einige Beispiele solcher Sprachen kommen in diesem Buch vor, und sie sind einfacher nachzuvollziehen als die allseits bekannte Web-Sprache. Sich Sprachen auszudenken, macht bereits kleinen Kindern Spaß. Und trotz des ernsten Hintergrunds – schließlich lernt man komplexe Dinge nicht zum Spaß – glauben wir, dass XML gerade durch sein »X« (die Erweiterbarkeit) Spaß machen kann und wird. Dahin zu gelangen, erfordert Lesearbeit. Das vorliegende Buch soll nicht nur die Grundlage dafür bieten; es soll selbstverständlich auch als Nachschlagewerk dienen und zum Schmökern in den Beispielen einladen. Das eine oder andere hier verwendete Beispiel lässt sich online nachvollziehen. An entsprechender Stelle findet sich jeweils ein Hinweis. Wer mit XML arbeiten will, dem14 stehen sowohl kostenlose als auch kommerziell vertriebene Produkte zur Verfügung (siehe Kapitel 12). Unter http:// www.heise.de/ix/raven/Web/xml/ finden Sie eine – sicherlich unvollständige – Liste frei erhältlicher Software. Es handelt sich um Editoren und Parser sowie Tools für die Erstellung und Verarbeitung von Stylesheets beziehungsweise das Generieren von Daten (HTML, RTF). Natürlich dürfen hier die zehn Aussagen nicht fehlen, die in der Syntaxbeschreibung von XML umreißen, worum es den Entwicklern der Sprache geht und ging: 1. XML soll sich im Internet auf einfache Weise nutzen lassen. 2. XML soll ein breites Spektrum von Anwendungen unterstützen. 3. XML soll zu SGML kompatibel sein. 4. Es soll einfach sein, Programme zu schreiben, die XML-Dokumente verarbeiten. 5. Die Anzahl optionaler Merkmale in XML soll minimal sein, idealerweise Null. 6. XML-Dokumente sollten für Menschen lesbar und angemessen verständlich sein. 7. Der XML-Entwurf sollte zügig abgefasst werden.

13. Den Fachmann wird's zwar nerven, aber gerade in diesem Kapitel kann man nicht oft genug darauf hinweisen. 14. Ja, auch der ... ;-)

28

Wohin die Reise geht

8. Der Entwurf von XML soll formal und präzise sein. 9. XML-Dokumente sollen leicht zu erstellen sein. 10. Knappheit von XML-Markup ist von minimaler Bedeutung. Die meisten dieser Design-Ziele hängen zusammen, etwa das zweite und dritte: weil SGML eben eine Vielfalt von Anwendungen unterstützt. Nur das letzte Ziel bringt Sie vielleicht zum Schmunzeln. Knappheit in der Auszeichnung (»terseness in markup«) ist deshalb nicht erstrebenswert, weil Maschinen nun einmal Mengendaten gut verarbeiten können. Es soll sich »zwar« um für Menschen lesbare Dokumente handeln, aber für Rechner, die letztlich die Verarbeitung erledigen sollen, ist es völlig unerheblich, wie ausführlich (oder umständlich) die Quelltexte sind. Ein kleines Code-Beispiel (das einzige in diesem Kapitel) zeigt, was gemeint ist: Meier Heinz 1938 10 29

Für jeden Mitarbeiter existiert ein mit seinen Detaildaten gefülltes Element MITARBEITER. Dessen Attribute enthalten Metadaten wie eine Kennnummer, das Eintrittsdatum sowie, wann und wie zum letzten Mal eine Veränderung vorgenommen worden ist. Der Rest dürfte sich von selbst erschließen. Für Menschen lesbar sind hier auf jeden Fall die Element- und Attributnamen; selbst mit dem Inhalt kann man etwas anfangen. Die Struktur der Kennummer dagegen ist schon in diesem Beispiel eher etwas für Maschinen – und sie könnte unleserlicher sein. Ohne jetzt schon in Erklärungen abzuschweifen: Das Beispiel riecht förmlich nach Datenbanken, und das ist kein Zufall. Ein beträchtlicher Anteil der künftig im Web abzurufenden Daten (sofern sie in XML vorliegen) dürfte aus Datenbeständen generiert sein. Das hat verschiedene Gründe. Erstens ist die sequenzielle Generierung großer Datenbestände aus einer Datenbank am sinnvollsten (Konsistenz et cetera), zweitens gilt: Habe ich aus einem Datensatz korrektes XML generiert, dann funktioniert das auch mit Hunderttausenden.

29

1 Einführung

Drittens müssen die resultierenden Dokumente nicht unbedingt XML-Instanzen sein. Es kann sich – und wird es in vielen Fällen sein – um in HTML gewandelte Ausschnitte (in der Sprache der Datenbänker: Views oder Sichten) handeln. Einfachstes Beispiel ist das Inhaltsverzeichnis dieses Buches, das im Quelltext so gar nicht bestand, sondern automatisch erstellt wurde. Zum besseren im Sinne von »erfolgreicheren« Arbeiten mit XML hier ein paar Zusätze in Form von Geboten, an die jede(r) sich beim Verfassen oder Generieren von XML-Dokumenten halten sollte. 1. Du sollst Deine Elemente immer schließen. 2. Du sollst Attributwerte immer in doppelte Anführungszeichen setzen. 3. Schachtele Deine Elemente immer hierarchisch. Wer dies beachtet, den loben die Parser. Etwas ausführlicher lassen die »Gebote« sich etwa so umschreiben: Alle Elemente zu schließen, heißt im Normalfall, dass jede Elementinstanz außer dem Start-Tag auch ein End-Tag haben muss: Inhalt von mein-elem

Das dürfte vor allem für diejenigen gewöhnungsbedürftig sein, die sich bislang darauf verlassen haben (und dies auch tun konnten), dass die Browser selbst herausfinden, wo ein Element aufhört und eine neues beginnt. Eine Ausnahme gibt es auch von dieser Regel: Das »leere Element« (IMG aus der HTML-DTD wäre ein Beispiel) kann, muss aber nicht mit einem End-Tag abgeschlossen werden. Zusätzlich erlaubt die Spezifikation – anders als in HTML – eine weitere Schreibweise, den Schrägstrich vor der schließenden spitzen Klammer:

Was in HTML durch die Großzügigkeit der DTD möglich ist, nämlich EndTags wegzulassen, das funktioniert in XML nicht. Jedes Element muss ordentlich abgeschlossen sein. Die zweite Vorgabe ist insofern neu, als es in HTML zwar als guter Stil gilt, Attribute mit Anführungszeichen zu versehen:

Eigentlich sind sie aber nicht erforderlich. Browser wie der Internet Explorer oder der Navigator sind auf jeden Fall einverstanden, wenn jemand die Zeichen weglässt. Das Gleiche gilt im Prinzip für das dritte Gebot, denn HTML sieht die hierarchische Schachtelung von Elementen durchaus vor. Es sind die Browser, die über Zeilen wie

30

Wohin die Reise geht

Beispiel: fetter und kursiver Text ab hier normal

Abbildung 1.2: Navigator 4.04 stellt das letzte Listing wie diese Abbildung dar.

gnädig hinweggehen. In XML-Dokumenten ist strenger als in HTML darauf zu achten, dass die Elemente korrekt geschachtelt sind15. In den meisten Fällen wird's der Editor schon richten... Dennoch ist es gut, sich daran zu gewöhnen, dass diese strikte Ordnung in XML wichtig ist, weil sie bereits in der Planungsphase berücksichtigt werden kann und zur sinnvollen Struktur von DTD (die die hierarchische Ordnung vorgibt beziehungsweise beschreibt) und Dokumenten beiträgt. Disziplin hin und her: XML verspricht vielleicht keine Lösung aller durch proprietäre Formate bestehenden Konvertierungsprobleme, aber mindestens die Freude, aus einer selbst entwickelten Struktur und entsprechend ausgezeichneten Dokumenten (sowie ein paar dazugehörigen Stylesheets) Web-Dokumente zu generieren, die gut zu warten sind. Das Management einer Website etwa lässt sich durch die zentrale Verwaltung von Links (beispielsweise Sites mit vielen Seiten, die viele Links enthalten) wesentlich vereinfachen, um nur ein einfaches Beispiel zu nennen. Außerdem ist es unsere Hoffnung, dass der Umgang mit XML kreativen WebAutoren sogar schon für sich Spaß macht, denn wenn man die ersten Hürden überwunden hat (eine DTD zu schreiben), dürfte schnell klar sein, wo die Vorteile gegenüber HTML liegen. Ein abschließender Satz darf in dieser Einführung nicht fehlen: Wenn Sie dieses Buch lesen, wird manches, das hier steht, leider schon veraltet sein. Das gilt für erhältliche Software ebenso wie für den Stand der Dinge beim W3C. Die Spezifikation für das Linking und Entwürfe für die Stilkomponente dürften noch in diesem Jahr fertig werden.

15. Noch einmal zum Grund dafür: Es gibt in XML keine Tag-Minimierung, das heißt, man darf keine End-Tags weglassen.

31

2

Was sind Dokumente?

Hypertext is Literature, not Technology.

Ted Nelson Das letzte Kapitel hat gezeigt, welche Schwächen HTML besitzt und welche Probleme daraus entstanden sind. Man kann sich nun fragen, ob die Entwickler von HTML geschlafen haben, als sie diese Sprache entwickelten. Tatsächlich sind viele der Probleme auf die unkontrollierte Entwicklung1 von HTML zurückzuführen. Auf der anderen Seite sind viele so genannte »Schwächen« auf Unwissenheit der Anwender über die grundlegenden Ideen von HTML bzw. SGML zurückzuführen. Diese Ideen stecken auch in XML, und ihr Verständnis ist für den sinnvollen Einsatz der Sprache unverzichtbar.

2.1

Eine kurze Geschichte der Textverarbeitung

Ein Makel, den kaum ein Buch abstreifen kann, das sich mit Informatik oder Computern beschäftigt, ist die Tatsache, dass man so viele interessante Dinge nicht behandeln kann. In diesem Abschnitt wird dies überdeutlich. Die Überschrift »Eine kurze Geschichte der Textverarbeitung« erweckt vielleicht die Hoffnung, die Arbeitsweise der großen Autoren der Weltgeschichte vorzustellen – doch weit gefehlt. Leider überspringen wir Homer, lassen Kant aus und ignorieren Proust. Unser Einstieg in die »kurze Geschichte der Textverarbeitung« beginnt erst kurz bevor die Computer dabei eine Rolle spielten. Für einen Informatiker ist diese Zeit freilich so etwas wie die »graue Vorzeit«, kurz nach dem Urknall sozusagen, als Texte noch auf mechanischen Schreibmaschinen verfasst wurden. Das Klischee des Literaten, der zurückgezogen, bei spärlicher Beleuchtung und mit einer Zigarette im Mundwinkel seine Zeilen schreibt, mag stimmen oder nicht, sicher ist jedoch, dass seine Mittel zur Formatierung und typografischen Ausschmückung sehr einfach waren. Viel mehr als gesperrter Text2 oder bestenfalls Unterstreichungen war nicht möglich. 1. Von einer »Weiterentwicklung« kann in einigen Punkten wirklich nicht gesprochen werden. 2. Für den, der sich schon nicht mehr daran erinnern kann, sei erwähnt, dass sich gesperrter Text durch L e e r z e i c h e n zwischen den Buchstaben auszeichnet.

33

2 Was sind Dokumente?

Mit der zunehmenden Verbreitung von preiswerten Büro-Computern änderte sich zunächst nicht viel. Ursache waren insbesondere die eingeschränkten Druckmöglichkeiten. Die Typenraddrucker basierten im Wesentlichen auf der Schreibmaschinentechnik. Erst der Einsatz von Nadel- und Laserdruckern erlaubte vielfältige Schriftvariationen. Der Verfasser musste dazu anfänglich so genannte »Steuerzeichen« in den Text einfügen. Am Bildschirm wurden die Schriftänderungen nicht oder nur in einem Vorschaumodus dargestellt. Erst der Ausdruck zeigte den Text in seiner ganzen Pracht. Grafische Oberflächen bilden die Grundlage für »What you see is what you get« und DesktopPublishing. Dadurch wurde die Textverarbeitung nachhaltig geprägt.

Die Einführung der grafischen Oberfläche – allen voran der Apple Macintosh im Jahre 1984 – erlaubte erstmals eine weitgehend identische Darstellung von Text auf Papier und auf dem Bildschirm. Das Konzept des What you see is what you get (WYSIWYG) war geboren. Wie so viele Entwicklungen hatte auch dieser Schritt seine guten und schlechten Seiten. Positiv ist sicherlich die Möglichkeit zum Desktop-Publishing (DTP), der Erstellung von (semi-)professionellen Druckerzeugnissen am Schreibtisch. Die Professionalität besteht insbesondere in der technischen Qualität. Viele Verfasser überschätzen jedoch ihre Fähigkeit, mit den neuen Werkzeugen adäquat umzugehen. Jeder, der schon einmal einen Brief mit zehn verschiedenen Schriftarten bekommen hat, weiß, wovon hier die Rede ist. Neben diesen »stilistischen Ausrutschern« hat der Trend zum WYSIWYG und DTP aber eine viel bedeutendere Konsequenz gehabt: Die Arbeitsweise bei der Texterstellung orientierte sich fortan fast ausschließlich am Layout, an der Formatierung und an der Darstellung des Textes. Für eine DTP-Anwendung mag das auch die richtige Vorgehensweise sein. Sobald jedoch das Ausgabemedium nicht mehr nur Papier ist, wird die Angelegenheit komplizierter. Die folgenden Abschnitte stellen einen anderen Ansatz vor, dessen Wurzeln schon relativ weit zurückreichen.

2.2

Bestandteile eines Dokumentes

Bei der Fragestellung, aus welchen Bestandteilen ein Dokument besteht, beschränken wir uns hier auf Textdokumente, d.h. auf Dokumente, die überwiegend aus Text bestehen. Selbstverständlich dürfen darin auch Abbildungen, Tabellen oder sogar Videos enthalten sein. Letzteres bedeutet natürlich auch, dass keine Beschränkung auf druckbare Dokumente besteht, wenngleich diese Vorstellung zum besseren Verständnis beiträgt. Dokumente bestehen aus Inhalt, Formatierung, Struktur und logischen Informationen.

34

Woraus ist also ein solches Dokument aufgebaut? Als erste Antwort (vgl. Abbildung 2.1) findet man sicherlich den Inhalt, also den Text, die Bilder usw. Mit dem DTP-Gedanken im Hintergrund ist es klar, dass die Formatierung, das Layout, die gewählte Schriftart usw. eine wichtige Rolle spielen. Schließlich bestimmt dieser Teil eines Dokumentes das visuelle Erscheinungsbild. Die genannten Dinge sollen hier zusammenfassend als Information zur (visuellen) Darstellung bezeichnet werden. Die dritte Komponente ist für die meisten Verfasser überraschenderweise weniger offensichtlich, was wohl auf die zuvor genannte Dominanz des WYSIWYG-Prinzips zurückzu-

Die neue, alte Idee: Strukturorientiert schreiben

führen ist. Gemeint ist die Struktur des Textes, also die Aufteilung in Kapitel, Abschnitte usw. Desweiteren bestehen Sätze ja nicht einfach aus aneinandergereihten Wörtern. Auch Informationen über einzelne Wörter oder Satzteile können interessant sein. Handelt es sich um ein Zitat oder um eine wichtige Textstelle? Ist ein Wort ein Personenname oder ein Befehl? – All diese logischen Informationen, die jeder Leser auf einen Blick erkennt, fehlen einem Computerprogramm nach dem WYSIWYG-Ansatz. Für eine spätere Weiterverarbeitung ist das sicherlich nicht förderlich. Was liegt also näher, als bei der Texterfassung den Schwerpunkt nicht auf das Aussehen, sondern die Struktur und die logischen Elemente zu legen? Neu ist diese Idee nicht. Sie ist tief verwurzelt in der Herkunft von SGML. Abbildung 2.1: Drei Komponenten eines Dokumentes

Struktur

Inhalt

Informationen ABC Text

Bilder

zur Darstellung

2.3

Die neue, alte Idee: Strukturorientiert schreiben

Die wesentliche Idee von SGML, nämlich das Konzept des »generic coding«, ist bereits fast dreißig Jahre alt. WILLIAM TUNNICLIFFE von der Graphic Communications Association (GCA) machte im September 1967 den Vorschlag, den Informationsgehalt eines Dokumentes von seiner äußeren Form zu trennen. Ebenfalls Ende der sechziger Jahre veröffentlichte STANLEY RICE, ein New Yorker Buch-Designer, seine Idee der »editorial structure tags«, woraus später das »generic markup« entstand. Der Begriff des »markup« stammt aus dem Verlagswesen, aus einer Zeit, als Begriffe wie Desktop-Publishing noch unbekannt waren. Nach der inhaltlichen Überprüfung und Korrektur eines Manuskriptes folgte die Bearbeitung durch den Layouter, der die Entschei-

35

2 Was sind Dokumente?

dungen über Seitenformat, Zeichensätze und weitere typografische Festlegungen traf. Diese wurden in Form von handschriftlichen Markierungen und Anweisungen in das Manuskript eingefügt und anschließend im Satz berücksichtigt. Eine genaue Umsetzung dieser Vorgehensweise spiegelte sich dann auch in elektronischen Dokumenten wider. Texte enthielten Steuerzeichen oder Makros, die Anweisungen für die Formatierung gaben. Als später der Trend begann, in den Büros Schreibmaschinen durch Computer zu ersetzen, lebte dieses Konzept fort. Noch heute arbeiten die gängigen Textverarbeitungen nach diesem Prinzip. Zwar stellen die modernen WYSIWYG-Programme die Steuerzeichen nicht mehr auf dem Bildschirm dar, sondern können dank grafischer Oberflächen Attribute wie Fettdruck, Unterstreichungen und verschiedene Zeichensätze unmittelbar anzeigen, die Fixierung auf das Layout des Dokuments herrscht jedoch noch immer vor. Um so erstaunlicher, dass die Idee des Generic Coding schon so alt ist. Im Gegensatz zum formatorientierten Ansatz geht es beim Generic Coding darum, die Struktur und die logischen Elemente eines Dokuments zu kennzeichnen. Diese Art der Information geht bei der üblichen Vorgehensweise verloren. Setzt ein Verfasser eine Überschrift in einer größeren Schriftart, so kann ein Leser diesen Text durchaus als Überschrift erkennen, der Computer »weiß« jedoch nichts davon. Das Dokument enthält in diesem Fall nur die Information, wie ein Text darzustellen ist, aber nicht, welche Funktion er erfüllen soll. Abbildung 2.2: Die historische Entwicklung bis zur Extensible Markup Language

William Tunnicliffe (GCA)

1967

Stanley Rice

generic coding editorial structure tags GenCode-Komitee

Norman Scharpf (Direktor GCA) Goldfarb, Mosher, Lorie (IBM)

1969

ANSI

1978

GML

Charles Goldfarb ISO

1986

SGML (ISO 8879)

Tim Berners-Lee (CERN)

1989

HTML

1993

HTML-Formulare (XMosaic)

1994

HTML-Abweichungen

Marc Andreessen (NCSA)

Netscape Microsoft

HTML

Dave Raggett (W3C)

CSS

Håkon Lie (W3C) W3C (Jon Bosak (Sun), James Clark et.al.)

36

1997

XML

Die neue, alte Idee: Strukturorientiert schreiben

Genau hier setzt das Generic Coding an. Markierungen sagen etwas über die Art (generic, englisch: artmäßig) der markierten Stelle aus. Die »Art« bezeichnet hier zum Beispiel ein Kapitel, eine Überschrift, einen hervorgehobenen Text, eine Fußnote, einen Eigennamen, ein Zitat und so weiter. Die Vorteile liegen auf der Hand. Die Struktur des Dokuments geht bei der Speicherung nicht verloren. Die Zuordnung einer bestimmten Darstellung zu einer bestimmten Klasse von Textstellen ist anwendungsspezifisch eindeutig möglich: Bei einem Ausdruck etwa hätten alle Überschriften die gleiche Schriftart und -größe, bei einer Ausgabe über einen Sprachsynthesizer immer den Hinweis »Titel«.

Generic Coding: Struktur- und logische Informationen bleiben erhalten.

Das waren die ursprünglichen Ideen von Tunnicliffe und Rice. Die Bedeutung dieser Ideen erkannte NORMAN SCHARPF, Direktor der GCA. Er gründete ein Komitee, dessen Entwicklung des »GenCode«-Konzepts später Bedeutung für SGML erlangte. Ebenfalls auf den Ideen von Tunnicliffe und Rice basierend, entwickelten CHARLES GOLDFARB, EDWARD MOSHER und RAYMOND LORIE bei IBM im Jahre 1969 die Generalized Markup Language (GML). GML enthielt erstmals das Konzept eines formal definierten Dokumenttyps mit einer verschachtelten Struktur. Nach der Fertigstellung von GML formulierte Goldfarb weitere Konzepte, die zwar nicht in GML, aber später in SGML Einzug hielten3. Die Entwicklung zu einem Standard begann 1978, als das American National Standard Institute (ANSI) ein Komitee gründete, dessen Ziel die Entwicklung einer standardisierten Textbeschreibungssprache auf GML-Basis war. Goldfarb war Mitglied dieser Gruppe, die auch vom GCA-GenCode-Komitee Unterstützung erhielt. Nach mehreren Normentwürfen fand 1984 eine Neuorganisation des Projekts unter Leitung des ANSI und inzwischen auch der International Organization for Standardization (ISO) statt. Die zuständige Arbeitsgruppe der ISO unter Leitung von JAMES MASON vom Oak Ridge National Laboratory rief regelmäßige Treffen ins Leben. Parallel dazu arbeitete das ANSI-Komitee, geleitet von WILLIAM DAVIS (SGML Associates), immer noch unterstützt vom GenCode-Komitee, dessen Leiter SHARON ADLER von IBM war. Die Abstimmung zwischen ISO und ANSI lag in den Händen von Charles Goldfarb. Ein letzter Entwurf für den internationalen Standard wurde im Oktober 1985 präsentiert. Nach einem weiteren Jahr, in dem man Anregungen und Kommentare einarbeitete, gipfelte die Arbeit 1986 in der Veröffentlichung der Standard Generalized Markup Language als ISO-Standard 88794.

3. Damit sollte klar sein, was der Scherz in der FAQ der Newsgruppe comp.text.sgml bedeutet: »Was heißt SGML?« Antwort: Standard Goldfarb Mosher Lorie. 4. Weitere Informationen zur geschichtlichen Entwicklung von SGML sind in [GOLD90] und [GOLD97] zu finden.

37

2 Was sind Dokumente?

2.4

Die Entwicklung des Hypertextes

Some of them were dreamers Some of them were fools Who were making plans and thinking of the future

Jackson Browne Der zweite große Entwicklungsstrang, der in das Web mündete, begann noch ein paar Jahre früher als die ersten Generic-Markup-Ideen. Die Rede ist vom Hypertext. Älteste Beispiele von Texten, die Querverweise nutzen, datieren einige Jahrhunderte zurück. DeRose und Durand zeigen zum Beispiel einen Druck von Euklids »Elementen« aus dem 17. Jahrhundert [DEDU94], in dem Verknüpfungen von Textstellen durch Verweise realisiert sind. Die Protagonisten unseres Jahrhunderts sahen im Hypertext stets mehr als nur eine Form von Verweisen. Urvater aller Hypertextsysteme: Memex

Als Vorläufer oder zumindest als Inspiration der modernen Hypertextsysteme gilt VANNEVAR BUSHS fiktives System Memex. Seinen vielzitierten Artikel »As we may think« veröffentlichte er bereits im Jahre 1945. Darin skizziert er ein System, das man sich äußerlich als Schreibtisch (vielleicht mit eingebautem Desktop-Computer) vorstellen kann. Selbstverständlich ist noch nicht die Rede von Mikroprozessoren und Festplatten. Seine technologische Grundlage ist die (Mikro-)Fotografie. Wesentlich ist aber, dass Memex mit einzelnen Informationseinheiten (vorstellbar als einzelne Seiten eines Hypertextes) arbeitet, die der Benutzer durch »Wege« (»trails«) miteinander verbinden kann (heute: Hyperlinks). Bush zeichnet ein sehr feines Bild der Anwendungen, die ihm vorschweben. Die visionäre Kraft dieses vorausschauenden Artikels macht den Text auch nach mehr als 50 Jahren lesenswert5. DOUGLAS ENGELBART bezieht sich in der ersten Veröffentlichung zu seinem Augment-Projekt ebenfalls auf Bush. Engelbart beschreibt hier im Jahre 1962 (in »Augmenting Human Intellect« [ENGE62]) eine auf Lochkarten basierende Hypertext-Anwendung, die das Ziel hat, Gedankengänge abzubilden: »There was no convenient way to link these cards together so that the train of thought could later be recalled by extracting the ordered series of notecards. An associative-trail scheme similar to that out lined by Bush for his Memex could conceivably be implemented with these cards to meet this need and add a valuable new symbol-structuring process to the system. [...] 5. Im Oktober 1995 fand anläßlich des fünfzigsten Jubiläums von Bushs Artikel eine Feier am Massachusetts Institute of Technology statt. Dabei ging es auch darum, herauszufinden, »What Has Been Accomplished, and What Remains to Be Done«. Zu den Rednern gehörten Douglas Engelbart, Theodor Nelson und Tim Berners-Lee; außerdem auch DOUGLAS ADAMS, Autor zahlreicher Science-Fiction-Romane. Informationen zu dieser Veranstaltung sind im Web unter http://www-eecs.mit.edu/AY95-96/events/bush/ zu finden.

38

Die Entwicklung des Hypertextes

Suppose that one wants to link Card B to Card A, to make a trail from A to B. He puts Card B into a slot so that the edge-notched coding of the card's serial number can automatically be sensed, and slips Card A under a hole-punching head which duplicates the serial-number code of Card B in the coding of the holes punched in a specific zone on Card A. Later, when he may have discovered Card A, and wishes to follow this particular associative trail to the next card, he aligns that zone on Card A under a hole-sensing head which reads the serial number for Card B therein and automatically sets up the sorting mechanism. A very quick and simple human process thus initiates the automatic extraction of the next item on the associative trail. It's not unreasonable to assume that establishing a link would take about three seconds, and tracing a link to the next card about three to five seconds.«

Vannevar Bush

1945

Memex

Douglas Engelbart

1962

Augment

Ted Nelson

1965

Xanadu

Abbildung 2.3: Einige Stationen der HypertextEntwicklung

Proprietäre Hypertext-Systeme Hypertext-Forschung

Tim Berners-Lee (CERN)

1989

HTML

ISO

1992

HyTime

W3C

200?

XLink, XPointer

Den Begriff »Hypertext« prägte ein Mann namens TED NELSON. Seine Historie beginnt im Jahre 1960, als er begann, sich Gedanken über Hypertext zu machen [XANA97]. Die erste Veröffentlichung erschien im Jahre 1965, drei Jahre nachdem Douglas Engelbart seine erste Schrift zu Augment vorstellte. Nelsons System Xanadu6 hat eine bewegte, mehr als dreißigjährige Geschichte hinter sich, von der GARY WOLFS Artikel in Wired berichtet7 [WOLF95]. Die Ideen und Visionen, die bereits in den 60er Jahren im XanaduProjekt formuliert wurden, gehen weit über das hinaus, was bis heute im Web realisiert ist. Es ist überraschend, dass Nelsons Visionen über Jahr-

»What I Do: I build paradigms. I work on complex ideas and make up words for them. It is the only way.« Ted Nelson prägt den Begriff Hypertext.

6. Siehe http://www.xanadu.net/ 7. Wir wollen nicht verschweigen, dass dieser Artikel außerordentlich negativ aufgenommen wurde. Nelson selbst nennt ihn »böswillig« (»maliciously«) und Raggett et al. sprechen in [RAGG97] von »offenen Beschimpfungen, mit denen Wired [Nelson] bedacht hat«. Machen Sie sich selbst ein Bild!

39

2 Was sind Dokumente?

zehnte so geringen Anklang gefunden haben und nun in kürzester Zeit eine »schlechte Kopie« Wirklichkeit wurde. Dass er selbst die Entwicklung mit zwiespältigen Gefühlen betrachtet, ist verständlich. So kann er in [RAGG97] zwar noch eine »besser als nichts«-Aussage abgeben, »Endlich gibt es ein populistisches, anarchisches elektronisches Publishing in Netzwerken. Das World Wide Web ist wie Karaoke: Jeder kann es, ohne es geübt zu haben, und das ist das Großartige daran.« , aber auf einer seiner Webseiten [NELS96] liest sich das schon weniger positiv: »Many people think Xanadu was an attempt to build the World Wide Web. On the contrary: the World Wide Web was exactly what we were trying to prevent.« In [CONN97] stellt er die SGML-Grundlage des Web, Embedded Markup, in Frage8. Der Titel seines Aufsatzes lautet »Embedded markup considered harmful« [NELS97]. Seine bisherigen revolutionären Ansätze und visionären Gedanken verbieten, seine Kritik einfach zu ignorieren. Vielmehr könnte es viel Zeit und Geld sparen, sich vor Entwicklung einer neuen Technologie ein paar Gedanken darüber zu machen. So sind aktuelle Probleme des Web, wie zum Beispiel das Urheberrechtsproblem, von Nelson schon durchdacht worden. Wie er schon vor 30 Jahren die Begriffe Hypertext und Hypermedia prägte, so spricht er heute von »Transcopyright« und »Transpublishing«. Es bleibt abzuwarten, wann wir seine Terminologie so selbstverständlich benutzen, wie wir es mit »Hypertext« heute machen. Neben allem Lob für Nelsons Visionen muss man aber auch sehen, dass die Revolution des Web keine technische Revolution war. Aus technischer Sicht war es eher ein kleiner Schritt. Vielleicht kommt es auf die gute Kombination an: das Machbare machen und das Wünschenswerte nicht aus den Augen verlieren. Aus neuerer Zeit ist noch eine ISO-Norm zu erwähnen. Im Jahre 1992 wurde HyTime, die Hypermedia/Time-based Structuring Language verabschiedet. Sie hatte auch große Bedeutung für die neuen Linking-Konzepte XLink und XPointer. Eine stilgerechte Zusammenfassung der Hypertext-Entwicklung bietet Stefan Münz in [MUEN97]. Selbstverständlich beschränkt sich Münz nicht auf die historischen Meilensteine, sondern sagt auch etwas über das Web. Das tun wir nun auch.

8. Man beachte, dass es darum geht, dass die Auszeichnungen in den Inhalt eingebettet (embedded) sind. Es geht nicht um Generic Markup oder die Bevorzugung des layoutorientierten Ansatzes; Nelson nennt neben SGML ausdrücklich RTF, was ebenfalls eingebettete Auszeichungen enthält, die jedoch die Formatierung betreffen. Insofern richtet sich seine Kritik gegen alle bekannten Textsysteme.

40

Textformate im Web

2.5

Textformate im Web

Ende der achtziger Jahre, genauer im Jahre 1989, begann die Entwicklung des World Wide Web. Den Grundstein legte TIM BERNERS-LEE am CERN, dem Forschungszentrum der Europäischen Organisation für Kernforschung, in Meyrin bei Genf. Als Auszeichnungssprache für die Dokumente entschied sich Berners-Lee für eine einfache, auf SGML basierende Sprache, die später den Namen Hypertext Markup Language erhielt. Damit führte die Entwicklung des Web die beiden zuvor genannten Stränge, strukturorientierte Texte auf der Grundlage SGML und Hypertext, zusammen. Die Beliebtheit des World Wide Web stieg sprunghaft durch den ersten Browser mit einer grafischen Oberfläche, XMosaic. Die Version 1.0 von XMosaic erschien im April 1993. Im weiteren Verlauf des Jahres programmierten die Entwickler um MARC ANDREESEN am National Center for Supercomputing Applications (NCSA) Versionen für PC und Macintosh. Konsequent wurde der Name systemneutral in »Mosaic« verändert. Im November 1993 führte Mosaic die Formulare als Erweiterungen zu HTML ein. Weitere umfangreiche Abweichungen vom Standard brachten die Browser der Firmen Netscape – der »Navigator« erschien im Jahre 1994 – und wenig später auch Microsoft. Parallel dazu hat das World Wide Web Consortium (W3C) die Entwicklung von HTML und den Cascading Style Sheets (CSS) betrieben. Unter den Beteiligten sind DAVE RAGGETT für HTML und HÅKON LIE für CSS zu nennen. Die jüngste Vertreterin dieser Sprachenfamilie ist die Extensible Markup Language (XML). Sie wird von einer Arbeitsgruppe des W3C betreut, dessen Leitung JON BOSAK von Sun inne hat. Ein weiterer, im SGML-Umfeld angesehener Mitarbeiter ist JAMES CLARK. Der erste XML-Entwurf wurde im November 1996 im Rahmen der SGML'96Konferenz in Boston vorgestellt. Im darauffolgenden Jahr begann die große XML-Begeisterung, die schließlich in der Vorstellung des Proposals durch die zuständige Arbeitsgruppe des W3C auf der SGML/XML'97 am 8. Dezember in Washington gipfelte. Man beachte, dass XML innerhalb eines Jahres ein gleichberechtigtes Thema der SGML-Konferenz der GCA wurde. Die weitere Entwicklung darf mit Spannung erwartet werden.

2.6

Das SGML-Konzept: Generic Markup

Nach den »Ausflügen« in die Hypertext- und Web-Entwicklung kehren wir nun zu den ursprünglichen Fragen der Texterstellung zurück. Was bedeuten die vorausgegangenen Ausführungen für die Praxis? Was ändert sich für den Verfasser? Wie schreibt er seine Texte? – Die Idee des WYSIWYG ist ja nicht vom Himmel gefallen. Selbstverständlich macht es Sinn, etwa beim Desktop-

41

2 Was sind Dokumente?

Publishing, das Endergebnis mehr oder weniger exakt auf dem Bildschirm zu sehen. Oft wird aber übersehen, dass eine andere Arbeitsweise durchaus auch ihre Berechtigung hat und manchmal sogar besser geeignet ist. Stellen Sie sich vor, Sie schreiben einen langen Text, vielleicht einen Aufsatz oder eine technische Dokumentation. Innerhalb des Textes kommt eine Reihe von gleichartigen Textstücken vor, zum Beispiel Zitate, Personennamen, Beispiele, Fachbegriffe und so weiter. Sie möchten für eine konsistente Darstellung von gleichartigen Texten sorgen. Ein Zitat soll also stets gleich erscheinen, etwa vom linken und rechten Rand eingerückt und in kursiver Schriftart. Beim ersten auftretenden Zitat legen Sie dieses Aussehen fest und für Personennamen, Beispiele und all Ihre Textelemente verfahren Sie genauso. So angenehm es ist, eine schöne Darstellung beim Schreiben zu haben, so lästig ist es doch, wenn Sie 200 Seiten später das nächste Zitat schreiben möchten und sich daran erinnern müssen, wie denn das erste Zitat aussah. War es fett und mit Anführungszeichen versehen oder doch eher serifenlos und in kleinerer Schriftgröße? Und wie sahen die Personennamen aus? Und wie die Beispiele? Was mache ich, wenn ich alle Zitate nachträglich umformatieren möchte; ich muß wohl alle einzeln bearbeiten... – Das Problem sollte klar sein, und viele Programme bieten auch Lösungen an. In dem Textverarbeitungsprogramm Word gibt es die so genannten Formatvorlagen (vgl. Abbildung 2.4). Sie erlauben es, für solche Textelemente Namen zu vergeben und diese mit einem bestimmten Format zu verknüpfen. Eine nachträgliche Änderung der Formatierung ist damit auch möglich. Abbildung 2.4: Word: Auswahlfenster für Formatvorlagen

Das insbesondere im wissenschaftlichen Bereich beliebte LaTeX-System gestattet die Verwendung von selbst definierten Befehlen, die ähnlich wie Formatvorlagen verwendet werden können. Da LaTeX nicht mit WYSIWYG arbeitet, sondern aus dem geschriebenen Quelldokument in einem Formatierungsprozess eine Ausgabe erzeugt, kann man beim Schreiben sogar Befehle verwenden, die noch nicht definiert sind. Im Gegensatz zu Word, wo eine Formatvorlage definiert sein muss, bevor sie zum erstenmal verwendet wird, ist die LaTeX-Variante noch eine Spur flexibler. Zudem lassen sich die mit

42

Das SGML-Konzept: Generic Markup

Befehlen markierten Texte nicht nur formatieren, sondern beispielsweise auch in das Stichwortverzeichnis einfügen oder zur weiteren Verarbeitung in eine Datei ausgeben. \documentclass{brief} % ein Beispiel für eine fiktive % Dokumentklasse namens "brief" \begin{brief} \begin{adressat} \name{Gordon Shumway} \strasse{167 Hemdale Avenue} \ort{Los Angeles} \end{adressat} \betreff{Grüße} \datum{\today} \anrede{Lieber Gordon,} wie geht es Dir? -- Ich hoffe, wir sehen uns bald wieder! \gruss{Viele Grüße,\\ Deine Rhonda!} \end{brief}

Formatvorlagen von Word oder LaTeXs Befehle erlauben die Verwendung des Generic-Markup-Konzepts mit diesen Programmen. Der Vorteil beim Schreiben des Textes ist, dass man sich keine Gedanken über das Aussehen machen muss. Der Verfasser wird von der Bürde befreit, sich bereits bei der Texterfassung um das Format kümmern zu müssen. Hat man sich erst einmal an diese Arbeitsweise gewöhnt, wird man die neue Freiheit schnell zu schätzen wissen. XML besitzt einige Gemeinsamkeiten mit den genannten Programmen. Auch hier muss in der Regel, vergleichbar zu Word, bereits vor der Arbeit definiert sein, welche Textelemente es gibt9. Was mit den Texten geschieht, ist jedoch nicht festgelegt. Neben der Formatierung ist auch die Erstellung eines Stichwortverzeichnisses möglich, wie zuvor bei LaTeX erwähnt. Dank der Standardisierung von XML, den frei verfügbaren Programmen und der für einen Computer leicht verständlichen Form gehen die Verarbeitungsmöglichkeiten über die von LaTeX und vielen anderen Programmen hinaus. Wesentlich ist auch hier wieder das Generic Markup. XML-Dokumente enthalten Informationen über den Text, so genannte Meta-Daten. Darunter versteht man beispielsweise die oben genannten Informationen »Zitat«, »Personenname« und so weiter. Erst dadurch wird es möglich, in einem Dokument etwa nach einer Person zu suchen. Wären dort ausschließlich Formatierungsanweisungen enthalten, könnte ein Computerprogramm nur raten, ob ein Wort ein Name, eine Adresse oder etwas anderes ist. Erst die

Das neue Lieblingswort des Web: Meta-Daten. Den Wert von »Daten über Daten« kennen Informatiker (und nicht nur die) schon lange, das WWW lernt ihn erst jetzt kennen. Die Begeisterung für alles, was damit zu tun hat – XML, RDF, MCF – ist beim W3C kaum zu übersehen.

43

2 Was sind Dokumente?

explizite Speicherung dieser Informationen erlaubt die vernünftige Nutzung von Texten, die über die Darstellung oder den Druck hinausgeht. Arbeitet man ausschließlich formatorientiert, gehen all diese Meta-Daten verloren. LaTeX

Word

SGML/XML

Dokumentklasse

Dokumentvorlage

Dokumenttyp-Definition

Befehle, Umgebungen

Formatvorlagen

Elementtypen

Tab. 2.1: Gegenüberstellung von wichtigen Begriffen in LaTeX, Word und SGML/XML.

Ein weiterer Vorteil des Generic Markup besteht darin, dass man völlig unabhängig vom Ausgabemedium ist. Da einfach gar keine Formatierungsanweisungen gespeichert sind, können diese auch nicht nur für den Ausdruck auf Papier oder die Darstellung auf dem Bildschirm brauchbar sein. Durch die erst nachträgliche Ausgabeaufbereitung kann man ein und dasselbe Dokument auf Papier ausdrucken, auf dem Bildschirm darstellen und sogar vorlesen lassen. Für die letzte Option entwickelte das W3C als Teil der Cascading Style Sheets Level 2 (CSS2) die so genannten Aural style sheets. Sie werden die Zuordnung von solchen Eigenschaften wie Lautstärke, Sprechpause und Geschwindigkeit oder auch einer Stimmfamilie (männlich, weiblich, kindlich) zu Elementen von HTML gestatten. Diese Informationen versetzen einen Sprachsynthesizer dann in die Lage, eine Web-Seite verständlicher und betont vorzulesen.

2.7

Dokumente versus Daten

Dieses Kapitel hat sich sehr stark an der historischen Entwicklung orientiert. Der geschichtliche Hintergrund von XML ist das Publishing (in Form von SGML). Als Folge davon hat sich dieses Kapitel mit Dokumenten auseinander gesetzt. Seit dem Erscheinen von XML sind aber viele Anwendungen entstanden (entweder als Implementation oder als Idee), die XML nicht als Dokumentenformat, sondern allgemeiner als Datenformat oder als Datenaustauschformat ansehen. Obwohl wir hier ganz bewusst auf die Wurzeln von XML eingegangen sind, möchten wir aber dennoch schon jetzt betonen, dass sich mit XML prinzipiell beliebige Daten beschreiben lassen. Welche Anwendungsidee dahintersteckt (Dokumente, Datensätze, Transaktionsdaten) spielt aus technischer Sicht keine Rolle. Das einfache Mitarbeiter-Beispiel im vorhergehenden Kapitel hat eigentlich schon gezeigt, dass XML-Daten keine Dokumente im engeren Sinn sein müssen. Mittlerweile ist es wohl keine gewagte Prognose mehr, zu behaupten, dass der größte Anteil der XMLkodierten Daten keine Dokumente, sondern andere Daten beschreiben wird. Allerdings wird auch die Unterscheidung immer schwieriger. XML-kodierte Dokumente erlauben eine breitere Verwendung als die bloße Darstellung (auf 9. In SGML gilt dies immer; wie die Ausnahme von der Regel in XML aussieht, erläutern wir später.

44

Dokumente versus Daten

Papier oder Bildschirm) und XML-kodierte Daten lassen sich auch als Dokumente auf irgendeinem Ausgabegerät visualisieren. Die Aussage, auf die es hier ankommt ist, dass Sie bei XML durchaus an (Text-)Dokumente denken sollen, denn schließlich ist das die Herkunft, aber Sie sollten auch die unzähligen anderen Verwendungsmöglichkeiten im Hinterkopf behalten.

45

3

XML im Web

Client, n. A person who has made the customary choice between the two methods of being legally robbed.1

Ambrose Bierce XML wird HTML nicht ablösen, jedenfalls nicht so schnell und nur in bestimmten Bereichen. Und XML wird vor allem denjenigen, die professionell mit dem World Wide Web arbeiten, einige Aufgaben erleichtern. Von manchen XML-Texten dürften Web-Surfer gar nichts merken, weil sie nur das in HTML gewandelte Ergebnis sehen. Andere XML-Dokumente wiederum kommen »nativ« (ohne Umweg) zum Browser.

Wie immer das letztlich aussieht, hinter den Kulissen verschiedener Ausgabegeräte (wie Bildschirm oder Braille-Lesegerät)2 wird sich einiges tun, das mit der Verwaltung von Websites, der Abwicklung von Geschäftsprozessen und Auslieferung von »Content« (das neudeutsche Wort für Inhalt) zu tun hat. Immer unter der Prämisse, die Einschränkungen von HTML endlich hinter sich gelassen zu haben. Die SGML-Arbeitsgruppe beim W3C, die sich ursprünglich darum bemühte, für die Standard Generalized Markup Language einen Weg ins Web zu finden, ist nicht zufällig bei XML gelandet – und damit fast bei SGML geblieben. Dies gilt vor allem seit Dezember 1997, als der SGML-Standard um ein paar Details ergänzt/verändert worden ist, die bewirken, dass XML tatsächlich eine Teilmenge von SGML ist (siehe dazu den Anhang A).

für XML modifiziert

SGML

»SGML on the Web« war ebenfalls keineswegs zufällig der Titel eines Buches [RUBI96], das die Begrenzungen von HTML aufzeigte und gleichzeitig Wege aufzeigte, um SGML ins Web zu bringen. YURI RUBINSKY, der das Buch geplant und begonnen hatte, hat den Erfolg von XML (das in Rubinskys Buch gar nicht vorkommt und vorkommen kann) leider nicht mehr erleben können; er starb Anfang 1996. Sein Freund und Kollege MURRAY MALONEY stellte das Werk fertig. Sowohl den Buchautoren als auch der oben genannten Arbeitsgruppe ging es um eine deutliche Verbesserung des World Wide Web. Anders ausgedrückt: ein Kompromiss zwischen zu viel Komplexität (SGML, jedenfalls was das Web angeht) und zu wenig Gestaltungsmöglichkeit (HTML).

1. Das Zitat stammt aus dem »Enlarged Devil's Dictionary«. 2. Display, sagt man heute allgemeiner...

47

3 XML im Web

»XML im Web« – das kann auf recht unterschiedliche Art und Weise geschehen. Und genau das wird sicherlich der Fall sein. Wie, das sei hier jeweils im Vergleich zu HTML dargestellt, und zwar aus zwei Gründen: 1. HTML ist bekannt genug, um als Vergleichsmaßstab zu dienen. 2. Für die Darstellung von XML-Dokumenten im Web ist die Sprache unter Umständen notwendig. Zwei Arten von XML-Dokumenten

Wandlung von im Browser oder auf dem Server

XML-Instanzen:

Zunächst aber noch ein paar Worte zu den möglichen XML-Dokumenten respektive -Anwendungen. In diesem Buch geht es hauptsächlich um zwei Arten: Es kann sich um einen Datenbankersatz handeln, das heißt um Daten, die vor allem bei großen Beständen wahrscheinlich in einem relationalen oder objektorientierten Datenbanksystem gelagert sind und von dort aus in ein XML-Format generiert werden. Anders ausgedrückt handelt sich um Anwendungen, die viele gleichartige Elemente beeinhalten (Adressbuch, Wörterbuch, Zeittafel). Die andere Art von Dokumenten (ein Beispiel ist das vorliegende Buch) ist zwar ebenfalls strukturiert, aber es handelt sich um eine wesentlich tiefer reichende Hierarchie. Und sie ist nicht nur für eine Dokumentinstanz gedacht, sondern für beliebig viele, während erstgenannte DTDs relativ speziell sind. Was in diesem Kapitel nicht thematisiert wird, sind Strukturbeschreibungen (siehe dazu Kapitel 13). Wer sich ein gutes Beispiel für eine Buch-DTD ansehen will, sei auf die DocBook-DTD verwiesen (nähere Informationen unter http://www.oasis-open.org/docbook/ und http://nwalsh.com/). Zwei Varianten stehen für die Darstellung von XML-Dokumenten in einem Web-Browser zur Wahl: entweder übernimmt der Client die Aufgabe, die Daten ohne Bearbeitung auf dem Server darzustellen, oder sie sind bereits auf dem Server so aufzubereiten beziehungsweise zu wandeln, dass auf der Client-Seite nicht mehr viel zu tun ist. Zukünftig dürften beide Methoden in Frage kommen. Wonach sich das richtet, wann welcher Weg sinnvoller sein mag, sollen die nächsten Abschnitte klären. Schließlich gibt es noch einen weiteren möglichen Einsatzbereich für XML: als Datenformat zwischen verschiedenen Anwendungen, die eine gemeinsame Sprache verwenden müssen, um Information austauschen zu können.

3.1

XML bei der Verwaltung von Websites

Unsichtbares Wirken von XML dürfte hinter den dicken Mauern der Firewalls an den Schreibtischen von Webmastern stattfinden. Hier sei nur kurz ein Beispiel genannt. Wer als Verantwortlicher für eine Website irgendwann einmal gemerkt hat, dass die vielen innerhalb der letzten Jahre entstandenen Seiten mit ihren Hunderten oder Tausenden von Referenzen (»Alle Links zu Bertolt Brecht« oder »Meine Lieblings-URLs«) vor allem dann ins Chaos führen, wenn bestimmte Links immer gleich auf drei, vier oder mehr Seiten aktualisiert werden müssen. Diesem Alptraum kann man mit XML entgegen-

48

XML bei der Verwaltung von Websites

wirken, indem eine zentrale Liste von Links diese abhängig von der Art ihres Inhalts definiert. Ein XML-Dokument zum Thema Web-Software könnte unterschiedliche Produktgruppen enthalten, innerhalb derer einzelne Produkte aufgelistet sind (mehr Details zu diesem Beispiel finden sich in 11.2). Mindfact OpenCms

Trotz der Kürze des Ausschnitts machen die wenigen Zeilen hoffentlich deutlich, dass sich hier eine fast beliebige Tiefe der Struktur erreichen ließe, denn Produktgruppen kann man in einer Art Übergruppe zusammenfassen, die selbst wiederum nur eine Untergruppe von etas anderem ist. Wichtig ist, dass man auf diese Weise eine lange Liste von Referenzen aufbauen kann. Tritt der unwahrscheinliche Fall ein, dass eine Firma ihre Web-Adresse ändert, greift die Webmistress auf die Link-Datei zu und ändert die Referenz. Einmal. Bei den ständigen Änderungen, denen Web-Adressen unterworfen sind, kann das tatsächlich helfen; vor allem aber vermeidet es, falsche Schreibweisen in langen URLs3.

Web-Verwaltung mit Hilfe von XML

Ein solches Vorgehen setzt voraus, dass die Webseiten, auf denen solche Informationen verwendet werden, entweder in HTML gewandelt auf dem Webserver landen oder mit einem Werkzeug wie Cocoon (siehe dazu das Kapitel 18) bearbeitet werden. Bei der Verwaltung von Websites ist der Unterschied zwischen Intranet und Internet nur dann von Bedeutung, wenn intern beispielsweise ein SGML-/ XML-fähiger Browser zum Einsatz kommt4, der Nicht-HTML-Daten nutzt. Selbst unabhängig von der Website lassen sich Einsatzmöglichkeiten denken, die zwar mit Hilfe von SGML schon »immer« vorhanden waren, die aber durch XML ins Bewusstsein von mehr Menschen rücken werden. SoftwareVerwaltung in einem heterogenen Netz etwa kann durchaus mit XML erfolgen (siehe Kapitel 16). Microsofts Channel-Lösung, das Pushing von Webseiten, gehört ebenfalls in diesen Zusammenhang. 3. Auf die Unterscheidung zwischen URL (Uniform Resource Locator) und URI (Universal Resource Identifier) sei hier verzichtet. Es gibt einen Unterschied zwischen beiden, aber der ist für die Betrachtung an dieser Stelle nicht relevant. 4. Der Unterschied wird in ein paar Jahren vielleicht nicht mehr relevant sein, was XML angeht.

49

3 XML im Web

3.2

Clientseitige XML-Interpretation

Statische und dynamisch erzeugte XML-Instanzen lassen sich ebenso wie HTML-Daten verschicken. Die Frage ist, wie die Browser XML darstellen.

3.2.1

XML mit CSS

XML in einem handelsüblichen Browser anzuzeigen, hat Microsoft durch den hauseigenen Web-Browser Internet Explorer in der Version 5 dadurch gelöst, dass der IE ein XML-Dokument in HTML gewandelt anzeigt, es sich aber um XML handelt, wie die sogenannte »Location«-Zeile zeigt, auf der datei.xml zu sehen ist. Das heißt, ein Dokument mit einer vom Web-Autor selbst gewählten Struktur (und ebensolchen Elementnamen) wird von einem IE-internen XSLT-»Prozessor« mit Hilfe eines Stylesheets »on the fly« gewandelt. Eine DTD ist hierfür nicht erforderlich (siehe Kapitel 11).

Die Lösung, nur die XML-Instanz zu schreiben oder zu generieren, hat den Vorteil, dass auch diejenigen, die sich mit dem DTD-Schreiben nicht anfreunden wollen oder können, XML »machen« können. Alles, was nötig ist, ist die oben genannte Wohlgeformtheit, das heißt ein ordentlich strukturiertes Markup, geschlossene Elemente et cetera – ohne DTD. Werkzeuge, die unbedingt die DTD lesen wollen, kann man zwar in solchen Fällen nicht nutzen, aber für einfach strukturierte Dokumente wird CSS reichen. Alles, was Web-Autoren, die von dieser Möglichkeit Gebrauch machen wollen, benötigen, sind das ordentlich ausgezeichnete Ausgangsdokument und ein Stylesheet (Näheres siehe in Kapitel 9).

3.2.2

XML

mit XSL(T)

Bis auf zugegebenermaßen viele Ausnahmen wird eine HTML-Webseite im Quelltext – möglicherweise gemeinsam (wenn auch nicht ganz zeitgleich) mit Bildmaterial und Musik – vom HTTP-Server an den Browser geschickt, der das Material nach den Vorgaben der Datei darstellt. Hinzukommen kann die Übertragung eines Cascading Stylesheets oder auch eines Applets; Videos auf keinen Fall vergessen... Mit XML-Dokumenten und XSL(T)Stylesheets ist das noch nicht möglich, weil die entsprechenden Clients fehlen beziehungsweise nicht weit genug verbreitet sind. Insofern entfällt zumindest für die nächsten Monate die Option, einfach XML-Quellen samt XSL(T)-Stylesheets ins Web zu stellen und darauf zu hoffen, dass die SurferMassen über die eigenen Seiten hereinbrechen5. 5. Der Explorer 5 kann es schon ansatzweise; Netscapes RAMANATHAN GUHA hat schon Ende März 1998 auf der XML98 in Seattle darüber gesprochen, wie Navigator 5 XML unterstützen soll Auf die Realisierung warten wir jetzt immer noch. Immerhin gibt es auf http://www.mozilla.org/ vielversprechende Vorversionen.

50

XML

auf dem Server

In dieser Hinsicht bleibt also ein bisschen Warten. Dennoch hier ein paar Details dazu, was in diesem Fall geschieht. Ein XML-Dokument enthält im Wesentlichen ausgezeichnete Daten. Außerdem sollte das Quelldokument für die Darstellung im Browser eine so genannte Processing Instruction (PI, deutsch etwa: Verarbeitungsanweisung) enthalten, die festlegt, welches Stylesheet hier zum Tragen kommen muss. Es definiert, welche Teile des Dokuments wie darzustellen sind – und welche nicht.

Warten auf »richtige« XML-Browser