SVG/ Einführung/ Kurze Einführung in XML

Vorwort Kurze Einführung in XML Vektorgraphik Programme rund um SVG

Kurze Einführung in XML

Soweit es von Belang ist, soll hier kurz auf die prinzipielle Sprachkonstruktion eines XML-Formates eingegangen werden (XML – erweiterbare Auszeichnungssprache, englisch: eXtensible Markup Language).

Bereits vor der Jahrtausendwende hat sich am Beispiel von HTML (Versionen 1 bis 4, Hypertextauszeichnungssprache, englisch: HyperText Markup Language) gezeigt, dass diese auf SGML (englisch: Standard Generalized Markup Language) basierende Sprache derart komplex ist, dass es bis zum heutigen Tage kein Darstellungsprogramm geschafft hat, diese komplett zu interpretieren. Auch die offengelassene Fehlerbehandlung hat letztlich zusammen mit der unvollständigen oder fehlerhaften Interpretation der Darstellungsprogramme dazu geführt, dass dieses Format gewissermaßen korrumpiert ist, gleichzeitig aber durch die häufige Verwendung im Netz zu einem der wichtigsten Formate überhaupt geworden ist. Aufgrund der Komplexität und der zahlreichen Probleme der Programme schien indes eine Erweiterung nur schwierig möglich.

Mit XML wurde daher eine Sprachfamilie konzipiert, die eine einfachere Syntax hat und gleichzeitig die Möglichkeit der Erweiterbarkeit bietet. Zusätzlich hat es zumindest hinsichtlich grober Strukturfehler eine definierte Fehlerbehandlung, die Darstellungsprogramme dazu bringt, Strukturfehler anzuzeigen, am besten noch bevor ein Autor fehlerhafte Dokumente veröffentlicht.

Die Grundidee von XML ist vorzugeben, wie eine Sprache dieser Sprachfamilie zu spezifizieren ist, statt die Sprache selbst zu spezifizieren. Gemeinsam vorgegeben ist allen XML-Formaten die Konstruktion mit Elementen und Attributen.

Ein XML-Dokument besteht aus Klartext und beginnt generell mit einer XML-Deklaration, die dem Darstellungsprogramm kenntlich macht, dass es sich um XML handelt und gegebenenfalls auch, wie das Dokument kodiert ist und ob es Abhängigkeiten zu anderen Dokumenten gibt.

Als nächstes können eine oder mehrere XML-Stilvorlagenverarbeitungsanweisungen folgen. Diese enthalten Verweise zu Stilvorlagen, mit denen die Darstellung des Dokumentes beeinflusst werden kann. Beispiele für Sprachen für Stilvorlagen sind CSS oder XSL (CSS – kaskadierende Stilvorlagen, englisch: Cascading StyleSheets, XSL – erweiterbare Stilvorlagensprache, englisch: eXtensible Stylesheet Language).

Darauf kann ein sogenannter 'doctype' folgen. Dies ist eine Dokumenttypdeklaration, die angibt, welches das Hauptelement des Dokumentes ist und entweder direkt definiert, welche Elemente auftreten können, oder auch auf eine Quelle verweist, in der dies formal beschrieben ist. Diese Beschreibung ist in einer Schemasprache maschinenlesbar angelegt. Weil die per Dokumenttypdeklaration verwendbare Schemasprache, welche selbst kein XML ist, deutliche Grenzen darin aufweist, was man wie genau über die zu definierende Sprache aussagen kann, gibt es auch einige andere Schemasprachen mit mehr Möglichkeiten. Da diese immer noch sehr beschränkt sind, werden neuere Formate auch zunehmend nur noch oder vorrangig mit einem Prosa-Dokument beschrieben. Dann kann die Dokumenttypdeklaration entfallen (wie etwa in SVG tiny 1.2). Die Dokumenttypdeklaration kann aber dennoch zusätzlich genutzt werden, um Abkürzungen anzugeben (sogenannte Entitäten, englisch: entities).

