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

5.8.3 Möglichkeiten, die DTD zu gestalten und zu gliedern

Entity-Referenzen zur Abkürzung und Mehrfachverwendung von wiederkehrenden Phrasen haben Sie bereits kennen gelernt. Der Einsatz ist auf die Instanz beschränkt, in der DTD jedoch nicht zulässig. An ihre Stelle tritt die so genannte Parameter Entity ReferenceFussnoteDer Name rührt wohl daher, dass sie in der Elementtyp-Deklaration als Parameter zulässig ist. (PEReference). Die Schreibweise unterscheidet sich von den Entity References dadurch, dass statt des et-Zeichens (&) nun ein Prozentzeichen (%) als Präfix dient. Ein häufiger Anwendungsfall besteht darin, Inhaltsmodelle, die für mehr als einen Elementtyp verwendet werden, unter einem Namen zusammenzufassen.

Beispiel
<!ENTITY % block "absatz | listing | abbildung | kasten">
 
<!ELEMENT buch            (kapitel+)>
<!ELEMENT kapitel         (ueberschrift, (%block;)*, abschnitt+)>
<!ELEMENT abschnitt       (ueberschrift, (%block;)*, unterabschnitt*)>
<!ELEMENT unterabschnitt  (ueberschrift, (%block;)+)>

In obigem Beispiel gibt es mehrere Textblöcke, die im Inhaltsmodell dreier Elementtypen auftreten. Auf den ersten Blick ist damit nur eine kürzere Schreibweise erzielt worden. Sollten nun aber Änderungen anstehen, wie etwa das Hinzufügen eines Blockelements Tabelle, so muss lediglich die Definition der PEReference geändert werden. Neben der leichteren Wartbarkeit einer DTD erhöht sich durch den sinnvollen Einsatz von PEReferences auch die Lesbarkeit.

Innerhalb einer DTD kann man auf diese Weise Ordnung schaffen. Ein anderes Problem ist noch offen: Wie schafft man es, dass Elementtypen, die in mehreren DTDs enthalten sind, nicht in jede DTD-Datei einzeln hineingeschrieben werden müssen? Ein konkretes Beispiel sind Tabellen. Es ist nicht leicht, ein gutes Tabellenmodell zu entwerfenFussnoteIn der Praxis wird man ein Tabellenmodell verwenden, mit dem man schon vertraut ist, wie zum Beispiel die HTML-Tabellen oder das CALS-Modell, das zum Teil als Vorlage für HTML gedient hat.. Hat man einmal eines, so wird man es sicherlich gern in alle eigenen DTDs einbauen wollen. Auch dies lässt sich bequem mit PEReferences realisieren, und zwar als externes Entity. Unser obiges Beispiel ändern wir dafür wie folgt ab:

Beispiel
<!ENTITY % tab-modell SYSTEM "/usr/local/sgml/tabelle.dtd">
%tab-modell;
<!ENTITY % block "absatz | listing | abbildung | kasten | tabelle">

Hier sind die Blöcke um eine Tabelle ergänzt worden. Die Tabelle selbst ist aber in einer externen Datei namens tabelle.dtd gespeichert, die sich im Verzeichnis /usr/local/sgml/ befindet. Die erste Zeile definiert das Entity tab-modell. In der zweiten Zeile wird dieses Entity expandiert, d.h. der Inhalt der Datei wird an dieser Stelle eingefügt. Die Wirkung ist also die gleiche, als ob die Deklaration für den Elementtyp Tabelle (und seine ggf. benötigten weiteren Elementtypen) in der DTD selbst stünde.

Auf diese Weise können Sie immer wieder benutzte DTD-Fragmente in einzelne Dateien auslagern und Ihre DTDs wie mit einem Baukasten zusammensetzen. Beispiele für solche Fragmente sind neben der Tabelle auch das Glossar, die Bibliografie, aber auch solche auf den ersten Blick einfachen Elementtypen wie Abbildungen. Sehen Sie sich einmal die Beschreibung des Elementtyps object in HTML 4 an. Es ist aus dem img hervorgegangen und zeigt, wie kompliziert es sein kann, einfach ein Objekt in ein Dokument einzufügen.

