Scriptum zur Vorlesung XML Dokumente und Daten...

Das Akronym XML ist derzeit in aller Munde...
Es hat Einzug in fast jede Produktankündigung jüngerer Zeit gefunden, und keine neuere IT-Entwicklung, die nicht XML enabled wäre.

Es scheint, daß sich anhand XML dieselbe übersteigerte (und nicht notwendigerweise immer mit wahrheitsgemäßen Versprechungen arbeitende) Marketing-Euphorie (engl. hype) vollzieht, die bereits für das Schlagwort Objektorientierung zu beobachten war.
Die fachlichen Einschätzungen des Themas XML reichen von ASCII des 21 Jahrhunderts (H. S. Thomson) bis hin zur (berechtigten) kritischen Hinterfragung des Neuheitswertes, insbesondere im Vergleich zu bekannten Lösungen wie troff, LaTeX oder das Rich Text Format (RTF).

Zur Illustration der Bandbreite der Bedeutungs- und Anwendungszuschreibungen die XML zuteil werden sind nachfolgend einige willkürlich ausgewählte Pressezitate versammelt:

Schon die Spannweite dieser Definitionen läßt die Bedeutung des Themas XML erahnen. Hervorzuheben ist, daß sich offensichtlich nicht nur technisch-fokussierte Blätter des dreibuchstabigen Akronyms annehmen.
Allgemein scheint XML vorzugsweise im Kontext World Wide Web (manchmal auch schlicht zum Internet verallgemeinert) Beachtung zu finden.

Das erste Kapitel dieser Vorlesung bietet einen Einstieg in die XML-Welt anhand der zugrundeliegenden technischen Basiskonzepte.
Hierzu wird zunächst die Historie strukturierter Auszeichnungssprachen (engl. markup language) beleuchtet, und die Vorläufer der Markup-Sprache XML vorgestellt.
Desweiteren werden die grundlegenden syntaktischen Konstrukte des XML Standards anhand verschiedener Beispiele eingeführt. Die notwendige Begriffsbildung erfolgt auf Basis des XML Information Set .
Ein weiteres Teilkapitel motiviert die Notwendigkeit der XML-Namensräume zur Unterscheidung verschiedener XML-Vokabulare und als Voraussetzung der XML-basierten Inhaltssyndikatisierung.
Daran schließt sich die Betrachtung der Grammatik eines XML-Dokuments an. Hierzu wird der klassischen Mechanismus der Document Type Definitions (DTD) eingeführt. Schwerpunkt liegt jedoch auf der Diskussion der XML Schema Description Language (XSD), durch welche die strukturellen und inhaltlichen Ausdrucksmöglichkeiten der DTDs entscheidend erweitert werden.
Zum Abschluß des Kapitels wird mit der XML Hyper Text Markup Language (XHTML) die vermutlich bekannteste Auszeichnungssprache, welche zur Grundlage des World Wide Webs wurde, unter dem Blickwinkel XML besprochen.

Einführung und Überblick

Im Grunde besitzt die Geschichte der eXtensible Markup Language zwei Anfänge. Einerseits stellt XML die evolutionäre Fortentwicklung existierender generischer Auszeichungssprachen dar; andererseits sind die Hintergründe der Sprache XML so eng mit dem Aufkommen des World Wide Webs (WWW) verwoben, daß die Geschichte auch hier ihren Anfang nehmen könnte...

Der chronologischen Ordnung folgend sei zunächst die Entwicklung aus der Idee des Hypertext aufgerissen.
Die ersten Ideen zum Konzept des Hypertexts, als Plan zur Überwindung der Beschränkungen und Unzulänglichkeiten des klassischen textbasierten Publikationsmediums Papier, datieren zurück bis in die 1950er Jahre. Sie postulieren neben der nichtsequentiellen Organisation des Mediums auch zentrale Begriffe wie Knoten, Link, Anker und Netz. Ziel dieser Überlegungen war es, den auszudrückenden Inhalt von editorieller- und Präsentationsinformation wie Seitenzahlen, Fußnoten, Paginierung usw. zu trennen. Durch die nichtlineare Organisation soll es dem Leser freigestellt werden, auf welchen Pfaden er sich durch das Dokument bewegt.

Zur Realisierung dieser Bemühungen wird das Dokument mit weiteren Informationen angereichert, die jedoch für den Leser unsichtbar bleiben. Dieser Gedanke reicht zurück bis in die Anfänge des Buchdrucks. Dort sind formatierungsorientierte Auszeichnungssymbole, etwa für Fettdruck oder Unterstreichung, seit jeher bekannt. Vor dem Aufkommen der what you see is what you get Textverarbeitungssysteme waren diese bildlichen Symbole die einzige Möglichkeit zur Kommunikation präsentationsorientierter Information an den Schriftsetzer und Drucker.
Jedem Schüler ist bereits ein weiteres Beispiel einer editoriellen Auszeichnungssprache bekannt: Die graphischen Korrekturzeichen der Deutschlehrer. Auch sie liefern Informationen über den Inhalt, die nicht Bestandteil des Dokuments sind.

Voraussetzung für die angestrebte Flexibilisierung der Struktur eines Textes ist eine -- wie auch immer geartete -- technische Unterstützung. Seit den 60er Jahren wurden hierfür die aufkommenden elektronischen Rechenanlagen herangezogen. Eine der ersten Aktivitäten hierzu ist das von Ted Nelson initiierte (inzwischen legendäre) Xanadu-Projekt.

Zunächst erforderte die maschinelle Verarbeitung die Überarbeitung des Auszeichnungssymbolvorrates. Dies wurde notwendig, da eingesetzte Technik keine Unterstützung der alt-hergebrachten graphischen Auszeichungssymbole bot.
In einem ersten Entwicklungsschritt wurden daher die vormalig bildhaften Zeichen durch textuelle Pendants ersetzt und verallgemeinert. Beispielsweise: Überschrift zur inhaltlichen Kennzeichnung einer entsprechenden Textzeile.
Mit diesem Schritt erfolgte auch der Übergang zur formatierungsunabhängigen Auszeichnung, die bewußt auf die Beschreibung des späteren visuellen Aussehens der Information zugunsten einer neutralen deskriptiven Beschreibung der Semantik verzichtete.

In den 60er und 70er Jahren werden verschiedene Weiterentwicklungen der generischen Auszeichnungssprachen betrieben; u.a. bei der IBM durch das Team um Goldfarb, Mosher und Loire. Sie stellen 1969 unter dem Namen Generalized Markup Language einen Sprachvorschlag zusammen, der in der Folgezeit durch IBM kommerziell vermarktet wird.

Aus den GML-Aktivitäten bei IBM entwickelt sich die internationale Standardisierungsbewegung der Standard GML (SGML).
Durch sie wird eine Sprache festgelegt, welche die Definition eigener Sprachen erlaubt; daher auch der Begriff Metasprache. SGML bietet somit keinen feststehenden problemspezifischen Sprachumfang an, sondern eine Menge verschiedenster struktureller Konstrukte zur Formulierung von Dokumentgrammatiken.
In der Praxis wird der Einsatz einer mit Hilfe von SGML definierten Sprache oftmals plakativ zum Einsatz von SGML verkürzt, obwohl diese Begrifflichkeit lediglich den Erstellungsprozeß der Grammatik bezeichnet.

Mittels SGML definiert Tim Berners-Lee Mitte der 80er Jahre eine eigene Sprache zur vereinfachten Formulierung von Dokumenten, die er HyperText Markup Language (HTML) nennt. Hauptbeweggrund seiner Aktivitäten ist der Versuch den Dokumentenaustausch am Europäischen Kernforschungszentrum CERN rechnergestützt zu vereinfachen.
Die Eingangs erwähnten zentralen Hypertextkonzepte finden sich bereits in seinem ersten Sprachvorschlag wieder. Zur technischen Realisierung der Verknüpfung zwischen den Dokumenten mittels Ankern und Links definiert er den Uniform Resource Locator (URL), eine global eindeutige Adresse für beliebige Inhalte.

Seine Aktivitäten in Genf bilden die Keimzelle des Web.

In der Folgezeit, insbesondere im Zuge der Kommerzialisierung des Word Wide Web, entstehen verschiedene Revisionen der ursprünglichen HTML. Einige der Erweiterungen werden durch die beiden großen Web Browser Hersteller Microsoft und Netscape proprietär vorgenommen, um ihre Position am Markt zu stärken.
In der Konsequenz entstehen während des oft apostrophierten browser war teilweise inkompatible HTML-Dialekte. (Man denke nur an die Tags: marquee (nur Microsoft Internet Explorer) oder layer (nur Netscape Navigator))
Darüberhinaus entwickelt sich HTML zunehmend von einer Präsentations-orientierten Auszeichnungssprache zu einer semantischen. Dies bedeutet: während HTML in der ersten Grundform zunächst überwiegend Elemente bot, durch die die Präsentation der Inhalte am Bildschirm festgelegt wurde (Beispiele: b für Fettdruck, u für Unterstreichungen oder i für Kursivschreibung), wurden später zunehmend semantische Elemente eingeführt. Durch sie wird die Bedeutung der ausgezeichneten Information ausgedrückt (Beispiele hierfür: acronym zur Kennzeichnung von Abkürzungen, address für Adressen oder strong zur besonderen Betonung einer Textpassage).

So wünschenswert die sukzessive Umgestaltung der HTML an die veränderten Bedürfnisse war, so aussichtslos waren die Bemühungen dennoch. Während bei den Präsentations-orientierten Elementen zunehmend Vollständigkeit hinsichtlich der Anwenderwünsche erzielt werden konnte, offenbaren sich die bisher erfolgten semantischen Erweiterungen als permanent inadäquat.
Letztlich war der Versuch, durch Standardisierung, semantische Erweiterungen in HTML einzubringen in doppelter Hinsicht zum Scheitern verurteilt:
1. birgt der Ansatz die Gefahr, die Elementmenge in unbekannte Größen zu erweitern
2. muß die Semantik jedes Tags definiert, abgestimmt und verabschiedet werden.

Aus diesen Gründen wurde seitens des W3C nach einer tragfähigeren Lösung gesucht. Unter Rückgriff auf die HTML-Wurzeln (als Anwendung der Metasprache SGML) wurde das Projekt SGML for the Web initiiert.
Der letztendlich verabschiedete Vorschlag zur eXtensible Markup Language (XML) bildet konzeptionell eine Untermenge der Sprachmöglichkeiten von SGML. Konsequenterweise ist jedes XML-Dokument auch ein gültiges SGML-Dokument.

Die Abweichung zu SGML wird besonders aus den Entwicklungszielen für XML deutlich:

  1. Einfache Nutzung im Internet.
    In Abkehr von den Hauptnutzung SGMLs als offline Dokumentationsformat wird die Untermengenbildung XML für die primäre Nutzung im Internet vorgenommen.
  2. Unterstützung eines breiten Anwendungsspektrums.
    Auch hier soll die Untermengenbildung das Einsatzspektrum über die Hauptnutzung SGMLs als Format der technischen Dokumentation hinaus befördern.
  3. SGML Kompatibilität.
    XML bildet eine echte Untermenge des ISO-Standards SGML, durch diesen Schritt kann jedes XML-Dokument auch als gültiges SGML-Dokument interpretiert und durch die entsprechenden SGML-Werkzeuge verarbeitet werden.
  4. Einfache Applikationsentwicklung.
    Die Untermengenbildung wird im Hinblick auf eine gegenüber SGML deutlich vereinfachte Entwicklung von XML verarbeitenden Applikationen vorgenommen.
  5. Minimierung optionaler Sprachmerkmale -- Idealerweise gleich Null.
    Auch dieses Ziel ist im Hinblick auf eine vereinfachte Applikationsentwicklung, aber auch eine einfachere Benutzbarkeit durch Menschen auf dem Wege der Komplexitätsreduktion zu interpretieren.
  6. Lesbarkeit.
    Das entstehende Textformat soll für Menschen und Maschinen gleichermaßen les- und verstehbar sein.
  7. Kompakte Spezifikation.
    Die erstehende XML-Spezifikation sollte deutlich weniger Umfang aufweisen als der SGML-Vorgängerstandard. Letztlich konnte die reine Seitenzahl von über 600 Seiten für die SGML-Spezifikation auf ungefähr 30 Seiten für XML reduziert werden.
  8. Formaler und präziser Sprachentwurf.
    Um die schnelle Akzeptanz seitens der Anwender zu forcieren erachteten die Mitglieder der XML-Arbeitsgruppe die schnelle Verfügbarkeit von XML-Werkzeugen für essentiell. Aus diesem Grunde sollte der XML-Sprachentwurf möglichst leicht und eindeutig in XML-Werkzeuge zu implementieren sein.
  9. Leichte Dokumenterstellung.
    Die Erstellung von korrekten XML-Dokumenten sollte idealerweise so einfach sein, daß hierfür keine speziellen Werkzeuge benötigt werden.
  10. Nicht notwendigerweise knappes Markup.
    Kompaktheit und Effizienz hinsichtlich des Volumens eines XML-Dokuments war zu keinem Zeitpunkt eines der Hauptentwicklungsziele. Auf der Basis des XML-Information Sets ist es jedoch möglich beliebig kompakte Binärformate identischer Mächtigkeit zur die in der XML-Spezifikation vorgestellten Textnotation zu definieren.

XML stellt jedoch keine echte semantische Auszeichnungssprache dar, da durch die Metasprache lediglich eine Möglichkeit zur Formulierung eigener Syntax gegeben ist. Die Bedeutung der Elemente bleibt jedoch unberücksichtigt, und kann mittels XML nicht ausgedrückt werden.

Jahr Ereignis 1945 Vannevar Bush diskutiert in seinem Artikel As We May Think ein persönliches Informationssystem mit Kommunikationsmöglichkeiten und Zugriff auf Bücher, Tonaufnahmen, etc. unter dem Namen Memex. 1967 William Tunnicliffe (Chairman des Graphic Communications Association (GCA) Composition Committee) schlägt aus seinen Erfahrungen bei der wiederholten Erstellung von Telephonkatalogen (yellow pages) vor, häufig auftretende strukturelle Elemente zu standardisieren. September 1967 William Tunnicliffe (Vorsitzender der Graphic Communication Association) spricht sich auf einer Konferenz des Printing Office der Regierung von Kanada für die Separierung von Inhalt und Format aus. Ende der 1960er Jahre Stanley Rice, ein New Yorker Schriftsetzer, schlägt editorial structure tags vor.
Der CGA-Direktor Norman Scharpf initiiert das Projekt GenCode. 1969 Charles Goldfarb, Edward Mosher und Raymond Lorie entwickeln bei der IBM die Generalized Markup Language (GML).
Anwendungshintergrund war ein Projekt zur Integration von Informationssystemen für Anwaltskanzleien. 1970 Goldfarb formuliert zwei Grundprinzipien generalisierter Auszeichungssprachen:
1) Auszeichnungssprachen beschreiben die Dokumentstruktur, nicht die physischen Charakteristika wie Präsentation
2) Die Struktur der Auszeichnungssprache soll so gewählt sein, daß sie sowohl von Menschen als auch Maschinen interpretiert werden kann 1978 ANSI ruft Computer Languages for the Processing of Text-Komitee ins Leben.
Ziel ist die Weiterentwicklung der GML zu einem nationalen US-Standard. 1980
  • ANSI veröffentlicht ersten Entwurf einer standardisierten GML (SGML).
  • Tim Berners-Lee tritt seine Arbeit am Europäischen Kernforschungszentrum CERN an.
    Dort entwickelt er in der Folgezeit die (niemals veröffentlichte) Hypertextanwendung Enquire.
 1983 Der International Revenue Service (IRS) und das US Verteidigungsministerium (DoD) übernehmen den sechsten Entwurf zur SGML (auch bekannt als GCA 101-1983). 1984 Die SGML-Arbeitsgruppe nimmt unter Schirmherrschaft der International Standardization Organization (ISO) als ISO/IEC JTCI/SC18/WG8 ihre Arbeit auf.
Goldfarb dient als technical leader der ISO-Gruppe, sowie dem umorganisierten ANSI-Komitee X3V1.8. 1985 Norm-Entwurf zu SGML veröffentlicht. 15. Oktober 1986 ISO verabschiedet SGML als ISO 8879:1986. März 1989 Berners-Lee schlägt mit dem Dokument Information Management: A Proposal ein SGML-basiertes Hypertext-System zum Informationsaustausch vor. 1990 Am Weihnachtstag nimmt das World Wide Web seinen Betrieb mit zwei Maschinen am CERN auf.
Die notwendigen Implementierungen von HTML, HTTP und URL erfolgten durch Berners-Lee. Die erste WWW-Verbindung wird zwischen Berners-Lees Workstation und Robert Cailliaus' NeXT-Rechner aufgebaut.
Ein Screenshot des ersten Web-Browsers
NeXTStep-Implementierung des Browsers 1991 Beginn der turnusmäßigen Überarbeitungsphase von ISO 8879. 3. November 1992 Erster Entwurf zu HTML Juni 1993 Einreichung des ersten HTML Entwurfs bei IETF. Oktober 1994 Gründung World Wide Web Consortium 14. November 1996 Erster Entwurf zu XML vorgestellt 14. Januar 1997 Verabschiedung der HTML v3.2 1998 W3C gibt die erste Version von XML als Recommendation frei. 2000
  • W3C gibt XHTML v1.0 -- die Reformulierung von HTML v4.01 zu einer XML-Anwendung -- frei.
  • W3C verabschiedet XML 2nd edition; sie integriert u.a. die XML Namespaces und behebt einige editorielle Fehler.
 2. Mai 2001 Das W3C verabschiedet den XML Schema-Standard.
Er geht an vielen Stellen deutlich über die ererbten SGML-Möglichkeiten hinaus, und markiert den Übergang von Präsentations-orientierten Strukturen hin zu Datenstrukturen.

Zum Abschluß dieser Einführung seinen die zehn Punkte zusammengestellt und kommentiert, die durch das World Wide Web Consortium als plakative Kurzcharakterisierung von XML veröffentlicht wurden:

  1. XML steht für strukturierte Daten.
    Diese Aussage betont die Rolle von XML als Sprache um Sprachen zu erzeugen. Nicht XML wird innerhalb verschiedenster Applikationen direkt verarbeitet, sondern XML basierte Formate. So steht nicht die XML selbst für all diese Anwendungsdomänen, sondern die jeweiligen problemspezifischen XML-basierten Sprachen. XML selbst dient lediglich der Strukturierung der verschiedensten darzustellenden Daten.
    Gleichzeitig rückt durch Aussage die Rolle der XML als Datenformat in den Vordergrund und läßt so die Weiterentwicklung gegenüber den präsentationsorientierten Vorläufern deutlich werden.
    Die Vorlesungskapitel Strukturelle Grundkonzepte, Dokument-Typ-Definitionen sowie XML Schemasprachen vermitteln einen Eindruck dieses Wandels und dokumentieren die Grundlagen des gegenwärtigen datenorientierten Einsatzes der XML.
  2. XML sieht ein wenig wie HTML aus.
    Diese Aussage soll offenkundig einerseits den bisherigen HTML-verwendenden Web-Autoren den Einstieg in die XML schmackhaft werden lassen. Dennoch führt sie ein wenig von der Grundidee XMLs als generischer Auszeichnungssprache für beliebigste Anwendungen weg, indem sie den Blick auf HTML focussiert.
    Die -- im Grunde der Verwandschaft zu SGML geschuldete -- offensichtliche syntaktische Ähnlichkeit zu HTML wird bereits bei der Betrachtung der strukturellen Grundkonzepte deutlich.
  3. XML ist Text, aber nicht zum Lesen.
    XML-Dokumente können sicherlich im wörtlichen Sinne gelesen werden ... Die Aussage zielt jedoch auf den intendierten Einsatzzweck von XML: der Darstellung von Daten für den Austausch zwischen Maschinen. Unbenommen dessen kann XML selbstverständlich auch von Menschen gelesen und verstanden werden, wenngleich dies bei umfangreicheren XML-Dokumenten durchaus mühsam werden kann.
    Aufschluß über die textuelle Natur XMLs, insbesondere im Hinblick auf die Verwendung unterschiedlicher Alphabete, liefert das Kapitel strukturelle Grundkonzepte.
  4. XML ist vom Design her ausführlich.
    Hiermit wird versucht dem häufig geäußerten Kritikpunkt der Platzzunahme XML-codierter Inhalte gegenüber klassischen Darstellungsweisen etwas pauschal entkräftend entgegenzutreten. Sicherlich geht das W3C in dieser Aussage nicht fehl, wenn die Entwicklung der Netzwerkbandbreiten, der CPU-Leistung und der Speicherkapazitäten berücksichtigt. Andererseits ist die Aufblähung der XML-formatierten Inhalte im Vergleich zu optimierten Binärformaten nicht von der Hand zu weisen, wird jedoch durch die mit der Verwendung von XML einhergehenden Vorteile mehr als ausgeglichen.
    Einen ersten Eindruck der Natur XML-codierter Inhalte liefert das Kapitel strukturelle Grundkonzepte. Dort finden sich auch Ansätze die bekannte XML-Syntax kompaktifiziert darzustellen ohne die Vorteile der generischen Auszeichnungssprache aufgeben zu müssen.
  5. XML ist eine Familie von Techniken.
    Eine Aussage, die durch alle drei Kapitel der Vorlesung unterstrichen wird, die deutlich zeigen, daß XML nicht als isolierte Idee oder Technik anzusehen ist -- sondern erst im Zusammenspiel mit anderen XML-Standards und eingebettet in Applikationen und Infrastrukturen -- seine volle Wirkungsmächtigkeit entfalten kann.
  6. XML ist neu, aber nicht so neu.
    Diese Bezugnahme soll nochmals unterstreichen, daß XML keineswegs den Anspruch erhebt eine vollkommen neue technische Errungenschaft zu sein, sondern vielfach bekanntes und erprobtes aus der Informatik wiederverwendet und im neuen Verwendungskontext weiterentwickelt.
    Diese Aussage wird durch die in den einzelnen Kapiteln dargebotenen Rückbezüge auf bereits bekannte Techniken und Lösungsformen untermauert.
  7. XML überführt HTML in XHTML.
    Diese Aussage greift nochmals die Beziehung zwischen XML und HTML auf. Diesmal soll die Rolle von XML im Bezug auf die Weiterentwicklung von HTML zum XML-basierten Vokabular XHTML unterstrichen werden. So löst XML die Abhängigkeit zwischen SGML und HTML auf und reformuliert HTML auf der Basis von XML.
    Das Kapitel XHTML führt kurz in die Entwicklung der neuen HTML-Varianten auf Basis der XML ein und skizziert die vorgenommen Änderungen und zukünftige Erweiterungen dieser Hypertextsprache.
  8. XML ist modular.
    Hierdurch wird unterstrichen, daß XML kein in sich geschlossenes monolithisches Gebilde darstellt, sondern einzelne Vertreter aus der Familie der XML-Sprachen wahlfrei zur Lösung konkreter Probleme herangezogen werden können. Ebenso wird die Sprachfamilie beständig an verschiedensten Stellen unabhängig voneinander weiterentwickelt, ohne einer zentralen Koordination zu bedürfen.
    Einen Eindruck dieser Modularität liefern bereits die Grundlagensprachen des ersten Kapitels. Eindrucksvoll verstärkt wird diese Aussage durch die im zweiten Kapitel eingeführten problemorientierten Sprachen.
  9. XML ist die Basis für RDF und das Semantic Web.
    Grundidee des Semantic Web ist die Weiterentwicklung des sichtbaren XHTML-basierten Webs unter Nutzung seiner datenorientierten Ergänzung XML zu einem Netz von Sinnzusammenhängen. Die technische Voraussetzung hierzu bildet das im gleichnamigen Kapitel beschriebene Resource Description Framework welches eine XML-Sprache zur Darstellung von beschreibenden Daten zu beliebigen Quellen definiert.
  10. XML ist lizenzfrei, plattform- und herstellerunabhängig, und gut unterstützt.
    XML ist eine durch das World Wide Web Consortium herausgegebene Spezifikation, die kostenfrei über das Web bezogen werden kann und durch Interessierte ohne weitere Lizenzkosten in eigenen kommerziellen Produkten verwendet werden. Durch den Standardisierungsprozeß innerhalb des World Wide Web Consortiums wird sichergestellt, daß keine Ausführungsplattform bevorzugt wird und gleichzeitig keine Nachteile für Andere entstehen. Dies wird durch die herstellerunabhängige Organisation des Gremiums versucht zu garantieren, in dem zwar Hersteller Mitglied werden können, die technischen Entscheidungen jedoch Arbeitsgruppen obliegen, die nicht durch eine Firma dominiert werden können.
Artikel in der Online-Ausgabe des Economist über Ted Nelson -- The Babbage of the web COT1800 Public Networks, Lecture 8, Standard Generalised Markup Language Brief History of Document Markup XML, Element Types, DTDs, and All That Clark, J.: Comparison of SGML and XML Browser Timelines Browser Emulator

Die Rolle des World Wide Web Consortiums:
Das World Wide Web Consortium (W3C) stellt keine Normierungsorganisation im klassischen Sinne staatlicher Standardisierung wie die ISO, mit ihren nationalen Organisationen wie dem DIN, die UN, die ITU (früher CCITT) oder die IEC dar. Dies äußert sich schon darin, daß es keine normativen Dokumente verabschiedet, sondern lediglich Einsatzempfehlungen recommendations (im Sinne des IETF RFC 2119) gibt. Konkret bedeutet dies: Das W3C ist de jure nicht in der Lage auf rechtlichem Wege einklagbare Normen zu setzen. Vielmehr spricht es Empfehlungen aus, von denen unter bestimmten Umständen durchaus abgewichen werden kann. Jedoch empfiehlt RFC 2119 zunächst die Auswirkungen zu untersuchen und die endgültige Entscheidung gründlich abzuwägen.

Organisatorisch ist das W3C seit seiner Gründung 1994 ein Projekt des Massachusetts Institute of Technology (Labaratory for Computer Science) in Zusammenarbeit mit CERN, der Kejo Universität in Japan und dem European Research Consortium for Informatics and Mathematics (ERCIM). Unterstützt wird das Projekt durch DARPA und die Europäische Kommission.
Das W3C versteht sich als offenes herstellerunabhängiges Gremium. Zugang zu den Ergebnissen erhält jeder Interessierte kostenfrei über die W3C-Web-Site.
Die Mitwirkung an neuen Standards ist auf die Mitglieder des W3C beschränkt. Dieser Status ist juristischen Personen vorbehalten, steht aber generell jeder Institution oder jedem Unternehmen offen. Durch die Mitgliedschaft wird ein Sitz im Advisory Committee, dem offiziellen Bindeglied zwischen Mitgliedern und W3C-Team, erworben. Darüberhinaus kann jedes W3C-Mitglied an den laufenden Standardisierungsaktivitäten teilnehmen.

Das W3C veröffentlicht sechs verschiedene Typen von Dokumenten, wobei jedoch nur fünf formal zum Standardisierungsprozeß zu zählen sind.

Informationen über das W3C Liste der W3C-Mitglieder Deutsches W3C-Büro W3C Process Document; es definiert die verschiedenen W3C-Standardisierungsstatus Eine Anwendung der Extensible Markup Language. Ein Vokabular, das aus Symbolen und der ihnen zugewiesenen Bedeutung (Semantik) gebildet wird, ergänzt um Regeln (grammatikalische Struktur und Gültigkeitsregeln für den Inhalt (z.B. Datentypen)) zur Kombination der Vokabularelemente.
Anwendungen einer so neu geschaffenen XML-Sprache L werden als XML-Dokumente, auch: L-Dokumente, bezeichnet.

Die XML-Sprachfamilie:

Die Graphik stellt den Zusammenhang einiger Basistechniken der XML sowie verschiedene bekannte XML-Sprachen dar.

Die strukturelle Basis der Extensible Markup Language bilden heute der XML Information Set, welcher die zentralen Begriffe der XML Strukturprimitive definiert, gemeinsam mit dem Codierungsstandard (ISO/IEC 10646) des Unicode Konsortiums zur plattformunabhängigen Darstellung beliebiger Zeichensätze.
XML selbst wurde ursprünglich als eine Untermenge der ISO-Norm der Standard Generalized Markup Language (SGML) definiert. Daher erbt XML auch den dort definierten Grammatikmechanismus, die sog. Document Type Definitions (DTD), welche eine zusätzliche Text-basierte Sprache zur Festlegung des Vokabulars einer XML-Sprache liefern.

Aufbauend auf dem grundlegenden XML-Standard des W3C führt die Graphik die XML Namespaces ein, welche zur Unterscheidung von gleichen Bezeichnernamen in verschiedenen Verarbeitungskontexten dienen.
Diese Erweiterung der XML gestattet es Anwendern ihre Element- und Attributnamen vollkommen frei festlegen zu können, ohne zukünftig, etwa bei der Syndikatisierung verschiedener Dokumente mit Namenskonflikten konfrontiert zu werden.

Durch die XML HyperText Markup Language (XHTML) wird der große und wichtige Bereich der präsentationsorientierten Auszeichnungssprachen vertreten. XHTML v1.0 stellte die Reformulierung der bekannten Web-Sprache HTML v4.01 ein, die als SGML-Sprache nicht mehr durch das W3C weiterentwickelt wird.

Am Rande sei noch auf die (auf der Abbildung nicht dargestellte) ISO-Norm DSSSL (sprich: Dißl) -- die Document Style Semantics and Specification Language -- hingewiesen. Sie erlaubt die Formulierung von Transformationsregeln, die beliebige SGML-Dokumente in ein präsentationsfähiges Format überführen. Hierzu ist ein generischer Prozessor notwendig, der als Eingabe das umzuformende SGML-Dokument und die Transformationsregeln akzeptiert.
Bekannte DSSSL-Implementierungen: James Clarks Jade, oder Seng.
Die mit DSSSL gesammelten Erfahrungen flossen in die Entwicklung der XML-Stylesheet und Transformationssprachen XSL-Formatting Objects und XSLT ein.

Ein zentraler Bestandteil des Hypertext-Gedankens ist die nichtlineare Navigierbarkeit. In Web-Dokumenten, die mit der Sprache HTML erstellt wurden, findet sich dies durch die bekannten Hyperlinks verwirklicht. Der darstellende Browser sorgt dafür, daß durch Mausklick auf den meistens farblich und durch Unterstreichung hervorgehobenen Link die hinterlegte Aktion ausgeführt wird; üblicherweise wird ein neues HTML-Dokument geladen.
Auch XML verfügt über einen solchen -- jedoch durch Verallgemeinerung ungleich mächtigeren -- Verknüpfungsmechanismus. Er beschränkt sich jedoch nicht nur auf visuelle Hyperlinks, sondern steht durch den W3C-Standard XLink für alle XML-Sprachen zur Verfügung. Dadurch erweitert sich das aus HTML bekannte System u.a. um mehrgliedrige Verweise, die auf eine Menge von Dokumenten verweisen sowie verschiedene Verhaltensmuster bei der Traversierung eines Links.

Während Hyperlinks zur direkten Referenzierung einzelner Elemente eines XML-Dokuments verwendet werden, lagert die Lokatorsprache XPath dies in eine eigene Sprache aus. Sie stellt den Kern einer Anfragesprache, zur Extraktion verschiedenster Informationen (Knotenmengen, Positionsangaben, Werte, etc.) aus einem XML-Dokument, dar.
Aufgrund des dadurch eröffneten Anwendungsgebietes finden sich Teile von XPath in der Transformationssprache XSLT wieder. Hier dienen sie zum Auffinden der zu transformierenden Dokumentstrukturen.
XSLT erlaubt die Generierung beliebiger Unicode-Ströme aus XML-Strukturen. Häufigstes Einsatzgebiet in der Praxis ist aber die Verwendung zur Umformung von XML-Dokumenten. Hierzu wird nicht die volle Mächtigkeit der Ausgabe beliebiger Texte genutzt, sondern es werden lediglich XML-Dokumente erzeugt.
Für das Anwendungsgebiet freier Dokumentstrukturen, wie z.B. RTF, Postscript oder LaTeX werden durch das W3C die Formatting Objects entwickelt. Konzeptionell baut dieser Standard auf XSLT auf, und reichert dieses um notwendige Primitive zur Erzeugung der erwähnten Formate an.

Ausgehend von mit XPath beschaffenen Lokalisierungsmöglichkeiten innerhalb eines XML-Dokuments oder einer Menge von XML-Dokumenten ist es konzeptionell nur ein kleiner Schritt eine Anfragesprache zu definieren. Dies wird durch XQuery vollzogen. Dieser Sprachstandard definiert eine SQL-artige algebraische Anfragesprache. Für beide Sprachen existiert eine textuelle nicht-XML-konforme kompakte Syntax, die ihre Einbettung in existierende XML-Vokabulare gestattet.

Zur Unterscheidung zwischen XML-codierten Sprachen und anderen Ansätzen hinterlegt die Graphik der Abbildung alle im folgenden behandelten Standards zu denen eine XML-Sprache existiert farblich.

Auch das Resource Description Framework (RDF) baut auf den durch die Namensräum-Spezifikation etablierten Grundlagen auf. RDF definiert eine XML-Sprache, die ausgehend von klassischer Prädikatenlogik die Formulierung und maschinelle Auswertung von Aussagen über Web Ressourcen (etwa Text- oder Bilddaten) gestattet.

Die Erschließung neuer Anwendungsfelder läßt die Unzulänglichkeiten der Dokument-Typ-Definition als Möglichkeit zur Formulierung von XML-Vokabularen offenkundig werden, unterstützt der DTD-Mechanismus doch weder ein hinreichend entwickeltes Typsystem noch gestattet er die angemessene Formulierung von Strukturen wie sie in XML-Dokumenten benötigt werden.
Aus diesem Grunde entwickelt die XML-Sprache XML Schema die Primitive der DTD in einem eigenständigen XML-Vokabular fort, welches neben erweiterten Strukturierungsmöglichkeiten auch ein umfangreiches Typsystem zur Verfügung stellt.

Als eine Anwendung der Schemasprache stellt die Abbildung die beiden Sprachen WSDL und SOAP vor, die im Umfeld der Web Services große Bedeutung erlangt haben.
Diese XML-Sprachen dienen der Beschreibung von Aufrufschnittstellen und -charakteristika von Funktionalitäten, die über Internetprotokolle zur Verfügung gestellt werden. Die Darstellung des eigentlichen Aufrufs, des Namens der aufzurufenden Funktion sowie der benötigten Übergabeparameter, kann ebenfalls XML-codiert erfolgen. Den bekanntesten Ansatz hierzu bildet das SOAP-Protokoll welches einen betriebsystem- und programmiersprachenunabhängigen Nachrichtenmechanismus definiert.

Strukturelle Grundkonzepte

Die grundlegende XML-Syntax ist in der namensgebenden W3C-Recommendation der Extensible Markup Language definiert. Die Semantik der Metasprache wird hingegen durch den W3C-Standard des XML Information Set festgelegt.
Diese Spezifikationen beinhalten die grundlegenden Definitionen hinsichtlich Terminologie und Beziehung der verschiedenen möglichen Elemente eines XML-Dokuments. Im vorliegenden Teilkapitel werden beide Sprachaspekte grundlegend eingeführt und ein erstes Verständnis der XML vermittelt. Dabei wird in Form von Ausblicken auf nachfolgende Abschnitte der Bogen zu Grammatikdefinitionssprachen und weiterführenden Konzepten wie Namensräumen gespannt.
Zum leichteren Verständnis sind die aus der offiziellen Spezifikationen entnommenen formalen Grammatikdefinitionen der EBNF-Notation durch vereinfachte graphische Strukturdarstellungen ergänzt.

Ein XML-Dokument ist ein Datenstrom (der nicht zwingend als Datei vorliegen muß), welcher den Strukturierungsprinzipien der eXtensible Markup Language genügt. Die Spezifikation des XML Information Sets definiert die Semantik der Metasprache XML, d.h. ihre zentralen Begriffe.
Gleichzeitig setzt es diese Begriffe in Beziehung und definiert so syntaxunabhängig die Struktur eines XML-Dokumentes.

Ausgehend von der Allgemeinheit der Aussage aus Definition folgt, daß der Infoset neben seinem theoretischen Wert als Semantikdefinition zur XML auch zur Formulierung der Datenstrukturen, welche innerhalb eines XML-Prozessors vorliegen müssen, um beliebige XML-Dokumente verarbeiten zu können, herangezogen werden kann.
Daher läßt sich ein XML-Prozessor definieren als:

Ein XML-Prozessor ist eine maschinelle Komponente (typischerweise: Software), die zum Lesen, Speichern und Verarbeiten eines XML-Dokuments eingesetzt wird.
Er erlaubt Zugriff auf den Inhalt und die Struktur des XML-Dokuments.

Die XML-Spezifikation faßt den XML-Prozessorbegriff etwas enger und beschränkt ihn lediglich auf Software-Module, die XML-Dokumente lesend verarbeiten. Konzeptionell spricht jedoch nichts gegen eine Umsetzung in Hardware, beispielsweise im Kontext eingebetter Systeme etc.
Ferner nimmt die XML-Spezifikation an, ein Prozessor operiere nicht eigenständig, sondern im integrierten Zusammenspiel mit einer Applikation.

Das Beispiel zeigt ein erstes einfaches XML-Dokument, welches bereits die häufigst verwendeten Sprachelemente der XML versammelt.
Jedem XML-Dokument entspricht genau ein Information Set, der alle Informationselemente des Dokuments in Form einer Baumstruktur beinhaltet. Die nachfolgende Abbildung zeigt den Information Set des Beispiels in der Notation eines UML-Klassendiagramms. Dabei sind die einzelnen Knoten des Information Sets als Objekte (Klassensymbole mit unterstrichenem Klassennamen) und die Eigenschaften der Knoten als Attributwerte dargestellt.

Document Information Item

Jedes Information Set besteht genau aus einem Document Information Item. Dieses stellt den äußeren Rahmen des XML-Dokuments dar. Es beinhaltet dokumentbezogene Informationen, wie die verwendete XML-Version und das gewählte Codierungsschema innerhalb des Unicode-Systems.
Das Document Information Item enthält daher u.a. die Informationen des XML-Dokumentprologs in der erste Zeile jedes Dokuments. Das durch die öffnende Winkelklammer und ein Fragezeichen eingeleitete Konstrukt ist in der ersten Zeile des Beispiels dargestellt. Innerhalb des Prologs findet sich die Zeichenkette xml, sowie die Bezeichner version und encoding. Beiden ist ein durch doppelte Hochkommata umschlossener Wert nachgestellt, 1.0 für version, bzw. ISO-8859-15 für encoding.
Beendet wird der Prolog wiederum durch ein Fragezeichen und die schließende Winkelklammer. Wird auf die Angabe des optionalen Prologs im Dokument verzichtet, so sind die daraus ableitbaren Angaben im Document Information Item nicht gesetzt.

Als weitere Eigenschaften verfügt jedes Document Information Item über eine geordnete Liste von Kindknoten. Darin ist genau ein Element Information Item enthalten, welches den Startknoten des XML-Dokuments verkörpert. Wegen seiner hervorgehobenen Bedeutung als Wurzel des Dokumentbaumes wird dieser Knoten auch als Document Element bezeichnet.
Zusätzlich kann die Liste Elemente vom Typ Processing Instruction Information Item enthalten. Sie dienen der Darstellung von Verarbeitungsanweisungen, die durch den XML-Prozessor interpretiert werden.
Im Kopfbereich vor Document Element plazierte XML-Kommentare werden durch Comment Information Items innerhalb der children-Liste dargestellt.
Verfügt das XML-Dokument über eine Dokumenttypdeklaration, so findet sich auch ein Document Type Declaration Information Item in der Liste.
Deklarierte Notationen werden in einer ungeordneten Menge als Notation Information Item dargestellt.

Zusammengefaßt enthält das Document Information Item folgende Informationen:

  • Kindknoten: In der Reihenfolge des Auftretens im Dokument geordnete Liste. Sie enthält mindestens ein Element Information Item, welches in der Rolle des Document Items fungiert. Ferner je ein Element des Typs Processing Instruction Information Item für jede Processing Instruction die außerhalb des Wurzelements definiert ist und jeweils ein Comment Information Item zu jedem definierten Kommentar.
  • Document Element: Ein Element des Typs Element Information Item, das auf den Wurzelknoten des Dokuments verweist.
  • Notations: Die in der DTD definierten Notationen als ungeordnete Menge.
  • Unparsed Entities: Die in der DTD definierten ungeprüften Entitäten als ungeordnete Menge.
  • Basis URI: Lokation, falls bekannt, des XML-Dokuments in Form eines Uniform Resource Identifiers (URI) gemäß IETF RFC 2396.
  • Character Encoding Scheme: Der Name der gewählten Codetabelle aus dem Unicode-Standard.
  • Standalone : Legt -- als Boole'scher Wert (Zugelassene Belegungen: yes, no) -- fest, ob die im Dokument gespeicherten Daten durch eine sie verarbeitende Applikation interpretiert und somit ergänzt oder verändert werden.
    Häufigste Form dieses Interpretationsvorganges ist die Präsenz einer expliziten Grammatik in Form einer Document Type Definition, welche Gültigkeitsregeln für eine Familie von Dokumenten formuliert.
    Konsequenterweise bedeutet daher die Belegung mit no, daß die gespeicherten Daten entweder durch die Applikation interpretiert werden, dies ist beispielsweise bei der Auflösung von Entitäten der Fall, oder durch eine DOCTYPE -Deklaration ein Verweis auf die externe Dokumentgrammatik erfolgt. Die Angabe von standalone ist optional. Fehlt sie und ist gleichzeitig eine DOCTYPE-Deklaration im Dokument gegeben, so wird standalone="no" angenommen.
    Im Beispiel ist die standalone-Deklaration auf yes gesetzt, d.h. es existiert explizit keine Dokumentgrammatik.
  • Version: Die eingesetzte XML-Version. Dieser Wert wird aus dem Dokumentprolog übernommen.
  • All Declarations Processed: Boole'scher Wert der angibt ob der verarbeitende XML-Prozessor die evtl. verfügbare DTD vollständig abgearbeitet hat.

Wie auch im Beispieldokument, bildet die erste Zeile den sog. Prolog eines jeden XML-Dokuments . Die Angabe der Version ist zwingend und derzeit auf die Konstante 1.0 fixiert. Die aktuelle XML-Spezifikation sieht als gültige Belegung der Versionsangabe ausschließlich die Zeichenkette 1.0 vor. Zukünftigen Weiterentwicklungen ist es jedoch freigestellt auch andere Revisionskennungen zu vergeben.
encoding leitet das zweite Namen-Wert-Paar ein. Die Deklaration ist innerhalb des Prologs optional, und kann daher auch unterbleiben. Die Zeichenkette der Encodingdeklaration benennt das Codierungsschema, welches für das so gekennzeichnete Dokument verwendet wurde. Es definiert den Satz der innerhalb des Dokumentes zugelassenen Zeichen fest.
Gemäß Produktion 22 der XML-Syntaxdefinition ist der gesamte Prolog optional.

Die Encoding-Deklaration hat folgendes Aussehen :

               
                  

                     

                        [80]
                        EncodingDecl
                        ::=
                        S 'encoding' Eq ('"' EncName '"' | "'" EncName "'"    )
                     

                     

                        [81]
                        EncName
                        ::=
                        [A-Za-z] ([A-Za-z0-9._] | '-')*
                     

                     

                        
                           [3]
                        
                        S
                        ::=
                        (#x20 | #x9 | #xD | #xA)+
                     

                     

                        [25]
                        Eq
                        ::=
                        S? '=' S?

Die Festlegung der Produktion 80, sowie die der Produktion 23, stellt heraus, daß sich die Encodingdeklaration nicht auf die Prologzeile selbst auswirkt. Hier sind die beiden Zeichenketten xml und encoding in der Codierung UTF-8 oder UTF-16 Vorschrift.

Als Belegungen des Encoding Namens (EncName) sind beliebige Zeichensätze zugelassen. Der XML-Standard empfiehlt jedoch lediglich auf die durch die Internet Assigned Numbers Authority verwalteten zurückzugreifen (Dokument: Official Names for Character Sets) .
Die häufigsten praktisch eingesetzten Deklarationen sind die der ISO-8859 (extended ASCII)-Familie, sowie die der Unicode- und ISO-10646-Standards.
Die verschiedenen Abschnitte der ISO-8859 Familie werden als ISO-8851-n ausgedrückt, wobei n die Nummer des Abschnittes des zugehörigen ISO-Dokuments referenziert. Ferner können die durch JIS X-0208-1997 normierten asiatischen Zeichensätze als ISO-2022-JP, Shift_JIS und EUC-JP dargestellt werden.

Unicode stellt einen Industriestandard (entwickelt u.a. durch Apple, HP, IBM, Microsoft und SUN) zur Darstellung verschiedenster Alphabete und graphischer Zeichen dar. Sein zunächst durch 16-Bit codierter Zeichenvorrat bot Raum für 65536 unterschiedliche Symbole.
Die seit 1991 laufenden Unicodebemühungen münden in die ISO-Norm zur Erweiterung des klassischen ASCII-Codes (ISO 646) als ISO-10646 Universal Multiple-Octet Coded Character Set (UCS). Seit 1996 sind beide Standards synchronisiert und werden abgestimmt vorangetrieben.
UCS definiert zwei aufeinander aufbauende Codierungen: UCS-2 (16 Bit Umfang) und UCS-4 (32 Bit). Der bisherige Unicode-Standard ist voll kompatibel zu UCS-2 und durch diesen darstellbar.

Codierung Bitbreite Binärdarstellung Größe der Beispieldatei in Byte
(ohne Berücksichtigung des XML-Prologs) Bemerkung zum Meßwert UTF-7 >= 7 100 0001 263 (encoding="UTF-7") Extended ASCII, Latin-1 (ISO-8859-1) 8 0100 0001 258 (encoding="ISO-8859-1") UTF-8 >= 8 0100 0001 259 (encoding="UTF-8") keine Byte Order Mark UCS-2, Unicode 16 0000 0000 0100 0001 516 (encoding="UCS-2") keine Byte Order Mark UTF-16 (big endian) >= 16 0000 0000 0100 0001 516 (encoding="UTF-16") keine Byte Order Mark UCS-4 32 0000 0000 0000 0000 0000 0000 0100 0001 1032 (encoding="UTF-8") keine Byte Order Mark UTF-32 >= 32 0000 0000 0000 0000 0000 0000 0100 0001 1032 (encoding="UTF-32") keine Byte Order Mark

Die Zeilenumbrüche wurden in allen Fällen durch die Kombination von Wagenrücklauf und Zeilenvorschub ausgedrückt.

Die Tabelle stellt einige Codierungen zur Darstellung des Zeichens A zusammen.
Auffallend ist der große Platzbedarf der UCS-2 und -4 Codierungen. Insbesondere bei den klassischen ASCII-Symbolen werden hier (u.U. sehr viele) führende Nullbits erzeugt, die in der Konsequenz zu einer deutlichen Vergrößerung der Beispieldatei führen.
Daher wurde mit dem UCS Transformation Format (UTF) eine kompaktere Darstellung zum jeweiligen UCS-Set eingeführt. UTF-8 verwendet standardmäßig die ersten acht Bit zur Darstellung der bekannten ASCII-Zeichen

Anmerkung: Inzwischen existiert auch eine UTF-32 genannte 32-Bit Ausprägung, diese ist jedoch identisch zu UCS-4, mit Ausnahme daß durch UTF-32 nur 221-Zeichen dargestellt werden können.
Die Dateigröße ist daher für das betrachtete Beispiel in dieser Darstellungsweise unverändert zu der des UCS-4-Encodings.

Der Größenunterschied zwischen der UTF-7 codierten Datei und der Latin-1 encodierten erklärt sich aus der Darstellung des Umlautes sowie des +-Zeichens, die beide nicht nicht im klassischen 7-Bit ASCII-Code enthalten ist. So wird Ü im Wort Übungsbetrieb des Beispieldokumentes durch die die Bytefolge 2B 41 4E 77 2D dargestellt, während alle übrigen Zeichen durch ein einzelnes Byte ausgedrückt werden können.
UTF-8 ist in der Lage sämtliche Standard-ASCII-Zeichen durch jeweils genau ein Byte auszudrücken, wiederum für den Umlaut muß auf die 16-Bit-Darstellung des UCS-2 zurückgegriffen werden. Daher erhöht sich hier die Dateigröße um ein Byte.
Erwartungsgemäß beträgt der Umfang des UCS-2 codierten Dokuments exakt das Doppelte des 8-Bit Äquivalents der Latin-1-Darstellung.
Dasselbe gilt für die UTF-16-Variante, die für das vorliegende Beispiel unterschiedslos zu UCS-4 verläuft, da keinerlei Zeichen aus UCS-4 im Dokument auftreten.

Die nachfolgende Tabelle stellt beispielhaft die Anwendung der UTF-8-Codierung zusammen:

Unicode-Bereich Bitbelegung U-00000000 - U-0000007F: 0xxxxxxx U-00000080 - U-000007FF: 110xxxxx 10xxxxxx U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Diese Mimik zeigt den Nachteil des UTF-n-Encodings deutlich: Die Darstellung nicht n-Bit darstellbarer Zeichen benötigt u.U. mehr Bitstellen als im Standard UCS-Code.
So wird beispielsweise das Zeichen mit der größtmöglichen Position (7FFFFFFF) in UTF durch sechs Byte encodiert, während UCS dieselbe Information mit den verfügbaren 32-Bit ausdrücken kann. Andererseits verschwendet die UCS-Darstellung für die niederwertigen Zeichen Bitstellen durch die führenden Nullen.

In der Praxis gilt es daher für das zu wählende Encoding einen möglichst guten Kompromiß zu finden: Im allgemeinen stellt das UTF-8-Encoding einen solchen dar, soweit überwiegend ASCII-Zeichen, und nur vereinzelt Sonderzeichen (hierzu zählen auch die deutschen Umlaute) eingesetzt werden.
Bei überwiegender Verwendung nicht in acht-Bit ASCII darstellbarer Zeichen (z.B. arabischer, chinesischer, etc.) erhöht die dann aufwendigere UTF-8-Codierung die Datenmenge.
So umfaßt die UTF-16-Darstellung des unten abgebildeten Beispieldokuments, welche in diesem Anwendungsfall identisch zu UCS-2 ist, 966 Bytes, während UTF-8 1299 Byte benötigt.

Achtung: Bereits durch die Unterstützung der beiden ISO-Zeichendarstellungen UTF-8 und UTF-16 ist die Konformität zum XML-Standard erfüllt! XML-Prozessorimplementierungen wird nicht abverlangt darüberhinausgehend weitere Darstellungen umzusetzen.

Wie bereits eingangs angemerkt, erklärt die XML-Spezifikation die Encodingdeklaration sowie den gesamten Prolog-Ausdruck als optionales Element .
Als Konsequenz geht dabei (auch) die Angabe des gewählten Encodings verloren.
Daher fordert der Anhang F der XML-Spezifikation Autodetection of Character Encodings bei einem von UTF-8 oder -16 abweichendem Codierungsschema die zwingende Angabe der XML-Deklaration (<?xml ...) .
Hintergrund dieser Maßnahme ist der Versuch anhand der damit bekannten fünf Zeichen das zugrundeliegende Encoding zu ermitteln.
Diese fünf Zeichen können als stabil angenommen werden, da Produktion 23 und 80 diese explizit von einem von UTF-8 oder -16 abweichenden Encoding ausnehmen.

Für Dokumente im deutschen Sprachraum, d.h. XML-Ströme die häuptsächlich aus den um die deutschen Umlaute ergänzten Standard-ASCII-Zeichen bestehen, hat es sich in der Vergangenheit eingebürgert den Zeichensatz latin-1 (ISO-8859-1) zu verwenden, um die Mehrbytedarstellung der Umlaute und weiterer Sonderzeichen in der UTF-Codierung zu umgehen.
Jedoch enthält der latin-1-Zeichensatz nicht das unter Unicode-Zeichennummer 20AC abgelegte Eurosymbol (_) welches zur Abkürzung des Währungsbegriffes der europäischen Gemeinschaftswährung verwendet wird.
Dieses Symbol wurde in die unter Nummer 15 veröffentlichte aktualisierte Fassung der Zeichensatzfamilie 8859 aufgenommen. Daher sollte bei der Erstellung von XML-Dokumenten generell darauf geachtet werden entweder ISO-8859-15 als Codierung zu wählen oder auf die ohnehin ungleich flexiblere UTF-Codierung zurückzugreifen.

Die Darstellung der Abbildung faßt die syntaktischen Elemente abgekürzt zusammen:

Payer, M.: UNICODE, ISO/IEC 10646, UCS, UTF Kuhn, M.: UTF-8 and Unicode FAQ SC Unipad ein kostenfreier Unicode Editor Element Information Item

Jedes XML-Dokument enthält mindestens ein Element, das Document Element.
Seine, wie auch die Grenzen aller anderen Elemente, werden durch die Start- und Ende-Marke (engl. Tag) markiert. Für den Sonderfall eines leeren Elements bildet die Start- auch zugleich die Ende-Marke. Als eine Konsequenz können diese Elemente keine weiteren Kindknoten besitzen.

Die XML-Spezifikation legt den Aufbau des Start-Tags wie folgt fest :

               
                  

                     

                        [40]
                        STag
                        ::=
                        '<' Name (S Attribute)* S? '>'
                     

                     

                        [41]
                        Attribute
                        ::=
                        Name Eq AttValue

Mittels der Tag-Namen werden die Typen eines Dokumentes definiert. Sie werden später, in Verbindung mit einem Grammatikmechanismus wie DTD oder XML-Schema, zur Gültigkeitsprüfung herangezogen.
Der Aufbau der Elementnamen ist ähnlich zu den aus den Programmiersprachen bekannten Regeln. Am Beginn muß ein Buchstabe, ein Unterstrich oder der Doppelpunkt stehen. Darauf können nahezu beliebige Zeichen folgen, die über ihre Unicoderepräsentation genau definiert sind.
Leerzeichen und sog. white spaces (vgl. Produktion 3 der XML-Spezifikation) wie Tabulatoren und Zeilenvorschübe sind nicht zugelassen. Desweiteren darf ein Elementname weder Auszeichnungssymbole, wie die öffnenden und schließenden Winkelklammern, enthalten, noch mit der Zeichenkette XML beginnen. Die Zeichenfolge XML ist -- in allen Schreibweisen -- für die Standardisierung reserviert und wird ausschließlich in W3C-Dokumenten verwendet.
Durch den Namespace Standard (siehe Abschnitt 1.3) wird dem Doppelpunkt, als Trennsymbol zwischen Namensraumkürzel und Elementnamen, eine besondere semantische Bedeutung zugeschrieben. Daher sollte -- obwohl er spezifikationsgemäß ein erlaubtes Zeichen darstellt -- von seiner Verwendung in Elementnamen abgesehen werden.

Oftmals wird -- insbesondere in der Praxis -- die existierende und notwendige Unterscheidung zwischen Tag und Element nicht getroffen.
Die Tags oder Marken drücken beschreibende Information über ein Element aus. Der durch den Tag ausgedrückte Elementname liefert somit lediglich deskriptive Information über die Natur des Elements. Hierzu können Worte einer natürlichen Sprache verwendet werden, jedoch auch beliebige andere identifizierende Zeichenketten. Üblicherweise sind jedoch sprechende Tags anzutreffen.

Über den Tag-Namen hinaus kann ein Startelement auch noch Attribute enthalten (Vgl. Produktion 41). Diese sind jedoch nicht vom Typ Element und werden daher im Abschnitt Attribute Information Item betrachtet.

Der Aufbau eines Elementnamens wird durch die Produktionen 4ff definiert :

               
                  

                     

                        
                           [4]
                        
                        NameChar
                        ::=
                        Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
                     

                     

                        
                           [5]
                        
                        Name
                        ::=
                        (Letter | '_' | ':') (NameChar)*
                     

                     

                        [6]
                        Names
                        ::=
                        Name (S Name)*
                     

                     

                        
                           [7]
                        
                        Nmtoken
                        ::=
                        (NameChar)+
                     

                     

                        [8]
                        Nmtokens
                        ::=
                        Nmtoken (S Nmtoken)*

Im Beispiel sind Vorlesung, Titel und Hochschule (normale) Elemente, während ein leeres Element darstellt.
Die Abbildung zeigt, daß auf der semantischen Ebene des Information Sets die syntaktische Unterscheidung zwischen Elementknoten mit Kindelementen und leeren Elementen des XML-Dokuments keine Berücksichtigung findet.

Eine Sonderstellung unter den Elementen eines Dokuments nimmt der ausgezeichnete Wurzelknoten ein, er wird auch durch das Document Information Item referenziert. Unterhalb dieses Knotens spannt sich der Dokumentbaum auf. Hierfür enthält jedes Element Information Item eine geordnete Menge (children) weiterer Elementknoten.
Die durch den Elementnamen verwirklichte Typisierung spiegelt sich im Information Set durch das Attribut local name wieder.

Darüberhinaus enthält jedes Element Information Item durch die Eigenschaft namespace name die Identifikation des Namensraumes, in dem dieses Element plaziert ist.
Das Namensraumkürzel, welches zur Identifikation eines Elements herangezogen wird, findet sich in der Eigenschaft prefix.
Der local name entspricht dem -- um Namensraumkürzel und trennenden Doppelpunkt gekürzten -- wiedergegebenen Elementnamen des XML-Dokuments.
Zusätzlich wird jeder Namensraum, der syntaktisch an die Attributdefinition angelehnt ist, in ein Element der ungeordneten Menge namespace attributes abgebildet, welche (nochmals) die Namensräume eines Elements beinhaltet.

Das Beispiel zeigt das leere Element aElement innerhalb des Elements aParent. Durch das Elternelement wird der Namensraum example.com deklariert und dem Kürzel myNS zugewiesen.
Gemäß den Prinzipien der Namensräume steht der auf dem Elternknoten deklarierte Namensraum auch in allen Kindknoten zur Verfügung. Daher enthält die Eigenschaft in-scope namespaces des Elements aElement auch die Namensräume der übergeordneten Elemente.
Das resultierende Element Information Item des Knotens aElement ergibt sich daher als (der Ausschnitt enthält nur die für das Beispiel relevanten Elemente):

               
                  

                     

                        local name
                        =
                        aElement
                     

                     

                        namespace URI
                        =
                        example.com
                     

                     

                        prefix
                        =
                        myNS

Nähere Ausführungen zur Bedeutung von Namensräumen und ihrer Verwendung finden sich im Abschnitt Namensräume .

Verweise auf die im Dokumentbaum nachfolgenden Knoten eines Elements werden in einer geordneten Liste children gesammelt. Ihre Inhalte sind sind vom Typ Element Information Item , Unexpanded Entity Reference Information Item , Character Information Item und Comment Information Item .
Anhand der beiden Informationstypen Element Information Item und Character Information Item zeigen sich bereits die beiden Strukturierungsformen eines XML-Dokuments. Einerseits die durch die starke Verwendung von Elementen- und Attributen gekennzeichnete strukturierte Darstellung, andererseits die durch eingestreuten Freitext entstehende charakteristische semistrukturierte Variante.
In beiden Fällen werden die textartigen Inhalte durch Character Information Items repräsentiert.
Das Beispiel zeigt die verschiedenen Auftretensformen exemplarisch. Der Inhalt der Elemente title und organization ist rein Zeichenketten-artig; jedoch mischt vorlesung strukturierten Inhalt (in Form der genannten Elemente) und unstrukturierte Information -- repräsentiert durch den Text 2002/03.
Die XML-Spezifikation prägt für Zeichenketten-artige Inhalte, die optional durch eingestreute Elemente angereichert werden, den Begriff mixed Content .

children enthält jedoch keine Verweise auf die Attribute eines Elements. Diese sind durch die separate ungeordnete Menge attributes repräsentiert. Die Diskussion der als Attribute Information Item bezeichneten Mengenelemente findet sich im folgenden.

Die in der Abbildung dargestellte Beziehung parent verbindet jedes Element mit seinem übergeordneten. Als Ziele dieser Referenz sind ausschließlich Ausprägungen von Document Information Item oder Element Information Item zugelassen.
Diese Festlegung untermauert nochmals die strikte Baumstruktur eines XML-Dokuments. Andernfalls müßte parent als Menge definiert werden.

Attribute Information Item

Das betrachtete Beispiel enthält, neben den Elementen, auch ein XML-Attribut.
Syntaktisch werden Attribute innerhalb eines Start-Tags plaziert und durch Namen-Wert-Paare ausgedrückt .

Der Information Set enthält folgende Eigenschaften zu jedem Attribut:

  • namespace name : Namensraum des Attributs, falls definiert.
  • Lokaler Name : Der um das eventuell definierte Namensraumkürzel bereinigte Attributname.
  • Präfix: Namensraumkürzel des Namensraumes, innerhalb dessen das Attribut plaziert ist.
  • Normalisierter Wert: Normalisierter Attributinhalt. Der Normalisierungsvorgang ist in Abschnitt 3.3.3 der XML-Spezifikation beschrieben .
    Unter anderem eliminiert er Zeilenumbrüche innerhalb des Attributinhalts und löst Entitätsreferenzen auf.
  • specified: Boole'scher Wert, der angibt, ob das Attribut im XML-Dokument auftrat oder aufgrund einer Vorgabebelegung durch die DTD erzeugt wurde.
    Zur Ermittlung dieser Eigenschaft des Attribute Information Items ist die Definition und Referenzierung einer expliziten Grammatik notwendig.
  • Attributtyp: Typ des Attributs. Zugelassene Belegungen sind: ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS, NOTATION, CDATA, und ENUMERATION.
    Zur Ermittlung dieser Eigenschaft ist der Zugriff auf die DTD des Dokumentes notwendig. Ist dies nicht möglich, so ist der attribute type mit keinem Wert belegt.
  • Referenzen: Handelt es sich bei dem Attribut um ein Referenzattribut (d.h. es ist als IDREF(S), ENTITY, ENTITIES oder NOTATION typisiert), so enthält diese Eigenschaft eine Verweisliste auf alle Auftreten des Attributwertes.
  • Eigentümerelement: Bildet die Entsprechung zur parent-Eigenschaft des Element Information Item . Als solches enthält die Eigenschaft einen Verweis auf das Element, welches das Attribut beherbergt.

Im Vergleich zum Element Information Item erlaubt das Attribut keine weitere Unterstrukturierung (im XML-Sinne); insbesondere fehlen mengenwertige Eigenschaften zur Aufnahme der dann notwendigen Verweise. Stattdessen wird der gesamte Inhalt durch die Eigenschaft normalized value dargestellt.
Daher dürfen innerhalb von Attributen keine (Meta-)Symbole wie die öffnende Winkelklammer auftreten, die als Starttags (miß-)interpretiert werden könnten .

Auch die Form des Auftretens von Attributen innerhalb des definierenden Elements unterscheidet sich von der der Subelemente innerhalb eines Elements. Während Kindelemente durch die geordnete Liste children dargestellt werden, können Attribute (formalisiert in der ungeordneten Menge attributes) in beliebiger Reihenfolge angegeben werden, ohne die Dokumentsemantik zu verändern. Mehr noch, die Listenkonstruktion erlaubt das unterscheidbare mehrfache Auftreten desselben Elements. Diese Mimik ist für allgemeine Mengen, und damit für Attribute, nicht möglich.

Element vs. Attribut
Der Vergleich der Eigenschaften von Element und Attribut zeigt bereits, daß sich nicht weiter strukturierte Elemente auch durch Attribute darstellen ließen. Dies wirft innerhalb der Betrachtung der Syntax eines XML-Dokuments bereits die Frage nach der Organisation, und damit dem Entwurf, eines solchen auf.
Die bestehende XML-Spezifikation bleibt jedoch eine Anwendungs- oder Einsatzempfehlung zu dieser Fragestellung schuldig.
Aufgrund der inhärenten Einschränkungen der Attributprimitive bietet sich ihr Einsatz nur in einigen Sonderfällen an. Beispielsweise zur Darstellung deskriptiver Information über das enthaltende Element, die nicht Bestandteil der im XML-Dokument dargestellten Information ist. Hierbei kann es sich um Informationen höherer Ordnung, sog. Metainformation handeln.

Generell bieten sich Elemente immer dann an, wenn eine weitere Unterstrukturierung des Inhaltes gewünscht oder vielleicht zukünftig notwendig ist. Die Darstellungsform als Attribut würde in diesem Fall eine strukturelle Umorganisation des XML-Vokabulars erfordern, da die Spezifikation keine Unterstrukturierungsmöglichkeit für Attribute vorsieht.
Darüberhinaus gestatten Attribute keine Wiederverwendung in verschiedenen Bedeutungskontexten, da sie syntaktisch an das umgebende Element gebunden sind. Diese Einschränkung wird zwar durch die Einführung des Standards XML Schema weitgehend gemildert, jedoch nicht die zuvor genannte Mächtigkeitseinschränkung. Zusätzlich stellen Attribute die einzige Möglichkeit zur Typisierung des Inhaltes dar solange DTDs verwendet werden. Dieser Punkt dürfte jedoch durch den wachsenden Praxiseinsatz der XML Schemata immer mehr an Bedeutung verlieren.

Die Darstellung der Abbildung faßt die syntaktischen Elemente abgekürzt zusammen:

Character Information Item

Die Betrachtung der Attribut- und Elementknotentypen im Information Set zeigt bereits die zwei grundlegenden Arten der Informationsdarstellung eines XML-Dokumentbaumes.
Die Eigenschaft normalized value des Attribute Information Items kapselt den im XML-Dokument angegebenen Inhalt direkt im Informationsknoten. Der Datentyp der Eigenschaft ist für alle Dokumenttypen fixiert angebbar, da keine weitere Unterstukturierung von Attributen erfolgen kann.
Entgegensetzt hierzu verläuft die Argumentationslinie für Elemente. Ihr Inhaltsmodell kann eine freie Mischung aus Zeichenketten-Daten und weiteren Elementen aufweisen. Die Länge der Zeichenketten ist hierbei nicht näher festgelegt. Daher können diese im minimalen Falle nur aus einem einzelnen Zeichen bestehen. .
Innerhalb des Information Sets eines Dokuments werden alle Zeichen im Rumpf eines Elements als Ausprägungen des Character Information Items dargestellt.

Jedes Character Information Item stellt das im Dokument gegebene Zeichen gemäß ISO 10646-Codierung in der Eigenschaft character code dar. Die Werte können hierbei jedoch nur in den durch die Spezifikation vorgegebenen Grenzen variieren . Darüberhinaus genügt bereits die Unterstützung der UTF-8 und -16-Darstellung zur Erfüllung der Spezifikationsanforderungen an konforme Prozessoren.
Handelt es sich bei dem betrachteten Zeichen um einen white-space (Leerzeichen, Tabulator, Zeilenvorschub, Wagenrücklauf), der in der DTD als erhaltenswert spezifiziert wurde, so ist die Boole'sche Eigenschaft element content whitespace auf true gesetzt; andernfalls konstant auf false. Häufig werden white-spaces zur besseren visuellen Strukturierung des XML-Dokumentes eingesetzt. So enthält das Beispieldokument jeweils nach der schließenden Marke einen Zeilenvorschub. Unter Datengesichtspunkten handelt es sich hierbei jedoch um keine verwertbare Information. Die Angabe der Berücksichtigung bzw. Vernachlässigung im XML-Dokument existierender white-spaces kann in der DTD gesetzt werden. Ist keine solche Deklaration gesetzt oder existiert keine explizite Grammatik, so hat die Eigenschaft element content whitespace keinen Inhaltswert.
Der als parent-Eigenschaft realisierte Verweis auf das beherbergende Elternelement bildet den Abschluß der Eigenschaften des Character Information Items.
Im betrachteten Beispiel sind unterhalb der Elemente organization und title  Character Information Element-Ausprägungen plaziert. Die Darstellung zeigt diese als Objekte (Unterhalb des organization-Knotens wurde aus Übersichtlichkeitsgründen auf die Darstellung verzichtet).

Eine Sonderrolle kommt den Zeichen zu, die auch als Metasymbole der Auszeichnungssprache dienen. Sie dürfen daher nicht in XML-Dokumenten auftreten.
Bei diesen Zeichen handelt es sich um die beiden Winkelklammern, die einfachen und doppelten Anführungszeichen sowie das Kaufmanns-Und. Um eine Fehlinterpretation zu vermeiden existieren hierfür vordefinierte Textersetzungsmuster.
Jeder spezifikationskonforme XML-Prozessor berücksichtigt diese Symbole und gibt sie in der korrekten Darstellung an die Applikation weiter; damit sind diese Fluchtsymbole (engl. escape characters) aus Applikationssicht vollkommen transparent.

Entitätsreferenz Ausgedrücktes Zeichen &amp; & &lt; < &gt; > &apos; ' &quot; " Latin-1 Entities
Special Entities
Symbole Comment Information Item

Zur Dokumentation steht innerhalb jedes XML-Dokuments die von SGML ererbte Kommentierungssyntax zur Verfügung.
Die Spezifikation erlaubt die Anbringung von Kommentaren an zwei Stellen im XML-Dokument:

  • Nach dem Prolog.
  • An jeder beliebigen Stelle des Inhalts, außerhalb von Markup-Symbolen.

Nicht erlaubt sind demnach Kommentare in Tags, d.h. innerhalb geöffneter Winkelklammern.
Dergleichen gilt für Kommentare selbst, was geschachtelte Kommentare verbietet.

Ferner können Kommentare desselben Stils auch in DTDs und im internal Subset verwendet werden.

Produktion 15 der XML-Spezifikation legt die Struktur wie folgt fest:

                  

                     

                        [15]
                        Comment
                        ::=
                        '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'

Als Konsequenz sind innerhalb von Kommentaren alle Zeichen, auch Metasprachensymbole, zugelassen. Somit ist das beliebige auskommentieren von Dokumentteilen möglich.
Als zentrale Einschränkung dürfen (aus SGML-Kompatibilitätsgründen) keine zwei aufeinanderfolgenden Trennstriche (hyphen-minus, ISO 10646 #x2D) innerhalb eines Kommentars auftreten, da diese fehlerhafterweise als Beginn des Kommentarendes interpretiert würden.

Der gesamte Inhalt eines Kommentars wird als uninterpretierte Zeichenkette in der Eigenschaft content des Comment Information Items abgelegt.
Zusätzlich verweist jeder Kommentar über die bekannte parent-Eigenschaft auf seinen Elternknoten. Wie bereits durch die beiden Einsatzformen angedeutet, kann es sich hierbei ausschließlich um ein Document Information Item oder ein Element Information Item handeln.

Das Beispiel zeigt verschiedene Einsätze von Kommentaren. Zunächst eine einzeilige Anmerkung, die nur verschiedene Zeichen versammelt. Im Anschluß einen mehrzeiligen Kommentar, der auch XML-Strukturen beinhaltet. Ein prozessierender Zugriff auf den Kommentarinhalt ist jedoch nicht vorgesehen, und wird durch gängige Parser und APIs zumeist nicht unterstützt.

Processing Instruction Information Item

Im Gegensatz zu den prinzipiell in beliebigem Freitext formulierbaren Kommentaren, die üblicherweise zur Kommunikation mit einem menschlichen Leser des XML-Dokuments dienen, zielt die Processing Instruction und das zugehörige Element des Information Sets auf Kommentare, welche einen maschinellen Verarbeiter des XML-Dokuments, den XML-Prozessor, betreffen.

Im Grunde genommen läuft die Anreicherung eines XML-Dokuments mit Verarbeitungsinformation der Idee einer deskriptiven Auszeichnungssprache entgegen ...
Jedoch wurde für die XML beschlossen, nicht zuletzt aus Kompatibilitätsgründen zu SGML, dieses Sprachmerkmal beizubehalten. Eine mögliche weitere Erklärung könnte das syntaktische Aussehen der XML-Deklaration innerhalb des des Dokumentprologs sein. Ihre in Produktion 23ff festgelegte Struktur stellt eine Anwendung der Processing Instruction dar, auch wenn dies innerhalb der Spezifikation nicht explizit formuliert wird.

Die Syntax einer Processing Instruction lautet:

                  

                     

                        [16]
                        PI
                        ::=
                        '<?' PITarget (S (Char* - (Char* '?>' Char*)))?    '?>'
                     

                     

                        [17]
                        PITarget
                        ::=
                        Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

Eine Processing Instruction wird demnach immer durch eine öffnende Winkelklammer und ein folgendes Fragezeichen eingeleitet. Daran schließt sich die Benennung der Applikation an, für die diese Instruktion eingefügt wurde. Optional können weitere Zeichen -- ausgenommen der Kombination aus Fragezeichen und schließender Winkelklammer -- folgen.
Das adressierte System kann beliebig identifiziert werden, jedoch ist die Zeichenkette XML in allen Variationen ausgeschlossen.
Unbedachterweise verbietet die Spezifikation jedoch nicht die Bildung von Namen, die XML als Präfix nutzen ... Jedoch sollte von der Nutzung solcher Konstruktionen abgesehen werden, da sie zur Verwirrung der (menschlichen) Leser beitragen.

Wie Kommentare auch können Processing Instructions an beliebiger Stelle innerhalb des XML-Dokuments auftreten: Vor Beginn des Wurzelelements sowie im Rumpf jedes Elements. Nicht gestattet ist ihre Angabe in Elementnamen und Attributen.
Ergänzend sei angemerkt, daß die Angabe von Processing Instructions auch innerhalb der Document Type Definition erfolgen kann. (siehe Document Type Definition Information Item ).

Begründen Sie mit Hilfe der XML-Spezifikation warum Processing Instructions nicht innerhalb von Elementen und Attributen zugelassen sind.
Hinweis: Es gibt mehr als eine Begründung!

Das Processing Instruction Information Item enthält die angesprochene Zielapplikation als Namen innerhalb der Eigenschaft target.
Der weitere Inhalt der Deklaration wird uninterpretiert als Zeichenkette in die Eigenschaft content übernommen.
Neben einem Verweis auf die Basis-URI der Processing Instruction wird durch parent das Elternelement -- entweder ein Knoten des Typs Document Information Item oder Element Information Item -- referenziert.

Zur Formalisierung der Identifikation der Zielapplikation empfiehlt die XML-Spezifikation die Verwendung des Sprachmittels Notation.

Notation Information Item

Notationen können nicht in XML-Dokumenten auftreten, sondern sind DTDs vorbehalten.
Dennoch sollen sie hier wegen ihrer Berücksichtigung im Information Set und der Verbindung zu den Processing Instructions kurz eingeführt werden.

Durch Notations können Dateninhalten externe Quellen (etwa: URLs oder Applikationen) zugeordnet werden. Der Grundgedanke liegt in der Erweiterung der Ausdrucksmächtigkeit eines XML-Dokuments. Parser berücksichtigen solch typisierte Inhalte jedoch nicht. Die Behandlung muß (proprietär) in der datenverarbeitenden Applikation erfolgen.
Die Syntax der Notation lautet:

               
                  

                     

                        [82]
                        NotationDecl
                        ::=
                        '<!NOTATION' S Name S (ExternalID | PublicID) S?    '>'
                     

                     

                        [83]
                        PublicID
                        ::=
                        'PUBLIC' S PubidLiteral
                     

                     

                        
                           [75]
                        
                        ExternalID
                        ::=
                        'SYSTEM' S SystemLiteral
                     

                     

                        
                        
                        
                        | 'PUBLIC' S PubidLiteral S SystemLiteral

Die einfachst denkbare Anwendung von Notations zielt auf Informationen, deren Inhalte nicht durch den XML-Prozessor auf syntaktische Korrektheit geprüft werden. Dies sog. unparsed entities werden aus einem eineindeutigen Namen und einer freien Zeichenkette gebildet.
Die Zeichenkette bezeichnet primär die als URI (gemäß RFC 2396 und 2732) codierte Identifikation des verarbeitenden Systems. Im Falle standardisierter Inhalte kann auf einen public identifier zurückgegriffen werden. Üblich ist die Verwendung von system identifiern, die auf eine bekannte URI oder ein installiertes Anwendungsprogramm verweisen.

Hinweis: Die Deklarationen in DTD-Syntax -- erkennbar am einleitenden Ausrufezeichen (!) -- sind kein XML! Sie müssen daher nicht den syntaktischen Konventionen der Extensible Markup Language genügen!

Im Beispiel wird nach der DOCTYPE-Deklaration DTD-Syntax verwendet, um das Inhaltsmodell des nachfolgenden XML-Dokuments festzulegen. Die genaue Bedeutung der DTD-Konstrukte wird im Abschnitt 1.4 behandelt.
Das Beispiel beinhaltet drei Notationselemente: isoDate, gif und hex. isoDate referenziert die internationale Norm 8601 als PDF-Dokument.
Die durch hex definierte NOTATION wird im XML-Dokument verwendet.
Diese Anwendung offenbart auch einen weiteren Aspekt dieses Konstrukts; die Nachbildung von Datentyp-ähnlichen Strukturen, die jedoch durch den Anwendungsprogrammierer umgesetzt werden müssen.
Im Vergleich der beiden SYSTEM-Referenzen zeigt sich die Allgemeinheit des URI-Mechanismus als Schwäche. Da anhand der URI nicht ermittelbar ist, ob es sich bei der identifizierten Lokation um ein Dokument, ein System oder ein ausführbares Programm handelt, läßt sich keine verbindliche Semantik zur Behandlung von NOTATION-Elementen angeben.
Die mit gif benannte Notation definiert einen Public-Identifier, der nicht auf eine URI verweist, sondern eine weltweit eindeutige Benennung darstellt. Die Abbildung auf eine Systemlokation zur Behandlung der Notation kann durch die zusätzliche Angabe eines System-Identifiers erfolgen. Liegt eine solche nicht vor, muß der XML-Prozessor für die Abbildung Sorge tragen.
Ein weiteres Beispiel für die Verwendung des NOTATION-Konstrukts findet sich im Zusammenspiel mit ungeprüften Entitäten.

Jedes NOTATION-Element wird im Information Set durch ein Notation Information Item repräsentiert. Es enthält neben dem Namen (Eigenschaft name) die beiden möglichen Identifierinhalte in den Eigenschaften system identifier bzw. public identifier. Beide Eigenschaften sind Zeichenketten-artig; lediglich die URI-spezifische Inhaltsnormalisierung wird (wie in der XML-Spezifikation beschrieben) durchgeführt.

Document Type Declaration Information Item

Dokumente, zu denen eine -- in der Sprache DTD formulierte -- explizite Grammatik existiert, verfügen über eine DOCTYPE-Deklaration, welche den durch URI identifizierten Ablageort der DTD enthält.
Die Charakteristika dieser Information sind im Document Type Declaration Information Item zusammengefaßt. Es enthält alle Informationen, die im XML-Dokument über die DTD vorliegen. Daher bietet es keinen Zugriff auf die durch die DTD festgelegte Grammatik!
Im Einzelnen bietet der Information Set Knotentyp:

  • system identifier: Verweis auf die externe DTD (external subset), falls vorhanden.
  • public identifier: Verweis auf eine externe DTD, die durch einen public identifier identifiziert wird.
  • children: Ungeordnete Menge, die Verweise auf Processing Instruction Information Items enthält, die innerhalb der DTD definiert wurden.
  • parent: Der Verweis auf das übergeordnete Document Information Item

Das Beispiel zeigt zwei DOCTYPE-Deklarationen. Zunächst eine SYSTEM-Deklaration, welche die Datei abc.dtd im aktuellen Dateisystemkatalog über eine URI referenziert.
Die zweite Deklaration zeigt die HTML v4.01-Standarddeklaration. Für sie existiert der dargestellte PUBLIC-Identifer. Zusätzlich wurde ein SYSTEM-Identifier (er folgt direkt ohne Schlüsselwort auf den PUBLIC-Identifer) angegeben, der, per URI, auf das DTD-Dokument beim W3C verweist.

Unexpanded Entity Reference Information Item

Im Abschnitt über das Character Information Item wurden bereits die Vordefinierten Textersetzungsmuster eingeführt, um die als Metasymbole dienenden Zeichen auch im Informationsbereich von XML-Dokumenten verwenden zu können.
Das für die fünf vordefinierten Symbole gewählte Verfahren steht auch dem Anwender zur Definition eigener Ersetzungsmuster offen. Die Definition kann ausschließlich in der Document Type Definition, oder dem DTD-Abschnitt eines Dokuments, erfolgen.
Diese Muster werden als Entitäten (engl. entities) bezeichnet.

Die Syntax ist wie folgt festgelegt 

                  

                     

                        [71]
                        GEDecl
                        ::=
                        '<!ENTITY' S  Name  S  EntityDef S? '>'
                     

                     

                        [4]
                        NameChar
                        ::=
                        Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar |    Extender
                     

                     

                        [73]
                        EntityDef
                        ::=
                        EntityValue | (ExternalID     NDataDecl?)
                     

                     

                        [9]
                        EntityValue
                        ::=
                        '"' ([^%&"] | PEReference | Reference)* '"'
                     

                     

                        
                        
                        
                        |  "'" ([^%&'] | PEReference | Reference)* "'"
                     

                     

                        
                           [76]
                        
                        NDataDecl
                        ::=
                        
                           S  'NDATA' S  Name

Aus der Syntax ergeben sich zwei Klassen von Entitäten: Die durch eine URI und evtl. öffentlichen Namen identifizierten externen Entitäten, und die internen Entitäten, deren Inhaltsdefinition direkt rechts neben dem Schlüsselwort ENTITY gegen ist.
Die Verwendung von Entitäten kann an jeder Stelle des Informationsbereichs eines XML-Dokuments gestattet werden. Daher können Element- und Attributnamen keine Entitätsreferenzen enthalten.
Der Einsatz erfolgt, wie für die vordefinierten entities gezeigt, durch namentliche Referenzierung mit einem vorgestellten Kaufmanns-Und und einem abschließenden Semikolon.

Referenzierungssyntax: & entityName ;

Das Beispiel zeigt die drei möglichen Ausprägungen der Entitätsdefinitionen. entA deklariert eine interne Entität, deren Auftreten durch die Zeichenfolge abc ersetzt wird.
Durch entB und entC werden externe Quellen angesprochen. Die verwendete Syntax ist dabei zu der bei NOTATIONs eingeführten identisch. Während entB ausschließlich eine lokal bekannte Referenz darstellt, bedient sich entC des PUBLIC-Identifiers um darüberhinaus auch eine öffentlich bekannte Quelle anzusprechen.
Im Dokument werden alle drei Entitäten über den selben Syntaxmechanismus eingebunden.

Innerhalb des Information Sets werden nicht-expandierte Entitäten durch das Element Unexpanded Entity Reference Information Item repräsentiert (für alle expandierten ist ihre Herkunft vollkommen transparent und für die Applikation nicht von Interesse).
Es definiert folgende Eigenschaften:

  • name: Name der Entität.
  • system identifier: Falls vorhanden, der angegebene SYSTEM-Identifier.
    (Im Beispiel: http://www.jeckle.de/vorlesung/xml/script.html bzw. file://symbols)
  • public identifier: Der öffentliche Identifier, der zuvor entsprechend Abschnitt 4.2.2 der XML-Spezifikation bearbeitet wurde.
    (Im Beispiel: -//FHA//Symbol//DE)
  • parent: Das Element Information Item, welches die Entität enthält.
Unparsed Entity Information Item

Mit der XML-Syntaxproduktion 76 wird als zusätzlicher Entitätstyp die explizit nicht zu prüfende Entität (engl. unparsed entity) eingeführt. Sie kann beispielsweise dazu verwendet werden, um Binärdaten wie Bilder, Videos, o.ä. aus einem XML-Dokument zu referenzieren.

Das Beispiel definiert zunächst die NOTATION für das Graphikformat GIF über dessen PUBLIC-Identifier. Diese wird innerhalb der Entität entA zur Definition der ungeprüften Inhaltsreferenz auf die Datei xyz.gif herangezogen.

Seitens des Information Sets stellt das Unparsed Entity Information Item eine Abwandlung der im vorhergehenden betrachteten Entitätsreferenz dar.
Im Einzelnen definiert der Information Set die Eigenschaften:

  • name: Name der Entität.
  • system identifier: Falls vorhanden, der angegebene SYSTEM-Identifier.
    (Im Beispiel: xyz.gif)
  • public identifier: Der öffentliche Identifier, der zuvor entsprechend Abschnitt 4.2.2 der XML-Spezifikation bearbeitet wurde.
    (Im Beispiel: -//Compuserve Information Services//NOTATION Graphics Interchange Format//EN)
  • notation: Referenz auf das Notation Information Item, welches auf die Inhaltsdefinition der Entität verweist.

Die Darstellung der Abbildung faßt die syntaktischen Elemente abgekürzt zusammen:

Namespace Deklaration Information Item

Jedem im XML-Dokument definierten Namensraum ist ein Namespace Deklaration Information Item zugeordnet. Es enthält die notwendigen syntaktischen Details zur Identifikation des Namensraumes:

  • prefix: Das gewählte Präfix des Namensraumes, bzw. leer falls es sich um den Vorgabenamensraum handelt.
  • namespace name: Der Name des Namensraumes, an den das Präfix gebunden ist.

Für das Beispiel lauten die Namensräume wie folgt:

root (Das Element befindet sich im leeren Namensraum) elementA (Das Element befindet sich im leeren Namensraum) elementB http://www.fh-furtwangen.de elementC (Das Element befindet sich im leeren Namensraum) elementD http://www.xyz.com

Eine ausführliche Betrachtung zur Verwendung von Namensräumen findet sich im entsprechenden Abschnitt.

Die Graphik der Abbildung stellt alle diskutierten Elemente des Information Sets in der Übersicht mit ihren Beziehungen dar. Zur Veranschaulichung wurde eine einfache Graphenstruktur gewählt, die alle Informationseinheiten als Knoten (darstellt als Ellipsen) und alle zugelassenen Beziehungen als gerichtete Kanten zwischen diesen enthält. Zusätzlich ist an die Kanten die Art der Beziehung angetragen.
Den Ausgangspunkt der baumartigen Struktur eines XML-Dokuments bildet die im Zentrum abgebildete Primitive Document Information Item, die alle weiteren Inhalte eines Dokuments über die children-Kante als Kindknoten enthält. Ferner fällt in dieser Darstellung besonders auf, daß lediglich Element Information Items über weitere Kindknoten verfügen und so die charakteristische XML-Struktur herausbilden. Alle übrigen Primitive dienen überwiegend als Blattknoten des Baumes.

Die Graphik der Abbildung setzt die durch den Infoset-Standard definierte Semantik und die darauf aufsetzenden Syntaxen in Beziehung. Der XML-Basisstandard definiert hierbei nur eine von mehreren möglichen Syntaxen zur Darstellung von Infoset-Ausprägungen. Ebenso denkbar wäre der Einsatz anderer Darstellungen gleicher Mächtigkeit wie beispielsweise der S-Expression aus LISP oder objektorientierte Umsetzungen.

Auf Basis der Definitionen des Information Sets läßt sich ein beliebiges XML-Dokument, welches den Strukturierungsprinzipien des Infosets folgt, als wohlgeformt (well-formed) charakterisieren.

Ein textartiges Objekt, dessen Inhalt folgenden Anforderungen genügt:
  • Das XML-Dokument nutzt eine DTD, oder enthält die Deklaration standalone="yes"
  • Zu jedem Start-Tag existiert genau ein Ende-Tag.
    Bei leeren Elementen können diese zu einem Tag zusammenfallen.
  • Korrekte Elementschachtelung, d.h. Elemente überlappen einander nicht.
  • Genau ein Wurzelelement.
  • Alle Attributwerte sind in einfachen oder doppelten Anführungszeichen.
  • Kein Start-Tag (oder Tag der ein leeres Element einleitet) enthält zwei oder mehr Attribute desselben Namens.
  • Keine Kommentare oder Processing Instructions innerhalb von Tags.
  • Kommentare beginnen und enden mit genau zwei Bindestrichen.
  • Die Sonderzeichen < und & treten nicht innerhalb von Elementinhalten oder Attributwerten auf.

siehe XML-Spezifikation

Der Textstrom des Beispiels zeigt ein nicht-wohlgeformtes XML-Dokument, welches gegen eine Reihe der in Definition verstößt:

So findet sich in Zeile 3 ein nicht in die erforderlichen Anführungszeichen eingeschlossener Attributwert.
Der textuelle Elementinhalte des in Zeile 4 geöffneten Elements elementB enthält ein öffnendes Winkelklammersybol, welches um Fehler während des Einlesevorganges zu vermeiden durch die alternative Zeichensequenz &lt; hätte ersetzt werden müssen. Darüberhinaus fehlt das korrekte schließende Tag zum Öffnenden.
Innerhalb des Elements elementC der Zeile 6 wird zweifach ein identisch benanntes Attribut definiert.
Im öffnenden Tag des in Zeile 7 definierten Elements elementD findet sich eine -- dort nicht zugelassene -- Processing Instruction.
Überdies überlappen sich die Elementgrenzen der Elemente elementC und elementD und zusätzlich wird der in Zeile 10 plazierte Kommentar nicht durch die erforderlichen genau zwei Bindestriche eingegrenzt.

 Namensräume

Die XML-Namensräume wurden schon verschiedentlich erwähnt. Sie bilden die wichtigste, und offensichtlichste Weiterentwicklung der XML-Urspezifikation seit ihrer Veröffentlichung.
Trotz ihrer engen Beziehung zum XML-Kernstandard bildet die Recommendation Namespaces in XML eine eigenständige Spezifikation. Aufgrund der engen syntaktischen Beziehung zum XML-Standard und der großen praktischen Bedeutung, sowie des Einflusses auf die weitere Entwicklung verschiedenster Sekundärstandards und XML-Sprachen, werden die Namensräume explizit in der Neuauflage des XML-Standards berücksichtigt. Einen Beleg hierfür bildet die Anmerkung zu Abschnitt 2.3 Common Syntactic Constructs . Dort wird von der -- laut Syntaxproduktion 5 erlaubten -- Verwendung des Doppelpunktes in Elementnamen abgeraten. Dies geschieht, um Mehrdeutigkeiten, oder schlichtweg der Verwirrung des Anwenders, vorzubeugen, da es sich beim Doppelpunkt um ein Symbol besonderer Bedeutung innerhalb der Namensraumdeklarationen handelt.

Warum Namensräume?
Die breite Entwicklung immer neuer XML-Sprachen führt zwangsläufig zu Mehrfachentwicklungen für ähnliche oder identische Problemstellungen. Technisch betrachtet äußerst sich dies -- bei natürlichsprachlicher Benennung der Elemente -- durch die Verwendung identischer Bezeichner in verschiedenen XML-Sprachen. Hierbei bilden die verschiedenen Sprachen Anwendungskontexte, innerhalb derer die Bezeichner, durch Einbezug der Anwendungssemantik, eindeutig sind; andernfalls kann unterstellt werden, daß bereits durch die Sprachentwicklung andere Benennungskonventionen gewählt worden wären.
In der Konsequenz der Verfügbarkeit verschiedenster XML-Sprachen für beliebige Anwendungsbereiche entsteht der (berechtigte) Wunsch existierende Sprachfragmente in eigene Sprachen zu integrieren, um so zeitraubenden und vielfach fehleranfälligen Mehrfachentwicklungen vorzubeugen. Jedoch tritt bei diesem Integrationsszenario die u. U. kontextabhängige Elementeindeutigkeit zu Tage.
Das Beispiel zeigt zwei Dokumente identischen Informationsumfanges, die lediglich strukturell differieren.

Die beiden Bäume mit Information Set -Ausprägungen zeigen die Struktur der Beispieldokumente. Dabei sind Knoten die den selben Inhalt repräsentieren mit identischen Farben unterlegt, unabhängig davon um welchen Knotentyp es sich handelt. Die Character Information Item Knoten wurden aus Übersichtlichkeitsgründen weggelassen und durch Punkte angedeutet, sie sind jedoch für die vorliegende Betrachtung nicht von Interesse.

Einige der Elemente und Attribute werden in beiden Dokumenten mit gleichen Inhalten verwendet; z.B. Name, Ort oder PLZ. Dies äußert sich in identischen Teilbäumen unterhalb der Information Set-Knoten welche diese XML-Elemente repräsentieren. Hieraus läßt sich ableiten, daß die beiden vorgestellten Sprachen an den genannten Stellen keine strukturelle Differenz aufweisen.
Dagegen unterscheiden sich die Kindknoten der Elemente Rechnung und Kunde hinsichtlich ihrer Struktureigenschaften. So folgt im ersten Beispieldokument auf das Rechnung-Element direkt der Kunde, während im zweiten XML-Dokument zunächst ein Element mit dem Namen Rechnungsanschrift erwartet wird.
Dergleichen gilt für die Kindelemente des Kunden. Im zweiten Beispieldokument wird die diesem Element untergeordnete Kundennummer durch ein Attribut (kundenNr) dargestellt. Dagegen codiert das erste Beispiel diese Information direkt in den Elementinhalt.

Solange die beiden Dokumente in unterschiedlichen Anwendungswelten (Unternehmen o. ä.) verwendet werden, ist der gewählte Ansatz nicht problematisch. Bedenklich wird er jedoch in mindestens zweierlei Hinsicht:
Zunächst bei der Mischung der beiden Dokumente. Dieser Wunsch tritt bei praktischen Problemstellungen häufig auf, wenn es um die Übernahme von XML-codierten Daten in ein anderes XML-Dokument geht. In der Konsequenz folgt das entstehende Zieldokument nicht mehr den Strukturierungsregeln eines der Ausgangsdokumente; mithin entsteht eine neue Dokumentstruktur, deren Regeln nicht explizit dokumentiert sind.
Eine weitaus größere Herausforderung stellt die Zusammenfassung und Veröffentlichung von XML-Strukturen in sog. Schemabibliotheken oder Datenbanken dar. Hier werden zwar die Dokumente nicht vereinigt, jedoch offenbart sich die gleiche Anwendungsdomäne (z.B. Rechnungsverwaltung, Stücklisten, Produktstrukturen) als problematisch, da sie die XML-Strukturen in direkte Konkurrenz treten läßt. In Zeiten immer stärker werdenden ökonomischen Flexibilisierungsdruckes erweist sich dies als äußerst kontraproduktiv, im Hinblick auf eine angestrebte Standardisierung. Die offene Konkurrenz verschiedener Dialekte innerhalb einer Domäne verzögert damit oft die Entscheidung zum Einsatz eines Sprachformates.

Einen anderen interessanten Anwendungsfall stellt der ausdrückliche Wunsch nach der Einbettung fremder Sprachelemente dar. Diese Form der Wiederverwendung knüpft an das durch öffentlich verfügbare XML-Formate eröffnete Anwendungsfeld an. Da nicht in jedem Fall ein alle Anforderungen erfüllendes existierendes XML-Format ermittelt werden kann, jedoch verschiedene vorhandene Formatteile des gewünschten Umfanges abdecken, entsteht der Wunsch nach einer selektiven Weiterverwendung. Ein bekanntes Beispiel bilden Freitexte in beliebigen XML-Sprachen, welche auf Teile des (X)HTML-Sprachumfanges zurückgreifen. Gleichzeitig ist damit die Semantik der Elemente durch den zugehörigen W3C-Standard festgelegt. XHTML selbst stellt ein interessantes Anwendungsbeispiel für die gemeinsame Verwendung verschiedener XML-Sprachen in einem Dokument dar. So können Web-Seiten neben den bekannten Textstrukturen (XHTML) auch mathematische Symbole und Formeln (in der XML-Sprache MathML) und Vektorgraphiken (in der XML-Sprache SVG) enthalten.
Als Nebeneffekt der Wiederverwendung existierender XML-Sprachen verringern sich mögliche Fehlerquellen, was in der Konsequenz zur Erhöhung der Qualität der entstehenden Sprachen führt.

Zusammenfassend lassen sich die (Hinter-)Gründe der Namensraumeinführung wie folgt darstellen:

  • Wiederverwendung bestehender (fremder) XML-Strukturen in eigenen Dokumenten.
  • Wunsch nach breiteren Standards.
  • Verringerung des Designaufwandes.
  • Nutzung bereits gesammelter Designerfahrung.
  • Zusammenführung verschiedener XML-codierter Inhalte (heterogeneous content syndication).
XML-Namensräume stellen eine XML-basierte Syntax zur Verfügung um Element- und Attributnamen eines Vokabulars eindeutig zu identifizieren und so Bedeutungsüberschneidungen durch gleichbenannte Elemente- oder Attribute in zu unterscheidenden Vokabularen auszuschließen. XML-Namensräume bilden damit die notwendige Voraussetzung zur freien dezentralen Entwicklung eigener Vokabulare ohne die Möglichkeit einer späteren Syndikatisierung zu verlieren.

Konzept der Namensräume:
Die Recommendation Namespaces in XML definiert die Syntax und Semantik der Namensräume. Ihr Konzept wurde rund ein Jahr nach Verabschiedung der ersten XML-Version eingeführt. Daher wurde der Kompatibilität mit bereits existierenden XML-Dokumenten große Priorität eingeräumt.

Grundidee der Namensräume ist es, die Element- und Attributnamen dergestalt zu erweitern, daß (auch nach Vereinigung beliebiger Dokumente wieder) eineindeutige Bezeichner entstehen. Dies könnte durch anwenderdefinierte Erweiterungen geschehen, sie trügen jedoch wiederum die Gefahr in sich, daß sie unbeabsichtigt mehrfach benutzt würden.
Daher scheidet der unkoordinierte Einsatz solcher Namenserweiterungen aus. Jegliche Koordination bedingt jedoch inhärent eine zentrale Vergabestelle zur Registrierung der vergebenen Namen, die über die Eindeutigkeit wacht und Mehrfachnutzungen unterbindet.
Die Einführung einer solchen Stelle hätte jedoch einen unüberschaubaren Verwaltungsaufwand bedeutet, den das W3C nicht zu leisten im Stande wäre. Man nehme nur als Vergleich das Vergabeverfahren von Einträgen des Internet Domain Name Systems (DNS), welches bereits dezentral durch die einzelnen nationalen Domain-Registrars gehandhabt wird. Der dort anzutreffende Aufwand hätte sich für XML-Namensräume potenziert, legt man pro Domainadresse mehrere Namensräume zugrunde.

Ziel des W3C war es, durch die Namensräume einen gleichermaßen mächtigen als auch leicht zu handhabenden und zu administrierenden Identifikationsmechanismus zu etablieren. Offenkundig wird diesem Anspruch nur ein (überwiegend) dezentraler, aber dennoch die Eineindeutigkeit garantierender, Ansatz gerecht.
Diesen Anforderungen genügt das aus IETF RFC 2396 bekannte Namensschema der Uniform Resource Identification (URI) (später aktualisiert in ). Es kombiniert zentrale und dezentrale Elemente in der Handhabung, und ermöglicht so -- trotz Existenz und Pflege einer zentralen Registratur -- größtmögliche Flexibilität in der Anwendung. Der bekannteste Einsatz von URI-Namen ist der im World-Wide-Web allgegenwärtige Uniform Ressource Locator (URL) (); einer Untermenge der URI.
Die zentrale Komponente findet sich im Domainnamen verwirklicht. Er ist entweder durch die IP-Adresse (konkret: IPv4-Adresse; im Falle des RFC 2732: der IPv6-Adresse) oder deren literaler Repräsentation gegeben. Unterhalb der Domainebene kann durch deren Verwalter eine beliebige Strukturierung vorgenommen werden. Die verschiedenen Ebenen werden dabei durch ISO-10646/ASCII #x2F / voneinander abgetrennt.
Wie auch bereits bei URLs notwendig, ist das Schema (URI scheme) (z.B. http) zwingend mitanzugeben.

Trotz der Möglichkeit XML-Namensräume durch URLs zu identifizieren handelt es sich dabei nicht die Bezeichnung einer Internetquelle. Die verwendete Zeichenkette dient ausschließlich Benennung der im Namensraum versammelten XML Element Information Items und Attribute Information Items.
Die Auflösung des Namensraumbezeichners durch einen XML-Prozessor ist nicht vorgesehen.

Nachfolgend ist die in definierte Syntax einer URI wiedergegeben. Sie wurde behutsam an die in der XML-Spezifikation verwendete BNF-Notation angepaßt, ohne jedoch die Produktionen in ihrer Struktur zu verändern.

                  

                     

                        [URI1]
                        URI-reference
                        ::=
                        (absoluteURI | relativeURI)? ("#" fragment)?
                     

                     

                        [URI2]
                        absoluteURI
                        ::=
                        scheme ":" ( hier_part | opaque_part )
                     

                     

                        [URI3]
                        relativeURI
                        ::=
                        ( net_path | abs_path | rel_path ) [ "?" query ]
                     

                     

                        [URI4]
                        hier_part
                        ::= 
                        ( net_path | abs_path ) ("?" query)?
                     

                     

                        [URI5]
                        opaque_part
                        ::=
                        uric_no_slash uric?
                     

                     

                        [URI6]
                        uric_no_slash
                        ::=
                        unreserved | escaped | ";" | "?" | ":" | "@" |
                     

                     

                        
                        
                        
                        "&" | "=" | "+" | "$" | ","
                     

                     

                        [URI7]
                        net_path
                        ::=
                        "//" authority abs_path?
                     

                     

                        
                           [URI8]
                        
                        abs_path
                        ::=
                        "/"  path_segments
                     

                     

                        [URI9]
                        rel_path
                        ::=
                        rel_segment abs_path?
                     

                     

                        [URI10]
                        rel_segment
                        ::=
                        (unreserved | escaped |
                     

                     

                        
                        
                        
                        ";" | "@" | "&" | "=" | "+" | "$" | "," )+
                     

                     

                        [URI11]
                        scheme
                        ::=
                        alpha (alpha | digit | "+" | "-" | "." )*
                     

                     

                        [URI12]
                        authority
                        ::=
                        server | reg_name
                     

                     

                        [URI13]
                        reg_name
                        ::=
                        ( unreserved | escaped | "$" | "," |
                     

                     

                        
                        
                        
                        ";" | ":" | "@" | "&" | "=" | "+" )+
                     

                     

                        [URI14]
                        server
                        ::=
                        ((userinfo "@")? hostport)?
                     

                     

                        [URI15]
                        userinfo
                        ::=
                        ( unreserved | escaped |
                     

                     

                        
                        
                        
                        ";" | ":" | "&" | "=" | "+" | "$" | "," )*
                     

                     

                        [URI16]
                        hostport
                        ::=
                        host (":" port)?
                     

                     

                        [URI17]
                        host
                        ::=
                        hostname | IPv4address
                     

                     

                        [URI18]
                        hostname
                        ::=
                        ( domainlabel "." )* toplabel (".")?
                     

                     

                        [URI19]
                        domainlabel
                        ::=
                        alphanum | alphanum *( alphanum | "-" ) alphanum
                     

                     

                        [URI20]
                        toplabel
                        ::=
                        alpha | alpha (alphanum | "-" )* alphanum
                     

                     

                        [URI21]
                        IPv4address
                        ::=
                        digit+ "." digit+ "." digit+ "." digit+
                     

                     

                        [URI22]
                        port
                        ::=
                        digit*
                     

                     

                        [URI23]
                        path
                        ::=
                        (abs_path | opaque_part)?
                     

                     

                        
                           [URI24]
                        
                        path_segments
                        ::=
                        segment ("/" segment)*
                     

                     

                        [URI25]
                        segment
                        ::=
                        pchar* (";" param)*
                     

                     

                        [URI26]
                        param
                        ::=
                        pchar*
                     

                     

                        [URI27]
                        pchar
                        ::=
                        unreserved | escaped |
                     

                     

                        
                        
                        
                        ":" | "@" | "&" | "=" | "+" | "$" | ","
                     

                     

                        [URI28]
                        query
                        ::=
                        uric*
                     

                     

                        
                           [URI29]
                        
                        fragment
                        ::=
                        uric*
                     

                     

                        [URI30]
                        uric
                        ::=
                        reserved | unreserved | escaped
                     

                     

                        
                           [URI31]
                        
                        reserved
                        ::=
                        ";" | "/" | "?" | ":" | "@" | "&"    | "=" | "+" |
                     

                     

                        
                        
                        
                        "$" | ","
                     

                     

                        [URI32]
                        unreserved
                        ::=
                        alphanum | mark
                     

                     

                        [URI33]
                        escaped
                        ::=
                        "%" hex hex
                     

                     

                        [URI34]
                        hex
                        ::=
                        digit | "A" | "B" | "C" | "D" | "E" | "F" |
                     

                     

                        
                        
                        
                        "a" | "b" | "c" | "d" | "e" | "f"
                     

                     

                        [URI35]
                        digit
                        ::=
                        "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     

                     

                        
                        
                        
                        "8" | "9"
                     

                     

                        [URI36]
                        uric_no_slash
                        ::=
                        unreserved | escaped | ";" | "?" | ":" | "@" |
                     

                     

                        
                        
                        
                        "&" | "=" | "+" | "$" | ","

Die Produktionen alphanum, lowalpha sowie upalpha zur Konstruktion der alphanumerischen Namen wurden aus Übersichtlichkeitsgründen weggelassen.

Neben einigen anderen gängigen URI-Varianten stellt das nachfolgende Beispiel einige der möglichen syntaktisch korrekten URIs zusammen, die für die späteren Betrachtungen von Interesse sind.

Exkurs: URIs, URLs, URNs ...

Vielfach wird in der Praxis die Abgrenzung der im Internet gebräuchlichen Adressierungs- und Identifikationsmechanismen nicht trennscharf vollzogen.
Darüberhinaus trat im Laufe der Entwicklung eine merkliche Bedeutungsverschiebung insbesondere zwischen der Uniform Resource Identifikation und den als WWW-Adressen genutzten Uniform Resource Locators ein.

Gegenwärtig wird die Begriffsabgrenzung wie in Abbildung schematisch dargestellt vollzogen:

  • Uniform Resource Identification (URI) dient als abstrakter Oberbegriff eineindeutig identifizierbarer Web-Ressourcen.
    Konzeptionell sind URIs:
    • über Zeit und Raum eindeutig
    • für Menschen leicht zu merkend
    • mit keinerlei Registrierungskosten verbunden
    • unabhängig von der tatsächlichen Lokalisation der so identifizierten Ressource

    Der URI-Raum zerfällt in die disjunkten Bezeichnerschemata URL, URN und URC.
  • Uniform Resource Location (URL) bezeichnet den physischen Aufenthaltsort einer Ressource, etwa den Ablageort einer HTML-Seite.
    Beispiele:
    • http://www.jeckle.de/vorlesung/xml/script.html
    • http://www.wi.fh-furtwangen.de/
    • mailto:mario@jeckle.de
    • ftp://example.org/aDirectory/aFile
    • news:comp.infosystems.www
    • tel:+1-816-555-1212
    • ldap://ldap.example.org/c=GB?objectClass?one
    • urn:oasis:SAML:1.0
  • Uniform Resource Name (URN) bezeichnen den eineindeutigen Namen einer beliebigen Resource. Für die URN existiert kein Auflösungsmechanismus durch den die physische Lokation ermittelt werden könnte. URNs dienen daher ausschließlich der eindeutigen Benennung!
    Syntaktisch folgt auf das definierte Kürzel urn eine Zeichenkette welche eine Weiterklassifikation der Ressource gestattet. Hierdurch wird eine weitere Partitionierung des URN-Raumes erzielt. Diese namespace ID genannten Zeichenketten unterliegen einem globalen Registrierungszwang um ihre Eindeutigkeit zu gewährleisten. Diese Unterstrukturierungen sind in der Abbildung als ns1 bis ns3 benannt.
    Beispiele:
    • urn:oasis:names:specification:docbook:dtd:xml:4.1.2
    • urn:oid:1.3.6.1.2.1.27
  • Uniform Resource Citation (URC) schlägt die Brücke zwischen Lokationsbezeichnung und reiner Benennungskonvention. Eine URC verweist in eine Metadatenstruktur welche die physischen Ressourcen-Aufenthaltsorte katalogisiert.
    Dieser URI-Typ ist jedoch gegenwärtig kaum verbreitet.
URIs, URLs, and URNs: Clarifications and Recommendations The Anatomy of an URL

Verwendung von Namensräumen:
Am naheliegendsten wäre nach der Zielsetzung der Verwendung von URIs zur eindeutigen Benennung von XML-Element- und Attributnamen, die URI direkt vor dem XML-Bezeichner zu plazieren, evtl. separiert durch ein Trennsymbol wie den Doppelpunkt :.
Hieraus entstünden dann, auf jeden Fall eindeutige, Element- und Attributnamen wie beispielsweise für das erste Beispieldokument dieses Kapitels (die URI http://www.example.com/sales werde zur Identifizierung verwendet):

Bei entsprechender Nachbearbeitung des zweiten Beispieldokumentes mit einem anderen URI-identifizierten Namensraum, entstehen eindeutige Element- und Attributnamen, die nicht mehr kollidieren.

Jedoch verstößt diese Lösung gegen die in Produktion 5 der XML-Spezifikation formulierte syntaktische Einschränkung. Sie erlaubt das in URIs elementare Pfadtrennersymbol ( / ) (aus den URI-Produktionen 8, 24 und 31) nicht in XML-Namen (#x2F findet sich nicht in den in Produktion 85 aufgeführten Unicode-Blöcken).
Die Integration der Namensräume auf diesem Weg hätte daher eine Modifikation der XML-Spezifikation nach sich gezogen. Diese erweiternde Aufweichung der zugelassenen Namen für Elemente und Attribute hätte jedoch mit der Kompatibilität zu SGML gebrochen, und somit eine der Grundforderungen der XML-Entwicklung verletzt.
Darüberhinaus ist die Spezifikation vollständiger URIs für Menschen unhandlich und reduziert die Lesbarkeit der entstehenden XML-Dokumente.

Als Ausweg und pragmatischer Kompromiß zwischen eineindeutigen Namenspräfixen und Lesbarkeit wurde daher ein zweistufiges Verfahren eingeführt. Es erlaubt die Zuordnung von URIs zu Präfixen. Dieser Vorgang wird als Bindung bezeichnet.
Diese Präfixes können Attributen oder Elementen vorangestellt werden, um sie in bestimmte Namensräume zu übernehmen.
Für die Präfixe gelten dieselben Bildungsgesetze wie für die Element- und Attributnamen. Im Einzelnen legt die Namespace Recommendation fest: (im XML-Namespace-Dokument nachschlagen)

               
                  

                     

                        
                           [NS7]
                        
                        Präfix
                        ::=
                        NCName
                     

                     

                        
                           [NS4]
                        
                        NCName
                        ::=
                        (Letter | '_') (NCNameChar)*
                     

                     

                        [NS5]
                        NCNameChar
                        ::=
                        
                           Letter | Digit | '.' | '-' | '_'
                     

                     

                        
                        
                        
                        | CombiningChar
                        
                     

                     

                        
                        
                        
                        | Extender

Anmerkung: Die rechten Seiten der Produktionen beziehen sich entweder auf die dargestellten Definitionen des Namespace-Standards oder auf Syntaxregeln der XML-Recommendation.

Die Bindung einer URI an ein -- gemäß Produktion NS7 frei wählbares -- Präfix geschieht durch das reservierte Attribut xmlns.
Die Syntax hierfür wird mit

                  

                     

                        [NS2]
                        PräfixedAttName
                        ::=
                        'xmlns:' NCName

angegeben.

Nach der Bindung der URI an das Präfix kann dieses jedem Element oder Attribut vorangestellt werden, um es in den Namensraum zu übernehmen.
Hierdurch verändert sich die Produktion Name aus der XML-Spezifikation zum qualifizierten Namen, der durch die Voranstellung des Präfixes entsteht. Der rechts vom trennenden Doppelpunkt folgende Elementname stellt den lokalen Namen (innerhalb des Namensraumes dar). Dieser lokale Name darf keinen Doppelpunkt mehr enthalten; insofern schränkt Produktion NS8 in Verbindung mit NS4 die Festlegung der Produktion 5 der XML-Spezifikation ein.

               
                  

                     

                        
                           [NS6]
                        
                        QName
                        ::=
                        (Präfix ':')?    LocalPart
                     

                     

                        [NS8]
                        LocalPart
                        ::=
                        
                           NCName

Während der Verarbeitung eines XML-Dokuments, das Namensräume nutzt, ersetzt ein XML-Prozessor jedes Auftreten eines deklarierten Präfixes transparent durch die gebundene URI.
Prozessoren, welche die Namensraum-Spezifikation unterstützen, werden als namespace aware bezeichnet. Alle anderen Prozessoren treffen die durch NS6 eingeführte Unterscheidung zwischen Präfix und LocalPart eines qualifizierten Namens nicht und betrachten die Kombination aus Präfix und Element- bzw. Attributnamen als Bezeichner. Die Präfix-URI-Bindung durch das xmlns:...-Attribut wird hierbei als gewöhnliches XML-Attribut betrachtet und führt daher zu keinen Validierungsfehlern. (Die Einschränkung der Produktion 5, ein Name dürfe nicht mit der Zeichenfolge (('X'|'x') ('M'|'m') ('L'|'l')) beginnen, stellt in der XML-Spezifikation lediglich einen Hinweis dar.)

Semantisch bildet die durch xmlns eingeleitete Deklaration ein Pseudoattribut, da es für die maschinelle Verarbeitung vorbehalten und mit festelegter Bedeutung ausgestattet ist, welche durch den XML-Dokumentautor nicht verändert werden kann.
Zusätzlich werden Namensraumdeklarationen durch Programmiersprachenschnittstellen nicht den gewöhnlichen Attributen gleichgestellt betrachtet, sondern nehmen, wie auch im Information Set, dort eine Sonderstellung ein.

Anmerkung: Auf Webseiten und in Mailinglisten finden sich manchmal Formulierungen der Struktur {namespaceName}elementName (z.B. {http://www.w3.org/2001/XMLSchema}element oder {http://www.w3.org/1999/XSL/Transform}template).
Hierbei handelt es sich um eine zwar geläufige, aber nicht spezifikationskonforme Schreibweise!
Sie dient lediglich dazu, das prinzipiell beliebig wählbare Präfix einzusparen und den gewählten Namensraum hervorzuheben.
Strukturen dieses Stils sind jedoch keine gültigen XML-Dokumente!

Angewendet auf das betrachtete Beispiel läßt sich die URI http://www.example.com/sales an das Präfix myNS1 binden. Diese Bindung steht im definierenden Element (local name: rechnung) und allen untergeordneten zur Verfügung.

Hinweis: Für das Attribut xmlns kann keine Namensraumdeklaration angegeben werden; es ist spezifikationsgemäß an keinen Namensraum gebunden.

Die Deklaration des Namensraumes mit der Präfixbindung kann auf beliebige hierarchisch höhergeordnete Elemente ausgelagert werden. In der Praxis hat es sich aus Übersichtlichkeitsgründen durchgesetzt, alle in einem XML-Dokument benutzten Namensräume mit ihren Präfixen zu Beginn des Dokuments im Wurzelelement zu definieren.
Das nachfolgende Beispiel zeigt dies anhand eines XHTML-Dokuments, das neben Elementen der Hypertextsprache auch mathematische Formeln und Vektorgraphiken enthält.

Jeder XML-Namensraum wird durch eine gültige URI identifziert. Diese URI dient ausschließlich der Benennung, daher muß sie nicht auf eine gültige Ressource verweisen.

Überschreiben des Vorgabe-Namensraums:
Aus den Beispielen ist leicht ersichtlich, daß die explizite Angabe des definierten Präfixes für jedes Element eines Namensraumes platzraubend und für die Zuordnung aller Elemente eines Teilbaumes zum selben Namensraum redundant und -- wegen des zusätzlichen Spezifikationsaufwandes -- unpraktikabel ist. Die mehrmalige explizite redundante (identische) Angabe des identifizierenden Präfixes bildet zusätzlich noch eine potentielle Fehlerquelle hinsichtlich Übertragungsfehlern und reiner Tippfehler bei manuell erstellten XML-Dokumenten.

Eine einfache Kompaktifizierungsvariante greift auf die aus den Programmiersprachen geläufigen Regeln für Namensräume zurück. Dort beinhaltet ein explizit geöffneter Block alle enthaltenen Elemente bis zum Blockendesymbol und faßt sie so zu einem Gültigkeitsbereich zusammen.
Dieses Prinzip läßt sich leicht auch auf XML-Dokumente, die immer eine streng hierarchische Baumstruktur aufweisen, anwenden.

Hierzu wird das xmlns-Attribut leicht modifiziert eingesetzt. Wird es ohne nachfolgendes Präfix und unter Weglassung des separierenden Doppelpunktes verwendet, so definiert es einen Vorgabenamensraum (default namespace). Dieser umfaßt neben dem Element, welches das Attribut beinhaltet, auch alle Kindelemente. Eine Ausnahme hiervon bilden untergeordnete Elemente, die explizit durch Präfix oder Redefinition des Vorgabenamensraumes einem anderen Namespace zugeordnet werden.

Das nachfolgende Beispiel zeigt dies für das bereits mit Namenräumen versehene Rechnungsdokument

Die syntaktische Definitionsform der Namensraumüberschreibung als XML-(Pseudo-)Attribut stellt hierbei sicher, daß für ein Element keine mehrmalige Überschreibung des Vorgabenamensraumes vorgenommen werden kann, da in diesem Falle das Attribut xmlns mehrfach im selben Elementkontext auftreten müßte, was der XML-Basisspezifikation widerspräche.

Durch die Definition des Vorgabenamensraumes für das Element rechnung und all dessen Kindelemente wird derselbe Effekt erreicht wie durch die Präfixangabe im vorangegangenen Beispiel.
Diese Schreibweise stellt lediglich eine Abkürzung der expliziten Qualifizierung jedes einzelnen XML-Namens dar. Insbesondere führt die mehrmalige Redefinition des Vorgabenamensraumes nicht zu kaskadierten Namensräumen. Jeder Namensraum ist von allen umgebenden unabhängig definiert.
So kann das Dokument des XHTML-Beispiels auch dahingehend verändert werden, daß die Namensräume erst an der Stelle im Dokument deklariert werden, an der sie auch benötigt werden.

Die Namensraumpräfixe können durch den Anwender frei vergeben werden. Sie dienen lediglich der abkürzenden Schreibweise und sind für die Namensraumauflösung unerheblich.
Daher werden zwei Elemente oder Attribute als gleich betrachtet, wenn sie lexikalisch in Namen und Namensraumidentifier übereinstimmen. Hierbei ist es unerheblich, ob der Namensraum explizit durch Präfixangabe oder durch Überschreiben des Vorgabenamensraumes definiert wurde.
Die Elemente der XML-Dokumente aus den Beispielen und befinden sich alle ausnahmslos im Namensraum http://www.example.com.

Die Abbildung zeigt das Beispieldokument in der Darstellung des W3C-Browsers Amaya.

Im Beispieldokument wird der Vorgabenamensraum dreimal, entsprechend der verschiedenen verwendeten XML-Sprachen, neu gesetzt. So wird auf html und alle direkt untergeordneten Elemente der URI-identifizierte Namensraum http://www.w3.org/1999/xhtml angewendet. head, title und body sowie dessen Kindelemente finden sich demnach, da sie keinen eigenen Namensraum definieren, ebenfalls im so definierten Vorgabenamensraum.
mrow als hierarchisch tieferstehendes Element redefiniert den Namensraum zu http://www.w3.org/TR/REC-MathML. Daher werden das Element mrow sowie all dessen Kindelemente (im Beispiel: ellipse) auch diesem zugeordnet.
Die Attribute width, height, cx , ... verfügen über kein explizites Namensraumpräfix und sind daher dem leeren Namensraum zugeordnet.
Auf den MathML-Namensraum folgend wird der Vorgabenamensraum zu http://www.w3.org/2000/svg redefiniert. Auch hier gelten dieselben Regeln, d.h. der überschriebene Vorgabenamensraum erstreckt sich auf alle Kindelemente.
Mit dem schließenden Tag svg endet auch dessen Namensraum. Alle folgenden Elemente befinden sich wieder im umgebenden Namensraum, der zu Beginn des Dokuments mit http://www.w3.org/1999/xhtml festgelegt wurde.
Die nachfolgende Graphik stellt die Namensräume nochmals farblich hervorgehoben dar.
Ein weiteres Beispiel findet sich in der Namespace-Recommendation.

Der XML-Namensraumstandard des W3C sieht die beiden im Vorhergehenden diskutierten Varianten exklusiv zueinander vor. D.h. für ein Element, welchem bereits durch Präfixangabe eine Namensraumzuordnung gegeben wurde, kann nicht zusätzlich der Vorgabenamensraum überschrieben werden. Deklarationen der Form <xyz:abc xmlns="..." ...> sind widersprüchlich; und daher illegal. (in der XML-Namespace Recommendation nachschlagen)

Das abschließende Beispiel zeigt die Verwendung zweier Vokabulare (SVG und MathML), die beide ein mit set benanntes Element definieren.
Durch die Deklaration der jeweiligen Namensräume unterscheiden sich die qualifizierten Namen, die dem (gleichnamigen) Elementnamen die Namensraum-URI voranstellen.

Präzedenz des explizit zugeordneten Namensraumes:
Eine explizit durch Präfixzuordnung vorgenommene Namensraumfestlegung besitzt Präzedenz gegenüber dem evtl. überschriebenen Vorgabenamensraum.
Findet daher für ein Element sowohl die Überschreibung des Vorgabenamensraumes, als auch gleichzeitig die Namensraumfestlegung durch explizite Präfixzuordnung statt, so wird das Element demjenigen Namensraum zugeordnet, der durch die URI identifiziert wird, an den das Präfix gebunden ist.
Dies gilt insbesondere auch dann, wenn ein und dasselbe Element sowohl über ein Präfix, als auch eine Überschreibung des Vorgabenamensraumes verfügen.
Das XML-Dokument aus illustriert dies beispielhaft. So wird ElementA -- durch Überschreibung des Vorgabenamensraumes -- dem Namensraum urn:namspaces:Namespace1 zugeordnet und diese Festlegung auch an das Kindelement ElementB weitergegeben.
Das Kindelement ElementC hingegen überschreibt die Vorgabe des Elternelements durch explizite Präfixangabe und ist daher dem durch urn:namespace:Namespace2 identifizierten Namensraum zugeordnet.
Für ElementD findet sich sowohl eine Namensraumdefinition, welche durch Überschreiben des Vorgabenamensraumes zu urn:namespace:Namespace3 stattfindet, als auch eine Präfix-gebundene Definition an den Namensraum urn:namespace:Namespace2. Gemäß der Präzedenz der expliziten Festlegung durch Präfix wird ElementD jedoch ausschließlich dem Namensraum zugeordnet, an den das angegebene Präfix ns1 gebunden ist. Im Beispiel ist dies die URI urn:namespace:Namespace2.

Aufheben der Namensraumzuweisung:
Durch Überschreibung des Vorgabenamensraumes mit der Zeichenkette leeren Inhalts -- formal der Zuweisung der leeren URI als Namensraumidentifikator -- kann eine bestehende Namensraumdefinition aufgehoben werden. Als Resultat entsteht eine Situation identisch zu einem Dokument ohne festgelegte Namensräume, d.h. die Elemente finden sich im leeren Namensraum.

Das Beispiel zeigt die notwendigen Deklarationen zur Aufhebung der Vorgabenamensraumdefinition.
So wird zwar für das Element table und alle seine Kindelemente der Vorgabenamensraum auf http://www.w3.org/TR/REC-html40 gesetzt, dies jedoch für die Kindelemente Vorname, Nachname, Straße, PLZ und Ort durch die Festlegung xmlns="" explizit für das jeweilige Element aufgehoben.

Die Aufhebung von definierten Namensräumen kann ausschließlich durch die Überschreibung des Vorgabenamensraum erfolgen. Eine Bindung der leeren URI an ein Präfix zur späteren Verwendung ist nicht zugelassen.

Namensräume für Attribute:
Abweichend von der Mimik für Elemente, dort wirkt sich ein überschriebener Vorgabenamensraum auch immer auf die Kindelemente aus, wird eine Namensraumdeklaration auf Elementebene nicht auf Attribute propagiert.
Diese Festlegung der Spezifikation mag insbesondere unter Kenntnis der Baumstruktur der Infosets, welche Attribute und Elemente gleichermaßen als Kindknoten der beherbergenden Elementinformationseinheit darstellt, verwundern. Eine mögliche Begründung dieser Asymmetrie mag in der besonderen Rolle der Attribute zur Informationsdarstellung liegen. So wird teilweise damit argumentiert, daß Attribute üblicherweise unabhängig vom aktuell umgebenden Element sein sollten und daher nur zur Darstellung von Daten herangezogen werden sollten, die nicht über einen direkten Bezug zum sie umgebenden Element verfügen.
In der Konsequenz müssen Attribute immer explizit mit einem Namensraumpräfix versehen werden, um sie einem Namensraum zuzuordnen.
Beispiel zeigt die Anwendung der Namensräume auf Attribute. So befinden sich weder das Attribute att1 des Elements ElementB, noch dasjenige von ElementD in einem Namensraum. Das mit dem Wert XYZ versehene Attribut att2 des Elements ElementC wird hingegen -- aufgrund des explizit angegebenen Präfixes -- dem Namensraum http://www.example.com/NS2 zugeordnet.
Ferner illustriert ElementC die Rolle der Namensräume als Bestandteil des identifzierenden Namens von Elementen und Attributen. Aufgrund der Interpretation des Namensraumes als Benennungsbestandteil darf das att2 benannte Attribut mehrfach auftreten, da die Zuhilfenahme des Namensraumes die eindeutige Identifikation gestattet.

Namensräume, die durch Überschreiben des Vorgabenamensraumes zugewiesen werden wirken sich ausschließlich auf Elemente und deren direkte oder transitive Kindelemente aus, sofern diese den Namensraum nicht wieder verändern.
Namensräume, die durch explizite Präfixangabe zugewiesen werden, wirken sich ausschließlich auf dasjenige Element aus vor dessen Name das Präfix plaziert ist.
Namensräume für Attribute werden ausnahmslos durch explizite Präfixangabe festgelegt und gelten ausschließlich für das Attribut selbst.

Ausgehend von der Vererbungsregel für Namensräume, sowie der Präzedenz expliziter Präfixangaben lassen sich daher folgende Auswertungsregeln definieren:

Ein Element befindet sich in demjenigem Namensraum ...

  1. ... an den das vorangestellte Präfix gebunden ist.
    Verfügt das Element über kein Namensraumpräfix, so befindet es sich in demjenigen Namensraum ...
  2. ... der auf diesem Element durch Überschreibung des Vorgabenamensraumes definiert wurde.
    Findet für dieses Element keine Überschreibung des Vorgabenamensraumes statt, so befindet es sich in demjenigen Namensraum ...
  3. ... der für das Elternelement gilt, sofern er dort Vorgabenamensraum ist.
    Man beachte: Das gilt im vorangehenden Satz umschließt sich nicht nur die Überschreibung des Vorgabenamensraumes im direkten Elternelement, sondern auch eine dort geltende Namensraumüberschreibung die in dessen Elternelement oder dessen Elternelement ... stattfand.
    Findet in keinem der Elternelemente eine Überschreibung des Vorgabenamensraumes statt, so befindet sich das Element in demjenigen Namensraum ...
  4. ... der leer ist (d.h. im leeren Namensraum).

Ein Attribut befindet sich in demjenigem Namensraum, der durch explizite Präfixangabe festelegt wurde.

Internationale URIs und Namensraumidentifikatoren:
Die Berücksichtigung von Zeichen, die in XML v1.1 zugelassenen, deren Nutzung in den klassischen URIs nach RFC 2396 bzw. RFC 2732 jedoch untersagt ist, führt zur Einführung des neuen Begriffes des Internationalized Resource Identifiers (IRI). Diese Neuschöpfung stellt im Kern eine URI-Fassung dar innerhalb der Leerzeichen sowie diverse Sonderzeichen zulassen sind. Diese internationalisierten Identifikatoren werden durch einen im Spezifikationsentwurf festgelegten Algorithmus in syntaktisch korrekte URIs umgewandelt.
Beispiel zeigt gültige IRIs und jeweils dahinter in Klammern angegeben die daraus resultierende URI-Darstellung.

Kompatibilität zu älteren Dokumenten:
Elemente, für die weder ein expliziter Namensraum durch Präfix definiert ist, noch ein Namensraum von einem Elternelement übernommen werden kann, sind einem leeren Namensraum zugeordnet; konzeptionell entspricht dies einem NULL-Präfix.
Somit befinden sich alle Elemente, die keinem Namensraum angehören, automatisch in einem gemeinsamen Namensraum, der an keine URI gebunden ist.

Zusammenfassend gelten somit folgende Prinzipien:

  • Jede beliebige URI kann an eigendefinierte Präfixe gebunden werden.
    Insbesondere kann dieselbe URI an verschiedene Präfixe gebunden werden, und dasselbe Präfix in verschiedenen Kontexten für verschiedene URIs stehen.
  • Jedes Element übernimmt den überschriebenen Vorgabenamensraum seines Elternelements, sofern es keinen eigenen definiert.
  • Elemente oder Attribute ohne Namensraumzuordnung (die auch keine von ihrem hierarchisch höherstehenden Element übernehmen) befinden sich im Standardnamensraum.
  • Attribute ohne Namensraumprefix befinden sich im leeren Namensraum.
XML-Namespace Recommendation Namespace Recommendation in deutscher Übersetzung Namespace Tutorial @ Zvon.org Tim Bray: Namespaces by Example Hintergrundartikel: Namespaces in XML Adopted by W3C (Tutorial) Simon St. Laurent: Namespaces in XML Roland Bourret: XML Namespaces FAQ Dokument-Typ-Definitionen

Die Dokument-Typ-Definition (DTD) stellt eine an die EBNF angelehnte reguläre Sprache zur Formulierung von XML-Grammatiken zur Verfügung.
Ursprünglich wurde diese textuelle Notation zur Spezifikation von XML-Strukturen mit SGML eingeführt. Zur Verwendung in XML wurde der Sprachumfang lediglich reduziert, und um einige -- im neuen Anwendungskontext nicht benötigte -- Konstrukte bereinigt.
Inzwischen haben die sehr stark Dokumenten-orientierten DTDs gegenüber den XML-Schemasprachen an Bedeutung verloren. Mittelfristig ist, wegen der deutlich gesteigerten Ausdrucksmächtigkeit, mit dem vollständigen Übergang zu Schemasprachen zu rechnen.
Nachfolgend sollen jedoch die Grundzüge des DTD-Mechanismus vorgestellt werden, um seiner historischen Bedeutung gerecht zu werden. Ebenso soll hierdurch ein Grundverständnis für die existierenden Sprachdefinitionen geweckt werden.

Dokumenttypdeklaration:
Prinzipiell stellt die DTD eine eigenständige, vom XML-Dokument losgelöste, Informationseinheit dar. Ihre Rolle entspricht der der Klasse in der objektorientierten Programmierung, welche schablonenartig die Struktur und die inhaltlichen Charakteristika beliebig vieler konkreter Ausprägungen festlegt. In dieser Analogie agiert das XML-Dokument wie ein Objekt einer spezifischen Klasse.
Daher ergibt sie die folgende Definition als Erweiterung der Wohlgeformtheit fast intuitiv:

Ein XML-Dokument heißt gültig (valid), wenn es über eine Dokument-Typ-Definition verfügt, und konform zu dieser aufgebaut ist.

Implizit folgt hieraus, daß die Wohlgeformtheit eine schwächere Stufe der Gültigkeit, und damit Voraussetzung hierfür, darstellt.
Entsprechend der Unterscheidung in well-formed und valid ergeben sich zwei Klassen von XML-Prozessoren: nicht-validierende und validierende. Beide Typen prüfen die Wohlgeformtheit des eingehenden Textstromes. Zusätzlich testet ein validierender Prozessor die Konformität des XML-Dokuments zu seiner DTD.

Die am Markt verfügbaren XML-Editierwerkzeuge beinhalten zumeist einen validierenden Parser, der die Konformitätsprüfung zu einer gegebenen DTD erlaubt. Ferner bieten viele Hersteller, oder Open-Source-Initiativen, eigenständige Parser-Module zur Validierung von XML-Dokumenten an.

Üblicherweise liegt die DTD in Form einer separaten (Text-)Datei vor, welche durch das XML-Dokument referenziert wird. Zu diesem Zwecke kann im Prolog des XML-Dokuments durch das Schlüsselwort DOCTYPE die physische Lokation der DTD angegeben werden.

Die Syntax einer DOCTYPE-Deklaration lautet :

            
               

                  

                     [28]
                     doctypedecl
                     ::=
                     '<!DOCTYPE' S Name (S
                        ExternalID)?
                  

                  

                     
                     
                     
                     
                        S? ('[' (markupdecl | DeclSep)* ']' S?)? '>'
                  

                  

                     [28a]
                     DeclSep
                     ::=
                     PEReference | S
                  

                  

                     
                        [29]
                     
                     markupdecl
                     ::=
                     elementdecl | AttlistDecl | EntityDecl |    NotationDecl
                  

                  

                     
                     
                     
                     | PI | Comment

Die von SGML übernommene Syntax erinnert äußerlich leicht an die im XML-Dokument verwendete, weist jedoch mehr Ähnlichkeit zum Aussehen der Kommentare in XML auf.
So wird auch die DOCTYPE-Deklaration durch eine öffnende Winkelklammer und ein Ausrufezeichen eingeleitet. Daran schließt sich -- im Falle einer externen DTD -- die SYSTEM- oder PUBLIC-Deklaration an. XML-Dokument-interne Grammatikdefinitionen werden in eckigen Klammern innerhalb der DOCTYPE-Deklaration eingefügt.

Anwendungsbeispiele finden sich im Abschnitt zum Document Type Definition Information Item des Information Sets.

Alternativ zur externen Ablage der DTD kann diese auch ganz oder teilweise in das XML-Dokument eingebettet werden. Dieser Anteil der DTD innerhalb des XML-Dokuments wird als internal subset bezeichnet. Konsequenterweise wird der extern des Dokuments abgelegte DTD-Anteil daher mit dem Begriff external subset belegt.
Beispiele zur Definition interner Subsets finden sich in den Betrachtungen der XML-Information Set Items zu Notationen und Entitäten.
Anmerkung: Existieren in einem internen und externen Subset Festlegungen zum selben (identisch benannten) Informationselement, so überschreibt die des internal Subsets die extern getroffenen Definitionen.

Wie Produktion 29 bereits andeutet, erlaubt der DTD-Mechanismus die Strukturdefinition verschiedener Elemente aus dem XML-Information Set. Die wesentlichen hierbei sind: Elemente und Attribute. Ferner können durch die DTD Entitäten, Notation und Processing Instructions definiert werden.

JAXP: SUNs Standard-Parsing-API für Java XML Instance -- Ein validierender Dokumenteditor XML Authority -- Ein DTD-Editor XML Spy -- Dokument- und DTD-Editor

Definition von Elementen :
Der offensichtlichste Anteil der Struktur eines XML-Dokuments wird durch seine Elemente gebildet. Ein einzelnes Element stellt auch (siehe Definition im Information Set) den minimalsten Umfang eines gültigen XML-Dokuments dar.

Die Syntax zur Definition eines Elements lautet :

               

                  

                     [45]
                     elementdecl
                     ::=
                     '<!ELEMENT' S Name S contentspec S? '>'
                  

                  

                     [46]
                     contentspec
                     ::=
                     'EMPTY' | 'ANY' | Mixed | children
                  

                  

                     
                        [51]
                     
                     Mixed
                     ::=
                     '(' S? '#PCDATA' (S? '|' S? Name)* S?       ')*'
                  

                  

                     
                     
                     
                     | '(' S? '#PCDATA' S? ')'

Jedes Element wird durch die SGML-Syntax der öffnenden Winkelklammer, gefolgt von einem Ausrufezeichen, eingeleitet. Daran schließt sich der Elementname an.
In runden Klammern wird dann das Inhaltsmodell, d.h. die erlaubten Kindelemente, spezifiziert. Sind keine Kindelemente erlaubt, d.h. es handelt sich um ein leeres Element, so ist stattdessen das Schlüsselwort EMPTY anzugeben.
Eine Besonderheit bildet das durch ANY ausgedrückte Inhaltsmodell. Es erlaubt das beliebige Auftreten von Elementen aus der DTD. Ebenso ist textueller Inhalt (#PCDATA) zugelassen.

Zulässige Kindelemente sind neben allen namentlich definierten Elementen der DTD auch Freitexte (#PCDATA für parsed character data, die keine Auszeichnungssymbole enthalten dürfen). Sollen im Elementinhalt Zeichen verwendet werden, die auch als Metasprachensymbole dienen -- wie < oder & --, so müssen diese durch die vordefinierten Textersetzungsmuster ausgedrückt werden.
Über freie Texte und explizite Kindelemente hinaus bietet der DTD-Mechanismus keinerlei Unterstützung zur näheren Definition der Inhalte eines Elements an. Diese, gerade bei Daten-orientierten XML-Dokumenten schmerzhafte, Einschränkung hat mit zur Definition der XML-Schemasprachen geführt, die sich u.a. die Überwindung dieser Einschränkung zum Ziel setzen.
Die Kindelemente werden durch namentliche Aufzählung in der Reihenfolge ihres im Dokument erwarteten Auftretens benannt. Zur Gruppierung können Elemente durch Klammerung zusammengefaßt werden.
Zur Steuerung der Auftrittshäufigkeit von Elementen und Elementgruppen existieren drei Operatoren.

  • Das Fragezeichen ? deklariert ein Element oder eine Elementgruppe als optional.
  • Der positive Abschluß + erlaubt die Wiederholung desselben Elements; mindestens ein Element muß jedoch im XML-Dokument auftreten.
  • Der Kleene-Stern * erlaubt die beliebige Wiederholung desselben Elements, wobei auch das erste auftreten optional ist.

Als Kombination aus explizit benannten Elementen und beliebigen Markup-freien Texten ergibt sich das gemischte Inhaltsmodell.
Aus historischen Gründen folgt dieses Inhaltsmodell immer derselben Struktur (siehe Produktion 51): Auf das Schlüsselwort #PCDATA folgen die zugelassenen Elemente in exklusiver ODER-Beziehung.
Hinter der zunächst etwas kryptisch anmutenden Formulierung verbirgt sich ein kleiner Kunstgriff, um diese zunächst widersprüchlich anmutende Dualität zwischen markupfreiem (#PCDATA) und explizit ausgezeichnetem Inhalt aufzuheben. Das für diesen Anwendungsfall in der XML-Spezifikation vorgegebene mixed content Model erlaubt eine Mischung aus frei formulierter Information und Markupinhalten. Hierzu werden #PCDATA und das gewünschte Element zunächst exklusiv zueinander deklariert (symbolisiert durch den trennenden senkrechten Strich |); im Anschluß wird - durch den Stern -- die beliebig häufig hintereinandergereihte Wiederholung dieser Auswahlentscheidung vereinbart.

Kann ein Element sowohl über Zeichenketten-artigen als auch Element-wertigen Inhalt verfügen, so wird sein Inhaltsmodell als gemisches Inhaltsmodell (mixed content model) bezeichnet.
Innerhalb eines solchen Elements dürfen Unicodezeichen und die zugelassenen Elemente in wahlfreier Kombination auftreten.

Nachfolgend wird eine einfache Projektverwaltung, zur Organisation von Mitarbeitern und ihrer Zuordnung zu Projekten, als durchgängiges Beispiel verwendet.

Das Beispiel zeigt einige verschiedene Elementdefinitionen.
So kann ein Element des Typs ProjektVerwaltung mehrere, jedoch mindestens ein Personen-Element sowie auch mehrere Projekt-Elemente enthalten.
Innerhalb von Personen-Elementen können mehrere, wiederum jedoch mindestens ein Vornamen und genau ein Nachname auftreten. Das Auftreten des mit Qualifikationsprofil benannten Kindelements ist optional.
Über ein leeres Inhaltsmodell (Schlüsselwort EMPTY) verfügt das Element Projekt. Ihm dürfen keine Kindelemente im XML-Dokument folgen.
Die drei Elemente Ueberschrift, Vorname und Nachname erlauben jeweils das Auftreten markupfreien Textes in ihrem Elementinhalt.
Für Qualifikationsprofil ist das mixed content model verwirklicht. Es erlaubt in XML-Dokument das Auftreten des Elements Qualifikation oder Leistungsstufe an jeder beliebigen Stelle innerhalb eines (markupfreien) Freitextes.

Das Beispiel zeigt ein gültiges XML-Dokument zu den bisherigen Elementdefinitionen.
Es zeigt die Nutzung des mehrfachen Auftretens des Elements Vorname innerhalb der Person, sowie die Anwendung des mixed content models -- einschließlich Einsatz des Textersetzungsmusters des Und-Symbols -- für das Qualifikationsprofil.

Definition von Attributen :
Die Syntax der Attributdefinition ist wie folgt festgelegt: 

               

                  

                     [52]
                     AttlistDecl
                     ::=
                     '<!ATTLIST' S Name AttDef* S? '>'
                  

                  

                     [53]
                     AttDef
                     ::=
                     S Name S AttType S DefaultDecl
                  

                  

                     
                        [54]
                     
                     AttType
                     ::=
                     StringType | TokenizedType |       EnumeratedType
                  

                  

                     [55]
                     StringType
                     ::=
                     'CDATA'
                  

                  

                     [56]
                     TokenizedType
                     ::=
                     'ID' | 'IDREF' | 'IDREFS' | 'ENTITY' | 'ENTITIES'       |
                  

                  

                     
                     
                     
                     'NMTOKEN' | 'NMTOKENS'
                  

                  

                     [57]
                     EnumeratedType
                     ::=
                     
                        NotationType | Enumeration
                  

                  

                     [59]
                     Enumeration
                     ::=
                     '(' S? Nmtoken (S? '|' S? Nmtoken)* S?       ')'
                  

                  

                     [60]
                     DefaultDecl
                     ::=
                     '#REQUIRED' | '#IMPLIED'
                  

                  

                     
                     
                     
                     | (('#FIXED' S)? AttValue)

Auch die Syntax der Attributdefinition in der DTD ist SGML entlehnt; daher auch hier die öffnende Winkelklammer und das Ausrufezeichen als einleitendes Symbol. Darauf folgt der Name des Elements, an die die Attributliste gebunden wird. Leicht wird ersichtlich, daß Attribute nicht wie Elemente vollkommen frei definiert werden können, sondern immer im Kontext des nutzenden Elements stehen. In der Folge ist es daher unmöglich, dieselbe Attributdefinition mehreren Elementen zuzuordnen.
An den Namen des Attribut-beinhaltenden Elements schließen sich die eigentlichen Deklarationen an. Im einfachsten Fall bestehen sie lediglich aus dem eindeutigen Attributnamen, einem Datentyp (gemäß der Produktionen 55 und 56) sowie der Angabe, ob es sich um ein optionales (#IMPLIED) oder zwingend anzugebendes (#REQUIRED) Attribut handelt.
Das Angebot der zur Verfügung stehenden Datentypen spiegelt die präsentationsorientierte Vergangenheit der Vorgängersprache SGML wieder. So fehlen Programmiersprachen-orientierte Primitivtypen vollständig. Das mit CDATA -- für character data -- benannte Äquivalent zum Elementinhaltstyp #PCDATA erlaubt lediglich die Beschränkung der Attributwerte auf Zeichenketten-artige Inhalte.
In Erweiterung der IMPLIED-Angabe können Attribute als mit Vorgabewerten belegt und zusätzlich als konstant (#FIXED) deklariert werden. Ihre vorgegebenen Werte werden, auch bei fehlender Angabe im XML-Dokument, durch einen validierenden XML-Parser an die verarbeitende Applikation weitergegeben. Darüberhinaus prüft der Parser für Konstanten, ob der angegebene Attributwert mit der Vorgabe übereinstimmt.
Eine besondere Bedeutung kommt den Typen ID, IDREF und IDREFS zu. Durch sie ist ein rudimentärer Refenzierungsmechanismus, für den die Gültigkeit der Referenzen durch einen validierenden XML-Prozessor geprüft werden kann, verwirklicht. Alle Attributwerte des Typs ID bilden einen Dokument-weiten Namensraum (der jedoch außer Verwendung desselben Begriffs nicht mit den XML-Namespaces in Verbindung steht!). Auf diese Schlüssel kann durch Attribute des Typs IDREF und IDREFS verwiesen werden. IDREF realisiert hierbei eindeutige Verweise, während IDREFS die Angabe einer Liste von Verweiszielen erlaubt. Im einheitlichen Namensraum aller definierten ID-Attribute liegt eine der Hauptschwächen des angebotenen Referenzierungsmechanismus. So ist eine typisierende Einschränkung der erlaubten Referenzziele nicht vorgesehen. Da IDREF(S)-Attribute alle Werte annehmen können, die dokumentweit in ID-Attributen auftreten, kann potentiell auf jede definierte ID verwiesen werden, unabhängig davon ob dieser Verweis semantisch sinnvoll ist. Darüberhinaus können -- insbesondere in großen Dokumenten -- durch die fehlende Partitionierung des ID-Namensraumes Konflikte (und damit invalide Dokumente) durch mehrfachauftretende IDs auftreten. Auch die Teilung von Dokumenten in ID-konfliktfreie Einheiten stellt hierbei keine Lösung dar, da der Referenzierungsmechanismus nicht dokumentübergreifend angelegt ist und daher nicht auf Elemente anderer XML-Quellen zugreifen kann.
Als Lösung dieser angerissenen Problemstellungen bieten sich neben den (deutlich mächtigeren) Referenzierungsmechanismen der XML-Schemasprachen auch dokumentübergreifende Verweise -- wie u.a. in der im Kapitel 2.1 diskutierten W3C-Sprache XLink verwirklicht -- an.
Eine einfache Variante anwenderdefinierter Datentypen werden durch Aufzählungstypen angeboten. Sie werden durch Benennung der Alternativen gebildet. Syntaktisch werden diese, durch Oder-Verknüpfungen voneinander abgetrennt, in runden Klammern dem Attributnamen nachgestellt.

Das nachfolgende DTD-Beispiel erweitert die betrachteten Elementdeklarationen um Attributdefinitionen.

Das Beispiel zeigt verschiedene Attributdeklarationen. Zunächst date als ein simples optionales Zeichenkettenattribut vom Typ CDATA.
budget und version stellen die beiden möglichen Erweiterungen, einerseits durch Angabe eines Vorgabewertes (in Anführungszeichen dem Datentyp nachgestellt), andererseits durch zusätzliche Erklärung des Vorgabewertes als konstant (#FIXED-Angabe), dar.
Die Möglichkeit eines anwenderdefinierten Aufzählungstyps ist in Gehaltsgruppe genutzt. Die Alternative 1a ist darüberhinaus als Vorgabewert definiert.
Zwischen den einzelnen Projekten und verwalteten Personen können über die Attribute PersID bzw. ID und mitarbeitInProjekt bzw. Projektleiter und Mitarbeiter Referenzierungsbeziehungen aufgebaut werden. Auch hier zeigen sich zwei Einschränkungen der ID/IDREF-Semantik deutlich: So können für Personen und Projekte nicht Identifikationsschlüssel aus demselben Namensraum vergeben werden, da diese bei Doppelbelegung kollidieren. Bei automatisch generierten Attributwerten ist daher applikationsseitig sicherzustellen, daß jeder Wert nur höchstens einmal im Dokument auftritt. Da eine spätere Vereinigung von Dokumenten nicht auszuschließen ist, verschärft sich diese Forderung zu über Zeit und Raum eindeutigen Attributbelegungen.
Zusätzlich wird deutlich, daß innerhalb des Projekt-Elements nicht sicherzustellen ist, daß die Attribute Projektleiter und Mitarbeiter ausschließlich auf Attribute innerhalb des Personen-Elements verweisen. So wäre die Zuordnung einer innerhalb von Projekt vergebenen ID zum Attribut Projektleiter desselben Elements korrekt und würde durch einen validierenden Parser akzeptiert.

Definition von Entitäten und Notationen :
Die Document-Type-Definition bietet die Möglichkeit, eigene Textersetzungsmuster (sog. Entitäten) durch den Anwender zu definieren. Dieses Sprachmerkmal hat jedoch -- wegen verschiedenster Probleme -- keinen Eingang in den XML-Schemamechanismus gefunden. Daher sei es hier nur der Vollständigkeit halber einführend erwähnt.
Hinzuweisen ist jedoch bereits jetzt auf die daher abzusehende Problematik beim Übergang von existierenden DTDs zu gleichmächtigen Schemadefinitionen, da ein äquivalentes Sprachmittel dort nicht mehr zur Verfügung stehen wird. Daher sollte bei neu zu erstellenden XML-Grammatiken ganz auf die Definition eigener Entitäten verzichtet werden.

Die XML-Spezifikation definiert selbst fünf Entitäten: die bekannten Textersetzungsmuster der Metasprachensymbole. Daher ist die Referenzierungssyntax (einleitendes &-Symbol gefolgt vom Namen der Entität und abschließendem Semikolon) bereits geläufig.
Zur Definition einer Entität stehen die im Abschnitt Unexpanded Entity Reference Information Item vorgestellten Strukturen zur Verfügung.
Dort finden sich auch Beispiele eigener Definitionen.

Die in enger Verbindung mit den Entitäten stehenden Notationen zur Realisierung von Ersetzungsmustern, die keine XML-codierten Inhalte (z.B. Binärdaten) beinhalten, sind beispielhaft sowie in Syntax und Semantik im Abschnitt unparsed Entities vorgestellt.

XML Schemasprachen

Neben den Document Type Definitions ist in jüngerer Zeit ein alternativer Ansatz in den Blickpunkt des Interesses gerückt: die XML-Schemasprachen.
Sie setzen die Emanzipation der Metasprache XML von ihrer Vorgängersprache SGML fort. Bereits in engem zeitlichem Bezug zur Veröffentlichung der XML-Recommendation wurde mit XML Data ein erster Ansatz vorgestellt. In der Zwischenzeit fanden verschiedene konkurrierende Vorschläge ein breites Interesse. Übereinstimmende Zielsetzung aller verschiedenen vorgeschlagenen Schemasprachen ist die Schaffung eines Sprachdefinitionsmechanismus, der die Dokumenten-orientierten Strukturen und Inhaltsmodelle der DTD überwindet.
An die Spitze der Bemühungen setzte sich eine Arbeitsgruppe des W3C zur Definition einer XML-Schemasprache, unter Berücksichtigung der bekanntesten und verbreitetsten Vorschläge. Durch sie wurde im Mai 2001 der XML Schema-Standard des W3C veröffentlicht.

Der Begriff Schema ist der im Datenbankumfeld gebräuchlichen Terminologie entlehnt. Dort bezeichnet er Informations- oder Datenmodelle als Konstruktionsvorlage oder Dokumentation eines Datenbankdesigns. Hierzu muß ein Schema nicht unbedingt in einer graphischen Datenmodellierungssprache vorliegen, sondern kann beispielsweise auch die Tabellenstruktur einer relationalen Datenbank bezeichnen.

Zur Notwendigkeit einer Schemasprache:
Zum Zeitpunkt der Konzeption der Metasprache SGML war das Anwendungsfeld klar umrissen und im wesentlichen auf die Digitalisierung vormals papiergestützter Dokumentation festgelegt. Daraus erklärt sich auch die Mächtigkeit der Document Type Definition, der angebotenen Grammatiksprache zur Darstellung der Dokumentstrukturen.
Insbesondere war weder die Daten-orientierte Verwendung von SGML, noch die rund 30 Jahre später einsetzende Weiterentwicklung (eigentlich: Reduktion) zur eXtensible Markup Language abzusehen.
Die inzwischen eingesetzte breite Anwendung von XML-Sprachen zur Darstellung beliebiger Inhalte läßt jedoch die Beschränkungen und Unzulänglichkeiten des DTD-Mechanismus für diesen Anwendungen offenkundig werden.

Nachfolgend sind einige der durch Nutzung des DTD-Mechanismus zur Beschreibung Daten-intensiver Strukturen induzierten Einschränkungen zusammengestellt:

  • Unzureichende Datentypunterstützung.
    DTDs erlauben für Elemente nur die vier im vorigen Kapitel diskutierten Inhaltsmodelle: child elements, PCDATA, mixed content sowie das leere Inhaltsmodell EMPTY.
    Für die Attributdefinition (siehe Bemerkungen im vorhergehenden Kapitel) stehen die in Produktion 54 angegebenen Typen zur Verfügung.
    Genaugenommen werden jedoch hier nur Zeichenketten-artige Datentypen (explizit für CDATA, implizit für ID , IDREF, IDREFS , ENTITY, ENTITIES bzw. NMTOKEN und NMTOKENS durch die Beschränkung der zulässigen Inhalte auf Satzformen der Produktion 5 bzw. Produktion 7 der XML-Recommendation) angeboten.
    Die manchmal anzutreffende (Nach-)Modellierung benötigter Datentypen durch anwenderdefinierte Aufzählungstypen ist zeitaufwendig und fehlerträchtig.
  • Unzureichende Strukturierungsunterstützung.
    Zwar erlauben die vorgestellten Operatoren zur Steuerung der Auftrittshäufigkeit einzelner Kindelemente die Codierung beliebiger Kardinalitäten. Allerdings sind die hierfür anzuwendenden Prinzipien teilweise umständlich in der Schreibung, und daher fehlerträchtig. Die Lesbarkeit der entstehenden DTD wird entscheidend gesenkt.
  • Keine Unterstützung von Wiederverwendbarkeit.
    Während Elementstrukturen (zumindest) innerhalb der definierenden DTD beliebig wiederverwendet werden können, sind Attribute immer an das umgebende Element gebunden (vgl. ATTLIST-Konstrukt).
    Eine Nutzung in anderen Dokument-Typ-Definitionen als der definierenden ist nicht vorgesehen. Zwar läßt sich dies durch die Definition von Entitäten annähernd nachbilden. Jedoch ist dies bereits zum Erstellungszeitpunkt der DTD geeignet zu berücksichtigen.
    Modularisierung im Sinne einer Wiederverwendung der durch die Elemente definierten Typen innerhalb der DTD, beispielsweise zur Definition weiterer Typen, wird lediglich durch Parameter Entitäten unterstützt. Sie verhalten sich für die DTDs wie die Entitäten in XML-Dokumenten.
  • Starres Typsystem.
    Das angebotenen Typsystem kann durch den Anwender nicht erweitert werden.
  • Keine Unterstützung von Namensräumen.
    Namensräume können in der DTD nicht angegeben werden.
    Anmerkung: Die hierfür oft angeführten Hilfskonstrukte spiegeln weder die volle Mächtigkeit, noch die korrekte Semantik der Namensräume wieder.
  • Nur rudimentärer Referenzierungsmechanismus.
    Die offerierten ID-IDREF(S)-Verknüpfungen sind ausschließlich Dokument-lokal möglich und gestatten keine Differenzierung hinsichtlich der Semantik des eindeutig identifizierten oder referenzierten Elements.
  • DTD-Syntax ist nicht XML.
    Die von SGML übernommene Syntax der DTD bildet eine eigene Sprache, die von Werkzeugen gesondert zu implementieren ist.

Technische Ansätze:
Prinzipiell lassen sich die in der Vergangenheit vorgeschlagenen Ansätze zur Definition einer Schemasprache in vier Kategorien unterscheiden:

  1. Orientierung am bestehenden DTD-Mechanismus.
    Erweiterungen des bestehenden Mechanismus um zusätzliche Sprachelemente.
  2. Orientierung an der programmiersprachlichen Interpretation.
    Versuch XML und ein Ausführungsmodell möglichst eng zu koppeln.
  3. Orientierung an Wissensdarstellungen
    Interpretation des Schemas einer XML-Sprache als Wissen über die Sprache.
  4. XML-Sprachen zur Inhaltsbeschreibung.
    Da XML i.A. zur Beschreibung beliebigster Informationen herangezogen werden kann, ist die Verwendung auch für die Beschreibung von XML-Strukturen denkbar.

Die naheliegendste Option dürfte die Erweiterung des bestehenden DTD-Sprachumfanges bilden. Durch geeignete Modifikationen und Ergänzungen ließen sich alle, mit Ausnahme der letzten, identifizierten Unzulänglichkeiten beheben.
Konzeptionell lassen sich zwei Erweiterungsvarianten aufzeigen. Zunächst die Möglichkeit, die XML-DTDs um Elemente der ursprünglichen SGML-DTD zu erweitern. In der Konsequenz nähert sich XML, positiv formuliert, wieder der Ausdrucksmächtigkeit der Ursprache SGML an. Negativ formuliert, kann jedoch XML auf diesem Wege niemals Inhaltsstrukturen ausdrücken, die nicht durch SGML ausdrückbar sind, da die Mächtigkeit des SGML-DTD-Mechanismus eine natürliche Obergrenze der Erweiterbarkeit darstellt. Zusätzlich ist anzumerken, daß ein solcher Ansatz der ursprünglichen Intention der XML-Entwicklung -- ein leichter einsetzbares SGML zu schaffen -- entgegenläuft.
Eine der bekannten Ideen zur Erweiterung des DTD-Mechanismus stellt Datatypes for DTDs (DT4DTD) dar.
Alternativ zur Erweiterung hin zur SGML-Mächtigkeit ließe sich der bestehende XML-DTD-Mechanismus um neue zusätzliche Konstrukte anreichern, die nicht Bestandteil der SGML-DTD-Syntax sind. Dieser Ansatz böte den Vorteil, den Vorgängerstandard nicht berücksichtigen zu müssen und beliebige Erweiterungen in Syntax und Semantik einbringen zu können. Allerdings würde damit eine zentrale Forderung der XML-Entwicklung, die sich bereits im Abstract der XML-Recommendation findet, nicht berücksichtigt: die Untermengenbeziehung zu SGML. Durch eine Erweiterung, welche über die SGML-Mächtigkeit hinausreicht, würden legale ( well formed und sogar valid ) XML-Dokumente entstehen, die keine gültigen SGML-Dokumentinstanzen wären.

Die nachfolgende Graphik veranschaulicht die beiden Erweiterungsoptionen und die Argumente der geführten Diskussion.

Die im zweiten Punkt angedeutete Umsetzung ist durch eine programmiersprachliche Verarbeitung der XML-Dokumente motiviert. Aus Sicht dieser Anwendungsfacette ist ein Schemamechanismus idealerweise so ausgelegt, daß er die transparente Umsetzung in Applikationsdatenstrukturen ermöglicht. Dahinter steht der Wunsch, den impedance mismatch, mithin den zu leistenden Abbildungsaufwand zwischen XML-Konstrukten und Datenstrukturen, möglichst gering zu halten.
Beispielsweise greift der -- durch den Einsatz im e-Commerce-System der Firma CommerceOne bekannt gewordene -- Vorschlag Schema for Object-Oriented XML (SOX) zur Definition der notwendigen Semantik der angebotenen Schemaprimitiven auf die bekannte plattformunabhängige Programmiersprache Java zurück.
Die aktuelle Version der Schemasprache SOX, die zur Definition der XML-Sprache xCBL eingesetzt wird, findet sich unter xCBL.org.

Der dritte technische Ansatz weist auf eine alternative Interpretation der XML-Grammatikstruktur hin. So spiegelt ein Schema auch immer Wissen über Struktur und Inhalt eines betrachteten Problembereichs wieder.
Der bekannteste Vorschlag -- die Document Content Description (DCD) -- nutzt zur Definition der Wissensstrukturen eines XML-Dokuments das Resource Description Framework (RDF) des World Wide Web Consortiums.
Der Ansatz hat sich durch Referenzimplementierungen durchaus als tragfähig und, wegen der RDF-basiertheit, als allgemein verwendbar erwiesen. Jedoch liegt hierin auch die offensichtlichste Limitierung. RDF als Metasprache der Schemasprache legt bereits eine gewisse Strukturierung aller Schemata zugrunde, da jedes gültige DCD-Schema definitionsgemäß ein RDF-Dokument darstellt. Ebenso ist die Semantik der eingesetzten RDF-Elemente bereits durch diese Spezifikation vorgegeben. Beide Punkte zusammengenommen offenbaren eine ausgeprägte Abhängigkeit von den weiteren RDF-Aktivitäten des World Wide Web Consortiums, die bisher nicht auf die Interdependenz von Schemasprache und Wissensbeschreibungsformat ausgerichtet ist.
Positiv fällt an DCD die Verwendung von XML zur Beschreibung von XML-Sprachen auf, womit auch die letzte der erhobenen Anforderungen zu erfüllen wäre.
Die Verknüpfung von RDF mit DCD als Schemasprache birgt allerdings ein potentielles Problem hinsichtlich der Validierbarkeit der entstehenden Strukturen. Durch den Rückgriff von DCD auf RDF entsteht bei der Angabe eines Schemas für RDF ein transitiver Zirkelschluß. In der Konsequenz wird zur Validierung eines XML-Dokuments, welches einer mittels DCD-formulierten Grammatik folgt, neben dem eigentlichen DCD-Schema des Dokuments auch das DCD-Metaschema und dessen Semantik-liefernde RDF-Beschreibung benötigt.

Diese Beschränkung mildert die vierte Familie von XML-Schemasprachen ab. Sie umfaßt die meisten Vorschläge, die alle als eigenständige XML-Sprachen ausgelegt sind; daher definieren sie ein eigenständiges XML-Vokabular zur Darstellung der benötigten XML-Strukturen, sowie die zugehörige Semantik.
In der Folge sind sie für die Meta-Schemaebene selbstbeschreibend. Das bedeutet das Schema eines Schemas kann durch sich selbst validiert werden. Da dieser Validierungsschritt statisch nur einmal erfolgen muß, kann er durch Schemawerkzeuge vorweggenommen werden.
In dieser Kategorie sind die meisten der bisher vorgeschlagenen Schemadialekte einzuordnen.

Die größte Bedeutung haben kontextfreie reguläre Sprachen zur Spezifikation von XML-Sprachstrukturen erlangt.
Eine Sprache dieses Typs entwickelt auch die W3C-Arbeitsgruppe zur Definition eines XML-Schemasprachstandards. Insbesondere berücksichtigt diese Aktivität explizit die Vorgängersprachen XML Data, DCD, SOX sowie Document Definition Markup Language. Die erwähnten konkurrierenden Vorschläge unterscheiden sich semantisch lediglich in Nuancen, bieten dem Anwender jedoch teilweise (optisch) stark unterschiedliche Konstrukte zur Syntaxspezifikation an.

Einen strukturell unterschiedlichen Ansatz verfolgt die durch Rick Jelliffe vorgeschlagene Sprache Schematron . Sie interpretiert ein Schema als Sammlung von Regeln, denen ein gegebenes Dokument genügen muß, um als gültig akzeptiert zu werden. Dies erlaubt die Formulierung mächtiger konktextsensitiver Einschränkungen, die während des Validierungsvorganges geprüft werden.
Die Umsetzung dieser Schemasprache setzt auf den XML-Standards XPath und XSLT auf.

W3Cs XML-Schema:
Jenseits aller existierenden verschiedenen Sprachvorschläge kommt dem W3C-Standard der XML Schema Description Language (XSD) die größte praktische Bedeutung zu.
Tim Berners-Lee verkündete in der Eröffnungsrede der WWW-Konferenz in Hong Kong am 2. Mai 2001 die Verabschiedung als Recommendation. Gleichzeitig deutete er bereits weitere Schema-Aktivitäten des World Wide Web Consortiums an.
XML-Schema bildet zusammen mit XML v1.0 2nd edition und den Namensräumen die Basis aller weiteren W3C-XML-Sprachstandards.

Aus formalen Gründen ist nicht mit dem Ersatz der DTD durch Schema zu rechnen. Jedoch werden mittelfristig neu entwickelte XML-Sprachen keine Grammatiken mehr in der Syntax der DTD entwickeln, sondern direkt Schemata definieren.

XSD bildet eine vollständig in XML-Syntax formulierte kontextfreie reguläre Grammatik zur Formulierung beliebiger XML-Strukturen ab. Hierbei handelt es sich um die bekannten Grundprimitive Element und Attribut , andere -- wie Entitäten oder Notationen -- können hingegen nicht durch Schemata ausgedrückt werden. Somit erfolgt durch XSD implizit eine Weiterentwicklung von XML, dahingehend, daß ursprünglich von SGML übernommene -- jedoch inzwischen als unpraktikabel oder potentiell fehlerträchtig angesehene -- Sprachbestandteile nicht mehr durch den Grammatikmechanismus unterstützt werden.
Gleichzeitig wurde, neben zahlreichen anderen Neuerungen, die Kommentarsyntax für Schemata neu definiert.

Inhaltlich gliedert sich der XSD-Sprachvorschlag in zwei große Teilbereiche: Part 1: Structures zur Definition von Inhaltsmodellen für Elemente, Attributstrukturen und wiederverwendbaren Strukturen und Part 2: Datatypes zur Festlegung diverser inhaltlicher Charakteristika wie Datentypen und konsistenzgarantierende Einschränkungen.
In beiden Teilen werden XML-Namensräume explizit berücksichtigt. Konzeptionell rekonstruiert XSD-Part1 zunächst die bekannte Mächtigkeit der DTD um so die evolutionäre Weiterentwicklung bestehender XML-Sprachen zu ermöglichen.
Der zweite Teil der XSD-Spezifikation definiert ein eigenständiges Typsystem, das neben der naheliegenden Verwendung im ersten Teil der Schemasprache XSD auch in anderen W3C-Arbeitsgruppen Verwendung findet. Inhaltlich baut auch Part2 auf den in der DTD definierten Typen auf und erlaubt zunächst direkt ihre Angabe in Schemata. Darauf aufbauend wird eine Fülle verschiedenster Typen angeboten, die an die verschiedenen verfügbaren Typsysteme aus den Programmiersprachen, Datenbanken und internationalen Standards angelehnt sind.
Alle durch XSD definierten Elemente, d.h. alle Primitive zur Definition eines eigenen Schemas, befinden sich im Namensraum http://www.w3.org/2001/XMLSchema, der üblicherweise an das Präfix xsd gebunden wird. Elemente und Attribute aus XML-Schema, die in Instanzdokumenten verwendet werden könne sind im Namensraum http://www.w3.org/2001/XMLSchema-instance (übliches Präfix xsi) organisiert.
Wegen des Umfanges der offiziellen Schemadokumente wird zusätzlich durch das W3C ein Part 0: Primer herausgegeben. Er stellt die beiden XSD-Teile in der Zusammenschau an Beispielen dar.

Nachfolgend werden die Bestandteile der Schemasprache XSD an einigen Beispielen eingeführt, die Struktur der Darstellung orientiert sich dabei an der bereits für die Vorstellung der DTD genutzten Gliederung. Im Verlauf wird das dort verwendete Beispiel zu einem XSD-konformen Schema weiterentwickelt.

Schemareferenz :
Jedes XML-Schema bildet als XML-Dokument eine eigenständige Speichereinheit, üblicherweise eine Datei. Mithin ist die Einbettung in das Instanzdokument, also die Bildung eines internal subset, nicht möglich.
Die Verbindung zwischen Schema und beschriebenem Dokument wird durch das in der XSD-Spezifikation vordefinierte Attribut schemaLocation bzw. noNamespaceSchemaLocation definiert. Eines dieser Attribute muß zwingend im Wurzelelement des XML-Dokuments angegeben werden.
Legt das Schema keinen Namensraum für die enthaltenen Deklarationen fest, d.h. alle darin deklarierten Elemente befinden sich im Vorgabenamensraum, so findet sich die Schemareferenz in noNamespaceSchemaLocation; andernfalls in schemaLocation.
Das nachfolgende Beispiel zeigt die Deklaration:

Im Beispiel wird zunächst der XML-Schema-Instanzen-Namensraum an das Präfix xsi gebunden. Dies ermöglicht die Einbindung von Elementen und Attributen aus der Schemaspezifikation in das eigene Dokument.
Als erste Nutzung eines solchen Elements aus XSD wird das Attribut schemaLocation im Wurzelelement mit der URI des Schemas als Wert belegt. Die Deklaration des XSI-Namensraumes ist daher zwingend. Die angegebene URI kann zur Ermittlung des Schemas für Validierungszwecke durch einen XML-Prozessor genutzt werden.

Durch die Einführung von XSD als weiterer Grammatiksprache verliert der Begriff der Gültigkeit an Qualität. So sind Dokumente denkbar, die zwar hinsichtlich einer gegebenen DTD als valid eingestuft werden, jedoch ein zugehöriges Schema verletzen.
Daher findet sich in der XSD-Spezifikation der Begriff der schema validness in Erweiterung der bisherigen (DTD-bezogenen) validness.

Ein XML-Dokument heißt gültig hinsichtlich eines Schemas (schema valid), wenn es über ein Schema verfügt, und konform zu diesem aufgebaut ist.

Der hier gegebene Gültigkeitsbegriff stützt sich explizit nicht auf der bisherigen validness ab, da er die Konformität hinsichtlich einer eventuell existierenden DTD außer Acht läßt.

So etabliert XML-Schema einen vom DTD-gebundenen Gültigkeitsbegriff losgelösten Validierungsmechanismus.
Aufgrund der Realisierung der Schemasprache als XML-Sprache ist jedes Schema auch ein XML-Dokument. Daher eröffnet sich die Möglichkeit, das Schema selbst durch ein Schema zu beschreiben. Dieses Schema für Schema -- auch Metaschema genannte -- XML-Dokument erlaubt die Validierung (im Sinne der schema validness) jedes Schemas. Damit erfüllt sich eine der Anforderungen an den Schemamechanismus: die Validierbarkeit der erstellten Schemata selbst, was für DTDs nicht gegeben war. In der praktischen Anwendung zeigt sich dies in der Möglichkeit, erstellte Schemata mit denselben Werkzeugen zu analysieren, verarbeiten und zu prüfen, die auch für Instanzdokumente verwendet werden.
Da das Metaschema selbst wiederum ein XML-Dokument ist, folgt, daß hierfür auch ein Schema angegeben werden kann. Die XML-Standardisierung hat hier -- nicht zuletzt um eine unendliche Reihung zur Validierung notwendiger Schemata zu vermeiden -- den Ansatz gewählt, das Schema für Schema durch sich selbst zu beschreiben.
Um den schrittweisen Übergang zu XSD zu befördern, hat die XSD-Arbeitsgruppe eine DTD für XSD herausgegeben. Mittels dieser können neu erstellte Schemata auch mit klassischen Werkzeugen auf (DTD-)Gültigkeitkeit geprüft werden.
Die Abbildung stellt die getroffenen Aussagen und Validierungsbeziehungen nochmals graphisch zusammen.

Die Schema-Definition:
Wuzelknoten jedes XSD-Dokuments ist das Element Information Item schema. Alle Definitionen eines Schemas sind direkte Kindknoten dieses Elements oder dessen Kindknoten.
Durch die Attribute des schema-Elements werden verschiedene Eigenschaften festgelegt, die für alle im Schema definierten Elemente und Attribute gelten.

Zunächst wird durch eine Reihe von Attributen das Verhalten des Schemas in Bezug auf Namensräume festgelegt. Als Besonderheit eines XML-Schemas fällt hier die ständige Berücksichtung von mindestens zwei Namensräumen ins Auge. Während ein Schema mit Elementen des Schemanamensraumes aufgebaut wird, trifft es zeitgleich Aussagen über einen zweiten Namensraum -- den Namensraum des Vokabulars für das das Schema erstellt wird. Dieser Namensraum wird Zielnamensraum (target namespace) genannt.
Daher findet sich im Attribut targetNamespace die URI des Zielnamensraumes. In diesen Namensraum werden automatisch alle durch das Schema deklarierten Elemente und Attribute übernommen. Als Konsequenz müssen diese in jedem Schema-gültigen XML-Dokument im entsprechenden Namensraum auftreten. Hierbei wird nicht zwischen expliziter Namensraumdeklaration durch ein gebundenes Präfix und impliziter Deklaration durch Überschreiben des Vorgabenamensraumes unterschieden.
Durch Angabe der Attribute elementFormDefault und attributeFormDefault kann der durch targetNamespace implizierte Namensraumzwang für das XML-Instanzdokument gelockert werden. Wird der Wert der beiden Attribute auf unqualified gesetzt, so können die Attribute auch außerhalb des Zielnamensraumes auftreten. Dies entspricht auch dem Vorgabeverhalten.

Definition von Elementen:
Als Obermenge der Ausdrucksmächtigkeit der DTD unterstützt auch XSD die Inhaltsmodelle

  • unstrukturierter Inhalt
  • beliebig (jedes Element kann als Kindelement angegeben werden)
  • leer (keine Kindelemente)
  • explizit angegebene Kindelemente
  • gemischter Inhalt (gleichzeitiges Auftreten von Elementen und unstrukturiertem Text)

Generell wird jedes Element durch das XSD-Element element ausgedrückt.

Für unstrukturierten Inhalt bot die DTD lediglich Zeichenketten-artige Inhalte des Typs #PCDATA .
XML-Schema Part 2 definiert insgesamt 44 Primitivtypen. Darunter finden sich die aus der DTD bekannten Element- und Attributtypen, sowie eine Fülle Neuer.

Im Kern zerfallen die XSD-Typen in drei Typklassen:

  • Atomare und aggregierte Typen
    Atomare Typen bestehen aus unteilbaren Werten. Der Begriff der Unteilbarkeit soll dabei auf die nicht erkennbare Unterstrukturierung (string besteht zwar aus einzelnen Zeichen) bzw. falls erkennbar, dem nicht explizit unterstützten Zugriff auf die Komponenten (date bietet keine Zugriffsmöglichkeit auf die Komponenten Tag, Monat und Jahr), verweisen.
    Die aggregierten Typen teilen sich in Listen-artige und Vereinigungstypen (Union). Listen bestehen dabei aus einer geordneten Menge atomarer Typen.
    Vereinigungstypen erlauben hingegen die Verknüpfung Typ-verschiedener Datentypen zu einem neuen.
  • Primitive und abgeleitete Typen
    Primitive Datentypen existieren unabhängig von anderen Datentypen, während abgeleitete Datentypen von der Definition ihres Elterntyps abhängig sind.
  • Vorgegebene und anwenderdefinierte Typen
    Die vorgegebenen Typen sind diejenigen, die in XML-Schema Part2 beschrieben sind. Alle weiteren Typen eines Schemas sind durch den Anwender definierte abgeleitete Typen.

Durch Erweiterungs- und Aggregationsmechanismen ergibt sich das in der nachfolgenden Abbildung dargestellte Typsystem.

Die Tabelle stellt die angebotenen Typen mit einigen Beispielen dar:

Typname Beispiel Bemerkung string    Hello &#xD;&#xA; World   Jedes beliebige Unicode Symbol gemäß XML-Syntaxproduktion 2 normalizedString &#20Hello&#20;World Jedes beliebige Unicode Symbol außer Zeilenvorschub, Wagenrücklauf und Tabulatoren
normalizedString ist eine einschränkende Spezialisierung des Typs string token Hello World Jeder normalizedString, unter Weglassung führender, abschließender und mehrfacher Leerzeichen (#x20), sowie Zeilenvorschüben (#xA) und Tabulatoren (#x9).
token ist eine einschränkende Spezialisierung des Type normalizedString Name aName, _helloWorld, :notAGoodIdea XML Name gemäß Syntaxproduktion 5.
Name ist eine einschränkende Spezialisierung des Typs token QName xsd:element, element Durch Namensraumpräfix qualifizierter Name gemäß Produktion 6 der XML Namespace Recommendation NCName aName, _anotherName, X Name, der keinen Doppelpunkt enthält (non colonized name), gemäß Produktion 4 der XML Namespace Recommendation decimal -1.23, 12678967.543233, +100000.00, 210 Wertebereich: i*10-n, mit i, n aus integer, n>=0
Ein Prozessor muß mindestens 18 Dezimalstellen unterstützen long -9223372036854775808, ... -1, 0, 1, ... 9223372036854775807 Wertebereich: 263 <= long <= 263-1
long ist eine einschränkende Spezialisierung des Typs integer int -2147483648, ... -1, 0, 1, ... 2147483647 Wertebereich: -231 <= int <= 231-1
int ist eine einschränkende Spezialisierung des Typs long short -32768, ... -1, 0, 1, ... 32767 Wertebereich: -215 <= short <= 215-1
short ist eine einschränkende Spezialisierung des Typs int byte -128, ...-1, 0, 1, ... 127 Wertebereich: -27 <= byte <= 27-1
byte ist eine einschränkende Spezialisierung des Typs short integer ...-1, 0, 1, ... Wertebereich: entspricht der mathematischen Menge der ganzen Zahlen (Z)
integer ist eine einschränkende Spezialisierung des Typs decimal positiveInteger 1, 2, ... Wertebereich: entspricht der mathematischen Menge der natürlichen Zahlen (N)
positiveInteger ist eine einschränkende Spezialisierung des Typs nonNegativeInteger negativeInteger ... -2, -1 Wertebereich: {..., -2, -1}, die unendliche Menge der negativen Zahlen
negativeInteger ist eine einschränkende Spezialisierung des Typs nonPositiveInteger nonNegativeInteger 0, 1, 2, ... Wertebereich: 0 <= nonNegativeInteger
nonNegativeInteger ist eine einschränkende Spezialisierung des Typs integer nonPositiveInteger ... -2, -1, 0 Wertebereich: {..., -2, -1, 0} die unendliche Menge der negativen Zahlen, und die Null
nonPositiveInteger ist eine einschränkende Spezialisierung des Typs integer unsignedLong 0, 1, ... 18446744073709551615 Wertebereich: 0 <= unsignedLong <= 264-1
unsignedLong ist eine einschränkende Spezialisierung des Typs nonNegativeInteger unsignedInt 0, 1, ...4294967295 Wertebereich: 0 <= unsignedInt <= 232-1
unsignedInt ist eine einschränkende Spezialisierung des Typs unsignedLong unsignedShort 0, 1, ... 65535 Wertebereich: 0 <= unsignedShort <= 216-1
unsignedShort ist eine einschränkende Spezialisierung des Typs unsignedInt unsignedByte 0, 1, ... 255 Wertebereich: 0 <= unsignedByte <= 28-1
unsignedByte ist eine einschränkende Spezialisierung des Typs unsignedShort float -1E4, 1267.43233E12, 12.78e-2, 12, INF 32-Bit-Zahl mit einfacher Genauigkeit gemäß IEEE 754-1985.
Wertebereich: m * 2 e , wobei m und e integer-Elemente mit m <= 224, und -149 <= e < 104 sind. double -1E4, 1267.43233E12, 12.78e-2, 12, INF 64-Bit-Zahl mit doppelter Genauigkeit gemäß IEEE 754-1985.
Wertebereich: m * 2 e , wobei m und e integer-Elemente mit m <= 253, und -1075 <= e < 970 sind. boolean true, false, 1, 0 Unterstützung der klassischen zweiwertigen Logik time 13:20:00-05:00, 13:20:00.000 Uhrzeit, die täglich wiederkehrt, ausgedrückt im Format gemäß ISO 8601 date -- Datumsformat: CCYY-MM-DD, gemäß ISO 8601 gYear 1999, 2001, Darstellung von Jahren des gregorianischen Kalenders gemäß ISO 8601 gYearMonth - Darstellung eines Monats eines bestimmten Jahres des gregorianischen Kalenders gemäß ISO 8601 gDay ----05, ----31 Darstellung eines wiederkehrenden Tages eines Monats gemäß ISO 8601 gMonthDay --31-12, --01-01 Darstellung eines wiederkehrenden gregorianischen Datums, gebildet aus Tag Monat und Monat im Format --MM-DD, gemäß ISO 8601 gMonth --03, --12 Monatsformat: --MM-- gemäß ISO 8601 dateTime --T::.000+02:00 Zeitpunkt, ausgedrückt durch Datum und Uhrzeit; beide gemäß ISO 8601 codiert. duration P1Y2M3DT10H30M12.3S
Zeitraum von einem Jahr, zwei Monaten, drei Tagen, zehn Stunden, 30 Minuten und 12,3 Sekunden Nach Größe (Signifikanz) geordnete Koordinate im sechs-dimensionalen Raum aus Jahr, Monat, Tag, Stunde, Minute und Sekunde.
Formatdefinition laut ISO 8601 base64Binary SGVsbG8gd29ybGQhCg== Base64-Darstellung eines beliebigen Binär-interpretierten Inhaltes gemäß hexBinary 0FB7 Hexadezimale Darstellung beliebiger Binär-interpretierter Inhalte anyURI http://www.jeckle.de Jede gemäß bzw. gültige URI language en-GB, en, de-de Sprachcodierung gemäß und XML Recommendation language identification.
Die Identifikationsnamen werden durch ISO 639 sowie ISO 3166 definiert.
language ist eine einschränkende Spezialisierung des Typs token ID test, XYZ XSD-Darstellung des DTD-Typen ID .
Zugelassen sind alle Ausprägungen der Namespaceproduktion 4 (NCName).
ID ist eine einschränkende Spezialisierung des Typs NCName IDREF test, XYZ XSD-Darstellung des DTD-Typen IDREF .
Zugelassen sind alle Ausprägungen der Namespaceproduktion 4 (NCName).
IDREF ist eine einschränkende Spezialisierung des Typs NCName IDREFS test1 test2 test4, test3 test5 XSD-Darstellung des DTD-Typen IDREFS .
Zugelassen sind Listen aus white space separierten Ausprägungen der Namespaceproduktion 4 (NCName).
IDREFS ist eine nichtleere Aufzählung von IDREF-Ausprägungen ENTITY XSD-Darstellung des DTD-Typen ENTITY.
Zugelassen sind alle Satzformen, die der Produktion NCName der XML-Namensräume entsprechen und als ungeparste Entität definiert sind.
ENTITY ist eine einschränkende Spezialisierung des Typs NCName ENTITIES XSD-Darstellung des DTD-Typen ENTITIES.
Zugelassen sind Listen aus white space separierten Ausprägungen des Typs ENTITY.
ENTITIES ist eine nichtleere Aufzählung von ENTITY-Ausprägungen NOTATION XSD-Darstellung des DTD-Typen NOTATION.
Zur Verwendung dieses Typs in einem Schema muß eine Ableitung von NOTATION durch den Anwender definiert werden. NMTOKEN US, Deutschland XSD-Darstellung des DTD-Typen NMTOKEN.
Ausprägungen dieses Typs müssen konform zur Produktion 7 der XML-Spezifikation sein.
NMTOKEN ist eine einschränkende Spezialisierung des Typs token NMTOKENS US UK Aus, Ger XSD-Darstellung des DTD-Typen NMTOKENS.
Zugelassen sind Listen aus white space separierten Ausprägungen des Typs NMTOKEN.
NMTOKENS ist eine nichtleere Aufzählung von NMTOKEN-Ausprägungen anyType 1, 2.3, aGVsb, 06b8f45, test&#20;für&#20;anyType&#0A; <sentence>the quick brown <animal>fox</animal>...</sentence> Allgemeinster Datentyp. Konzeptionell bildet er die Vereinigung aller angebotenen XSD-Typen.

Die einfachste Form zur Definition eines Elements mit unstrukturiertem typisierten Inhalt lautet:

<xsd:element
                    name="elementName"
                    type="typeName"/>

In dieser Darstellung entspricht die Definition -- von der Typisierung abgesehen -- der Mächtigkeit der ELEMENT-Deklaration einer DTD mit PCDATA-artigem Inhalt.
XSD definiert ferner folgende Charakteristika für Elemente, die durch Attribute der Elementdeklaration ausgedrückt werden:

  • abstract: falls auf true gesetzt, darf ein solches Element nicht in einem XML-Dokument auftreten. Es kann ausschließlich zur Strukturierung des Schemaentwurfs eingesetzt werden und als Basis von Spezialisierungen dienen.
    Vorgabewert ist false
  • block: erlaubt die Kontrolle der Verwendung abgeleiteter Typen. Zugelassene Belegungen beliebige Kombinationen aus extension, restriction und substitution oder der Einzelwert #all.
    Ist das Attribut auf restriction gesetzt, so dürfen keine (einschränkend) abgeleiteten Typen Ausprägungen des Originaltyps in Instanzdokumenten ersetzen. Dasselbe gilt für extension oder als Substitutionsgruppen deklarierte Typen (substitution-Belegung).
    Der Wert #all versammelt alle möglichen Varianten und verbietet generell die Ersetzung eines Elements durch andere.
  • default : Vorgabebelegung des Inhalts durch eine beliebige Zeichenkette, die konform zum gewählten Typ ist.
    Dieser Wert wird durch den XML-Prozessor an die Applikation gemeldet, wenn kein Wert im Dokument angegeben wird.
  • final: verhindert die Ableitung von Typen. Die zulässigen Belegungen sind mit denen für block identisch, nur daß durch dieses Attribut die Vererbungsmechanismen bereits auf Schemaebene verboten werden, während block ihre Nutzung im Instanzdokument einschränkt.
  • fixed : erlaubt die konstante Wertbelegung.
  • form: legt fest, ob das Element im Instanzdokument mit Namensraumpräfix erscheint.
    Zulässige Belegungen: qualified (Namensraumpräfix muß angegeben werden) und unqualified.
  • id: erlaubt die eineindeutige Kennzeichnung eines Elements durch eine Schema-weit eindeutige Zeichenkette.
  • minOccurs : Minimalkardinalität, d.h. Mindestzahl zulässiger Vorkommen dieses Elements. Der Attributinhalt ist ein Element aus nonNegativeInteger.
    Das Attribut ist optional, und wird bei fehlender Angabe mit dem Vorgabewert 1 belegt.
  • maxOccurs : Maximalkardinalität, d.h. Höchstzahl zulässiger Vorkommen dieses Elements. Der Attributinhalt ist entweder ein Element aus nonNegativeInteger oder die Zeichenkette unbounded zur Kennzeichnung beliebig vieler Auftreten.
    Das Attribut ist optional, und wird bei fehlender Angabe mit dem Vorgabewert 1 belegt.
  • name: Unqualifizierter Name des Elements, konform zur NCName-Produktion der Namensraum-Spezifikation.
  • nillable: Erlaubt Null-Werte im Instanzdokument, die Semantik ist dabei an die in relationalen Datenbanksystemen verwirklichte angelehnt.
    Die Belegung ist entweder true oder false, was auch als Vorgabe bei Fehlen dieses Attributs angenommen wird.
  • ref: Referenz auf eine andere Elementdeklaration zur Übernahme der dort spezifizierten Definitionen.
  • substitutionGroup: Name einer Gruppe von Elementen, die anstatt des aktuellen Elements im Instanzdokument auftreten dürfen.
  • type : Ein durch Schema Part 2 vordefinierter Typ, oder jeder beliebige anwenderdefinierte.

Nachfolgend sind einige Elementdeklarationen für unstrukturierten Inhalt versammelt

Die Deklaration geburtsdatum definiert ein XML-Element des Typs date zur Darstellung eines Datums. Weitere Festlegungen sind nicht getroffen, daher wird das Element mit minOccurs und maxOccurs 1 belegt, wodurch es als zwingend anzugebend (mandatory) und skalar (d.h. nicht mengenwertig) ausgewiesen wird.
pi legt die gleichnamige mathematische Konstante fest. Als Datentyp wurde double, eine Gleitkommazahl mit doppelter Genauigkeit gewählt. Als konstante Belegung wird durch das fixed Attribut der entsprechende Zahlenwert festgelegt. Daher muß eine Vorgabebelegung durch das Attribut default nicht erfolgen; gemäß Schema-Spezifikation darf sie sogar nicht erfolgen, fixed und default schließen sich gegenseitig aus. Um eine weitere Spezialisierung des Elements durch Vererbung oder Aggregation zu verhindern wird der Wert von block auf #all gesetzt, wodurch die Teilnahme an allen Typbildungsmechanismen unterbunden wird.
Die Definition für vorname nutzt als Datentyp den token, der automatisch mehrfache, führende und abschließende Leerzeichen sowie sonstige Formatierungssymbole entfernt. Ferner kann dieses Element beliebig häufig auftreten -- maxOccurs ist daher auf unbounded gesetzt. Die Fixierung der minimalen Auftrittshäufigkeit auf 1 (minOccurs) entspricht der Vorgabebelegung.
Für das Element artikelNummer ist als Typ NCName ausgewählt, was beliebigen Zeichenketten -- die keinen Doppelpunkt enthalten -- entspricht. Darüberhinaus ist das Attribut form mit dem Wert qualified versehen. Dies führt dazu, daß das Namensraumkürzel für dieses Element zwingend im Instanzdokument anzugeben ist.

Zur Umsetzung des freien Inhaltsmodells, das beliebige Inhalte aus den definierten Elementen und freien Texten zuläßt, wird ebenfalls auf das Typsystem zurückgegriffen.
Wird das type Attribut nicht belegt, so wird gemäß Vorgabe der Typ anyType angenommen. Elemente dieses Typs können beliebige wohlgeformte Inhalte beherbergen.
Die beiden nachfolgenden Angaben sind daher äquivalent.

<element
   name="elementName"
   type="xsd:anyType/>
<element name="elementName"/>

XSD prägt den bereits im Kontext der DTD genutzten Typbegriff strenger. Dies zeigt sich deutlich in der Existenz des XSD-Elements complexType . Es führt die Möglichkeit einer expliziten, d.h. von der Verwendung losgelösten Typbildung, ein. Syntaktisch kann die complexType-Definition sowohl innerhalb einer Elementdefinition, als auch separat erfolgen.
Den einfachsten Anwendungsfall bildet die eingebettete leere complexType-Definition zur Darstellung des leeren Inhaltsmodells.
Die Syntax hierfür lautet (der XSD-Namensraum sei an das Präfix xsd gebunden):

<xsd:element
   name="elementName">
   <xsd:complexType/>
</xsd:element>

Ein XML-Schema-validierender Parser verhält sich in diesem Falle identisch zu einem (DTD-)validierenden Parser für das Inhaltsmodell EMPTY. Daher werden für die obige Festlegung ausschließlich die beiden Darstellungsformen zur Angabe eines leeren Elements (<elementName/> bzw. <elementName></elementName>) akzeptiert.

Die Befüllung des complexType-Elements leitet direkt zum wichtigsten Inhaltsmodell über, dem explizit angegebener Kindelemente.
Während die DTD das sequentielle Auftreten der Kindelemente in der angegebenen Reihenfolge nur implizit zu Grunde legt, stellt XML-Schema diesen Sachverhalt durch ein eigenes Sprachkonstrukt klar dar. Hierfür werden alle Kindelemente in ein weiteres Element sequence eingebettet.
Das Auswahlinhaltsmodell (auch: Selektionsmodell) -- in der DTD durch Oder-Verknüpfung der einzelnen Elemente einer Elementgruppe ausgedrückt (...|...|...) -- wird entsprechend durch das XSD-Element choice ausgedrückt.
Eine besondere Variante des Selektionsmodells stellt die all-Gruppe dar. Sie kürzt das häufig genutzte Inhaltsmodell (...|...|...)* ab. Es erlaubt die Angabe der Kindelemente in beliebiger Reihenfolge.
In Entsprechung zur Klammerdarstellung in der DTD muß zwingend einer der drei Reihenfolgetypen sequence, choice oder all als Element spezifiziert werden.
Analog der Klammer-Schachtelung in der DTD, können auch die verschiedenen Modellgruppen ineinander kombiniert werden.
Am Beispiel der Elementdefinitionen der Projektverwaltung:

Das Schema enthält alle Elementdefinitionen für die Projektverwaltung. Innerhalb jedes element-Elements sind die entsprechenden Kindelemente in sequence-Strukturen eingebettet. Analog dem entsprechenden DTD-Mechanismus müssen sie daher in der Reihenfolge ihres Auftretens im Schema auch im Instanzdokument wiedergegeben werden.
Von besonderem Interesse ist die Definition des Qualifikationsprofils. Es handelt sich dabei um ein mixed content model, ausgedrückt durch das Boole'sche Attribut mixed (in Spezifikation nachschlagen). Die dargestellte Definition läßt an dieser Stelle einen weiteren Vorteil der Schemasprache gegenüber der Dokument-Typ-Definition offensichtlich werden. Während gemischte Inhalte aus Auszeichnungssymbolen und freiem Text durch DTD-validierende Parser nur rudimentär geprüft werden konnten, ermöglicht XSD die vollständige inhaltliche Validierung gemischter Inhalte. Die lediglich partielle Strukturvalidierung der DTD lag in deren syntaktischer Konstruktion zur Darstellung gemischter Inhalte begründet. Diese erlaubt zwar die Spezifikation von innerhalb unstrukturierter Textpassagen (möglicherweise) auftretenden Elementen, nicht jedoch die Überwachung der Auftrittshäufigkeit oder Reihenfolge. So wäre gemäß der Beispiel-DTD auch die Hintereinanderreihung von Qualifikationen ohne zugehörige Leistungsstufe zulässig. Insgesamt kann durch DTD-basierte Validierung das Auftreten von Elementen in gemischten Inhaltsmodellen nicht geprüft werden. Durch den Einsatz von XML-Schema ergibt sich auch für mixed content models die Möglichkeit zur strikten Validierung. Dies bedeutet konkret die Prüfbarkeit der Anzahl und Auftretensreihenfolge der angegebenen Kindelemente (in Spezifikation nachschlagen).
Darüberhinaus enthält das Beispiel neben lokalen Elementdeklarationen, die sich vollständig im Elternelement finden (wie Vorname, Nachname und Qualifikation), auch globale Elementdeklarationen, die zunächst deklariert und in einem zweiten Schritt durch Referenzierung als Kindelemente verwendet werden (wie Person und Projekt innerhalb Projektverwaltung, oder Qualifikationsprofil innerhalb des Elements Person). Hierdurch können vollständige Elemente an verschiedenen Stellen im Schema referenziert und so verwendet werden. Die Definition ist der lokalen ebenbürtig und wird im Instanzdokument identisch behandelt. Zusammenfassend läßt sich festhalten: Mit dem Referenzierungsmechanismus für Elemente kann eine einfache Form der Wiederverwendung umgesetzt werden.
Den Zeichenketten-artigen Elementtypen wurde durchgehend der XSD-Typ string zugewiesen.

Durch die Referenzierungsmöglichkeit existiert eine erste Möglichkeit zur Wiederverwendung bereits im Schema definierter Elemente. Jedoch werden Elemente hierbei zwingend in ihrer vollständigen Definition, d.h. Name, Typ und Inhaltsmodell, eingebunden. Im Grunde genommen ist diese Art der Wiederverwendung bereits mit den Mitteln der DTD möglich. Allerdings, wie im eben betrachteten Beispiel, auch dergestalt, daß nur die vollständige Definition übernommen werden kann.
XML-Schema bietet zusätzlich die Möglichkeit, strukturierte Typen, die ausschließlich durch ihr Inhaltsmodell definiert werden, festzulegen. In der Konsequenz verändert sich der durch die DTD formulierte Typbegriff hin zu einer eher an den Programmiersprachen orientierten Sichtweise, da die Benennung des Typs von der Namensgebung der typisierten Instanz separiert wird.
Syntaktisch erfolgt die Typbildung durch die Benennung des complexType-Elements durch ein Attribut name. Um die mehrfache Verwendung eines solchen Typen zu ermöglichen, muß seine Definition zwingend auf einer Baumstufe erfolgen, die für alle nutzenden Elemente erreichbar ist. Üblicherweise werden daher diese Definitionen auf der ersten Stufe, direkt unterhalb des Wurzelknotens, plaziert.
Zur Unterscheidung dieser benannten komplexen Typen werden die bisher genutzten -- namenlosen Typen -- als anonyme komplexe Typen bezeichnet.
Das nachfolgende Beispiel zeigt die Definition eines benannten komplexen Typen am Beispiel des Elements Person:

Das Schema zeigt die Definition des komplexen Typen PersonType. Dieser Typ wird zur Festlegung des Inhaltsmodells des Elements Person verwendet.

Definition eigener Datentypen durch Vererbung:
Zur Unterstützung von Wiederverwendung und Erhöhung der Strukturierung des Entwurfs definiert XSD ein Vererbungskonstrukt zur Bildung neuer komplexer Typen auf der Basis bereits bestehender.
Zwei verschiedene Ableitungssemantiken werden angeboten:

  • Ableitung durch Einschränkung (derivation by restriction)
    Der erbende Subtyp gibt eine engere Definition des Supertypen
  • Ableitung durch Erweiterung (derivation by extension)
    Der erbende Subtyp erweitert die Definition des Supertypen

Das nachfolgende Beispiel zeigt die Anwendung der einschränkenden Ableitung.
Hierbei erbt der benannte komplexe Typ childType von parentType. Innerhalb des -- aus syntaktischen Gründen notwendigen -- Elements complexContent findet sich die Definition der Vererbung im Element restriction, das base-Attribut verweist auf den benannten Elterntypen.
Der Inhalt des restriction-Elements gleicht der Inhaltsmodelldefinition des komplexen Typen: Auch hier werden Elemente und ihre Auftrittsstruktur (im betrachteten Beispiel sequence) angegeben. Die Elementdefinition des Elements elementA in childType schränkt die gleichnamige Elementdefinition innerhalb des Elterntypen ein. Nachvollziehbar wird diese Einschränkungsbeziehung zwischen short und int bei Betrachtung der Datentyphierarchie und der Typdefinition der verwendeten Primitivtypen. So bildet short per definitionem eine eingeschränkte Untermenge von int an. (Die entsprechende XSD-Definition findet sich im Schema für Schema).
Die beiden Elementdefinitionen usage1 und usage2 zeigen die Verwendung der anwenderdefinierten Typen.

Durch das strukturierte Inhaltsmodell ergeben sich über die reine Typisierung hinausgehende Möglichkeiten zur Einschränkung der Inhalte. Die nachfolgende Tabelle stellt einige Varianten zusammen.

Basistyp Restriktion Bemerkung default Zusätzliche Belegung eines Elements mit einem Vorgabewert fixed Beschränkung eines zunächst frei wählbaren Elements auf konstanten Inhalt type Definition eines Typen für ein zunächst untypisiertes Element.
(Auch hierbei handelt es sich um eine einschränkende Redefinition, da allen Elementen ohne Typdefinition standardmäßig der Typ anyType zugeordnet wird.) minOccurs=n1 , maxOccurs=m1 minOccurs=n2 , maxOccurs=m2 Restriktion der Auftrittshäufigkeit auf eine geringere Anzahl.
Daher gilt: n1 <= n2 und m1 >= m2

Die direkte Umkehrung der einschränkenden Spezialisierung bildet die erweiternde Spezialisierung. Sie greift nicht verändernd auf die Elemente des Supertyps zu, sondern definiert zusätzliche neue.
Untenstehendes XSD-Schema zeigt dies am Beispiel des Supertyps parentElement, der durch das abgeleitete Kindelement childElement erweitert wird. Hierzu definiert childElement ein zusätzliches elementB.

Zusätzlich sieht XML Schema die Möglichkeit vor, komplexe Typen von simplen abzuleiten. Dies mag auf den ersten Blick ungewöhnlich erscheinen, eröffnet es doch scheinbar einen Weg, unstrukturierte Typen in strukturierte zu überführen.
Bei näherer Betrachtung offenbart sich jedoch, daß hier lediglich der Ableitungsbegriff überladen wurde, um einen einfachen Weg zur Verknüpfung der beiden Inhaltsmodelle strukturierter XML-artiger Inhalt -- wie er durch complexTypes repräsentiert wird -- auf der einen, und unstrukturierter Inhalt -- wie er durch die einfachen Datentypen repräsentiert wird -- auf der anderen Seite, zu erhalten.

Durch die im Beispiel dargestellte Syntax wird es ermöglicht unstrukturiert-getypten Elementen Attribute zuzuordnen, obwohl diese eigentlich Bestandteil der Definition komplex-getyper Elemente sind.

So wird im Beispiel dem Element Vorname sowohl der simple Typ string, als auch durch den Ableitungsmechanismus das Attribut rufname -- im Rahmen eines complexType, zugeordnet.
Die Typisierung des Elements erfolgt hierbei nicht durch das type-Attribut innerhalb der Elementdeklaration, sondern innerhalb der simpleContent-Festlegung.

Neben der anwenderdefinierten Bildung komplexer Typen steht es dem XSD-Modellierer auch offen, eigene (primitive) Datentypen festzulegen oder eigene Typen von bestehenden abzuleiten.
Hierfür definiert XML-Schema Part1 das Element simpleType. Für einfache Typen ist jedoch nur die einschränkende Vererbung (restriction) zugelassen. Dies liegt in der praktischen Beherrschbarkeit des Typsystems begründet. Durch die strikte Restriktionssemantik ergibt sich die Möglichkeit kontravarianter Substitution, wie sie bei objektorientierten Typsystemen und Vererbungsstrukturen anzutreffen ist. Dies bedeutet, daß an jeder Stelle, an der eine Ausprägung eines Supertyps erwartet wird, auch -- unter Erhalt der Typrestriktion -- eine Ausprägung eines Subtypen auftreten darf. Beispielhaft: Wird an einer Stelle des Instanzdokumentes durch das Schema das Auftreten einer Ausprägung von integer verlangt, so kann der Anwender auch Ausprägungen der Subtypen int, short oder byte angeben ohne die Gültigkeit des XML-Dokuments zu beeinträchtigen.

Vereinigungstypen werden aus einer nichtleeren Menge von Ausgangstypen gebildet.
Das Beispiel zeigt die Definition eines Typen termin, der den vorgegebenen Primitivtypen date und eine Liste NamenDerWochentage (deren Definition nicht dargestellt ist) vereinigt. Insbesondere zeigt der Ausschnitt die Möglichkeit der Vereinigungsbildung auch über aggregierte Typen.

Das XSD-Beispiel zeigt, als Fragment der XML-Schemaspezifikation, die Definition des vorgegebenen Typs short, einer einschränkenden Spezialisierung des Typs int.
Am Beispiel gut nachvollziehbar sind die beiden Schritte zur Bildung eines eigenen Typen:

  1. Auswahl eines Ausgangstypen (später Elementtyp (bei aggregierten Typen) oder Basistyp (bei abgeleiteten Typen) )
  2. Typdefinition durch Anwendung der entsprechenden Typkonstruktion und evtl. Einschränkung verschiedener Charakteristika

Im Beispiel wird der kleinste und größte gültige Wert (minInclusive bzw. maxInclusive) des neuen Typen short gegenüber dem Basistypen beschränkt.

Die Bildung aggregierter Typen folgt demselben Muster. Jedoch tritt an die Stelle der Ableitung die Spezifikation des Aggregationstyps (im Beispiel Liste) und Angabe des Inhaltstyps (im Beispiel string).

Nachfolgend sind die verschiedenen Beschränkungsmöglichkeiten zusammengefaßt:

  • length
    Längenbeschränkung bei atomaren Typen bzw. Beschränkung der Elementanzahl bei aggregierten Typen.
    Längenbeschränkung eines simplen Typs:
    Beschränkung der Elementanzahl einer Liste:
  • minLength
    Minimale Länge (bei atomaren Typen bzw. minimale Elementanzahl bei aggregierten Typen.
    Beispiel (der aggregierte Typ VornamenRestrictedList muß mindestens einen Eintrag enthalten):
    Beispiel (der spezialisierte atomare Typ Titel muß aus mindestens fünf Zeichen bestehen):
  • maxLength
    Maximale Länge bei atomaren Typen bzw. maximale Elementzahl bei aggregierten Typen.
    Beispiel (der aggregierte Type VornamenRestrictedList muß mindestens einen, jedoch höchstens drei, Einträge enthalten):
    Beispiel (der spezialisierte atomare Typ Titel muß aus mindestens fünf, darf jedoch aus höchstens 80 Zeichen bestehen):
  • pattern
    Erlaubt die Inhaltsdefinition durch Muster (reguläre Ausdrücke).
    XML-Strukturen sind nicht durch reguläre Ausdrücke darstellbar, hierfür können lediglich die vorgestellten Strukturierungsprimitive eingesetzt werden; daher sind Muster auf atomare Typen beschränkt.
    Die XML-Schemaspezifikation definiert einzelne Symbole und Symbolsequenzen, sowie einige abkürzende Schreibweisen zum Aufbau beliebiger Ausdrücke. Alle anderen Zeichen können direkt in die Musterspezifikation übernommen werden.
    Die aus der Verarbeitung regulärer Ausdrücke mit anderen Programmiersprachen oder Werkzeugen bekannten Quantifier stehen in der bekannten Semantik zur Verfügung.
    Sei S eine Zeichenkette aus einer beliebigen Anzahl von Zeichen (d.h. sie kann auch leer sein!), dann gilt: Quantifiziertes Mustersymbol Bedeutung S Alle Zeichenketten, die S genau entsprechen. S? Alle Zeichenketten, die S genau entsprechen oder die leere Zeichenkette. S* Alle Reihungen von S; insbesondere entspricht S* auch der leere Zeichenkette. S+ Alle Reihungen von S, die S mindestens einmal enthalten.
    Entspricht der Formulierung: S S*     S{n,m} Alle Zeichenketten, die aus mindestens n, jedoch höchstens m Auftreten von S bestehen.
    Durch n=0 lassen sich somit optionale, nach oben begrenzte, Auftrittsanzahlen realisieren,
    sowie durch n=m=0 die leere Zeichenkette ausdrücken         S{n} Alle Zeichenketten, die aus genau n Auftreten von S bestehen.
    Entspricht der Formulierung: S{n,n}     S{n,} Alle Zeichenketten, die aus mindestens n Auftreten von S bestehen.
    Entspricht der Formulierung: S{n} S*     Zur Darstellung nicht-druckbarer Zeichen oder von Metasymbolen werden folgende Fluchtsymbole angeboten: Mustersymbol (escape character) ausgedrücktes Zeichen \n Zeilenumbruch (#xA) \r Zeilenvorschub (#xD) \t Tabulator (#x9) \\ \ \| | \. . \- - \^ ^ \? ? \* * \+ + \{ { \} } \( ( \) ) \[ [ \] ] Ferner sind noch eine Reihe häufig benötigter Zeichenfamilien definiert und in den Kategorien Buchstaben (Letter), Marken (Marks), Zahlen (Numbers), Interpunktion (Punctuation), Trennsymbole (Separators) sowie sonstige (Others) zusammengefaßt. Die Zeichenfamilien innerhalb dieser Kategorien entsprechen den in Unicode v3.1 definierten general categories in Namen und Aufbau. symbolische Darstellung Bedeutung L (All Letters) Alle Buchstaben Lu (Uppercase) Alle Großbuchstaben Ll (Lowercase) Alle Kleinbuchstaben Lt (Titlecase) Sprachabhängige (potentielle) Großschreibung des ersten Buchstabens eines Wortes. (vgl. UNICODE technical report #21 sowie Derived General Category Lt ). Lm (Modifiers) Zusammenfassung der verschiedensten Ton- und Betonungszeichen Lo (Others) Zusammenfassung von Zeichen, die in keine der sonstigen L-Zeichenfamilien fallen symbolische Darstellung Bedeutung M (All Marks) Alle Markierungssymbole Mn (Non-Spacing) Markierungssymbole, ausschließlich Leerzeichen Mc (Space combining) Markierungssymbole mit Leerzeichen kombiniert Me (Enclosing) Markierungssymbole, die andere Zeichen umschließen symbolische Darstellung Bedeutung N (All Numbers) Beliebige Ziffer; daher nicht notwendigerweise arabisch. Unicode stellt eingekreiste (#x2460-#x2473), geklammerte (#x2474-#x2487) sowie Ordinalzahlen (mit abschließendem Punkt) (#x2488-#x249b) zur Verfügung. Nd (Decimal Digit) eine arabische Ziffer Nl (Letter) auf Buchstaben beruhende Zifferndarstellungen, wie römische Ziffernsymbole (#x20dd-#x217f) No (Other) Alle sonstigen Ziffernsymbole symbolische Darstellung Bedeutung P (Punctuation) Alle Interpunktionssymbole Pc (Connector) Verbindende Interpunktionssymbole (z.B. Unterstrich (#x5f) Pd (Dash) Verschiedene Verbindungsstriche Ps (Open) Öffnende Bereichssymbole wie die verschiedenen Klammertypen Pe (Close) Schließende Bereichssymbole wie die verschiedenen Klammertypen Pi (Initial Quote) Öffnende Anführungszeichen.
    In einigen Fällen Verhalten identisch zu Ps oder Pe         Pf (Final Quote) Schließende Anführungszeichen.
    In einigen Fällen Verhalten identisch zu Ps oder Pe         Po (Other) Alle anderen Interpunktionssymbole     symbolische Darstellung Bedeutung Z Alle Separatoren Zs (Space) Trennende Leerzeichen Zl (Line) Zeilentrenner (#x2028) Zp (Paragraph) Absatztrenner (#x2029) symbolische Darstellung Bedeutung S Alle Symbole Sm (Math) Verschiedene mathematische Symbole (Operatoren, Pfeile, etc.) Sc (Currency) Währungssymbole (Dollarzeichen: #x24, Eurozeichen: #x20ac) Sk (Modifier) Ton- und Betonungssymbole (ähnlich zu Lm) So (Other) Alle anderen Symbole symbolische Darstellung Bedeutung C Alle sonstigen Cc (Control) Nicht-druckbare Kontrollzeichen Cf (Format) Formatierungszeichen (z.B. syrisches Abkürzungssymbol) Co (Private Use) ungefähr 137500 Zeichen zur freien anwenderdefinierten Belegung Cn (Not Assigned) Zeichen, denen innerhalb Unicode explizit keine Belegung zugewiesen wurde Reguläre Ausdrücke können innerhalb des pattern-Elements direkt angegeben werden. Die Zeichenkettenfamilien werden durch ihre symbolische Darstellung, eingeleitet durch \p und durch geschweifte Klammern umschlossen, dargestellt.
    Zusätzlich ist durch \P das Komplement zu jeder der aufgeführten Zeichenkettenfamilien definiert.
    Ergänzend kann die Definition der zulässigen Zeichengruppen vollständig wahlfrei erfolgen. Hierzu wird das Negationssymbol ^ angeboten, welches eine Aufzählung von Zeichen von der Verwendung ausschließt. Darüberhinaus können auf der Basis simpler Mengendifferenzoperationen eigene Zeichenklassen komfortabel definiert werden.
    Für die am häufigsten benötigten Zeichenklassen sind durch XML-Schema bereits vorgegebene abkürzende Schreibweisen definiert. Hierzu werden bereits die bisher vorgestellten Syntaxmechanismen angewendet. abkürzende Schreibweise entsprechende Langform . [^\n\r] \s [#x20\t\n\r] \S [^\s] \i Die initialen Zeichen eines gültigen XML-Namens; entspricht dem ersten Teil der Syntaxproduktion 5 \I [^\i] \c Diejenigen Zeichen, die der XML-Syntaxproduktion 4 entsprechen \C [^\c] \d \p{Nd} \D [^\d] \w [#x0000-#x10FFFF]-[\p{P}\p{S}\p{C}]
    Alle Zeichen, außer der Klassen für Interpunktions- und Separatorenzeichen, sowie der Klasse der sonstigen Zeichen.         \W [^\w]

    Beispiel (eine vereinfachte, d.h. unter Nicht-Berücksichtigung von Behörden- und Diplomatennummern) deutsche Autonummer im bekannten Format: Einführende Bezeichnung des Landkreises durch mindestens einen, jedoch höchstens drei Großbuchstaben, gefolgt von einem trennenden Bindestrich, an den sich ein oder zwei weitere Großbuchstaben anschließen. Auf ein Leerzeichen folgen eine, jedoch höchstens vier Ziffern:
    Weitere Informationen: Anhang F -- Reguläre Ausdrücke -- der XML-Spezifikation
  • enumeration
    Festlegung von zulässigen Werten eines Typs durch vollständige Aufzählung.
    Beispiel (die Ampelfarben: rot, gelb, grün):
  • whitespace
    Behandlung von white spaces innerhalb eines Elements des definierten Typs. Erlaubte Belegungen und ihre Bedeutung:
    preserve: Keine Veränderung des Inhaltes durch Normalisierung; evtl. enthaltene white spaces bleiben erhalten
    replace: Alle Vorkommen von Tabulatoren, Zeilenvorschub und Wagenrücklauf werden durch Leerzeichen (#x20) ersetzt
    collapse: Nach der Substitution gemäß replace werden mehrfach auftretende Leerzeichen zu einem einzigen kompaktifiziert, sowie führende und abschließende Leerzeichen entfernt.
    (in Spezifikation nachschlagen)
  • maxInclusive
    Höchster zulässiger numerischer Wert. Im mathematischen Sinne sind daher alle Werte kleiner oder gleich dem im value-Attribut angegebenen zugelassen.
    Beispiel (Zahlen <= 100):
    Anmerkung: In vielen Fällen kann eine maxInclusive-Festlegung ohne Informationsverlust in eine äquivalente maxExclusive-Definition überführt werden.
  • maxExclusive
    Wert unterhalb (im mathematischen Sinne kleiner) dem alle numerischen Belegungen zugelassen sind.
    Beispiel (Zahlen < 100):
    Als Belegungen des Typs uHu sind alle Zahlen kleiner als 100 zugelassen. Durch die Verwendung des XSD-Typen decimal als Basistyp kann auch keine verlustfreie Überführung in eine maxInclusive-Festlegung überführt werden, da hierfür die größte zugelassene Zahl fixiert werden müßte, was jedoch die Typdefinition von decimal explizit offen läßt.
  • minInclusive
    Kleinster zugelassener Wert.
    Beispiel (Zahlen >= 25):
  • minExclusive
    Kleinster Wert, der nicht mehr zugelassen ist. Im mathematischen Sinne sind alle Zahlen, die größer sind, gültige Belegungen.
    Beispiel (Zahlen > 25):
  • totalDigits
    Gesamtstellen einer Zahl, gebildet aus der Summe der Vorkomma- und der Nachkommastellen.
    Beispiel (Zahlen mit höchstens sieben Stellen):
  • fractionDigits
    Anzahl der Nachkommastellen eines Dezimalbruches.
    Beispiel (Zahl mit höchstens neuen Stellen, davon zwei Nachkommastellen):

Definition von Attributen:
Die Attributdeklaration erfolgt durch das XSD-Element attribute. Die Mächtigkeit entspricht auch hier, wie bereits für die Elemente verwirklicht, einer Obermenge der DTD. So können neben optionalen, zwingenden und konstanten Attributen auch Aufzählungsattribute und Mengen realisiert werden. Hierbei wurde auf die Orthogonalität zum durch simpleType geschaffenen Typmechanismus geachtet.
Die Charakteristika (ausgedrückt in Attributen des XSD-Elements attribute) einer Attributdeklaration umfassen:

  • name: Ein Doppelpunkt-freier Namen (NCName) gemäß Namensraumproduktion 7.
  • id: erlaubt die eineindeutige Kennzeichnung eines Attributs durch eine Schema-weit eindeutige Zeichenkette.
  • default: Belegung mit Vorgabewert.
  • fixed: Konstante Belegung.
  • type: Typ des Attributes, definiert durch einen simpleType.
  • form: Legt fest, ob der Attributname im XML-Instanzdokument durch ein Namensraumpräfix eingeleitet wird (Belegung: qualified, andernfalls unqualified).
  • ref: Verweis auf eine globale Attributdefinition.
  • use: Verwendung des Attributes, Wert entspricht optional, required oder prohibited.
    Vorgabegemäß wird optional angenommen und das Attribut damit nicht zwingend im XML-Dokument erwartet. Den Gegensatz hierzu bildet required, wodurch das Attribut als zwingend anzugeben definiert wird. prohibited verbietet die Nutzung des Attributes im XML-Dokument.

Anmerkung: Einen Anwendungsfall der Belegung prohibited für use bilden Attribute, die innerhalb des Schemas bereits definiert sind, jedoch noch nicht zur allgemeinen Nutzung freigegeben wurden.

Das Beispiel zeigt einige Varianten der Attributdeklaration. So definieren myAtt1 mit myAtt4 globale Attribute, die innerhalb verschiedener Elemente verwendet werden können. Hierdurch wird die bereits für Elemente verwirklichte Mimik der einmaligen Deklaration und anschließenden beliebigen Verwendung auch auf Attribute ausgedehnt. Die Nutzung der so deklarierten Attribute geschieht durch das ref-Attribut innerhalb des Attribute-Elements des beherbergenden Elements.
myAtt1 definiert ein typenloses Attribut, dem vorgabegemäß der allgemeinste Typ anyType zugeordnet wird. Die Angabe dieses Attributes ist optional (use="optional"), was der Vorgabe entspricht.
Der XSD-Standardtyp decimal findet zur Definition des Attributs myAtt2 Verwendung. Die zwingend anzugebenden (use="required") Inhalte dieses Attributs werden durch einen XML-Schema-Parser auf Typkonformität geprüft.
myAtt3 veranschaulicht die Bildung eines anonymen (inneren) atomaren Typen zur Definition eines Attributs. Der durch Restriktion gebildete neue Datentyp steht ausschließlich innerhalb des Attributs myAtt3 zur Verfügung. Die Syntax der Datentypspezialisierung entspricht der im vorhergehenden Abschnitt diskutierten. Zudem ist die Verwendung des Attributes innerhalb eines XML-Dokumentes untersagt; ausgedrückt durch die Belegung use="prohibited"
Analog der Typisierung eines Elementinhaltes durch einen anwenderdefinierten Typen gestaltet sich das Vorgehen für Attribute. Veranschaulicht wird dies durch die Definition von myAtt4. Sie greift auf den eigen-definierten Typen myType1 zurück.
Dem Attribut myAtt5 ist zusätzlich zur Benennung, die innerhalb des verwendenden Elementes eindeutig sein sollte, ein Dokument-weiter Schlüssel (id) zugeordnet.
Innerhalb des Elements foo werden die fünf zuvor definierten Attribute verwendet. Trotz der Reihenfolge der Definitionen im complexType-Element verfügen die Attribute im XML-Instanzdokument -- auch bei der Verwendung von XML-Schema -- über keinerlei Reihenfolge (vgl. XML-Spezifikation).
Zusätzlich enthält die Elementdefintion für foo mit myAtt6 ein lokales Attribut. Diese Definitionsvariante entspricht am ehesten der der Document Type Definition, da sie eine Wiederverwendung außerhalb des definierenden Elements ausschließt.

Abschließend eine gültige (sowohl valid als auch schema valid) Dokumentinstanz der Projektverwaltungsstruktur.

Werkzeuge:
Zwar existiert -- wie für alle XML-Dokumente -- die Möglichkeit, Dokument Typ Definitionen und XML-Schemata per Hand mit einem Texteditor zu erstellen, jedoch ist dieses Vorgehen, insbesondere für umfangreiche XML-Vokabulare, zeitaufwendig und fehlerträchtig. Zusätzlich läßt die rein textuelle Formulierung die entstehenden Schemadokumente schnell unübersichtlich werden.
Inzwischen existieren einige gute DTD- und Schemaeditoren, die zumeist neben visueller Syntaxhervorhebung auch die kontextsensitive Editierung erlauben und so eine wesentliche Erleichterung der Schemaerzeugung bilden. Gleichzeitig bieten die meisten verfügbaren Werkzeuge dieser Klasse auch Möglichkeiten zur Validierung des erzeugten Schemas an.
Ergänzend wird vielfach auch eine graphische Repräsentation der DTD- oder XSD-Struktur angeboten.
Die Abbildungen zeigen Ansichten der Werkzeuge XML Authority bzw. XML Spy

XML Schema Part 0: Primer XML Schema Part 1: Structures XML Schema Part 2: Datatypes XML Schema @ Cover-Pages Parsing the Atom -- Diskussion über die Vor- und Nachteile inhärent komplexer atomarer Typen Schema-Informationen @ jeckle.de XML-Authority (DTD- und XSD-Editor) XML Spy (DTD- und XSD-Editor) XHTML -- XML und das Web

Die Verbindung zwischen der generischen Metasprache XML und dem World Wide Web datiert zurück bis vor die Entstehung der XML ...
Wie bereits im Eingangskapitel erwähnt, bildet die Hypertext Markup Language HTML die eigentliche Initialzündung des World Wide Web. Technisch ist sie als Anwendung der normierten generischen Metasprache SGML realisiert und kann heute als vermutlich bekannteste und verbreitetste Auszeichnungssprache überhaupt gelten.

Die Graphik faßt noch einmal die Beziehung von HTML und SGML zusammen, und schlägt eine Brücke in die XML-Welt.
Ursprünglich setzte Tim Berners-Lee das Ur-HTML 1989 als SGML-Anwendung durch Definition einer geeigneten (SGML-)Document Type Definition um (vgl. IETF RFC 1866 (HTML v2.0)). Zwar ähnelt die für HTML definierte Syntax der später für XML-Dokumente eingeführten, jedoch läßt sich an einigen Stellen (deutlich) die Abkunft von SGML ablesen. Dies wird insbesondere bei Syntaxkonstrukten offenkundig, die zwar in SGML erlaubt, jedoch in der später gebildeten Untermenge XML illegal sind. Die fehlenden schließenden Tags (beim img- oder br-Element) oder die gelockerte Attributsyntax (beim compact-Attribut des ul-Elements) können hierfür als bekannte Beispiele dienen.
Diese SGML-Sprachmittel werden entweder durch den Anwender vorgegeben (wie SHORTTAG = YES für das img-Element) oder sind inhärent zur Kompaktifizierung der Instanzstrukturen (wie die Attributminimierung) vorgegeben. Sie stellen einen Gutteil der Unübersichtlichkeit und Komplexität der Sprache SGML dar, da durch sie prinzipiell unterschiedliche Darstellungen identischer Bedeutung erlaubt werden. Als Resultat des sich (theoretisch) ergebenden Umsetzungsaufwandes realisieren HTML-Browser bis heute nicht die volle Mächtigkeit von SGML, die notwendig wäre um HTML korrekt zu interpretieren, sondern nur einen herstellerabhängigen Ausschnitt. Daher kommt es immer wieder zu sichtbaren Inkompatibilitäten der HTML-Interpretation verschiedener Web-Browser.
Zusätzlich haben die verschiedenen Hersteller im Laufe der Zeit den ursprünglichen HTML-Standard um eigene proprietäre Elemente erweitert. Naturgemäß werden diese neuen Elemente nur durch den Browser des jeweiligen Herstellers interpretiert; alle anderen Browser ignorieren die ihnen unbekannten Tags spezifikationsgemäß und zeigen stattdessen nur den Elementinhalt an.
Die nachfolgenden Graphiken zeigen dies an einem einfachen Beispiel:

Das dargestellte HTML-Dokument nutzt das in der HTML-Spezifikation ab der Version 3.2 vorgesehene rules-Attribut. Die Abbildungen zeigen jedoch, daß es nur durch den Internet Explorer ausgewertet und dargestellt wird.
Die Tabellendefinition nutzt in der wiedergegebenen Form die Freiheiten des HTML-Standards aus, und verzichtet weitestgehend auf schließende Tags. Beide Browser geben trotzdem die Struktur korrekt wieder.
Bei den drei abschließenden Elementen handelt es sich um herstellerspezifische Erweiterungen durch Netscape (blink) bzw. Microsoft (color-Attribut und marquee-Element).

Einerseits zur (Wieder-)Vereinheitlichung der inzwischen offen konkurrierenden HTML-Dialekte, andererseits zur leichteren technischen Umsetzbarkeit der HTML-Grammatik initiierte das World Wide Web Konsortium 1998 die XHTML-Aktivität, welche sich die Umsetzung von HTML als XML-Anwendung zum Ziel setzte.
Mit der Verabschiedung des HTML-Nachfolgers XHTML v1.0 im Januar 2000 wurde für die bis dato prominenteste Web-Sprache die Abkehr von SGML vollzogen. Im Kern stellt die neue Sprache die Reformulierung der letzten SGML-basierten HTML-Variante 4.01 in XML dar. Wie bereits die Ur-Sprache verwendet auch XHTML (zunächst) den Grammatikmechanismus der Document Type Definition und ist äußerlich (d.h. bei Betrachtung der Instanzdokumente) nicht von der Vorgängersprache zu unterscheiden. Genaugenommen sind die angebotenen Minimierungsmöglichkeiten für SGML optional und müssen nicht zwingend genutzt werden. Daher ist weiterhin jedes gültige XHTML v1.0-Dokument ebenfalls konform zur HTML v4.01-Definition.

Nachfolgend sind die Änderungen an HTML zusammengetragen, welche zum XHTML-Standard führten:

  • Groß- und Kleinschreibung der Element- und Attributnamen ist signifikant.
  • Attribute müssen über Wertangaben verfügen, die Definition <ul compact> als Kurzschreibweise von <ul compact="compact"> ist nicht mehr zugelassen.
  • Attributwerte müssen in Anführungszeichen eingeschlossen sein.
  • Im Instanzdokument dürfen die Zeichen & und < nicht direkt auftreten, sondern müssen durch Enititätsrefernzen &amp; bzw. &lt; ausgedrückt werden.
  • Bisher optionale Endtags sind in XHTML zwingend anzugeben. Elemente enden daher wie in XML üblich mit dem schließenden Tag.
  • Korrekte Element-Schachtelung ist zwingend einzuhalten.
  • Leere Elemente müssen über schließende Tags verfügen, oder durch die abkürzende Schreibweise dargestellt werden.
  • Das Instanzdokument muß über genau ein Wurzelelement (üblicherweise html) verfügen.
  • Innerhalb der Kommentarsyntax müssen die beiden Bindestriche nach der Eröffnungssequenz <! folgen.
  • Die XML-Encodingdeklaration ist für alle Zeichensätze außer UTF-8 und -16 zwingend anzugeben.

Wird ein HTML-Dokument entsprechend modifiziert, so erhält man ein wohlgeformtes XML-Dokument. Wird zusätzlich die DOCTYPE-Deklaration angegeben, und so die XHTML-DTD referenziert, so kann zusätzlich die Gültigkeit sichergestellt werden.
Die aktuell verfügbaren Browser können überwiegend bereits XHTML v1.0-konforme Dokumente darstellen.
Im Detail bedeutet dies, daß neben der Einhaltung der durch die DTD definierten Strukturen auch die Nutzung des XHTML-Namensraumes für das gesamte Dokument erfolgen muß. Konsequenterweise muß jedes XHTML-Dokument ferner die entsprechende XHTML-DTD referenzieren. Zur korrekten Behandlung bereits existierender Dokument-Instanzen, die noch Elemente früherer HTML-Versionen beinhalten, welche nicht mehr durch den Standard unterstützt werden, sind insgesamt drei HTML-DTDs durch den Standard definiert. Neben den DTDs zur Darstellung Frame-basierter (frameset-DTD) bzw. normaler (strict-DTD) Dokumente ermöglicht die transitional Dokument Typ Definition den leichteren Übergang zu XHTML.
Zur automatisierten Anpassung existierender HTML-Dokumente auf den neuen Sprachstandard hat das W3C das kostenfreie Werkzeug Tidy veröffentlicht.
Der nachfolgende XHTML-Code wurde mit diesem Werkzeug automatisch aus dem vorangegangenen Beispiel erzeugt. (Aufruf: tidy -asxml incompatibleHTML.html > validXHTML.html )

Modulares XHTML

XHTML v1.1 dekomponiert das ehemals durch genau eine DTD dargestellte HTML-Vokabular in einzelne problemspezifische Module. Zusätzlich wird die Sprache um die Ruby-Anmerkungen erweitert. Hierbei handelt es sich um einen simplen Annotationsmechanismus für beliebige Anmerkungen im Text, wie er im südasiatischen Sprachraum breite Verwendung findet.

Breite Aufmerksamkeit dürften die in XHTML v1.1 verwirklichten Modularisierungsaktivitäten wecken. Sie haben es sich sich zum Ziel gesetzt, die Sprache in verschiedene eigenständige Module aufzuteilen, um so die Wiederverwendung einzelner Teilbereiche (wie z.B. Tabellen, Graphiken, Listen) in anderen XML-Sprachen zu ermöglichen. Gleichzeitig können ausgewählte Module für bestimmte Endgeräte umgesetzt werden, beispielsweise für ressourcenbeschränkte mobile Endgeräte.
Im Detail definiert der Standard 22 Einzelmodule mit ihren spezifischen Aufgaben. Das Zentrum der Dekomposition bilden die vier Kernmodule Struktur, Text, Hypertext und Listen. Sie müssen zwingend durch eine Implementierung umgesetzt werden, um als konform zu XHTML v1.1 anerkannt zu werden.
Nachfolgend sind die Module und ihre Aufgabe sowie typische Elemente daraus zusammengefaßt:

  • Attribute Collections : Versammelt XML-Attribute die für verschiedenste XHTML-Elemente angegeben werden können.
    Die Attribute Collections werden durch fünf Einzelsammlungen (Core, I18N (Internationalisierung), Events, Style, Common) gebildet, die jeweils ein oder mehrere Attribute umfassen.
    Beispiele: class (Core-Modul), onclick (Events-Modul), style (Style-Modul)
  • Structure Module: Bestandteil des XHTML-Kernmoduls.
    Definiert die zentralen strukturellen Elemente von XHTML, die als Inhalt in den meisten Dokumenten der XHTML-Familie auftreten.
    Beispiele: html, head, body, ...
  • Text Module: Bestandteil des XHTML-Kernmoduls.
    Definiert alle grundlegenden Containerelemente sowie deren Attribute und Inhaltsmodelle.
    Beispiele: abbr, p, strong, ...
  • Hypertext Module: Bestandteil der XHTML-Kernmodule.
    Definiert das (eine!) Element welches zur Verlinkung in XHTML-basierten Hypertexten verwendet wird.
    Beispiel: a
  • List Module: Bestandteil des XHTML-Kernmoduls.
    Definiert alle Listen-orientierten Elemente und deren Attribute.
    Beispiele: ul, li, dl, ...
  • Presentation Module: Bestandteil des XHTML-Texterweiterungsmoduls.
    Definiert einige einfache Elemente zur Realisierung präsentationsorientierter Darstellungen.
    Beispiele: b, small, tt, ...
  • Edit Module: Bestandteil des XHTML-Texterweiterungsmoduls.
    Definiert Elemente zum Ausdruck editorieller Änderungen.
    Beispiele: ins, del
  • Bi-directional Text Module: Bestandteil des XHTML-Texterweiterungsmoduls.
    Definiert ein Element zur Behandlung von Text in verschiedenen Lesrichtungen.
    Beispiel: bdo
  • Basic Forms Module: Bestandteil des XHTML-Formularmoduls.
    Versammelt die gurndlegenden Elemente zur Realisierung von Formularen.
    Beispiel: form, input, option, ...
  • Forms Module: Bestandteil des XHTML-Formularmoduls.
    Versammelt alle in HTML v4.0 definierten Formularelemente. Dieses Modul hat daher Überschneidungen mit dem Basic Forms Modul.
    Beispiele: form, input, button, ...
  • Basic Tables Module: Bestandteil des XHTML-Tabellenmoduls.
    Definiert die grundlegendsten Elemente die zur Formulierung einer Tabelle notwendig sind.
    Beispiele: table, td, th, ...
  • Tables Module: Bestandteil des XHTML-Tabellenmoduls.
    Umfaßt als Obermenge des Basic Tables Moduls alle Elemente die zur Definition einer Tabelle benötigt werden.
    Beispiele: table, td, thead, ...
  • Image Module: Umfaßt das ausschließlich Element zur referenzierenden Einbettung von Bildern.
    Beispiel: img
  • Client-side Image Map Module: Versammelt Elemente zur clientseitigen Verarbeitung von Ereignissen die durch Anwenderinterkation mit Bildern entstehen. Dieses Modul erfordert die Umsetzung des Image Moduls.
    Beispiel: Die Attribute coords oder usemap für die Elemente a, area, ...
  • Server-side Image Map Module: Versammelt Elemente zur serverseitigen Verarbeitung von Ereignissen die durch Anwenderinteraktion mit Bildern entstehen. Dieses Modul erfordert die Umsetzung des Image Moduls.
    Beispiel: Das Attribut ismap für die Elemente img und input
  • Object Module: Definiert ein Element zur allgemeinen Einbettung beliebiger Elemente.
    Beispiel: object
  • Frames Module: Umfaßt die Elemente die zur Formulierung von Frames, d.h. die Anzeige separierter XHTML-Dokumente in einem Darstellungsfenster.
    Beispiel: frameset, frame, noframes
  • Target Module: Ermöglicht es aus Frames heraus andere anzusprechen bzw. neue Fenster zu öffnen.
    Beispiel: Das target-Attribut für die Elemente a, link, base, ...
  • Iframe Module: Definiert ein Element zur Realisierung von inline Frames
    Beispiel: iframe
  • Intrinsic Events Module: Definiert Attribute zur Behandlung von benutzergetriebenen Ereignissen.
    Beispiel: onblur, onload, onsubmit, ... für die Elemente a, body, form, ...
  • Metainformation Module: Definiert ein Element zur Darstellung von Metainformation über XHTML-Seiten.
    Beispiel: meta
  • Scripting Module: Definiert Elemente zur Einbettung von aktiven Elementen in XHTML-Seiten durch Scriptsprachen.
    Beispiel: noscript, script
  • Style Sheet Module: Definiert ein Element zur Einbettung von präsentationsorientierter Information in XHTML-Dateien.
    Beispiel: style
  • Link Module: Definiert ein Element, das zur Referenzierung externer Ressourcen verwendet werden kann.
    Beispiel: link
  • Base Module: Definiert ein Element welches verwendet werden kann um die Basis URI eines Dokuments festzulegen. Diese URI wird im Rahmen einer Auswertung gemäß XMLBase herangezogen.
    Beispiel: base
  • Name Identification Module: Dieses -- inzwischen als veraltet (engl. deprecated) gekennzeichnete -- Modul definiert ein Attribut zur Benennung verschiedener XHTML-Elemente.
    Beispiel: name-Attribut für die Elemente a, applet, form...
  • Legacy Module: Dieses Modul versammelt eine Reihe von Attributen und Elementen, die bereits in vorhergehenden (X)HTML-Versionen als veraltet gekennzeichnet wurden.
    Beispiel: basefont, center, font, ...

Das Schema-Fragment zeigt die Nutzung beliebiger Elemente aus dem XHTML-Namensraum im QualifikationsprofilType.

Eine gültige Dokumentinstanz kann innerhalb des Elements Qualifikationsprofil jedes Element aus dem XHTML-Namensraum beinhalten:

XHTML und XML Schema

Parallel zur Modularisierung und den laufenden Erweiterungsaktivitäten zu XHTML wurde inzwischen auch an der Neufassung der Strukturbeschreibung gearbeitet. Da der Sprachumfang der SGML-basierten Sprache HTML mit der Reformulierung in XML (XHTML v1.0) nicht verändert wurde (auch XHTML v1.1 läßt diesen unangetastet) bestand auch keinerlei Notwendigkeit zur Überarbeitung der DTD-basierten Vokabularbeschreibung.
Mit dem abzusehenden Übergang zur nächsten Version des XHTML-Vokabulars, welche erstmals seit 1999 neue Elemente in die Sprache einführen wird, vollzieht sich auch die Umstellung auf XML Schema.
Bereits für XHTML v1.0 liegt Formulierung als XML Schema in einer nicht normativen W3C Note vor.

Ausblick auf XHTML v2.0

XHTML markiert die erste echte Weiterentwicklung der XHTML-Sprachfamilie seit ihrer Löslösung von SGML und der daran anschließenden Fundierung auf XML.
Das gegenwärtig erst im Status eines Working Draft zugängliche Vokabular definiert einige neue Elemente und entfernt einige bekannte Konstrukte. Daher stellt es keine abwärtskompatible Weiterentwicklung der existierenden XHTML-Sprachfamilie dar, sondern entwirft vielmehr eine neue Hypertextsprache.
Nachfolgend werten einige Erweiterungen und Modifikationen gegenüber dem vertrauten XHTML an Beispielen diskutiert.

XHTML v2 wird keine explizite Angabe des Zeilenumbruchs durch den Anwender mehr unterstützen, sondern dies vollständig der Darstellungskomponente überlassen. Konkret wird das br-Element als veraltet gekennzeichnet und stattdessen zukünftig durch das neu eingeführte Element line ersetzt werden welches sich in ähnlicher Weise nutzen läßt.
Beispiel zeigt ein XHTML-Fragment welches korrekt im Sinne der Festlegungen der ersten XHTML-Generation formuliert ist. Beispiel stellt diesem die XHTML v2 konforme Darstellung gegenüber.

Die Beispiele und illustrieren die wohl augenscheinlichste Neuerung des XHTML v2 Sprachvorschlages. Das bisher zur Referenzierung von Bilddaten vorhergesehene Element img wird zugunsten des bereits existierenden Elements object für veraltet erklärt.
Hintergrund dieser Entscheidung ist der Versuch der Aufhebung der Asymmetrie in der Adressierung von referenzierten Bilddaten und sonstigen externen Daten eines nicht näher definierten Formats wie beispielsweise Applets.
Innerhalb des object-Elements übernimmt das Attribut data die Rolle der bisher durch src ausgedrückten Lokalisationsreferenz. Neu hinzu kommt die die Typisierung des referenzierten Objekts mittels MIME-Type, welcher im type-Attribut angegeben wird.
Zusätzlich zeigt das Beispiel die Nutzung der standby-Angabe welche zur Aufnahme von Text dient der während des Objektladevorganges (d.h. der Dereferenzierung der durch data identifizierten Ressource) dem Anwender präsentiert werden kann.

Folgenschwerste Modifikation der bestehenden XHTML-Struktur dürfte die Entfernung der Überschriftenelemente h1 mit h6 sein. Diese Elemente welche bisher die hierarchische Position einer Überschrift absolut durch die Wahl des Elementtyps ausdrückten werden zukünftig durch zugunsten eines allgemeinen Hierarchieelements h nicht mehr unterstützt. Ein Grund dieser Entscheidung mag in der praktischen Verwendung der bisher angebotenen Überschriftselemente liegen. So wurden diese häufig zur Erreichung eines gewissen visuellen Verhaltens herangezogen, welches sich aus dem im Elementnamen ablesbaren Verhältnis der Elemente zueinander ablesen lies. So wird typischerweise ein Überschriftselement der Ebene zwei (h2) in einer kleineren oder schwächeren optischen Darstellung umgesetzt als eines der Ebene eins (h1).
In XHTML v2 ergibt sich die visuelle Präsentation ausschließlich aus dem Verhältnis der h-Elemente zu der sie umgebenden section. Daher entspricht die Formulierung des Beispiels der aus semantisch.

Die unauffälligste und gleichermaßen wirkungsmächtigste Neuerung ergibt sich aus der Inklusion des href-Attributes in die Zusammenstellung der allgemeine verwendbaren Attribute der Common Attribute Collection .
Diese Aufwertung des genannten Attributs eröffnet die Möglichkeit beliebige XHTML-Elemente als Quellen von Hyperlinkverknüpfungen heranzuziehen wie es zeigt.

Obwohl das Beispiel auf den ersten Blick einen interessanten Mächtigkeitsgewinn erkennbar werden läßt, birgt es jedoch verschiedene Problemstellungen.
So ist das Interaktionsverhalten von Hyperlinks jenseits des bekannten a vollständig undefiniert und ihre überlappende Definition (wie durch die Einbettung des Elements line in das bereits mit einem Hyperlink versehene Element p illustriert) wirft die Frage nach der Behandlung durch das Anzeigegerät auf.
Auch führt dieser neu einzuführende Mechanismus notwendigerweise mit der aus verschiedenen Browsern bekannten Darstellungsweise von Hyperlinks durch blau gefärbten und unterstrichenen Text. So müßte das Beispieldokument vollständig gefärbt und unterstrichen dargestellt werden, was sich zweifellos als der Lesbarkeit nicht zuträglich erweisen würde.
Überdies entwickelt XHTML durch die diskutierte Vorgehensweise einen allgemein verwendbaren Referenzierungsmechanismus neu, der bereits durch den Standard XLink verfügbar ist. Vielmehr noch ergeben sich auf der zulässigen Kombination beider Verfahren weitere Problemstellungen.
Vor dem Hintergrund dieser Kritikpunkte ist nicht damit zu rechnen, daß die bestehende Form der erweiterten Hyperlinks in den letztendlich verabschliedeten Standard eingang finden wird.

XML über HTTP

Ähnlich der Übertragung von klassischem HTML über HTTP zur Anzeige in Web-Browsern kann auch reines XML direkt per HTTP transportiert werden. Naturgemäß ist hierfür jedoch, anders als für (X)HTML, keine visuelle Repräsentation durch das empfangende Endgerät festgelegt.
Einige Hersteller bieten für natives XML strukturierte baumartige Darstellungen an. Der bekannteste Vertreter dieser Klasse dürfte Microsofts Internet Explorer sein, der ab Version 5.0 auch XML-Eingangsdaten unterstützt. Seine Browseransicht für das Beispieldokument ist im nachfolgenden Bildschirmabzug wiedergegeben.
Über Zuordnung von Präsentationsinformation durch XML Stylesheets (siehe Kapitel 2.4) kann XML direkt an einen Web-Client gesendet werden. Zur Anzeige der Informationen wird im Browser ein Stylesheet herangezogen. Genau dieses Prinzip ist auch durch den Internet Explorer verwirklicht; dort wird auf jedem XML-Dokument, welches keine eigene Stylesheetquelle identifiziert, eine Vorgabetransformation durchgeführt, welche die abgebildete Baumstruktur erzeugt.
Andere Browser unterstützen dieses Verhalten nicht und präsentieren daher für XML-Dokumente ohne assoziiertes Stylesheet lediglich einen leeren Bildschirm.

Modularization of XHTML XHTML 1.0 in XML Schema XHTML v2.0 XML-Standards und -Anwendungen der zweiten Generation ...

Das nachfolgende Kapitel beleuchtet aufbauend auf den Grundlagen des ersten Abschnittes einige der sog. XML Standards der zweiten Generation.
Sie bilden zugleich als erste Anwendungen der eXtensible Markup Language auch Sprachen im engeren Sinne, da sie neben der Syntax auch Semantikdefinition, zumeist in Form eines Ausführungsmodells, umfassen.

Die Abbildung stellt die verschiedenen Generationen der XML-Standards in der Übersicht dar. Den Anfang -- augenzwinkernd als Web-Prähistorie bezeichnet -- bildet die bekannte Hypertextsprache HTML. Die erste Standardgeneration läßt sich an der Verabschiedung der XML-Recommendation im Februar 1998 festmachen. In der Folge wurden erste XML-Sprachen, wie XHTML, entwickelt. Wesentlich komplettiert wird diese erste Entwicklungsstufe durch die XML-Namensräume. Auf der Basis des Urstandards und dieser ersten Erweiterung, die selbst als XML-Sprache realisiert ist, entstanden die ersten weiter verbreiteten XML-Sprachen für produktive Zwecke. Beispielsweise die erweiterten Hyperlinks der Spezifikation XLink, aber auch die Stylesheetsprache XSL zur Erzeugung verschiedener Präsentationssichten auf Basis von XML-Dokumenten, sowie die Transformationssprache XSLT ! zur Umwandlung von XML-Dokumenten in verschiedene Ausgabeformate.
Mit der Integration der Namensräume in die XML-Spezifikation (XML 2nd edition) vollzieht sich bereits andeutungsweise der Übergang zur neuen konzeptionellen Basis der Metasprache XML. Am deutlichsten wird dieser Evolutionsschritt durch die Verabschiedung des XML-Schemastandards im Mai 2001 markiert. Er löst den bisherigen -- von SGML übernommenen -- Grammatikmechanismus der Document Type Definition ab, und legt die XML als selbstbeschreibende Metasprache an. Gemeinsam mit XML v1.0 2nd edition bildet diese W3C-Recommendation die neue technische Basis der weiteren Standardisierungsbemühungen. Die Graphik verwendet hierfür den teilweise anzutreffenden Begriff einer XML v2.0, der jedoch in dieser Form nicht durch das W3C geprägt wurde. Aufbauend auf diesem Fundament werden einige der bereits bestehenden XML-Co-Standards überarbeitet und auf die neuen Randbedingungen, wie XML-Schema, abgestimmt.

(Dokument-)Verknüpfungen: XML Links

Hyperlinking, als Möglichkeit der nichtlinearen wahlfreien Navigation in Dokumenten und zwischen beliebigen Ressourcen, ist in Zeiten des WWW allgegenwärtig. Zumeist werden die bekannten Sprungstellen im (X)HTML-Dokument farblich und zusätzlich durch Unterstreichung hervorgehoben dargestellt; ein simpler Mausklick verzweigt zur referenzierten Adresse oder aktiviert die hinterlegte Reaktion.
Bei genauerer Betrachtung läßt sich noch ein zweiter Verweismechanismus in (X)HTML identifizieren: die Referenzierung Dokument-externer Graphikdateien. Die (X)HTML-Datei enthält lediglich einen Verweis auf die URI der Graphik; die automatische Auflösung der Referenz, das Laden der Datei und die Integration in das (X)HTML-Dokument an der Stelle des img-Elements übernimmt der HTML-Agent (Browser oder sonstiges Anzeigegerät) ohne Interaktion durch den Anwender. Dieser Vorgang der automatisierten einbettenden Referenzierung wird Transklusion genannt. Der Begriff geht auf Ted Nelson und sein Xanadu-Projekt zurück. Der Terminus verbindet die beiden Worte Transfer und Inklusion um auf die beliebige physische Lokation der referenzierten Ressource und ihre transparente Einbindung in das Zieldokument gleichermaßen hinzuweisen.
Konzeptionell bilden beide Verweisarten unidirektional navigierbare (d.h. vom Quelldokument zur referenzierten Zielressource traversierbare) Verknüpfungen, die syntaktisch in das Quelldokument eingebunden werden. Das Verweisziel bleibt von der Bildung des Links unberührt.
So flexibel und naheliegend dieser Ansatz auf den ersten Blick scheinen mag, dennoch birgt er im praktischen Einsatz durchaus ernstzunehmende Unwägbarkeiten. Die bekannteste Ausprägung dürfte der HTTP-Fehler 404 -- Not Found -- sein. Er signalisiert der anfragenden Instanz, daß die angeforderte URI nicht gefunden werden konnte (spezifikationsgemäß möglich, wenn auch seltener genutzt, ist für diesen Fall auch Fehlercode 403 -- Forbidden -- zugelassen (siehe HTTP v1.0 Spezifikation )).
Die Fehlersituation entsteht zumeist durch Referenzierung einer zwischenzeitlich gelöschten oder umgezogenen URI. Zwar läßt die HTTP v1.1 Spezifikation mit dem Fehlercode 410 -- Gone -- Rückschlüsse auf die frühere Gültigkeit der URI zu, jedoch schlägt auch in diesem Falle der Referenzierungsversuch fehl (siehe HTTP v1.1 Spezifikation ).
Die Grundidee des in (X)HTML verwirklichten Linkingmechanismus läßt keine Möglichkeit zur Vermeidung diese Situation zu, da die referenzierte (d.h. unabhängige) Instanz keinerlei Information über den gesetzten Verweis innerhalb des abhängigen Dokuments erhält.

Gemeinsames Kennzeichen der beiden Verweisarten ist die direkte explizite Einbettung der Links in das Quelldokument. Hierdurch werden Pflege des Dokumentinhaltes und der Verweise an derselben organisatorischen Stelle konzentriert, Änderungen an den gesetzten Verweisen ziehen in jedem Falle Änderungen am verweisenden Dokument nach sich.
Als Folge können Dokumente nicht durch Externe auf dem Wege der Annotation durch Verweise ergänzt werden. Technisch erfordert dieses Vorgehen neben der verknüpften Quell- und Zielressource eine dritte Instanz zur unabhängigen Speicherung der Verweise.
Eine konkrete Umsetzung der freien Annotation beliebiger WWW-Seiten durch Dritte bot der, mittlerweile eingestellte, Dienst Third Voice .

Die klassischen HTML-Hyperlinks sind als Bestandteil der XML-Sprache XHTML durch Strukturen ihrer Grammatikdefinition in Form von Elementen und Attributen realisiert. Sie siedeln sich damit im Anwendungsbereich der XML an, und stehen daher nicht sprachunabhängig für alle XML-Sprachen zur Verfügung.
Durch die XML-Grundauffassung einer Welt vernetzter unabhängiger Dokumente ergibt sich die natürliche Notwendigkeit zur Schaffung eines Verweismechanismus, der für beliebige XML-Sprachen gleichermaßen universell eingesetzt werden kann. Dieser Anforderung soll die XML Linking Language (XLink) genügen.

Der Sprachstandard XLink behebt dieses Manko und schlägt für beliebige XML-Sprachen ein Vokabular mit zugehöriger Semantikdefinition zur Realisierung beliebiger Verweisstrukturen vor. Konzeptionell bildet XLink eine Obermenge des klassischen href-Elements.

Die XML Linking Language (XLink) definiert ein XML-basiertes Vokabular zur Darstellung allgemeiner Verweise in einem XML-Dokument.
Die Verwendung von XLink ist nicht an ein konkretes XML-Vokabular gebunden.
XLink-konforme Verweise können sowohl in einem Dokument ausgedrückt sein, als auch in einer externen Datenstruktur -- der sog. Linkbase -- verwaltet werden.

Erste Umsetzungen der Standardvorschlages existieren, neben einigen Spezialwerkzeugen, in den Web-Browsern Netscape (ab Version sechs) und dem Open-Source Projekt Mozilla.

Die XML Linking Spezifikation definiert in einem eigenen Namensraum eine Reihe von Attributen mit zulässigen Wertbelegungen, die für die Verwendung in eigenen XML-Sprachen zur Verfügung stehen.
Durch die Beschränkung auf Attributdefinitionen wird dem Anwender ein zusätzlicher Freiheitsgrad gegenüber der bisherigen (X)HTML-Verweismimik eröffnet. Während in Hypertextdokumenten Links ausschließlich durch Spezifikation des Attributs href im Ankerelement a definiert werden konnten, können die XLink-Attribute in beliebigen Elementen verwendet werden.

Im Einzelnen definiert die XLink-Spezifikation folgende Attribute und Wertbelegungen:

Attribut zulässige Belegung Semantik type simple, extended, locator, arc, resource, title Die verschiedenen durch die Spezifikation vorgegebenen XLink-Typen href Jede gültige URI gemäß Verweis auf die referenzierte Ressource role Jede gültige URI gemäß Verweis auf eine Ressource, welche eine nähere Beschreibung der referenzierten Ressource enthält; verwendet für simple, extended, locator oder resource typisierte Links arcrole Jede gültige URI gemäß Verweis auf eine Ressource, verwendet für simple oder arc typisierte Links title Freier Text Beschreibt die Bedeutung des Verweises in lesbarem Format show new, replace, embed, other, none Verhalten des Verweises bei seiner Aktivierung.
new öffnet die referenzierte Resource in einem neuen Fenster (entspricht damit der (X)HTML-Definition <a href="http://www.jeckle.de" target="_blank">...</a> ),
replace ersetzt den aktuellen Fensterinhalt (entspricht damit der (X)HTML-Definition <a href="http://www.jeckle.de" target="_self">..</a> ),
embed ersetzt den Verweis durch den Inhalt der referenzierten Resource (entspricht damit der (X)HTML-Definition <img src="http://www.w3.org/Icons/w3c_home.gif" />),
other erlaubt die Definition beliebiger eigener Aktionen durch Markup.
none definiert, daß durch den Client keine Standardaktion bei Linkaktivierung auszuführen ist.
Die hier gegebenen Interpretationen der Aktionen sind stark an denen eines Web-Browsers orientiert, und können daher für andere Endgeräte beliebig variieren bzw. unter Umständen garnicht angeboten werden. actuate onLoad, onRequest, other, none onLoad bewirkt die automatische Aktivierung des XLinks, das Verhalten entspricht damit dem des (X)HTML-Elements img.
Wird onRequest spezifiziert, so kann der Verweis durch den Anwender interaktiv wahlfrei aktiviert werden. Das Verhalten entspricht hierbei den bekannten Hypertextlinks.
other definiert durch weiteres Markup spezifiziertes freies Verhalten, welches durch das Endgerät umgesetzt wird.
Bei none kann durch den interpretierenden Client eine im XML-Sinne proprietäre, d.h. nicht durch Markup spezifizierte, Verhaltensdefinition angegeben werden. label Jeder zulässige NCName. Definiert textuelle Identifikation des XLinks from Jeder zulässige NCName, der angegebene Wert muß dem eines existierenden label-Attributs entsprechen. Verweisquelle eines erweiterten XLinks to Jeder zulässige NCName, der angegebene Wert muß dem eines existierenden label-Attributs entsprechen. Verweisziel eines erweiterten XLinks

Je nach ihrer Belegung definierten die XLink-Attribute drei verschiedene Linktypen, die relativ zu einem Bezugsdokument benannt werden.
Verweist das href-Attribtut eines XLinks lediglich auf eine Ressource innerhalb des Bezugsdokuments, dann handelt es sich um einen Local Link. Wird auf eine anderes Dokument verwiesen, so spricht man von einem Outbound Link. Umgekehrt, d.h. im Falle eins externen Verweises auf das Bezugsdokument, so wird dieser als Inbound Link bezeichnet. Inbound und Outbound Links entsprechen sich daher, jeweils mit geändertem Bezugspunkt.
Abbildung stellt die Typen in der Übersicht zusammen.

Als besondere Form existiert mit dem Linktyp des External Links ein Verweistyp, der sich nicht in obiges Schema fügt. In seinem Falle wird der gesamte XLink in einer externen Ressource gehalten, die selbst nicht notwendigerweise in XML-Dokument sein muß.
Dieses externe Linkverzeichnis wird Link Base genannt, es ist typischerweise durch eine Datenbank umgesetzt.

Beispiel zeigt die Definitionen der einfachsten Form eines XLinks, den sog. simple Link. Benannt ist diese Darstellung nach dem Wert des type-Attributs.
Im Beispiel wird durch das Element myElementA ein Verweis definiert, dessen Verhalten den (X)HTML-Hyperlinks entspricht. Zunächst ist zur Identifikation der XLink-Attribute der durch die Spezifikation vorgegebene Namensraum http://www.w3.org/1999/xlink festzulegen; daher wird dieser an das Präfix xlink gebunden.
Die Definition als Vorgabenamensraum ist für diesen Anwendungsfall nicht möglich, da sich Namensräume vorgabegemäß nur auf Elemente auswirken.
Das Verweisziel wird in Form des href-Attributs (im XLink-Namensraum) angegeben.

Der transklutorischen (d.h. die referenzierte Ressource einbettenden und automatisch aktivierten) Graphik-Referenz des img-Elements aus (X)HTML entspricht folgendes Konstrukt:

Durch die zusätzlichen angebbaren Attribute läßt sich die Semantik eines Links spezifizieren. Dies stellt eine erste Erweiterung der Mächtigkeit gegenüber den bisher im Vergleich zu (X)HTML diskutierten Verweisen dar.
So erlaubt das title -Attribut die genauere Charakterisierung eines Links durch beliebigen anwenderdefinierten Freitext.
Am Beispiel der Projektverwaltung: Das nachfolgende Codefragment realisiert die Beziehung zwischen Projekt und seinen Mitarbeitern, die in einer anderen Datei abgespeichert sind, durch einen XLink.

Ein simpler XLink ist eine unidirektionale Verbindung zwischen zwei Ressourcen, wobei eine Ressource als Quelle und die andere als Ziel des Links interpretiert wird.

Während die simplen XLinks größtenteils in Analogie oder behutsamer Erweiterung zum entsprechenden (X)HTML-Konzept aufgebaut sind, führen die extended links bisher nicht realisierbare Möglichkeiten ein.
Wiederum am Beispiel der Projektverwaltung: Zwar läßt das vorhergehende Codefragment die Referenzierung der Projektmitarbeiter zu, jedoch kann innerhalb des Projekt-Elements kein weiterer XLink als Verweis auf die Projektleiter gesetzt werden, da sonst mehrfach dasselbe Attribut auftreten würde.
Das zugrundeliegende Problem, nämlich der Wunsch durch einen Link mehrere Ressourcen gebündelt referenzieren zu können, tritt in praktischen Anwendungen häufig auf. Beispielsweise beim Verweis auf mehrere Versionen eines Dokuments, alternativen Downloadservern oder Bildern verschiedener Auflösung.
Zu Realisierung erlaubt XLink die Bündelung von verschiedenen Verweisen zu einem einzigen erweiterten XLink. Nachfolgend ein Codeausschnitt, der dies für die Projektverwaltung zeigt.

Ein erweiterter XLink kann gleichzeitig auf mehr als eine Ressource verweisen.

Das Beispiel definiert einen dreigliedrigen extended link. Zur Realisierung ist zunächst das type-Attribut des die Einzellinks umschließenden Elements auf extended zu setzen. Im Rumpf dieses Elements folgen die als locator typisierten Verweise auf die verschiedenen Ressourcen. Die von den simple-Links bekannten XLink-Attribute href zur URI-basierten Referenzierung der Ressource, title zur natürlichsprachlichen Beschreibung des Verweises, sowie role zur Referenzierung einer beschreibenden Resource, können mit gleicher Semantik weiterverwendet werden. Zusätzlich nutzt das Beispiel die Möglichkeit der eindeutigen Identifikation der Verweisteile innerhalb des extended Links durch das label-Attribut.

Generell trifft das Konstrukt des erweiterten Links keine Vorgabe über mögliche Navigationsrichtungen zwischen allen im Rumpf des Linkelements aufgeführten Ressourcen.
Die Graphik stellt die referenzierten externen Ressourcen Meier, Huber und Müller als Rechteckte die durch den als Dreieck dargestellten erweiterten Link verbunden sind dar.
Es kann jedoch der Wunsch bestehen Beziehungen zwischen den durch einen erweiterten XLink verbundenen Ressourcen zu definieren. Hierfür gibt der Standard das arc-Attribut vor.

Zusätzlich zu diesem Attribut kann die Traversierungsrichtung des Links durch die Attribute from und to festgelegt werden. Die Graphik stellt diese Beziehungen als unterbrochene gerichtete Kanten dar.
Implizit kann daher die Existenz dieses Attribut-Tripels für simple XLinks angenommen werden.
Für das vorhergehende Beispiel ist die Navigationsdefinition dergestalt gewählt, daß eine Beziehung zwischen der Ressource Müller und Huber besteht. Diese Beziehung wird durch das Element befreundet_mit definiert. Zusätzlich etabliert das Element Bruder_von durch das arc-Attribut eine Beziehung zwischen Müller und Meier.

Das Beispiel verwendet zur Referenzierung der einzelnen Ressourcen das XLink-Attribut label.
Abschließend bleibt anzumerken, daß die arc-Typisierung lediglich die positive Definition explizit erlaubter Traversierungspfade erlaubt. Eine Einschränkung der Vorgabepfade ist nicht möglich.

Neben den bisher diskutierten Verweisen, bei denen es sich ausschließlich um Outbound Links handelte, läßt XLink auch die Auslagerung der Referenzierungen in eine sog. Link Database (kurz: Linkbase) zu. Ein solcher Datenspeicher enthält eine Menge von Zwei-Tupeln , welche Quelle und Ziel eines Verweises wiedergeben. Eine geeignete Applikation muß zur Realisierung der Verzeigerung immer eine Anfrage an diese Datenbank absetzen, und das Quell-Dokument unter Umständen geeignet aufbereiten, um dem Anwender die Möglichkeit zur Interaktion zu geben.
Das Schema der Abbildung stellt die beiden Verweismechanismen in der Zusammenschau dar. Im oberen Bereich ist ein inline link angedeutet, der im Quelldokument die zur Lokalisierung und Anzeige der referenzierten Ressource notwendigen Daten enthält. Im unteren Bereich ist das Konzept einer externen Linkdatenbank, die vor Anzeige des durch sie annotierten Quelldokuments zu konsultieren ist.

Für das Anwendungsszenario der externen Linkdatenbank stellt sich die Frage nach dem Aussehen der in der Datenbank abgespeicherten Zwei-Tupel. Während die Notation des Verweisziels durch die URI () vorgegeben ist, eröffnet sich die Frage nach der Lokalisierung des Verweises selbst innerhalb des Quelldokuments.
Unter Rückgriff auf (X)HTML ließen sich zwar durch die explizite Definition von Textankern (a-Element mit name-Attribut) beliebige Stellen als Aufsetzpunkt von extern verwalteten Verweisen definieren, jedoch würde dies erhebliche Modifikationen am Quelldokument nach sich ziehen, die bei Dokumentänderungen ihrerseits wiederum Wartungsarbeiten erfordern würden.
Idealerweise sollte das Quelldokument durch die Definition extern abgelegter Verweise nicht berührt werden. Im Falle eines freien Annotationsdienstes, der durch Dritte genutzt werden kann, stellt dies sogar eine Grundforderung dar.
Dieser Anwendungsfall bildet -- neben anderen -- ein Anwendungsszenario, welches eine Möglichkeit zur flexiblen Lokalisierung von Dokumentteilen erfordert. Hierfür wurde durch das W3C die im nachfolgenden Abschnitt vorgestellte XML Path Language verabschiedet.

XML Base

Um die Möglichkeiten der klassischen Hypertextverknüpfungen aus HTML auch für XML vollständig nachzubilden fehlt XLink in der Grundform die Unterstützung relativer Verweise.
Diese aus (X)HTML bekannte Kurzschreibweise dient zur Adressierung eines Teils einer durch URI identifizierten Ressource. In Hypertextdokumenten werden solche Verweise häufig zur direkten Navigation zu Teilkapitel oder Zwischenüberschriften verwendet.

Zur Realisierung müssen die Sprungziele im Dokument durch den Autor festgelegt werden. (X)HTML bietet hierfür das id-Attribut an. In Verbindung mit dem Anker-Element erlaubt es die freie Definition von Sprungzielen innerhalb beliebiger XHTML-Dokumente.
Syntaktisch kann dabei der durch das #-Symbol vom Ankernamen separierte Identifikator einer URI nachgestellt werden um auf ein Sprungziel innerhalb der durch die URI bezeichneten Ressource zu verweisen. Abkürzend kann -- durch Weglassung der URI -- auf Anker des aktuellen Dokuments verwiesen werden.

Das XHTML-Dokument des Beispiels zeigt die beiden Nutzungsvarianten relativer Verweise.
Die mit Zueignung, Vorspiel und Prolog benannten Anker adressieren die im Beispieldokument plazierten Ressourcen gleichen Namens (a-Elemente mit gesetztem id-Attribut).
Die übrigen Verweise (etwa Teil1.html#Nacht) nehmen Bezug auf benannte Ressourcen anderer Quellen (etwa innerhalb des Dokuments Teil1.html). Diese Quellen müssen zur Gewährleistung der Auflösbarkeit die notwendigen Anker-Elemente definieren.

Während innerhalb des (X)HTML-Dokuments relative Verweise durch die URI des umgebenden Dokumentes ergänzt werden können ist dies für XML-Dokumente im allgemeinen Falle nicht anzunehmen. Aus diesem Grunde definiert der W3C-Standard XML Base einen einfachen Mechanismus zur Nachbildung der in (X)HTML verwirklichten Mimik.

Zur Realisierung relativer Verweise definiert XML Base ein aus genau einem Attribut bestehendes XML-Vokabular. Dieses Attribut -- xml:base -- dient zur Aufnahme des URI-Anteils. Alle referenzierenden Informationselemente, beispielsweise href, die innerhalb des mit diesem Attribut versehenen Element oder innerhalb seiner Kindelemente auftreten werden relativ zur im xml:base-Attribut angegebenen URI interpretiert. Intuitiv wird diese dynamisch vor dem Fragmentidentifikator plaziert und mit ihm zu einer neuen URI konkateniert.
Dieser Vorgang kann auch über mehrere Stufen des XML-Dokumentbaumes vollzogen werden. Hierzu werden die Inhalte aller xml:base-Attribute die sich in hierarchisch übergeordneten Elementen des referenzierenden Knotens befinden zusammengefügt.

Das Beispiel der Abbildung formuliert den XHTML-Code des vorangegangenen Beispiels XML Base-konform um.
Daher wird zunächst der URI-Anteil der für alle Verweise gleichermaßen gilt auf einem hierarchisch höherstehenden gemeinsamen Element als Belegung des Attributs xml:base definiert. Im Beispiel wird daher die Basis-URI http://www.example.com/ im entsprechenden Attribut des Wurzelelements html plaziert.
Die Dokumentinternen Verweise (sie folgen auf den Text Inhaltsverzeichnis) ändern sich daher nicht. In diesem Falle expliziert xml:base lediglich die im XHTML durch seine physische Lokation implizit gegebene Information.
Für die Verweise des Dokumentes Akt1.html im Pfad Teil1 hingegen tritt eine Veränderung des durch href formulierten Verweises ein. Denn auch in diesem Falle kann der gemeinsame Anteil wieder in das XML-Basis-Attribut ausgelagert werden. In der Konsequenz ergibt sich die vollständige URI des Verweises Nacht wieder als http://www.example.com/Teil1/Akt1.html#Nacht, die durch Hierarchie-konforme Hintereinanderreichung der xml:base-Inhalte entsteht.
Für die Verweise in das Dokument Akt1.html im Pfad Teil2 gilt dasselbe. Auch hier wird die zu dereferenzierende URI durch Konkatenation der XML-Basis-Attribute gebildet.
Durch die Organisation dieses xml:base-Attributs auf derselben Hierarchieebene wie das zuvor diskutierte ergibt sich auch in diesem Anwendungsfalle die korrekte URI als http://www.example.com/Teil2/Akt1.html.

XLink Spezifikation XLink Implementierungen Fabio Arciniegas A.: XLink: An Introductory Example Fabio Arciniegas A.: What is XLink? XML Base Spezifikation Die Lokatorsprache XPath

Zur Extraktion beliebiger Teile eines wohl-geformten XML-Dokuments verabschiedete das W3C 1999 die Sprache XPath. Sie bildet eine pfadorientierte Lokatorsprache, die das Auffinden von Dokumentteilen (einzelnen Elementen, Attributen, etc.) durch Pfadausdrücke, die sich an der Struktur des XML-Dokuments orientieren, gestattet.
Die Grenze zwischen Lokatorsprache und echter Anfragesprache wie SQL sind fließend. Zwei Unterscheidungsmerkmale sollen jedoch hervorgehoben werden: XPath wird im üblichen Anwendungsfall nicht interaktiv oder in eine Programmiersprache als Wirtssprache eingebettet verwendet, sondern wurde (zunächst) nur für die Nutzung in Kombination mit der Transformationssprache XSLT und den erweiterten Verweisen der Sprache XPointer konzipiert. Zum zweiten fehlt XPath die üblicherweise mit dem reinen Anfrageteil verwobene Manipulationssprache zur Änderung bereits bestehender Daten; XPath ist allein für den lesenden Zugriff auf XML-Dokumente ausgelegt.
Hinweis: XPath unterscheidet XML-üblich zwischen Groß- und Kleinschreibung. Daher sind Element- und Attributnamen unbedingt in der im Dokument gewählten Schreibweise anzugeben.

Lokalisierungspfade:
Lokalisierungspfade dienen der abstrakten Beschreibung einer Menge von Informationsknoten innerhalb eines Dokuments.
Die einfachste Form eines Lokalisierungspfades beschreibt der Wurzellokalisierungpfad (root location path), ausgedrückt durch /. Er liefert für jedes XML-Dokument den Wurzelknoten. Dieser ist nicht identisch mit dem Wurzelelement eines XML-Dokuments! Der (unbenannte) Wurzelknoten entspricht dem Document Information Item des Information Sets, während das erste benannte Element des Dokuments durch ein Element Information Item dargestellt wird.

Die Navigation zu den einzelnen Elementknoten, oder Knotenmengen, wird durch einen Pfadausdruck realisiert. Die explizite Variante erlaubt die Angabe aller zu traversierenden Knoten bis hin zu den zu extrahierenden. Hierzu werden die Knoten, von der Wurzel absteigend durch /-Symbole separiert, notiert. Wegen der Korrespondenz der voneinander abgetrennten Knotennamen und den Baumstufen, werden diese auch als Lokalisierungsschritte bezeichnet. Als weitere sprachliche Analoge spiegelt der XPath-Ausdruck, von links nach rechts gelesen, auch die Schritte -- ausgehend vom Wurzelelement des Dokuments -- zur Lokalisierung der gesuchten Knotenmenge wieder.
Das Beispiel zeigt eine solche Definition am Beispiel der Projektverwaltung.
Anmerkung: Das Resultat ist in XML-Notation dargestellt, obwohl genaugenommen eine Knotenmenge des Information Sets als Resultat zurückgeliefert wird. Die gewählte XML-Darstellung ist hierbei nur eine der möglichen Varianten zur Ergebnispräsentation.

XPath-Ausdruck: /ProjektVerwaltung/Person/Vorname
Ergebnis: <Vorname>Hans</Vorname>, <Vorname>Franz</Vorname>, <Vorname>Xaver</Vorname>, <Vorname>Fritz</Vorname>

Die Einzelknoten werden entsprechend ihrer Auftrittsreihenfolge im Quelldokument (sog. document order) zurückgegeben.

Die expliziten Pfadausdrücke lassen sich in beliebiger Länge fortsetzen, jedoch zeigen sie fundamentale Schwächen in Puncto Flexibilität. Wie im Beispiel der XHTML-Verwendung innerhalb eines eigenen XML-Dokuments gesehen, kann Information desselben Typs (d.h. umschlossen durch denselben Tag) verschiedene Elternknoten besitzen. So im Beispiel, dort ist die Qualifikation auf derselben Baumstufe sowohl unterhalb des Elternelements em als auch u anzutreffen.
Als Lösung erlaubt XPath die Nutzung von Platzhaltern statt der expliziten Elementnamen innerhalb eines Lokalisierungsschrittes. In der Folge entstehen freie Lokalisierungsschritte, die alle Kindknoten einer im direkt vorhergehenden Lokalisierungsschritt selektierten Knotenmenge adressieren.
Der nachfolgende XPath-Ausdruck zeigt dies am Beispiel des Qualifikationsprofils.

XPath-Ausdruck: /ProjektVerwaltung/Person/Qualifikationsprofil/*/Qualifikation
Ergebnis: <Qualifikation>Programmierung</Qualifikation> <Qualifikation>Projektleiterfunktion</Qualifikation>

Der Pfadausdruck liefert die beiden Kindelemente Qualifikation -- unabhängig von der Benennung des Elternknotens -- die direkt unterhalb des Knotens Qualifikationsprofil angeordnet sind.
Allerdings enthält die Ausgabe nicht alle Knoten des Typs Qualifikation. Der gegebene Pfadausdruck gestattet lediglich das Überspringen einer Hierarchieebene. Daher wird der hierarchisch tieferstehende Qualifikations-Knoten mit Inhalt Entwickler nicht lokalisiert. Die (zunächst naheliegende) Lösung den Pfadausdruck zu /ProjektVerwaltung/Person/Qualifikationsprofil/*/*/Qualifikation zu erweitern liefert nicht das gewünschte Resultat aller Qualifikations-Knoten, sondern ausschließlich den zuvor nicht lokalisierbaren, da der modifizierte Ausdruck nun zwingend zwei freie Lokalisierungsschritte vorsieht.
Zur Variierung der Tiefe der freien Schritte sieht XPath die Schreibweise // vor. Sie erlaubt die Lokalisierung der Kindknoten auf einer beliebigen Hierarchiestufe.

Ein Lokalisierungsschritt setzt sich aus dem Namen der Achse gefolgt von zwei Doppelpunkten und einem Knotentest, optional ergänzt um ein auszuwertendes Prädikat, zusammen.
Wird keine Achse spezifiziert, so gilt vorgabegemäß die Achse child.
Ein Knotentest ist syntaktisch ein QName, der genau dann erfüllt ist, wenn der Knotenname mit dem Namen des Knotentests übereinstimmt.
Das Prädikat filtert die Ergebnismenge hinsichtlich verschiedener Charakteristika wie Existenz von Kindknoten oder Attributen, Position in der Ergebnismenge, etc.

Das Beispiel zeigt die korrekte XPath-Formulierung zur Lokation aller Qualifikations-Knoten:

XPath-Ausdruck: /ProjektVerwaltung/Person/Qualifikationsprofil//Qualifikation
Ergebnis: <Qualifikation>Programmierung</Qualifikation>
<Qualifikation>Entwickler</Qualifikation>
<Qualifikation>Projektleiterfunktion</Qualifikation>

Durch die abkürzende Schreibweise // entsteht ein Muster zur Selektion aller nachfolgenden Knoten. In Verallgemeinerung dieses Konzepts bietet XPath sog. Achsen an, um relativ zum aktuellen Knoten beliebige Teilbäume zu lokalisieren.
Die Abbildung zeigt die verschiedenen durch Achsen zugänglichen Knotenmengen relativ zum rot hervorgehobenen aktuellen Knoten.

Download der XML-Datei mit dem Beispiel der Graphik

Achse Semantik Im Beispiel selektierte Knoten Graphik self Lokalisiert den aktuellen Knoten
Als abkürzende Schreibweise kann der Punkt . verwendet werden. XPath-Ausdruck:
/node1/node3/node8/self::node8
Ergebnisknotenmenge: {8} child Lokalisiert die (direkten) Kindknoten des aktuellen Knotens XPath-Ausdruck:
/node1/node3/node8/child::*
Ergebnisknotenmenge: {12, 13, 14} descendant Lokalisiert transitiv alle Kindknoten des aktuellen Knotens, außer Attribut- und Namensraumknoten XPath-Ausdruck:
/node1/node3/node8/descendant::*
Ergebnisknotenmenge: {12, 13, 14, 15, 16} descendant-or-self Lokalisiert transitiv alle Kindknoten des aktuellen Knotens (außer Attribut- und Namensraumknoten), sowie den Knoten selbst XPath-Ausdruck:
/node1/node3/node8/descendant-or-self::*
Ergebnisknotenmenge: {8, 12, 13, 14, 15, 16} parent Lokalisiert den Elternknoten des aktuellen Knotes, falls existent XPath-Ausdruck:
/node1/node3/node8/parent::*
Ergebnisknotenmenge: {3} ancestor Lokalisiert transitiv alle Elternknoten des aktuellen Knotes.
Die ancestor-Achse enthält daher immer den Wurzelknoten, außer der aktuelle Knoten ist es selbst; in diesem Falle liefert die Achse die leere Menge XPath-Ausdruck:
/node1/node3/node8/ancestor::*
Ergebnisknotenmenge: {1, 3} ancestor-or-self Lokalisiert transitiv alle Elternknoten des aktuellen Knotes, sowie den aktuellen Knoten.
Diese Achse enthält immer den Wurzelknoten des Dokuments. XPath-Ausdruck:
/node1/node3/node8/ancestor-or-self::*
Ergebnisknotenmenge: {1, 3, 8} preceding Lokalisiert alle dem aktuellen Knoten vorausgehenden Knoten, ohne seine Vorfahren sowie Attribut- und Namensraumknoten XPath-Ausdruck:
/node1/node3/node8/preceding::*
Ergebnisknotenmenge: {2, 5, 6, 7} preceding-sibling Lokalisiert die im Dokument vor dem aktuellen Knoten auftretenden Geschwisterknoten XPath-Ausdruck:
/node1/node3/node8/preceding-sibling::*
Ergebnisknotenmenge: {7} following Lokalisiert alle dem aktuellen Knoten nachfolgenden Knoten ohne dessen Kind-, Attribut und Namensraumknoten XPath-Ausdruck:
/node1/node3/node8/following::*
Ergebnisknotenmenge: {9, 4, 10, 11} following-sibling Lokalisiert alle Geschwister des aktuellen Knotens, d.h. Knoten auf derselben Hierarchieebene. XPath-Ausdruck:
/node1/node3/node8/following-sibling::*
Ergebnisknotenmenge: {9} attribute Lokalisiert Attribut(e) eines Knotens XPath-Ausdruck:
/node1/node3/node8/attribute::*
Ergebnisknotenmenge: {Att1} namespace Lokalisiert Namensraum-Attribut eines Knotens XPath-Ausdruck:
/node1/node3/node8/namespace::*
Ergebnisknotenmenge:
{xmlns:xml="http://www.w3.org/XML/1998/namespace",
xmlns:x="namespace:www.jeckle.de/vorlesung/xml"}

Anmerkung:
Die Achsen ancestor, descendant, following, preceding und self partitionieren ein Dokument (unter Auslassung der Attribut- und Namensraumknoten): sie überschneiden sich nicht und enthalten alle Elementknoten des Dokuments.

Filterung durch Prädikate:
Ein -- durch eckige Klammern abgegrenztes -- Prädikat kann innerhalb jedes Lokalisierungsschrittes eines XPath-Ausdrucks angegeben werden. Fehlt es, wird die bisher ermittelte Knotenmenge nicht modifiziert.
Das Prädikat kann selbst ein gültiger XPath-Ausdruck sein.
Das prinzipielle Vorgehen kann folgendermaßen beschrieben werden:
Beginnend von links nach rechts für jeden Lokalisierungsschritt: (1) Ermittlung der zur Anfrage passenden Knotenmenge
(2) Reduzierung der Ergebnismenge um diejenigen Knoten, für die das Prädikat false liefert.
Befinden sich rechts vom aktuell bearbeiteten Lokalisierungsschritt weitere Ausdrücke, so wird die Resultatmenge als Eingabe eines weiteren Schritts (1) übergeben.

XPath-Ausdruck: //Person[Qualifikationsprofil]/Nachname
Ergebnis:
<Nachname>Obermüller</Nachname>

Der Ausdruck selektiert an beliebiger Stelle des Dokuments (//) alle Knoten des Typs Person. Die Knotenmenge wird um diejenigen Personen vermindert, zu denen kein Qualifikationsprofil angelegt ist. D.h. Es werden nur diejenigen Knoten selektiert, die über einen Kindknoten des Typs Qualifikationsprofil verfügen. Von dieser Knotenmenge (des Typs Person!) werden anschließend im zweiten Lokalisierungsschritt die Kindknoten des Typs Nachname selektiert.
Mithin liefert der XPath-Ausdruck alle Nachnamen von Personen, zu denen ein Qualifikationsprofil abgelegt ist.
Anmerkung: Das Beispiel nutzt im Prädikat die abkürzende Schreibweise zur Angabe der Vorgabeachse child. Die ausführliche Schreibweise -- mit unveränderter Semantik -- des XPath-Ausdruckes lautet daher: //Person[child::Qualifikationsprofil]/Nachname

Durch die zusätzliche Definition eines Prädikats für den zweiten Lokalisierungsschritt kann eine weitere Filterung der Ergebnismenge realisiert werden. Zusätzlich können innerhalb eines Prädikats neben XPath-Ausdrücken auch einige vordefinierte Funktionen verwendet werden.
Das Beispiel zeigt die Selektion der Vornamen als Kind eines Personen-Knotens (Test der Elternschaft durch erstes Prädikat), wenn dieser mit O beginnt (Test durch starts-with -Funktion innerhalb des zweiten Prädikats). Die Struktur der Eingabedatei zwingt zusätzlich zur Anwendung der following-Achse, da Knoten des Typs Nachname in der Dokumentreihenfolge nach Knoten des Types Vornamen auftreten.

XPath-Ausdruck: //Person[parent::ProjektVerwaltung]/Vorname[starts-with(following::Nachname,'O')]

Ausgewerteter XPath: //Person
Ergebnis:
<Person PersID="Pers01" mitarbeitInProjekt="Prj01"> ... </Person>
<Person PersID="Pers02" mitarbeitInProjekt="Prj02"> ... </Person>
<Person PersID="Pers03" mitarbeitInProjekt="Prj02"> ... </Person>

Ausgewerteter XPath: //Person[parent::ProjektVerwaltung]
Ergebnis:
<Person PersID="Pers01" mitarbeitInProjekt="Prj01"> ... </Person>
<Person PersID="Pers02" mitarbeitInProjekt="Prj02"> ... </Person>
<Person PersID="Pers03" mitarbeitInProjekt="Prj02"> ... </Person>

Ausgewerteter XPath: //Person[parent::ProjektVerwaltung]/Vorname
Ergebnis:
<Vorname>Hans</Vorname>
<Vorname>Franz</Vorname>
<Vorname>Xaver</Vorname>
<Vorname>Fritz</Vorname>

Ausgewerteter XPath: //Person[parent::ProjektVerwaltung]/Vorname[following::Nachname]
Ergebnis:
<Vorname>Hans</Vorname>
<Vorname>Franz</Vorname>
<Vorname>Xaver</Vorname>
<Vorname>Fritz</Vorname>

Ausgewerteter XPath:
//Person[parent::ProjektVerwaltung]/Vorname[starts-with(following::Nachname,'O')]
Ergebnis:
<Vorname>Franz</Vorname>
<Vorname>Xaver</Vorname>

Die durch die XPath-Spezifikation vordefinierten Funktionen lauten in der Übersicht:

Funktionsprototyp Funktionalität number last() Liefert die Größe der aktuellen Knotenmenge; damit den Index des letzten Elements number position() Liefert die Position des aktuellen Knotens innerhalb der Knotenmenge.
Die erste Knoten trägt die Positionsnummer 1. number count(node-set) Liefert Elementzahl der übergebenen Knotenmenge node-set id(object) Liefert denjenigen Knoten, dessen ID-typisiertes Attribut den Argumentwert aufweist.
Anmerkung: Zur Nutzung dieser Funktion muß zwingend eine Dokument-Grammatik (DTD oder Schema) zum Eingangsdokument vorliegen. string local-name (node-set?) Liefert den local name (oder die Menge der Namen) der übergebenen Knotenmenge. Wird keine Knotenmenge übergeben, dann wird der aktuelle Knoten als Argument genutzt. string namespace-uri (node-set?) Liefert die Namensraum-URI der übergebenen Knotenmenge. Wird keine Knotenmenge übergeben, dann wird der aktuelle Knoten als Argument genutzt.
Anmerkung: Handelt es sich nicht um einen Element- oder Attributknoten, so ist die retournierte Zeichenkette leer. string name (node-set?) Liefert die QName(n) (=qualifizierte(r) Name(n) aus Namensraumkürzel und local name) der übergebenen Knotenmenge, oder des aktuellen Knotens bei leerer Knotenmenge.
Anmerkung: Nur für Element- und Attributknoten liefert name andere Resultate als local-name. Funktionsprototyp Funktionalität string string (object)? Liefert Zeichenkettenrepräsentation einer Knotenmenge.
Dabei wird der Zeichenkettenwert des ersten Knotens in der Dokumentreihenfolge zurückgegeben, andernfalls die leere Zeichenkette. string concat (string, string, string*) Verkettet mindestens zwei Zeichenketten. boolean starts-with (string1, string2) Liefert true falls string1 das zweite Argument string2 als Präfix enthält; andernfalls false boolean contains (string1, string2) Liefert true falls string1 die Zeichenkette aus string2 enthält; andernfalls false. string substring-before (string1, string2) Liefert denjenigen Teil der Zeichenkette string1, der sich vor dem ersten Auftreten der Zeichenkette string2 befindet. string substring-after (string1, string2) Liefert denjenigen Teil der Zeichenkette string1, der sich nach dem ersten Auftreten der Zeichenkette string2 befindet. string substring (string, number1, number2?) Liefert eine Zeichenkette der Länge number2 aus string, beginnend mit der Position number1.
Fehlt das dritte Argument, so wird der Teilstring bis zum Ende der Zeichenkette string zurückgegeben.
Anmerkung: Das erste Zeichen trägt die Indexnummer 1, nicht 0 wie in Java und C üblich. number string-length(string?) Liefert die Länge der übergebenen Zeichenkette.
Wird kein Argument übergeben, so wird die Länge des zuvor in eine Zeichenkette konvertierten aktuellen Knotens zurückgegeben. string normalize-space (string?) Liefert die übergebene Zeichenkette unter Entfernung führender, schließender und mehrfacher Leerzeichen zurück. Ferner werden noch evtl. in der Argumentzeichenkette enthaltenen Entitätsreferenzen aufgelöst.
Anmerkung: Der Normalisierungsvorgang entspricht damit der Attributwertenormalisierung nach Abschnitt 3.3.3 der XML-Spezifikation. string translate (string1, string2, string3) Liefert die Zeichenkette string1 wobei jedes Zeichen aus string2 durch das Zeichen an derselben Position aus string3 ersetzt wurde. Funktionsprototyp Funktionalität boolean boolean (object) Liefert die Boole'sche Repräsentation des übergebenen Arguments.
Hierbei gilt:
Eine Zahl wird genau dann nach true konvertiert, wenn sie weder Null (unbeachtlich ihres Vorzeichens) noch eine nicht darstellbare Zahl (NaN) ist.
Eine Knotenmenge ergibt true, wenn sie nicht leer ist.
Eine Zeichenkette ergibt true, wenn sie nicht leer (d.h. Länge größer Null) ist.
Die Konvertierung anderer Typen ist typabhängig, und nicht durch den Standard festgelegt boolean not (boolean) Negiert das übergebene Argument boolean true() Liefert statisch den Wert true boolean false() Liefert statisch den Wert false boolean lang (string) Liefert true wenn der aktuelle Knoten ein xml:lang-Attribut gemäß der als Argument übergebenen Sprache besitzt Funktionsprototyp Funktionalität number number (object?) Konvertiert ein Objekt in eine Zahl gemäß folgender Regeln:
Eine Zeichenkette wird in eine Fließkommazahl gemäß IEEE 754 konvertiert, wenn sie aus einem optionalen Leerzeichen, gefolgt durch ein optionales Minuszeichen, gefolgt von einem optionalen Leerzeichen und einer Ziffernfolge besteht.
Der Boole'sche Wert true wird zu 1, der Wert false zu 0 konvertiert.
Eine Knotenmenge wird zunächst in eine Zeichenkette übersetzt, und dann gemäß der oben definierten Regeln umgesetzt.
Die Konvertierung anderer Typen erfolgt typabhängig, und ist nicht durch den Standard geregelt.
Wird kein Argument übergeben, so wird stattdessen der aktuelle Knoten als einziges Element einer Knotenmenge interpretiert. number sum (node-set) Liefert die Summe aller Elemente der übergebenen Knotenmenge, die zuvor in eine Zahl konvertiert werden. number floor (number) Liefert die größte ganze Zahl, die nicht größer als das Argument ist.
Anmerkung: Entspricht dem Abschneiden beliebiger Nachkommastellen number ceiling (number1) Liefert die kleinste ganze Zahl, die nicht kleiner als das Argument ist.
Anmerkung: Entspricht floor(number1+0.999...) number round (number) Liefert das Argument auf die nächste ganze Zahl gerundet.
Gibt es zwei solche -- wie bei Nachkommastelle gleich 0.5 immer der Fall -- so wird die größere zurückgeliefert.

Für mathematische Berechnungen auf zahlenartigen Knoten stehen folgende Operatoren zur Verfügung.

Operator Funktionalität + Addition - Subtraktion als zweistelliger Operator.
Der einstellige Operator - ist nicht spezifiziert, er liefert üblicherweise die negative Zahlendarstellung. * Multiplikation.
Außer wenn innerhalb von XPath-Ausdrücken als Knotentest eingesetzt. div Division
Achtung: Das Symbol / dient ausschließlich als Trennzeichen zur Separierung von Lokalisierungspfaden! mod Rest einer ganzzahligen Division

Ein umfangreiches Beispiel: Für das nachfolgende Beispiel wird das Projektverwaltungsdokument erweitert zu:

Der XPath-Ausdruck der Abbildung lokalisiert den Attributknoten des Inhalts Prj02.

Welches Ergebnis liefern folgende XPath-Ausdrücke?
(a) //Person[//child::Qualifikationsprofil]/Nachname
(b) //Person[parent::ProjektVerwaltung]/Vorname[following-sibling::Vorname]
(c) /ProjektVerwaltung/Person[attribute::PersID='Pers01']//Nachname

Wie muß ein XPath-Ausdruck lauten, um folgendes zu selektieren?
(d) Selektion aller Personen mit Nachnamen Obermüller.
(e) Selektion aller Nachnamen von Personen die über mehr als eine Qualifikation verfügen.
(f) Selektion der Nachnamen aller Projektleiter.
 Anwendungsbeispiel: Integritätsbedingungen in XML-Schema

Die bei der Diskussion des Referenzierungsmechanismus für DTDs geäußerte Kritik gilt prinzipiell auch für die Verwendung von XML-Schema fort. Zwar steht mit XLink ein deutlich flexiblerer Verknüpfungsmechanismus zur Verfügung, jedoch verbleibt das Problem der Gültigkeit von Referenzen. Sie bleibt auch bei der Verwendung von XML-Schema, durch die unverändert von den DTDs übernommene Semantik der Datentypen ID und IDREF, IDREFS, auf das aktuelle Dokument beschränkt. Zusätzlich ist eine Einschränkung, etwa auf den aktuellen Namensraum, nicht möglich. Daher müssen alle Belegungen aller ID-typisierten Attribute zwingend dokumentweit eindeutig sein.

Über die Möglichkeiten der Datentypen hinausgehend bietet XML-Schema das Element unique zur Definition eindeutiger Wertbelegungen an. Hierbei wird auf die Lokatorsprache XPath zurückgegriffen um die abzuprüfenden Knoten innerhalb des Dokuments zu bezeichnen.

Die Syntax verwendet XPath-Ausdrücke eingeschränkter Mächtigkeit sowohl zur Festlegung des der Knotenmenge, auf die sich die Einschränkung bezieht (selector), als auch zur Angabe der eingeschränkten Knoten (field) selbst.

Die Mächtigkeit der XPath-Ausdrücke ist dahingehend eingeschränkt, daß für das selector-Element ausschließlich Ausdrücke erlaubt sind, die Kindelemente des Knotens liefern, in dessen Kontext die durch unique formulierte Einschränkung angegeben wird. Als Konsequenz ist die Nutzung der verfügbaren XPath-Achsen auf diejenigen beschränkt, die Element-Knotenmengen zurückliefern.
Die Lokationsausdrücke in den -- möglicherweise mehrfach auftretenden -- field-Elementen werden relativ zum Pfad des selector-Knotens interpretiert. Hintereinandergesetzt muß der Pfad eines selector-Elements, gefolgt von einem Pfad eines field-Elements, einen gültigen Lokationsausdruck ergeben, der genau einen Knoten oder genau ein Attribut in der Ergebnismenge liefert. Sind mehrere field-Elemente zu einem selector-Element gegeben, so werden diese als durch logisches und verknüpft interpretiert. Mithin entspricht diese Semantik einem concatenated primary key aus den relationalen Datenbanken.

Das Beispiel zeigt die Nutzung des unique-Konstrukts zur Angabe der Eindeutigkeitsbedingung für das Attribut PersID des Elements Person.
Zunächst selektiert der Pfad /Person alle Knoten des gleichnamigen Typs; durch das field-Element wird die Eindeutigkeitsbedingung auf alle Attribut-Kindnoten des Typs PersID der Knoten in der selektierten Knotenmenge angewendet.
Die Semantik ist damit zur bisherigen ID-Typisierung identisch.

Das nächste Beispiel zeigt die Verwendung mehrerer field-Elemente zur Realisierung zusammengesetzter Schlüssel.
Hierzu wird die Kombination aus dem Inhalt des Nachnamen- und des Vornamen-Elements zusammen als eindeutig deklariert.
Überdies zeigt das Beispiel die Anwendung des Schlüsselmechanismus auf Elemente ohne Änderung der Basissyntax, abgesehen von der geänderten XPath-Achse.

Das Pendant des IDREF(S)-Attributtyps bildet die Kombination der XSD-Elemente key und keyref.
Hierzu lokalisiert key auf der Basis eines XPath-Ausdruckes eine Referenzmenge, während keyref diejenige Knotenmenge lokalisiert, in der ausschließlich Elemente der Referenzmenge enthalten sein dürfen.
Das Beispiel zeigt die Anwendung auf das Element ProjektVerwaltung. Der mit projectKey benannte Schlüssel definiert die Referenzmenge als das Ergebnis der Anfrage Projekt/@ID, worauf die projectReference Bezug nimmt.

Zusammenfassend lassen sich folgende Vorteile gegenüber dem ID/IDREF-Mechanismus festhalten:

  • Neben Attributen können auch Elemente und ihre Inhalte Beschränkungen unterworfen werden.
  • Typisierung des Elements oder Attributs nicht mehr berührt.
    Trennung zwischen Inhaltsmodell und Eindeutigkeitsbedingung erlaubt Beschränkung beliebig typisierter Elemente und Attribute.
  • Eindeutigkeitsbeschränkungen sind auf Gültigkeitsbereich des definierenden Elements beschränkt.
  • Zusammengesetzte Schlüssel möglich.
  • Schlüsselbestandteile müssen im XML-Dokument zwingend mit Werten (ungleich nil) belegt sein.
  • Gleichheitsvergleich erfolgt typbasiert.
XPath Spezifikation Deutsche Übersetzung der XPath-Spezifikation XPath Visualisierer (Java-basiert) Visual XPath (.NET Windows-Applikation)
Originalbezugsquelle XPath Explorer (Java-basiert)
Originalbezugsquelle Online Experimentieren mit XPath Transformation von XML-Dokumenten: XSL Transformations

Die prominenteste Verwendung der XPath-Pfadausdrücke und eine der in jüngerer Zeit am weitesten beachteten XML-Vokabulare dürfte XSLT -- die Sprache der XSL Transformations -- sein. Sie wurde im Verlauf der Standardisierung der Stylesheetsprache XSL von dieser abgetrennt und seither durch eine eigene W3C-Arbeitsgruppe vorangetrieben.
In einem Satz zusammengefaßt stellt sie eine Turing-vollständige funktionale Programmiersprache zur Transformation wohlgeformter XML-Dokumente in beliebige Unicode-Streams -- und damit im speziellen wiederum in XML-Dokumente -- dar.
Der Begriff Transformationen bezeichnet hierbei die Selektion einzelner Bestandteile des Quelldokuments, deren Umordnung sowie die Ableitung neuer Inhalte aus den bereits bestehenden.
Derzeit aktuell ist die Recommendation zur Version 1.0 von Herbst 1999. Intern arbeitet das W3C bereits an der Nachfolgerversion XSLT v2.0, welche auch die absehbaren Entwicklungen des Umfeldes, wie XPath v2.0 oder XML-Schema, berücksichtigen wird.

Jedes XSLT-Stylesheet ist ein gültiges XML-Dokument, in dem alle Elemente der Sprache XSLT im Namensraum http://www.w3.org/1999/XSL/Transform plaziert sind.
Üblicherweise wird der Namensraum an das Präfix xsl gebunden, welches allen XSLT-Sprachelementen explizit vorangestellt wird.
Das Wuzelelement eines XSLT-Dokuments bildet der Knoten stylesheet. Alternativ kann auch transform angegeben werden. Zusätzlich verfügt jedes Stylesheet über ein Versionsattribut zur Bezeichnung der verwendeten XSLT-Version.
Das Beispiel zeigt ein minimales Stylesheet

Angewendet auf das Beispieldokument der Projektverwaltung liefert es folgende Ausgabe:

Dies mag zunächst verwundern, definiert doch das Beispiel-Stylesheet keinerlei Transformationsregeln oder Ausgabefunktionen.
Das Ergebnis des minimal-Beispiels wird durch die eingebauten Vorgaberegeln erzeugt. Diese geben, sofern nicht anders angegeben alle Character Information Items unverändert aus.
Durch Überschreiben dieser Vorgaben und die Definition eigener Regeln lassen sich komplexe Transformationen auf dem Eingabedokument verwirklichen.

Transformationsschablonen

Die Graphik zeigt den Aufbau einer Transformationsschablone. Ihre beiden Hauptbestandteile sind der Lokalisierungspfad und das Ersetzungsmuster.
Der Lokalisierungspfad (in der Spezifikation als pattern bezeichnet) liefert eine Knotenmenge. Als Syntax wird eine eingeschränkte Variante der Lokatorsprache XPath verwendet.
Augenfälligster Unterschied zur bisherigen Notation ist die Optionalität der descendant-Achse (zumeist zu // verkürzt) zur hierarchiebenenunabhängigen Lokalisierung eines Knotens.
Im Rumpf des Musters legt das Ersetzungsmuster diejenige Zeichenfolge fest, die statt jedem Element der lokalisierten Knotenmenge ausgegeben werden soll.
Das nachfolgende Transformationssheet liefert angewandt auf das Projektverwaltungsbeispiel dreimal die Ausgabe Person gefunden!; für jedes Auftreten des Knotens Person in der Eingabe.

Innerhalb des Ersetzungsmusters können im Allgemeinen beliebige Textsequenzen angegeben werden. Insbesondere ist die Verwendung wohlgeformter XML-Fragmente zugelassen.
Textsequenzen werden hierbei durch direktes Anschreiben, oder umschlossen durch das Element xsl:text definiert.
Anmerkung: Die Anforderungen an die Wohlgeformtheit sind hierbei auf die korrekte Terminierung der Elemente (damit einhergehend ihre korrekte Schachtelung), sowie die Quotierung der Attribute beschränkt.
Im folgenden Beispiel wird jedes Element des Typs Person durch ein leeres Mitarbeiter-Element ersetzt.
Das Beispiel erklärt auch die übliche Anwendungspraxis, alle XSLT-Elemente durch Namensraumpräfix zu qualifizieren, statt der -- weniger schreibaufwendigen -- Überschreibung des Vorgabenamensraumes. Würde der Vorgabenamensraum mit der Namensraum-URI der XSL-Transformations belegt, so befände sich auch jedes XML-Element und -Attribut innerhalb des Ersetzungsmusters in diesem Namensraum. Als Konsequenz würde der XSLT-Prozessor die Transformation wegen des Auftretens ungültiger (d.h. nicht in der XSLT-Sprache enthaltener) Elemente ablehnen. Bei Redefinition des Vorgabenamensraumes müßte daher für alle Elemente, die nicht Bestandteil von XSLT sind, eine explizite Namensraumdefinition im Element erfolgen, wodurch die Lesbarkeit stark herabgesetzt würde.

Erwartungsgemäß liefert das Beispiel dreifach das leere Element Mitarbeiter anstelle der Personen-Elemente der Eingabe.
Die bisher genutzte Form der Ersetzung ist jedoch für die praktische Anwendung in nur äußerst wenigen Fällen geeignet, da sie keine Übernahme von Daten der Eingabedatei in die Ausgabe erlaubt.
Dieses Manko wird durch das XSLT-Sprachelement value-of behoben.

Das Element value-of übernimmt als Teil des Ersetzungsmusters frei selektierbare Text-artige Informationsknoten aus dem Quelldokument. Die Lokalisierung der zu übernehmenden Knoten erfolgt durch XPath-Syntax innerhalb des select-Attributs.
Im folgenden Beispiel wird der Inhalt der Personen-Knoten in den neuen Knotentyp Mitarbeiter übernommen.

Das Resultat liefert jedoch nicht das Quelldokument, unter Umbenennung der Personen-Knoten in Mitarbeiter, sondern die dargestellte Textsequenz.

Die Lösung liegt in der Definition des value-of-Elements. Es konvertiert alle durch den im select-Attribut bezeichneten XPath lokalisierten Knoten in ihre Textrepräsentation. Im vorliegenden Beispiel ist dies der Inhalt der Knoten des Typs Person, der durch den Elementinhalt gebildet wird. Der Elementinhalt wird hierbei durch alle Kindknoten und deren Attribute gebildet.

Zur unveränderten Übernahme eines vollständigen Elements einschließlich der Auszeichnungssymbole wird das XSLT-Element copy-of angeboten.
Das nachfolgende Beispiel modifiziert das vorhergend diskutierte Stylesheet dergestalt, daß für alle Personen-Knoten zunächst ein öffnender Mitarbeiter-Tag gesetzt wird. Im Rumpf des so begonnenen Elements werden durch das copy-of-Element alle Kindknoten der aktuellen Knotenmenge unverändert kopiert.
Als zusätzliche Veränderung gegenüber dem vorigen Beispiel fällt die Nutzung der child-Achse im select-Attribut des copy-of-Elements auf. Dies ist notwendig, da durch den Lokalisierungspfad der Schablone alle Personen-Knoten zu einer Ergebnisknotenmenge zusammengefaßt werden. Die Anwendung der self-Achse innerhalb des copy-of-Elements würde daher auch die Personen-Knoten selbst übernehmen.
Zusammenfassend läßt sich die Funktionalität des Beispiels mit Umbenennung aller Elemente des Types Person in Mitarbeiter wiedergeben.

Die vorgestellte Transformationsvorschrift ist hinreichend flexibel für Knoten des Typs Person auf beliebiger Hierarchiestufe des Eingabedokuments. Jedoch versagt sie bereits beim Versuch einen weiteren Transformationsschritt einzubauen, der auf einem der unverändert kopierten Kindelemente von Person operiert.
Das folgende Stylesheet stellt einen flexibleren Ansatz zur Umbenennung von einzelnen Knoten vor.

Gegenüber der vorhergehenden Fassung ist der Umfang um zwei weitere template-Elemente erweitert. Eines, das für alle Qualifikationsprofil-Knoten angewendet wird und eines für alle anderen Knoten. Der dort eingesetzte Lokalisierungspfad liefert als Ergebnismenge die Vereinigung aller Attributknoten (attribute::*) mit allen Knoten außer dem Wurzelknoten (node()-Funktion). Im Rumpf des Elements wird das copy-Element zur Kopie jedes Elements verwendet. Anders als das bisher herangezogene copy-of-Element übernimmt diese Variante ausschließlich das aktuelle Element in das Ergebnisdokument und läßt eventuell vorhandene Kindelemente unberücksichtigt.
Das template-Element mit dem Lokalisierungspfad Qualifikationsprofil verfügt über kein Ersetzungsmuster. Es bewirkt damit die Unterdrückung des Teilbaumes unterhalb aller Knoten des Typs Qualifikationsprofil.

Die korrekte Anwendung der verschiedenen Schablonen wird durch den ausführenden XSLT-Prozessor gewährleistet, er ermittelt anhand der Lokalisierungspfade das best-passendste Template und bringt es zur Ausführung. Wenn, wie im vorliegenden Beispiel, mehrere Pfadausdrücke einen Knoten des Eingabedokuments lokalisieren, so wird das am weitesten spezifizierte Muster ausgewählt. Im untenstehenden Beispiel gilt dies für alle Elemente des Typs Person. Jeder dieser Knoten ist sowohl durch den XPath-Ausdruck der ersten Schablone als auch durch den allgemeineren Ausdruck node() zugänglich. Der explizite Pfad Person des ersten Lokalisierungsmusters ist jedoch gegenüber der Ergebnismenge der node-Funktion (deutlich) spezifischer.

Da jeder Knoten, außer denen des Typs Person und Qualifikationsprofil, unverändert in den Ausgabestrom übernommen werden soll, wird im Beispiel wieder ein copy-Element eingesetzt. Im Unterschied zum bisher verwendeten copy-of jedoch mit der Einschränkung, daß copy nur den aktuellen Knoten kopiert und eventuell existierende Kindknoten unberücksichtigt läßt. Dieser Vorgang wird auch als shallow copy bezeichnet.

Steuerung der Transformationsreihenfolge durch apply-templates-Elemente

Standardmäßig durchläuft ein XSLT-Prozessor den aus dem Eingabedokument erzeugten Baum ausgehend vom Wurzelknoten in Preorder Reihenfolge. Während des Traversierungsvorganges werden die zum jeweiligen Knoten passenden Schablonen ausgewertet. Passend deutet hierbei auf das Enthaltensein des besuchten Knotens in der Ergebnismenge eines XPath-Ausdrucks innerhalb eines match-Attributes hin.
Jedoch ist auch die anwenderdefinierte Beeinflussung der vorgegebenen Abarbeitungsreihenfolge möglich. Hierzu enthält das Beispiel zwei apply-templates-Elemente. Diese lösen einen Rekursionsschritt aus, dergestalt, daß an jeder Stelle, an der sich ein apply-templates-Aufruf findet, der Prozessor versucht, weitere passende Schablonen anhand der angegebenen Lokalisierungspfade zu ermitteln. Diese können an der gegebenen Stelle ausgewertet werden. Der Vorgang entspricht damit der Substitution in funktionalen Programmiersprachen.
Im vorliegenden Fall wird nach Ausgabe des öffnenden Tags Mitarbeiter -- nachdem ein Personen-Knoten im Eingabedokument ermittelt wurde -- nach weiteren Knoten im Eingabedokument gesucht, zu denen Lokalisierungspfade in der XSLT-Transformationsvorschrift existieren. Dies ist für alle Attribute und Kindknoten von Person der Fall, da sie durch den Lokalisierungspfad attribute::*|node() zugänglich sind. So wird innerhalb des neu erzeugten Elements Mitarbeiter des Ausgabestroms das Ersetzungsmuster ausgeführt, das die Elemente und Attribute mit ihren Inhalten unverändert übernimmt.
Als Besonderheit nutzt das apply-templates-Element im allgemeinen (dritten) template das Attribut select. Es erlaubt die anwenderdefinierte Steuerung der Menge, innerhalb der nach weiteren passenden Lokalisierungspfaden gesucht werden soll. Standardmäßig ist diese Menge mit allen dem aktuellen Element nachfolgenden (following-Achse) Elementknoten gefüllt. Im vorliegenden Beispiel wird sie durch den XPath des Attributwertes um alle Attributknoten erweitert.

Lassen Sie sich mit von einem XSLT-Prozessor die Aufrufreihenfolge der einzelnen Templates ausgeben.
Beispielsweise mit dem Prozessor Xalan aus dem Apache-Projekt. Benannte Ersetzungsschablonen und Parameterübergabe

Neben den Lokationspfad-gesteuerten Schablonen kann der Anwender auch benannte Schablonen, ohne match-Attribut, definieren. Diese werden während der Abarbeitung des Eingabebaumes nicht berücksichtigt, sondern müssen manuell durch call-template aufgerufen werden.
Konzeptionell entsprechen sie Funktionsaufrufen herkömmlicher Programmiersprachen.
(In Spezifikation nachschlagen).
Die Definition erfolgt analog den bisher genutzten Schablonen, mit der Ausnahme, daß statt dem match-Attribut ein eindeutiger Name (Attribute name) angegeben wird.

Als neuer Freiheitsgrad beim nun notwendigen manuellen Aufruf tritt die Möglichkeit der Parameterübergabe hinzu. Als Parameter können beliebige Dokumentbestandteile als Knotenmenge, Ergebnisse von Funktionsausdrücken oder Konstanten übergeben werden.
Eine Parameterrückgabe ist nicht möglich, sie wird durch den Anteil der Schablone an der Ausgabe realisiert.
Die Aufrufsyntax lautet:

Anmerkung: Wie in allen funktionalen Sprachen kommt den Funktionen dieses Typs besondere Bedeutung, als Ausgangspunkt rekursiver Aufrufe, zu.

Die Vorgabe-Transformationsregeln

Das einführende Beispiel dieses Kapitels griff bereits auf die in den XSLT-Prozessor eingebauten Standard-Transformationsvorschriften (built-in templates) zurück.
So lautet die Definition, welche für alle Text- und Attributknoten der Eingabe den Inhalt in die Ausgabe kopiert:

Ferner existiert ein template zur rekursiven Abarbeitung des Eingabebaumes, welches immer dann Anwendung findet, wenn sich keine spezialisiertere Transformationsvorschrift findet.

Ergänzt wird diese Zusammenstellung durch eine Schablone zur Eliminierung von Namensraum- und Kommentarknoten.

Elemente der Ablaufsteuerung

Ähnlich zu herkömmlichen Programmiersprachen bietet auch XSLT Sprachmittel zur Selektion und bedingten Verarbeitung, abhängig von den Eingabedaten.
So erlaubt das if-Element die Bearbeitung der umschlossenen Elemente nur, wenn die im test-Attribut formulierte Boole'sche Bedingung wahr ist.
(In Spezifikation nachschlagen)
Die Syntax lautet:

 <xsl:if test="Boole'scher Ausdruck">   <!-- Content: template --> </xsl:if>

Das Beispiel zeigt die Nutzung des if-Elements. Verfügt ein Knoten des Typs Person über mehr als einen Kindknoten des Typs Vorname so wird der Inhalt des if-Elements abgearbeitet, der durch das XSLT-Element message während des Transformationsvorganges eine Bildschirmausgabe erzeugt.
Diese gibt zunächst den Inhalt des Nachnamen Knotens gefolgt von einem statischen Text aus.
Angewandt auf das Beispieldokument liefert es auf Kommandozeile die Ausgabe: Obermüller hat mehr als einen Vornamen!. Der Inhalt des Eingabedokuments wird unverändert kopiert.

In Erweiterung der simplen Selektion bildet choose die Möglichkeiten einer Mehrfachselektion, oder einer simplen if-then-else-Struktur ab.
(In Spezifikation nachschlagen)
Die Syntax lautet:

Das Beispiel zeigt die Transformation des Beispieldokuments in eine XHTML-Ausgabe.
Hierbei wird zunächst der XHTML-Dokumentrahmen bei Auftreten des Dokumentknotens (Suchmuster /) erzeugt. Nach dem öffnenden XHTML-Rumpfelement body werden innerhalb des Quelldokuments wahlfrei weitere, auf eines der angegebenen Suchmuster passende, Knoten gesucht (apply-templates-Aufruf).
Bei Auftreten des Knotens ProjektVerwaltung wird -- nach einigen Überschriftszeilen -- der Kopf einer XHTML-Tabelle, bestehend aus den Elementen table und der Kopfzeile (eingeschlossen durch tr), erzeugt. Den Rumpf der Tabelle schreibt ein anderes Template. Dieses wird jedoch nicht direkt aufgerufen, sondern der Prozeß der Ermittlung neuer passender Knoten neu initiiert; jedoch diesmal, durch das select-Attribut des apply-templates-Elements, nur auf Knoten des Typs Person beschränkt.
Die Ersetzungsregel für Person speichert zunächst den Inhalt des Attributs PersID in einer Variable. Anschließend werden die Tabellenelemente der in der Ersetzungsregel für ProjektVerwaltung geöffneten Tabelle geschrieben. Hierzu werden nacheinander die Ersetzungsmuster für Knoten des Typs Vorname bzw. Nachname, die Kindknoten des aktuellen Knotens sind (die PersID des aktuellen Personen-Knotens findet sich in der zuvor belegten Variable), aktiviert.
Ein zweites Tabellenelement enthält einen XHTML-Hyperlink zu den durch den Mitarbeiter bearbeiteten Projekten. Als Sprungziel wird hierbei der Inhalt des Attributs mitarbeitInProjekt eingetragen.
Das Ersetzungsmuster Vorname übernimmt durch value-of die in einen Zeichenkettenwert gewandelten Inhalte des Elements. Zusätzlich existiert ein zweites Ersetzungsmuster für Knoten des Typs Vorname, das jedoch durch ein Prädikat nur auf das zweite und alle folgenden Elemente dieses Typs angewendet wird. Es gibt vor der Übernahme des Elementinhaltes ein Leerzeichen aus.
Das Element Nachname bettet den Elementinhalt in eine benannte Sprungreferenz ein. Zur Erzeugung der dokumentweiten eindeutigen Benennung wird die Funktion generate-id herangezogen, die für jedes Element des Information Sets des Eingabedokuments einen eindeutigen Bezeichner liefert.
Nach Abschluß der Tabellengenerierung im durch den Lokalisierungspfad ProjektVerwaltung gekennzeichneten Template werden durch den Aufruf des benannten Ersetzungsmusters wasteSpace 25 Leerzeilen, jeweils gefüllt mit der Zeichenkette ..., erzeugt. Als Besonderheit ist in diesem Muster sehr deutlich die Nutzung der Rekursion zur Modellierung einer Schleife zu sehen.
Zum Abschluß wird nochmals eine Tabelle, nun mit den Mitarbeitern und ihren Projekten, erzeugt.

Die nachfolgende XSLT-Transformation ermittelt zu jedem beliebigen Element- und Attributknoten (Muster: * bzw. @*) die zugehörige Namensraum-URI (Funktion namespace-uri ) und gibt sie gemeinsam mit dem Namen des Knotens (Funktion name ) in einer XML-formatierten Ausgabe aus.
Zur Neuselektion aller weiteren Element- und Attributknoten wird apply-templates mit dem Musterausdruck @*|node() ausgeführt, um in die Prüfung nach weiteren passenden Knoten (node()) auch explizit alle beliebigen Attribute (@*) einzubeziehen. Standardmäßig ermittelt apply-templates weitere passende Knoten nur innerhalb der Elemente eines Dokuments.

XSLT v1.0 Spezifikation XSLT @ jeckle.de Holman, K. G.: What is XSLT? Saxon -- ein freier XSLT-Prozessor Apache Xalan -- ein Open Source XSLT-Prozessor Literatur zum Thema Schreiben Sie eine XSLT-Transformation, die es erlaubt die Elementstruktur beliebiger wohlgeformter XML-Dokumente in Form eines ASCII-Baums (siehe Beispiel) am Bildschirm auszugeben.
Beispiel:
Eingabe:
Ausgabe:
Erzeugung von Präsentationssichten: XML Stylesheets

Mit XML können zwar beliebige Inhalte durch eigene Vokabulare ausgedrückt werden, jedoch bleibt die Präsentationssicht -- zumeist -- unberücksichtigt.
Lediglich für die standardisierte XML HyperText Markup Language (XHTML) ist eine Präsentationssicht eindeutig durch die Semantik der Sprachelemente definiert. Für alle anderen XML-Sprachen gibt es eine solche zunächst nicht, auch wenn einzelne Browser und Anzeigewerkzeuge eine zumeist baumartig orientierte graphische Ansicht bieten.

Zur Erzeugung einer Ansicht eines XML-Dokuments definiert das W3C derzeit die Extensible Stylesheet Language (XSL), eine XML-Sprache zur Formulierung beliebiger Präsentationssichten auf XML-Dokumente.
Dieser Ansatz verfolgt die Linie, Präsentationsinformation und Inhaltsinformation nicht in einem Dokument zu mischen, sondern beide Informationsarten physisch getrennt zu verwalten. Intuitiv wird der Vorzug dieser Idee klar; so können auf denselben Inhalt verschiedene Präsentationssichten angewendet werden, ebenso erlaubt die Abkopplung der Darstellungsinformation deren Wiederverwendung für verschiedenste Inhalte.

Der Gedanke der Trennung von Darstellung und inhaltlicher Information wurde bereits in späteren HTML-Versionen (ab 1996) durch die Cascading Style Sheets (CSS) realisiert. Sie sind, als Ergänzung der HTML, in einer proprietären (d.h. nicht XML) Syntax realisiert um einerseits die Layoutmöglichkeiten von HTML zu erweitern, und zusätzlich wiederkehrende Präsentationsinformation an einem zentralen Ort ablegen zu können.

Konzeptionell teilt sich die XML Stylesheet Language in zwei Bereiche: Eine Transformationssprache und ein XML-Vokabular zur Darstellung von medienunabhängigen Formatierungsanweisungen (formatting objects).
Per Anwendungsszenario sind die beiden Teile eng verknüpft. Die durch XSL definierten Formatierungsobjekte sind ohne Nutzdaten (die zu formatierende Information) weitestgehend nutzlos; die notwendigen Nutzdaten müssen naturgemäß auch als XML-Dokument vorliegen. Die Anreicherung der Nutzdaten um XML-formulierte Formatierungsobjekte reduziert sich somit auf eine Transformation der XML-Nutzdaten in ein XML-Dokument, das neben den (evtl. modifizierten) Nutzdaten auch Formatierungsobjekte enthält.
Wegen ihrer allgemeinen Einsetzbarkeit wurde die Transformationssprache im Laufe des Standardisierungsprozesses vom Formatierungsvokabular abgetrennt, und seither als eigenständiger Standard ( XSL Transformations ) weiterentwickelt, der im folgenden Kapitel betrachtet wird.
Dieses Kapitel beschränkt sich daher ausschließlich auf die Betrachtung der XSL formatting objects.

Die Abbildung faßt die beiden prinzipiellen Anwendungsszenarien zusammen. Im oberen Teilbild ist die Nutzung von XSL in Verbindung mit einem Dokument einer beliebigen XML-Sprache dargestellt. Als Resultat erzeugt der Browser-interne XSL-Prozessor eine XHTML-Repräsentation, die direkt zur Anzeige gebracht wird. Dieses Szenario wird im direkt anschließenden Kapitel vertieft.
Die untere Bildhälfte zeigt einige der Möglichkeiten der formatting objects für beliebige Zielrepräsentationen, beispielsweise Adobes portable document format (PDF) oder LaTeX. Der in den eingesetzten Prozessor integrierte Transformationsteil erzeugt zunächst die Baumrepräsentation der Zielstruktur, die anschließend zusätzlich durch den XSL formatter in das gewünschte physische Format umgesetzt wird. Diese Komponente übernimmt hierbei die Funktion einer rendering engine.

Für XSL-FO existiert keinerlei direkte Browserunterstützung. Dies erklärt sich einerseits in der Komplexität der Spezifikation, deren Umfang die üblichen Darstellungsmöglichkeiten gängiger Web-Browser bei weitem übersteigt und andererseits in dem Hauptanwendungsgebiet des Vokabulars: der (rechnerunabhängigen) Publikation von Texten. Konzeptionell orientiert sich XSL-FO daher eher am klassischem Buchdruck, als an den Cascading Style Sheets.

Geprägt durch das Anwendungsfeld arbeitet XSL-FO generell seitenorientiert. Daher werden die darzustellenden Inhalte gemäß anwenderdefinierter Vorgaben auf die erzeugten Seiten verteilt. Hierzu werden die verschiedenen graphischen Inhalte durch Bereiche (areas) umschlossen.
Die Abbildung zeigt die vier verschiedenen Grundtypen und ihr Verhältnis zueinander.

Ein Bereich kann entweder block- oder inline-Bereiche enthalten, jedoch nicht beide gleichzeitig. Block-Bereiche stellen die allgemeinste Variante der Inhaltsdarstellung zur Verfügung. Sie definieren einen rechteckigen durch Ränder umschlossenen Bereich zur Aufnahme von Textelementen wie: Absätzen, Überschriften oder Bildunterschriften (in XSL-Spezifikation nachschlagen).
Inline-Bereiche können zur graphischen Hervorhebung der umschlossenen Textbereiche, beispielsweise durch Farbunterlegung, verwendet werden. (in XSL-Spezifikation nachschlagen).
Als Spezialisierung der Block-Bereiche erlauben Line-Bereiche die Darstellung von Texten ohne umgebende Ränder.
Die feinste Darstellungsgranularität offerieren die Glyph-Bereiche, welche genau einen Buchstaben oder ein Zeichen kapseln.

Die nachfolgende Abbildung zeigt einen Bereich, mit einer Anzahl möglicher Attribute, zur Steuerung seiner Positions- und Abstandseigenschaften.
Der mit content rectangle bezeichnete Bereich nimmt die Nutzdaten (einzelner Buchstabe, einzelne Zeile oder mehrzeiliger Text) auf.
Direkt umschließend folgen padding- und border-Bereich.
Durch die Dimensionen von padding kann eine genaue Positionierung des Rahmenbereichs (border) erreicht werden. Optional kann der Rahmenbereich gefüllt oder die Rahmenlinie in verschiedensten Varianten angezeigt werden.
Die space-area definiert einzuhaltende nichtbedruckbare Abstandsflächen zum nächstliegenden plazierten Bereich. Hierdurch lassen sich zu enge Positionierungen oder gar Überschneidungen Verhindern.

Struktur eines XSL-FO-Dokuments: Spezifikationsgemäß befinden sich alle Elemente und Attribute eines XSL-FO-Dokuments im Namensraum http://www.w3.org/1999/XSL/Format.
Das Wurzelelement jedes XSL-FO-Dokuments bildet das Element root, es umschließt die einzelnen Definitionen und zu formatierenden Nutzdaten.
Die Spezifikation legt weiter fest, daß im root-Element zwingend die Kindknoten layout-master-set und page-sequence anzugeben sind.
Hierbei enthält das Element layout-master-set eine Art Schablone aller Seiten der zu erzeugenden Ausgabe. Innerhalb dieses Elements werden die Seitenmaße festgelegt, sowie weitere wiederkehrende Regionen dimensioniert. Die nachfolgende Abbildung zeigt diese im Überblick.

Innerhalb des zweiten zwingend als Kindelement von root zu spezifizierenden Elements page-sequence werden die einzelnen zu plazierenden Bereiche definiert. Das Element page-sequence nimmt eine Reihe von Seiten auf, beispielsweise ein Kapitel. Die graphische Aufbereitung der Seite wird durch einen page-master oder einen page-sequence-master, der durch das master-name-Attribut referenziert wird, festgelegt. (Informationen zur page-sequence in der XSL-Spezifikation)
Die darzustellenden Inhalte (Text, Tabellen, Graphik, etc.) werden durch flow-Elemente umschlossen. Innerhalb eines flow-Elements sind die verschiedenen Inhaltselemente plaziert.
Das Beispiel zeigt ein erstes formatting objects-Dokument. Der page-master definiert eine DIN A4 Seite mit den bekannten Abmessungen. Ferner wird die Größe des Kopfzeilenbereichs (region-before) auf mindestens (extent-Attribut) 3 cm festgelegt. Dergleichen geschieht für den Fußzeilenbereich (region-after).
Innerhalb der page-sequence, welche die im Seiten-Master festgelegten Dimensionscharakteristika übernimmt (das master-name-Attribut enthält die Identifikation des page-masters), wird innerhalb eines flow-Elements ein Text-block definiert.
Der zentriert gesetzte Text (text-align="center") wird in einer serifenlosen Schrifttype (font-family="sans-serif") der Größe 12 Punkt (font-size="12pt") gesetzt. Zusätzlich wird eine Zeilenhöhe von 15 Punkten (line-height="15pt") mit einem zusätzlichen Abstand von 3 Punkten (space-after="3pt") zum nächst folgenden Element festgelegt.
Als Inhalt des block-Elements ist der darzustellende Text plaziert.

<?xml version="1.0" encoding="utf-8"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:layout-master-set> <fo:simple-page-master master-name="simple" page-height="29.7cm" page-width="21cm" margin-top="1cm" margin-bottom="2cm" margin-left="2.5cm" margin-right="2.5cm"> <fo:region-body margin-top="3cm"/> <fo:region-before extent="3cm"/> <fo:region-after extent="1.5cm"/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-name="simple"> <fo:flow flow-name="xsl-region-body"> <fo:block font-size="12pt" font-family="sans-serif" line-height="15pt" space-after="3pt" text-align="center"> Hello World - mein erstes XSL-FO-Dokument! </fo:block> </fo:flow> </fo:page-sequence> </fo:root>

Textfluß und Objektplazierung
Zur Unterstützung der Erzeugung von Dokumenten mit geänderter Leserichtung, wie im nahen Osten und arabischen Sprachraum üblich, erlaubt XSL-FO ihre explizite Definition durch das Element writing-mode.
Darüberhinaus kann dieses Element auch die Anordnungsreihenfolge der einzelnen Symbole steuern, auf diesem Wege lassen sich auch asiatische Texte -- von oben nach unten -- erzeugen.
Die gültigen Belegungen des writing-modes lauten:

  • lr-tb: Von links nach rechts, darin von oben nach unten
    Vorgabebelegung und übliches westliches Anordnungsschema
  • rl-tb: Von rechts nach links, darin von oben nach unten
  • tb-rl: Von oben nach unten, darin von rechts nach links (Japanisch)
  • lr: Nur von links nach rechts; keine weitere Angabe
  • rl: Nur von rechts nach links; keine weitere Angabe
  • tb: Nur von oben nach unten; keine weitere Angabe

Die drei letzten Belegungen übernehmen den fehlenden Wert von ihrem direkt umgebenden Element.
Die nachfolgende Abbildung zeigt Beispiele der Anwendung des writing-mode-Elements (zum writing-mode in der XSL-Spezifikation nachschlagen).
Man beachte die geänderten Plazierungen der edges! So wird im hebräischen Dokument -- gemäß der getauschten Lesrichtung der Zeilen -- auch die dem Block folgende end-edge links ans Ende(!) des Absatzes verschoben. Dasselbe gilt spiegelsymmetrisch für die start-edge.
Im japanischen Dokument wird die Positionen der start- und after-edge ebenfalls verschoben, um wieder die bekannte Semantik (start-edge geht in Lesrichtung dem Block voraus, after-edge folgt ihm) zu erhalten.

Erzeugung von Tabellen
Tabellen werden als blockartige Objekte innerhalb eines flow-Bereichs definiert. Sie stellen ein eigenes Element dar und bedürfen daher keiner Kapselung durch ein block-Element.
Der prinzipiell Aufbau lautet:

 <table>
   <table-column>...</table-column>
   <!-- weitere table-column-Elemente; für jede Tabellenspalte -->
   <table-body>
      <table-row>
         <table-cell>...</table-cell>
         <!-- weitere Tabelleneinträge -->
      </table-row>
   </table-body>
</table>

table-column legt spaltenspezifische Charakteristika für alle Tabellenzellen der Spalte fest. Hierzu zählt beispielsweise die im angegebenen Code verwende Spaltenbreite; definiert durch das Attribut column-width.
Innerhalb jeder Tabellenzelle stehen wieder alle block-Elemente (Textblöcke, Listen, Tabellen) zur Verfügung.
Das Beispiel nutzt ferner die beiden Attribute border-width und border-style zur Definition der Rahmenlinienstärke bzw. ihres Aussehens.

<?xml version="1.0" encoding="utf-8"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:layout-master-set> <fo:simple-page-master master-name="myMaster" page-height="29.7cm" page-width="21cm" margin-top="1cm" margin-bottom="2cm" margin-left="2.5cm" margin-right="2.5cm"> <fo:region-body margin-top="3cm"/> <fo:region-before extent="3cm"/> <fo:region-after extent="1.5cm"/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-name="myMaster"> <fo:flow flow-name="xsl-region-body"> <fo:block font-size="16pt" font-family="sans-serif" space-after.optimum="15pt" text-align="center"> Eine Tabelle ... </fo:block> <fo:table> <fo:table-column column-width="50mm"/> <fo:table-column column-width="50mm"/> <fo:table-column column-width="50mm"/> <fo:table-body> <fo:table-row> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x11</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x12</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x13</fo:block></fo:table-cell> </fo:table-row> <fo:table-row> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x21</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x22</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x23</fo:block></fo:table-cell> </fo:table-row> <fo:table-row> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x31</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x32</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x33</fo:block></fo:table-cell> </fo:table-row> <fo:table-row> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x41</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x42</fo:block></fo:table-cell> <fo:table-cell border-width="0.5mm" border-style="solid"><fo:block>x43</fo:block></fo:table-cell> </fo:table-row> </fo:table-body> </fo:table> </fo:flow> </fo:page-sequence> </fo:root>

Einbindung von Graphiken
XSL-FO erlaubt die Einbindung von Graphiken in beliebigen Formaten; die Unterstützung konkreter Formate ist jedoch von der gewählten rendering engine abhängig.
Das nachfolgende Beispiel zeigt die Einbindung einer GIF-Graphik durch das Element external-graphic welches über eine URI die physische Lokation der einzubindenden Bilddatei angibt (in XSL-Spezifikation nachschlagen).
Ferner zeigt das Beispiel die Nutzung des inline-Elements um innerhalb eines Blockes Formatierungsinformation (im Beispiel auf Wortebene) anzubringen.

<?xml version="1.0" encoding="utf-8"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:layout-master-set> <fo:simple-page-master master-name="simple" page-height="29.7cm" page-width="21cm" margin-top="1cm" margin-bottom="2cm" margin-left="2.5cm" margin-right="2.5cm"> <fo:region-body margin-top="3cm"/> <fo:region-before extent="3cm"/> <fo:region-after extent="1.5cm"/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-name="simple"> <fo:flow flow-name="xsl-region-body"> <fo:block font-size="12pt" font-family="Helvetica" line-height="15pt" space-after="3pt" text-align="center"> Text <fo:inline text-decoration="underline">vor</fo:inline> der Graphik ... </fo:block> <fo:block text-align="center"> <fo:external-graphic src="file:sblumen.jpg"/> </fo:block> <fo:block font-size="12pt" font-family="Times" line-height="15pt" space-after="3pt" text-align="center"> Vincent van Gogh: <fo:inline font-style="italic">Sonnenblumen</fo:inline> </fo:block> </fo:flow> </fo:page-sequence> </fo:root>

XSL-FO offenbart sich als mächtiger und flexibler Mechanismus zur Erzeugung auch komplexer Dokumente mithilfe eines XML-Vokabulars. Jedoch zeigen die vorgestellten Beispiele, daß sich die Erstellung der notwendigen XSL-FO-Eingabedokumente mitunter sehr aufwendig gestaltet. Aus diesem Grunde haben sich XML-Sprachen wie das bekannte DocBook entwickelt, durch die diese Komplexität nochmals gekapselt wird. Zusätzlich zu einem vom Schriftsatz abstrahierten Vokabular zur Erzeugung von beliebigen Dokumenten enthält DocBook auch eine Reihe von Transformationsbeschreibungen zur automatisierten Ableitung der XSL-FO-Dokumente. So operiert der DocBook-Verwender mit den Primitiven Kapitel, Überschrift oder Bildunterschrift, die dann durch eine XSLT-Datei nach XSL-FO zur Weiterverarbeitung übersetzt werden.

Extensible Stylesheet Language (XSL) @ W3C Apache FOP -- eine freie XSL-FO-Implementierung XEP -- eine kommerzielle XSL-FO-Implementierung XSL-FO Tutorial @ RenderX Eisenberg, D. J.: Using XSL Formatting Objects, Part 1 Eisenberg, D. J.: Using XSL Formatting Objects, Part 2 XSL-FO Referenz @ Zvon.org DocBook Hintergrundinformation zu DocBook XSL @ Coverpages Anfragesprachen

Mit der Sprache XPath wurde im Abschnitt 2.2 ein mächtiger Ansatz zur Lokalisierung beliebiger Knotenmengen innerhalb von XML-Dokumenten vorstellt. Konzeptionell stellt XPath eine durch Pfadausdrücke navigierende Sprache dar. Neben den Vorteilen, insbesondere der vergleichsweise einfachen Formulierung kleiner Anfragen, treten jedoch einige bemerkenswerte Nachteile zu Tage:

  1. Das Ergebnis ist immer eine Element- oder Attributmenge,
    die Konstruktion neuer Ergebnistypen ist nicht möglich.
  2. Dem Anwender muß die Struktur des Eingabedokuments bekannt sein.
  3. Anfragen nach derselben Information müssen für strukturell verschiedene Eingaben i.A. unterschiedlich formuliert werden.
  4. Entstehende Pfadausdrücke gewinnen schnell an Komplexität und damit Unübersichtlichkeit.

Aus diesen Gründen wurden im Laufe der XML-Entwicklung einige Anfragesprachen vorgeschlagen, welche diese Beschränkungen nicht aufweisen. Sammelbecken der verschiedensten Ideen zur Definition einer eigenständigen Anfragesprache für XML-Dokumente war der Tandberg XML Query Workshop 1998. Zahlreiche Hersteller, Forschungsinstitute und Hochschulen legten in Positionspapieren ihre Ideen zur Thematik dar. Hierbei reichte das Spektrum von halbseitigen Anforderungsdefinitionen (eher Wunschzetteln) bis hin zu ausgearbeiteten Sprachvorschlägen (wie XQL). Verständlichermaßen handelte es sich bei den meisten beitragenden Firmen um (bekannte) Hersteller von Datenbankmanagementsystemen, welche eine Anfragesprache für XML als natürliche Erweiterung ihrer (inzwischen durch XML angereicherten) universellen Systeme sehen.
Prinzipiell kann jedoch eine XML-Anfragekomponente auf beliebigen XML-Eingaben, also auch auf reinen Dokumenten, operieren.

Anders als die in der XPath-Recommendation definierten Pfadausdrücke legen die vorgeschlagenen Anfragesprachen keine navigierenden Zugriffe zugrunde, sondern orientieren sich an den klassischen deskriptiven Anfragesprachen wie SQL.
Durch die unerwartet große Resonanz des Tandberg-Workshops motiviert initiierte das W3C die XML Query Working Group und beauftragte diese mit der Erarbeitung eines Sprachstandards, der mittlerweile als XQuery in einem ersten Arbeitsstand ( working draft ) vorliegt.
Nachfolgend soll diesem zukünftigen Sprachstandard die Hauptaufmerksamkeit gewidmet werden. Betrachtungen anderer Anfragesprachen finden nur insofern statt, wie sie für das Verständnis von XQuery notwendig und dienlich sind.

Neben der Behebung der erwähnten Nachteile einer Pfad-basierten Anfrage wurden folgende Anforderungen an XQuery definiert:

  • Abgeschlossenheit.
    Jede XQuery-Anfrage liefert als Ergebnis ein XML-Dokument das im Bedarfsfalle als Grundlage neuer Anfragen herangezogen werden kann.
  • Kombinierbarkeit von Funktionen.
    Durch die Anfragesprache angebotene Funktionen sind ohne Einschränkung miteinander kombinierbar.
  • Seiteneffektfreiheit.
    Eine XQuery-Anfrage darf keine Seiteneffekte auf nicht in der Anfrage spezifizierte Datenbereiche aufweisen.
  • Strenge Typisierung.
    Das Schema des XML-Ergebnisdokuments ist zur Anfrageanlysezeit ermittelbar.
  • Schemaberücksichtigung.
    Operation auf allen Datentypen, die durch XML-Schema definiert werden.
  • Relationale Vollständigkeit.
    Für jede durch einen Konstruktor erzeugbare Struktur existiert eine Zerlegungsmöglichkeit.

Die Abbildung stellt die Vorläufer, Entwicklungen und Einflüsse, die in die W3C-Initiative mündeten, dar.
Konzeptionell stellt sich XQuery, als deklarative Sprache und auch syntaktisch, in die Tradition der in den relationalen Datenbanken implementierten Sprache SQL; genaugenommen deren Anfrageteil der bekannten SELECT ... FROM ... WHERE ...-Struktur.
Die Berücksichtigung von SQL geht auf den Sprachvorschlag XML-QL zurück. Neben der Deklarativität weist XQuery eine funktionale Struktur auf, welche die beliebige Kombination von Teilausdrücken zu einer Anfrage erlaubt. Hierfür stand der ODMG-Sprachstandard OQL zur Anfrage auf objektorientierte Datenbanken Pate. Auch er hat sich als deklarative Anfragesprache aus SQL heraus entwickelt.
XQL markiert eine alternative Entwicklungslinie zur Formulierung der XML-Anfragesprache, sie entwickelt im wesentlichen die Pfadausdrücke der XPath-Syntax fort. Damit greift XQL frühere Entwicklungen aus dem Umfeld semi-strukturierter Datenverwaltung -- wie Lorel oder UnQL -- auf.
Beide Sprachstämme, sowie experimentelle Prototypen wie YATL, flossen in den Sprachvorschlag Quilt ein, der durch die W3C-Arbeitsgruppe zu XQuery weiterentwickelt wird.

Nicht zuletzt wegen der besseren Optimierbarkeit algebraisch fundierter Ausdrücke ist XQuery im Stile SQLs als deskriptive Anfragesprache realisiert. Dieser Sprachtyp definiert Bedingungen, denen ein gültiges Ergebnis genügen muß, läßt jedoch die Realisierung der Anfrageverarbeitung durch das System vollkommen offen. Hierunter sind insbesondere Auswertungsreihenfolge, Zugriffspfade und optimierende Techniken wie Indexstrukturen, etc. zu verstehen.
Die Abbildung zeigt (angeleht an K. Dittrich) das Prinzip deskriptiver Anfragen. Gelb dargestellt ist die Menge der möglichen XML-Dokumentinstanzen. Diese werden durch das zugrundeliegende Schema bestimmt. In der Praxis existiert eine -- rot symbolisierte -- Untermenge tatsächlich verwalteter Dokumente, die konform zum Schema formuliert sind.
Jede Anfrage (grünes Rechteck) beschreibt eine zweite Untermenge der gültigen Dokumentinstanzen. Anschaulich handelt es sich hierbei um diejenigen Dokumente, die die in der Anfrage formulierten Bedingungen erfüllen.
Innerhalb der Schnittmenge aus existierenden Dokumenten und prinzipiell passenden Dokumentinstanzen befindet sich das Anfrageergebnis. Mithin diejenigen verwalteten Daten, die den Anfragebedingungen genügen.
Da die Menge der durch die Anfrage beschriebenen Dokumentinstanzen leer sein kann -- dies ist bei a priori unmöglichen Anfragen (etwa: Zeige alle Dokumente, deren Element mit dem Namen X gleichzeitig Y heißt) der Fall -- muß sich nicht zwingend eine (nichtleere) Ergebnismenge ergeben. Die tatsächlich existierenden Dokumentinstanzen bilden lediglich bei Anfrageausführung auf XML-Dokumenten eine nichtleere Menge, da leere XML-Dokumente gemäß den Anforderungen an die Wohlgeformtheit nicht zulässig sind. Im Falle der Anfrageauswertung gegen die Inhalte einer XML-Datenbank -- XQuery spricht hierbei von virtuellen Dokumenten -- kann auch diese Eingangsmenge (bei unbefüllter Datenbank) leer sein.

Syntax einer XQuery-Anweisung:
Die Struktur einer XQuery Anweisung wird durch die FLWR- (sprich flower) Syntax beschrieben. Sie entspricht in ihrer Mächtigkeit der XQuery-Algebra. Syntaktisch verkörpert sie jedoch keineswegs die einzige Möglichkeit XQuery-Anfragen zu formulieren. Genaugenommen stellt die FLWR-Syntax nur eine Empfehlung einer möglichen Algebradarstellung vor. Weitere Syntaxen können jederzeit durch den Anwender definiert werden. Das W3C-Dokument XML Syntax for XQuery definiert beispielhaft eine XML-Syntax zu XQuery.

 FLWRExpr    ::=  (ForClause | LetClause)+ WhereClause? "return" Expr

                ForClause   ::=  "for" Variable "in" Expr ("," Variable "in" Expr)*

                LetClause   ::=  "let" Variable ":=" Expr ("," Variable ":=" Expr)*

                WhereClause ::=  "where" Expr Expr        ::=  extended XPath

Die entstehenden Ausdrücke sind durch das Auftreten der definierten Schlüsselworte FOR, LET, WHERE und RETURN strukturiert, die namensgebend für den Gesamtausdruck sind.
Nachfolgend werden ausgewählte Sprachbestandteile an Beispielen vorgestellt.

Beispiel zeigt einen ersten XQuery-Ausdruck, der eine Menge vorgegebener Elemente umstrukturiert. Mittels der FOR-Klausel werden alle in der durch runde Klammern begrenzten Aufzählungsmenge angegebenen Elemente des Namens Nachname an die Variable name gebunden. Die RETURN-Klausel gibt die gebundenen Werte einzeln aus und bettet sie statisch in ein Element Mitarbeiter ein.
Im Ergebnis treten daher nicht nur die textuellen Wertinhalte der Nachnamen-Elemente innerhalb der durch die Abfrage erzeugten Mitarbeiter-Elemente auf, sondern die gesamten Nachname-Elemente einschließlich ihrer Start- und Endemarken.

Üblicherweise werden jedoch die abzufragenden Werte nicht explizit durch den Anfragenden vorgegeben, sondern werden im Verlauf der Anfrageauswertung durch den XQuery-Prozessor aus einem oder mehreren Dokumenten extrahiert.
Daher liegt den nachfolgenden Anfragebeispielen, sofern nicht anders angegeben das Projektverwaltungsdokument zugrunde.

Der Ausdruck des Beispiels liefert alle Knoten des Typs Person. Hierzu werden eine oder mehrere durch XPath definierte Knotenmengen an Variablen gebunden. Im Beispiel ist dies die durch den erweiterten XPath //Person erreichbare Knotenmenge, die an die neu definierte Variable $x gebunden und im Anschluß durch das RETURN-Schlüsselwort ausgegeben wird.

Die Anfrage des Beispiels erweitert den vorhergehenden Ausdruck zunächst um eine WHERE-Bedingung. Sie prüft innerhalb der durch die Variablen $y repräsentierten Knotenmenge die Elemente des Typs Vorname auf den Inhalt Hans.
Für alle Knoten aus $y die diese Bedingung erfüllen, liefert die Anfrage das Element Nachname.

Ist eine sortierte Ausgabe der Resultate gewünscht, so kann der RETURN-Klausel ein Sortierausdruck der Form SORTBY (Knotenmenge ascending|descending) nachgestellt werten.
Beispiel zeigt dies als modifizierte Erweiterung der vorhergehend diskutierten Anfrage.

Beispiel zeigt eine Anfrage unter Ausprägung aller vier Strukturelemente. Die Anfrage ermittelt die Vornamen aller Projektleiter.
Hierbei wird zunächst die zu durchsuchende Knotenmenge //Person an die Variable $personen gebunden. Innerhalb des LET-Blockes wird zusätzlich die Variable $projekte mit der durch den XPath erreichbaren Knotenmenge //Projekt identifiziert. Durch die WHERE-Klausel werden alle diejenigen Knoten in $personen selektiert, deren PersID-Attribut mit dem Inhalt eines Projektleiter-Attributs in $personen übereinstimmt.
Zurückgeliefert werden durch RETURN alle Vorname-Elemente aus $personen.
Der wesentliche Unterschied zwischen den in FOR- und den in LET-Strukturen auftretenden Knotenmengen liegt in ihrer Behandlung während der iterativen Abarbeitung der Anfrage. Während alle in FOR referenzierten Knoten durchlaufen werden, wird die LET-Knotenmenge zu Beginn der Auswertung statisch ermittelt und keine Iteration über sie durchgeführt.
Beispiel zeigt nochmals gesondert die verschiedene Auswertungssemantik von FOR und LET ohne dabei auf die Projektverwaltung als Eingabedokument zurückzugreifen.

Im Verlauf der Anfrageauswertung werden zunächst die drei Nachnamen-Elemente iterativ an die Variable NName gebunden, d.h. in jedem Durchlauf der Auswertungsschleife wird genau ein Wert NName zugewiesen. Die Berechnung eines Ergebnisses für NName erfolgt also in jedem Teildurchlauf der Auswertung. Anders gelagert ist das Verhalten von LET. Das Ergebnis dieser Klausel wird nur einmal innerhalb der Abfrage bestimmt und an die Variable VName gebunden, daher enthält VName auch nicht einen Einzelwert, sondern die Menge aller zugewiesenen Werte.
Das Ergebnis spiegelt dieses Verhalten wieder, es enthält nicht, wie intuitiv zu vermuten die paarweise Zuordnung der Werte, sondern das Kartesische Produkt der Menge der Nachnamen mit der als einelementiger Menge betrachteten Nachnamensammlung.

Um mehr als eine Knotenmenge iterativ bearbeiten zu können darf ein XQuery-Ausdruck mehrere FOR-Klauseln beinhalten. Das folgende Beispiel zeigt auf diesem Wege die (korrekte) Berechnung des kartesischen Produktes der in Beispiel dargestellten Namen.

Auswertungsreihenfolge einer XQuery-Anfrage: In den Beispielen klingt bereits die Auswertungsreihenfolge der einzelnen Anweisungsteile an, sowie die zwischen den Einzelschritten transportierte Information.
Die Berechnung des Ergebnisdokuments erfolgt in Reihenfolge der verschiedenen Klauseln. In einem ersten Schritt werden die Knotenmengen der innerhalb von FOR- und WHERE-Klauseln auftretenden erweiterten XPath-Ausdrücke ermittelt. Die an Variablen gebundenen Knoten werden anschließend um diejenige Teilmenge vermindert, welche die in der WHERE-Klausel formulierte Bedingung nicht erfüllen.
Nach Errechnung des Typs des Zielschemas wird das Anfrageergebnis als XML-Dokument zurückgeliefert.
Abbildung veranschaulicht dies.

Einige Beispiele:
Die Anfrage aus Beispiel entspricht in Aufgabe und Ergebnis dem XPath-Ausdruck aus Beispiel . Geliefert werden -- unter Erhalt der Reihenfolge ihres Auftretens im Eingabedokument -- alle Vornamen zu jedem Knoten des Typs Person.

Die Anfrage aus Beispiel entspricht dem XPath-Ausdruck des Beispiels bzw. der hierarchieebenenunabhängigen Formulierung aus Beispiel .
Demnach ergibt sich die vermeintlich kompaktere Darstellung der XQuery-Anfrage gegenüber dem Pendant aus Beispiel allein aus der Nutzung der descendant -Achse aus XPath.

Die in Beispiel formulierte Anfrage gewinnt hingegen durch die erfolgte Separierung von Bedingung und Lokalisierungspfad deutlich an Übersichtlichkeit gegenüber der XPath-Formulierung gleicher Funktion.
Zusätzlich entsteht durch die Konzentration aller Bedingungen in die WHERE-Klausel Optimierungspotential vor Durchführung der Anfrage, das in der durch die nagivierende Schreibweise der XPath-Syntax nicht gegeben war.

Noch deutlicher zeigt sich gewonnene Übersichtlichkeit bei der Reformulierung des Beispiels .
Darüberhinaus erweist sich die Möglichkeit, Kontexte durch LET-Klauseln explizit zu bilden und zu benennen, deutlich der impliziten Formulierung in XPath überlegen:

Dasselbe Bild gibt auch Beispiel wieder; die mehrschrittige, mit Prädikaten zweiter Ordnung formulierte, XPath-Formulierung läßt sich durch eine äquivalente XQuery-Anfrage ersetzen.
Auch in diesem Beispiel erweist sich die Möglichkeit der gleichzeitigen Operation auf mehreren benannten Knotenmengen als sehr hilfreich.

Eine der abzusehenden Besonderheiten im noch nicht verabschiedeten XQuery-Standard ist die Nutzung von Schemainformation, falls vorhanden, zur Steigerung der Mächtigkeit der Anfragesprache.
Hervorstechendstes Beispiel dürfte die Auswertung der ID-IDERF(S)-Beziehungen sein, die innerhalb XPath gleichgestellt den CDATA-typisierten Attributen behandelt wurden.
Beispiel zeigt dies anhand der Beziehung zwischen Projekt und den dort eingesetzten Mitarbeitern. Inhaltlich läßt sich diese Beziehung an der Korrespondenz der Belegung des Attributs Mitarbeiter mit Werten, die zuvor bereits innerhalb eines Person-Elements im Attribut PersID angegeben wurden, festmachen.
XQuery definiert einen Operator =>, der Entsprechungen zwischen IDREF(S) und ID-typisierten Attributen auswertet. Formal kann dieser Operator beschrieben werden als:
=> := (e1 : xsd:IDREF(S), e2 : xsd:ID) --> xsd:boolean
Er liefert true wenn für die linksstehende Referenz(-menge) ein entsprechend belegtes ID-typsiertes Attribut existiert, andernfalls false. Die verwendeten Typen entsprechen denen der XML-Schema Part 2 Recommendation.

Erweiterung der XQuery-Basisfunktionalität:
Durch die Definition eigener Funktionen kann der Ausgangssprachumfang von XQuery durch den Anwender erweitert werden. Diese Funktionen stehen ab ihrer Definition für die Verwendung in Abfragen zur Verfügung.
Beispiel zeigt die Definition der Funktion get_vorname die zu einem gegebenen textuellen Elementinhalt die im Dokument abgelegten Vornamen-Elemente liefert.

Innerhalb einer XQuery-Funktion können vollständige XQuery-Ausdrücke aber auch einfache prozedurale Berechnungsvorschriften angegeben sein. Vor diesem Hintergrund führt Beispiel die Berechnung der Fakultät der Zahl 42 als XQuery-Funktion ein.

Berechnung des Zielschemas:
Wie anhand des =>-Operators im vorhergehenden Beispiel veranschaulicht, definiert XQuery für alle Operationen eine formale Semantik -- sie entspricht der Algebra --, die zur Berechnung des Zielschemas verwendet wird. Das zugrundeliegende Typsystem ist an das aus XML-Schema bekannte angelehnt, wenngleich es ihm nicht vollständig entspricht. Die verwendete mathematische Formalisierung des XSD-Typsystems ist im Dokument XML Schema: Formal Description ausführlich beschrieben und soll hier nicht vertieft werden.
Als Beispiel sei die formale Semantik der conditional expression herausgegriffen. Sie ist in Abschnitt 3.3 des XQuery-Dokuments beschrieben als:

Hieraus ergibt sich der Ergebnistyp eines solchen Ausdrucks, wie intuitiv erwartet, als Typ einer der beiden Alternativen (im Formalismus der Abbildung als t1 und t2 ).

Insgesamt zeigt sich XQuery als mächtige und, insbesondere für Anwender mit Vorwissen aus dem Bereich der Anfragesprachen für relationale oder objektorientierte Datenbanken, leicht zu erlernende Sprache.
Hervorgehoben sei abschließend, daß XQuery keineswegs die Pfadausdrücke nach XPath ersetzen wird, sondern vielmehr XPath im praktischen Einsatz auf seinen eigentlichen Zweck -- die Formulierung von navigierenden Pfadausdrücken -- reduziert werden kann.
Die Tabelle stellt die Charakteristika der XML-Anfragespache, klassischer Anfragesprachen und der XML-Pfadausdrücke zusammen. Die Übersicht wurde inspiriert durch P. Fankhauser.

Sprache Eingangsdaten Ausgangsdaten Schema Anwendungsbereich XPath und Muster aus XSLT XML Unicode Text oder XML XML-DTDs oder -Schema
(wird jedoch nicht ausgewertet) Dokumenttransformationen SQL, OQL strukturierte typisierte Information (Re-)Strukturierte typisierte Information SQL-DDL, ODL Auswertung von Datenbankinhalten
(relational oder postrelational) XQuery XML XML XML-Schema XML-Datenbanken, Anfrage an Dokumente Buch mit einer Sammlung von Aufsätzen zum Thema Tandberg-Workshop zu Anfragesprachen Rein, L.: The Quest for an XML Query Standard XQuery @ W3C Fatdog -- ein XQuery-Implementierung Rainbow -- eine weitere XQuery-Implementierung KWEELT -- eine Open-Source Implementierung von XQuery Qizx/Open -- Eine XQuery Implementierung