Auf den 'doctype' folgt das Hauptelement des Dokumentes, welches alle weiteren Elemente des Dokumentes enthält. Es gibt genau ein Hauptelement pro Dokument mit dieser ausgezeichneten Position im Quelltext (englisch: root). Je nach verwendeter Sprache kann das für das Hauptelement verwendete Element auch mehrmals im Dokument auftauchen. Dies kann zum Beispiel in SVG mit dem Element svg passieren.

Zumeist wird die Sprache oder das Format einem Namensraum zugeordnet. Der Namensraum kann mit dem Attribut xmlns angegeben werden. Dies schließt auch eine Notation mit einem Präfix mit ein, was hilfreich ist, wenn ein Dokument Elemente oder Attribute aus verschiedenen Namensräumen enthält. Das ist dann ein gemischtes Dokument oder ein Dokument, welches mehrere XML-Formate enthält (englisch auch compound-document).

Als Beispiel sei hier ein einfaches, nahezu leeres SVG-Dokument angegeben:

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

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="200px" height="200px" viewBox="0 0 200 200"
  xmlns="http://www.w3.org/2000/svg" version="1.1" baseProfile="tiny"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xml:lang="de">

<title>Beispiel für ein SVG-Dokument</title>
<desc>SVG-Beispiel eines Grundgerüstes baseProfile tiny</desc>
</svg>

Es beginnt also mit der XML-Verarbeitungsanweisung, in der XML-Empfehlung auch XML-Deklaration genannt, welche angibt, dass die Version 1.0 von XML verwendet wird, ferner die Kodierung iso-8859-1. Dann folgt die Dokumenttypdeklaration. Das Hauptelement ist bei SVG-Dokumenten das Element svg, dies hat Attribute, hier width, height, viewBox, version, baseProfile. Dazu kommt noch ein Attribut xml:lang, welches die im Dokument verwendete Sprache festlegt. Das Präfix (Vorsilbe) 'xml' gibt an, dass dieses Attribut ganz allgemein für alle XML-Formate bereits in der XML-Spezifikation definiert ist (siehe unten), also selbst ohne Kenntnis des Einzelformates eine bekannte Bedeutung hat. xmlns="http://www.w3.org/2000/svg" ist die Angabe zum Namensraum von SVG. Da hier kein Präfix angegeben ist, bedeutet dies, dass das Element svg selbst, seine Attribute und Kindelemente zu diesem Namensraum gehören, sofern es keine anderen Angaben gibt. Mittels xmlns:xlink="http://www.w3.org/1999/xlink" wird ein anderer Namensraum für die Sprache XLink angegeben (eine Sprache zur Auszeichnung von Verweisen; englisch: XML Linking Language), hier mit dem Präfix 'xlink'. Im Dokument können also Elemente oder Attribute aus diesem Namensraum auftauchen, die werden dann mit diesem Präfix angegeben. In SVG taucht besonders häufig xlink:href auf, um ein Beispiel für ein Attribut zu nennen (die Sprache XLink hat nur Attribute, keine Elemente).

Im Hauptelement svg sind die Kindelemente title und desc notiert, die in diesem Falle keine Attribute angegeben haben und nur Text als Inhalt enthalten.

XML-Deklaration und Verarbeitungsanweisungen

Zu Beginn eines XML-Dokumentes findet man im Allgemeinen eine XML-Deklaration, die der Notation einer Verarbeitungsanweisung folgt, gemäß XML aber eigentlich keine ist, sondern eben angibt, dass es sich um ein XML-Dokument handelt, es also nach den Regeln von XML zu verarbeiten ist. Der Unterschied in der Bezeichnung und Nutzung ist in der Praxis nicht relevant.

Oft kommt darin auch eine Angabe zur Kodierung vor. Ein offensichtliches Problem dabei ist, dass bis zu der Stelle, wo die Angabe erfolgt, das Dokument schon dekodiert sein muss, um die Angabe berücksichtigen zu können. Das typische Vorgehen besteht darin, dass das Programm erstmal eine Kodierung rät und guckt, ob damit der Dokumentinhalt einen Sinn ergibt. Wird so die erste Zeile eines Dokumentes dekodiert, in der die XML-Deklaration steht, kann gegebenenfalls die Dekodierung noch angepasst werden. Das liegt daran, dass die Angaben in der XML-Deklaration so ausgelegt sind, dass sie bei gängigen Kodierungen gleich ausfallen, also keine kritischen Sonderzeichen enthalten. Liegt keine Angabe vor, wird eine Kodierung als UTF-8 angenommen. Ein anderes Vorgehen kann sich ergeben, wenn das Dokument von einem Dienstrechner (englisch: server) kommt. Dieser kann verbindlich die Kodierung des Dokumentes angeben, wonach sich ein Darstellungsprogramm zu richten hat. Das vermeidet das Problem, dass die Datei bereits dekodiert sein muss, bevor man die Angabe zur Kodierung erhält. Gibt der Server eine Kodierung an, so wird die Angabe im Dokument ignoriert.