In der Definition des externen Entity haben wir im Beispiel einen (Unix-)Pfadnamen angegeben. Wie diese Zeichenkette verarbeitet wird, liegt außerhalb des XML-Standards. Auf einem PC würde also ein anderer Pfadname stehen, etwa C:\sgml\tabelle.dtd. Zusätzlich zu den systemabhängigen Bezeichnern kann man auch noch die Public Identifier verwenden. Sie sind system-unabhängig und müssen vom XML-Prozessor in geeigneter Weise in einen Dateinamen o.Ä. umgewandelt werden. Die HTML-4-DTD lädt zum Beispiel die Entities für den ISO-Latin-1-Zeichensatz mit einer Kombination aus Public und System IdentifierFussnoteDas Beispiel zeigt auch, dass ein System Identifier auch ein URL sein kann. Es hängt von dem verarbeitenden Programm ab, ob es etwas damit anfangen kann.:

Beispiel
<!ENTITY % HTMLlat1 PUBLIC
   "-//W3C//ENTITIES Latin1//EN//HTML"
   "http://www.w3.org/DTD/ISOlat1.ent">
%HTMLlat1;

Bedingte Abschnitte
Das nächste Feature, das wir Ihnen vorstellen wollen, hat zwar nicht direkt mit Parameter-Entities zu tun, lässt sich damit aber besser nutzen. Es geht um Abschnitte einer DTD, die nicht immer sichtbar sind, sondern nur unter gewissen Bedingungen.

Stellen Sie sich vor, Sie schreiben einen etwas umfangreicheren Text, vielleicht ein Buch. Meist werden Sie es nicht schaffen, einen so langen Text beim ersten Versuch so zu schreiben, wie Sie es gerne möchten. Dem ersten Entwurf folgt der zweite und so weiter, bis endlich nach einigen Schritten die endgültige Form vor Ihnen liegt. In der Entwurfsphase ist es üblich, Kommentare und Bemerkungen zu schreiben, die im gedruckten Buch nicht enthalten sein dürfen. Dazu können Sie natürlich XML-Kommentare einsetzen. Der Nachteil ist dabei, dass der Kommentartext in einem Probeausdruck nicht sichtbar ist. Schöner wäre es doch, einen Elementtyp kommentar zur Verfügung zu haben, dessen Inhalt auch im Probeausdruck erscheint. Nichts leichter als das:

Beispiel
<!ELEMENT kommentar  (#PCDATA)>

So weit so gut. Nun müssen Sie nur noch aufpassen, dass Sie Ihre Kommentare löschen, sobald die Arbeit beendet ist. Auch hier liegt eine Idee zur Verbesserung nahe: Das XML-System soll prüfen, ob alle Kommentare entfernt sind. Diese Überprüfung überlässt man am besten dem Parser, indem man die Definition des Elementtyps kommentar aus der DTD entfernt. Umgangssprachlich ist also Folgendes gewünscht: Kommentare sind in der Entwurfsphase erlaubt, in der endgültigen Fassung jedoch verboten. XML bietet dafür ein Konstrukt an, genannt bedingter Abschnitt. Realisiert wird er durch einen markierten Abschnitt der externen (!) DTD, der entweder berücksichtigt (include) oder ignoriert wird (ignore). Für die Entwurfsphase sieht das so aus:

Beispiel
<![INCLUDE[
   <!ELEMENT kommentar  (#PCDATA)>
]]>

Nach getaner Arbeit weisen Sie den Parser an, die Kommentar-Deklaration zu ignorieren:

<![IGNORE[
   <!ELEMENT kommentar  (#PCDATA)>
]]>

Sollte Ihre Instanz nun noch ein Element vom Typ kommentar enthalten, so wird der Parser dies als nicht deklarierten Typ, also als Fehler, anzeigen.

Wenn Sie solche bedingten Abschnitte an mehr als einer Stelle einsetzen, kann es recht lästig sein, zwischen INCLUDE und IGNORE zu wechseln. Leichter geht es mit geschickt benutzten Parameter-Entities, wie das folgende Beispiel demonstriert.

Beispiel
<!ENTITY % entwurf 'INCLUDE' >
<!ENTITY % fertig  'IGNORE' >
 
<![%entwurf;[
   <!ELEMENT kommentar  (#PCDATA)>
]]>
 
<![%fertig;[
   <!ELEMENT kommentar  EMPTY>
]]>
Tipp

Die Funktion ist die gleiche wie zuvorFussnoteEin Unterschied besteht darin, dass ein Kommentar in der endgültigen Fassung zwar noch erlaubt ist, jedoch nur als leeres Element. Der Parser zeigt also bei einem nicht leeren Kommentar immer noch einen Fehler an.. Hier genügt es jedoch, in der Definition der Entities die Worte INCLUDE und IGNORE zu vertauschen. Die Änderung wird damit automatisch für alle bedingten Abschnitte wirksam.

Valid HTML 4.01!Valid CSS!