Schicht 6: Presentation Layer -- Datendarstellungsschicht

Merkmale der Datendarstellungsschicht

Die Darstellungsschicht ist zuständig für:

• die Darstellung (Syntax) der Daten, die übertragen werden sollen
• die Darstellung der Datenstrukturen
• die Darstellung der Aktionen an diesen Datenstrukturen.

Die Darstellungsschicht ist nur für die Syntax (die Darstellung der Daten) zuständig, nicht für die Semantik (d.h. die Bedeutung der Daten). Für die Semantik sind nur die Anwendungen zuständig. Die Darstellungsschicht soll gewährleisten, dass die Anwendungen Syntax-unabhängig miteinander kommunizieren können. Die Protokolle der Darstellungsschicht wandeln also die anwendungsspezifischen Syntaxe in eine gemeinsame Syntax um, sodass sich die Anwendungen nicht um die Kompatibilität ihrer Syntax zu kümmern brauchen.

Aufgaben der Datendarstellungsschicht:

• Datenkompression (data compression) durch:
  • Nachrichtenreduktion durch Kürzung redundanter Teile
  • Datenvorverarbeitung durch intelligente Terminals
  • Messwertreduzierung: es werden nur Werte übertragen, die sich gegenüber der vorhergehenden Übertragung geändert haben
  • Arbeiten mit definierten Datenstrukturen
• Umcodierung (data format conversion) z.B. bei Kommunikation zwischen Rechnern mit ASCII und EBCDI.
• Datenverschlüsselung und -entschlüsselung (data encryption / decryption)
• Datenbank-Zugriff und -Verwaltung (data base management / access) (z.B. Zugriffsberechtigung, Entlastung der Datenübertragung durch intelligente Terminals)

Funktionen innerhalb der Datendarstellungsschicht:

• Anforderung der Eröffnung einer Sitzung Daten-Übertragung
• Abstimmung über Syntax
• Umwandlung der Syntax, inklusive Datenumwandlung,
• Formatierung und spezielle Umwandlungen wie Datenkompression
• Anforderung der Beendigung einer Sitzung

Protokolle für die Datendarstellungsschicht:

OSI Service Definition:

X.216 Presentation service definition

ISO 8822 Connection oriented presentation service definition

OSI Protocol Specification:

X.226 Presentation protocol specification

ISO 8823 Connection oriented presentation protocol specification

ISO 8824: Abstract Syntax Notation 1 (ASN.1)

LAN:

ISO 8822: Connection oriented presentation service definition

ISO 8823: Connection oriented presentation protocol specification

ISO 8824: Abstract syntax notation One (ASN.1)

ISO 8825: Basic encoding rules for ASN.1

Packet-switched data network:

X.216: OSI Presentation service definition note

Public-switched telephone network:

T.50: International reference alphabet -- 7-bit coded character set for information interchange

T.51: Latin based coded character sets for telematic services

ASN.1 -- Abstract Syntax Notation One:

Merkmale von ASN.1

ISO 8824 (CCITT/ITU X.208) -- Abstract Syntax Notation One (ASN.1)

ISO 8825 (CCITT/ITU X.209) -- Basic Encoding Rules (BER)

ASN.1 hat sich weitgehend durchgesetzt bei der Entwicklung von OSI-bezogenen Standards und TCP/IP-bezogenen Standards. Man verwendet ASN.1 um das Format von mittels der Protokolle ausgetauschten Daten sowie die diesbezüglichen Operationen zu definieren.

Die ASN.1-Umwandlung kann bis zu 80% (!) des CPU-Aufwandes für ein Paket bis zur Applikation hin ausmachen. ASN.1 ist nicht flexibel, sodass eine Verbesserung durch übliche Techniken der Leistungssteigerung (z.B. Parallelverarbeitung) nicht möglich ist.

ASN.1 ist eine Notation zur Beschreibung

• abstrakter Datentypen (abstract data types)
• Werte (values)

Grundbegriffe von ASN.1:

Module:

Der Grundbaustein einer ASN.1-Spezifikation ist das Modul (module).

ASN.1 kann benutzt werden, um Datenstrukturen zu definieren. Diese Definition geschieht in Form eines benannten Moduls. Der Name des Moduls wird dann zur Bezeichnung der Datenstruktur verwendet.

