Der Wert des Buches richtet sich vor allem nach bestimmten Eigenschaften. In Leder gebundene Bücher können beispielsweise beim Abziehen von Rasierklingen unbezahlbare Dienste leisten. Dünne Broschüren dagegen eignen sich vortrefflich dazu, wackelnden Tischchen das Gleichgewicht wiederzugeben. Ein Lexikon ist hervorragend geeignet, einen Einbrecher gefechtsunfähig zu machen.“
Mark Twain
XML-Dokumente sind zunächst einmal einfache Textdateien, deren Inhalt einer besonderen Struktur folgt. XML ist auch eher eine Metasprache, mit welcher einheitlich festgelegt wird, wie Sprachen zu spezifizieren sind, die zu dieser Sprachfamilie gehören. Das hat dann eine einheitliche Struktur und Notation bei allen Sprachen der Sprachfamilie zur Folge. Zudem kann man Fragmente aus verschiedenen Sprachen der Sprachfamilie XML miteinander in einem Dokument kombinieren. Die einzelnen Sprachen können unabhängig voneinander entwickelt werden, wobei sich die Entwickler auf das spezifische Problem konzentrieren können, welches mit der jeweiligen Sprache gelöst werden soll.
Um also eine spezielle Sprache aus der XML-Familie zu nutzen, ist es nicht notwendig, sich im Detail mit XML zu beschäftigen. Will man allerdings Fragmente aus verschiedenen Sprachen kombinieren, werden einige Konstruktionen wichtiger, die bei einer einzelnen Sprache erst einmal nicht so spannend wirken, wie etwa die Angabe eines Namensraumes. In den einzelnen Sprachen tauchen allerdings immer wieder dieselben oder ähnliche Strukturen auf. Wenn man sie in einer Sprache verstanden hat, kann man sein Wissen über die allgemein gültigen Strukturen auch in einer anderen der Familie nutzen. Solche Strukturen wie etwa die Identifikation eines Dokumentfragmentes oder die Struktur von Elementen sind daher in XML definiert und werden in den speziellen Sprachen nur weiterverwendet [XML].
Ein nahezu leeres Dokument im XML-Format XHTML 1.1 sieht zum Beispiel wie folgt aus:
<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet href="stil.css" type="text/css" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="de">
<head>
<title>Titel der Seite</title>
</head>
<body>
<h1 class="top">Dokumenttitel</h1>
<p>
Ein (sinnvoller) Gedanke könnte hier notiert werden.
</p>
</body>
</html>
Das Dokument beginnt in der ersten Zeile mit einer XML-Verarbeitungsanweisung, welche angibt, daß die Version 1.0 von XML verwendet wird, ferner die Kodierung UTF-8. Der Zweck der Zeile besteht vorrangig darin, anzugeben, daß das Dokument die Struktur eines XML-Dokumentes aufweist und entsprechend verarbeitet werden soll. Die Kodierungsangabe weist darauf hin, womit der Text im Dokument kodiert wurde.
Dann folgt in der nächsten Zeile eine XML-Stilvorlagenverarbeitungsanweisung,
welche eine Stilvorlagendatei im Format CSS
referenziert.
Mit einer Stilvorlage wird bestimmt, wie das Dokument von einem Darstellungsprogramm
präsentiert werden soll.
Für dem Darstellungsprogramm bekannte Formate hat dieses eigene Stilvorlagen.
Dann oder wenn das Dokument gar nicht präsentiert werden soll, ist die Referenzierung
einer Stilvorlage natürlich nicht notwendig.
Mittels href="stil.css" wird die Datei 'stil.css' referenziert.
Mittels type="text/css" wird angegeben, um welche Sprache es sich
bei der Stilvorlage handelt, dazu wird eine bestimmte Zeichenkette verwendet, die
Inhaltstyp oder Medientyp genannt wird und die ein Format eindeutig repräsentiert.
Dann folgt eine Dokumenttypdeklaration.
Der eigentliche Inhalt von XML-Dokumenten besteht immer aus Elementen
mit Attributen und Inhalt des jeweiligen Elementes.
Mit einer Dokumenttypdeklaration kann nun eine maschinenlesbare und formale
Dokumenttyp-Definition referenziert werden, in welcher in Form eines Schemas festgelegt
ist, welche Elemente es gibt, welche Attribute sie haben, welche Werte die Attribute
haben dürfen und welche Elemente und sonstige Inhalte in welchen Elementen als Inhalt
in welcher Reihenfolge stehen dürfen.
Neben Dokumenttyp-Definitionen gibt es für diesen Zweck auch andere Schemata und es
ist auch möglich, die Struktur als Prosa zu definieren, also nicht maschinenlesbar.
In solchen Fällen fällt dann die Dokumenttypdeklaration weg.
Was genau in der Dokumenttypdeklaration steht, wird durch die Metasprache für das Schema
festgelegt und auch durch die Spezifikation des zu definierenden Formates.
Darauf folgt das sogenannte Wurzelelement oder Hauptelement des Dokumentes, welches bereits
spezifisch für das verwendete Format ist.
Das Element heißt hier html.
Die Zeichenkette 'html' wird dann der Elementname genannt.
Der Name des Wurzelelementes ist in der jeweiligen Sprache festgelegt,
hier also in XHTML.
Sofern eine Dokumenttypdeklaration angegeben ist, findet sich darin der Elementname des
Wurzelementes hinter dem einleitenden '<!DOCTYPE '.
Solch ein Wurzelelement enthält bei XML immer alle anderen Elemente des
Dokumentes als Inhalt.
Das Element beginnt mit einer Anfangsmarkierung <html> und endet mit
einer Endmarkierung </html>.
Markierungen beginnen immer mit einem Kleinerzeichen '<' und enden mit einem Größerzeichen '>'.
Bei der Anfangsmarkierung folgt auf das '<' der Elementname.
Bei der Endmarkierung folgt auf das '<' ein Schrägstrich '/' vor dem Elementnamen, gefolgt von dem '>'.
In der Anfangsmarkierung können Attribute auftreten, jeweils mit Leerzeichen vom Elementnamen
und anderen Attributen getrennt.
In der Endmarkierung können keine Attribute auftreten.
In dem Beispiel hat html die Attribute xmlns und xml:lang.
Auf den Attributnamen folgt ein Gleichheitszeichen '=', dann folgt in Anführungszeichen der
Wert des Attributes.
Es werden entweder einfache Anführungszeichen oder doppelte Anführungszeichen verwendet.
Meistens sind die Attribute in der jeweiligen Sprache definiert.
Diese beiden Attribute habe jedoch eine spezielle Bedeutung, die bereits in XML
für alle Formate der Sprachfamilie vordefiniert ist.
Mit xmlns wird der Namensraum der verwendeten Sprache als Wert angegeben.
Der hier angegebene ist dann natürlich der für XHTML.
Dieser Wert ist in der Spezifikation von XHTML festgelegt.
Entsprechend legen die Spezifikationen der anderen Sprachen ihren eigenen Namensraum fest.
Mit einer Angabe des Namensraumes in einem Dokument wird eindeutig festgelegt, zu welcher Sprache ein Element gehört, für welches der Namensraum notiert ist. Von daher ist der Wert für den Namensraum charakteristisch für die jeweils verwendete Sprache. Anhand des Namensraumes kann ein Programm die Funktion und Bedeutung eines Elementes feststellen und es entsprechend interpretieren.
xml:lang ist ein Attribut, welches angibt, in welcher Sprache der Inhalt des Elementes verfaßt
ist [rfc5646].
Für deutsch ist der Wert des Attributes zum Beispiel 'de',
für englisch 'en'.
Zwischen der Anfangs- und Endmarkierung eines Elementes steht nun der Inhalt des Elementes. Die verwendete Sprache legt dann individuell fest, welcher Inhalt erlaubt ist. XHTML schreibt vor, daß als erstes exakt ein Element head in html zu notieren ist, darauf muß dann gemäß XHTML exakt ein Element body folgen.
Entsprechend ist festgelegt, daß head mindestens ein Element title als Inhalt haben muß. Der Inhalt von title wiederum ist einfacher Text. In diesem Falle repräsentiert der Inhalt von title das Dokument als Überschrift. head kann auch weitere Elemente als Inhalt haben.
body wiederum kann bestimmte Elemente als Inhalt haben, was ebenfalls festgelegt ist.
In diesem Beispiel ist aus einer größeren Anzahl von Möglichkeiten eine Überschrift der obersten Stufe
als erstes Element gewählt worden. Solch ein Element wird zumeist verwendet,
um den Dokumenttitel innerhalb der Präsentation des Dokumentes darzustellen, während der
Inhalt von title nicht direkt zusammen mit dem sonstigen Inhalt dargestellt wird
und auch bevorzugt dazu verwendet wird, um das Dokument mit einem Titel zu bezeichnen,
wenn darüber geschrieben oder gesprochen wird.
Als weiterer Inhalt ist ein Absatz notiert, dazu dient in XHTML das
Element p.
Eine XML-Verarbeitungsanweisung weist darauf hin, daß es sich bei dem vorliegenden Dokument um ein XML-Dokument handelt, es also nach den Regeln von XML zu verarbeiten ist.
Oft kommt in der Verarbeitungsanweisung eine Angabe zur Kodierung vor. EPUB schreibt ja vor, daß immer UTF-8 zu verwenden ist, oder sofern erforderlich, auch UTF-16. Bleibt man bei UTF-8, so braucht man die Kodierung nicht anzugeben, weil dies die Voreinstellung für XML-Dokumente ist, wenn nichts notiert ist. Das sieht dann so aus:
<?xml version="1.0" ?>
Ein offensichtliches Problem bei der Angabe der Kodierung ist, daß bis zu der Stelle, wo die Angabe erfolgt, das Dokument schon dekodiert sein muß, um die Angabe berücksichtigen zu können. Das typische Vorgehen besteht darin, daß das Programm erst einmal eine Kodierung rät (UTF-8) und guckt, ob damit die erste Zeile des Dokumentes einen Sinn ergibt. Wird so die erste Zeile eines Dokumentes dekodiert, in der die XML-Verarbeitungsanweisung steht, kann gegebenenfalls die Dekodierung noch angepaßt werden. Das liegt daran, daß die Angaben in der XML-Verarbeitungsanweisung so ausgelegt sind, daß sie bei gängigen Kodierungen gleich ausfallen, also keine kritischen Sonderzeichen enthalten.
Ein anderes Vorgehen als etwa in einem EPUB-Archiv kann sich ergeben, wenn das Dokument von einem Dienstprogramm ausgeliefert wird. Dieses kann verbindlich die Kodierung des Dokumentes angeben, wonach sich ein Darstellungsprogramm zu richten hat. Das vermeidet das Problem, daß die Datei bereits dekodiert sein muß, bevor man die Angabe zur Kodierung erhält. Gibt das Dienstprogramm eine Kodierung an, so wird die Angabe im Dokument ignoriert.
Wie bereits erläutert, werden mit XML-Stilvorlagenverarbeitungsanweisungen Stilvorlagen referenziert, mit welchen das Dokument präsentiert oder dargestellt werden kann. Formate wie XHTML haben dafür auch alternative eigene Mechanismen. Diese Verarbeitungsanweisungen gelten für alle XML-Dokumente und deren Interpretation ist in EPUB auch ausdrücklich von den Darstellungsprogrammen als notwendig gefordert. Das schließt auch die Möglichkeit ein, alternative Stilvorlagen anzubieten, dazu folgendes Beispiel:
<?xml-stylesheet href="hell.css" type="text/css" title="Hell"?> <?xml-stylesheet href="dunkel.css" type="text/css" title="Dunkel" alternate="yes" ?> <?xml-stylesheet href="kein.css" type="text/css" title="Kein CSS" alternate="yes" ?>
Mit dem Attribut href wird die externe Stilvorlage referenziert. Die Angabe des Attributes ist erforderlich. Der Attributwert ist eine absolute oder relative URI der Datei mit der Stilvorlage, hier einfach der Dateiname einer CSS-Datei im gleichen Verzeichnis. Es kann auch ein Fragmentidentifizierer sein, der dann eben auf ein Dokumentfragment verweist, welches die Stilvorlage enthält.
Mit dem Attribut type wird angegeben, welches Stilvorlagenformat verwendet wird, hier also CSS. Der Wert ist ein Inhaltstyp oder Medientyp [IANA]. Die Angabe des Attributes ist ebenfalls erforderlich.
Mit dem Attribut title kann ein Titel oder eine Überschrift angegeben werden. Die Angabe des Attributes ist nicht erforderlich, sie wird jedoch immer benötigt, wenn mehrere Stilvorlagen alternativ angeboten werden. Das Attribut ist also insbesondere relevant, wenn das Darstellungsprogramm mehrere alternative Stilvorlagen zur Auswahl stellen soll. Der Attributwert wird dann als Menüeintrag der Auswahl verwendet.
Daß Stilvorlagen alternativ und nicht alle gleichzeitig angewendet werden sollen, wird dann mit dem Attribut alternate angegeben. Die erste Angabe im obigen Beispiel ist ohne alternate, was dann bedeutet, das dies die Voreinstellung ist. Der Attributwert 'yes' gibt eben an, daß es sich um eine alternative Stilvorlage handelt. 'no' würde angeben, daß es zusätzlich zur Voreinstellung anzuwenden ist. Eine Angabe des Attributes ist nicht erforderlich, Voreinstellung ist 'no'.
Mit dem Attribut charset kann ein Hinweis auf die Kodierung des referenzierten Dokumentes angegeben werden. Eine Angabe des Attributes ist nicht erforderlich. Die möglichen Werte entsprechen denen von encoding in der XML-Verarbeitungsanweisung. Der Hinweis ist allerdings nur relevant, wenn es keine anderen bindenden Informationen gibt, zum Beispiel von einem Dienstprogramm, welches das referenzierte Dokument ausliefert, oder im Dokument selbst.
Mit dem Attribut media kann angegeben werden, für welches Ausgabemedium die Stilvorlage gedacht ist. Eine Angabe des Attributes ist nicht erforderlich, Voreinstellung ist in CSS 'screen'. Der Attributwert ist ein Medientyp oder eine Liste von Medientypen, die jeweils mit einem Komma und optionalen Leerzeichen voneinander separiert sind. Welche Medientypen verfügbar sind, hängt von der verwendeten Stilvorlagensprache ab. CSS 2.0 gibt zum Beispiel folgende Möglichkeiten an, von denen vermutlich nur einige sinnvoll für EPUB sind:
Für spätere Versionen von CSS sind weitere Typen und Schreibweisen vorgesehen, insbesondere auch, weil es inzwischen eine größere Anzahl von verschiedenen Geräten gibt, zum Beispiel weichen bei Mobiltelephonen oder Geräten für digitale Bücher die typischen Abmessungen von Höhe und Breite erheblich von denen von früheren Monitoren ab (auch im Seitenverhältnis). Auch bei heute üblichen Monitoren weicht das Seitenverhältnis teils erheblich von dem von älteren Monitoren ab. Die in einem Modul von CSS 3 definierten Medienanfragen sind allerdings noch nicht in EPUB 2 vorgesehen, wären aber gerade für diese Anwendung besonders nützlich.
Die Dokumenttypdeklaration kann hilfreich sein, wenn mit einem Validator [W3CV] untersucht werden soll, ob die Struktur eines Dokumentes korrekt ist. Ein Validator ist ein spezielles Programm, welches derartige Untersuchungen der Dokumentstruktur durchführt. Kennt der Validator das Format oder kann die entsprechende Datei mit Strukturinformationen herunterladen, kann er untersuchen, ob das Dokument die Verschachtelungsregeln und einige andere relevante Dinge einhält, die in der Dokumenttyp-Definition (DTD) angegeben sind, welche mit der Deklaration im Dokument zugeordnet wird. Weil man in der gängigen Notation als DTD längst nicht alles angeben kann, was hilfreich wäre, wird darauf auch bei neueren oder komplexeren Formaten verzichtet. Ist ein Format ferner in EPUB nicht als erforderlich angegeben und eine Dokumenttypdeklaration soll trotzdem in einem Dokument verwendet werden, so ist die DTD in das Buch zu integrieren und die Dokumenttypdeklaration muß auf dieses Dokument verweisen und nicht auf die öffentlich zugängliche DTD. Es kann also praktikabler sein, das Dokument erst mit dem Validator zu prüfen, dann die Dokumenttypdeklaration zu entfernen und die Datei ins Buch zu integrieren.
In SVG etwa kann auch mittels der DTD nicht überprüft werden, ob ein Autor Pfade korrekt notiert hat, weil die DTD solche Feinheiten nicht hergibt. Dem Validator fallen solche Fehler nicht auf. Andersherum können Beschränkungen in dem, was in einer Dokumenttypdefinition angegeben werden kann, dazu führen, dass der Validator Fehler anzeigt, die keine sind, weil in der Spezifikation etwas anderes angegeben ist, dies aber in solcher Allgemeinheit nicht in der Dokumenttypdeklaration angegeben werden kann.
Relevant ist bei einer konkreten Angabe einer Dokumenttypdeklaration weniger, genau zu verstehen, was da warum angegeben ist, sondern die Deklaration im Bedarfsfalle exakt so hinzuschreiben, wie es spezifiziert ist. Nur dann kann der Dokumenttyp von einem Programm erkannt werden. Als Autor ist nicht mehr zu tun. Die Entwickler der Formate haben sich zu überlegen, was wie deklariert wird.
Während ein Programm jedes XML-Dokument daraufhin prüfen kann, ob es korrekt nach den XML-Regeln erstellt ist (Wohlgeformtheit), braucht es ein solches für die Sprache spezifisches Schema wie eine DTD, um zu erkennen, ob die Bedingungen des Formates erfüllt sind. Ob also die Elemente und Attribute richtig verwendet werden und richtig ineinander verschachtelt sind. Letzteres wäre dann also eine Prüfung auf Validität des jeweiligen Formates.
Bei XHTML dient die Deklaration auch der Angaben der Version der Sprache. In der Praxis sind Angaben zur Version hilfreicher für den Autor oder spätere Leser des Quelltextes als für ein Programm, welches das Dokument interpretiert. Das liegt daran, daß aktuell real existierende Programme einfach nicht so ausgelegt sind, daß sie für verschiedene Versionen verschiedene Interpretationen implementiert haben. Entwickler von Formaten versuchen daher nach Möglichkeit, Inkompatibilitäten zu vermeiden, was aber nicht immer komplett möglich ist. Autoren können anhand der Versionsangaben bei Unstimmigkeiten gucken, wie das Dokument eigentlich gedacht war und es dann im Bedarfsfalle vorsichtig an eine neue Version anpassen. Bei Dokumenten ohne Versionsangabe wird in der Regel die aktuelle Version des Formates als relevant angenommen. Das hat zur Konsequenz, daß sich bei einer inkompatiblen Änderung der Spezifikation die Bedeutung von solchen Dokumenten ändern kann. Bei Dokumenten mit relevantem, kritischem Inhalt ist also immer zu empfehlen, eine eindeutige Angabe zur verwendeten Sprachversion anzugeben. Der Autor kann nicht vorhersagen, wie zukünftige Versionen des Formates aussehen werden.
Eine Dokumenttypdeklaration kann aber auch für Erweiterungen genutzt werden. Im folgenden Beispiel wird in der Deklaration für SVG eine Erweiterung (ENTITY) 'Pfad' definiert, eine Abkürzung für das, was hinter 'Pfad' in Anführungszeichen angegeben ist. Man kann da auch ganze Elemente oder Gruppen von Elementen angeben, die dann einfach wiederverwendet werden können. Im Dokument kann die Entität 'Pfad' dann mittels &Pfad; verwendet werden. Diese Zeichenkette wird durch die für 'Pfad' definierte ersetzt, bevor das Dokument interpretiert wird:
<!DOCTYPE svg [<!ENTITY Pfad "M200,300 L300,100"> ] >
In einem SVG könnte das dann wie folgt verwendet werden:
<path d="&Pfad;" stroke-width="10" stroke="blue" fill="none" />
Das kann etwa als Abkürzung nützlich sein, wenn die Entität öfter im Dokument verwendet wird.
In der Zeichenkette dürfen natürlich nur Zeichen stehen, die nicht mit der Syntax im Konflikt stehen, hier also keine doppelten Anführungszeichen.
Derartige Entitäten können auch in einer DTD definiert werden. Das wird insbesondere auch bei XHTML reichlich gemacht. Das ergibt aber nur einen Sinn, wenn die DTD lokal im EPUB steht, weil Programme nicht auf externe DTDs zugreifen können oder brauchen. Die Erweiterung in der Dokumenttypdeklaration ist davon natürlich nicht betroffen, die kann unbedenklich benutzt werden.
Ferner definiert XML selbst einige Entitäten, die nicht nur unbedenklich benutzt werden können, sondern je nach Position im Quelltext sogar genutzt werden müssen. Vordefiniert ist also, was in Konflikt mit der Notation geraten kann:
Nun gibt es auch zahlreiche andere Zeichen, die man nicht auf der eigenen Tastatur finden wird. Üblicherweise gibt es dafür auf dem eigenen Rechner Zeichentabellen, wo man das Zeichen nachschlagen und kopieren kann. Zusätzlich ist in solchen Tabellen auch die Unicode-Nummer des Zeichens angegeben. Mit dieser Angabe kann aber wiederum unabhängig von einer DTD eine zuverlässig funktionierende Entität konstruiert werden.
Die Zahl kann entweder im dezimalen System notiert werden oder im hexadezimalen System.
Eine Entität beginnt immer mit einem '&' und endet mit einem Semikolon ';'.
Für Zahlenangaben folgt auf das '&' ein '#'.
Zwischen '#' und ';' wird die zum Zeichen gehörige Zahl notiert.
Bei hexadezimaler Schreibweise wird zwischen dem '#' und der Zahl noch ein 'x' notiert.
Zum Beispiel könnte man das Zeichen '±' notieren wollen.
In der Zeichentabelle findet man dazu die dezimale Zahl '177' oder die hexadezimale Zahl 'B1'.
Folglich notiert man für die Entität '±' oder '±'.
Namensräume sind eine Konstruktion in XML, mit der Überschneidungen von Bedeutungen von Elementen von verschiedenen Sprachen vermieden werden können. Etwa hat das Element font in SVG eine andere Bedeutung als in XHTML. Das Element title kommt in verschiedenen Formaten meist mit ähnlicher Bedeutung vor, wo es aber auftreten kann, kann von Format zu Format sehr unterschiedlich sein. Ein Darstellungsprogramm muß nun bei einem Dokument wissen, dessen Inhalt aus verschiedenen Formaten zusammengemischt wurde, aus welchem Format das jeweilige Element oder Attribut kommt. Dazu dient die eindeutige Zuordnung zu einem Namensraum. Das löst wiederum nicht das mögliche Problem, daß bei verschiedenen Versionen eines Formates die Elemente oder Attribute leicht unterschiedliche Bedeutungen haben können. Um die Version eines Formates zu kennzeichnen, sind besondere Mechanismen im jeweiligen Format zu definieren.
Typisch wird eine URI als Namensraumangabe verwendet, damit die Zuordnung eindeutig ist.
Andere eindeutige Zeichenketten sind aber nicht ausgeschlossen.
Bei einer URI ist es meist üblich, daß man dort zumindest Angaben darüber findet,
um was für ein Format es sich handelt.
Häufig auftretende Formate und Namensräume:
SVG: http://www.w3.org/2000/svg
XLink: http://www.w3.org/1999/xlink
XHTML: http://www.w3.org/1999/xhtml
MathML: http://www.w3.org/1998/Math/MathML
RDF: http://www.w3.org/1999/02/22-rdf-syntax-ns#
Dublin Core, DCMI Elemente: http://purl.org/dc/elements/1.1/
Dublin Core, DCMI Terme: http://purl.org/dc/terms/
XML Schema: http://www.w3.org/2001/XMLSchema#
XSLT: http://www.w3.org/1999/XSL/Transform
Der Namensraum wird mit dem in XML selbst definierten Attribut xmlns angegeben,
Beispiel siehe oben.
Der Namensraum ist dann voreingestellt.
Der Namensraum gilt dann für das Element, für welchen der Namensraum angegeben wurde.
Bei jedem Element kann mit xmlns ein Namensraum voreingestellt werden,
der dann wieder für dieses Element gilt.
Ist bei einem Element durch das Attribut xmlns ein Namensraum voreingestellt, so gilt dieser
auch für alle Nachfahren dieses Elementes, die selbst keinen Namensraum angeben.
Es gilt dann jeweils jener Namensraum für Elemente ohne eigene Angabe, der beim nächstgelegenen Vorfahren angegeben ist.
Angaben zum voreingestellten Namensraum wirken also nur auf das Element selbst und auf seine Nachfahren,
nicht auf Geschwister, Vorfahren etc.
Hat man häufige Wechsel von Namensräumen, so kann man auch ein Präfix für den jeweiligen
Namensraum definieren.
Der per Präfix definierte Namensraum gilt nur für Elemente, deren Namen mit dem Präfix notiert sind und auch
nur dann, wenn der Präfix beim Element selbst oder einem Vorfahren mit einem Namensraum verknüpft ist.
Ein Element mit Präfix ändert also nicht den gegebenenfalls voreingestellten Namensraum für seine Nachfahren.
Wird derselbe Präfix in einem Dokument mehrmals mit verschiedenen Namensräumen verknüpft, so gilt
jeweils die Verknüpfung, welche beim Element selbst festgelegt ist, beziehungsweise wenn es dort nicht
festgelegt ist, beim nächstgelegenen Vorfahren.
Präfix-Definitionen wirken also gegebenenfalls nur auf das Element selbst und auf seine Nachfahren, nicht auf
Geschwister, Vorfahren etc.
Wird solch ein Präfix verwendet, ist dies den Elementnamen und Attributnamen jeweils voranzustellen,
wobei ein Doppelpunkt als Separator zwischen Präfix und Elementname dient.
Der Autor selbst legt das Präfix fest (Ausnahme: Das Präfix darf nicht mit der Zeichenfolge 'xml' beginnen,
auch nicht mit einer Variation davon, bei der ein oder mehrere der Buchstaben großgeschrieben werden).
Es kann allerdings in der Praxis Probleme vermeiden, wenn man nicht von den etablierten Präfixen abweicht,
falls ein Darstellungsprogramm Implementierungsfehler hat.
Beispiel dazu:
xmlns:dc="http://purl.org/dc/elements/1.1/"
Ein Element title zum Beispiel wird dann so markiert:
<dc:title>Mein Buch</dc:title>
Ist bei einem Element kein Namensraum angegeben, so gehört es also zum voreingestellten Namensraum des Elternelementes, sofern dies zu einem voreingestellten Namensraum gehört. Hat das Elternelement allerdings einen Präfix für einen eigenen Namensraum, so gilt dieser nicht für Nachfahren, die nicht diesen Präfix verwenden, für diese gilt dann die Präfix-Definition, beziehungsweise der voreingestellte Namensraum, wir für den nächsten Vorfahren festgelegt.
Typisch wird etwa bei Dokumenten, die nur ein Format verwenden, der Namensraum im Hauptelement angegeben und voreingestellt, womit die Angabe dann für alle Kindelemente gilt, die keine eigenen Angaben zum Namensraum machen.
Bei Attributen ist die Lage formal etwas komplizierter,
wenn sie zu einem anderen Namensraum gehören sollen als das Element, in dessen Markierung sie notiert sind.
Diese sind dann mit Präfix zu notieren.
Attribute ohne Präfix gehören nicht zu einem Namensraum, beziehungsweise gehören zum Null-Namensraum.
Ohne Präfix wird die Bedeutung solcher Attribute in dem Namensraum definiert und interpretiert,
der zu dem Element gehört, in dem sie notiert sind.
Insbesondere ist es nicht möglich, wie es für EPUB versucht wird, die Bedeutung von Attributen,
die bei Elementen aus anderen Namensräumen notiert sind, zu definieren, ohne sie dann mit dem eigenen
Präfix zu versehen, also etwa über den voreingestellten Namensraum zu definieren.
Sind solche Attribute ohne Namensraum nicht für das Element in seinem Namensraum definiert, haben
sie keine definierte Bedeutung.
Ähnliches gilt für Elemente ohne Namensraumzuordnung, oder wie man sagt, die sich im Nullnamensraum befinden. Ein Programm kann ohne Namensraumzuordnung keine definierte Bedeutung feststellen oder Interpretation haben, Elemente ohne Namensraum haben also keine definierte Bedeutung. Zusätzlich dazu muß es für den Namensraum natürlich irgendwo eine Spezifikation geben, welche die Bedetung definiert und diese mit dem Namensraum assoziiert. Wenn die Spezifikation mit dem Namensraum assoziiert ist und der Namensraum im jeweiligen XML-Dokument angegeben ist, ist die semantische Verknüpfung komplett und die Elemente und Attribute haben eine definierte, eindeutig nachvollziehbare Bedeutung.
Das prinzipielle Konzept von XML-Formaten liegt darin, Inhalte auszuzeichnen, also gemäß Bedeutung oder Funktion zu markieren. Dazu werden Konstruktionen verwendet, die Funktion oder Semantik des Inhaltes beschreiben.
Zum Beispiel gibt es in SVG ein Element, welches rect heißt. Dies beschreibt ein Rechteck, gegebenenfalls mit abgerundeten Ecken. Generell sind damit alle Arten von Rechtecken gemeint. Nun gibt es aber verschiedene Arten von Rechtecken, die sich insbesondere in Breite und Höhe unterscheiden und in der Positionierung, auch wie stark die Ecken abgerundet sind. Dies wird mit Attributen genauer festgelegt. Auch die Erscheinung oder Präsentation, etwa die Farbe, kann genauer festgelegt werden.
Um nun zu verstehen, was genau gemeint ist, wenn jemand sagt oder schreibt, es soll ein rect-Element verwendet werden - oder irgendein anderes Element - kommt es darauf an, die Bestandteile eines solchen Elementes genau bezeichnen zu können.
Dazu ein willkürliches, ausgedachtes Beispiel, einen Apfel, repräsentiert durch das Element apfel:
<apfel sorte="Boskop" zustand='reif'>
<kern />
<fruchtfleisch>
lecker
</fruchtfleisch>
</apfel>
Dabei ist nun dies das gesamte Element (englisch: element). 'apfel' ist der Name des Elementes, Groß- und Kleinschreibung ist signifikant. Apfel und apfel sind also zwei komplett verschiedene Elemente.
Folgendes ist die Anfangsmarkierung (englisch: begin tag). Diese enthält ferner die Attribute (englisch: attribute, Mehrzahl: attributes) sorte und zustand:
<apfel sorte="Boskop" zustand='reif'>
Ein Element hat immer eine entsprechende Endmarkierung (englisch: end tag), die keine Attribute enthalten kann, hier:
</apfel>
Achtung, aufgrund mangelnden Verständnisses,
einer gewissen Sprachkonfusion und einer Tendenz besonders in Deutschland,
hinter jedem englischen Begriff gleich ein Fachwort zu vermuten,
bezeichnen einige Menschen fälschlich ein Element als 'tag' oder noch schlimmer 'Tag', Mehrzahl auch 'tags'.
Diese Buchstabenkombination hat allerdings im Deutschen eine komplett andere Bedeutung
(Tagesabschnitt, wo die Sonne über dem Horizont steht, im Gegensatz zu 'Nacht',
oder aber auch ein Zeitraum von 24 Stunden, tags auch im Sinne von
'am Tage' oder bei 'tags drauf' eben 'am nächsten Tag').
Das ist so falsch und wird auch im englischen Sprachraum von kundigen Fachleuten nicht so verwendet.
'tag' ist einfach auf deutsch eine Markierung oder Kennzeichnung und hat nicht den Anspruch eines Fachwortes.
Die Fachbezeichnung ist auf englisch wie auf deutsch jedenfalls (mal abgesehen von Groß- und Kleinschreibung) die gleiche - Element.
Anfang und Ende eines Elementes werden markiert.
Dazu dienen Markierungen, Anfangs- und Endmarkierung, die jeweils den Elementnamen enthalten.
Die Markierungen sind aber nicht das Element selbst, ebenso wenig wie Anfang und Ende von einem Würstchen das Würstchen selbst sind.
Attribute haben immer einen Wert. Es werden also getrennt mit Leerzeichen in der Anfangsmarkierung die Attributnamen angegeben, wobei jeweils der Wert oder Attributwert nach einem Gleichheitszeichen in Anführungszeichen folgt. Das sind entweder einfache oder doppelte Anführungszeichen. Enthält der Attributwert einfache Anführungszeichen, sind doppelte zu verwenden und umgekehrt. Taucht beides im Attributwert auf, so sind Anführungszeichen dort am besten zu maskieren, dafür hat XML spezielle Abkürzungen, Entitäten genannt, eingeführt (siehe oben). Hier ist der Wert des Attributes sorte eben 'Boskop' und der von zustand 'reif'.
In obigem Beispiel ist dann der Inhalt von apfel (einschließlich der Leerzeichen davor und dahinter):
<kern /> <fruchtfleisch> lecker </fruchtfleisch>
Das sind zwei weitere Elemente kern und fruchtfleisch. Beide haben keine Attribute und kern hat auch keinen Inhalt. Das ist ein besonderer Fall in XML, ein sogenanntes inhaltsleeres Element (englisch: empty element). Entweder folgt dann die Endmarkierung direkt auf die Anfangsmarkierung:
<kern></kern>
Oder es wird wie im Beispiel eine spezielle Kurzschreibweise verwendet:
<kern />
Das Element fruchtfleisch enthält als Inhalt nur den Text 'lecker'. Reiner Text wird in XML auch 'CDATA' genannt, der wird als Elementinhalt nicht mehr interpretiert, als Wert eines Attributes schon. Text, der PCDATA genannt wird, wird interpretiert, also darin vorkommende Entitäten oder auch Markierungen werden interpretiert.
In diesem Falle sind also kern und fruchtfleisch Kindelemente von apfel. Sie sind in apfel verschachtelt, stehen also zwischen Anfangs- und Endmarkierung von apfel, welches dann das Elternelement ist.
Elemente, die direkt als Inhalt in einem anderen Element stehen, nennt man also dessen Kinder oder Kindelemente, das übergeordnete Element entsprechend das Elternelement. Die Kindelemente eines gemeinsamen Elternelementes werden gemäß der Analogie auch Geschwister genannt. In der Elementverschachtelung noch weiter übergeordnete Elemente nennt man entsprechend Vorfahren und welche, die noch tiefer verschachtelt sind, die Nachfahren.
Was der Inhalt eines Elementes sein darf, ist in der jeweiligen Spezifikation genau angegeben und kann - sofern vorhanden - mittels eines Schemas wie einer DTD auch formal überprüft werden.
Durch das Verschachteln der Elemente und das Zusammenspiel mit den Attributen entsteht so ein strukturiertes Dokument. An dem Beispiel mit dem Apfel ist bereits zu erkennen, daß damit maschinenlesbar und -verstehbar sehr genaue Angaben darüber gemacht werden können, worum es geht. Elemente, Attribute und zumindest festgelegte Attributwerte sind in dem Sinne einem Programm verständlicher Inhalt, der auch hinsichtlich der Zugänglichkeit so vermittelbar ist. Freier Text ist nicht zwangsläufig der Maschine verständlich, als Text aber jedenfalls von der Maschine Menschen vermittelbar, die die Sprache verstehen, in der der Text verfaßt ist.
Mehrere aufeinander folgende Leerzeichen und Zeilenumbrüche werden - sofern nicht ein besonderes Attribut von XML verwendet wird - zu einem Leerzeichen zusammengeschnurrt.
Zeilenumbrüche und aufeinander folgende Leerzeichen sind also für die Präsentation nahezu belanglos,
bis auf das eine verbleibende Leerzeichen.
Wenn das entsprechende oder ein anderes von XML vordefiniertes Attribut in einem Format
Verwendung finden soll, wird das dort explizit erwähnt.
Fragmentidentifizierer dienen der eindeutigen Identifikation von Elementen. In XML wird dafür eigentlich ganz allgemein das Attribut xml:id bereitgestellt. Weil dieses aber erst recht spät eingeführt wurde, findet es in dem meisten Formaten keine Berücksichtigung und ist bei zahlreichen Darstellungsprogrammen auch nicht durchgehend implementiert.
Daher definieren die meisten Formate ein eigenes Attribut für diesen Zweck,
oft mit dem Namen id.
Sie übernehmen dabei jedoch nahezu immer von XML die genaue
Struktur des Attributwertes und dessen Einschränkungen.
Der Attributwert wird in XML als eine Struktur mit dem Namen 'Name'
definiert.
'Name' beginnt mit einem der folgenden Zeichen
('|' steht in dieser Kurznotation jeweils für ein oder,
die auf '#x' folgende hexadezimale Zahl ist der Unicode des Zeichens,
in eckigen Klammern sind Unicode-Bereiche von Zeichen zusammengefaßt):
":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
Optional folgen darauf weitere Zeichen dieser Kollektion, des weiteren sind für solche optionalen
Folgezeichen auch diese erlaubt:
"-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040].
Prinzipiell können bei einigen Formaten auch weitere Einschränkungen erfolgen.
Auf der sicheren Seite ist man jedenfalls immer mit einer Teilmenge, die sich kurz so
zusammenfassen läßt:
Das erste Zeichen sei ein Buchstabe [A-Z] oder [a-z].
Danach können weitere dieser Buchstaben, Ziffern [0-9], '.', '_' oder '-' folgen.
Dies wird dann in diesem Artikel auch als Erklärung für Werte derartiger Fragmentidentifizierer
verwendet.
Wie man ein Fragment referenziert oder wiederverwendet, ist in den unterschiedlichen Formaten
leider unterschiedlich gelöst.
Von XHTML und SVG her kennt man die Methode, in einem referenzierenden
Attribut als Wert mit einer optional vorangehenden URI/IRI ein '#'
zu notieren und anschließend den gewünschten Fragmentidentifizierer.
Es gibt aber auch andere Methoden.
Zum Beispiel wird in dem für EPUB zu verwendenden OPF-Dokument
zum einen das Attribut idref verwendet, zum anderen auch toc, der Wert ist
dann jeweils direkt der gewünschte Fragmentidentifizierer ohne weiteres Zeichen davor.
In XML-Dokumenten dürfen auch Kommentare notiert werden. Inhalte solcher Kommentare werden nicht interpretiert, sind also nur im Quelltext lesbar, aber nicht in der Darstellung eines Dokumentes im Darstellungsprogramm. Kommentare können etwa sinnvoll sein, um den Quelltext verständlicher zu machen oder aktuell nicht benötigte Teile eines Dokumentes auszukommentieren.
Ein Kommentar beginnt mit der Zeichenfolge '<!--' und endet mit der Zeichenfolge '-->'. Dazwischen kann nahezu beliebiger Text stehen, mit Ausnahme der Zeichenfolge '--'.
Kommentare können stehen, wo Elemente notiert werden können. Zudem dürfen sie auch direkt zwischen der XML-Verarbeitungsanweisung und dem Wurzelelement auftreten und hinter der Endmarkierung des Wurzelelementes. Auch innerhalb von Dokumenttypdeklarationen können sie auftreten, besonders auch im Bereich der Erweiterung, etwa um selbst definierte Entitäten zu erläutern. Innerhalb der Elementmarkierungen dürfen Kommentare nicht stehen.
Hinsichtlich der Fehlerbehandlung ist festgelegt, daß Dokumente wohlgeformt sein müssen, um XML-Dokumente zu sein. Treten in diesem Sinne Fehler auf, so hat ein XML-Verarbeitungsprogramm (englisch: XML parser) die Verarbeitung abzubrechen. Üblicherweise gibt das Verarbeitungsprogramm dann eine Fehlermeldung aus, an welcher Stelle es ein Problem gibt. Dies ist dann eine enorme Hilfe für Autoren, um Fehler zu beseitigen.
In diesem Sinne sind auch undefinierte Entitäten, eine falsche Reihenfolge der Markierungen von verschiedenen Elementen, Attributwerte ohne Anführungszeichen, nicht geöffnete oder nicht geschlossene Elemente Fehler, die zum Abbruch der Verarbeitung führen und zu beheben sind.
Fehler hinsichtlich der spezifischen Sprache, etwa gegenüber einem Schema wie einer DTD, wie etwa unbekannte Elemente oder Attribute oder Attributwerte oder Elemente an der falschen Stelle der Dokumentstruktur der jeweiligen Sprache, sind hingegen nur Fehler hinsichtlich der sogenannten Validität oder Gültigkeit des Dokumentes, die gegebenenfalls oft mit einem Validator festgestellt werden können, aber nicht in allen Fällen müssen.
Die Behandlung solcher Fehler ist in der jeweiligen Sprache festzulegen, zumeist aber kein Grund, die Verarbeitung abzubrechen. Auch hier gibt es allerdings wichtige Ausnahmen. Für einige wenige Fehler schreibt SVG etwa explizit den Abbruch der Präsentation an der Stelle des Fehlers vor, um es Autoren zu erleichtern, den Fehler zu finden und zu beheben.
Meistens ist allerdings festgelegt, daß Attribute mit unbekannten Werten oder unbekannte
Attribute inhaltlich als nicht relevant angenommen werden.
Unbekannte Elemente werden ähnlich wie span in XHTML interpretiert -
keine besondere Funktion und auch keine besondere Präsentation, solange diese nicht mit
einer Stilvorlage festgelegt ist.
Entsprechend können dann auch unbekannte Attribute oder Attributwerte in Stilvorlagen
verwendet werden, um die Präsentation zu beeinflussen oder auch per Stilvorlage
zusätzliche Strukturen wie etwa die Attributwerte darzustellen, wie bei bekannten Attributen
auch.
Wenn Elemente oder Attribute zu einem anderen Namensraum gehören,
mit welchem das Darstellungsprogramm nichts anfangen kann,
ist dies an sich erstmal kein Fehler des Dokumentes,
sondern eventuell nur ein Defizit des Darstellungsprogrammes.
Jedenfalls kann die mangelnde Kenntnis ein ähnliches Verhalten wie bei unbekannten
Elementen oder Attributen zur Folge haben,
resultiert aber jedenfalls nicht in einem Abbruch der Verarbeitung oder Präsentation.
EPUB bietet in dem Zusammenhang ja auch eine Möglichkeit,
bei der Verwendung von nicht erforderlich interpretierbaren XML-Formaten,
Stilvorlagen dafür anzugeben, um die Präsentation sicherzustellen, nicht jedoch
gegebenenfalls relevante Funktionen, für welche dann als Alternative eine
Umsetzung in einem erforderlich zu interpretierenden Format zu realisieren ist.
Anmerkung, nur um Fragen vorzubeugen:
Einen ähnlichen Text habe ich bereits bei wikibooks im Buch über SVG veröffentlicht.