XML-Stilvorlagenverarbeitungsanweisungen können auf die XML-Deklaration folgen und referenzieren dann externe Dateien, in denen Stilvorlagen notiert sind.

Typische Beispiele

Nur eine Angabe, dass nach XML1.0 zu interpretieren ist. Sofern keine anderen Angaben gemacht wurden, wird UTF-8 als Kodierung unterstellt:

<?xml version="1.0" ?>

Zusätzliche Angabe der Kodierung als iso-8859-1 (das reicht für Umlaute, ß-Ligatur und einige andere Sonderzeichen aus dem europäischen Sprachraum):

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

Beziehungsweise wenn man das Euro-Zeichen braucht, kann auch iso-8859-15 verwendet werden:

<?xml version="1.0" encoding="iso-8859-15" ?>

Eine Kodierung mit UTF-8 eignet sich für die meisten Sprachen und kann insbesondere empfohlen werden, wenn neu angefangen wird und keine Altlasten mit anderer Kodierung bereits vorhanden sind.

<?xml version="1.0" encoding="UTF-8" ?>

Zu beachten ist, dass einige Editoren bei UTF-8 an den Beginn einer Datei bisweilen ein BOM setzen (Byte-Anordnungsmarkierung, englisch: byte order mark). Das ist für UTF-8 nicht unbedingt notwendig, weil dort die Anordnung der Bytes eindeutig ist. Dies kann aber mit der Forderung kollidieren, dass zu Beginn des Dokumentes die XML-Deklaration stehen soll. Entwicklern einiger Programme ist das Problem bekannt und sie umgehen es, indem sie das vorangestellte BOM hinsichtlich der Forderung ignorieren, dass die XML-Anweisung zu Beginn des Dokumentes stehen soll. Bei anderen Programmen oder älteren Versionen kann es hingegen passieren, dass versucht wird, das BOM zur Anzeige zu bringen, statt ein XML-Dokument zu verarbeiten. Deswegen ist es in der Praxis empfehlenswert, dem Editor nicht zu erlauben, ein BOM an den Anfang einer mit UTF-8 kodierten XML-Datei zu setzen.

Folgendes ist ein Beispiel mit XML-Stilvorlagenverarbeitungsanweisungen. Hier werden CSS-Dateien referenziert. Zudem gibt es drei verschiedene Vorlagen. Das Darstellungsprogramm sollte einen Auswahlmechanismus bereitstellen, um zwischen den drei Möglichkeiten zu wechseln (ist zum Beispiel mit Mozilla-Geckos oder Opera auch nachvollziehbar).

<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet href="css1.css" type="text/css" title="Stil 1"?>
<?xml-stylesheet href="css2.css" type="text/css" title="Stil 2"
   alternate="yes" ?>
<?xml-stylesheet href="css0.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 (ehemals MIME-Typ). Die Angabe des Attributes ist 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.

Dass 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, dass dies die Voreinstellung ist. Der Attributwert 'yes' gibt eben an, dass es sich um eine alternative Stilvorlage handelt. 'no' würde angeben, dass 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. Der Hinweis ist allerdings nur relevant, wenn es keine anderen bindenden Informationen gibt, zum Beispiel von einem Server, der 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 voneinander separiert sind. Welche Medientypen verfügbar sind, hängt von der verwendeten Stilvorlagensprache ab. CSS2 gibt zum Beispiel folgende Möglichkeiten an:

all: Für alle Ausgabemedien geeignet.
aural: Für eine akustische Wiedergabe vorgesehen.
braille: Für Braille-Geräte vorgesehen.
embossed: Für Braille-Seitendrucker vorgesehen.
handheld: Für Handheld-Geräte vorgesehen (normalerweise mit kleinem Schwarzweißbildschirm und begrenzter Bandbreite).
print: Für Drucker vorgesehen, ebenso für den Druckvorschaumodus auf dem Bildschirm.
projection: Für projizierte Präsentationen vorgesehen, wie zum Beispiel Projektoren oder den Ausdruck auf Folien.
screen: Hauptsächlich für normale Farbmonitore vorgesehen.
tty: Für Medien vorgesehen, die ein festes Zeichenraster verwenden, wie beispielsweise Fernschreiber oder Terminals.
tv: Für fernsehartige Geräte vorgesehen (geringe Auflösung, begrenzt rollbare Bildschirme, aber in Farbe und mit Ton).

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 Notebooks oder Mobiltelephonen die typischen Abmessungen von Höhe und Breite erheblich von denen von früheren Monitoren ab (auch im Seitenverhältnis).

Dokumenttypdeklaration und Dokumenttyp-Definition

Die Dokumenttypdeklaration kann hilfreich sein, wenn mit einem Validator 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. In SVG etwa kann mittels der DTD nicht überprüft werden, ob ein Autor Pfade oder Animationswerte 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 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 SVG 1.1 dient die Deklaration auch den Angaben der Version und des Profiles der Sprache. Alternativ kann das dort auch mit Attributen getan werden, letzteres ist dann die in SVG tiny 1.2 mögliche Methode, um eindeutig festlegen zu können, welche Version und welches Profil verwendet wird.

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, dass aktuell real existierende Programme einfach nicht so ausgelegt sind, dass 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, dass sich bei einer inkompatiblen Änderung der Spezifikation die Bedeutung von solchen Dokumenten ändern können. 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.

Typische Beispiele

SVG tiny 1.1 (aus der Empfehlung):

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG Tiny 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd">

Die vom Validator des W3C bevorzugte Variante ist allerdings:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1 Tiny//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd">

SVG 1.1:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

In SVG tiny 1.2 ist kein doctype mehr vorgesehen. Ein solcher kann aber für Erweiterungen weiterhin genutzt werden. Hier wird die Erweiterung (ENTITY) 'Pfad' definiert, eine Abkürzung für das, was hinter 'Pfad' in Anführungsstrichen 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 der Zeichenkette dürfen natürlich nur Zeichen stehen, die nicht mit der Syntax im Konflikt stehen, hier also keine doppelten Anführungszeichen.

Das Analogon entsprechend für SVG 1.1:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"
   [<!ENTITY Pfad "M200,300 L300,100">
   ]
>

Namensräume

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 muss 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, dass 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 Namensraum verwendet, damit die Zuordnung eindeutig ist. Andere eindeutige Zeichenketten sind aber nicht ausgeschlossen. Bei einer URI ist es meist üblich, dass man dort zumindest Angaben darüber findet, um was für ein Format es sich handelt.

Häufig auftauchende 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: http://purl.org/dc/elements/1.1/

Es gibt zwei Möglichkeiten, ein Element einem Namensraum zuzuordnen. Nur eine davon eignet sich auch, um Attributen einen Namensraum zuzuordnen.

Bei der ersten Methode, die sich nur für Elemente eignet, wird ein Namensraum voreingestellt. Der Namensraum wird mit dem in XML selbst definierten Attribut xmlns angegeben. Beispiel, um den SVG-Namensraum als voreingestellt anzugeben:
xmlns='http://www.w3.org/2000/svg'

Dieser voreingestellte Namensraum gilt dann für das Element und seinen Inhalt, sofern dieser keinem eigenen Namensraum zugeordnet wird. Es gilt also immer der voreingestellte Namensraum, welcher beim Element selbst notiert wird oder sofern dies nicht passiert ist, der voreingestellte des Elternelement und so weiter durch alle Vorfahren, falls beim jeweiligen Elternelement selbst kein Namensraum voreingestellt wird. Ist die Suche bis hinauf zum Wurzelelement einschließlich diesem erfolglos, gibt es keinen voreingestellten Namensraum, man sagt auch, die Elemente befinden sich im Null-Namensraum.

