XMLidP2000

Sitemap

Sitemap

1 Einführung
1.1 Warum mehr weniger ist
1.2 Warum mehr mehr ist
1.3 Wohin die Reise geht
2 Was sind Dokumente?
2.1 Eine kurze Geschichte der Textverarbeitung
2.2 Bestandteile eines Dokumentes
2.3 Die neue, alte Idee: Strukturorientiert schreiben
2.4 Die Entwicklung des Hypertextes
2.5 Textformate im Web
2.6 Das SGML-Konzept: Generic Markup
2.7 Dokumente versus Daten
3 XML im Web
3.1 XML bei der Verwaltung von Websites
3.2 Clientseitige XML-Interpretation
3.2.1 XML mit CSS
3.2.2 XML mit XSL(T)
3.3 XML auf dem Server
3.4 Linking-Möglichkeiten von XML
3.5 XML als Datenaustauschformat
4 XML Quick Start
4.1 Dokumenttyp-Definition (DTD) und Instanzen
4.2 Verarbeitung der Dokumente
4.2.1 Beispiel: Verarbeitung mit Cost/TCL
4.2.2 Beispiel: Verarbeitung mit XSLT
4.2.3 Beispiel: XML/XSLT im Internet Explorer
4.2.4 Fazit
5 XML-DTDs: Die verständliche Beschreibung
5.1 Ein Wort zur Notation
5.2 Dokumente
5.3 Elemente
5.4 Zeichen, Namen und Zeichendaten
5.5 Kommentare
5.6 Processing Instructions
5.7 Wo bleibt Multimedia?
5.8 Dokumenttyp-Definition (DTD)
5.8.1 Elementtyp-Deklaration
5.8.2 Attributlisten-Deklaration
5.8.3 Möglichkeiten, die DTD zu gestalten und zu gliedern
5.8.4 Notation-Deklaration
6 Namensräume in XML
7 XPath: Adressierung von XML-Dokumentteilen
7.1 Zu Grunde liegendes Datenmodell
7.2 Zugriff auf den Datenbaum
7.3 Hilfe von Operatoren
7.4 Kernfunktionen für den Datenzugriff
8 XML: Linking
8.1 Notwendige Begriffe
8.2 XLink: einfache und erweiterte Links
8.2.1 Einfache Verweise
8.2.2 Erweiterte Links
8.2.3 XLink in der Praxis
8.3 XPointer: Verweise in Dokumente hinein
8.3.1 XPath-Erweiterungen in XPointer
9 Überblick über Stylesheet-Sprachen
9.1 Cascading Style Sheets
9.1.1 Wertzuweisungen
9.1.2 Formatierungsmodell
9.1.3 CSS und XML
9.1.4 Ein Beispiel: XML im Mozilla
9.2 Document Style Semantics and Specification Language
9.2.1 Flow Objects
9.2.2 Verarbeitungs-Modus
9.2.3 DSSSL praktisch
9.2.4 Langer Marsch von DSSSL nach HTML
9.3 Extensible Stylesheet Language (XSLT und XSL)
9.3.1 Verhältnis von XSLT zu XSL
9.3.2 Formatierung mit XSL
10 XSL-Transformationen
10.1 Grundsätzliches über Templates
10.2 Ergänzungen zum Datenmodell von XPath
10.3 Struktur von XSLT-Stylesheets
10.4 Den Ergebnisbaum erzeugen
10.4.1 Diverse Basiselemente
10.4.2 Formatierte Nummerierung
10.4.3 Schleifen und bedingte Verarbeitung
10.4.4 Sortieren
10.4.5 Variable und Parameter
10.4.6 Zusätzliche Funktionen
10.4.7 XSLT-Erweiterungen
10.4.8 message, output
11 XSLT in Web-Anwendungen
11.1 XSLT im Internet Explorer
11.2 Linklisten erzeugen
11.3 Details einer Literaturgeschichte
11.3.1 Sortierte Überblicksseiten
11.3.2 Kalender: einzelne Tage ausgeben
12 XML-Editoren
12.1 Übersicht
12.1.1 Emacs + PSGML (mit XML-Unterstützung)
12.1.2 XML Notepad
12.1.3 XML Spy
12.1.4 XMetal
12.1.5 Epic
12.1.6 MarkupKit (für MS Word)
12.1.7 WordPerfect Office2000
12.2 Emacs und PSGML (mit XML-Unterstützung)
12.3 XML-Notepad
12.4 XML Spy
12.5 XMetal
12.6 Epic
12.7 MarkupKit (für MS Word)
12.8 WordPerfect Office2000
12.9 Fazit
13 Entwicklung einer DTD
13.1 Auswahl einer Mehrzweck-DTD
13.2 Entwurf einer DTD
13.2.1 Dokumentanalyse
13.2.2 Tipps und Tricks
13.3 Instanzen ohne DTD
14 Herstellung dieses Buches
14.1 Zielsetzung und Randbedingungen
14.2 Definition der DTD
14.2.1 Schritt 1: Die Grobstruktur
14.2.2 Schritt 2: Elemente auf Zeichenebene
14.2.3 Schritt 3: Die Details
14.3 Formatieren des Manuskriptes
14.3.1 Konvertierung in HTML
14.3.2 Aufbereitung für den Ausdruck
14.4 Erfahrungen mit der zweiten Auflage
15 Anwendungsbeispiel Literatur
15.1 Vorüberlegungen
15.2 En détail: die Autoren in der DTD
15.3 Wie die Daten ins Web gelangen
15.3.1 Inhaltsverzeichnis generieren
15.3.2 Ausgabe der Autorendaten
15.4 Vollständige Listings
15.4.1 DTD für die Literaturgeschichte
15.4.2 DSSSL-Listing: Inhaltsverzeichnis
15.4.3 DSSSL-Listing: Ausgabe eines einzelnen Autors
15.4.4 Perl-Code für Ausgabe einzelner Autoren
16 Verteilte Softwareverwaltung mit XML
16.1 Aufgabenbeschreibung
16.2 XML als Datenbasis
16.3 Bilden von DTD-Hierarchien
16.4 Zusammentragen von verteilten XML-Fragmenten
16.5 Fazit
16.6 Stylesheet zur Transformation in HTML
17 E-Commerce mit XML
17.1 B2B-E-Commerce
17.1.1 Die Rolle von XML
17.1.2 Technische Aspekte
17.2 BMEcat
17.3 Electronic Business XML (ebXML)
17.3.1 Arbeitsgruppen
17.3.2 Zeitplan des Projekts
17.4 XML und EDIFACT
18 XML und Apache
18.1 XML-Transformation per CGI
18.1.1 Konfiguration des Servers
18.1.2 CGI-Skript: xmlhandler.cgi
18.1.3 Beispiel: von HTML nach HTML mit DSSSL oder XSLT
18.2 Cocoon
18.2.1 Extensible Server Pages (XSP)
18.2.2 Beispiel: Formatierung in PDF mit XSL
18.2.3 Beispiel: Simuliertes XLink mit Dynamic HTML/JavaScript
18.2.4 Installation
19 XHTML: Neues HTML 4 — erweiterbar
19.1 Status quo: HTML neu definiert
19.2 Modulare Zukunft
20 Transformation von XML in WML und HTML
20.1 Erzeugen der WML-Dateien
20.2 Erzeugen der HTML-Dateien
21 Ausblick
21.1 XML Schema
21.2 Programmierung mit XML-Daten
21.3 XML und Java
21.4 Resource Description Framework
21.5 Die Zukunft
A Extensible Markup Language (XML) 1.0
A.1 Einleitung
A.1.1 Herkunft und Ziele
A.1.2 Terminologie
A.2 Dokumente
A.2.1 Wohlgeformte XML-Dokumente
A.2.2 Zeichen
A.2.3 Allgemeine syntaktische Konstrukte
A.2.4 Zeichendaten und Markup
A.2.5 Kommentare
A.2.6 Processing Instructions
A.2.7 CDATA-Abschnitte
A.2.8 Prolog und Dokumenttyp-Deklaration
A.2.9 Standalone-Dokumentdeklaration
A.2.10 Behandlung von Leerraum
A.2.11 Behandlung des Zeilenendes
A.2.12 Identifikation der Sprache
A.3 Logische Strukturen
A.3.1 Start-Tags, End-Tags und Leeres-Element-Tags
A.3.2 Elementtyp-Deklarationen
A.3.3 Attributlisten-Deklaration
A.3.4 Bedingte Abschnitte
A.4 Physikalische Strukturen
A.4.1 Zeichen- und Entity-Referenzen
A.4.2 Entity-Deklarationen
A.4.3 Analysierte Entities
A.4.4 Behandlung von Entities und Referenzen durch einen XML-Prozessor
A.4.5 Konstruktion des Ersetzungstextes von internen Entities
A.4.6 Vordefinierte Entities
A.4.7 Notation-Deklarationen
A.4.8 Dokument-Entity
A.5 Konformität
A.5.1 Validierende und nicht-validierende Prozessoren
A.5.2 Benutzen von XML-Prozessoren
A.6 Notation
A.7 Anhang A: Referenzen
A.7.1 Normative Referenzen
A.7.2 Weitere Referenzen
A.8 Anhang B: Zeichenklassen
A.9 Anhang C: XML und SGML (nicht normativ)
A.10 Anhang D: Expansion von Entity- und Zeichenreferenzen (nicht normativ)
A.11 Anhang E: Deterministische Inhaltsmodelle (nicht normativ)
A.12 Anhang F: Automatische Erkennung von Zeichenkodierungen (nicht normativ)
A.13 Anhang G: XML-Arbeitsgruppe des W3C (nicht normativ)
B Verknüpfen von Style Sheets mit XML-Dokumenten Version 1.0
B.1 Die xml-stylesheet-Processing-Instruction
B.2 Anhang A: Referenzen
B.3 Anhang B: Begründung
C Verhältnis von XML zu SGML und HTML
C.1 XML und SGML
C.2 XML und HTML
D Übersichten
D.1 Cascading Style Sheets
D.1.1 CSS-Eigenschaften und -Werte
D.1.2 CSS-Muster
D.2 DSSSL: Flow Objects
D.3 Syntax der XSLT-Elemente
D.4 DTD-Fragment für XSLT-Stylesheets (nicht normativ)
D.5 Relevante Spezifikationen und Organisationen
D.5.1 International Organization for Standardization
D.5.2 World Wide Web Consortium
D.5.3 Organization for the Advancement of Structured Information Standards
D.5.4 Internet Society und Internet Engineering Task Force
D.5.5 ISO-639-Sprachcodes
D.5.6 ISO-3166-Ländercodes
D.5.7 Zeichensatz ISO-Latin-1
D.5.8 Sonderzeichen
D.6 XML-1.0-Regeln

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, nichtFussnoteIn Form von XHTML werden es Webautoren mittelfristig auf jeden Fall mit einer XML-Anwendung zu tun bekommen.. 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.

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 SGMLFussnoteDen Fachmann wird's zwar nerven, aber gerade in diesem Kapitel kann man nicht oft genug darauf hinweisen. 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.

