Registriert seit: 29. Mai 2002
DTD – Document Type Definition
- Einleitung:
Den Meisten wird das Kürzel "DTD" vielleicht einmal aufgefallen sein, wenn sie sich den Quelltext einer HTML-Datei angesehen haben. Diese beginnt ja oft mit einer Zeile, wie:
Code:
<!DOCTYPE HTML PUBLIC "-// W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
oder auch nur
Code:
<!DOCTYPE HTML PUBLIC "-// W3C//DTD HTML 4.01 Transitional//EN">
Jetzt kann man sagen: "Na schön, ist nun einmal so."
Oder man überlegt: "Na schön, aber wozu ist das gut?"
Da ich mir ein Tool für HTML-Dateien schreiben wollte, bin ich natürlich bei der Frage hängengeblieben.
Es war recht schnell zu ermitteln, wofür DTD steht, nämlich: Document Type Definition.
In einer DTD wird angegeben, wie das folgende Dokument auszuwerten ist. Es handelt sich um eine Textdatei, die die Bestandteile und deren Zusammenhänge definiert. Um einmal bei HTML zu bleiben:- Welche Tags gibt es?
- Welche Attribute haben diese?
- Welche Werte dürfen/müssen diese Attribute haben?
- Wie können/dürfen die Tags verschachtelt sein?
- ...
Mit einer DTD kann man natürlich auch andere Dateien deklarieren, solange eine Anwendung einen Parser für diese Deklarationen hat, was eigentlich für alle XML-Parser gelten sollte, da mit DTDs XML-Dateien deklariert werden können. HTML ist wohl nur das Paradebeispiel, da hier die Verwendung einer Document Type Definition am auffälligsten ist.
Nachdem ich mir nun also einmal eine DTD heruntergeladen, und angesehen hatte (z.B.  HTML 4.01 Transitional") stand ich vor dem Problem die einzelnen Bestandteile einer DTD, und deren Zusammenspiel, zu verstehen.
Die erste Anlaufstelle hierfür war dann SELFHTML. Leider war es mir hiermit aber nicht möglich, alle Bestandteile zu klären, die diese Datei enthält. Unter der Annahme, dass die loose.dtd wohl einen gültigen Inhalt hat, sie stammt immerhin vom W3C, und dient als Vorlage für die Verarbeitung von HTML-Dateien, habe ich mich dann auf die Suche nach einer vollständigen Dokumentation, bzw. Referenz, gemacht.
Es gab zwar viele Fundstellen, in denen immer mal wieder etwas Neues auftauchte, nur leider erwies sich keine Quelle als komplett. Selbst beim W3C konnte ich hierzu nicht fündig werden, also habe ich mich dann mal daran gemacht, die Informationen zusammenzufassen.
Alles konnte ich leider nicht eindeutig klären, aber das Wesentliche sollte durch diese Referenz abgedeckt werden.
Anmerkung:
An einigen Stellen ist bekannt, dass es noch Klärungsbedarf gibt.
Diese sind durch
//TODO: Was noch zu klären ist
gekennzeichnet (ggf. mehrzeilig)
- Allgemein:
- Wo auch immer "Leerzeichen" als Trennzeichen auftritt, ist damit Whitespace gemeint (Tab (#09), LF (#10), CR (#13), Blank (#32)).
- Meistens muss bei Element und Attributnamen die Gross-/Kleinschreibung beachtet werden (Name <> name).
- Die Zuweisung von Werten an Attribute kann in '' oder "" eingschlossen werden. Hierbei dürfen die Zeichen ' und " nicht gemischt werden. Wenn also der Wert hinter einem ' beginnt, so darf er nicht durch " beendet werden.
- Schlüsselworte müssen grossgeschrieben werden
- Eine Deklaration beginnt immer mit <!SCHLÜSSELWORT ( <! müssen unmittelbar aufeinander folgen. Ob vor dem noch "Leerzeichen" stehen dürfen, liess sich nicht ermitteln, ich würde es aber, zur Sicherheit, einmal annehmen, da bei bedingten Abschnitten auch noch ein spezielles Zeichen vor dem SCHLÜSSELWORT steht.
- Eine Deklaration endet immer mit einem >.
Für dieses Dokument gilt:- Formatierung für alles, was mit DTD zu tun hat:
- Style: Fett
- Farbe: Schwarz
- bei Schlüsselworten:
- bei Bezeichnern:
- bei Werten:
- bei Typen
- Optionale Inhalte werden in [ ] eingeschlossen dargestellt. Da es ein paar Stellen gibt, in denen die eckigen Klammern auch für eine DTD Bedeutung haben, ist dieses dort gesondert beschrieben.
- Gültige Bezeichner:
Ein gültiger Bezeichner darf aus folgenden Zeichen bestehen:
'A'..'Z','a'..'z','0'..'9','_','-','.'
Bei Namensräumen ist auch ':' erlaubt.
Ein gültiger Bezeichner darf nicht mit '0'..'9', 'xml' oder 'XML' beginnen.
Meistens muss auf die Gross-/Kleinschreibung geachtet werden.
Hierzu gibt es eine nähere Erklärung beim Schlüsselwort DOCTYPE.
- Deklaration beginnen (DOCTYPE)
Code:
[b]<![color=blue]DOCTYPE[/color] [color=darkorange]rootelement[/color] [color=blue]SYSTEM[/color] "[color=red]system-ID ( URI)[/color]">
<![color=blue]DOCTYPE[/color] [color=darkorange]rootelement[/color] [color=blue]PUBLIC[/color] "[color=red]public-ID ( URI)[/color]" ["[color=red]system-ID ( URI)[/color]"]>
<![color=blue]DOCTYPE[/color] [color=darkorange]rootelement[/color] [
<![color=blue]--[/color]
Deklarationen für das folgende Dokument.
[color=blue]--[/color]>
]>[/b]
- Allgemein:
Das Schlüsselwort DOCTYPE wird nicht in einer DTD-Datei zu finden sein, da es ja die Deklarationen für ein Dokument enthält, bzw. auf eine DTD verweist.
Man wird es also zu Beginn einer Datei finden, die sich mit Hilfe einer DTD verarbeiten lässt.
- rootelement:
Dies ist der Bezeichner, des ersten Elementes des Dokumentes. Bei HTML-Dateien findet man hier, z.B., HTML, bei XHTML hingegen html.
Bezüglich der Schreibweise (gross oder klein) ergibt sich folgende Vermutung:
Wird der Name des Rootelementes grossgeschrieben, so wird bei der Verarbeitung des Dokumentes die Gross-/Kleinschreibung der Tags (ELEMENT) und Attribute (ATTLIST) nicht beachtet.
Wenn der Name kleingeschrieben wird, so müssen alle Tag- und Attributnamen so geschrieben werden, wie es die jeweilige Deklaration vorgibt. Dies bezieht sich ausschliesslich auf Tags und Attribute, nicht auf Entitities (ENTITY), da ja jeder Browser in der Lage ist Ä (Ä) und ä (ä) zu unterscheiden.
Leider konnte ich hierfür keine Quelle finden, aber es passt zu der Art und Weise, was für HTML bzw. XHTML zulässig ist.
- PUBLIC, SYSTEM
Siehe: "Externe Referenzen"
- Entities (eine Art Makro) deklarieren(ENTITY)
Code:
[b]<![color=blue]ENTITY[/color] [%] [color=darkorange]Name[/color] [color=red]Wert[/color]>
<![color=blue]ENTITY[/color] [%] [color=darkorange]Name[/color] [color=blue]SYSTEM[/color] "[color=red]system-ID ( URI)[/color]" [[color=blue]NDATA[/color] [color=darkorange]Datentyp[/color]]>
<![color=blue]ENTITY[/color] [%] [color=darkorange]Name[/color] [color=blue]PUBLIC[/color] "[color=red]public-ID ( URI)[/color]" ["[color=red]system-ID ( URI)[/color]"] [[color=blue]NDATA[/color] [color=darkorange]Datentyp[/color]]>[/b]
- Allgemein:
Hiermit kann man benannte Werte deklarieren. Wenn nicht auf externe Daten verwiesen wird (PUBLIC, SYSTEM), funktionieren sie dann so, wie #define-Makros in C. Man kann sie anlegen für den Gebrauch innerhalb der DTD, oder für den Gebrauch innerhalb des mit der DTD zu verarbeitenden Dokumentes.
ENTITY darf innerhalb einer DTD beliebig oft vorkommen, und muss vor der ersten Verwendung deklariert werden. Es ist auch eine Verschachtelung möglich, da man innerhalb des Wertes auch wieder Entities verwenden kann.
- Name
Muss ein gültiger Bezeichner sein.
Wird vor dem Namen ein % angegeben, so handelt es sich um eine Parameter-Entity, ansonsten um eine Allgemeine. Parameter-Entities können nur innerhalb der DTD verwendet werden.
Parameter-Entities werden über %Name; angesprochen, allgemeine über &Name;
Das letztere dürfte auch schon durch HTML-Dateien bekannt sein, z.B., durch für non-breaking space. Diese ENTITY ist in der "http://www.w3.org/TR/html4/HTMLlat1.ent" deklariert, die, z.B., wiederum in die "http://www.w3.org/TR/html4/loose.dtd" geladen wird.
Eine allgemeine ENTITY wird in der Form &Name; auch innerhalb von #PCDATA, bzw CDATA erkannt, und ausgewertet.
//TODO: Wirklich auch in CDATA? Wäre unlogisch, da CDATA ja nicht
// geparst wird.
- PUBLIC, SYSTEM:
Siehe: Externe Referenzen
- Wert:
Der Wert wird immer in "" eingeschlossen.
Beim Einfügen werden diese dann nicht mit eingefügt. Sind hier also weitere Entitities enthalten (&entity;) so werden diese, im weiteren Verlauf, auch interpretiert.
- NDATA Datentyp
Bei einer Angabe von NDATA Datentyp, werden die externen Daten nicht vom DTD-Parser aufbereitet, und an die Anwendung weitergegeben, sondern die Anwendung muss dieses, mit Hilfe der NOTATION Datentyp, selber erledigen.
- Beispiele:
Eine Include-Datei einbinden:
Code:
[b]<![color=blue]ENTITY[/color] % [color=darkorange]Meine.Externen.Daten[/color] [color=blue]SYSTEM[/color] "[color=red]Mehrfach.txt[/color]">
%[color=darkorange]Meine.Externen.Daten[/color];[/b]
Es wird der Inhalt der Datei Mehrfach.txt eingefügt.
Lässt man hier SYSTEM weg, so wird nur der Text Mehrfach.txt eingefügt, was dann zu einem Fehler führt.
Man könnte auch Schlüsselworte damit ersetzen, was für bedingte DTDs sinnvoll sein kann.
Code:
[b]<![color=blue]ENTITY[/color] % [color=darkorange]Werte[/color] "[color=red]links[/color],[color=red]rechts[/color],[color=red]oben[/color],[color=red]unten[/color]">
<![color=blue]ELEMENT[/color] [color=darkorange]Richtung[/color] (%[color=darkorange]Werte[/color]; )>[/b]
wird bei der Verarbeitung zu
Code:
[b]<![color=blue]ELEMENT[/color] [color=darkorange]Richtung[/color] ([color=red]links[/color],[color=red]rechts[/color],[color=red]oben[/color],[color=red]unten[/color])>[/b]
Die Verwendung ohne % in der Deklaration wurde bereits weiter oben erklärt.
- Elemente (Tags) deklarieren (ELEMENT)
Code:
[b]<![color=blue]ELEMENT[/color] [color=darkorange]Name[/color] [Flags] [color=red]Inhalt[/color]>[/b]
- Allgemein:
Mit werden die Tags eines Dokumentes deklariert, z.b. <html>
Es wird definiert, welcher Inhalt (weitere Tags) enthalten sein können, oder auch müssen, und auch in welcher Reihenfolge diese auftreten müssen.
Ausserdem kann man, optional, angeben, ob das Tag angegeben werden muss.
Leere Elemente (Inhalt = EMPTY) werden mit <Name/> als Endtag versehen, die übrigen bekommen das Endtag </Name>
- Name
Ein gültiger Bezeichner
- Flags
- -
Start- und Endtag sind erforderlich
- O
Starttag ist erforderlich, Endtag darf entfallen
O O
Start- und Endtag dürfen entfallen. Fehlt das Starttag, muss das Endtag auch weggelassen werden
- Inhalt
- Der Inhalt besteht aus ELEMENTEN, #PCDATA, EMPTY oder ANY
- EMPTY
Kein Inhalt (Beispielsweise
)
- ANY
Alle Elemente dürfen vorkommen (incl. #PCDATA)
- ELEMENT, #PCDATA
Wird keines der Schlüsselworte EMPTY oder ANY angegeben, so muss eine Inhaltsliste, in () eingeschlossen, angegeben werden. Es ist auch möglich mehrere Inhaltslisten kombinieren, indem man eine, oder mehrere, weitere Listen mit + oder – hinter die bestehende schreibt.
Die Verwendung von +/- ist interessant, wenn man Inhaltslisten mit ENTITY deklariert, die lange Listen enthalten, und man mal ein paar Elemente zusätzlich oder weniger benötigt.
//TODO: Gesichert ist, dass +/- bei Auswahllisten funktioniert
// (|), aber wie steht es mit Listen die eine Reihenfolge
// enthalten?
// Angenommen wird, dass es auch bei Reihenfolgen so ist.
- Inhaltsliste
Besteht die Inhaltsliste aus mehr als einem ELEMENT, so müssen die Elemente mit , oder | getrennt werden, ausserdem ist es möglich als Element wiederum eine Inhaltsliste anzugeben.
Wird mit , getrennt, so muss die Reihenfolge der Elemente eingehalten werden, bei | handelt es sich um eine Auswahlliste, es darf dann nur eines der Elemente angegeben werden.
Man kann auch angeben, wie oft ein Element, oder eine Inhaltsliste vorkommen muss, bzw. darf. Hierzu werden [b]'?','*'[b] und '+' verwendet.
'?' => Kommt höchstens einmal vor (darf entfallen)
'*' => Kommt beliebig oft vor (darf entfallen)
'+' => Kommt beliebig oft vor (mindestens einmal)
Wenn '?','*' oder '+' nicht angegeben werden, so muss das Element genau einmal enthalten sein.
Soll #PCDATA Bestandteil des Inhaltes sein, so muss es entweder alleine stehen (#PCDATA), oder an erster Stelle einer Auswahlliste stehen.
- Beispiele:
(Element1)
Element1 muss genau einmal enthalten sein
(Element1,Element2)
Element1 und Element2 müssen enthalten sein, und zwar genau in dieser Reihenfolge.
(Element1 | Element2)
Eines der beiden Elemente darf vorkommen.
(Element1?,Element2*)
Element1 darf einmal vorkommen, kann aber entfallen, Element2 darf beliebig oft vorkommen, darf aber auch entfallen.
Wenn beide Elemente vorkommen, muss die Reihenfolge eingehalten werden.
(Element1?,Element2*)+
Wie (Element1?,Element2*), aber die gesamte Kombination darf beliebig oft vorkommen (mindestens einmal).
(Element1,(Element2 | Element3),Element4)
Element1 und Element4 müssen vorkommen, aber zwischen den beiden steht nur Element2 oder ]Element3, keinesfalls beide.
(Element1 | Element2 | Element3)*
Hier hat man nun, im Prinzip eine wahlfreie Liste, da nur eines der Elemente vorkommen darf, aber das beliebig oft hintereinander.
(Element1 | Element2)*+(Element3|Element4)
Dieser Inhalt beginnt mit einer wahlfreien Liste, die um Element3 und Element4 ergänzt wird. Diese Deklaration ist identisch mit:
(Element1 | Element2 | Element3 | Element4)
(Element1 | Element2 | Element3)+-(Element2)
Diese Deklaration ist identisch mit:
(Element1 | Element3)+
- Attribute für ELEMENTdeklarieren (ATTLIST)
Code:
[b]<![color=blue]ATTLIST[/color] [color=darkorange]Element[/color]
[color=darkorange]AttributName1[/color] [color=green]Typ1[/color] [color=red]DefaultWert1[/color]
[color=darkorange]AttributName2[/color] [color=green]Typ2[/color] [color=red]DefaultWert2[/color]
[color=darkorange]AttributNamen[/color] [color=green]Typn[/color] [color=red]DefaultWertn[/color] >[/b]
- Allgemein:
Mit Attributen können Elemente um weitere Angaben ergänzt werden.
Im Dokument müssen die Attributewerte in '' oder "" eingeschlossen werden.
- Element
Der Name des Elementes, zu denen die Attributliste gehört.
Hier darf auch eine Liste angegeben werden, wenn verschiedene Elemente die gleichen Attribute bekommen sollen.
Die Liste muss dann in der Form (Element1 | Element2 | Element3) angegeben werden.
//TODO: Kann so eine Liste auch mit +/- ergänzt/gekürzt werden,
// wie bei ELEMENT?
// Es ist anzunehmen, dass dies geht
- Attributename
Ein gültiger Bezeichner. Er muss innerhalb der Liste eindeutig sein.
- Typ
- Wertliste (Wert1 | Wert2 | Wert3)
Mögliche Werte für das Attribut
- CDATA
Siehe: CDATA
- ID
Dokumentenweit eindeutiger Wert.
Erlaubte Zeichen 'A'..'Z','a'..'z','0'..'9','_','-','.',':'
Muss mit einem Buchstabem beginnen.
- IDREF
Verweis auf eine ID.
- IDREFS
Liste mit Verweisen auf ID.
Einzelne IDs werden durch Leerzeichen getrennt.
- NMTOKEN
Wie ID, muss aber nicht eindeutig sein, und muss auch nicht mit einem Buchstaben beginnen.
- NMTOKENS
Eine Liste mit NMTOKEN, getrennt durch Leerzeichen.
- ENTITY
Name einer Entity
- ENTITIES
Liste von ENTITY, getrennt durch Leerzeichen.
- NOTATION (Notationname1 | Notationname2 | Notationnamen)
Notationname ist der Bezeichner einer NOTATION der Verarbeitungshinweise für Datentypen enthält.
- xml:
Vordefinierter xml-Name. Achtung: Der : gehört mit zum Typ.
- DefaultWert
- [#DEFAULT] "Wert"
Standardwert für das Attribut, wenn es nicht angegeben wird.
- #IMPLIED
Das Attribut kann angegeben werden, muss aber nicht.
- #REQUIRED
Das Attribut muss angegeben werden
- #FIXED "Wert"
"Wert" muss als Wert angegeben werden, unabhängig davon, ob eventuell andere möglich wären (z.B. eine Wertliste, oder Freitext, wie CDATA)
//TODO: Impliziert das, dass dieses Attribut #REQUIRED ist?
- Notationen deklarieren (NOTATION)
Code:
[b]<![color=blue]NOTATION[/color] [color=darkorange]Datentyp[/color] [color=blue]SYSTEM[/color] "[color=red]system-ID ( URI)[/color]">
<![color=blue]NOTATION[/color] [color=darkorange]Datentyp[/color] [color=blue]PUBLIC[/color] "[color=red]public-ID ( URI)[/color]" ["[color=red]system-ID ( URI)[/color]"]>[/b]
- Allgemein:
Mit NOTATION kann man Datentypen deklarieren.
Sie sollte auf eine Beschreibung, oder ein Tool referenzieren, mit deren Hilfe die Anwendung den Datentyp verarbeiten kann.
- Datentyp
Eine Bezeichnung für den Datentyp, z.B. gif, oder GifImage, um anzugeben, dass die Beschreibung für eine Gif-Datei gemeint ist. Die Datentyp-Bezeichnung dient nur dazu einen sprechenden Namen zu haben, um die Beschreibung referenzieren zu können, sie hat nichts mit dem tatsächlichen Datentype zu tun.
- PUBLIC, SYSTEM
Siehe: Externe Referenzen
- Kommentare(--)
Extern:
Code:
[b]<![color=blue]--[/color] Kommentar [color=blue]--[/color]>[/b]
Intern:
Code:
[b][color=blue]--[/color] Kommentar [color=blue]--[/color][/b]
Extern:
Er wird in <!-- --> eingeschlossen, wobei zwischen <!-- und Kommentar, sowie zwischen Kommentar und --> beliebig viele (0-n) Leerzeichen stehen dürfen.
Extern meint: Der Kommentar befindet sich ausserhalb weiterer Tags der DTD, ist also als eigenständiges Tag zu betrachten.
Intern:
Intern meint: Der Kommentar befindet sich innerhalb eines Tags. Beispielsweise kann man hiermit die einzelnen Attribute einer ATTLIST kommentieren.
Innerhalb eines internen Kommentares darf natürlich die Zeichenfolge -- nicht auftauchen, da dies als Kommentarende interpretiert werden würde.
- Bedingte Abschnitte(INCLUDE|IGNORE)
Code:
[b]<![[color=blue]INCLUDE[/color][ Deklarationen ]]>
<![[color=blue]IGNORE[/color][ Deklarationen ]]>[/b]
- Allgemein:
Hiermit lassen sich bedingte Abschnitte innerhalb einer DTD deklarieren, wobei INCLUDE indirekt immer gegeben ist, wo ein Abschnitt nicht explizit durch IGNORE ausgeschlossen wird.
Wichtig:
Die eckigen Klammern stehen hier nicht für "optional", sondern sind Bestandteil des Abschnittes, und müssen mitgeschrieben werden.
- INCLUDE
Deklarationen, die sich innerhalb eines INCLUDE Abschnites befinden, werden mit verarbeitet.
- IGNORE
Alles, was sich innerhalb des IGNORE-Abschnittes befindet, wird als Kommentar betrachtet, und ignoriert.
Hiermit kann man, beispielsweise, Deklarationen vorbereiten, die erst später enthalten sein sollen, oder, zum Testen, unterschiedliche Deklarationen einbauen, und die jeweils zu testende aktivieren (INCLUDE).
- Beispiel:
Durch die Verwendung von Entities kann man das Einbinden, bzw. Weglassen bestimmter Deklarationen steuern, wie, z.B., mit Hilfe von {$DEFINE ...} in Delphi oder #define ... in C.
Code:
[b]<![color=blue]ENTITY[/color] % [color=darkorange]Debug_Data[/color] "[color=blue]INCLUDE[/color]">
<![%[color=darkorange]Debug_Data[/color];[
<![color=blue]--[/color]
Deklarationen, die nur für das Debuggen benötigt werden
[color=blue]--[/color]>
]]>[/b]
Wenn man hier nun den Wert von Debug_Data auf IGNORE ändert, so würde der folgende Abschnitt nicht mehr verarbeitet werden.
- Externe Referenzen (SYSTEM, PUBLIC)
Code:
[b][color=blue]SYSTEM[/color] "[color=red]system-ID ( URI)[/color]"
[color=blue]PUBLIC[/color] "[color=red]public-ID ( URI)[/color]" ["[color=red]system-ID ( URI)[/color]"][/b]
- Allgemein:
Der Wert verweist auf eine externe Quelle.
Extern meint hier, dass sich die referenzierten Daten ausserhalb der DTD befinden.
Die zugehörigen IDs sollten eigentlich in der Form einer URI (Uniform Resource Identifier) vorliegen, dies scheint aber, wenn man sich mal das RFC 3986 Dokument (http://tools.ietf.org/html/rfc3986) anschaut eher als Idee anzusehen sein, denn eine übliche public-ID wäre "-//W3C//DTD XHTML 1.0 Transitional//EN" für ein XHTML 1.0 Dokument. Ich konnte keinen Weg finden, diese entsprechend aufzulösen.
I.d.R. wird man eine Liste von möglichen public-IDs benötigen, um diese entsprechend interpretieren zu können.
Bei system-IDs sieht es etwas besser aus. Mit diesen wird oft der Pfad zu einer Datei angegeben (z.B. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd").
Es ist auch eine lokale Datei möglich. Ausserdem kann man als system-ID auch einen Mime-Typ (siehe RFCs: 2045, 2046 und 2077) angeben, dies speziell bei NOTATION.
- public-ID (URI)
Eine öffentlich zugängliche Quelle, i.d.R. in Form einer ID
Um eine solche ID verarbeiten zu können, muss sie bekannt sein, so dass das Programm weiss, wie damit umzugehen ist.
So gesehen handelt es sich nicht wirklich um eine externe Referenz, da man ja, anhand der ID, intern schon wissen muss, wie sie zu interpretieren ist.
- system-ID (URI)
Meistens wird hier der Pfad zu einer Datei angegeben. Dies kann eine lokale Datei sein, oder auch eine über das Internet erreichbare.
Bei einer lokalen Datei, ist ein relativer Pfad als relativ zur Datei anzusehen, in der sich der Pfad befindet.
- Freitext (CDATA/#PCDATA)
- CDATA (Character Data)
Dieser String wird so übergeben, wie er ist, und nicht vom Parser verarbeitet.
Spezielle Zeichen (z.B. < ) werden nicht als solcher erkannt und ausgewertet.
Allgemeine- und Parameter-Entities werden allerdings aufgelöst.
//TODO: Noch einmal prüfen, ob bei CDATA Entities aufgelöst
// werden. Es gibt hier widersprüchliche Aussagen,
// ausserdem wäre es unlogisch.
- #PCDATA (Parsed Character Data)
Im Gegensatz zu CDATA werden die #PCDATA-Werte vom Parser geprüft, so dass man, z.B., für die Verwendung eines <, sicherheitshalber < schreiben sollte.
#PCDATA darf keine Tags enthalten.
//TODO: Was in #PCDATA wird jetzt eigentlich wie ausgewertet?
- Quellen:
http://www.cse.ohio-state.edu/~gurar...is788su39.html
http://de.selfhtml.org/xml/dtd/allgemeines.htm
http://de.selfhtml.org/html/referenz/index.htm
http://www.comptechdoc.org/independent/web/dtd/
http://webdesign.about.com/od/dtds/a/aa101700a.htm
http://www.w3.org/TR/html4/types.html
Alle RFCs:
http://www.rfc-editor.org/rfc.html
Tschüss Chris
Die drei Feinde des Programmierers: Sonne, Frischluft und dieses unerträgliche Gebrüll der Vögel.
Der Klügere gibt solange nach bis er der Dumme ist
|
Antwort
Linear-Darstellung
