16. Einführung in XML und SGML 16-1 Kapitel 16: Einf ...users.informatik.uni-halle.de/~brass/asq_db08/dg_xml.pdf · 16. Einführung in XML und SGML 16-3 Inhalt 1. Einführung

16. Einfuhrung in XML und SGML 16-1

Kapitel 16: Einfuhrung inXML und SGML

References:• Liora Alschuler: ABCD . . . SGML — A User’s Guide to Structured Information.

International Thomson Computer Press (ITP), 1995, ISBN 1-850-32197-3, 414 pages.

• Charles F. Goldfarb, Yuri Rubinsky: The SGML Handbook. Clarendon Press, 1990.

• Henning Lobin: Informationsmodellierung in XML und SGML. Springer-Verlag, 1999.

• C. M. Sperberg-McQueen and Lou Burnard (Eds.): A Gentle Introduction to SGML.[http://www-tei.uic.edu/orgs/tei/sgml/teip3sg/index.html]

• On SGML and HTML (in the HTML 4.01 Specification).[http://www.w3.org/TR/html401/intro/sgmltut.html]

• Yuri Rubinsky, SoftQuad: The SGML Primer.[http://www.softquad.com/top_frame.sq?page=resources/content_sgml_primer.html]

• Martin Bryan (The SGML Centre): An Introduction to the Standard Generalized MarkupLanguage (SGML). [http://www.personal.u-net.com/~sgml/sgml.htm]

• Harvey Bingham: SGML Syntax Summary.[http://www.oasis-open.org/cover/sgmlsyn/contents.htm]

• Charles F. Goldfarb’s SGML Source Home Page: [http://www.sgmlsource.com/]

• Boc DuCharme: XML — The Annotated Specification. Prentice Hall, 1999.

• Tim Bray, Jean Paoli, C.M. Sperberg-McQueen: Extensible Markup Language (XML)1.0, 1998. [http://www.w3.org/TR/REC-xml] See also: [http://www.w3.org/XML].

Stefan Brass: Einfuhrung in Datenbanken und das WWW Universitat Halle, 2008


Lernziele

Nach diesem Kapitel sollten Sie folgendes konnen:

• die Beziehung zwischen SGML, XML, HTML und

XHTML erklaren.

• syntaktisch korrekte XML Dokumente schreiben.

• einfache XML DTDs lesen.

• XML mit relationalen Datenbanken vergleichen.



Inhalt

1. Einfuhrung

'

&

$

%2. XML Dokumente (Syntax)

3. Document Type Definitions (DTDs)

4. Namespaces

5. XML und Datenbanken



Einfuhrung (1)

• SGML (“Standard Generalized Markup Language”)

ist ein ISO-Standard seit 1986.

• Fruher wurden Manuskripte von Buchern auf der

Schreibmaschine geschrieben, “Markup” waren die

zusatzlichen, handschriftlichen Anweisungen an den

Setzer (z.B. “Fettdruck”).

Anderes Beispiel: Wichtige Teile von Texten werden mit Textmarkernhervorgehoben, gelegentlich sogar verschiedene Arten von Informa-tionen mit verschiedenen Farben. Der Name fur die VorlauferspracheGML (1969) wurde wohl nach den Projektmitarbeitern Goldfarb, Mos-her und Lorie gewahlt. Charles F. Goldfarb gilt als Vater von SGML.



Einfuhrung (2)

• In SGML/XML werden Bestandteile von Texten

mit “Tags” markiert, z.B.

<title>︸︷︷︸Start-Tag

Mein erstes HTML-Dokument︸︷︷︸Inhalt

</title>︸︷︷︸End-Tag︸︷︷︸

Element

• XML ist eine Teilmenge (vereinfachte Version) von

SGML, die 1998 vom W3C als Empfehlung verab-

schiedet wurde.

Den Browser-Herstellern war das vollstandige SGML zu kompliziert.



Einfuhrung (3)

• SGML hat zwei Ebenen:

� Einerseits ist es ein spezieller Syntaxformalismus:

Man kann in Form einer DTD (“Document Type

Definition”) festlegen, welche Tags erlaubt sind,

wie sie geschachtelt werden mussen, u.s.w.

� Andererseits ist es ein Datenformat: Man kann

Texte oder Daten mit Tags entsprechend einer

gegebenen DTD strukturieren.

• Das gilt entsprechend auch fur XML.Allerdings kann man XML auch ohne vorab festgelegte DTD als Da-tenformat benutzen (“well-formed XML”). Bei SGML geht das nicht.



Einfuhrung (4)

• HTML (HyperText Markup Language) ist die Syn-

tax, in der Web-Seiten verfasst sind.

Tatsachlich sind an einer Webseite, wie sie im Browser angezeigtwird, noch weitere Sprachen und Datenformate beteiligt. Z.B. enthaltHTML fur jedes Bild nur einen Verweis auf die entsprechende Bilddatei(in einem Format wie GIF, JPEG, PNG). Manche Webseiten enthaltenauch Programmcode in Javascript, in vielen Fallen wird das genaueAussehen von Stylesheets in CSS beeinflusst. Aber der eigentlicheText und die wesentliche Struktur der Webseite ist in HTML verfasst.

• HTML ist eine Anwendung von SGML, d.h. SGML

fur eine spezielle DTD.

Entsprechend ist XHTML eine Anwendung von XML.



Einfuhrung (5)

• Man kann Syntax (Dokument-Strukturen) in SGML

/XML definieren, aber nicht Semantik (Bedeutung).

• Z.B. kann man definieren, daß es ein Tag “<it>”

gibt, aber daß dies Kursivschrift (“italics”) bedeu-

tet, kann man nicht in SGML/XML festlegen.Es gibt zusatzliche Standards: DSSSL, CSS, XSLT/XSL FO.

• Die HTML Spezifikation enthalt daher außer einer

DTD noch beschreibenden Text, der Bedeutung

und Aussehen der Markierungen mit Tags erlautert.DTDs sind nicht sehr machtig, deswegen sind auch einige zusatzlicheSyntaxeinschrankungen nur textuell beschrieben.



Einfuhrung (6)

HTML-Dokument (Beispiel eines SGML Dokumentes):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

"http://www.w3.org/TR/html4/strict.dtd"><html>

<head>

<title>Mein erstes HTML Dokument</title>

</head>

<body>

<h1>Uberschrift</h1>

<p>Text</p>

</body>

</html>



Einfuhrung (7)

• Durch Schachtelung ergibt sich eine Baumstruktur:

html��

head

title

“Mein . . . ”

PPPPPPPPPPPP

body��

��

h1

“Uberschrift”

HHHHHH

HH

p

“Text”



Einfuhrung (8)

• SGML/XML sind keineswegs darauf eingeschrankt,

nur Strukturen in Texten zu markieren.

• Man kann auch Daten mit XML/SGML strukturie-

ren, die man in ahnlicher Weise in einer relationalen

Datenbank abspeichern konnte.

• Im folgenden Beispiel kommen auch Attribute vor:

< BEW︸︷︷︸El.-Typ

JAHR︸︷︷︸Attribut

= "2006"︸︷︷︸Wert

> Na ja, geht so︸︷︷︸Inhalt

</BEW>

• Bei leerem Inhalt kann man Start- und Endtag ver-

schmelzen (“leeres Element Tag”, endet in />).



Einfuhrung (9)

<?xml version="1.0" encoding="ISO-8859-1"?>

<Feuerwerksartikel>

<Bombenrohr Herst="Diamond" Name="Silver Star">

<Angebot Handler="Roder" Preis="5.49"/><Bew Jahr="2005">Goldpalme! Toll.</Bew>

<Bew Jahr="2006">Na ja, geht so.</Bew>

</Bombenrohr>

<Batterie Herst="Weco" Name="Tanz der Vampire"

Schuss="12" Hoehe="45" Dauer="30">

<Angebot Handler="Roeder" Preis="8.50"/><Angebot Handler="Preisw-FW" Preis="7.69"/><Bew Jahr="2006">Rote Blinker. Hubsch.</Bew>

</Batterie>

</Feuerwerksartikel>



Einfuhrung (10)

ARTIKEL

ID HERST NAME TYP HOEHE SCHUSS DAUER

1 Diamond Silver Star BO 60

2 Weco Tanz der Vampire BA 45 12 30

ANGEBOT

ID HAENDLER PREIS

1 Roder 5.49

2 Roder 8.50

2 Preisw.F. 7.69

BEWERTUNG

ID JAHR TEXT

1 2005 Goldpalme! Toll.

1 2006 Na ja, geht so.

2 2006 Rote Blinker. Hubsch.



Einfuhrung (11)

• Das Wesentliche bei XML ist nicht die Syntax, son-

dern die interne Baustruktur, die sich durch Schach-

telung der Elemente ergibt.

• Man kann XML als ein Datenmodell (neben dem

relationalen Modell und dem ER-Modell) ansehen.

• Es gibt auch eine eigene Anfragesprache: XQuery.

• Das XQuery Data Model (XDM) abstrahiert von

syntaktischen Details und stellt den Inhalt eines

XML Dokumentes als Baum mit Element-Knoten,

Attribut-Knoten, Text-Knoten u.s.w. dar.



Einfuhrung (12)

Dokument��

@@

@@

��

Feuerwerksartikel

��

Bombenrohr�

��

HHHH

HHHH

Herst��

��q q q

Name��

��

q q qPPPPPPPPPPPP

Batterie�

��

HHHH

HHHH

Herst��

��q q q ss

Dauer��

��

q q q

Angebot Bew Bewqqqqqq q q Handler��

��qqqqqqqq q q Preis

��

��

Angebot Angebot Bewqqqqqq q q Handler��


��

��

qqqqqq q q Handler��


��

��

q qJahr

��

��

q qJahr

��

��

q qJahr

��

��

Text��

��

Text��

��

Text��

��



Einfuhrung (13)

• Selbstverstandlich kann man SGML/XML Doku-

mente mit einem beliebigen Texteditor erstellen.

• SGML enthalt viele Abkurzungsmoglichkeiten, um

den Tippaufwand zu verringern.

• Da man heute bei syntaxgestutzten Editoren nicht

jedes Zeichen tippen muß, schien das bei XML nicht

mehr so wichtig (einfachere, aber langere Syntax).

• Ein Beispiel zeigen die nachsten Folien.Die unterschiedliche Visualisierung des gleichen Dokumentes (zumTeil mit Tabellenstrukturen) unterstreicht noch einmal die Bedeutungder internen Datenstruktur im Vergleich zum externen Text.







Markup-Arten (1)

• Wie oben schon erwahnt, war das erste “Markup”

Anweisungen fur den Setzer, z.B. “18pt Schrift”.

• Dies ist “darstellungsorientiertes Markup”.

• Es funktioniert, solange die einzige Anwendung des

Textes das Ausdrucken in genau diesem Format ist.

• Man kann Texte aber auch anders nutzen:

� Rechtschreib-Prufung

� Automatische Erstellung Inhaltsverzeichnis

� Suchen und Ersetzen

� Andere Formate, andere Medien (z.B. Web).



Markup-Arten (2)

• Z.B. kann man Kapitel-Uberschriften als groß, fett,

zentriert markieren.

• Da es aber vielleicht auch andere große, fette, zen-

trierte Teile im Text gibt (etwa spezielle Warnun-

gen), kann man aus den vorhandenen Daten nicht

automatisch ein Inhaltsverzeichnis konstruieren.

Außerdem eventuell einzelne Kapiteluberschriften leicht anders (nichtganz einheitlich): z.B. einmal Zentrierung vergessen, oder etwas klei-nerer Zeichensatz, damit die Uberschrift in eine Zeile passt.

• WYSIWYG (“What you see is what you get”):

“What you see is all you’ve got” (Brian Kernighan).



Markup-Arten (3)

• Wie auch sonst bei der Erfassung von Daten, muß

man sich vorher uberlegen, was man mit dem Do-

kument spater machen will.

• Alternative zu darstellungs-orientiertem Markup:

Inhaltsorientiertes Markup. Hier wird dieser Textteil

als Kapiteluberschrift markiert.

Die Warnung, die im Beispiel gleich gedruckt wird, wird explizit alsWarnung/Hinweis markiert. Bei inhaltsorientierten Markup unterschei-det man also Dinge, die fur das reine Ausdrucken nicht unterschiedenwerden mußten, um so auch andere Anwendungen zu erlauben.



Markup-Arten (4)

• Die genaue Darstellung wird dann (getrennt) in ei-

nem Stylesheet festgelegt.Es kann z.B. verschiedene Stylesheets fur verschiedene Ausgabeme-dien geben. Wie Kapiteluberschriften aussehen, ist nur an einer Stellefestgelegt, statt bei jeder Uberschrift. Es gibt daher eine großere Kon-sistenz und die festlegung ist leichter anderbar.

• In HTML sind darstellungsorientierte und inhalts-

orientierte Elemente vermischt.Rein darstellungsorientierte Dinge werden zuruckgedrangt, nachdemCascading Stylesheets verfugbar sind.

• Perfekt inhaltsorientiert geht nicht, da HTML fur

beliebige Arten von Dokumenten verwendet wird.



Markup-Arten (5)

• Z.B. hat HTML keine Tags fur Angebote, Waren-

bezeichnungen, Preise im Web. Das ware aber fur

Preisvergleichsdienste nutzlich.

• Diese prinzipielle Einschrankung jeder festen Menge

von Tags war eine Motivation fur die Einfuhrung

von XML.

• Umgekehrt kann man XML anzeigen, indem man

mit einem XSLT-Stylesheet eine Ubersetzung in

HTML festlegt.

Fur HTML ist die Darstellung ja definiert, fur beliebiges XML nicht.



Datenaustausch-Format

• XML wird haufig zum Datenaustausch zwischen

Firmen verwendet (z.B. Bestellungen, Rechnungen).

• Dazu ware es naturlich gut, sich auf einen einheit-

lichen Satz von Tags (eine DTD) fur die jeweilige

Anwendung zu einigen.

• Eine besondere Starke von SGML/XML ist aber

auch die leichte Konvertierbarkeit.

Mit einem XSLT Strylesheet kann man ein Dokument bezuglich einerDTD recht einfach in ein Dokument bezuglich einer anderen DTDumwandeln (oder auch in ein Nicht-XML Format).



Inhalt

1. Einfuhrung

2. XML Dokumente (Syntax)

'

&

$

%3. Document Type Definitions (DTDs)

4. Namespaces

5. XML und Datenbanken



Elemente (1)

• Ein XML/SGML Dokument ist ein Text, in dem

Worte, Phrasen, Abschnitte mit “Tags” markiert

sind, z.B.

<title>Mein erstes HTML Dokument</title>

• Tags sind in “<” und “>” eingeschlossen.

“Tag” (engl.) heißt u.a. “Etikett”, “Schildchen”.

• “<title>” ist ein Beispiel fur ein Start-Tag.

• “</title>” ist ein Beispiel fur ein End-Tag.

Das End-Tag erkennt man an dem “/” vor dem Namen im Tag.



Elemente (2)

• Der Textteil vom Beginn eines Start-Tags bis zum

Ende des zugehorigen End-Tags heißt ein Element.

• Der Name im Start-Tag und im End-Tag heißt

Element-Typ. Im Beispiel: “title”.

Manche Autoren sagen auch “Element-Name” statt “Element-Typ”.

• Oft wird “Tag” gesagt, wo eigentlich “Element”

oder “Element-Typ” formal richtiger ware.

Z.B. “Jedes HTML Dokument muß ein title-Tag enthalten”. Esstimmt zwar, daß jedes HTML-Dokument ein Tag “<title>” ent-halten muß (und auch ein Tag “</title>”), aber gemeint ist doch:“Jedes HTML-Dokument muß ein title-Element enthalten”.



Elemente (3)

• Namen (Bezeichner, u.a. fur Elementtypen) konnen

Buchstaben, Ziffern, Punkte “.”, Bindestriche “-”,

Unterstriche “_” und Doppelpunkte “:” enthalten.

Und noch einige zusatzliche Zeichen aus dem Unicode Zeichensatz.Sie mussen mit einem Buchstaben, einem Unterstrich “_”, oder einemDopplepunkt “:” beginnen. Der Doppelpunkt sollte nur in Uberein-stimmung mit der Namespace Spezifikation verwendet werden. Allenamen, die mit “xml” beginnen, sind reserviert.

• In XML wird Groß- und Kleinschreibung unterschie-

den, in SGML ist dies wahlbar.

In HTML ist die Groß-/Kleinschreibung egal, außer fur Entities (s.u.).In XHTML nicht.



Elemente (4)

• Der Text zwischen Start-Tag und End-Tag (ohne

die Tags selbst) ist der Inhalt des Elementes. Im

Beispiel von Folie 16-26 ist dies der Text

Mein erstes HTML Dokument

• Die DTD legt fest, was genau als Inhalt erlaubt ist.

Z.B. muß in XHTML eine “unordered list” ul (Liste

nicht numerierter Punkte) eine Folge von Elemen-

ten des Typs “list item” li enthalten:

<ul><li>First</li><li>Second</li></ul>

• Aufgabe: Zeichnen Sie die Baumstruktur dafur.



Elemente (5)

• Elemente konnen sich nicht partiell uberlappen.

Fur je zwei Elemente A und B ist A entweder vollstandig in B enthal-ten, oder B in A, oder die beiden uberlappen sich uberhaupt nicht.

• Start-Tags und End-Tags mussen daher korrekt ge-

schachtelt werden. Z.B. ist Folgendes erlaubt:

<h1><code>...</code></h1>

Das Folgende ist dagegen ein Syntaxfehler:

<h1><code>...</h1></code>

• Dies entspricht offenenden und schließenden Klam-

mern verschiedener Typen: ( [ ] ) ist ok, [ ( ] ) nicht.



Elemente (6)

• Es gibt vier Arten von Element-Typen:

� Elemente, die nur reinen Text enthalten konnen.Beispiel: title.

� Elemente, die nur andere Elemente enthalten.Diese “Kind-Elemente” konnen naturlich ihrerseits wieder Textenthalten. Beispiel: ul muß Folge von li-Elementen enthalten.

� Elemente, die eine Mischung von Text und an-

deren Elementen enthalten.“Mixed content model”. Beispiel: <p>Hello, <em>world</em>!</p>

� Elemente, die immer leeren Inhalt haben.Sie markieren dann eine Position im Text (Beispiel: br in HTML:Zeilenumbruch) oder enthalten Daten in Form von Attributen.



Leere Elemente

• In XML muß es fur jedes offnende Tag (Start-Tag)

ein zugehoriges schließendes Tag (End-Tag) geben.

SGML erlaubt dagegen, unter gewissen Voraussetzungen Tags weg-zulassen, die sich aus dem Kontext eindeutig rekonstruieren lassen.

• Da <br></br> nicht gut aussieht (und das schlie-

ßende Tag keine zusatzliche Information enthalt),

wurden spezielle Tags fur leere Elemente in XML

eingefuhrt: “<br/>” ist aquivalent zu “<br></br>”.

Dies war einer der wenigen Punkte, bei dem XML zunachst keineTeilmenge von SGML war. Bei SGML bestand das Problem nicht, daman dort das schließende Tag immer weggelassen hatte. SGML wirdnun entsprechend erweitert.



Attribute (1)

• Im Start-Tag konnen optional Attribut-Wert Paare

angegeben werden.

• Z.B. werden in HTML/XHTML Verweise auf an-

dere Dokumente mit dem Element a (“anchor”)

markiert:XML was developed by the

<a href="http://www.w3.org">W3C</a>.

• Der Text des Verweises (“Label”) ist im Element-

Inhalt gegeben, die URI der referenzierten Webseite

im Attribut “href”.



Attribute (2)

Start-Tag:

- <��

��- Element-Type -

? - Space - A-V-Pair

6

6

-6

- >��

��-

End-Tag:

- <��

��- /

��


- Space

6 >��

��-



Attribute (3)

Empty Element Tag:

- <��


? - Space - A-V-Pair

6

6

-6

- /��

��- >

��

��-

• “Space” (white space) besteht aus ein oder mehr

Leerzeichen, Zeilenumbruchen, Tabulatorzeichen.

Dies entspricht den ASCII-Codes 32, 13, 10, 9.



Attribute (4)

A-V-Pair:

- Attribute - =��

�� -

-Space

6

-Space

6 Value -

Value:

-

��

��" - Data String without " -

��

��" -

-

��

��’ - Data String without ’ -

��

��’

6



Attribute (5)

• Attributwerte konnen in " oder ’ eingeschlossen

werden. Das jeweils andere Zeilen kann dann im

Attributwert benutzt werden.

Falls man beide Arten von Anfuhrungszeichen benotigt, muß man einEntity oder eine Zeichen-Referenz verwenden (s.u.).

• Attributwerte konnen keine Elemente enthalten.

• Das Zeichen “<” ist in Attributwerten verboten.

Wenn notig, kann man es aber mit einem Entity oder einer Zeichen-Referenz darstellen (s.u.). Durch das Verbot von “<” in Attributwertenwerden Fehler fruher gefunden (z.B. ein fehlendes ").



Attribute (6)

• Das Zeichen “&” hat in SGML/XML eine besondere

Bedeutung (Zeichen/Entity Referenz, s.u.), das gilt

auch in Attributwerten.

• Attributwerte konnen sich uber mehrere Zeilen er-

strecken. Tabulatorzeichen und Zeilenenden werden

dabei intern in Leerzeichen umgewandelt.Abhangig vom in der DTD deklarierten Attributtyp wird Leerplatzggf. normalisiert: Er wird dann am Beginn und Ende des Attributwer-tes entfernt, mehrere aufeinanderfolgende Leerzeichen werden durchein einzelnes ersetzt. Fur “CDATA” Attribute geschieht dies nicht.

• Die Reihenfolge, in der mehrere Attribut-Wert Paa-

re in einem Start-Tag angegeben werden, ist egal.



Zeichen-Referenzen (1)

• Man muß unterscheiden zwischen

� dem Zeichenvorrat, der intern benutzt wird (Da-

ten, die ein XML Parser der Anwendung liefert)

� der Codierung dieser Zeichen in Dateien fur den

Datenaustausch (externe Reprasentation).

• Intern benutzt XML den Unicode Zeichensatz.

• Extern kann man z.B. auch die ISO 8859-1 (ISO

Latin 1) Zeichen-Codes verwenden (Teilmenge der

Unicode Zeichen fur westeuropaische Sprachen).

Andere Codierungen sind z.B. spezialisiert auf kyrillische Zeichen.




• Die XML-Deklaration ganz am Anfang des Doku-

mentes (s.u.) legt die Codierung fest.

Die Codierung kann auch bei der Ubertragung des Dokumentes mitHTTP spezifiziert werden. In SGML gibt es eine extra Parameterdatei(SGML Deklaration), die u.a. die Zeichencodierung festlegt.

• Alle Zeichen des ISO Latin 1 Zeichensatzes (der

seinerseits ASCII umfasst) sind auch im Unicode

Zeichensatz enthalten und haben den gleichen Zah-

lenwert als Code (siehe aber nachste Folie).

ASCII ist der “American Standard Code for Information Interchange”(enthalt z.B. keine deutschen Umlaute). ASCII ist sehr verbreitet.




• Von der externen Codierung her ist Unicode (mit

UTF-8) aber nicht kompatibel mit ISO Latin 1.

Im Unicode sind 17 “Planes” vorgesehen, die sich in jeweils 16 bit co-dieren lassen, damit konnen uber eine Million Zeichen codiert werden.Es sind mehrere externe Codierungen definiert, eine ist UTF-16, inder Zeichen der wichtigen “Basic Multilingual Plane” mit 16 bit co-diert sind, und andere (sehr seltene) Zeichen mit zwei 16 bit Einheitenhintereinander. Sehr verbreitet ist UTF-8. Dort sind die Zeichen mit1 bis 4 Bytes codiert. ASCII-Zeichen (Zahlwerte bis 127) benotigennur ein Byte, insofern ist UTF-8 voll kompatibel zu ASCII. Die deut-schen Umlaute (im Bereich zwischen 128 bis 255) benotigen aberschon zwei Bytes. In der normalen ISO Latin 1 Codierung benotigensie nur ein Byte. Der Grund fur den Unterschied ist, daß UTF-8 Bitsbenotigt, um anzuzeigen, daß es noch Folgebytes gibt. Dies ist beiISO Latin 1 nicht notig, da seine Codes immer in ein Byte passen.




• Zeichen konnen als “Zeichen-Referenz” uber ihren

numerischen Code angegeben werden:

ä

ist z.B. ein “a”.

• Hexadezimale Notation ist auch moglich: ä

• Die Zahlwerte beziehen sich auf den Zeichenvorrat

(z.B. Unicode), nicht auf die externe Codierung.

• Man kann z.B. extern (in der Datei) nur ASCII

verwenden (besonders portabel), und dennoch alle

Unicode-Zeichen darstellen.




Character Reference:

-

��

��& -

��

��# - Decimal Digits -

��

��; -

-

��

��x - Hexadecimal Digits

6

• In DTDs konnen symbolische Namen (“Entities”)

fur diese Zeichen-Referenzen definiert werden.

• Dann braucht man sich die Zeichencodes nicht zu

merken.In HTML kann man z.B. “ä” (“a Umlaut”) fur “a” schreiben(falls man extern reines ASCII benutzen will). In XML muß man sichsolche Namen selbst definieren.




• Zeichen-Referenzen konnen auch benutzt werden,

um Zeichen einzugeben, die sonst eine spezielle Be-

deutung in XML/SGML hatten.Man muß diese Zeichen “escapen”, um ihnen ihre spezielle Bedeutungzu nehmen, so daß sie als normale Daten behandelt werden.

• Z.B. leitet das Zeichen “&” (ASCII 38) normaler-

weise eine Zeichen/Entity-Referenz ein. Wenn man

es als gewohnliches Zeichen in den Daten haben

will, muß man & schreiben.Das Ergebnis einer Zeichen-Referenz sind immer normale Daten. An-deres Beispiel: Ein Anfuhrungszeichen " (ASCII 34) ist in einem At-tributwert enthalten, der mit " begrenzt ist: Als “"” schreiben.



Entity-Referenzen (1)

• Entities sind benannte Bausteine von Dokumenten.

• Mit einer Entity-Referenz kann den Inhalt eines En-

tities in ein Dokument einfugen.

• Entities konnen als Abkurzung verwendet werden.

Z.B. kann man ein Entity “ora” mit dem Wert

“Oracle 8.1.6” definieren (in der DTD).

• Anschließend wird die Entity-Referenz

&ora;

im Dokument durch “Oracle 8.1.6” ersetzt.




Entity Reference:

-

��

��& - Entity Name -

��

��; -

In SGML ist das Semikolon “;” optional, wenn das folgende Zeichen nichtTeil des Entity-Namens sein kann (z.B. ein Leerzeichen). Wenn ein Zei-lenende dem Entity-Namen folgt, wird es geloscht. In XML ist das Semi-kolon “;” notig.

Entities konnen nur im Inhalt eines Elementes oder im Wert eines Attributesoder im Ersetzungstext fur ein anderes Entity verwendet werden. Man kannmit einem Entity also z.B. nicht den Elementtyp definieren oder den Nameneines Attributes.




• SGML und besonders XML stellen sicher, daß sich

durch “Expansion” einer Entity-Referenz (Ersetzen

durch den Inhalt des Entities) keine syntaktischen

Uberraschungen ergeben.Wenn die offnende Klammer “<” eines Tags, eines Kommentars,u.s.w. im Ersetzungstext fur ein Entity enthalten ist, muß auch diepassende schließende Klammer im Ersetzungstext des gleichen En-tities enthalten sein. Bei XML muß sogar das Element (auch mitdem schließenden Tag) vollstandig im Entity enthalten sein. XML Do-kumente sollen ja auch ohne Kenntnis der DTD verarbeitet werdenkonnen, der Ersetzungstext ist also eventuell gar nicht bekannt.

Wenn eine Entity-Referenz in einem Attributwert enthalten ist, werdeneventuelle Anfuhrungszeichen im Ersetzungstext nicht interpretiert,d.h. sie konnen nicht den Attributwert vorzeitig beenden.




• In XML sind die folgenden funf Entities vordefiniert

(um Zeichen mit spezieller Bedeutung leichter als

normale Daten eingeben zu konnen):

� & fur “&” (“ampersand”, “und”).

� < fur “<” (“less than”, “kleiner als”).

� > fur “>” (“greater than”, “großer als”).

� ' fur “ ’ ” (Apostroph).

� " fur “"” (“quotation mark”, Anfuhrungsz.).In SGML sind diese Entities nicht vordefiniert. Deswegen wird ausKompatibilitatsgrunden empfohlen, sie auch in einer XML DTD ex-plizit zu deklarieren.




• Entities sind in SGML/XML ein recht machtiges

Konzept. Sie konnen z.B. auch fur den Inhalt einer

Datei stehen.

Entities gelten in SGML/XML als physische Einheiten eines Doku-mentes, Elemente als die logischen Einheiten.

• Es gibt auch Parameter-Entities, die nur in DTDs

verwendet werden. Sie werden mit einem Prozent-

zeichen “%” statt einem “und”-Zeichen “&” ange-

sprochen.

Dies funktioniert nur in DTDs. Im eigentlichen Dokument-Inhalt hatdas Prozentzeichen keine spezielle Bedeutung.



Markierte Abschnitte (1)

• Angenommen, ein XML/SGML-Dokument soll ein

Teilstuck in einer anderen Syntax (als reinen Text)

enthalten. Eventuell enthalt dieses Stuck aber viele

Vorkommen der Spezialzeichen “<”, >”, “&”.

• Es ware sehr aufwendig, jedes Zeichen einzeln mit

einer Zeichen/Entity-Referenz zu codieren.

• Fur diesen Fall sind CDATA-Abschnitte gedacht. Sie

konnen die Zeichen “<”, “>” und “&” als normalen

Text enthalten (nicht als Markup interpretiert).

<![CDATA[...]]>



Markierte Abschnitte (2)

• CDATA Abschnitte kann man nicht schachteln.

Der einzige Markup, der in einem CDATA Abschnitt erkannt wird, ist dieEnde-Markierung “]]>”. Der Parser wurde den Beginn eines geschach-telten Abschnittes nicht bemerken, aber beim ersten Vorkommen derEnde-Markierung den gesamten Abschnitt beenden. Die ungewohnli-che Syntax wurde gewahlt, damit Ende-Markierungen nicht zufallig inden Daten vorkommen.

• CDATA Abschnitte konnen z.B. verwendet werden,

um Beispiele von XML/HTML Code in eine XML-

Datei einzufugen. In diesem Fall soll der Markup ja

nicht interpretiert werden.



Kommentare (1)

• Kommentare konnen verwendet werden, um Er-

klarungen fur den Leser der SGML/XML-Quelldatei

in das Dokument einzufugen.

• Kommentare werden von Programmen ignoriert,

die XML/SGML-Daten verarbeiten. Sie erscheinen

also nicht in der formatierten Ausgabe.

Der XML Standard erlaubt, daß ein XML Parser Kommentare an dasAnwendungsprogramm liefert, aber er verlangt das nicht.

• Ein Kommentar in SGML/XML hat die Form





Kommentare (2)

• Kommentare konnen sich uber mehrere Zeilen er-

strecken.

D.h. sie mussen nicht auf der gleichen Zeile geschlossen werden.

• Innerhalb eines Kommentars darf man nicht zwei

aufeinander folgende Bindestriche schreiben: “--”.

In SGML, erstreckt sich ein Kommentar eigentlich von “--” bis “--”.Er darf aber nur innerhalb von Markup Deklarationen verwendet wer-den. Eine Deklaration beginnt mit “<!” und endet mit “>” (sie darfansonsten leer sein). Das erklart die komplizierte Syntax fur den Kom-mentar. In SGML konnen Kommentare auch in richtigen Element-,Attribut- u.s.w. Deklarationen verwendet werden, in XML geht diesnicht. XML erlaubt nur “”. In SGML wurde “--” inner-halb des Kommentares den Kommentar beenden.



Kommentare (3)

• Offiziell sind Tags innerhalb von Kommentaren er-

laubt (uninterpretiert), aber sie verwirren manche

Browser.

Zumindest bei HTML-Dateien versuchen Browser Syntaxfehler zu kor-rigieren (bei XML/XHTML mussen sie eigentlich einen Fehler mel-den). Wenn sie ein Tag sehen, vermuten sie eventuell, daß der Be-nutzer die Kommentarende-Markierung vergessen hat.

• Man kann Kommentare uberall außerhalb von an-

derem Markup verwenden.

Also z.B. nicht in Tags.



Kommentare (4)

• Man beachte, daß Kommentare in HTML Seiten

dem Leser nicht wirklich verborgen sind:

� Sie werden zwar vom Web-Browser normalerwei-

se nicht angezeigt,

� aber der Benutzer kann den Menupunkt “View

Document Source” des Browsers wahlen.

Falls dies nicht vorhanden ist, konnte er die Seite auch ohne Brow-ser direkt mit telnet abrufen (siehe Kapitel uber HTTP).

Kommentare werden also nicht auf dem Web-Server ausgewertet(entfernt), sondern mit dem HTML Quelltext ausgeliefert. In ahn-licher Weise sind “versteckte Felder” in Formularen ungeeignet furgeheime Passworte und ahnliches.



Processing Instructions

• “Processing Instructions” sind Anweisungen an

Programme, die SGML/XML-Daten verarbeiten.

• Processing Instructions beginnen mit “<?” und en-

den mit “?>” (XML) bzw. “>” (SGML).

SGML ist stark parametrisiert, und man kann naturlich auch “?>” furden Parameter “pic” (processing instruction close) wahlen. Es gibtaber eine “Reference Concrete Syntax” mit der obigen Setzung.

• In XML identifiziert das erste Wort in der Proces-

sing Instruction das Programms, an die sich der

Rest der Anweisung wendet (“target”).

Andere Programme ignorieren die PI wie einen Kommentar.



XML Deklaration (1)

• XML Dokumente sollten mit einer XML Deklarati-

on beginnen, die die XML Version angibt:

<?xml version="1.0"?>

• Durch die explizite Angabe der verwendeten Versi-

on kann ein eventueller zukunftiger XML-Prozessor

in einen Kompatibilitatsmodus schalten, um alte

XML Dateien zu verarbeiten.

• Version 1.0 ist sehr verbreitet, und es wird empfoh-

len, sie zu verwenden, wenn man nicht die neuen

Moglichkeiten von Version 1.1 benotigt.



XML Deklaration (2)

• Da viele Standards auf der XML Syntax aufbauen,

sind großere Anderungen nicht zu erwarten.

• Auch die Unterschiede zwischen Version 1.0 und

Version 1.1 sind minimal.

Es gibt neue Auflagen der W3C Empfehlung fur XML 1.0, aber sie kor-rigieren nur Fehler oder stellen kritische Punkte klarer. Die W3C Emp-fehlung fur XML 1.0 wurde am 10.02.1998 veroffentlicht, eine zweiteAuflage erschien am 06.10.2000, die dritte Auflage der XML 1.0 Emp-fehlung erschien am 04.02.2004 zusammen mit der ersten Auflage derEmpfehlung fur XML 1.1. Die aktuelle, vierte Auflage der XML 1.0Empfehlung erschien am 16.08.2006 zusammen mit der zweiten Auf-lage der XML 1.1 Empfehlung. Beide wurden am 29.09.2006 nocheinmal geandert. [http://www.w3.org/XML/].



XML Deklaration (3)

• Anderungen von Version 1.0 zu Version 1.1:

� Mehr Zeichen sind in Namen zulassig.

In XML 1.0 wurden die gultigen Zeichen in Elementtypen etc.explizit aufgezahlt. Da der Unicode Standard noch erweitert wird,schien es nun besser, die verbotenen Zeichen aufzulisten. Zeichenwerden nur noch verboten, wenn es einen Grund dafur gibt.

� Zeilenenden von IBM Großrechnern unterstutzt.

� Die Regeln fur Steuerzeichen andern sich etwas.

Zeichen-Referenzen fur Steuerzeichen im Bereich x01–x1F sindnun erlaubt, Steuerzeichen im Bereich x7F–x9F (außer Leerplatz)mussen nun als Zeichen-Referenzen geschrieben werden.

� Normalisierung erlaubt binaren Vergleich.



XML Deklaration (4)

• Fur SGML Prozessoren ist die XML Deklaration

einfach eine Processing Instruction.

Alte Browser konnen dadurch aber verwirrt werden, weil sie nicht einenallgemeinen SGML Parser enthalten, sondern nur die in HTML ublicheSyntax verstehen. Moderne Browser unterstutzen naturlich XHTML.

• Die XML Deklaration ist (auch in XML Dateien)

optional (bei Verwendung von UTF-8 / UTF-16).

• Wenn man sie aber verwendet, muß sie ganz am

Anfang der XML Datei stehen.

Nicht einmal Leerplatz / Kommentare sind davor erlaubt. Der Grundist, daß sie auch zur Erkennung der externen Zeichen-Codierung dient.



XML Deklaration (5)

• XML Prozessoren mussen als Zeichen-Codierung

mindestens UTF-8 und UTF-16 von Unicode ver-

arbeiten konnen (UTF-8 beinhaltet ASCII).UTF-16 codierte Dateien mussen mit dem “Byte Order Mark” #xFEFF

beginnen. Dadurch ist eine automatische Unterscheidung von UTF-8moglich, sowie eine Erkennung der Bytereihenfolge der 16 Bit Zahlen.

• Fur andere Codes (z.B. ISO Latin 1) ist eine XML-

Deklaration mit der Angabe der Codierung notig:


Wenn die Codierung fur die in der XML Deklaration verwendetenZeichen (reines ASCII) mit UTF-8 kompatibel ist, kann der XMLProzessor das encoding lesen, ohne die genaue Codierung zu kennen.



DOCTYPE Deklaration (1)

• Fur jedes SGML-Dokument muß es eine DTD ge-

ben, die die Syntax des Dokumentes beschreibt.

Die DTD muß nicht explizit im Dokument genannt sein, sie kann auchin die Software (z.B. den Web Browser) eingebaut sein.

• In XML ist die DTD optional. Man unterscheidet

zwei Klassen von XML Dokumenten:

� Wohlgeformte Dokumente (“well-formed XML”)

erfullen die allgemeinen XML-Syntaxregeln.

� Valide Dokumente haben eine zugehorige DTD

und erfullen die Syntaxregeln dieser DTD.




• Die Prufung der Syntax eines XML-Dokumentes

bezuglich einer DTD heißt entsprechend “validie-

ren” des Dokumentes.

• Selbst wenn es eine DTD gibt, muß ein XML Pro-

zessor sie nicht lesen und das Dokument validieren.

Entsprechend unterscheidet die XML Spezifikation zwischen “valida-ting” und “non-validating XML processors”.

Im Gegensatz dazu benotigt die Syntaxanalyse fur SGML unbedingteine DTD, weil die Markup Minimierung (optionale Start- und End-Tags) davon abhangt.




• Der Verweis auf eine zugehorige DTD geschieht

am Anfang des Dokumentes (ggf. nach der XML

Deklaration und eventuell Kommentaren etc.):

<!DOCTYPE FEUERWERKSARTIKEL SYSTEM "fw.dtd">

<FEUERWERKSARTIKEL>...

</FEUERWERKSARTIKEL>

• Die Datei “fw.dtd” enthalt dann die Deklaration

von Elementen, Attributen, Entities.

• Der Dokument-Typ muß immer so heißen wie das

außerste Element (“document element”).




• Fur allgemein bekannte DTDs kann man auch einen

“Public Identifier” benutzen, in XML benotigt man

aber zusatzlich einen System Identifier (eine URI).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

"http://www.w3.org/TR/html4/strict.dtd">

<HTML>...

</HTML>

Typischerweise hat so ein System eine Konfigurationsdatei, in derPublic Identifier auf lokale Dateien mit den DTDs abgebildet werden(falls die Software nicht ohnehin auf eine ganz bestimmte DTD be-schrankt ist). Dann ware fur die Syntaxanalyse kein Netzwerk-Zugriffnotig, es wurde die lokale Datei benutzt.




• Man kann die DTD auch im Dokument selbst de-

finieren:

<!DOCTYPE FEUERWERKSARTIKEL [

<!ELEMENT FEUERWERKSARTIKEL ...>

...]>

<FEUERWERKSARTIKEL> ... </FEUERWERKSARTIKEL>

• Auch eine Mischung von beidem ist moglich:

<!DOCTYPE FEUERWERKSARTIKEL SYSTEM "fw.dtd" [...]>

Z.B. kann man im “internal subset” [...] Entity-Definitionen aus derDatei uberschreiben.




DOCTYPE Declaration:

- <!DOCTYPE��

��- Name

?

?- SYSTEM��

�� - SysID -

?

- PUBLIC��

��- PubID - SysID -

- [��

��- Declarations -

��

��] -

��

��> -



XML Dokument

• Ein XML Dokument besteht aus:

� Einer XML Deklaration (optional, empfohlen).

� Kommentaren, Processing Instructions, Leerplatz

(optional).

� Einer Dokumenttyp Deklaration (DOCTYPE, opt.).

� Kommentaren etc. (optional).

� Einem Element (“document element”, notig).

Darin geschachtelt alle anderen Elemente, Text, u.s.w.

� Kommentare etc. (optional).



Aufgabe

Welche Syntax-Fehler enthalt die folgende Datei?


<GradesDB3>

<student sid=’101’ first=’Ann’ last="Smith"

<result cat=’H’ eno = 1 points=10>

<result cat=’H’ eno =’1’ points=’8’>

<result cat=’M" eno ="1" points=’12’

>

</ student >



<ex cat=’H’ eno=’1’ note=’<em>difficult</em>’>

Rel&#97 tional Algebra</ex>

</Grades-DB>



Software (1)

• Although browsers are very generous with syntax

errors in HTML documents, they show all errors in

XML documents.

E.g. Internet Explorer, Firefox.

• They check only the syntax of well-formed XML,

they do not validate documents against a DTD.

• If no style sheet is given, the document tree is dis-

played (child nodes are indented under the parent).

It is possible to collapse/expand subtrees by clicking on the -/+ infront of the elements.



Software (2)

• Xerces from the Apache Software Foundation is an

example for a validating parser for XML (supporting

DTDs and XML Schema).

See [http://xerces.apache.org/]. It has a DOM and a SAX interfacefor accessing the parsed data. It comes with a test program domprint,which can be used for checking the syntax (it is an unparser, i.e. itoutputs the result of parsing again as XML, but probably differentlyformatted). There is a C++ and a Java version, and a Perl interfaceto the C++ version.

• There are also validation services on the web, e.g.

� [http://www.stg.brown.edu/service/xmlvalid/]

� [http://www.validome.org/xml/]



Overview

1. Introduction

2. XML Documents (Syntax)

3. Document Type Definitions (DTDs)

'

&

$

%4. DOCTYPE, XML Declaration

5. Entities, Notations, Marked Sections



Example

Simple DTD for a HTML-Subset:

<!ELEMENT html (head, body)>

<!ELEMENT head (title)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT body ((#PCDATA|p|em|ul)*)>

<!ELEMENT p ((#PCDATA|em|ul)*)>

<!ELEMENT em (#PCDATA)>

<!ELEMENT ul (li+)>

<!ELEMENT li ((#PCDATA|p|em|ul)*)>



Element-Type Declarations (1)

An Element-Type Declaration consists of:

• “<!” followed by the keyword “ELEMENT”.In SGML, one could define a different string instead of “<!”. Thisis the parameter MDO (“Markup Deklaration Open Delimiter”) inthe SGML declaration. Correspondingly, “>” is called MDC (“Mar-kup Declaration Close Delimiter”). XML is based on a fixed SGMLdeclaration, so one cannot change these delimiters.

• Name of the element type to be declared.Such names are officially called “Generic Identifiers”.

• Then one specifies what is permitted as content of

this type of elements (“content model”).

• “>”.



Element-Type Declarations (2)

Element-Type Declaration:

- <!ELEMENT��

��- Name - Content - >

��

��-

White space is required between “<!ELEMENT” and the name, and betweenthe name and the content specification. It is permitted but not requiredbetween content specification and the “>”.

Names in XML must start with a letter, an underscore “_” or a colon“:”, and can otherwise contain letters, digits, periods “.”, hyphens “-”,underscores “_”, colons “:”, or certain special Unicode characters. Namesstarting with “xml” in any capitalization are reserved, the colon is treatedspecially by the XML namespace standard.

The element type declaration is SGML is more complicated: There, alsospecifications for markup minimization are required (if the markup mini-mization parameter OMITTAG is set), “exclusions” and “inclusions” arepossible, several element types can be declared together, etc.



Content Specifications (1)

• The building blocks of content specifications are

� Names X of element types: This pattern mat-

ches exactly one element of type X, i.e. basically

<X>...</X>.

� The keyword #PCDATA: Pure textual data without

tags (but possibly character/entity references).

#PCDATA stands for “Parsed Character Data”. The text is syntac-tically analyzed in order to check that it does not contain tagsand in order to resolve entity and character references. In SGML(but not in XML) there is also “CDATA”, which is not syntacticallyanalyzed (like “verbatim” in LATEX). The use of #PCDATA in modelgroups is very restricted in XML, see below.




• One can specify the optionality/multiplicity of ele-

ments and groups by attaching occurrence indica-

tors:

� A?: Optional, non repeatable (0 or 1 time).

� A*: Optional, repeatable (0 or more times).

� A+: Required, repeatable (1 or more times).




• Content specifications can be connected with

� (A | B): “A or B”.The content must match A or B.

� (A , B): “First A, then B” (“A followed by B”).A prefix of the content must match A, the rest B.

• In SGML, there is also (not supported in XML):

� (A & B): “A and B”.A and B must both appear, but in arbitrary sequence. This isequivalent to ((A,B) | (B,A)). Therefore, & is not strictly ne-cessary. But rewriting an “and” with many components in thisway becomes clumsy. There are also restrictions because of thedeterministic parsing requirement, see below.




• Model groups consisting of more than two com-

ponents are also possible:

� (A1|...|An): “Alternative”/“Choice”

(one of the Ai).

� (A1,...,An): “Sequence”

(all Ai in the given sequence).

• The Ai are

� An element type (possibly with ?/*/+).

� #PCDATA (in XML with restrictions, see below).

� A nested model group (possibly with ?, *, +).




• A content specification (“content model”) is

� A model group (possibly only of one element),Element types must always be specified within parentheses.XML has special restrictions for mixed content, see below.

� the keyword EMPTY: No content permitted.

� The keyword ANY: Character data and elements

of arbitrary type.

• SGML has also CDATA and RCDATA.For CDATA, even the special characters <, >, & can be used. They are notinterpreted. RCDATA is the same, but & is interpreted (i.e. one can usecharacter/entity references). In XML, one can use a CDATA-Section(see below) to include arbitrary text data in an XML document.




Content:

- Model Group -

- ?��

��-

- *��

��-

- +��

��-

6

- Text/Mixed -

-

��

��EMPTY -

-

��

��ANY -

6




Text/Mixed:

- (��

��- #PCDATA

��

�� - )

��

�� -

- (��

��- #PCDATA

��

�� - )

��

��- *

��

��

6

6

Element Type � |��

��

• In XML, the only content models that can contain

#PCDATA are (SGML has no such restriction):

� (#PCDATA)

� (#PCDATA | Element-Type | ... | Element-Type)*




Model Group:

- (��

�� - Group Element - )

��

�� -

�|��

��

6 6

- (��

�� - Group Element - )

��

��-

�,��

��

6




Group Element:

- Element Type -

- Model Group

6

- ?��

��-

- *��

��-

- +��

��-

6




• In SGML and XML, the possible occurrence of whi-

te space is defined by the grammar.

• It is permitted but not required between each two

tokens (“word symbols”) in content models, except

before the occurrence indicators “?”, *”, “+”.

• The keyword “#PCDATA” requires the symbol “#”

(RNI, “Reserved Name Indicator”) in order to di-

stinguish it from an element type named “PCDATA”.

Other keywords like “EMPTY” do not use it, since in the element typedeclaration, they appear outside of parentheses, while user-definednames must appear inside parentheses.




• In SGML and in XML, content models must be not

ambiguous. E.g. the following is forbidden:

<!ELEMENT E ((A, B?), B)>

When the parser has read an A and sees a B, it is not

clear whether this is the optional B in the middle or

already the required B at the end.

The parser could solve this problem by looking ahead to see whetherafter the B in question there is another B. However, the SGML standardexplicitly states: “an element or character string that occurs in thedocument instance must be able to satisfy only one primitive contenttoken [in the content model] without looking ahead in the documentinstance.” A primitive content token is an element type or #PCDATA.




• Another example for an ambiguous content model:

<!ELEMENT E ((A, B) | (A, C))>

When the parser sees the element A, it does not

know which path to follow in the content model.

• This requirement simplifies the task of checking the

input with respect to a given DTD.There are standard techniques for generating a nondeterministic finiteautomaton for a given regular expression. Normally, one would needto translate this into a deterministic automaton, which can lead toan exponential increase in the number of states. SGML and XML arerestricted in such a way that the constructed automaton is alreadydeterministic.



Attribute Declarations (1)

• Example (symbol used for marking list items):

<!ATTLIST UL type (disc|square|circle) #IMPLIED>

In HTML 4.01 Strict this attribute was removed.

• Several attributes (of one element type) can be

declared in a single ATTLIST command.

• E.g. some attributes of images in HTML:

<!ATTLIST IMG src CDATA #REQUIRED

alt CDATA #REQUIRED

width CDATA #IMPLIED

height CDATA #IMPLIED>




- <!ATTLIST��

��- Element Type

? - Name - Data Type - Default - >��

��-

6

• For each attribute, three things are defined:

Name, data type, and default value.White space is required between each two components of the ATTLIST

command, except before the final “>”, where it is optional.




• The same attribute name can appear in an ATTLIST

declaration only once.This is clear: There cannot be conflicting definitions for an attributein the same declaration.

• If there are several ATTLIST declarations for the sa-

me element type, they are merged. The first decla-

ration for an attribute becomes effective, all other

declarations for the same attribute are ignored.This might be useful if a DTD is constructed in several pieces. It ishowever recommended (required in SGML?) that for every elementtype, there is only one ATTLIST declaration which defines all its attri-butes.



Attribute Data Types (1)

• E.g. (yes|no): Enumeration type.

The attribute value must be one of the listed values. Each value isa “name token” (NMTOKEN), i.e. a sequence of characters thatcan appear anywhere in identifiers (letters, digits, and certain specialcharacters). E.g. a sequence of digits would be valid. In SGML, itis forbidden that same enumeration type value is used for two attri-butes of the same element type. In XML, this is recommended “forinteroperability”.

• CDATA: Sequence of arbitrary characters.

The character “&” is interpreted, i.e. one can use character and entityreferences in the attribute values. In XML, “<” is forbidden in attri-bute values (so that missing quotes are easier found), and “>” is notinterpreted (treated as data). In SGML, “<” and “>” are valid, butnot interpreted. Thus, attribute values still cannot contain elements.




• ID: A name that uniquely identifies this element

(within the entire document).

The syntax is the same as for element type names (sequence of lettersand digits plus _, :, ., -, starting with letter or _, :, .). Two elementsmust not have the same value for an attribute of type ID. This evenholds for elements of different type. The same element type cannothave two attributes of type ID. One should use the same name for allattributes of type ID, and the attribute name “ID” is very common.

• IDREF: A name that appears as value of an ID-

attribute somewhere in the document.

• IDREFS: List of IDREF-values.

The single values are separated by white space.




• NMTOKEN: Sequence of name characters.An arbitrary sequence of letters, digits, “_”, “-”, “.”, and “:”.

• NMTOKENS: List of NMTOKEN-values.

• ENTITY: Name of an entity.Entities are a kind of macros or include files (see below). An attributeof type ENTITY takes as value the name of a declared unparsed entity.

• ENTITIES: List of ENTITY-values.

• NOTATION (N1|...|Nm): One of the notations Ni.The Ni must be declared as notations (data formats). Only one at-tribute of an element type can have the type NOTATION. This attributedefines the format of the content of the element.




• In summary, XML supports the following attribute

data types:

� Enumeration types,

� CDATA,

� ID, IDREF, IDREFS,

� NMTOKEN, NMTOKENS,

� ENTITY, ENTITIES,

� enumerations of notations.

• SGML has in addition NAME, NAMES, NUMBER, NUMBERS,

NUTOKEN, NUTOKENS. E.g. NUMBER: sequence of digits.



Default Values (1)

• One must specify what should happen if an element

of the type has not defined a value for the attribute.

• One possibility is to specify a default value:

<!ATTLIST UL type (disc|square|circle) "disc">

The quotation marks around the default value are not required inSGML, but they are required in XML. This is a bit inconsistent, sin-ce in accordance with SGML, there are no quotation marks in theenumeration of possible values. In SGML, attribute values that areNMTOKENS do not need quotes.

• Then the tag <UL> in the document is equivalent to

<UL type="disc">.



Default Values (2)

• Instead of a default value, one can also specify:

� #IMPLIED: The attribute is optional.I.e. the default value is a “null value” different from all possiblenormal values. The name for the keyword was chosen because itis assumed that the application program can compute a value forthe attribute. E.g. a chapter number is usually the number of thelast chapter plus 1.

� #REQUIRED: An attribute value must be specified.

� #FIXED "Value": The attribute can have only this

single value that is specified in the DTD.This is e.g. used when many/all element types have an attribu-te with the same name, and for each element type a (possiblydifferent) value is declared in the DTD.



Exercise (1)

Please find syntax errors:


<!DOCTYPE GradesDB4 [ 

<!ELEMENT GradesDB4 (STUDENT, RESULT)*>

<!ELEMENT STUDENT RESULT+>

<!ATTLIST STUDENT FIRST CDATA #REQUIRED

LAST CDATA #REQUIRED>

<!ELEMENT RESULT #EMPTY>

<!ATTLIST RESULT EX_ID IDREF #REQUIRED

POINTS NMTOKEN #REQUIRED>

<!ELEMENT EXERCISE #PCDATA>

<!ATTLIST EXERCISE ID ID #REQUIRED>]> 



Exercise (2)

Please validate against DTD on last slide:

<GradesDB4>

<student sid=’101’ first=’Ann’ last=’Smith’>

<email>[email protected]</email>

<result ex_id=’H1’ points=’A+’/>

<result ex_id=’2’ points=’8’/>

<result ex_id=’M1’ points=’12 points’/>

</student>

<student first=’Maria’ last=’Brown’/>

<exercise id=’H1’>Relational Algebra</exercise>

<exercise id=’2’>SQL</exercise>

</GradesDB4>



Exercise (3)

Please develop a DTD for this document:


<smallbusiness>

<product id=’P01’ name=’Apple’ price=’0.40’>

Really <em>delicious</em>Apples!</product>

<product id=’P02’ name=’Banana’ price=’0.50’>

The best bananas!</product>

<order id=’R100’ customer=’Ann Smith’/>

<item prodid=’P01’/>

<item prodid=’P02’ quantity=’5’/> </order>

<order id=’R100’ customer=’Maria Brown’/>

<item prodid=’P01’ quantity=’3’/> </order>

</smallbusiness>