Hinweis

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, demFussnoteJa, auch der ... ;-) 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.
  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:

Beispiel
<mitarbeiter id="firma.abteilung.4725721.r238-4523/003"
        eintritt="01011976"
        lastmod="04021997"
        lastmodby="firma.abteilung.31296.261263c-3461/001">
    <name>Meier</name>
    <vorname>Heinz</vorname>
    <gebdatum>
          <jahr>1938</jahr>
          <monat>10</monat>
          <tag>29</tag>
    </gebdatum>
<!-- viele weitere Daten -->
</mitarbeiter> 
        

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.

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:

Beispiel
<mein-elem attribut="wert">Inhalt von 
mein-elem</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:

<abbildung src="bildquelle" text="bild-kommentar" />
<abbildung src="bildquelle" text="bild-kommentar"></abbildung>        

Was in HTML durch die Großzügigkeit der DTD möglich ist, nämlich End-Tags 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:

<body bgcolor="#ffffff" text="#000000">

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

Vorsicht!
<p>Beispiel: <b>fetter und 
<i>kursiver</b> Text</i> 
ab hier normal</p>
Navigator 4.04 stellt das letzte Listing wie diese
  Abbildung dar.

Abbildung 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 sindFussnoteNoch einmal zum Grund dafür: Es gibt in XML keine Tag-Minimierung, das heißt, man darf keine End-Tags weglassen.. 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 Web-Autoren 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.

Valid HTML 4.01!Valid CSS!