Bei der zweiten Methode kann man bei einem Element einem Präfix einen Namensraum zuordnen. Dieses Präfix kann man dann bei dem Element selbst, seinen Attributen und seinen Nachfahren und dessen Attributen verwenden, um deren Namensraumzugehörigkeit anzugeben. Das Präfix ist also im Bedarfsfalle immer explizit anzugeben und wird nie impliziert. Wird ein Präfix verwendet, ist dies den Elementnamen und Attributnamen jeweils voranzustellen, dazwischen wird ein Doppelpunkt notiert. Das Präfix selbst wird definiert, indem man als Attribut xmlns angibt, gefolgt von einem Doppelpunkt, gefolgt von einer Zeichenfolge, die als Präfix verwendet werden soll, darauf folgt die Wertzuweisung mit einem Gleichheitszeichen und einer Namensraumangabe als Wert in Anführungszeichen entsprechend der ersten Methode. Beispiel, um dem Präfix 'xlink' den Namensraum von XLink zuzuordnen:
xmlns:xlink="http://www.w3.org/1999/xlink"

Beispiel zur Verwendung:

<?xml version="1.0" encoding="iso-8859-1" ?>
<svg viewBox="-100 -100 200 200"
  xmlns="http://www.w3.org/2000/svg" version="1.1"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xml:lang="de">

<title>Beispiel für ein SVG-Dokument mit Verweis</title>
<desc>
<h:p xmlns:h="http://www.w3.org/1999/xhtml" >
Im Wurzelelement wird der Namensraum für <h:em>SVG</h:em> voreingestellt.
Ebenso wird dort der Präfix für den Namensraum von <h:em>XLink</h:em> 
festgelegt, welches im Inhalt sodann verwendet wird, um auf wikibooks 
mittels eines Kreises zu verweisen.<h:br />
Dieser Absatz gehört per Präfix, welches im selben Element zugeordnet wird, 
zum Namensraum von <h:em>XHTML</h:em>.<h:br />
Ein paar Elemente in diesem Absatz verwenden das gleiche Präfix, 
gehören also ebenfalls zum Namensraum von <h:em>XHTML</h:em>.
</h:p>
</desc>

<a xlink:href="https://de.wikibooks.org" 
   xlink:title="Zu den deutschen wikibooks">
 <circle r='50' fill='#ccf' stroke='#00f'>
  <title>Knopf</title>
  <desc>
   <div xmlns="http://www.w3.org/1999/xhtml">
    <p>
     Durch aktivieren des Knopfes 
     kann zu den deutschen wikibooks gewechselt werden.
    </p>
    <p>
     Der voreingestellte Namensraum dieses Absatzes 
     und des vorherigen ist der von <em>XHTML</em>.<br />
     Daher gehören die in diesem Element ohne 
     Namensraumangabe notierten Elemente
     ebenfalls zum Namensraum von <em>XHTML</em>.
    </p>
   </div>
  </desc>
 </circle>
</a>

</svg>

Der Autor selbst legt das Präfix fest. Hinsichtlich XLink in SVG ist allerdings das Präfix 'xlink' dringend zu empfehlen, weil einige Darstellungsprogramme Mängel in der Interpretation von Namensräumen aufweisen und dieses Präfix wegen seiner Erwähnung in der DTD von SVG 1.1 durchgehend getestet ist.

Insgesamt also: Ist bei einem Element kein Namensraum und kein Präfix angegeben, so gehört es zum voreingestellten Namensraum des Elternelementes, sofern dies zu einem voreingestellten Namensraum gehört. Typisch wird etwa bei Dokumenten, die nur ein Format verwenden, der Namensraum im Hauptelement angegeben, womit die Angabe dann für alle Nachfahren gilt, sofern die keine eigenen Angaben zum Namensraum machen. Elemente mit Präfix beziehen den zugehörigen Namensraum über das Präfix, der zuvor oder im selben Element zu definieren ist. Der so zugeordnete Namensraum gilt nicht automatisch für Kindelemente.