Struktur eines Modul:

<modulreference> DEFINITIONS::=
BEGIN
 EXPORTS
 IMPORTS
 AssignmentList
END

Erklärung:

modulreference:

Name des Moduls

EXPORTS:

Definitionen, die aus diesem Modul von anderen Modulen übernommen werden können

IMPORTS:

Definitionen, die aus anderen Modulen in dieses Modul übernommen werden sollen

AssignmentList:

Typen-Zuweisungen (type assignments), Wert-Zuweisungen (value assignments), Macrodefinitionen

Typen- und Wert-Zuweisungen haben die Form:

<name>::<description>

Darstellungs-Konventionen:

ASN.1 types und values werden in einer Programmiersprache-artigen Notation dargestellt. Dabei gelten folgende Regeln:

• das Layout hat keine Bedeutung. Mehrfach-Spatien und Zeilenvorschub werden als einfaches Spatium betrachtet
• kommentierende Bemerkungen stehen zwischen -- und --, bzw. zwischen -- und Zeilenvorschub
• identifiers (Namen von values und fields) und type references (Namen von types) bestehen aus Groß- und Kleinbuchstaben, Ziffern, Bindestrichen (-) und Spatien. Identifiers beginnen mit Kleinbuchstaben, references beginnen mit Großbuchstaben

Abstakte Daten-Typen (abstract data types):

Ein type ist eine Menge von Werten (values). Für einige types gibt es eine endliche Anzahl von möglichen Werten, für andere eine unendliche. Ein Wert ist umgekehrt ein Element der type-Menge.

Arten von types:

• simple types: sind elementar und haben keine weiteren Komponenten
• structured types: bestehen aus Komponenten
• tagged types: sind von anderen types abgeleitet
• other types:
  • CHOICE: ein oder mehrere Alternativen
  • ANY: ein beliebiger Wert eines beliebigen type

Types und Werten kann man mit mittels des ASN.1 assignement operators ::= einen Namen zuordnen. Dieser Name kann dann verwendet werden bei der Definition anderer types und Werte.

Jeder ASN.1 type außer CHOICE und ANY hat einen tag (Identifikator). Jeder tag besteht aus einer tag-classe und einer nicht-negativen tag-number.

Tag classes:

• universal: für types, deren Bedeutung in allen Anwendungen gleich ist. In ISO 8824 (X.208) definiert
• application-wide: für types, deren Bedeutung für eine bestimmte Anwendung spezifisch ist, z.B. für X.500 Directory Services. Types in zwei verschiedenen Anwendungen können denselben application tag haben, aber dennoch zwei unterschiedliche, anwendungsspezifische Bedeutungen
• private: für types, deren Bedeutung innerhalb eines bestimmten Unternehmens einheitlich ist
• context-specific: für types, deren Bedeutung spezifisch ist für Komponenten innerhalb eines structured type. Solche tags für Komponenten können innerhalb zweier verschiedener structured types dasselbe tag haben, aber dennoch unterschiedliche, kontextspezifische Bedeutungen haben

Universal types (Auswahl):

• Basic Types
  • UNIVERSAL 1: BOOLEAN. Werte: TRUE, FALSE
  • UNIVERSAL 2: INTEGER: positive und negative ganze Zahlen
  • UNIVERSAL 3: BIT STRING: eine beliebige Reihe von Bits (0, 1)
  • UNIVERSAL 4: OCTET STRING: eine beliebige Reihe von Oktetten (8bit-Werten in dezimaler Darstellung)
  • UNIVERSAL 9: REAL: reelle Zahlen
  • UNIVERSAL 10: ENUMERATED: Aufzählung von Werten, die ein Datentyp annehmen darf
• Object Types
  • UNIVERSAL 6: OBJECT IDENTIFIER: eine Reihe von Zeichen, die z.B. einen Algorithmus oder einen Attribute type bestimmen
  • UNIVERSAL 7: OBJECT DESCRIPTOR
• Character String Types:
  • UNIVERSAL 18: NumericString: Ziffern 1 bis 9, Spatium
  • UNIVERSAL 19: PrintableString: eine beliebige Reihe von druckbaren Zeichen
  • UNIVERSAL 22: IA5String: eine beliebige Reihe von ASCII-Zeichen
  • UNIVERSAL 25: GraphicString: nach ISO 8824
  • UNIVERSAL 27: GeneralString: allgemeiner Zeichen-String
