Computervermittelte Kommunikation

Kapitel 12: OSI-Schicht 6: Presentation Layer -- Datendarstellungsschicht

Teil II: SGML und XML

von Margarete Payer

Zitierweise / cite as:

Payer, Margarete <1942 -- >: Computervermittelte Kommunikation. -- Kapitel 12: OSI-Schicht 6: Presentation Layer -- Datendarstellungsschicht. -- Teil 2: SGML und XML. -- Fassung vom 2001-01-21. -- URL: http://www.payer.de/cmc/cmcs1202.htm. -- [Stichwort].

Erstmals publiziert: 1995

Überarbeitungen: 23. Juni 1997; 21.6.1999 [grundlegende Neubearbeitung und Erweiterung]; 2001-01-21 [Kleine Verbesserungen]

Anlass: Lehrveranstaltungen an der HBI Stuttgart

©opyright: Dieser Text steht der Allgemeinheit zur Verfügung. Eine Verwertung in Publikationen, die über übliche Zitate hinausgeht, bedarf der ausdrücklichen Genehmigung der Verfasserin.

Zur Inhaltsübersicht von Margarete Payer: Computervermittelte Kommunikation.

12.0. Übersicht

12.5. SGML (Standard Generalized Markup Language) und XML (Extensible Markup Language)
- 12.5.1. Ablauf eines zeitgemäßen Publikationsvorgangs
- 12.5.2. Einleitung zu und Geschichte von SGML und XML
- 12.5.3. Grundzüge von SGML
- 12.5.4. Zusammenfassung: SGML-gestütztes Publizieren
- 12.5.5. SGML profiles: XML
12.6. XML -- Extensible Markup Language
- 12.6.1. Aufbau eines XML-Dokumentes
- 12.6.2. XML Declaration
- 12.6.3. DTD -- Document Type Definition
  - 12.6.3.1. Allgemeine Syntax einer formal markup declaration
  - 12.6.3.2. ELEMENT declarations
  - 12.6.3.3. ATTLIST declarations
  - 12.6.3.4. General_ENTITY declarations
  - 12.6.3.5. Parameter_ENTITY declarations
  - 12.6.3.6. NOTATION declarations
- 12.6.4. XLink (XLL)
- 12.6.5. XPointer
- 12.6.6. XSL -- Extensible Stylesheet Language
- 12.6.7. Umsetzung eine XML-Ausformung/Manifestation in ein Einzelexemplar
12.7. Anwendungen von SGML und XML
- 12.7.1. Wichtige öffentlich zugängliche Document Type Definitions (DTD) in SGML
  - 12.7.1.1. ISO 12083
  - 12.7.1.2. DocBook
  - 12.7.1.3. TEI DTD -- Text Encoding Initiative DTD
  - 12.7.1.4. CALS und MIL-STD-38784
  - 12.7.1.5. Kompatibilitätsfragen: Architectural Forms
- 12.7.2. Electronic Manuscript Project (-> Z39.50)
- 12.7.3. HyTime -- Hypermedia/Time-based Structuring Language : ISO 10744
- 12.7.4. XML und Metadata
- 12.7.5. Einige XML-konforme Spezial-MLs
12.8. Weiterführende Ressourcen zu SGML und XML

12.5. SGML (Standard Generalized Markup Language) und XML (Extensible Markup Language)

Zu den wichtigsten "Formaten" für den Austausch von Daten gehören SGML (Standard Generalized Markup Language) und XML (Extensible Markup Language).

12.5.1. Ablauf eines zeitgemäßen Publikationsvorgangs

Als Einführung zu SGML und XML soll kurz der Ablauf eines Publikationsvorganges dargestellt werden, der nicht der technischen Revolution Gutenbergs (15. Jahrhundert!) entspricht, sondern der technischen Revolution (Computer und Kommunikation) der zweiten Hälfte des 20. Jahrhunderts.
**Ablauf eines zeitgemäßen Publikationsvorgangs**
1.	Gedankliche Konzeption	als solche nicht darstellbar
2.	Computer-Fassung von Werk	als solche nicht darstellbar
3.	Computerfassung von Ausformung	als solche nicht darstellbar
4.	Computerfassung der Manifestation	darstellbar
5.	Physische Darstellung des Einzelexemplars	benutzbar

Das Folgende folgt den Grundgedanken des IFLA-Draft:

**Functional requirements for bibliographic records** : draft report for world-wide review / recommended by the IFLA Study Group on the Functional Requirements for Bibliographic Records. -- Frankfurt am Main : Deutsche Bibliothek, 1996. -- 115 S. : graph. Darst.
Fußn.: erarbeitet innerhalb: IFLA Universal Bibliographic Control and International MARC Program

Ausführlicher dazu siehe:

**Payer, Margarete <1942 - >:** Datenbankaufbau : Skript / Margarete Payer & Alois Payer. -- Kapitel 3: Datenbank-Design: Entity-Relationship (ER) Modelling. -- Fassung vom 15. Mai 1997. -- URL: http://machno.hbi-stuttgart.de/~payer/dbauf03.html#3.2.1.1.

Den Zweck dieser Studie beschreibt Olivia M. A. Madison, die Vorsitzende der Study Group in ihrem Begleitschreiben zum Draft vom 10. Juni 1996 so:

"Briefly stated, the purpose of this study is to delineate in clearly defined terms the functions performed by the bibliographic record with respect to various media, applications, and user needs. The study covers the full range of functions for the bibliographic record in the widest sense (i.e., a record that encompasses not only descriptive elements, but also access points (name, title, subject, etc.), other »organizing elements« (classification, chronological codes, etc.), and annotations). The study`s ultimate recommendation is a proposed basic level of functionality and basic data requirements for records created by national bibliographic agencies."

Dieser Draft schlägt für die bibliographische Beschreibung folgende Entities vor:

**Works -- Werke:** "a distinct intellectual or artistic creation" -- eine einzelne intellektuelle oder künstlerische Schöpfung. *Werk* ist eine abstrakte Entity. Ein Werk ist in individuellen *Expressions* realisiert. *Werk* aber ist die abstrakte Gemeinsamkeit der verschiedenen *Expressions* des Werkes. So ist *Asterix und Kleopatra* ein Werk, das in verschiedenen Ausgaben, in Originalsprache und Übersetzungen als seinen Expressions realisiert ist.

***Expressions -- Ausformungen:*** "the intellectual or artistic realization of a work in the form of alpha-numeric, musical, or choreographic notation, sound, image, object, movement, etc., or any combination of such forms" -- die intellektuelle oder künstlerische Verwirklichung eines *Werkes* in Form einer alphanumerischen, musikalischen oder choreographischen Notation, oder in Form von Ton, Bild, Objekt, Bewegung usw. So sind eine Partitur, eine Tonwiedergabe und eine Opernaufführung von *Parzival* drei Expressions desselben *Werkes.* Auch Übersetzungen, Bearbeitungen, Arrangements, Überarbeitungen usw. sind Expressions.

***Manifestations -- Manifestationen:*** "the physical embodiment of an *expression* of a work" -- die physikalische Verkörperung einer *Expression.* Z. B. die sind die verschiedenen Druckausgaben der Partitur von *Parzival* verschiedene Manifestationen der Expression *Partitur von Parzival*. Verschiedene Ausgaben desselben Textes sind Manifestationen, usw.

**Items -- Einzelexemplare:** "a single exemplar of a *manifestation*" -- ein Einzelexemplar einer Manifestation. z. B. das vorliegende Exemplar der Ausgabe von 1906 im Buddhistischen Missionsverlag von Friedrich Zimmermann's Buddhistischem Katechismus.

*Persons -- Personen:* "an individual" -- ein Individuum

*Corporate Bodies -- Körperschaften:* "an organization or group of individuals and/or organizations acting as a unit" -- eine Organisation oder eine Gruppe von Individuen und/oder Organisationen, die als Einheit handelt. Hierher gehören auch Kongresse, Expeditionen, Ausstellungen, Messen usw.

*Concepts -- Begriffe:* "an abstract notion or idea" -- ein abstrakter Begriff oder Idee. Begriffe werden hier nur insoweit berücksichtigt als sie Gegenstand eines Werkes sind (z.B. *Erlösung* als Gegenstand eines theologischen Traktates).

*Objects -- materielle Objekte:* "a material thing" -- ein materielles Ding. Materielle Objekte werden hier nur insoweit berücksichtigt als sie Gegenstand eines Werkes sind (z.B. *Plüschkatzen* als Gegenstand einer wissenschaftlichen Abhandlung).

*Events -- Ereignisse:* "an action or occurrence" -- eine Handlung oder ein Vorkommnis. (z.B. *der 2. Weltkrieg* als Gegenstand eines Romans)

*Places -- Orte:* "a location" -- eine Örtlichkeit. Begriffe werden hier nur insoweit berücksichtigt als sie Gegenstand eines Werkes sind (z.B. *Ofterdingen* als Gegenstand eines Ortsplanes).

Für unsere Zwecke sind bedeutsam die Entitäten Werk, Ausformung, Manifestation, Einzelexemplar:

**Beispiel für Werk - Ausformung - Manifestation - Einzelexemplar**
Werk	Statistische Datenbanken des Bundes und der Länder
Ausformungen	Statistisches Jahrbuch der BRD	Länderberichte (ausländische Staaten)		Atlas		Agrarstatistik usw.
Manifestationen	Druckausgabe		CD-ROM		On-line
Einzelexemplare	gedruckte Bücher	physische CD-ROMs		On-line Sites		.....

Wenn man mit Hilfe von Computern publiziert, stehen für die einzelnen bibliographischen Entities folgende Hilfsmittel zur Verfügung: SGML und XML werden in diesem Kapitel ausführlich behandelt, HTML in Kapitel 13, 2,2.
**Publizieren mit Hilfe eines Computer**
Werk und seine Derivate	Computer-Fassung	Physische Darstellung
Werk (work, abstraction)	SGML
Ausformung (expression, abstraction)	SGML, XML, [HTML (semantische Tags)]
Manifestation (manifestation, rendition, Ausgabe)	SGML-DTD, XML-DTD, HTML (Style-Tags), PostScript, Textverarbeitungsformate, Style sheets ...
Einzelexemplar (item)		Verschiedene Medien: Hardcopy, Braille, Bildschirmdarstellung, CD-Rom, Audio, Video ....

12.5.2. Einleitung zu und Geschichte von SGML und XML

SGML -- Standard Generalized Markup Language ist eine Dokument-Definier-Sprache, die den Austausch von Informationen beliebiger Komplexität unabhängig von herstellerspezifischer Soft- und Hardware ermöglichen soll.

SGML ist internationaler ISO-Standard:

ISO 8879 (1986): Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML)

Markup-Languages sind keine neue Erfindung: in der Form von Satzanweisungen waren sie ein unentbehrliches Hilfsmittel für Verfasser und Lektoren, um Schriftsetzern ihre Wünsche mitzuteilen, wie das Manuskript (die "Ausformung" des Werkes) in eine "Manifestation" umgesetzt werden soll. Die folgenden Abbildungen zeigen einen Ausriss einer solchen Markup-Language, wie sie in den 60er und 70er-Jahren des 20. Jahrhunderts in Deutschland gebräuchlich war:

Markup	Beispiel

Abb.: "Klassische" Markup-Language: Markup für Buchsatz

Quelle der Abb.: Satzanweisungen und Korrekturvorschriften : mit ausführlicher Beispielsammlung / hrsg. von der Dudenredaktion und der Dudensetzerei. -- Mannheim : Bibliographisches Institut, ©1969. -- 187 S. : Ill. -- (Duden-Taschenbücher ; 5/5a). -- [Ein "klassisches" Regelwerk einer Markup-Language für die Epoche der traditionellen Buchproduktion]

Für den anglo-amerikanischen Raum sind die Regeln einer dieser klassischen Markup-Languages (neben vielem anderen) immer noch enthalten in:

The Chicago Manual of Style. -- 14. ed. -- Chicago [u.a.] : Univ. of Chicago Press, ©1993. -- 921 S. : Ill. -- ISBN 0226103897. -- {Wenn Sie HIER klicken, können Sie dieses Buch bei amazon.de bestellen}

Ausgangspunkt zu SGML in ihrer jetzigen Form war der Paradigmawechsel vom Konzept des Specific Coding (Procedural Markup) zum Konzept des Generic Coding (Descriptive Markup).

Specific Coding codiert spezifische Prozeduren (procedural markup), wie z.B. Formatierungskommandos (z.B. ESC, CTRL oder SHIFT Kommandos)
Generic Coding codiert dagegen den Zweck oder die Funktion, beschreibt also, was die konkrete Formatierung ausdrücken soll (descriptive markup) (z.B. Titel, Kapitel, Anmerkung)

Vermutlich geht die Anregung zu diesem Paradigmenwechsel auf William Tunnicliffe zurück, der 1967 bei einer Sitzung des Canadian Government Printing Office vorschlug, den Informationsgehalt eines Dokumentes von seinem Format zu trennen. Diese und andere Anregungen führten zur Gründung des Generic Coding Projekt innerhalb des Composition Committe der Graphic Communications Association (GCA). In diesem Projekt wurde das GenCode(R)-Konzept entwickelt: man erkannte, dass verschiedene Arten von Dokumenten verschiedene Codes benötigen und, dass man kleinere Dokumente als Elemente in größere Dokumente einbinden könnte.