Bei Attributen ist die Lage formal etwas komplizierter, weil sie nicht direkt zu einem Namensraum gehören, wenn für sie mittels Präfix keiner angegeben ist. Allerdings werden die Attribute dann in dem Namensraum definiert und interpretiert, der zu dem Element gehört, in dem sie notiert sind. Will man ein Attribut explizit einem Namensraum zuordnen, geht das nur über ein vorangestelltes Präfix. Attribute ohne Präfix befinden sich also im Null-Namensraum, ihre Bedeutung kann nur vom Element her impliziert werden, in welchem sie notiert sind.

Etwa bei der deklarativen Animation von SVG kann es notwendig sein, dass Attributnamen samt Namensraumzugehörigkeit als Werte anderer Attribute anzugeben sind. In solchen Fällen ist in dem jeweiligen Format, hier also SVG, festgelegt, wie dabei Präfixe zu interpretieren sind und die Attribute zu identifizieren sind.

Elemente und Attribute

Das prinzipielle Konzept von XML-Formaten liegt darin, Inhalte auszuzeichnen. 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 Rechtecke 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 können also zwei komplett verschiedene Elemente sein.

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 davon 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 eingeführt (siehe unten). Hier ist der Wert des Attributes sorte eben 'Boskop' und der von zustand 'reif'.

In obigem Beispiel ist dann

<kern /><fruchtfleisch>lecker</fruchtfleisch>

der Inhalt von apfel. 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 nicht mehr interpretiert. Text, der PCDATA genannt wird, wird interpretiert, also darin vorkommende Entitäten oder auch Markierungen werden interpretiert.

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

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, dass 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 verfasst ist.

Attribute und Entitäten von XML

In XML sind bereits einige Attribute vordefiniert. Diese werden mit dem ebenfalls bereits in XML fest vorgegebenem Präfix 'xml' notiert.

Ein Attribut ist xml:lang zur Kennzeichnung der Sprache, die im jeweiligen Element verwendet wird. Der Wert ist eine mit Leerzeichen separierte Liste von Sprachkennungen wie 'de' (deutsch) oder 'en' (englisch) oder auch 'en-us' (englisch im amerikanischen Dialekt). Siehe auch BCP47.

Ein weiteres ist xml:space mit den Werten 'preserve' oder 'default'. Dies hat Einfluss auf die Interpretation von Leerraum (Leerzeichen, Zeilenumbrüche) im Textinhalt. Bei 'preserve' wird der Leerraum in der Präsentation erhalten. Bei 'default' werden bei der Präsentation mehrere aufeinanderfolgende Leerzeichen oder Zeilenumbrüche zu einem Leerzeichen zusammengefasst. Je nach Format (besonders bei einem graphischen wie SVG) kann es weitere Angaben in der Spezifikation geben, wie mit Textinhalt im Detail umzugehen ist, wie es zum Beispiel mit Hilfe von Glyphen zu einer graphischen Repräsentation des Textes kommt.

xml:base gibt als Wert die Basis-URI an, von der aus Pfadangaben zu absoluten URIs aufgelöst werden sollen. In der Praxis problematisch kann dieses Attribut sein, wenn vom Autor nur Fragmentidentifizierer oder Bezeichner in einem Attribut angegeben werden, welches zu einer absoluten URI aufzulösen ist.

xml:id ist ein dokumentweit eindeutiger Bezeichner oder Fragmentidentifizierer für das Element, entsprechend den Attributen id in (X)HTML oder SVG. In SVG ist die Verwendung dieses erst spät in XML eingeführten Attributes erst in SVG tiny 1.2 alternativ zu id vorgesehen. Der Vorteil gegenüber formatspezifischen Bezeichnern wie id liegt darin, dass die Bezeichner formatübergreifend gelten und auch Fragmente in Formaten referenzierbar sind, ohne dass das genaue Format dem Darstellungsprogramm bekannt sein müsste.

Als Entitäten (maskierte Zeichen) sind in XML vordefiniert, was in Konflikt mit der Notation geraten kann:

& (&)
< (<)
> (>)
' (')
" (")

Weitere Details über XML kann man im Wikibuch XML lernen.

Vorwort Kurze Einführung in XML Vektorgraphik Programme rund um SVG