• Miscellaneous Types:
  • UNIVERSAL 5: NULL
  • UNIVERSAL 8: EXTERNAL: in einem externen, Nicht-ASN.1-Dokument definierter Typ
  • UNIVERSAL 24: GeneralizedTime
• Structured Types:
  • UNIVERSAL 16: SEQUENCE eine geordnete Ansammlung von ein oder mehreren types; SEQUENCE-OF eine geordnete Anordnung von null oder mehreren Vorkommen eines einzigen type
  • UNIVERSAL 17: SET eine ungeordnete Ansammlung von ein oder mehreren types; SET OF eine ungeordnete Anordnung von null oder mehreren Vorkommen eines einzigen type

Beispiel der Definition einer Datenstruktur:

Informelle Beschreibung eines persönlichen Datensatzes	ASN.1 Beschreibung des nebenstehenden einzelnen Datensatzes (record value)
Name: John P Smith Title: Director Employee Number: 51 Date of Hire: 17 September 1971 Name of Spouse: Mary T Smith Number of Children: 2 Child Information: Name: Ralph T Smith Date of Birth: 11 November 1957 Child Information: Name: Susan B Jones Date of Birth: 17 July 1959	{ {givenName "John", initial "P", familyName "Smith"}, title "Director" number51 dateOfHire "19710917" nameOfSpouse{givenName "Mary", initial "T", familyName "Smith"}, children { { {givenName "Ralph", initial "T", familyName "Smith"} dateOfBirth "19571111" { {givenName "Susan", initial "B", familyName "Jones"} dateOfBirth "19590717"}}}

ASN.1 Beschreibung der Struktur des obigen Datensatzes:

PersonelRecord ::= [APPLICATION 0] IMPLICIT SET {
 Name,
 title [0] VisibleString,
 number EmployeeNumber,
 dateOfHire [1] Date,
 nameOfSpouse [2] Name,
 children [3] IMPLICIT SEQUENCE OF ChildInformation DEFAULT {}}

ChildInformation ::= SET {
 Name,
 dateOfBirth [0] Date}

Name ::= [APPLICATION 1] IMPLICIT SEQUENCE {
 givenName VisibleString,
 initial VisibleString,
 familyName Visible String }

EmployeeNumber ::= [APPLICATION 2] IMPLICIT INTEGER

Date ::= [APPLICATION 3] IMPLICIT VisibleString -- YYYYMMDD

BER -- Basic Encoding Rules:

Die Basic Encoding Rules (BER) geben an, wie man einen ASN.1 value als Oktett-Reihe darstellen kann.

Es gibt drei Darstellungsmethoden. Die Wahl richtet sich nach der Art des value und danach, ob die Länge des value zuvor schon bekannt ist.

• primitive, definite-length encoding: für simple types
• constructed, definite-length encoding: für structured types mit fester Feldlänge sowie für simple string types mit fester Feldlänge
• constructed, indefinite-length encoding: für structured types mit offener Feldlänge sowie für simple string types mit offener Feldlänge

Bei jeder dieser Darstellungsmethoden hat die BER-Kodierung drei bzw. vier Teile:

• identifier octets: identifizieren die class und tag number des value und zeigen an, ob die Methode primitive oder constructed ist
• length octets: gibt bei den definite length Methoden die Feldlänge an, bei der constructed indefinite-length Methode gibt es an, dass die Feldlänge offen ist
• contents octets: geben bei der primitive Methode den Wert des value an, bei den constructed Methoden geben sie die Verkettung der BER-Kodierungen der Komponenten des Wertes an
• end-of-contents octets: nur bei contructed, indefinite-length encoding. Dort markieren sie das Ende des Datenfeldes (contents octets)

Formate zum Austausch von Dokumenten:

Es gibt viele Versuche, hard- und software-unabhängige Formate für Dokumente zu schaffen und durchzusetzen. Bisher herrscht aber immer noch Chaos, und ohne Umwandlungsprogramme kommt man kaum aus.

Bit-Kodierung: ASCII-Text:

ASCII (American Standard Code for Information Interchange) ist ein ISO (International Organization for Standardization) Standard (ISO/IEC 646). 

ASCII ist ein 8-Bit-Code:

• 7 Bit dienen der Zeichendefinition, d.h. er kann nur 128 Zeichen und Steuerzeichen (Hex 00 bis 20, 7F) definieren
• 1 Bit ist ein Fehler-Check-Bit (Checksum)

Tabelle: US-ASCII (128 Zeichen) mit Hexadezimalkodierung ([ZeilenNr][SpaltenNr]): (A = 41; a = 61)

	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
0	NUL	SOH	STX	ETX	EOT	ENQ	ACK	BEL	BS	HT	LF	VT	FF	CR	SO	SI
1	DLE	DC1	DC2	DC3	DC4	NAK	SYN	ETB	CAN	EM	SUB	ESC	FS	GS	RS	US
2	SP	!	"	#	$	%	&	'	(	)	*	+	,	-	.	/
3	0	1	2	3	4	5	6	7	8	9	:	;	<	=	>	?
4	@	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O
5	P	Q	R	S	T	U	V	W	X	Y	Z	[	\	]	^	_
6	`	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o
7	p	q	r	s	t	u	v	w	x	y	z	{	|	}	~	DEL

Leider blieb es nicht bei US-ASCII, sondern es wurden regionale ASCIIs entwickelt, um z.B. die Umlaute zu kodieren. Dies führt zu den bekannten Problemen mit der Darstellung von Umlauten (die dann z.B. als "[" wiedergegeben werden). So gibt es folgende  ASCII-Varianten: International Reference Version (ISO 646.IRV), Deutschland (ISO 646.DE), Schweiz (ISO 646.CH), Französisch-Kanada (ISO 646.CA), Spanien (ISO 646.ES), Finnland (ISO 646.FI) , Frankreich (ISO 646.FR), Großbritannien (ISO 646.GB), Italien (ISO 646.NL), Norwegen/Dänemark (ISO 646.NO), Portugal (ISO 646.PT) , Schweden (ISO 646.SE), Korea (KS C 5363), China (GB 1988-80), Japan (JIS X 201). Alle sind nicht voll miteinander kompatibel. 

ASCII-Text kann von fast allen Textbearbeitungsprogrammen verwertet werden. ASCII erlaubt aber keine unterschiedlichen Schriften, Schriftarten, kompliziertere Textformatierungen, Grafiken, Farben. SGML, XML und HTML haben den großen Vorteil, dass ihre Kodierungen in reinem US-ASCII sind!

8-Bit-Kodierung: ISO 8859, ISCII:

Da moderne Computer weniger fehleranfällig sind als ältere Systeme, hat man das 8. Bit auch zur Zeichendefinition verwendet und Extended ASCII entwickelt, das 256 Zeichen und Steuerzeichen definiert. Diese 8-Bit-Kodierungen werden als ISO 8859-n international standardisiert.: 

ISO 8859-n	Name	Sprachspezifische Zeichensätze
ISO 8859-1	Latin-1	für Englisch, Dänisch, Niederländisch, Finnisch, Französisch, Deutsch, Isländisch, Irisch, Italienisch, Bahasa Malaysisch, Norwegisch, Portugiesisch, Spanisch, Schwedisch, Tagalog (Philippinen)
ISO 8859-2	Latin-2	für Albanisch, Tschechisch, Deutsch, Ungarisch, Polnisch, Rumänisch, Kroatisch, Slowakisch, Slowenisch, Schwedisch
ISO 8859-3	Latin-3	für Afrikaans, Katalanisch, Französisch, Galizisch, Italienisch, Maltesisch, Türkisch
ISO 8859-4	Latin-4	für Dänisch, Estnisch, Finnisch, Deutsch, Grönländisch, Lappisch, Litauisch, Norwegisch, Schwedisch.  Jetzt ersetzt durch ISO 8859-10: Latin-6
ISO 8859-5	Latin/Cyrillic	Bulgarisch, Belorussisch, Mazedonisch, Russisch, Serbisch, Ukrainisch
ISO 8859-6	Latin/Arabic	Arabisch ohne Punktation
ISO 8859-7	Latin/Greek	Griechisch
ISO 8859-8	Latin/Hebrew	Hebräisch ohne Punktation
ISO 8859-9	Latin-5	Finnisch, Französisch, Deutsch, Irisch, Italienisch, Norwegisch, Portugiesisch, Spanisch, Schwedisch, Türkisch
ISO 8859-10	Latin-6	Dänisch, Estnisch, Faroerisch, Finnisch, Deutsch, Grönländisch (Inuit), Isländisch, Lappisch (Samisch), Litauisch, Lettisch, Norwegisch, Schwedisch
ISO 8859-14 [Entwurf]	Latin-7	Gälische Sprachen

Neun indische Hauptschriften (Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Kannada, Telugu, Malayalam) sind als ISCII (Indian Standard Codes for Information Interchange) in 8-Bit-Kode definiert (Indian Standard IS 13194:1991)..

UNICODE, ISO/IEC 10646, UCS, UTF:

Um alle Zeichensätze der Welt, sowohl Alphabete, nichtalphabetische sprachbezogene Zeichen (z.B. Chinesisch) sowie Symbole, mathematische Operatoren, chemische Zeichen usw. zu kodieren, wurden zwei Standards entwickelt:

• Unicode, eine einheitliche 16- Bit-(2 Byte)-Kodierung: erlaubt die Kodierung von 65536 unterschiedlichen Zeichen
• ISO 10646 -- Information Technology -- Universal Multiple-Octet Coded Character Set (UCS), eine Kodierung, die bis zu 32 Bit (4 Byte) lang ist: erlaubt die Kodierung von über 2 Milliarden (256⁴) (!) Zeichen

Die historische Abfolge ist:

• 1991: Unicode, Version 1.0: Grundlage für Entwurf 2 zu ISO 10646
• 1993: ISO 10646 und Unicode, Version 1.1. Beide stimmen überein
• 1996: Unicode, Version 2.0, stimmt überein mit: ISO 10646 + Verbesserungen
• 1998 Unicode, Version 2.1

ISO 10646 besteht aus zwei miteinander kompatiblen Kodierungsschemata:

	Beispiel "T" (ASCII 54)
	binär kodiert	hexadezimal kodiert
UCS-2: Kodierung mit 2 Byte (16 Bit)	0000 0000 0101 0100	0054 = 54
UCS-4: Kodierung mit 4 Byte (32 Bit)	0000 0000 0000 0000 0000 0000 0101 0100	0000 0054 = 54

ISO 10646 ist kompatibel mit ISO 646 (US-ASCII) und ISO 8859 (Latin-1), d.h. die ersten 128 Zeichen haben (mit Ausnahme der führenden Nullen) in UCS dieselben Werte wie in US-ASCII., die ersten 256 Zeichen dieselben Werte wie  ISO 8859 (Latin-1).

Die Abwärtskompatibilität zeigt folgende Tabelle für die Kodierung von "A":

Standard	Bits	Binärkodierung	Hexadezimal-Kodierung
ISO 646 (US-ASCII)	7	100 0001	41
ISO 8859-1 (Latin-1)	8	0100 0001	41
UCS-2, Unicode	16	0000 0000 0100 0001	41
UCS-4	32	0000 0000 0000 0000 0000 0000 0100 0001	41

Den Bytegruppen in UCS wurden folgende Namen zugeordnet:

0000 0000 (4. Byte)	0000 0000 (3. Byte)	0000 0000 (2. Byte)	0000 0000 (1. Byte)
group	plane	row	cell

Da man eine UCS-2-Kodierung in UCS-4 als 00 00 xx xx darstellen kann, enthält UCS-2  alle Zeichen von group 00, plane 00 von UCS-4. Die plane von UCS-2 nennt man Basic Multilingual Plane (BMP). Es gibt noch keine Zeichensätze, die außerhalb von BMP kodiert sind.

Unicode und UCS sind voll kompatibel, d.h. jede Unicode-Kodierung ist identisch mit der entsprechenden UCS-2-Kodierung.

Die UCS-Kodierung kann, wenn sie viele Nullen enthält, sehr speicherfressend sein, deshalb entwickelte man UTF-8 (UCS Transformation Format, 8-bit form): Wenn der Hauptteil des Textes aus mit hohen Zahlen kodierten Zeichen besteht ist UTF-8 speicherfressender als UCS, bei niedrig kodierten Zeichen erspart es bis zu 25% Speicherplatz. Andere UTFs haben die unten angegebenen Funktionen.

UTF-8 (UCS Transformation Format, 8-bit form) (ISO/IEC 10646 AM1): benutzt 1 Byte für ASCII-Zeichen und 2 bis 6 Byte für die übrigen Zeichen	Beispiel "T" (ASCII 54): UCS-4:  0000 0000 0000 0000 0000 0000 0101 0100 = Hex 00000054 = 54 UTF-8: 0101 0100 (d.h. alle führenden Nullen werden weggelassen) = Hex 54
UTF-7 (UCS Transformation Format, 7-bit form): Unicode-Kodierung für Anwendungen, die das 8. Datenbit übergehen, z.B. e-mail nach dem SMTP (Simple Mail Transfer Protokol) des Internet (s. RFC 1642 : UTF-7 : A Mail-Safe Transformation Format of Unicode. In MIME setzt man den character set identifier auf "UNICODE-1-1-UTF-7".
UTF-16 (UCS Transformation Format for Planes of Group 00): erlaubt es, unter UNICODE (UCS-2) Zeichen aus UCS-4 darzustellen (genau von 16 zusätzlichen planes); dies tut man, indem manche Werte reserviert sind, um auf höhere planes zu schalten.

Alle XML-Implementierungen müssen UTF-8 und UTF-16 unterstützen.

ASCII, UCS, UNICODE und UTF sind miteinander voll kompatibel. Ihr gegenseitiges Verhältnis zeigt folgende Grafik (nicht maßstabgetreu!):

Den Zeichensätzen werden in UCS bzw. Unicode zusammenhängende Bereiche zugeordnet, deren Größe vom Umfang des Zeichensatzes abhängt. Je vier Bit werden als Hexadezimalzahl (0 bis F) kodiert und als Kennzeichnung für Unicode U+ davor gesetzt. Bisher wurden ca. 39000 Zeichen kodiert, davon ca. 21000 chinesische Zeichen! 

In XML werden Unicode-Zeichen folgendermaßen kodiert:

&#x[Unicode Hexadezimalkodierung ohne führende Nullen];

Einige Beispiele, die das Prinzip klar machen sollen:

Lateinschrift Basic Latin: Bereich U+0000 bis U+007F

Zeichen	Binärcode	Hexadezimalcode	XML Codierung	Darstellung in UNICODE-fähigem Browser
A	0000 0000 0100 0001	U+0041	A	A
B	0000 0000 0100 0010	U+0042	B	B
%	0000 0000 0010 0101	U+0025	%	%

Kyrillisch: Bereich U+0400 bis 04FF

Zeichen	Hexadezimalcode	XML Codierung	Darstellung in UNICODE-fähigem Browser
[a]	U+0430	а	а
[b]	U+0431	б	б
[v]	U+0432	в	в

Devanagari (Hindi und Sanskrit): Bereich U+0900 bis U+097F

Zeichen	Hexadezimalcode	XML Codierung
[a]	U+0905	अ
[â]	U+0906	आ
[i]	U+0907	इ

Thai: Bereich U+0E00 bis U+0E7F

Zeichen	Hexadezimalcode	XML Codierung	Darstellung in UNICODE-fähigem Browser
[ng]	U+0E07	ง	ง
[c]	U+0E08	จ	จ
[ch]	U+0E09	ฉ	ฉ

Chinesisch: CJK Ideographs: Bereich U+4E00 bis U+9FA5

Zeichen	Hexadezimalcode	XML Codierung	Darstellung in UNICODE-fähigem Browser
[zhang = ein best. Längenmaß usw.]	U+4E08	丈	丈
[lin]	U+4E83	亃	亃
[quan = Hund]]	U+72AC	犬	犬
[wen = Fisch]	U+9B69	魩	魩

Etwas für Pharmakologen und Botaniker (nur mit UNICODE-fähigem Browser lesbar): 药 茶 莓 茉 莉 茄 菜 草

Die wichtigste und die schwierigste Aufgabe der Kodierung sind die chinesisch-japanisch-koreanisch-[klassisch-vietnamesischen] Ideographe. Einige wichtige Punkte in der Geschichte dieser Kodierung:

• 1980: Chinese Character Code for Information Exchange (CCCII), in Taiwan entwickelt, kommt in Gebrauch
• 1981: Takahashi Tokutaro, Japan's National Diet Library, schlägt einen Standard für alle ostasiatischen Länder vor
• 1989 CCII wird für bibliographische Zwecke in den USA als ANSI Z39.64 angepasst und normiert: East Asian Character Code (EACC)
• 1986: bei Xerox beginnt man eine Han character cross-reference database
• 1988 RLIN (Research Libraries Information Network) beginnt CJK (Chinese-Japanese-Korean) Thesaurus: dient dem Unterhalt von EACC
• 1989: die Xerox- und die RLIN-database werden verschmolzen, dies führt zum ersten Entwurf des Unicode character set, das im selben Jahr der ISO zum Einschluss in ISO 10646 vorgeschlagen wird
• 1990: Gründung einer Arbeitsgruppe mit Mitgliedern aus allen ostasiatischen Ländern: CJK-JRG (Chinese/Japanese/Korean Joint Research Group)
• 1990: China kündet an, dass es vor Abschluss eines eigenen Entwurfs für ein Han character set (GB 13000) steht. Das Unicode Consortium und das Center for Computer and Information Development Research, die Computer-Standard-Organisation der Volksrepublik China beschließen ihre beiden Vorschläge zu einem einzigen Vorschlag zu vereinen
• 1992: Die CJK-JRG legt Unified Repertoire and Ordering (URO) 2.0 vor. URO wird sowohl Bestandteil von Unicode 1.0 als auch von ISO 10646
• 1993: CJK-JRG wird subgroup von ISO und wird umbenannt in Ideographic Rapporteur Group (IRG). Die IRG ist verantwortlich für die Weiterentwicklung von URO 2.0
• 1994: die IRG beschließt, auch klassische vietnamesische Ideographe aufzunehmen
• 1995: es liegen über 21000 Ideographe vor, deren zusätzliche Aufnahme in URO 2.0 in Erwägung gezogen wird. Für die endgültige Code-Zuweisung ist nicht die IRG zuständig, sondern ISO SC2/WG2

Mathematische Operatoren: U+2200 to U+22FF

Zeichen	Hexadezimalcode	XML Codierung
	U+221B	∛
	U+222E	∮
	U+22C2	⋂

Die gegenwärtig gültige Version des Unicode-Standards (2.1) unterstützt offiziell die im Folgenden genannten Schriften und Zeichensätze. Die Reihenfolge der Aufzählung entspricht der Abfolge in der Zuteilung der 16-Bit-Codes. Die Links verweisen auf Zeichentafeln mit der Kodierung der einzelnen Zeichen. (Zugriff auf alle Links am 11.6.1999).

• Steuerzeichen und Lateinschrift
  • C0 Controls and Basic Latin
  • C1 Controls and Latin-1 Supplement
  • Latin Extended-A
  • Latin Extended-B
• Internationale Lautschrift
  • IPA (International Phonetic Association] Extensions
• Spacing Modifier Letters
• Combining Diacritical Marks
• Greek
• Cyrillic
• Armenian
• Hebrew
• Arabic
• Indische Schriften
  • Devanagari
  • Bengali
  • Gurmukhi
  • Gujarati
  • Oriya
  • Tamil
  • Telugu
  • Kannada
  • Malayalam
• Thaischriften:
  • Thai
  • Lao
• Tibetan
• Georgian
• Hangul Jamo
• Latin Extended Additional
• Greek Extended
• Sonderzeichen, Symbole, Graphisches:
  • General Punctuation
  • Superscripts and Subscripts
  • Currency Symbols
  • Combining Diacritical Marks for Symbols
  • Letterlike Symbols
  • Number Forms
  • Arrows
  • Mathematical Operators
  • Miscellaneous Technical
  • Control Pictures
  • Optical Character Recognition
  • Enclosed Alphanumerics
  • Box Drawing
  • Block Elements
  • Geometric Shapes
  • Miscellaneous Symbols
  • Dingbats
• CJK -- Chinesisch, Japanisch, Koreanisch:
  • CJK Symbols and Punctuation
  • Hiragana
  • Katakana
  • Bopomofo
  • Hangul Compatibility Jamo
  • Kanbun
  • Enclosed CJK Letters and Months
  • CJK Compatibility
  • CJK Ideographs
  • Hangul Syllables
  • High Surrogates
  • High Private Use Surrogates
  • Low Surrogates
  • Private Use Area
  • CJK Compatibility Ideographs
• Typographisches und Kalligraphisches:
  • Alphabetic Presentation Forms
  • Arabic Presentation Forms-A
  • Combining Half Marks
  • CJK Compatibility Forms
  • Small Form Variants
  • Arabic Presentation Forms-B
  • Halfwidth and Fullwidth Forms
• Specials

Weiterführende Ressourcen zu UNICODE:

Organisationen:

Unicode Consortium. -- URL: http://www.unicode.org.

PostScript:

PostScript ist eine von Adobe entwickelte und 1985 vorgestellte Layoutdefinitions-Sprache, die von vielen Softwarepaketen und Betriebssystemen unterstützt wird. PostScript erlaubt, kompliziert formatierte Dokumente mit unterschiedlichen Schriften, Schriftarten, Grafiken, Farben usw. zu definieren. PostScript macht die Files aber sehr groß (z.B. 100 Druckseiten u.U. = 40 Mb (!) PostScript). Auch gibt es durchaus lästige Inkompatibilitäten zwischen PostScript-Files, die mit verschiedenen Programmen erstellt wurden. PostScript wird vor allem zur Steuerung von Druckern und Fotosatzgeräten benutzt. Softwarepakete, die PostScript zur Druckerausgabe unterstützen, ermöglichen trotzdem oft nicht eine Bildschirmwiedergabe von PostScript-Dateien. Die Umsetzung einer Postscript-Datei zur Druckausgabe erfolgt innerhalb des Druckers durch einen speziellen Postscript-Interpreter. Mit Display PostScript besteht die Möglichkeit, auch die Bildschirmausgabe durch PostScript zu steuern.

Weiterführende Ressourcen zu Postscript:

Adobe Acrobat:

Acrobat® ist eine von Adobe 1993 vorgestellte Software zum Datenaustausch. Adobe Acrobat hat ähnliche Features wie PostScript, Acrobat-Files sind aber weniger umfangreich als PostScript-Files. Lange Zeit war der Acrobat Reader nicht kostenlos erhältlich, was der Verbreitung von Adobe Acrobat sehr im Wege stand. Jetzt ist der Adobe Acrobat Reader Freeware und Files im Acrobat-Format .pdf (Portable Document Format) werden auch immer häufiger als Web-Seiten angeboten. Da pdf-Files viel umfangreicher und umständlicher in der Handhabung sind als html-Files, scheint mir die Publikation im WWW mittels von pdf-Files nur in den Fällen berechtigt, in denen ein unveränderliches Layout zwingend zum angebotenen Inhalt gehört (sonst gehört das in die Kategorie: "Protzige Form soll mangelhaften Inhalt verbergen").

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).

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

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. Persons -- Personen: "an individual" -- ein Individuum

6. 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.

7. 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).

8. 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).

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

10. 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: 

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 ....

Einleitung zu und Geschichte von SGML und XML

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:

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.

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.

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.)

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)

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.

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

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!)

Erklärung:

• XML-Version: verwendete Version von XML
• Zeichenkodierung: normalerweise UTF-8
• 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:

 

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 (....)> ... ]>

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."

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> <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:

<Kapitel> <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.

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)

 

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

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 -->

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>

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

 

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>

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.

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.

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">

XLink  (XLL):

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

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 CONTENT­TITLE 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 CONTENT­TITLE 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:

<ExtendedLink XML:LINK="extended" INLINE="false">  <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.ä.

XPointer:

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

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 -- Extensible Stylesheet Language:

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

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.

Anwendungen von SGML und XML:

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)
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)

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 ist EPSIG (Electronic Publishing Special Interest Group) [http://www.oasis-open.org/cover/epsig.html.]  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.

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

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) >

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 beeinflusst.

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.

Struktur der DocBook DTD (vereinfacht!):

 

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]

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/]

Besteht aus:

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

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.

<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/.

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/.

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/.[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/.

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/) bzw. JADE (http://www.jclark.com/jade/).

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

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?)> .... ]>

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"> ...

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.

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)

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) ... ]>