Es zeigte sich bald, dass der Versuch, ein Generic Coding für alle Dokumententypen zu entwerfen, daran scheitern würde, dass es zu viele verschiedene Dokumententypen mit zu vielen unterschiedlichen Arten von Elementen gibt. Die Lösung fand man darin, dass man SGML nicht als eine Gesamtheit von standardisierten Codes entwarf, sondern als eine Art Programmiersprache, mit der man eine Dokumenten-Typ-Definition (document type definition) (DTD) erstellen konnte. Die DTD kann die Elemente usw. definieren, die man für ein Dokument oder eine Gruppe ähnlicher Dokumente benötigt. Das Vorbild dafür lieferten Programmiersprachen, die es erlauben "primitives" zu definieren, Grundoperationen, die man in einem header file zusammenstellen kann, um Befehle zu definieren, die das Programm dann benutzt.

1980 wurde ein erster Entwurf von SGML veröffentlicht. Im Oktober 1985 wurde ein Draft International Standard veröffentlicht und vom Office of Official Publications of the European Community angenommen. 1986 wurde der endgültige Text, der am CERN ausgearbeitet wurde, von ISO als Standard akzeptiert und in Rekordzeit veröffentlicht.

Als im WWW (World Wide Web) immer mehr proprietäre HTML-Erweiterungen auftauchten (vor allem von Netscape und Microsoft), reagierte das World Wide Web Consortium unter Leitung von Tim Berners-Lee, dem Erfinder von HTML, ab ca. 1996:

man entwickelte eine HTML-spezifische Stylesheet-Language: Cascading Style Sheets (CSS), die es erlaubt, spezifische Formatierungen vorzunehmen, ohne HTML proprietär zu verändern
man beschloss, eine vereinfachte Form von SGML zu entwickeln, die die Vorteile von SGML beibehält, aber gleichzeitig einfach ist: XML = Extensible Markup Language
man beschloss, XML-entsprechende Standards für die Erstellung von Links zu erstellen: XLink. XLink ist stark beeinflusst von HyTime (s.unten) und TEI (s. unten).
man beschloss, XML-entsprechende Standards für Stylesheets zu entwickeln: Extensible Style Sheets (XSL). XSL ist eine Kombination von Prinzipien von CSS und ISO's DSSSL (s. unten)

XML 1.0 wurde offiziell am 10.2.1998 veröffentlicht.

12.5.3. Grundzüge von SGML

Jedes Dokument besteht aus:

dem eigentlichen Inhalt des Dokuments (content data, bestehend aus data characters). Data characters werden von der SGML-Software im CON-mode (für content) gelesen und an die Anwendungssoftware zur Weiterbearbeitung weitergegeben. Die Bestandteile eines Dokuments werden entities genannt. Entities können verschiedenen Dokumenten gemeinsam sein oder auch wieder selbstständige Dokumente sein
dem Markup -- den Charakteristika (z.B. visueller Art), die dem Nutzer mitteilen, z.B. welche Stellung im Ganzen (Titel, Paragraphen, Absätze usw.) oder welchen Stellenwert ein Teil des Dokuments hat (Hervorhebungen, Zitate, Fußnoten usw.), bestehend aus markup characters. Markup character werden als solche gekennzeichnet durch delimiter characters. Delimiter characters teilen der Software mit, dass die dadurch gekennzeichneten Zeichen im TAG-mode gelesen werden müssen.
Die üblichen delimiter characters sind:
- < > für start tags: zeigen Beginn eines Elementes an
- </ > für end tags: zeigen Ende eines Elementes an
- & ; zum Absetzen von Entities wie Graphiken, Sonderzeichen u.ä.

SGML ist eine Sprache zum Definieren des Markup

für ein einzelnes Dokument
für eine Gruppe von Dokumenten
für alle Dokumente, die eine bestimmte Gruppe benutzt

SGML ist eine Computer-Sprache: ein Computerprogramm -- ein validating SGML parser -- liest die Definitionen, lernt die daraus folgenden Regeln und wendet sie auf das Dokument an.

12.5.4. Zusammenfassung: SGML-gestütztes Publizieren

Die folgende Abbildung fasst an einem Beispiel zeitgemäßes SGML- (bzw. XML-)gestütztes Publizieren zusammen:

Abb.: SGML-gestütztes Publizieren

Im hier schematisch wiedergegebenen Beispiel wird die Ausformung eines Werkes (SGML) in verschiedenen Manifestationen publiziert:

als Druckanweisung (Postscript)
als HTML-File
als Audio-File (.au)

Diese Manifestationen werden als Einzelexemplare realisiert:

als gedruckte Bücher
als Bildschirmdarstellungen bzw. Ausdrucke von WWW-Pages
als Lautwiedergabe von Audio-Files (z.B. von Kassette, CD-ROM, im Radio, im WWW usw.)

12.5.5. SGML profiles: XML

Ein SGML profile ist eine Anzahl von Regeln, die auf verschiedene SGML Document types anwendbar sind. Ein profile kann

die Optionen, die SGML offenlässt, einschränken
kann Festlegungen treffen, die außerhalb des Bereichs von SGML liegen (z.B. Zeichenkodierung)
kann auch die Behandlung von Dokumenten festlegen, die nicht voll SGML-konform sind.

Das erste öffentlich definierte profile von SGML ist XML. XML ist für das WWW optimiert.

XML-Dokumente können sein

valid: voll SGML-konform
well-formed: nicht voll SGML-konform (meist haben sie keine oder keine vollständige DTD, enthalten aber Elemente, die SGML-konform sind)

12.6. XML -- Extensible Markup Language

XML ist ein stark vereinfachtes SGML (SGML minus minus (--)), das SGML für das WWW ebenso leicht anwendbar machen soll, wie HTML eine bestimmte DTD von SGML populär gemacht hat.

**Unterschied zwischen SGML, XML, HTML**
SGML -- Standard Generalized Markup Language	Allgemeine Markup-Language für alle Arten von Anwendungen: von der Transkription sumerischer Tontäfelchen bis zur technischen Dokumentation von Weltraumfahrzeugen, von Patientendaten bis zu musikalischen Notationen
XML -- Extensible Markup Language	Vereinfachte Fassung von SGML. XML ist SGML--, nicht HTML++
HTML -- HyperText Markup Language	Ein document type, der mittels von SGML definiert ist

XML ist ein Projekt des WWW-Konsortium (W3C).

XML befreit das WWW von:

der Starrheit des durch HTML vorgegebenen Dokumenttyps
der Schwierigkeiten des vollen SGML, das nur wenigen Profis wirklich zugänglich ist

Für die Nutzung von XML-Dokumenten sind spezielle Browser nötig. Solche sind teilweise schon erhältlich, wirklich gute werden aber wohl noch einige Zeit auf sich warten lassen.

12.6.1. Aufbau eines XML-Dokumentes

Document Prolog
- XML declaration: teilt mit:
  - XML-Version: verwendete Version von XML
  - Zeichenkodierung:
  - Standalone document declaration
- Document Type Declaration (DTD): definiert das verwendete Markup. Oft besteht die DTD aus einer einzigen Zeile, die aussagt, dass die verwendete DTD eine veröffentlichte Implementierung ist bzw. dem empfangenden System bekannt ist
Document instance: das eigentliche Dokument mit dem Markup

12.6.2. XML-Declaration

Die XML declaration wird oft weggelassen, wenn man annehmen kann, dass sowohl das sendende als auch das empfangende System die default syntax (reference concrete syntax) benutzen.

Konvention im Folgenden: { }: der Wert für die zwischen den geschwungenen Klammern stehende Variable ist einzusetzen (die geschwungenen Klammern sind dann wegzulassen!).

Achtung: XML ist case sensitive, d.h. Groß- und Kleinschreibung für XML-Sprachbestandteile dürfen nicht verändert werden und die gewählte Schreibung variabler Elemente muss beibehalten werden! (Also: !ELEMENT muss mit Großbuchstaben geschrieben werden!)

Option	Syntax	Beispiel
Nur XML-Version	<?xml version="{Versionsnummer}"?>	<?xml version="1.0"?>
XML-Version + Zeichenkodierung (Standard:: UTF-8)	<?xml version="{Versionsnummer}" encoding="{Kodierung}"?>	<?xml version="1.0" encoding="UTF-8"?>
XML-Version + Standalone document declaration	<?xml version="{Versionsnummer}" standalone="{yes/no}"?>	<?xml version="1.0" standalone="no"?>

Erklärung:

XML-Version: verwendete Version von XML
Zeichenkodierung: normalerweise UTF-8 (siehe: Kapitel 12,1#12.4.3.)
Standalone document declaration: gibt an, ob externe DTD nicht beachtet werden soll (yes = braucht nicht beachtet zu werden). Sollte immer auf "no" gesetzt werden ("yes" erfordert sehr gute Kenntnisse des Funktionierens der Programme!)

Innerhalb des Dokuments können Sonderzeichen dann auf zwei Arten bezeichnet werden

Methode	Syntax	Beispiele
character reference	&#{binärer Wert}; &#x{hexadezimaler Wert};	¡ [= ¡ ] ¡ [= ¡ ]
Definition von Sonderzeichen (sog. predefined entity references) (soweit vorhanden)	&{Sonderzeichendefinition};	ä (a-Umlaut) [= ä] Ä [= Ä] ö [= ö] Ö [= Ö] ü [= ü] Ü [= Ü] ß (sz-Ligatur) [= ß] < (less than) [= <] > (greater than) [= >]

12.6.3. DTD -- Document Type Definition (Dokumenttypdefinition)

Die document type definition (DTD) definiert die Elemente und anderen Konstrukte, die für ein spezifisches Dokument oder eine Gruppe von Dokumenten benötigt werden.

Die DTD und jeder ihrer Teile hat die allgemeine Syntax:

<! {Inhalt} >

Eine DTD kann sein:

extern: als eigenes Dokument
intern: Bestandteil des Dokuments (Achtung: XML lässt in internen DTD einiges nicht zu, was in externen DTDs von XML unterstützt wird!)
gemischt aus extern und intern: in diesem Fall hat jede Definition und Anweisung in der internen DTD Vorrang vor der externen DTD, d.h. die interne DTD kann Bestimmungen der externen DTD aufheben

Es gibt folgende Optionen:

Option	Syntax	Beispiel
Hinweis auf eine dokumentexterne DTD	<!DOCTYPE {Name der DTD} SYSTEM "{URL der DTD}">	<!DOCTYPE Dissertation SYSTEM "http://www.payer.de/dissertation.dtd">
Hinweis auf eine dokumentexterne öffentliche DTD	<!DOCTYPE {Name der DTD} PUBLIC "{Öffentliche Bezeichnung der DTD}" "{URL der DTD}">	<!DOCTYPE Dissertation PUBLIC "-//AKADEMISCH//DTD DISS//EN" "http://www.ddb.de/dtd/diss.dtd">
DTD (dokumentenintern)	<!DOCTYPE {Name der DTD} [ <!{DTD}> (Syntax s. unten!) ]>	<!DOCTYPE Dissertation [ <!ELEMENT Dissertation (Titelblatt, Kapitel+, Zusammenfassung, Literaturverz, Lebenslauf)> <!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)> <!ELEMENT (Titel \| Autor \| Lebensdaten \| WissInst \| Jahr \| ...) (#PCDATA)> <!ELEMENT Kapitel (....)> ... ]>
gemischt: Hinweis auf dokumentenexterne DTD mit Sonderregelungen für das vorliegende Dokument	<!DOCTYPE {Name der DTD} SYSTEM "{URL der DTD}" [ <!{Sonderregelungen}> ]>	<!DOCTYPE Dissertation PUBLIC "-//AKADEMISCH//DTD DISS//EN" "http://www.ddb.de/dtd/diss.dtd" [ <!ELEMENT Lebensdaten EMPTY> ]>

Eine DTD hat folgende Struktur:

Syntax Beispiel

<!DOCTYPE {Name der DTD}
[
<!ELEMENT {Elementname des obersten Elements}{Elementinhalt}>
<!ELEMENT {Elementname}{Elementinhalt}>
...
]> <!DOCTYPE Dissertation
[
<!ELEMENT Dissertation (Titelblatt, Kapitel+, Zusammenfassung, Literaturverz, Lebenslauf)>
<!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)>
<!ELEMENT (Titel | Autor | Lebensdaten | WissInst | Jahr | ...) (#PCDATA)>
<!ELEMENT Kapitel (....)>
...
]>

Syntax	Beispiel
<!DOCTYPE {Name der DTD} [ <!ELEMENT {Elementname des obersten Elements}{Elementinhalt}> <!ELEMENT {Elementname}{Elementinhalt}> ... ]>	<!DOCTYPE Dissertation [ <!ELEMENT Dissertation (Titelblatt, Kapitel+, Zusammenfassung, Literaturverz, Lebenslauf)> <!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)> <!ELEMENT (Titel \| Autor \| Lebensdaten \| WissInst \| Jahr \| ...) (#PCDATA)> <!ELEMENT Kapitel (....)> ... ]>

Jede DTD hat genau ein oberstes Element, dessen Elementinhalt bestimmt, was alles Inhalt des Dokuments sein kann: z.B. andere Elemente. Für die Elemente kann man Meta-data in der Form von Attributen festlegen.

Die Elemente werden in element declarations definiert. Element declarations haben zwei Aufgaben:

Element_name: Zuweisung eines Namens zu einem Element. Dieser Name wird dann innerhalb von den delimiter characters "< >" (Anfangs-Tag) bzw. "</ >" (End-Tag) zur Kennzeichnung des Elementes verwendet. z.B. <Kapitel> ... </Kapitel>
Content_specification: Definition, was ein Element enthalten darf

Syntax	Beispiel
<!ELEMENT Element_name Content_specification>	<!ELEMENT Kapitel (KapTitel, (Para \| Zwischentit)+) > Erklärung: <!ELEMENT = es folgt eine element declaration Kapitel = Name des Elementes ( ) = Unterelemente , = darauf folgend \| = oder + = eines oder mehrere = Definition des Elementes Kapitel: beginnt mit Kapitelüberschrift enthält beliebig viele Paragraphen eventuell auch Zwischentitel Die Anweisung für XML-Software lautet also: "Kapitel ist der Name eines Elementes, welches aus einem KapTitel sowie ein oder mehreren Para oder Zwischentit besteht."

Syntax

Beispiel

<!ELEMENT Element_name Content_specification>

<!ELEMENT Kapitel (KapTitel, (Para | Zwischentit)+) >

Erklärung:

<!ELEMENT = es folgt eine element declaration
Kapitel = Name des Elementes
( ) = Unterelemente
, = darauf folgend
| = oder
+ = eines oder mehrere

= Definition des Elementes Kapitel:

beginnt mit Kapitelüberschrift
enthält beliebig viele Paragraphen
eventuell auch Zwischentitel

Die Anweisung für XML-Software lautet also: "Kapitel ist der Name eines Elementes, welches aus einem KapTitel sowie ein oder mehreren Para oder Zwischentit besteht."

Jedes Subelement muss ebenso definiert werden. In unserem Beispiel müssen die Inhalte (contents) der Unterelemente (subelements) KapTitel, Para, Zwischentit definiert werden. Wenn alle die gleiche Content_specification haben, kann man dies in einer einzigen element definition tun:

<!ELEMENT (KapTitel | Para | Zwischentit) (#PCDATA)>

PCDATA ist ein reservierter Name, der definiert, dass die betreffenden Elemente keine eigenen Unterelemente haben, sondern nur Zeichen enthalten, die zum Inhalt des Dokumentes gehören. PCDATA = parsed character data.

Mit diesen element definitions und den zuvor gegebenen predefined entity references könnte man z.B. folgendes Dokument erstellen:

<KapTit>Katzenweisheit</KapTit>

<Para>Katzen sind äußerst kluge Tiere. Sie tun nichts, wovon sie keinen Nutzen für sich einsehen .... </Para>

<Zwischentit>Tüpfli zum Beispiel</Zwischentit>

<Para>Tüpfli ist ein Kater. Sein Vater oder Großvater war vermutlich ein sexuell frustrierter Wildkater, der seine sexuellen Bedürfnisse bei einer Hauskatze befriedigte ... </Para>

</Kapitel>

Man kann Elementen Attribute zuordnen. So könnte man z.B. dem Element Para zwei Stufen der Zugänglichkeit zuordnen: topsecret und public:

<!ATTLIST para secrecy (topsec | public) "public">

"public" definiert public als default value: Alle Paragraphen, die nicht ausdrücklich als topsecret gekennzeichnet werden, sind public.

Unser Beispiel könnte dann z.B. so aussehen:

<KapTit>Katzenweisheit</KapTit>

<Para>Katzen sind äußerst kluge Tiere. Sie tun nichts, wovon sie keinen Nutzen für sich einsehen .... </Para>

<Zwischentit>Tüpfli zum Beispiel</Zwischentit>

<Para secrecy=topsec>Tüpfli ist ein Kater. Sein Vater oder Großvater war vermutlich ein sexuell frustrierter Wildkater, der seine sexuellen Bedürfnisse bei einer Hauskatze befriedigte ... </Para>

</Kapitel>

In diesem Falle würde die Abstammung Tüpflis nur berechtigten Geheimnisträgern zugänglich gemacht.

Im Folgenden wird das mit diesem Beispiel Illustrierte systematisch dargestellt.

12.6.3.1. Allgemeine Syntax einer formal markup declaration

Syntax	Beispiel
<!{keyword} {parameter} {associated_parameters}>	<!ELEMENT Kapitel (KapTitel, (Para \| Zwischentit)+) >

Erklärung:

keyword: Die wichtigsten Keywords sind:

keyword Funktion Beispiel

DOCTYPE ordnet einer Gruppe von Declarations einen Namen zu, z.B. Namen des ganzen Dokuments <!DOCTYPE DISSERTATION
[
<!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)>
<!ELEMENT (Titel | Autor| Lebensdaten | WissInst | Jahr| ...) (#PCDATA)>
<!ELEMENT Kapitel (....)>
...
]>

ELEMENT definiert ein Element innerhalb der logischen Struktur eines Dokumentes. associated_parameters gibt hier die möglichen Inhalte dieses Elementes an (content model) <!ELEMENT Kapitel (KapTitel, (Para | Zwischentit)+) >
<!ELEMENT (KapTitel | Para | Zwischentit) (#PCDATA)>

ATTLIST Zuordnung von Attributen zu einem Element <!ATTLIST para secrecy (topsec | public) "public">

ENTITY ermöglicht, eine Kurzform für etwas Längeres einzugeben, oder auf ein externes File zu verweisen <!ENTITY Tü "Tübingen, Univ., Diss.,">

NOTATION verbindet den ersten Parameter, der Non-XML-data bezeichnet mit dem zweiten Parameter, der dem System angibt, wie so Bezeichnetes zu behandeln ist: z.B: MIDI für MIDI-Files, CGM für Graphik u.ä.
<!NOTATION MathText SYSTEM "/usr/bin/tex" >

( = mathematischer Text ist zu bearbeiten mit einem Sub-Programm, das als usr/bin/tex gespeichert ist)

keyword	Funktion	Beispiel
DOCTYPE	ordnet einer Gruppe von Declarations einen Namen zu, z.B. Namen des ganzen Dokuments	<!DOCTYPE DISSERTATION [ <!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)> <!ELEMENT (Titel \| Autor\| Lebensdaten \| WissInst \| Jahr\| ...) (#PCDATA)> <!ELEMENT Kapitel (....)> ... ]>
ELEMENT	definiert ein Element innerhalb der logischen Struktur eines Dokumentes. associated_parameters gibt hier die möglichen Inhalte dieses Elementes an (content model)	<!ELEMENT Kapitel (KapTitel, (Para \| Zwischentit)+) > <!ELEMENT (KapTitel \| Para \| Zwischentit) (#PCDATA)>
ATTLIST	Zuordnung von Attributen zu einem Element	<!ATTLIST para secrecy (topsec \| public) "public">
ENTITY	ermöglicht, eine Kurzform für etwas Längeres einzugeben, oder auf ein externes File zu verweisen	<!ENTITY Tü "Tübingen, Univ., Diss.,">
NOTATION	verbindet den ersten Parameter, der Non-XML-data bezeichnet mit dem zweiten Parameter, der dem System angibt, wie so Bezeichnetes zu behandeln ist: z.B: MIDI für MIDI-Files, CGM für Graphik u.ä.	<!NOTATION MathText SYSTEM "/usr/bin/tex" > ( = mathematischer Text ist zu bearbeiten mit einem Sub-Programm, das als usr/bin/tex gespeichert ist)


parameter:

Parameter ist immer der Name, der für das betreffende Markup verwendet werden soll

<!DOCTYPE DISSERTATION ... >
<!ELEMENT Kapitel ...>
<!ATTLIST para secrecy ...>

associated parameters:

Innerhalb von associated_parameter (und teilweise innerhalb der parameter) können folgende Indikatoren und Verknüpfungszeichen vorkommen:

Indikator / Verknüpfungszeichen Bedeutung Erklärung Beispiel

kein Indikator
das betreffende Element usw. muss genau einmal vorkommen <!ELEMENT BibliogrBeschreibung (Titelangabe, Verfasserangabe, Ausgabebezeichnung?, Erscheinungsvermerk, Kollationsvermerk, Gesamttitel?, URN?)>

( )
Gruppe zwischen der Parenthese steht eine Abfolge, eine Gruppe oder eine Reihe von Alternativen <!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)>
<!ELEMENT (Titel | Autor | Lebensdaten | WissInst | Jahr | ...) (#PCDATA)>
<!ATTLIST para secrecy (topsec | public) "public">

?

optional das betreffende Element usw. kann

nicht oder

einmal

vorkommen
<!ELEMENT BibliogrBeschreibung (Titelangabe, Verfasserangabe, Ausgabebezeichnung?, Erscheinungsvermerk, Kollationsvermerk, Gesamttitel?, URN?)>

*

optional und wiederholbar das betreffende Element usw. kann

nicht

einmal oder

mehrmals

vorkommen
<!ELEMENT authgrp (author|corpauth|aff)* >

+

notwendig und wiederholbar das betreffende Element usw. muss

mindestens einmal

vorkommen
<!ELEMENT Kapitel (KapTitel, (Para | Zwischentit)+) >

,

aufeinanderfolgend

a,b = auf a muss b folgen

a,b? = auf a kann b folgen

|

oder (OR) mindestens eines der so verknüpften Elemente usw. muss vorkommen

Indikator / Verknüpfungszeichen	Bedeutung	Erklärung	Beispiel
kein Indikator		das betreffende Element usw. muss genau einmal vorkommen	<!ELEMENT BibliogrBeschreibung (Titelangabe, Verfasserangabe, Ausgabebezeichnung?, Erscheinungsvermerk, Kollationsvermerk, Gesamttitel?, URN?)>
( )	Gruppe	zwischen der Parenthese steht eine Abfolge, eine Gruppe oder eine Reihe von Alternativen	<!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)> <!ELEMENT (Titel \| Autor \| Lebensdaten \| WissInst \| Jahr \| ...) (#PCDATA)> <!ATTLIST para secrecy (topsec \| public) "public">
?	optional	das betreffende Element usw. kann nicht oder einmal vorkommen	<!ELEMENT BibliogrBeschreibung (Titelangabe, Verfasserangabe, Ausgabebezeichnung?, Erscheinungsvermerk, Kollationsvermerk, Gesamttitel?, URN?)>
*	optional und wiederholbar	das betreffende Element usw. kann nicht einmal oder mehrmals vorkommen	<!ELEMENT authgrp (author\|corpauth\|aff)* >
+	notwendig und wiederholbar	das betreffende Element usw. muss mindestens einmal vorkommen	<!ELEMENT Kapitel (KapTitel, (Para \| Zwischentit)+) >
,	aufeinanderfolgend	a,b = auf a muss b folgen a,b? = auf a kann b folgen
\|	oder (OR)	mindestens eines der so verknüpften Elemente usw. muss vorkommen

Comment declarations für Anmerkungen und Erklärungen des Produzenten des XML-Dokumentes, die vom System nicht beachtet werden sollen, haben folgende Syntax:

Syntax Beispiel

Syntax	Beispiel
<!-- {Text der Anmerkung} -->	<!-- Dies ist eine DTD für deutschsprachige Dissertationen -->

12.6.3.2. ELEMENT declarations

Syntax:

Syntax	Beispiel
<!ELEMENT Element_name Content_specification>	<!ELEMENT Kapitel (KapTitel, (Para \| Zwischentit)+) > <!ELEMENT (KapTitel \| Para \| Zwischentit) (#PCDATA)>

Erklärung:

Element_name: Name des Elements, bestehend aus höchstens acht alphanumerischen Zeichen (das erste Zeichen muss ein Buchstabe sein)
Content_specification: zulässiger Inhalt des Elements:
- ein Content model: definiert, was in welcher Anzahl und in welcher Reihenfolge Inhalt des Elements sein darf
  - element content
  - mixed content
- das Keyword ANY
- das Keyword EMPTY

Content_specification	Erklärung	Beispiel
element content	eine Liste anderer Elemente (content particles), als Auswahl (choice) oder als Reihenfolge (sequence)	<!ELEMENT Kapitel (KapTitel, (Para \| Zwischentit)+) >
mixed content:	#PCDATA = Parsed character data = zulässige Zeichen + XML-Tags, eventuell zusammen mit einer Liste anderer Elemente	<!ELEMENT Zwischentit (#PCDATA)> <!ELEMENT Para (#PCDATA \| Unterpara \| Abb)>
EMPTY	leeres Element: darf keinen Inhalt enthalten, kann aber Attribute haben (z.B. <BR/> oder <BR></BR> = Zeilenumbruch )	<!ELEMENT BR EMPTY>
ANY	jegliche #PCDATA bzw. jedes definierte Element ist in jeder Reihenfolge und Häufigkeit zulässig	<!ELEMENT Diss ANY>

12.6.3.3. ATTLIST declarations

Neben Inhalt können Elemente auch Attribute und Werte haben. Attribute sind Meta-data für Elemente. In der DTD werden die Attribute und ihre zulässigen Werte in einer attribute list declaration definiert:

Syntax der attribute list declaration	Beispiel
<!ATTLIST element_name attribute_definition attribute_definition ..... >	<!ATTLIST Beispiel id ID #IMPLIED n CDATA #REQUIRED status (Entwurf \| endgültig) "endgültig">

Erklärung der attribute list declaration:

Erklärung: element_name Beispiel

Name des Elements oder der Elemente, die mit dieser attribute list verknüpft werden sollen para

Erklärung: element_name	Beispiel
Name des Elements oder der Elemente, die mit dieser attribute list verknüpft werden sollen	para

Die attribute_definition hat folgende Syntax:

Syntax der attribute_definition Beispiel

attribute_name attribute_type default_value <!ATTLIST para
secrecy (topsec | public) "public">

Syntax der attribute_definition	Beispiel
attribute_name attribute_type default_value	<!ATTLIST para secrecy (topsec \| public) "public">

Erklärung der attribute definition:

Erklärung: attribute_name Beispiel

Name für die Attribute, die mit dem Element verknüpft werden secrecy

Erklärung: attribute_name	Beispiel
Name für die Attribute, die mit dem Element verknüpft werden	secrecy

attribute_type:

Arten von attribute_types Unterarten Beispiele

String Type CDATA null oder mehr Zeichen, wobei auch die reservierten Zeichen (mit Ausnahme von <) als normale Zeichen gelten <!ATTLIST Dissertation Rückentitel CDATA #REQUIRED>
<Dissertation Rückentitel = "Billy K. Koala"> ... </Dissertation>

Tokenized Types ENTITY eine externe binäre entity, die in der DTD definiert ist <!ENTITY Abbildung1 SYSTEM "tuepfli.gif" NDATA gif>
<!ELEMENT Abbildung EMPTY>
<!ATTLIST Abbildung File ENTITY #REQUIRED>
<Abbildung File = "Abbildung1"> </Abbildung>

(ENTITY als Platzhalter für Abbildung)

ENTITIES dasselbe wie ENTITY, aber mehrere Werte, durch Spatien getrennt

ID ein einmaliger Identifikator für das Element, auf den mit IDREF verweiesenwerden kann (wird immer als ID angegeben) <!ATTLIST Kapitelüberschrift ID ID #REQUIRED>
<Kapitelüberschrift ID = "Kap 3"> ... </Kapitelüberschrift>

IDREF Referenz zu einer ID, die wo anders im Dokument definiert ist <!ATTLIST Verweisung Vw IDREF #REQUIRED>
<Verweisung Vw = "Kap. 3"> ... </Verweisung>

IDREFS Liste von IDREFs, getrennt durch Spatien

NMTOKEN eine Verbindung alphanumerischer Zeichen <!ATTLIST Formular Druckformat NMTOKEN #IMPLIED>
<Formular Druckformat = "A4"> </Formular>

NMTOKENS Liste von NMTOKEN-Werten, getrennt durch Spatien <!ATTLIST Abbildung Abbildungsrand NMTOKENS #IMPLIED>
<Abbildung Abbildungsrand = "5 12 35 55"></Abbildung>

Enumerated Types: der Nutzer der DTD muss oder kann aus einer Aufzählung von Möglichkeiten wählen Name token group <!ATTLIST Norm
status (Entwurf | zurKorrektur | endgültig) #REQUIRED>
<Norm status = "Entwurf"> ... </Norm>

NOTATION attribute type <!ATTLIST mathFormel
format NOTATION (tex | troff) #REQUIRED>
<mathFormel format = "tex"> ... </mathFormel>

Arten von attribute_types	Unterarten	Beispiele
String Type	CDATA null oder mehr Zeichen, wobei auch die reservierten Zeichen (mit Ausnahme von <) als normale Zeichen gelten	<!ATTLIST Dissertation Rückentitel CDATA #REQUIRED> <Dissertation Rückentitel = "Billy K. Koala"> ... </Dissertation>
Tokenized Types	ENTITY eine externe binäre entity, die in der DTD definiert ist	<!ENTITY Abbildung1 SYSTEM "tuepfli.gif" NDATA gif> <!ELEMENT Abbildung EMPTY> <!ATTLIST Abbildung File ENTITY #REQUIRED> <Abbildung File = "Abbildung1"> </Abbildung> (ENTITY als Platzhalter für Abbildung)
ENTITIES dasselbe wie ENTITY, aber mehrere Werte, durch Spatien getrennt
ID ein einmaliger Identifikator für das Element, auf den mit IDREF verweiesenwerden kann (wird immer als ID angegeben)	<!ATTLIST Kapitelüberschrift ID ID #REQUIRED> <Kapitelüberschrift ID = "Kap 3"> ... </Kapitelüberschrift>
IDREF Referenz zu einer ID, die wo anders im Dokument definiert ist	<!ATTLIST Verweisung Vw IDREF #REQUIRED> <Verweisung Vw = "Kap. 3"> ... </Verweisung>
IDREFS Liste von IDREFs, getrennt durch Spatien
NMTOKEN eine Verbindung alphanumerischer Zeichen	<!ATTLIST Formular Druckformat NMTOKEN #IMPLIED> <Formular Druckformat = "A4"> </Formular>
NMTOKENS Liste von NMTOKEN-Werten, getrennt durch Spatien	<!ATTLIST Abbildung Abbildungsrand NMTOKENS #IMPLIED> <Abbildung Abbildungsrand = "5 12 35 55"></Abbildung>
Enumerated Types: der Nutzer der DTD muss oder kann aus einer Aufzählung von Möglichkeiten wählen	Name token group	<!ATTLIST Norm status (Entwurf \| zurKorrektur \| endgültig) #REQUIRED> <Norm status = "Entwurf"> ... </Norm>
NOTATION attribute type	<!ATTLIST mathFormel format NOTATION (tex \| troff) #REQUIRED> <mathFormel format = "tex"> ... </mathFormel>

default_value:

Mögliche Werte des default_value eines Attribute	Erklärung	Beispiel
literal value	eine konkrete Zeichenfolge	<!ATTLIST para secrecy (topsec \| public) "public">
#FIXED {fixedvalue}	das Attribut muss den Wert {fixedvalue} haben; wenn das Attribut nicht angegeben wird, wird trotzdem der Wert {fixedvalue} angenommen; der Anwender kann den Wert nicht ändern	<!ATTLIST para secrecy (topsec \| public) #FIXED "public">
#REQUIRED:	Es gibt keinen default value: für jedes Element, das dieses Attribut enthält, muss der Nutzer einen Wert spezifizieren.; sonst gibt es eine Error-Meldung	<!ATTLIST Norm status (Entwurf \| zurKorrektur \| endgültig) #REQUIRED>
#IMPLIED:	das Attribut ist optional, wenn kein Wert angegeben ist, übergeht es die Software oder fügt einen softwarespezifischen default value ein. Ist in den meisten DTDs der häufigste default value	<!ATTLIST Paragraph Schrifttype CDATA #IMPLIED>

12.6.3.4. General_ENTITY declarations

Entities können sein:

general entities: für Anwendung im Dokument
parameter entities: für Anwendung innerhalb der Bestandteile der DTDs

Syntax der general_ENTITY
<!ENTITY EntityName EntityDefinition>

Entities in der DTD können sein:

Entity	Erklärung	Beispiel einer Entity declaration
parsed = text entities:	enthalten Text, der dort, wo die Entity im Dokument steht, ins Dokument eingefügt wird	<!ENTITY Tü "Tübingen, Univ., Diss.,">
unparsed = binary entities	Hinweis auf ein externes binäres File (d.h. Teile, die nicht als XML behandelt werden)	<!ENTITY Abbildung1 SYSTEM "tuepfli.gif" NDATA gif> (NDATA = es handelt sich um Daten, die nur innerhalb der betreffenden Anwendung interpretiert werden können)

Parsed (text) entities werden im Dokument so gekennzeichnet:

Syntax	Beispiel
&{EntityName};	&Tü;

Wirkung bei parsed (text) entities: der Parser ersetzt immer, wenn er auf &entity_name; stößt, dies durch das, was zwischen in der EntityDefinition steht.

Text mit Markup	Aufgelöst
&Tü; 1999	Tübingen, Univ., Diss., 1999

Parsed_Entity declarations können sein:

	Erklärung	Beispiel
internal_ENTITY declarations	die EntityDefinition enthält den ganzen Text der ENTITY	<!ENTITY Tü "Tübingen, Univ., Diss.,">
external_ENTITY declarations	die EntityDefinition verweist auf einen Ort, an dem sich der Inhalt der ENTITY befindet	<!ENTITY Kapitel1 SYSTEM "C:/payerde/cmc/cmcs01.xml"> (Damit kann man z.B. die einzelnen Kapitel eines Buches zusamenführen)

(Diese beiden Formen sind auch bei parameter_ENTITIES möglich).

Eine Entity kann folgende Funktionen haben:

Ersetzung eines Kurzstrings durch einen Langstring
Verknüpfung mit einem anderen XML-File
Platzhalter für Graphik oder andere Nicht-XML-Daten, die eingefügt werden, wenn das Dokument angesehen oder gedruckt wird
ein Sonderzeichen, wie Umlaute usw.

Entities ermöglichen globales Ersetzen und Updating. Entities unterstützen auch Standardisierung, da eine Entity nur an einer Stelle, der entity declaration, definiert und formuliert wird.

12.6.3.5. Parameter_ENTITY Declarations

Syntax der parameter_ENTITY	Beispiel
<!ENTITY % entity_name "replacement_entity_text">	<!ENTITY % Lebensdaten "(#PCDATA)"> <!ENTITY % Lebensdaten "EMPTY">

Bei Parameter Entities besteht der replacement_entity_text aus associated parameters.

Parameter Entities werden in den Bestandteilen der DTD durch %entity_name; gekennzeichnet

Parameter entities ermöglichen es, sehr einfach durchgehende Änderungen in der DTD durchzuführen.

Beispiel:

<!ENTITY % Lebensdaten "(#PCDATA)">
<!ELEMENT Lebensdaten %Lebensdaten;>
<!ELEMENT Alter %Lebensdaten;>
...

Ersetzt man nun

<!ENTITY % Lebensdaten "EMPTY">

dann werden in allen Elementen der DTD, die Lebensdaten enthalten, die Lebensdaten weggelassen.

12.6.3.6. NOTATION declarations

Notations werden benötigt, wenn bei der Verarbeitung von XML-Dokumenten einzelne Daten eine spezielle Behandlung erfordern. Typische Beispiele: mathematische Formeln, Graphiken, Sound, Video, SourceCode. Der Parser überweist dann die entsprechenden Teile an entsprechende Software

Syntax der NOTATION_declaration	Beispiel
<!NOTATION notation_name SYSTEM "external_identifier"> (wenn sich die betreffende Software auf dem System des Anwenders befindet)	<!NOTATION MathText SYSTEM "/usr/bin/tex" > ( = mathematischer Text ist zu bearbeiten mit einem Sub-Programm, das als usr/bin/tex gespeichert ist) <!NOTATION Gleichung SYSTEM "/usr/bin/eqn"> ( = mathematische Formeln sind zu bearbeiten mit einem Sub-Programm. das als /usr/bin/eqn gespeichert ist]
<!NOTATION notation_name PUBLIC "external_identifier"> (wenn sich die betreffende Software öffentlich zugänglich ist)	<!NOTATION TeX PUBLIC "+//ISBN 0-201-13448-9::Knuth// NOTATION The TeXbook//EN">

Syntax der NOTATION_declaration

Beispiel

<!NOTATION notation_name SYSTEM "external_identifier">

(wenn sich die betreffende Software auf dem System des Anwenders befindet)

<!NOTATION MathText SYSTEM "/usr/bin/tex" >

( = mathematischer Text ist zu bearbeiten mit einem Sub-Programm, das als usr/bin/tex gespeichert ist)

<!NOTATION Gleichung SYSTEM "/usr/bin/eqn">

( = mathematische Formeln sind zu bearbeiten mit einem Sub-Programm. das als /usr/bin/eqn gespeichert ist]

<!NOTATION notation_name PUBLIC "external_identifier">

(wenn sich die betreffende Software öffentlich zugänglich ist)

<!NOTATION TeX PUBLIC "+//ISBN 0-201-13448-9::Knuth// NOTATION The TeXbook//EN">

12.6.4. XLink (XLL)

XLink ist noch im Entwurfsstadium, deshalb können hier nur die Grundzüge wiedergegeben werden.

Der neuste Entwurf: http://www.w3.org/TR/WD-xlink. -- Zugriff am 21.6.1999

Zum Verständnis des Folgenden sind folgende Unterscheidungen und Definitionen nützlich:

Unterscheide:

Linking: Definition einer Verbindung zwischen zwei "Objekten". Diese "Objekte" werden resources genannt
Adressing: Definition, wie man die beiden "Objekte", die verbunden sind, finden kann

XLink (XLL) ist eine XML-konforme Unter-Sprache, mit der man Verknüpfungen (Links) in XML definieren kann. Im Unterschied zu den Links in HTML erlaubt XML zweierlei Links:

simple links: eine Verbindung zwischen zwei Objekten
extended links: eine Verbindung von bzw. zu beliebig vielen Objekten

Simple Links: haben die in folgender ATTLIST angegebenen Möglichkeiten:

DTD	Erklärung
<!ELEMENT SimpleLink ANY> <!ATTLIST SimpleLink XML:LINK CDATA #FIXED "simple" HREF CDATA #REQUIRED INLINE (true l false) "true" ROLE CDATA #IMPLIED TITLE CDATA #IMPLIED SHOW (replace l new l embed) #IMPLIED ACTUATE (auto l user) #IMPLIED BEHAVIOR CDATA #IMPLIED CONTENT-ROLE CDATA #IMPLIED CONTENTTITLE CDATA #IMPLIED >	XML:LINK: kann Wert simple für simple link oder extended für extended link haben HREF: resource locator von einer ganzen Ressource (mit der URL oder URN) oder einem Teil der Ressource (mit URL#Xpointer). XML erlaubt es, wenn man auf einen Teil einer Ressource zuzugreifen und nur diesen Teil zu übertragen) INLINE: ROLE: man kann der Anwendungssoftware mitteilen, was der Link bedeuted (z.B. Glossar, Hintergrund Information, Zitat ...), sodass die Anwendungs-Software die entsprechende Information direkt vom Link holt und entsprechend in die Darstellung einbaut (z.B. das in einer Fußnote Zitierte wird im Volltext in die Fußnote eingebaut) TITLE: gibt dem Nutzer Informationen über den Link SHOW: kann folgende Werte haben replace = ersetze die lokale Ressource durch die gelinkte Ressource (d.h. neuer Bildschirminhalt, wie bei HTML meistens) new = das Gelinkte soll in einem neuen Kontext (auf neuem Bildschirm) geöffnet werden embed = das Gelinkte wird in die lokale Ressource eingebettet ACTUATE: kann folgende Werte haben: auto = Link soll sofort ausgeführt werden, wenn die Anwendungssoftware auf ihn stoßt (z.B. automatisches Einbetten eines Zitates) user = Link soll nur auf entsprechende Betätigung durch Nutzer (z.B. Mouseklick) ausgeführt werden BEHAVIOR: gibt an, wie der Link selber sich verändern soll: z.B. Änderung der Farbe vor und nach dem Ausführen des Links; auch andere Möglichkeiten sind implementierbar CONTENT-ROLE: ähnlich wie ROLE (s.oben), aber für lokale Ressourcen CONTENT-TITLE: ähnlich wie TITLE (s. oben), aber für lokale Ressourcen

DTD

Erklärung

<!ELEMENT SimpleLink ANY>

<!ATTLIST SimpleLink

XML:LINK CDATA #FIXED "simple"

HREF CDATA #REQUIRED

INLINE (true l false) "true"

ROLE CDATA #IMPLIED

TITLE CDATA #IMPLIED

SHOW (replace l new l embed) #IMPLIED

ACTUATE (auto l user) #IMPLIED

BEHAVIOR CDATA #IMPLIED

CONTENT-ROLE CDATA #IMPLIED

CONTENTTITLE CDATA #IMPLIED

XML:LINK: kann Wert simple für simple link oder extended für extended link haben

HREF: resource locator von einer ganzen Ressource (mit der URL oder URN) oder einem Teil der Ressource (mit URL#Xpointer). XML erlaubt es, wenn man auf einen Teil einer Ressource zuzugreifen und nur diesen Teil zu übertragen)

INLINE:

ROLE: man kann der Anwendungssoftware mitteilen, was der Link bedeuted (z.B. Glossar, Hintergrund Information, Zitat ...), sodass die Anwendungs-Software die entsprechende Information direkt vom Link holt und entsprechend in die Darstellung einbaut (z.B. das in einer Fußnote Zitierte wird im Volltext in die Fußnote eingebaut)

TITLE: gibt dem Nutzer Informationen über den Link

SHOW: kann folgende Werte haben

replace = ersetze die lokale Ressource durch die gelinkte Ressource (d.h. neuer Bildschirminhalt, wie bei HTML meistens)
new = das Gelinkte soll in einem neuen Kontext (auf neuem Bildschirm) geöffnet werden
embed = das Gelinkte wird in die lokale Ressource eingebettet

ACTUATE: kann folgende Werte haben:

auto = Link soll sofort ausgeführt werden, wenn die Anwendungssoftware auf ihn stoßt (z.B. automatisches Einbetten eines Zitates)
user = Link soll nur auf entsprechende Betätigung durch Nutzer (z.B. Mouseklick) ausgeführt werden

BEHAVIOR: gibt an, wie der Link selber sich verändern soll: z.B. Änderung der Farbe vor und nach dem Ausführen des Links; auch andere Möglichkeiten sind implementierbar

CONTENT-ROLE: ähnlich wie ROLE (s.oben), aber für lokale Ressourcen

CONTENT-TITLE: ähnlich wie TITLE (s. oben), aber für lokale Ressourcen

Ein simple link schaut dann im Markup z.B. so aus:

<SimpleLink XML:LINK="simple" HREF="http.//www.payer.de">Tüpflis Global Village Library</SimpleLink>

Extended Links:

Extended Links sollen erlauben:

Links zu einer ganzen Gruppe von möglichen Ressourcen (z.B. Nachrichten)
Filterung relevanter Links

Extended Links können sein:

Inline Extended Links: der Link-Text ist Bestandteil des Links, d.h. die lokale Resource ist Teil des Links
Out-of-line Extended Links: Links zwischen Resources, wobei der Linkende Text außerhalb der gelinkten Resource liegt (Beispiel: ich rede über Luther und Buddha, verknüpfe also beide, ohne selbst Luther oder Buddha zu sein)

Inline Extended Link:

DTD	Erklärung
<!ELEMENT ExtendedLink ANY> <!ATTLIST ExtendedLink XML:LINK CDATA #FIXED "extended" INLINE (true l false) "true" ROLE CDATA #IMPLIED TITLE CDATA #IMPLIED SHOW (replace l new l embed) #IMPLIED ACTUATE (auto l user) #IMPLIED BEHAVIOR CDATA #IMPLIED CONTENT-ROLE CDATA #IMPLIED CONTENTTITLE CDATA #IMPLIED >	Die ATTLIST für diesen INLINE extended link ist wie die für den simple link (s.oben) mit zwei Unterschieden: XML:LINK hat den Wert extended es gibt kein Attribut HREF Bei Extended Links müssen nämlich die sogenannten locators als eigene ELEMENTs definiert werden. Dies erlaubt, für ein linking element viele locators zu spezifizieren.
<!ELEMENT ExtendedLocator ANY> <!ATTLIST ExtendedLocator XML:LINK CDATA #FIXED "locator" HREF CDATA #REQUIRED ROLE CDATA #IMPLIED TITLE CDATA #IMPLIED SHOW (replace l new l embed) #IMPLIED ACTUATE (auto l user) #IMPLIED < BEHAVIOR CDATA #IMPLIED >

DTD

Erklärung

<!ELEMENT ExtendedLink ANY>

<!ATTLIST ExtendedLink

XML:LINK CDATA #FIXED "extended"

INLINE (true l false) "true"

ROLE CDATA #IMPLIED

TITLE CDATA #IMPLIED

SHOW (replace l new l embed) #IMPLIED

ACTUATE (auto l user) #IMPLIED

BEHAVIOR CDATA #IMPLIED

CONTENT-ROLE CDATA #IMPLIED

CONTENTTITLE CDATA #IMPLIED

Die ATTLIST für diesen INLINE extended link ist wie die für den simple link (s.oben) mit zwei Unterschieden:

XML:LINK hat den Wert extended
es gibt kein Attribut HREF

Bei Extended Links müssen nämlich die sogenannten locators als eigene ELEMENTs definiert werden. Dies erlaubt, für ein linking element viele locators zu spezifizieren.

<!ELEMENT ExtendedLocator ANY>

<!ATTLIST ExtendedLocator

XML:LINK CDATA #FIXED "locator"

HREF CDATA #REQUIRED

ROLE CDATA #IMPLIED

TITLE CDATA #IMPLIED

SHOW (replace l new l embed) #IMPLIED

ACTUATE (auto l user) #IMPLIED

<
BEHAVIOR CDATA #IMPLIED

Obige DTD kann im Markup z.B. so verwendet werden:

<ExtendedLink XML:LINK="extended"> CMC-Skript

<Extended Locator TITLE "Kap. 1" HREF 0 "cmcs01.htm">
<Extended Locator TITLE "Kap. 2" HREF 0 "cmcs02.htm">
<Extended Locator TITLE "Kap. 3" HREF 0 "cmcs03.htm">

....

</ExtendedLink>

Dieser Link besagt nicht, was die Anwendungssoftware damit tun soll, sondern gibt der Anwendungssoftware alle Information, die sie für Linking braucht. Es ist z.B. denkbar, dass die Anwendungssoftware in diesem Fall alle Kapitel zu einem Buch zusammenfügt, oder dass sie in einem Pop-Up-Fenster die Kapitel zu Wahl stellt.

Out-of-Line Extended Link:

Das eben genannte Markup-Beispiel würde mit einem Out-of-Line Extended Link so ausschauen:

<Extended Locator TITLE "Kap. 1" HREF 0 "cmcs01.htm">
<Extended Locator TITLE "Kap. 2" HREF 0 "cmcs02.htm">
<Extended Locator TITLE "Kap. 3" HREF 0 "cmcs03.htm">

....

</ExtendedLink>

Ein solcher Link ist nicht an eine bestimmte Stelle des Dokuments gebunden (Inline). So könnte z.B. die Software die Links checken bevor sie sie überhaupt anzeigt u.ä.

Weiterführende Ressourcen zu XLL:

Die obige Darstellung folgt weitgehend:

Pardi, William J.: XML in action. -- Redmont, WA : Microsoft Press, ©1999. --- 329 S. : Ill. + 1 CD-ROM. -- ISBN 0735605629. -- S. 143 - 157. -- {Wenn Sie HIER klicken, können Sie dieses Buch bei amazon.de bestellen}

12.6.5. XPointer

XPointer ist noch im Entwurfsstadium, deshalb können hier nur die Grundzüge wiedergegeben werden.

Der neuste Entwurf: http://www.w3.org/TR/WD-xptr. -- Zugriff am 21.6.1999

XPointer dient der Verknüpfung zur inneren Struktur eines XML-Dokuments. Es soll z.B. ermöglicht werden, nur einzelne Teile eines Dokuments zu linken und zu übertragen.

12.6.6. XSL -- Extensible Stylesheet Language

XSL ist noch im Entwurfsstadium, deshalb können hier nur die Grundzüge wiedergegeben werden.

Der neuste Entwurf: http://www.w3.org/TR/WD-xsl/. -- Zugriff am 21.6.1999

XSL nutzt templates, die patterns enthalten. Einzelheiten mit einem durchgeführten Beispiel sind gut erklärt in:

Pardi, William J.: XML in action. -- Redmont, WA : Microsoft Press, ©1999. --- 329 S. : Ill. + 1 CD-ROM. -- ISBN 0735605629. -- S. 162 - 192. -- {Wenn Sie HIER klicken, können Sie dieses Buch bei amazon.de bestellen}

Interessierten ist die Darstellung dort sehr empfohlen.

12.6.7. Umsetzung eine XML-Ausformung/Manifestation in ein Einzelexemplar

Um XML in ein Einzelexemplar voll oder zumindest teilweise umzusetzen, bedarf es entsprechender Browser. Man kann mittels Scripting-Languages (z.B: JScript) selbst solche Umsetzungen programmieren. Für Näheres dazu wird auf die weiterführenden Ressourcen verwiesen.

Als Beispiel eines XML-fähigen Browsers sei Amaya (für MathML) genannt. Siehe unten 12.7.5.

12.7. Anwendungen von SGML und XML

12.7.1. Wichtige öffentlich zugängliche Document Type Definitions (DTD) in SGML

HTML -- HyperText Markup Language	für WWW; enthält sowohl Elemente der Ausformung als auch Elemente der Manifestation (Layout-Tags, Style sheets) s. Kapitel 13,2,2
ISO 12083	international standardisiert für Verlagswesen (entwickelt von Association of American Publishers): Autoren verwenden diese DTD, die Verlage wandeln sie dann in den verlagsspezifischen Stil um
DocBook	Industriestandard für technische Dokumentationen
TEI DTD -- Text Encoding Initiative DTD	Vor allem für sprach- und literaturwissenschaftliches elektronisches Publizieren
MIL-STD-38784	US-Militär-DTD für technische Handbücher (innerhalb des CALS Project
DSSSL	international standardisierter Document Type für Dokumente, die Styles oder andere Spezifikationen für Dokumente definieren (SGML Quelldokumente) Yahoo Category: http://dir.yahoo.com/Computers_and_Internet/Information_and_Documentation/Data_Formats/DSSSL/. -- Zugriff am 18.6.1999

12.7.1.1. ISO 12083

Hintergrund und Geschichte:

Ursprünglich von der Association of American Publishers (AAP) entwickelt wurde der Vorläufer dieser DTD 1988 zum ANSI-Standard. Mit einigen Änderungen wurde sie 1993 zum internationalen ISO-Standard. Im Auftrag der ISO [ http://www.iso.ch/. -- Zugriff am 19.6.1999] ist EPSIG (Electronic Publishing Special Interest Group) [http://www.oasis-open.org/cover/epsig.html. -- Zugriff am 21.6.1999] für den Unterhalt der Norm verantwortlich. Als ISO-Standard darf die Norm (mit Ausnahme von Fehlerkorrekturen) frühestens alle fünf Jahre geändert werden. Dies gibt der Norm eine gute Stabilität, macht sie aber auch etwas unbeweglich.

Zweck:

Statement of scope 1998: "This International Standard presents a reference document type definition which facilitates the authoring, interchange and archiving of a variety of publications. This document type definition is deliberately general. It is a reference document type definition which provides a set of building blocks for the structuring of books, articles, serials, and similar publications in print and electronic form. This International Standard is intended to provide a document architecture to facilitate the creation of various application-specific document type definitions." [URL: http://www.xmlxperts.com/scope.htm. -- Zugriff am 19.6.1999]

Besteht aus:

Anwendung Doctype declaration

Bücher <!DOCTYPE book PUBLIC "ISO 12083:1994//DTD Book//EN">

Fortlaufende Sammelwerke <!DOCTYPE serial PUBLIC "ISO 12083:1994//DTD Serial//EN">

Unselbständige Werke (Artikel) <!DOCTYPE article PUBLIC "ISO 12083:1994//DTD Article//EN">

Mathematisches in obigen DOCTYPEs enthalten

Anwendung	Doctype declaration
Bücher	<!DOCTYPE book PUBLIC "ISO 12083:1994//DTD Book//EN">
Fortlaufende Sammelwerke	<!DOCTYPE serial PUBLIC "ISO 12083:1994//DTD Serial//EN">
Unselbständige Werke (Artikel)	<!DOCTYPE article PUBLIC "ISO 12083:1994//DTD Article//EN">
Mathematisches	in obigen DOCTYPEs enthalten

Unterhalten von:

ISO. -- URL: http://www.iso.ch/. -- Zugriff am 19.6.1999

Erhältlich:

Gebührenfrei: ISO 12083 Information / Dianne Kennedy. -- URL: http://www.xmlxperts.com/12083.htm. -- Zugriff am 18.6.1999. -- [Stellt alle ISO 12083 DTDs zur Verfügung]

Beispiele aus der DTD für Book:

Markup	Beispiele für ELEMENTs (in SGML)
<book> <front> ... <front> <body> ... <body> <appmat>{Anhänge u.ä. [optional]} </appmat> <back> [optional] </back> </book>	<!ELEMENT (%doctype;) - - (front, body, appmat?, back?) +(%i.float;) >
<front> <titlegrp> ... </titlegrp> [= Angabe von Sachtiteln] <authgrp> ... </authgrp> [= Verfasserangabe] <date> ... [optional] ... </date> <pubfront>{Impressum [optional]}</pubfront> <toc> {Table of contents [optional]}</toc> </front>	<!ELEMENT front O O (titlegrp, authgrp, date?, pubfront?, (%fmsec.d;)*, toc?) >
<titlegrp> [= Angabe von Sachtiteln] <msn> ... [optional] ...</msn> [= Zählung des Gesamttitels] <sertitle>... [optional] ...</sertitle> [= Gesamttitel] <no>... [optional] ...</no> [= Zählung] <title>...</title> [= Sachtitel] <subtitle>... [optional] ...</subtitle> [= Zusatz zum Sachtitel] </titlegrp>	<!ELEMENT titlegrp O O (msn?, sertitle?, no?, title, subtitle?) >
<authgrp> [= Verfasserangabe] Optional und wiederholbar: <author> ... </author> [= Verfasser] ODER: <corpauth>...</corpauth> [= Urheber] ODER: <aff> {Affiliation}</aff> </authgrp>	<!ELEMENT authgrp O O (author\|corpauth\|aff)* >
<confgrp> [= Kongressangabe] <no>{Zählung[optional]}</no> <confname>{Kongressname}<confname> <date>...[optional]...</date> <location>...[optional]...</location> <sponsor>...[optional]...</sponsor> </confgrp>	<!ELEMENT confgrp - - (no?, confname, date?, location?, sponsor?) > <!ELEMENT confname - O (#PCDATA) >

Weiterführende Ressourcen zu ISO 12083:

ISO 12083 Information / Dianne Kennedy. -- URL: http://www.xmlxperts.com/12083.htm. -- Zugriff am 18.6.1999. -- [Stellt alle ISO 12083 DTDs zur Verfügung]

12.7.1.2. DocBook

Hintergrund und Geschichte:

DocBook wurde von HaL Computer Systems und dem Verlag O'Reilly & Associates 1991 entwickelt (DocBook Version 1.1). Darauf wurde DocBook vor allem von der Davenport Group diskutiert, einem Forum für Produzenten von Computer-Dokumentationen. Version 1.2 war stark von Novell und DEC beeinflußt.

1994 bekam die Davenport Group offiziell die Verantwortung für Pflege und Weiterentwicklung von DocBook. Version V1.2.2 erscheint. Unter der Obhut der Davenport Group wurde die Zielsetzung von DocBook sehr ausgeweitet. Novell und Sun, die größten Nutzer von DocBook, versuchten größeren Einfluss zu bekommen.

1997 erschien DocBook Version 3.0. Viele der Teilnehmer der Davenport Group wechselten ihr Engagement von DokBook zu XML. Deswegen verlangsamte sich die Entwicklung von DocBook drastisch. Deswegen wurde die Verantwortung von DocBook an OASIS übertragen.

1998 wurde das OASIS DocBook Technical Committe gegründet. Vorsitzender ist Eduardo Gutentag von Sun. Eine XML-konforme Version von DocBook wurde in Angriff genommen.

Zweck:

"DocBook is an SGML DTD maintained by the DocBook Technical Committee of OASIS. It is particularly well suited to books and papers about computer hardware and software (though it is by no means limited to these applications).

Because it is a large and robust DTD, and because its main structures correspond to the general notion of what constitutes a "book," DocBook has been adopted by a large and growing community of authors writing books of all kinds. DocBook is supported "out of the box" by a number of commercial tools, and there is rapidly expanding support for it in a number of free software environments. These features have combined to make DocBook a generally easy to understand, widely useful, and very popular DTD. Dozens of organizations are using DocBook for millions of pages of documentation, in various print and online formats, worldwide." [http://www.oasis-open.org/docbook/intro.html. -- Zugriff am 20.6.1999]

Besteht z.Zt. aus:

DOCTYPE declaration

Doc Book 3.1. <!DOCTYPE Book PUBLIC "-//OASIS//DTD DocBook V3.1//EN">

Es gibt auch eine (noch nicht offizielle) XML-Version.

	DOCTYPE declaration
Doc Book 3.1.	<!DOCTYPE Book PUBLIC "-//OASIS//DTD DocBook V3.1//EN">

Unterhalten von:

DocBook Technical Committee (TC) von OASIS.

Erhältlich:

Gebührenfrei: http://www.oasis-open.org/docbook/docbook/3.1/docbook.dtd. -- Zugriff am 20.6.1999

Struktur der DocBook DTD (vereinfacht!):

Markup
<Set> [= Sammlung im weiteren Sinn] <SetTitle> ... </SetTitle> < SetInfo> ... < /SetInfo> <Book> ... </Book> [ein oder mehrere] <SetIndex> ... </SetIndex> </Set>
<Book> <BookInfo> ... </BookInfo> <ToC> {Table of Contents} [optional] </ToC> [eine oder mehrere] <LoT> {Abbildungsverzeichnis, Tabellenverzeichnis} [optional] </LoT> [ein oder mehrere] <Preface> ... [optional] </Preface> <Part> [optional] <Chapter> ... </Chapter> und/oder <Article>{Aufsatz} </Article> [ein oder mehrere] <Reference>{Nachweise / Fussnoten} [optional] </Reference> </Part>[ ein oder mehrere] <Appendix > ... [optional] </Appendix> <Glossary> ... [optional] </Glossary> <Bibliography> ... [optional] <Bibliography> <Index> ... [optional] </Index> [ein oder mehrere] <LoT> {Abbildungsverzeichnis, Tabellenverzeichnis} [optional] </LoT> [ein oder mehrere] <ToC> {Table of Contents} [optional] </ToC> [eine oder mehrere] </Book>
*Beispiel einer einfachen* BookInfo: <BookInfo> <BookBiblio> <Title> ... </Title> [= Sachtitel] <AuthorGroup> [= Verfasserangabe] <Author> [= Verfasser <FirstName> {Vorname} </FirstName> <Surname>{Nachname}</Surname> </Author> </AuthorGroup> </BookBiblio> </BookInfo>**

Markup

<Set> [= Sammlung im weiteren Sinn]

<SetTitle> ... </SetTitle>
< SetInfo> ... < /SetInfo>

<Book> ... </Book> [ein oder mehrere]

<SetIndex> ... </SetIndex>

</Set>

<Book>

<BookInfo> ... </BookInfo>
<ToC> {Table of Contents} [optional] </ToC> [eine oder mehrere]
<LoT> {Abbildungsverzeichnis, Tabellenverzeichnis} [optional] </LoT> [ein oder mehrere]
<Preface> ... [optional] </Preface>
<Part> [optional]

<Chapter> ... </Chapter> und/oder <Article>{Aufsatz} </Article> [ein oder mehrere]
<Reference>{Nachweise / Fussnoten} [optional] </Reference>

</Part>[ ein oder mehrere]
<Appendix > ... [optional] </Appendix>
<Glossary> ... [optional] </Glossary>
<Bibliography> ... [optional] <Bibliography>
<Index> ... [optional] </Index> [ein oder mehrere]
<LoT> {Abbildungsverzeichnis, Tabellenverzeichnis} [optional] </LoT> [ein oder mehrere]
<ToC> {Table of Contents} [optional] </ToC> [eine oder mehrere]

</Book>

Beispiel einer einfachen BookInfo:

<BookInfo>

<BookBiblio>

<Title> ... </Title> [= Sachtitel]
<AuthorGroup> [= Verfasserangabe]

<Author> [= Verfasser

<FirstName> {Vorname} </FirstName>
<Surname>{Nachname}</Surname>

</Author>

</AuthorGroup>

</BookBiblio>

</BookInfo>

Weiterführende Ressourcen zu DocBook:

Organisationen:

Official DocBook Homepage. -- URL: http://www.oasis-open.org/docbook/. -- Zugriff am 18.6.1999

12.7.1.3. TEI DTD -- Text Encoding Initiative DTD

Hintergrund und Geschichte:

1977 forderten Experten auf dem Gebiet elektronischer Texte ein einheitliches Kodierungsschema für elektronische Texte, da sonst ein Chaos unterschiedlichster Lösungen entstehen würde

1987 versammelten sich in Poughkeepsie, New York Experten auf dem Gebiet elektronischer Texte. Sie stellten fest, dass das 1977 befürchtete Chaos eingetreten ist. Man einigte sich darauf, ein einheitliches Kodierungsschema für elektronische Texte zu entwickeln. Dazu beschloss man die Poughkeepsie Principles [URL: http://www-tei.uic.edu/orgs/tei/info/pcp1.html. -- Zugriff am 21.6.1999].

1990 wurde der erste öffentliche Entwurf (TEI P1) veröffentlicht. Es wurden 15 Arbeitsgruppen gegründet, um die speziellen Bedürfnisse von Spezialgebieten einzuarbeiten. Die einzelnen Kapitel wurden von 1992 bis 1993 veröffentlicht (TEI P2).

1993 wurden alle bisher veröffentlichten Teile nochmals revidert.

Im Mai 1994 erschien die erste nicht als Entwurf bezeichnete Fassung (TEI P3). Seither liegt der Schwerpunkt darauf, TEI verständlicher zu machen. Teile einer XML-Fassung (TEI-Lite) wurden bereits veröffentlicht.

Zweck:

"The Text Encoding Initiative (TEI) is an international project to develop guidelines for the preparation and interchange of electronic texts for scholarly research, and to satisfy a broad range of uses by the language industries more generally." [http://www.uic.edu/orgs/tei/. -- Zugriff am 20.6.1999]

Sponsors:

"The TEI is sponsored by the Association for Computers and the Humanities (ACH), the Association for Computational Linguistics (ACL), and the Association for Literary and Linguistic Computing (ALLC). Major support for the project has come from the U.S. National Endowment for the Humanities (NEH), Directorate XIII of the Commission of the European Communities (CEC/DG-XIII), the Andrew W. Mellon Foundation, and the Social Science and Humanities Research Council of Canada." [http://www.uic.edu/orgs/tei/. -- Zugriff am 20.6.1999]

Besteht aus:

TEI P3 (1994)
TEI-Lite für XML: <!DOCTYPE Book PUBLIC "-//TEI//DTD TEI Lite 1.6//EN">

Unterhalten von:

TEI Consortium. -- URL: http://www.tei-c.org/. -- Zugriff am 18.6.1999

Erhältlich:

Unentgeltlich; s. Weiterführende Ressourcen

Markup-Beispiele zur TEI DTD:

<TEI.2>

<teiHeader>

<fileDesc>...</fileDesc> [= Beschreibung der elektronischen Ressource]
<encodingDesc>... [optional] </encodingDesc>
<profileDesc>... [optional] </profileDesc>
<revisionDesc>...[optional] </revisionDesc>

</teiHeader>

<text>
<front> ...[optional] </front> <body> ... </body> oder <group> ... </group> <back> ... [optional] </back> </text>

</TEI.2>

The University of Virginia Etext Center Header: TEMPLATE [http://etext.lib.virginia.edu/tei/uvatei4.html. -- Zugriff am 20.6.1999:

<teiHeader type=aacr2>

<fileDesc> [= Beschreibung der elektronischen Ressource]

<titleStmt> [Title Statement = Titelangabe]

<title> ... </title> [= Sachtitel] <author> ... </author> [= Verfasser] <respStmt> [= Angabe weiterer Verantwortlicher]

<resp> Erstellung der maschinenlesbaren Version:</resp>

<name>{Ersteller der elektronischen Version}</name>

<resp>Erstellung der digitalen Bilder: </resp>

<name> {Ersteller der digitalen Bilder}</name>

<resp>Conversion to TEI.2-conformant markup: </resp>

<name> ... </name>

</respStmt>

</titleStmt>

<extent> ca. {XXX} kilobytes </extent> [= Umfangsangabe]

<publicationStmt> [= Impressum]

<publisher> ... </publisher> [= Verlag] <pubPlace> ... </pubPlace> [= Erscheinungsort] <idno type="ETC">{Sammlung und Signatur}</idno> <availability>{woher Text bezogen werden kann, z.B. Archiv, URL, Verleger}</availability> <date> ... </date> [= Erscheinungsjahr]

</publicationStmt>

<seriesStmt> ... [optional]</seriesStmt> [= Gesamttitelangabe]

<notesStmt> [optional] [= Angabe der Fussnoten]

<note> ... </note> [eine oder mehrere] [= Fussnote]

</notesStmt>

<sourceDesc> [= bibliographische Beschreibung der Quelle]

<biblFull>

<titleStmt> [= Titelangabe]

<title> ... </title> [= Sachtitel] <title level="a|m|j|s|u">{Titel des Werkes, in dem das Werk physisch enthalten ist} [optional]</title> [= übergeordneter Titel] <author>...</author> [= Verfasser] <respStmt> [= Angabe weiterer Verantwortlicher]

<resp>{z.B. Herausgeber, Kommentator, Übersetzer}</resp>

<name> ... </name>

</respStmt>

</titleStmt> <editionStmt> ... </editionStmt> [= Ausgabebezeichnung] <extent> ... </extent> [= Umfangsangabe] <publicationStmt> [= Impressum]

<publisher> ... </publisher> [= Verlag] <pubPlace> ... </pubPlace> [= Erscheinungsort] <date> ... </date> [= Erscheinungsjahr]

</publicationStmt> <seriesStmt> ... </seriesStmt> [= Gesamttitelangabe] <notesStmt> [= Angabe der Fussnoten]

<note>...</note>

</notesStmt>

</biblFull>

</sourceDesc>

</fileDesc>

<encodingDesc>

<projectDesc> ... </projectDesc> [= Bezeichnung des TEI-Projekts]

<editorialDecl>{Beschreibung der speziellen elektronischen Umsetzung, z.B. Bildformate usw.}</editorialDecl>

<refsDecl>{wie die Textstücke identifiziert werden, Zitierweise}</refsDecl>

<classDecl>[=Angabe der Verwendeten Klassifikation]

<taxonomy id=LCSH>[=Library of Congress Subject Headings]

<bibl>

<title>Library of Congress Subject Headings</title>

</bibl>

</taxonomy>

</classDecl>

</encodingDesc>

<profileDesc>

<creation>

<date> {Datum der Erstveröffentlichung} </date>

</creation>

<langUsage>

<language id="">{ISO 639 Kodes für die Sprachen des Textes}</language>

</langUsage>

<textClass> [= Sacherschließung]

<keywords> [=Formalschlagwörter]

<term>{Fiction, Non-Fiktion, Prosa, Gedicht, Drama ...}</term>

</keywords>

<keywords scheme="LCSH"> [Schlagwörter, benutzte Norm:Library of Congress Subject Headings]

<term> {Library of Congress Subject Heading} </term>

</keywords>

</textClass>

<textClass>

<keywords>

<term type="artist"> {Name des Illustrators, Malers usw.}</term> <term type="visual work"> {Stich, Gemälde, Illustration usw.}</term>

</keywords>

<keywords>

<term>{24-bit color; 400 dpi [or variant]}</term>

</keywords>

</textClass>

</profileDesc>

<revisionDesc>

<change>

<date>...</date> [= Korrekturdatum]

<respStmt>

<resp>corrector</resp>

<name> ... </name>

</respStmt>

<item> {Beschreibung der Änderungen} </item>

</change>

</revisionDesc>

</teiHeader>

Weiterführende Ressourcen zu TEI:

Organisationen:

TEI Consortium. -- URL: http://www.tei-c.org/. -- Zugriff am 18.6.1999
TEI Homepage. -- URL: http://www.uic.edu/orgs/tei/. -- Zugriff am 18.6.1999

12.7.1.4. CALS und MIL-STD-38784

Hintergrund und Geschichte:

Das US-Militär und die Rüstungsindustrie sind die größten Anwender von SGML. Deswegen sind die militärischen SGML-Standards bei SGML-Entwicklern oft der praktische Hintergrund.

CALS (ursprünglich = Computer-Aided Logistic Support; z.Zt. = Continuous Acquisition & Lifecycle Support) ist ein Projekt des U.S. Department of Defense und des U.S. Departement of Commerce zur elektronischen Erwerbung und Verwaltung von technischen Informationen, insbesondere zu Waffensystemen. Der SGML-Teil von Cals wurde seit 1987 entwickelt und wurde 1987 Militär-Standard MIL-M-28001. Ähnliche militärische SGML-Projekte laufen z.B. in Kanada, Schweden, Australien.

MIL-STD-38784 (Standard practice for manuals, technical: general style and format requirements) wird manchmal irrtümlich CALS DTD genannt. Es gibt jedoch viele CALS DTDs, MIL-STD-38784 ist nur am bekanntesten wegen seines Tabellen-Modells, das zum de facto Standard für kommerzielle SGML Anwendungen geworden ist.

Zweck von MIL-STD-38784:

"This standard covers the general style and format requirements for the preparation of standard Technical Manuals (TM) .. and changes to standard TMs. This includes all technical documents which are assignet a TM identification number and are to be controlled by a TM management information system or are subject to requisition from an inventory control point. In addition to 'paper' delivery, this standard provides for electronic delivery of data through the use of the Document Type Definitions contained in Appendixes B trough E." [MIL-STD-38784 1.1]

Besteht aus:

MIL-Std-38784 (2 July 1995): Standard practice for manuals, technical: general style and format requirements / Department of Defense [US]

Erhältlich:

Unentgeltlich: http://wpcdso1.wpafb.af.mil/. -- Zugriff am 20.6.1999

Markup-Beispiel zu MIL-STD-38784 (stark vereinfacht)

<doc>

<volume> [optional] [ein oder mehrere Bände]

<front>

<idinfo>

<tmidno> {Technical Manual identification number} </tmidno>
<doctype> ... </doctype>
<prtitle> [= Sachtitel]

<subject> ... </subject>

</prtitle>
<distrib>{distribution statement}</distrib>
<authnot> {Verfasserangabe} </authnot>
<pubdate> {Erscheinungsdatum} </pubdate>

</idinfo>
<contents> {Inhaltsverzeichnis} </contents>
<intro> {Einleitung, Vorwort} </intro>

</front>
<body> ... </body>
<rear> ... [optional] </rear>

</Volume

</doc>

Weiterführende Ressourcen zu MIL-STD-38784 und CALS:

Organisationen:

The Air Force Product Data Systems Modernization (PDSM) Program Office
Technical Manual Specifications & Standards (TMSS) Project. -- URL: http://wpcdso1.wpafb.af.mil/. -- Zugriff am 20.6.1999. -- [Informationen zu MIL-STD-38784]
CONTINUOUS ACQUISITION & LIFE-CYCLE SUPPORT (CALS) / DEFENSE INFORMATION SYSTEMS AGENCY, Center for Standards, Information Processing Division, JIEO/CFS/JEBE. -- URL: http://www-cals.itsi.disa.mil/. -- Zugriff am 18.6.1999

12.7.1.5. Kompatibilitätsfragen: Architectural Forms

Obwohl alle vier dargestellten DTDs im Wesentlichen dieselbe Zielsetzung haben, sind sie miteinander nicht kompatibel! Um das Problem der Kompatibilität in den Griff zu bekommen, ohne die Freiheit (und Weltanschauung) der Anwender zu tangieren, gibt es die Möglichkeit Meta-DTDs zu entwerfen, sogenannte Architectural Forms. Architectural Forms werden in normalem XML/SGML definiert.

Zur Verarbeitung von Architectural Forms benötigt man eine sogenannte Architectural Engine: Software (einen Parser), um Architectural Forms in einem XML/SGML Dokument zu verarbeiten.

Solche Architectural Engines sind James Clark's SP (http://www.jclark.com/sp/. -- Zugriff am 21.6.1999) bzw. JADE (http://www.jclark.com/jade/. -- Zugriff am 21.6.1999).

Der Standard für Architectural Forms ist:

ISO/IEC 10744:1997 [HyTime]: Architectural Form Definition Requirements. Frei erhältlich: http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html. -- Zugriff am 23.6.1999

Bei Architectural Forms muss man unterscheiden:

die abgeleitete konkrete DTD: client bzw. derived DTD
die meta-DTDs, die jeweils eine sogenannte base architecture definieren

Architectural DTDs können bestimmen:

die Form von ELEMENTs
die Form von ATRRIBUTEs
die Form von NOTATIONs

Folgendes sehr vereinfachende Beispiel soll das Prinzip von Architectural Forms klar machen:

Entwurf einer Architectural Form für bibliographische Angaben nach der ISBD (International Standard Book Description) (sehr vereinfacht!):

Markup	DTD
<BibliogrBeschreibung> <Titelangabe> {Sachtitel}</Titelangabe> <Verfasserangabe> ... </Verfasserangabe> <Ausgabebezeichnung> ... [optional] </Ausgabebezeichnung> <Erscheinungsvermerk> ... </Erscheinungsvermerk> <Kollationsvermerk> ... </Kollationsvermerk> <Gesamttitel> ... [optional] </Gesamttitel> <URN> ... [optional] </URN> </BibliogrBeschreibung>	<!DOCTYPE ISBD PUBLIC "-//Payer/ISBD DTD//DE" [ <!ELEMENT BibliogrBeschreibung (Titelangabe, Verfasserangabe, Ausgabebezeichnung?, Erscheinungsvermerk, Kollationsvermerk, Gesamttitel?, URN?)> .... ]>

Markup

DTD

<BibliogrBeschreibung>

<Titelangabe> {Sachtitel}</Titelangabe>

<Verfasserangabe> ... </Verfasserangabe>

<Ausgabebezeichnung> ... [optional] </Ausgabebezeichnung>

<Erscheinungsvermerk> ... </Erscheinungsvermerk>

<Kollationsvermerk> ... </Kollationsvermerk>

<Gesamttitel> ... [optional] </Gesamttitel>

<URN> ... [optional] </URN>

</BibliogrBeschreibung>

<!DOCTYPE ISBD PUBLIC "-//Payer/ISBD DTD//DE"

[

<!ELEMENT BibliogrBeschreibung (Titelangabe, Verfasserangabe, Ausgabebezeichnung?, Erscheinungsvermerk, Kollationsvermerk, Gesamttitel?, URN?)>

....

Diese Architectural Form kann man nun auf alle vier genannten DTDs anwenden, indem man durch sogenannte Processing instructions die analogen, aber nicht gleich benannten bibliographischen Bestandteile in die ISBD-Bezeichnung überführt: die Processing Instruction besagt also, dass ein Programm, das aufgrund der Dokumente automatisch einheitliche bibliographische Beschreibungen erstellt, z.B. in Dokumenten nach ISO 12083 das ELEMENT titlegrp so behandeln soll, als ob dort die ELEMENT-Bezeichnung "Titelangabe" stehen würde.

DTD	Entsprechungen	Instructions
alle DTD		Processing Instruction: <?IS10744:arch name "ISBD" public id = "-//Payer/ISBD DTD//DE" dtd-system-id = "ISBN.dtd"?>
ISO 12083	titlegrp -- Titelangabe authgrp -- Verfasserangabe ....	<!ATTLIST titlegrp ISBD NMTOKEN #FIXED "Titelangabe"> <!ATTLIST authgrp ISBD NMTOKEN #FIXED "Verfasserangabe"> .... D.h. ein Programm, das "ISBD" verarbeitet, liest die Notation <titlegrp> ... </titlegrp> als: <Titelangabe> ... </Titelangabe>
DocBook	BookBiblio --- Titelangabe authgrp -- Verfasserangabe ...	<!ATTLIST BookBiblio NMTOKEN #FIXED "Titelangabe> <!ATTLIST authgrp NMTOKEN #FIXED "Verfasserangabe"> ....
TEI-Lite	title -- Titelangabe author -- Verfasserangabe publicationStm --- Erscheinungsvermerk ...	<!ATTLIST title NMTOKEN #FIXED "Titelangabe> <!ATTLIST author NMTOKEN #FIXED "Verfasserangabe"> <!ATTLIST publicationStm NMTOKEN #FIXED "Erscheinungsvermerk"> ....
MIL-STD-38784	prtitle -- Titelangabe authnote -- Verfasserangabe ...	<!ATTLIST prtitle NMTOKEN #FIXED "Titelangabe> <!ATTLIST authnote NMTOKEN #FIXED "Verfasserangabe"> ...

Weiterführende Ressourcen zu Architectural Forms:

XML Resource Guide Architectural Forms. -- http://www.xml.com/xml/pub/Guide/Architectural_Forms. -- Zugriff am 21.6.1999

12.7.2. Electronic Manuscript Project (-> Z39.50)

Von 1983 bis 1987 entwickelt. SGML Anwendung zur Herstellung von Büchern, Zeitschriften und Zeitschriftenartikeln. Zweck ist u.a. die Ermöglichung des Manuskriptaustauschs zwischen Autoren und Verlegern. Enthalten sind optionelle Element-Definitionen für komplexe Tabellen und wissenschaftliche Formeln.

An der Entwicklung beteiligt waren u.a.:

UMI (University Microfilms)
IEEE
Council of Library Resources
LoC
American Society of Indexers
American Chemical Society
American Institute of Physics
Councils of Biology Editors
American Mathematical Society

Diese Anwendung wurde besonders von den CD-ROM-Verlegern weitgehend angenommen. Als ANSI Z39.50 wurde sie amerikanischer Standard. Zu Z39.50 s. unten.

12.7.3. HyTime -- Hypermedia/Time-based Structuring Language : ISO 10744

HyTime ist eine Anwendung von SGML für Hypermedia (Hypertext and Multimedia).

HyTime ist ISO-Standard 10744 (2. ed.: 1997). Die erste Version erschien 1992.

Wegen der rasanten Entwicklungen im Bereich der Hypermedia ist Hytime kein Standard, der alle Aspekte von Hypermedia umfasst. Hytime standardisiert z.B. nicht bestimmte Datenformate. Hytime standardisiert aber folgende Teilgebiete:

Adressierung von Komponenten von Hypermedia-Dokumenten (Linking)
Verknüpfung, Justierung und Synchronisierung, die für eine solche Adressierung nötig sind

Hytime ist ein Standard für

links to anything, anywhere, at any time

HyTime ist gedacht für Integrated Open Hypermedia (IOH) Anwendungen:

IOH folgt dem bibliographischen Modell des Hyperlinking: mögliche "bibliographische" Verweisungen auf jeden Teil jedes Dokumentes durch eine standardisierte bibliographische Verweisung:

integrated (I): Verknüpfungen zu jeder Art von "Information", unabhängig davon, ob diese speziell für Verknüpfungen vorbereitet ist
open (O): die Adressierung ist unabhängig von der faktischen physikalischen Standortverwaltung (es ist eine logische Adresse)
hypermedia (H): Hypertext (offenes Netz von Verknüpfungen) und Multimedia (unterschiedlichste Medien -- Text, Klang, Bild ... -- werden miteinander verknüpft)

Weiterführende Ressourcen zu HyTime:

Cover, Robin: HyTime. ISO 10744:1997 -- Hypermedia/Time-based Structuring Language (HyTime), 2nd Edition. -- URL: http://www.oasis-open.org/cover/hytime.html. -- Zugriff am 21.6.1999

12.7.4. XML und Metadata

Da XML kein Dokumenttyp ist, sondern eine Document definition language, besteht die Möglichkeit, Document types zu definieren, die Metadaten in jedem Ausführlichkeitsgrad enthalten. Damit können u.a. auch Suchmaschinen gezielt z.B. nach Veröffentlichungsgattungen, Autoren, Titeln usw. suchen. Als Beispiel diene ein stark vereinfachender Entwurf für eine XML-DTD für deutsche Dissertationen: Im Text der Dissertation werden sämtliche Metadaten wie Titel, Autor, Erscheinungsjahr, Abstract usw. mit Markup markiert und sind so für eine maschinelle Titelaufnahme und Dokumentation bereitgestellt.

**Beispiel: XML-Dokument "Dissertation"**
Markup	Aus der DTD
<Dissertation> <Titelblatt> <Titel>Billy, das Koala-Genie</Titel> von <Autor>Alois Murr</Autor> <Lebensdaten>1990 - </Lebensdaten> <WissInstitution>Universität Tübingen</WissInstitution> <Jahr>1998</Jahr> .... </Titelblatt> <Kapitel> <Kapitelüberschrift>1. Koalas in den letzten 40 Mio. Jahren</Kapitelüberschrift> .... </Kapitel> ..... <Kapitel> ... </Kapitel> <Zusammenfassung> .... </Zusammenfassung> <Literaturverz> ..... </Literaturverz> <Lebenslauf> .... </Lebenslauf> </Dissertation>	<!DOCTYPE Dissertation PUBLIC .... [ <!ELEMENT Dissertation (Titelblatt, Kapitel+, Zusammenfassung, Literaturverz, Lebenslauf) <!ELEMENT Titelblatt (Titel, Autor, Lebensdaten, WissInst, Jahr, ...)> <!ELEMENT (Titel \| Autor \| Lebensdaten \| WissInst \| Jahr \| ...) (#PCDATA)> (PCDATA = keine Unterelemente,sondern nur zum Inhalt des Dokuments gehörige Zeichen) ... ]>

12.7.5. Einige XML-konforme Spezial-MLs

Um einen Eindruck vom breiten Anwendungsspektrum von XML zu geben, werden im Folgenden in alphabetischer Reihenfolge der Akronyme einige XML-konforme Spezial-MLs genannt, die bisher entwickelt wurden bzw. an denen gearbeitet wird (ohne Anspruch, auch nur die wichtigsten genannt zu haben!):

AIML -- Astronomical Instrument Markup Language: für Astronomie. Siehe: http://pioneer.gsfc.nasa.gov/public/aiml/. -- Zugriff am 16.6.1999
BIOML -- BIOpolymer Markup Language: Für Biopolymerforschung. Siehe: http://www.proteometrics.com/BIOML/. -- Zugriff am 16.1999
BSML -- Bioinformatic Sequence Markup Language: Für Genomforschungsprojekte. Siehe: http://www.visualgenomics.com/. -- Zugriff am 15.6.1999
CDF -- Channel Definition Format: soll automatische Distribution von Informationen ohne Intervention des Empfängers ermöglichen. Siehe: http://dir.yahoo.com/Computers_and_Internet/Standards/Channel_Definition_Format__CDF_/. -- Zugriff am 16.6.1999
CKML -- Conceptual Knowledge Markup Language: Siehe http://wave.eecs.wsu.edu/CKRMI/CKML.html. -- Zugriff am 15.6.1999
CML -- Chemical Markup Language: erlaubt die Darstellung von Molekülstrukturen. Siehe http://www.xml-cml.org/. -- Zugriff am 15.6.1999
EAD -- Encoded Archival Description: von Library of Congress für Archivalien. -- Siehe: http://www.loc.gov/ead/ead.html. -- Zugriff am 16.6.1999
GedML -- Genealogical Data in XML: Siehe: http://home.iclweb.com/icl2/mhkay/gedml.html. -- Zugriff am 16.6.1999
JSML -- Java Speech Markup Language: Für Sprachsynthetisizer. Siehe: http://java.sun.com/products/java-media/speech/. -- Zugriff am 15.6.1999
MCF -- Meta Content Framework: für Metadaten von Files und Sammlungen. "The Meta Content Framework (MCF) is a tool to provide information about information. The primary goal is to make the Web (Internet or Intranet) more like a library and less like a messy heap of books on the floor." Siehe: http://www.textuality.com/mcf/MCF-tutorial.html. -- Zugriff am 16.6.1999
MML (MathML) -- Mathematical Markup Language: erlaubt die Wiedergabe mathematischer Ausdrücke. -- Siehe: http://www.w3.org/Math/. -- Zugriff am 16.6.1999
Ein guter MathML-fähiger Browser ist Amaya. Frei erhältlich: http://www.w3.org/Amaya/. -- Zugriff am 21.6.1999

Beispiel zu MathML: die Maxwell-Gleichung

Darstellung im MathML-fähigen Browser Amaya	Darstellung in "normalem" Browser
	&dtri; · E = ρ ϵ 0 &dtri; × E = - &PartialD; ⁡ B &PartialD; ⁡ t c 2 ⁢ &dtri; × B = &PartialD; ⁡ E &PartialD; ⁡ t + j ϵ 0 &dtri; · B = 0
Einzelne Bestandteile der Maxwell-Gleichung	Markup
	<mrow> <mi fontstyle="normal">&dtri;</mi> <mo>·</mo> <mi fontstyle="normal">E</mi> </mrow>
=	<mo>=</mo>
	<mfrac> <mi>ρ</mi> <msub> <mi>ϵ</mi> <mn>0</mn> </msub> </mfrac>
	<mrow> <mi fontstyle="normal">&dtri;</mi> <mo>×</mo> <mi fontstyle="normal">E</mi> </mrow>
=	<mo>=</mo>
	<mrow> <mo>-</mo> <mfrac> <mrow> <mi>∂</mi> <mo>⁡</mo> <mifontstyle="normal">B</mi> </mrow> <mrow> <mi>∂</mi> <mo>⁡</mo> <mi>t</mi> </mrow> </mfrac> </mrow>

[Quelle des Inhalts obiger Tabelle: http://www.w3.org/Amaya/MathExamples.html. -- Zugriff am 21.6.1999]

Weitere Beispiele zu den Fähigkeiten von MathML:

[Quelle der Screenshots von MathML-Darstellungen in Amaya: http://www.w3.org/Amaya/MathExamples.html. -- Zugriff am 21.6.1999]

NITF -- News Industry Text Format: Format für den Austausch elektronischer Texte zwischen Nachrichtenagenturen und Zeitungsverlagen. Siehe: http://www.iptc.org/iptc/. -- Zugriff am 16.6.1999
NML -- News Markup Language: Format für den Austausch elektronischer Texte zwischen Nachrichtenagenturen und Zeitungsverlagen. Siehe: http://www.mediacenter.org/nml.htm. -- Zugriff am 16.6.1999: Konkurrenz zu NITF
PGML -- Precision Graphics Markup Language: für 2D-Vektorgraphik. Siehe: http://www.w3.org/TR/1998/NOTE-PGML-19980410. -- Zugriff am 16.6.1999
OFX -- Open Financial Exchange: für Banken. Siehe: http://www.ofx.net/ofx/default.asp. -- Zugriff am 16.6.1999
OSD -- Open Software Description Format: für Software-Firmen. Siehe: http://www.w3.org/TR/NOTE-OSD.html. -- Zugriff am 16.6.1999
RDF -- Resource Description Framework: versucht, verschiedene Metadaten-Aktivitäten zu integrieren. Siehe: http://www.w3.org/RDF/. -- Zugriff am 16.6.1999
RDL -- Resource Description Language: erlaubt z.B. Anwendungen, in denen ein Browser auf dem Computer eines Kindes automatisch Inhalte ausblendet, die nicht jugendfrei sind (dadurch würde PICS -- Platform for Internet Content Selection überflüssig).
SAE J2008 -- XML for the Automotive Industry: Siehe: http://www.xmlxperts.com/sae.htm. -- Zugriff am 16.6.1999
SMIL -- Synchronized Multimedia Integration Language: regelt das Zusammenspiel verschiedener Medientypen innerhalb eines Dokumentes. Siehe: http://dir.yahoo.com/Computers_and_Internet/Information_and_Documentation/Data_Formats/SMIL/. -- Zugriff am 16.6.1999
VML -- Vektor Markup Language: für Vektorgraphik. Siehe: http://www.w3.org/TR/1998/NOTE-VML-19980513.html. -- Zugriff am 16.6.1999
XML/EDI --- XML/Electronic Data Exchange: für geschäftliche Datenübertragung. Siehe: http://www.cenorm.be/isss/workshop/ec/xmledi/isss-xml.html. -- [XML/EDI-Projekt des European Comittee for Standardization -- CEN/ISSS] -- Zugriff am 16.6.1999

Weiterführende Ressourcen zu SGML/XML-Anwendungen:

Die unten genannte Ressource enthält sehr umfangreiche Kurzdarstellungen mit einer Fülle von Links zu Anwendungen und Projekten (unbedingt zu konsultieren!):

Cover, Robin: The SGML/XML page. -- URL: http://www.oasis-open.org/cover/. -- Zugriff am 16.6.1999. -- ["The SGML/XML Web Page is a comprehensive online database containing reference information and software pertaining to the Standard Generalized Markup Language (SGML) and its subset, the Extensible Markup Language (XML)."]

12.8. Weiterführende Ressourcen zu SGML und XML

Yahoo Categories:

http://dir.yahoo.com/Computers_and_Internet/Information_and_Documentation/Data_Formats/XML/. -- Zugriff am 18.6.1999
http://www.yahoo.com/Computers_and_Internet/Information_and_Documentation/Data_Formats/SGML/. -- Zugriff am 18.6.1999

Organisationen:

OASIS -- Organization for the Advancement of Structured Information Standards. -- URL: http://www.oasis-open.org/. -- Zugriff am 18.6.1999. -- ["OASIS, the Organization for the Advancement of Structured Information Standards, is a nonprofit, international consortium dedicated to accelerating the adoption of product-independent formats based on public standards. These standards include SGML, XML, HTML and CGM as well as others that are related to structured information processing. Members of OASIS are providers, users and specialists of the technologies that make these standards work in practice."]

Ressourcen in Printform:

Megginson, David: Structuring XML documents. -- Upper Saddle River, NJ : Prentice Hall, ©1998. -- 420 S. + 1 CD-ROM. -- ISBN 0136422993. -- [Von allen mir bekannten Darstellungen am besten für die Bedürfnisse von Dokumentaren und Bibliothekaren geeignet. Empfehlenswert]. -- {Wenn Sie HIER klicken, können Sie dieses Buch bei amazon.de bestellen}

Pardi, William J.: XML in action. -- Redmont, WA : Microsoft Press, ©1999. --- 329 S. : Ill. + 1 CD-ROM. -- ISBN 0735605629. -- {Wenn Sie HIER klicken, können Sie dieses Buch bei amazon.de bestellen}

Zum nächsten Kapitel:
Kapitel 13,1: OSI-Schicht 7: Application Layer -- Anwendungsschicht, Teil 1