mailto: payer@hbi-stuttgart.de
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.
Zu den wichtigsten "Formaten" für den Austausch von Daten gehören SGML (Standard Generalized Markup Language) und XML (Extensible Markup Language).
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 |
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 | ..... |
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 .... |
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).
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:
XML 1.0 wurde offiziell am 10.2.1998 veröffentlicht.
Jedes Dokument besteht aus:
SGML ist eine Sprache zum Definieren des Markup
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.
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.)
Ein SGML profile ist eine Anzahl von Regeln, die auf verschiedene SGML Document types anwendbar sind. Ein profile kann
Das erste öffentlich definierte profile von SGML ist XML. XML ist für das WWW optimiert.
XML-Dokumente können sein
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.
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:
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.
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:
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}; |
|
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:
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 (....)> ... ]> |
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:
Syntax | Beispiel |
---|---|
<!ELEMENT Element_name Content_specification> | <!ELEMENT Kapitel (KapTitel, (Para | Zwischentit)+) >
Erklärung:
= Definition des Elementes Kapitel:
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:
<Kapitel> <KapTit>Katzenweisheit</KapTit>
<Zwischentit>Tüpfli zum Beispiel</Zwischentit>
</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:
<Kapitel> <KapTit>Katzenweisheit</KapTit>
<Zwischentit>Tüpfli zum Beispiel</Zwischentit>
</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.
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) |
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
vorkommen |
<!ELEMENT BibliogrBeschreibung (Titelangabe, Verfasserangabe, Ausgabebezeichnung?, Erscheinungsvermerk, Kollationsvermerk, Gesamttitel?, URN?)> |
|
optional und wiederholbar | das betreffende Element usw. kann
vorkommen |
<!ELEMENT authgrp (author|corpauth|aff)* > |
|
notwendig und wiederholbar | das betreffende Element usw. muss
vorkommen |
<!ELEMENT Kapitel (KapTitel, (Para | Zwischentit)+) > |
|
aufeinanderfolgend |
|
|
|
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 |
---|---|
<!-- {Text der Anmerkung} --> | <!-- Dies ist eine DTD für deutschsprachige Dissertationen --> |
Syntax:
Syntax | Beispiel |
---|---|
<!ELEMENT Element_name Content_specification> | <!ELEMENT Kapitel (KapTitel, (Para | Zwischentit)+) > <!ELEMENT (KapTitel | Para | Zwischentit) (#PCDATA)> |
Erklärung:
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> |
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 |
Die attribute_definition hat folgende Syntax:
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 |
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> |
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> |
Entities können sein:
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:
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.
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.
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"> |
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:
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: haben die in folgender ATTLIST angegebenen Möglichkeiten:
DTD | Erklärung |
---|---|
<!ELEMENT
SimpleLink ANY>
<!ATTLIST SimpleLink
> |
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
ACTUATE: kann folgende Werte haben:
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
>
|
Die ATTLIST für diesen INLINE extended link ist wie
die für den simple link (s.oben) mit zwei Unterschieden:
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
> |
Obige DTD kann im Markup z.B. so verwendet werden:
<ExtendedLink XML:LINK="extended">
CMC-Skript
</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:
<ExtendedLink XML:LINK="extended" INLINE="false">
</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}
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.
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.
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.
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:
|
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
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>
</book> |
<!ELEMENT (%doctype;) - - (front, body, appmat?, back?) +(%i.float;) > |
<front>
</front> |
<!ELEMENT front O O (titlegrp, authgrp, date?, pubfront?, (%fmsec.d;)*, toc?) > |
<titlegrp> [= Angabe von Sachtiteln]
</titlegrp> |
<!ELEMENT titlegrp O O (msn?, sertitle?, no?, title, subtitle?) > |
<authgrp> [= Verfasserangabe]
</authgrp> |
<!ELEMENT authgrp O O (author|corpauth|aff)* > |
<confgrp> [= Kongressangabe]
</confgrp> |
<!ELEMENT confgrp - - (no?, confname, date?, location?,
sponsor?) > <!ELEMENT confname - O (#PCDATA) > |
Weiterführende Ressourcen zu ISO 12083:
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.
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]
</Set> |
<Book>
</Book> |
Beispiel einer einfachen BookInfo:
<BookInfo>
</BookInfo> |
Weiterführende Ressourcen zu DocBook:
Organisationen:
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:
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>
</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]
</fileDesc> <encodingDesc>
</encodingDesc> <profileDesc>
<revisionDesc>
</revisionDesc> </teiHeader> |
Weiterführende Ressourcen zu TEI:
Organisationen:
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>
</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
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>
</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"
|
|
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 |
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:
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.:
Diese Anwendung wurde besonders von den CD-ROM-Verlegern weitgehend angenommen. Als ANSI Z39.50 wurde sie amerikanischer Standard. Zu Z39.50 s. unten.
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:
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:
Weiterführende Ressourcen zu HyTime:
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.
Markup | Aus der DTD |
---|---|
<Dissertation>
</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) ... ]> |
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!):
Beispiel zu MathML: die Maxwell-Gleichung
Darstellung im MathML-fähigen Browser Amaya | Darstellung in "normalem" Browser |
---|---|
▿
|
|
Einzelne Bestandteile der Maxwell-Gleichung | Markup |
<mrow>
|
|
= |
<mo>=</mo> |
<mfrac>
</mfrac> |
|
<mrow>
|
|
= |
<mo>=</mo> |
<mrow>
|
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]
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!):
Yahoo Categories:
Organisationen:
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