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.

Tabelle 1: Einige chronologische Eckdaten

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.

	Web-Referenzen 1: Vertiefende Informationen
	•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

	Web-Referenzen 2: Weiterführende Links
	•Browser Timelines •Browser Emulator

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.

	Definition 2: XML Dokument
	Ein XML-Dokument ist ein Datenstrom (der nicht zwingend als Datei vorliegen muß), welcher den Strukturierungsprinzipien der eXtensible Markup Language genügt.

	Definition 3: XML Information Set
	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 1 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:

	Definition 4: XML-Prozessor
	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. (In XML-Spezifikation nachschlagen)
Ferner nimmt die XML-Spezifikation an, ein Prozessor operiere nicht eigenständig, sondern im integrierten Zusammenspiel mit einer Applikation.

	Beispiel 1: Ein erstes XML-Dokument
	(1)<?xml version="1.0" encoding="ISO-8859-15" standalone="yes"?> (2)<Vorlesung> (3) <Wahlfach/> (4) SS2003 (5) <Titel beginn="2003-03-17T14:00:00+01:00">XML</Titel> (6) <Hochschule>Fachhochschule Furtwangen</Hochschule> (7) <Praktikum>Freiwilliger Übungsbetrieb</Praktikum> (8)</Vorlesung> Download des Beispiels

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 1 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. (In XML-Spezifikation nachschlagen)
• 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 (In XML-Spezifikation nachschlagen) . 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 (In XML-Spezifikation nachschlagen) :

[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) (In XML-Spezifikation nachschlagen) .
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.

Tabelle 2: Verschiedene Codierungen des Zeichens "A"

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“ 2²¹-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:

	Tabelle 3: UTF-8 Codierung
	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. (In XML-Spezifikation nachschlagen)

Wie bereits eingangs angemerkt, erklärt die XML-Spezifikation die Encodingdeklaration sowie den gesamten Prolog-Ausdruck als optionales Element (In XML-Spezifikation nachschlagen) .
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 ...) (In XML-Spezifikation nachschlagen) .
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 6 faßt die syntaktischen Elemente abgekürzt zusammen:

	Web-Referenzen 4: Weiterführende Links
	•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 (In XML-Spezifikation nachschlagen) :

[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 (In XML-Spezifikation nachschlagen) :

[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.

	Beispiel 2: Element mit deklariertem Namensraum
	(1)... (2) <myNS:aParent xmlns:myNS="example.com"> (3) <myNS:aElement/> (4) </myNS:aParent> (5)...

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 (In XML-Spezifikation nachschlagen) .

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 (In XML-Spezifikation nachschlagen) .
  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 (In XML-Spezifikation nachschlagen) .

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 7 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. (In XML-Spezifikation nachschlagen) .
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 (In XML-Spezifikation nachschlagen) . 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.

	Tabelle 4: Vordefinierte Textersetzungsmuster
	Entitätsreferenz Ausgedrücktes Zeichen &amp; & &lt; < &gt; > &apos; ' &quot; "

	Web-Referenzen 5: Weiterführendes ... Die in XHTML v1.0 vordefinierten Entitäten
	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. (In XML-Spezifikation nachschlagen)
• An jeder beliebigen Stelle des Inhalts, außerhalb von Markup-Symbolen. (In XML-Spezifikation nachschlagen)

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.

	Beispiel 3: Verschiedene Kommentarstrukturen
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<Root> (3) <!-- this is a comment --> (4) <ElementA> (5) <ElementB> (6) <!-- (7) <ElementC/> (8) <ElementD att1="..."/> (9) --> (10) </ElementB> (11) </ElementA> (12)</Root>

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).

	Beispiel 4: Verschiedene Processing Instructions
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<?mySystem value="42"?> (3)<root> (4) <?System2?> (5) <elementA> (6) <?System3 a="1" anotherValue?> (7) </elementA> (8)</root> Download des Beispiels

	Übung 1: Processing Instructions
	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.

Beispiel 5: NOTATIONS

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<!DOCTYPE someContent [ (3)<!NOTATION isoDate SYSTEM "http://www.iso.ch/markete/8601.pdf"> (4)<!NOTATION gif PUBLIC (5) "-//Compuserve Information Services//NOTATION Graphics Interchange (6) Format//EN"> (7)<!NOTATION hex SYSTEM "hexEditor.exe"> (8)<!ELEMENT someContent (#PCDATA)> (9)<!ATTLIST someContent format NOTATION (hex) #IMPLIED> ]> (10)<someContent format="hex">4C 65 74 20 61 6C 6C 20 68 6F 70 65 20 61 (11)62 61 6E 64 6F 6E 2C 20 79 65 20 77 68 6F 20 6D 61 79 20 65 6E 74 (12)65 72 20 68 65 72 65 21</someContent> Download des Beispiels

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.

	Beispiel 6: Verschiedene DOCTYPE-Deklarationen
	(1)<!DOCTYPE someContent SYSTEM "abc.dtd"> (2)<!DOCTYPE HTML PUBLIC (3) "-//W3C//DTD HTML 4.01//EN" (4) "http://www.w3.org/TR/html4/strict.dtd">

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 (In XML-Spezifikation nachschlagen)

[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 ;

	Beispiel 7: Einige Entitätsdefinitionen
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<!DOCTYPE someContent [ (3) <!ELEMENT someContent ANY> (4) <!ENTITY entA "xyz"> (5) <!ENTITY entB SYSTEM "http://www.jeckle.de/vorlesung/xml/script.html"> (6) <!ENTITY entC PUBLIC "-//FHA//Symbol//DE" "file://symbols"> (7)]> (8)<someContent> (9)&entA; (10)&entB; (11)&entC; (12)</someContent> Download des Beispiels

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.

	Beispiel 8: Eine ungeprüfte Entität
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<!DOCTYPE someContent [ (3) <!ELEMENT someContent ANY> (4) <!NOTATION gif PUBLIC (5) "-//Compuserve Information Services//NOTATION Graphics Interchange (6) Format//EN"> (7) <!ENTITY entA SYSTEM "xyz.gif" NDATA gif> (8)]> (9)<someContent> (10)&entA; (11)</someContent> Download des Beispiels

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 8 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.

	Beispiel 9: Beispiel eines Dokuments mit Namensräumen
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<root> (3) <elementA>...</elementA> (4) <elementB xmlns="http://www.fh-furtwangen.de">...</elementB> (5) <elementC xmlns:abc="http://www.xyz.com"> (6) ... (7) <abc:elementD/> (8) </elementC> (9)</root>

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

Elementname Namensraum 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 9 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 10 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.

Definition 5: Wohlgeformtes XML-Dokument

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 10 zeigt ein nicht-wohlgeformtes XML-Dokument, welches gegen eine Reihe der in Definition 5 verstößt:

	Beispiel 10: Ein nicht wohl-geformtes XML-Dokument
	(1)<?xml version="1.0"?> (2)<root> (3) <elementA att=a oder b> (4) <elementB> iff a<b ==> ... (5) </elementA> (6) <elementC att1="42" att1="3.14"> (7) <elementD <?do-something?> > (8) </elementC> (9) </elementD> (10) <!---- dies ist nicht erlaubt ----> (11)</root> Download des Beispiels

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

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.

	Beispiel 11: Ein Rechnungsdokument
	(1)<?xml version="1.0" encoding="UTF-8" standalone="yes"?> (2)<Rechnung> (3) <Kunde> (4) <KundenNr>4711</KundenNr> (5) <Name>Max Mustermann</Name> (6) <Anschrift> (7) <Straße>Musterplatz 1</Straße> (8) <PLZ>12345</PLZ> (9) <Ort>Musterstadt</Ort> (10) </Anschrift> (11) </Kunde> (12) <Rechnungsposten> (13) ... (14) </Rechnungsposten> (15)</Rechnung>

Beispiel 12: Eine alternative Rechnungsstruktur

(1)<?xml version="1.0" encoding="UTF-8" standalone="yes"?> (2)<Rechnung> (3) <Rechnungsanschrift> (4) <Kunde kundenNr="4711"> (5) <Name>Max Mustermann</Name> (6) <Straße>Musterplatz 1</Straße> (7) <PLZ>12345</PLZ> (8) <Ort>Musterstadt</Ort> (9) </Kunde> (10) </Rechnungsanschrift> (11) <Lieferanschrift> (12) ... (13) </Lieferanschrift> (14) <Rechnungsposten> (15) ... (16) </Rechnungsposten> (17)</Rechnung>

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).

Definition 6: Namensräume

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 IETF RFC 2732). 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) (IETF RFC 1738); 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 (In XML-Spezifikation nachschlagen) 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.

	Beispiel 13: Gültige URIs
	(1)http://www.wi.fh-furtwangen.de (2)http://meinrechner.wi.fh-augsburg.de (3)mailto:mario@jeckle.de (4)ftp://ftp.shareware.com (5)http://www.jeckle.de/xml/vorlesung/script.htm#Namespaces (6)#EinfuehrungUndUeberblick (7)urn:oasis:names:specification:docbook:dtd:xml:4.1.2 (8)urn:oid:1.3.6.1.2.1.27 (9)org.omg/standards/UML

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 12 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.

	Web-Referenzen 6: Weiterführende Links
	•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):

(1)<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
(2)	<http://www.example.com/sales:Rechnung>    
(3)		<http://www.example.com/sales:Kunde>       
(4)			<http://www.example.com/sales:KundenNr>4711</http://www.example.com/sales:KundenNr>       
(5)			<http://www.example.com/sales:Name>Max Mustermann</http://www.example.com/sales:Name>       
(6)			<http://www.example.com/sales:Anschrift>          
(7)				<http://www.example.com/sales:Straße>Musterplatz 1</http://www.example.com/sales:Straße>          
(8)				<http://www.example.com/sales:PLZ>12345</http://www.example.com/sales:PLZ>          
(9)				<http://www.example.com/sales:Ort>Musterstadt</http://www.example.com/sales:Ort>       
(10)			</http://www.example.com/sales:Anschrift>    
(11)		</http://www.example.com/sales:Kunde>    
(12)	<http://www.example.com/sales:Rechnungsposten>
(13)		... 
(14)	</http://www.example.com/sales:Rechnungsposten>
(15)</http://www.example.com/sales:Rechnung>

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.

Beispiel 14: Dokument mit W3C-konformen Namensräumen

(1)<?xml version="1.0" encoding="UTF-8" standalone="yes"?> (2)<myNS1:Rechnung xmlns:myNS1="http://www.xyz.com/sales"> (3) <myNS1:Kunde> (4) <myNS1:KundenNr>4711</myNS1:KundenNr> (5) <myNS1:Name>Max Mustermann</myNS1:Name> (6) <myNS1:Anschrift> (7) <myNS1:Straße>Musterplatz 1</myNS1:Straße> (8) <myNS1:PLZ>12345</myNS1:PLZ> (9) <myNS1:Ort>Musterstadt</myNS1:Ort> (10) </myNS1:Anschrift> (11) </myNS1:Kunde> (12) <myNS1:Rechnungsposten> (13) <!--...--> (14) </myNS1:Rechnungsposten> (15)</myNS1:Rechnung> Download des Beispiels

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.

Beispiel 15: Ein XHTML-Dokument mit MathML- und SVG-Inhalten

(1)<?xml version="1.0" encoding="UTF-8" standalone="yes"?> (2)<xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml" (3) xmlns:mml="http://www.w3.org/TR/REC-MathML" (4) xmlns:svg="http://www.w3.org/2000/svg"> (5) <xhtml:head> (6) <xhtml:title>XHTML Dokument, mit MathML- und SVG-Inhalten</xhtml:title> (7) </xhtml:head> (8) <xhtml:body> (9) <xhtml:h1>Eine Û¢erschrift</xhtml:h1> (10) <mml:math> (11) <mml:mrow> (12) <mml:mi>x</mml:mi> (13) <mml:mo>=</mml:mo> (14) <mml:mfrac> (15) <mml:mrow> (16) <mml:mrow> (17) <mml:mo>-</mml:mo> (18) <mml:mi>b</mml:mi> (19) </mml:mrow> (20) <mml:mo>&PlusMinus;</mml:mo> (21) <mml:msqrt> (22) <mml:mrow> (23) <mml:msup> (24) <mml:mi>b</mml:mi> (25) <mml:mn>2</mml:mn> (26) </mml:msup> (27) <mml:mo>-</mml:mo> (28) <mml:mrow> (29) <mml:mn>4</mml:mn> (30) <mml:mo>&InvisibleTimes;</mml:mo> (31) <mml:mi>a</mml:mi> (32) <mml:mo>&InvisibleTimes;</mml:mo> (33) <mml:mi>c</mml:mi> (34) </mml:mrow> (35) </mml:mrow> (36) </mml:msqrt> (37) </mml:mrow> (38) <mml:mrow> (39) <mml:mn>2</mml:mn> (40) <mml:mo>&InvisibleTimes;</mml:mo> (41) <mml:mi>a</mml:mi> (42) </mml:mrow> (43) </mml:mfrac> (44) </mml:mrow> (45) </mml:math> (46) <svg:svg width="4cm" height="8cm"> (47) <svg:ellipse cx="2cm" cy="4cm" rx="2cm" ry="1cm"/> (48) </svg:svg> (49) </xhtml:body> (50)</xhtml:html> Download des Beispiels

	Definition 7: Namensraumidentifikation
	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.

Beispiel 16: Rechnungsdokument mit überschriebenem Vorgabenamensraum

(1)<?xml version="1.0" encoding="UTF-8" standalone="yes"?> (2)<Rechnung xmlns="http://www.xyz.com/sales"> (3) <Kunde> (4) <KundenNr>4711</KundenNr> (5) <name>Max Mustermann</Name> (6) <Anschrift> (7) <Straße>Musterplatz 1</Straße> (8) <PLZ>12345</PLZ> (9) <Ort>Musterstadt</Ort> (10) </Anschrift> (11) </Kunde> (12) <Rechnungsposten> (13) <!--...--> (14) </Rechnungsposten> (15)</Rechnung> Download des Beispiels

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.

Beispiel 17: Ein XHTML-Dokument mit MathML- und SVG-Inhalten, unter Verwendung überschriebener Vorgabenamensräume

(1)<?xml version="1.0" encoding="UTF-8" standalone="yes"?> (2)<html xmlns="http://www.w3.org/1999/xhtml"> (3) <head> (4) <title>XHTML Dokument, mit MathML- und SVG-Inhalten</title> (5) </head> (6) <body> (7) <h1>Eine Überschrift</h1> (8) <math xmlns="http://www.w3.org/1998/Math/MathML"> (9) <mrow> (10) <mi>x</mi> (11) <mo>=</mo> (12) <mfrac> (13) <mrow> (14) <mrow> (15) <mo>-</mo> (16) <mi>b</mi> (17) </mrow> (18) <mo>+-</mo> (19) <msqrt> (20) <mrow> (21) <msup> (22) <mi>b</mi> (23) <mn>2</mn> (24) </msup> (25) <mo>-</mo> (26) <mrow> (27) <mn>4</mn> (28) <mo>&#160;</mo> (29) <mi>a</mi> (30) <mo>&#160;</mo> (31) <mi>c</mi> (32) </mrow> (33) </mrow> (34) </msqrt> (35) </mrow> (36) <mrow> (37) <mn>2</mn> (38) <mo>&#160;</mo> (39) <mi>a</mi> (40) </mrow> (41) </mfrac> (42) </mrow> (43) </math> (44) <svg xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" svg:width="4cm" svg:height="8cm"> (45) <ellipse cx="2cm" cy="4cm" rx="2cm" ry="1cm"/> (46) </svg> (47) </body> (48)</html> Download des Beispiels

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 18 und 19 befinden sich alle ausnahmslos im Namensraum http://www.example.com.

	Beispiel 18: Namensraumpräfixe 1
	(1)<abc:ElementA xmlns:abc="http://www.example.com" (2) xmlns:xyz="http://www.example.com"> (3) <ElementB xmlns="http://www.example.com"> (4) <ElementC/> (5) </ElementB> (6) <xyz:ElementB> (7) <abc:ElementC/> (8) </xyz:ElementB> (9)</abc:ElementA> Download des Beispiels

	Beispiel 19: Namensraumpräfixe 2
	(1)<ElementA xmlns="http://www.example.com" (2) xmlns:myNamespace="http://www.example.com"> (3) <foo:ElementB xmlns:foo="http://www.example.com"> (4) <myNamespace:ElementC/> (5) </foo:ElementB> (6) <ElementB xmlns="http://www.example.com"> (7) <myNamespace:ElementC/> (8) </ElementB> (9)</ElementA> Download des Beispiels

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 20 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.

Beispiel 20: Namensräume im realen Einsatz

(1)<?xml version="1.0"?> (2)<document> (3) <svg xmlns="http://www.w3.org/2000/svg"> (4) <g transform="translate(100,100)"> (5) <text id="TextElement" x="0" y="0" style="font-family:Verdana; font-size:35.27; visibility:hidden"> (6) It's alive! (7) <set attributeName="visibility" attributeType="CSS" to="visible" begin="3s" dur="6s" fill="freeze"/> (8) </text> (9) </g> (10) </svg> (11) (12) <math xmlns="http://www.w3.org/1998/Math/MathML"> (13) <set> (14) <ci> b </ci> (15) <ci> a </ci> (16) <ci> c </ci> (17) </set> (18) </math> (19)</document> Download des Beispiels

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 21 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.

	Beispiel 21: Präzedenzregel
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<ElementA xmlns="urn:namspaces:Namespace1" (3) xmlns:ns1="urn:namespace:Namespace2" (4) xmlns:ns2="urn:namespace:Namespace3"> (5) <ElementB/> (6) <ns1:ElementC/> (7) <ns1:ElementD xmlns="urn:namespace:Namespace3"/> (8)</ElementA> Download des Beispiels

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.

Beispiel 22: Aufheben von Namensraumdeklarationen

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<Adressen> (3) <table xmlns="http://www.w3.org/TR/REC-html40"> (4) <tr> (5) <td>Name</td> (6) <td>Adresse</td> (7) </tr> (8) <tr> (9) <td> (10) <Vorname xmlns="">Max</Vorname> (11) <Nachname xmlns="">Mustermann</Vorname> (12) </td> (13) <td> (14) <Straße xmlns="">Musterstr. 1</Straße> (15) <PLZ xmlns="">12345</PLZ> (16) <Ort xmlns="">Musterstadt</Ort> (17) </td> (18) </tr> (19) </table> (20)</Adressen>

Das Beispiel 22 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 23 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.

	Beispiel 23: Namensräume für Attribute
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<Wurzelelement> (3) <ElementA xmlns:NS1="http://www.example.com/NS1" xmlns:NS2="http://www.example.com/NS2"> (4) <ns2:ElementB att1="..."> (5) <ElementD att1="..." xmlns="http://www.example.com/NS3"> (6) <ElementC att2="ABC" NS2:att2="XYZ"/> (7) </ElementD> (8) </ns2:ElementB> (9) </ElementA> (10)</Wurzelelement>

Definition 8: Namensraumvererbung

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 24 zeigt gültige IRIs und jeweils dahinter in Klammern angegeben die daraus resultierende URI-Darstellung.

	Beispiel 24:
	(1)http://www.{iri-}example.com (http://www.%7Biri-%7Dexample.com) (2)mailto:marc léon@example.org (mailto:marc%20l%E9on@example.org)

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.

	Web-Referenzen 7: Weiterführende Links
	•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

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 (In XML-Spezifikation nachschlagen) , IDREF, IDREFS (In XML-Spezifikation nachschlagen) , ENTITY, ENTITIES (In XML-Spezifikation nachschlagen) bzw. NMTOKEN und NMTOKENS (In XML-Spezifikation nachschlagen) 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 2^nd 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:

	Beispiel 28: Definition einer Schemareferenz
	(1)<?xml version="1.0" encoding="UTF-8"?> (2)<ProjektVerwaltung (3) xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" (4) xsi:schemaLocation="http://www.jeckle.de/vorlesung/xml/examples/projektverwaltung.xsd"> (5) ...

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.

	Definition 11: Gültigkeit hinsichtlich eines Schemas
	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:

Tabelle 5: Typen in XSD-Schema Part 2

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 * 2e, wobei m und einteger-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 * 2e, wobei m und einteger-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 2004-06-11 Datumsformat: CCYY-MM-DD, gemäß ISO 8601 gYear 1999, 2001, 2004 Darstellung von Jahren des gregorianischen Kalenders gemäß ISO 8601 gYearMonth 2004-06 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 2004-06-11T07:12:46.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äß IETF RFC 2045 hexBinary 0FB7 Hexadezimale Darstellung beliebiger Binär-interpretierter Inhalte anyURI http://www.jeckle.de Jede gemäß IETF RFC 2396 bzw. IETF RFC 2732 gültige URI language en-GB, en, de-de Sprachcodierung gemäß IETF RFC 1766 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

	Beispiel 29:
	(1)<element name="geburtsdatum" type="xsd:date"/> (2)<element name="pi" (3) type="xsd:double" (4) fixed="3.141592653" (5) block="#all" (6) final="#all"/> (7)<element name="vorname" (8) type="xsd:token" (9) minOccurs="1" (10) maxOccurs="unbounded"/> (11)<element name="artikelNummer" (12) type="xsd:NCName" (13) form="qualified"/>

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:

Beispiel 30: Einige Elementdefinitionen

(1)<?xml version = "1.0" encoding = "UTF-8"?> (2)<xsd:schema xmlns:xsd = "http://www.w3.org/2001/XMLSchema"> (3) <xsd:element name = "ProjektVerwaltung"> (4) <xsd:complexType> (5) <xsd:sequence> (6) <xsd:element ref = "Person" maxOccurs = "unbounded"/> (7) <xsd:element ref = "Projekt" maxOccurs = "unbounded"/> (8) </xsd:sequence> (9) </xsd:complexType> (10) </xsd:element> (11) <xsd:element name = "Person"> (12) <xsd:complexType> (13) <xsd:sequence> (14) <xsd:element name = "Vorname" type = "xsd:token" maxOccurs = "unbounded"/> (15) <xsd:element name = "Nachname" type = "xsd:token"/> (16) <xsd:element ref = "Qualifikationsprofil" minOccurs = "0"/> (17) </xsd:sequence> (18) </xsd:complexType> (19) </xsd:element> (20) <xsd:element name = "Projekt"> (21) <xsd:complexType/> (22) </xsd:element> (23) <xsd:element name = "Qualifikationsprofil"> (24) <xsd:complexType mixed = "true"> (25) <xsd:sequence> (26) <xsd:element name = "Qualifikation" type = "xsd:string" minOccurs = "0" maxOccurs = "unbounded"/> (27) <xsd:element name = "Leistungsstufe" type = "xsd:string" minOccurs = "0" maxOccurs = "unbounded"/> (28) </xsd:sequence> (29) </xsd:complexType> (30) </xsd:element> (31)</xsd:schema> Download des Beispiels

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:

Beispiel 31: Nutzung benannter komplexer Typen

(1)<xsd:schema xmlns:xsd = "http://www.w3.org/2001/XMLSchema"> (2) <xsd:complexType name="PersonType"> (3) <xsd:sequence> (4) <xsd:element name = "Vorname" type = "xsd:string" (5) maxOccurs = "unbounded"/> (6) <xsd:element name = "Nachname" type = "xsd:string"/> (7) <xsd:element ref = "Qualifikationsprofil" minOccurs = "0"/> (8) </xsd:sequence> (9) </xsd:complexType> (10) (11) <xsd:element name = "ProjektVerwaltung"> (12) <xsd:complexType> (13) <xsd:sequence> (14) <xsd:element name="Person" type="PersonType" maxOccurs = "unbounded"/> (15) <xsd:element ref = "Projekt" maxOccurs = "unbounded"/> (16) </xsd:sequence> (17) </xsd:complexType> (18) </xsd:element> (19) (20) <xsd:element name = "Projekt"> (21) <xsd:complexType/> (22) </xsd:element> (23) (24) <xsd:element name = "Qualifikationsprofil"> (25) <xsd:complexType mixed = "true"> (26) <xsd:sequence> (27) <xsd:element name = "Qualifikation" type = "xsd:string" (28) minOccurs = "0" maxOccurs = "unbounded"/> (29) <xsd:element name = "Leistungsstufe" type = "xsd:string" (30) minOccurs = "0" maxOccurs = "unbounded"/> (31) </xsd:sequence> (32) </xsd:complexType> (33) </xsd:element> (34)</xsd:schema> Download des Beispiels

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.

Beispiel 32: Einschränkende Typableitung

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> (3)<xsd:complexType name="parentType"> (4) <xsd:sequence> (5) <xsd:element name="elementA" type="xsd:int"/> (6) </xsd:sequence> (7)</xsd:complexType> (8) (9)<xsd:complexType name="childType"> (10)<xsd:complexContent> (11) <xsd:restriction base="parentType"> (12) <xsd:sequence> (13) <xsd:element name="elementA" type="xsd:short"/> (14) </xsd:sequence> (15) </xsd:restriction> (16)</xsd:complexContent> (17)</xsd:complexType> (18) (19)<xsd:element name="usage1" type="parentType"/> (20)<xsd:element name="usage2" type="childType"/> (21) (22)</xsd:schema> Download des Beispiels

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.

Tabelle 6: Beispiele für zulässige Restriktionen

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.

Beispiel 33: Erweiternde Typableitung

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> (3) <xsd:complexType name="parentElement"> (4) <xsd:sequence> (5) <xsd:element name="elementA"/> (6) </xsd:sequence> (7) </xsd:complexType> (8) (9) <xsd:complexType name="childElement"> (10) <xsd:complexContent> (11) <xsd:extension base="parentElement"> (12) <xsd:sequence> (13) <xsd:element name="elementB"/> (14) </xsd:sequence> (15) </xsd:extension> (16) </xsd:complexContent> (17) </xsd:complexType> (18)</xsd:schema> Download des Beispiels

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.

Beispiel 34: Ableitung eines komplexen Typen von einem Simplen

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xs:schema (3) xmlns:xs="http://www.w3.org/2001/XMLSchema" (4) elementFormDefault="qualified" (5) attributeFormDefault="unqualified"> (6) <xs:element name="Vorname"> (7) <xs:complexType> (8) <xs:simpleContent> (9) <xs:extension base="xs:string"> (10) <xs:attribute (11) name="rufname" (12) type="xs:boolean"/> (13) </xs:extension> (14) </xs:simpleContent> (15) </xs:complexType> (16) </xs:element> (17)</xs:schema> Download des Beispiels

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.

(1)<xs:simpleType name="termin">
(2)	<xs:union memberTypes="xs:date NamenDerWochentage"/>
(3)</xs:simpleType>

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.

	Beispiel 35: Einschränkende Spezialisierung eines simplen Typen
	(1)<xsd:simpleType name="short" id="short"> (2) <xsd:restriction base="xsd:int"> (3) <xsd:minInclusive value="-32768" (4) id="short.minInclusive"/> (5) <xsd:maxInclusive value="32767" (6) id="short.maxInclusive"/> (7) </xsd:restriction> (8)</xsd:simpleType>

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).

	Beispiel 36: Bildung eines Aggregationstypen
	(1)<xsd:simpleType name="WarenkorbElemente"> (2) <xsd:list itemType="xsd:string"/> (3)</xsd:simpleType>

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:

  (1)<xs:simpleType name="Postleitzahl">    
  (2)	<xs:restriction base="xs:string">       
  (3)		<xs:length value="5"/>
  (4)	</xs:restriction> 
  (5)</xs:simpleType>

  Beschränkung der Elementanzahl einer Liste:

  (1)<xs:simpleType name="VornamenList">    
  (2)	<xs:list itemType="xs:token"/> 
  (3)</xs:simpleType> 
  (4)<xs:simpleType name="VornamenRestrictedList">    
  (5)	<xs:restriction base="VornamenList">       
  (6)		<xs:length value="5"/>
  (7)	</xs:restriction> 
  (8)</xs:simpleType> 

• minLength
  Minimale Länge (bei atomaren Typen bzw. minimale Elementanzahl bei aggregierten Typen.
  Beispiel (der aggregierte Typ VornamenRestrictedList muß mindestens einen Eintrag enthalten):

  (1)<xs:simpleType name="VornamenList">    
  (2)	<xs:list itemType="xs:token"/> 
  (3)</xs:simpleType> 
  (4)<xs:simpleType name="VornamenRestrictedList">    
  (5)	<xs:restriction base="VornamenList">       
  (6)		<xs:minLength value="1"/>
  (7)	</xs:restriction> 
  (8)</xs:simpleType> 

  Beispiel (der spezialisierte atomare Typ Titel muß aus mindestens fünf Zeichen bestehen):

  (1)<xs:simpleType name="Titel">    
  (2)	<xs:restriction base="xs:string">       
  (3)		<xs:minLength value="5"/>
  (4)	</xs:restriction> 
  (5)</xs:simpleType>

• 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):

  (1)<xs:simpleType name="VornamenList">    
  (2)	<xs:list itemType="xs:token"/> 
  (3)</xs:simpleType> 
  (4)<xs:simpleType name="VornamenRestrictedList">    
  (5)	<xs:restriction base="VornamenList">       
  (6)		<xs:minLength value="1"/>       
  (7)		<xs:maxLength value="3"/>
  (8)	</xs:restriction> 
  (9)</xs:simpleType>

  Beispiel (der spezialisierte atomare Typ Titel muß aus mindestens fünf, darf jedoch aus höchstens 80 Zeichen bestehen):

  (1)<xs:simpleType name="Titel">    
  (2)	<xs:restriction base="xs:string">       
  (3)		<xs:minLength value="5"/>       
  (4)		<xs:maxLength value="80"/>
  (5)	</xs:restriction> 
  (6)</xs:simpleType>

• 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:

  Tabelle 7: Übersicht der Quantifier

  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:

  	Tabelle 8: Übersicht der Escape-Symbole
  	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.

  Tabelle 9: Buchstaben

  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

  
  

  

  
  

  	Tabelle 10: Markierungssymbole
  	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

  
  

  

  
  

  Tabelle 11: Zahlen

  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

  
  

  

  
  

  Tabelle 12: Interpunktionszeichen

  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

  
  

  

  
  

  	Tabelle 13: Separatoren
  	symbolische Darstellung Bedeutung Z Alle Separatoren Zs (Space) Trennende Leerzeichen Zl (Line) Zeilentrenner (#x2028) Zp (Paragraph) Absatztrenner (#x2029)

  
  

  

  
  

  	Tabelle 14: Symbole
  	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

  
  

  

  
  

  	Tabelle 15: Sonstige Zeichen
  	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.

  Tabelle 16: Zeichensequenzen

  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:

  (1)<xs:simpleType name="gerAutoNummer">    
  (2)	<xs:restriction base="xs:string">       
  (3)		<xs:pattern value="\p{Lu}{1,3}-\p{Lu}{1,2} \p{Nd}{1,4}"/>
  (4)	</xs:restriction> 
  (5)</xs:simpleType>

  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):

  (1)<xs:simpleType name="ampelfarben">   
  (2)	<xs:restriction base="xs:string">     
  (3)		<xs:enumeration value="rot"/>     
  (4)		<xs:enumeration value="gelb"/>     
  (5)		<xs:enumeration value="grün"/>
  (6)	</xs:restriction> 
  (7)</xs:simpleType>

• 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):

  (1)<xs:simpleType name="uHu">    
  (2)	<xs:restriction base="xs:decimal">       
  (3)		<xs:maxInclusive value="100"/>
  (4)	</xs:restriction>
  (5)</xs:simpleType> 

  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):

  (1)<xs:simpleType name="uHu">
  (2)	<xs:restriction base="xs:decimal">
  (3)		<xs:maxExclusive value="100"/>
  (4)	</xs:restriction>
  (5)</xs:simpleType> 

  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):

  (1)<xs:simpleType name="uFz">
  (2)	<xs:restriction base="xs:decimal">
  (3)		<xs:minInclusive value="25"/>
  (4)	</xs:restriction>
  (5)</xs:simpleType>

• minExclusive
  Kleinster Wert, der nicht mehr zugelassen ist. Im mathematischen Sinne sind alle Zahlen, die größer sind, gültige Belegungen.
  Beispiel (Zahlen > 25):

  (1)<xs:simpleType name="uFz">    
  (2)	<xs:restriction base="xs:decimal">
  (3)		<xs:minExclusive value="25"/>
  (4)	</xs:restriction>
  (5)</xs:simpleType>

• totalDigits
  Gesamtstellen einer Zahl, gebildet aus der Summe der Vorkomma- und der Nachkommastellen.
  Beispiel (Zahlen mit höchstens sieben Stellen):

  (1)<xs:simpleType name="myNumber">
  (2)	<xs:restriction base="xs:decimal">
  (3)		<xs:totalDigits value="7"/>
  (4)	</xs:restriction>
  (5)</xs:simpleType>

• fractionDigits
  Anzahl der Nachkommastellen eines Dezimalbruches.
  Beispiel (Zahl mit höchstens neuen Stellen, davon zwei Nachkommastellen):

  (1)<xs:simpleType name="myNumber">
  (2)	<xs:restriction base="decimal">
  (3)		<xs:totalDigits value="9"/>
  (4)		<xs:fractionDigits value="2"/>
  (5)	</xs:restriction>
  (6)</xs:simpleType>

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.

Beispiel 37: Einige Attributdefinitionen

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> (3) <xsd:attribute name="myAtt1"/> (4) (5) <xsd:attribute name="myAtt2" type="xsd:decimal"/> (6) (7) <xsd:attribute name="myAtt3"> (8) <xsd:simpleType> (9) <xsd:restriction base="xsd:int"> (10) <xsd:minInclusive value="10"/> (11) <xsd:maxInclusive value="20"/> (12) </xsd:restriction> (13) </xsd:simpleType> (14) </xsd:attribute> (15) (16) <xsd:simpleType name="myType1"> (17) <xsd:restriction base="xsd:string"> (18) <xsd:maxLength value="5"/> (19) </xsd:restriction> (20) </xsd:simpleType> (21) <xsd:attribute name="myAtt4" type="myType1"/> (22) (23) (24) (25) <xsd:element name="foo"> (26) <xsd:complexType> (27) <xsd:attribute ref="myAtt1" use="optional"/> (28) <xsd:attribute ref="myAtt2" use="required"/> (29) <xsd:attribute ref="myAtt3" use="prohibited"/> (30) <xsd:attribute ref="myAtt4"/> (31) <xsd:attribute name="myAtt5" type="xsd:date" id="myDate"/> (32) <xsd:attribute name="myAtt6"> (33) <xsd:simpleType> (34) <xsd:restriction base="xsd:float"> (35) <xsd:totalDigits value="5"/> (36) </xsd:restriction> (37) </xsd:simpleType> (38) </xsd:attribute> (39) </xsd:complexType> (40) </xsd:element> (41) (42)</xsd:schema> Download des Beispiels

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.

Beispiel 38: Vollständiges XML-Schema der Projektverwaltung

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> (3) <xsd:element name="Nachname" type="xsd:string"/> (4) <xsd:complexType name="PersonType"> (5) <xsd:sequence> (6) <xsd:element ref="Vorname" maxOccurs="unbounded"/> (7) <xsd:element ref="Nachname" maxOccurs="unbounded"/> (8) <xsd:element name="Qualifikationsprofil" type="QualifikationsprofilType" minOccurs="0"/> (9) </xsd:sequence> (10) <xsd:attribute name="PersID" type="xsd:ID" use="required"/> (11) <xsd:attribute name="Gehaltsgruppe" default="1a"> (12) <xsd:simpleType> (13) <xsd:restriction base="xsd:NMTOKEN"> (14) <xsd:enumeration value="1"/> (15) <xsd:enumeration value="1a"/> (16) <xsd:enumeration value="2"/> (17) </xsd:restriction> (18) </xsd:simpleType> (19) </xsd:attribute> (20) <xsd:attribute name="mitarbeitInProjekt" type="xsd:IDREFS" use="required"/> (21) </xsd:complexType> (22) <xsd:complexType name="ProjektType"> (23) <xsd:attribute name="ID" type="xsd:ID" use="required"/> (24) <xsd:attribute name="date" type="xsd:date"/> (25) <xsd:attribute name="budget" default="10000.00"> (26) <xsd:simpleType> (27) <xsd:restriction base="xsd:double"> (28) <xsd:fractionDigits value="2"/> (29) </xsd:restriction> (30) </xsd:simpleType> (31) </xsd:attribute> (32) <xsd:attribute name="Projektleiter" type="xsd:IDREF" use="required"/> (33) <xsd:attribute name="Mitarbeiter" type="xsd:IDREFS" use="required"/> (34) </xsd:complexType> (35) <xsd:element name="ProjektVerwaltung"> (36) <xsd:complexType> (37) <xsd:sequence> (38) <xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/> (39) <xsd:element name="Projekt" type="ProjektType" maxOccurs="unbounded"/> (40) </xsd:sequence> (41) <xsd:attribute name="version" type="xsd:string" fixed="1.0"/> (42) </xsd:complexType> (43) </xsd:element> (44) <xsd:complexType name="QualifikationsprofilType" mixed="true"> (45) <xsd:choice minOccurs="0" maxOccurs="unbounded"> (46) <xsd:element ref="Qualifikation"/> (47) <xsd:element ref="Leistungsstufe"/> (48) <xsd:any namespace="http://www.w3.org/1999/xhtml"/> (49) </xsd:choice> (50) </xsd:complexType> (51) <xsd:element name="Qualifikation" type="xsd:string"/> (52) <xsd:element name="Leistungsstufe" type="xsd:string"/> (53) <xsd:element name="Vorname" type="xsd:string"/> (54)</xsd:schema> Download des Beispiels

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

Beispiel 39: Gültiges Projektverwaltungsdokument

(1)<?xml version="1.0" encoding="ISO-8859-1"?> (2)<ProjektVerwaltung (3) xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" (4) xsi:noNamespaceSchemaLocation="http://www.jeckle.de/vorlesung/xml/examples/projektverwaltung.xsd"> (5) <Person PersID="Pers01" mitarbeitInProjekt="Prj01"> (6) <Vorname>Hans</Vorname> (7) <Nachname>Hinterhuber</Nachname> (8) </Person> (9) <Person PersID="Pers02" mitarbeitInProjekt="Prj02"> (10) <Vorname>Franz</Vorname> (11) <Vorname>Xaver</Vorname> (12) <Nachname>Obermüller</Nachname> (13) <Qualifikationsprofil> (14) IT-Kompetenz verschiedene Betriebssysteme und <Leistungsstufe>professionelle</Leistungsstufe> (15) <Qualifikation>Programmierung</Qualifikation> verschiedener Programmiersprachen (16) <Qualifikation>Entwickler</Qualifikation> von 1988-1990 (17) <Qualifikation>Projektleiterfunktion</Qualifikation> von 1990-93 im X42-Projekt in Abteilung AB&amp;C (18) </Qualifikationsprofil> (19) </Person> (20) <Person PersID="Pers03" mitarbeitInProjekt="Prj02"> (21) <Vorname>Fritz</Vorname> (22) <Nachname>Meier</Nachname> (23) </Person> (24) <Projekt ID="Prj01" Projektleiter="Pers01" Mitarbeiter="Pers01"/> (25) <Projekt ID="Prj02" Projektleiter="Pers02" Mitarbeiter="Pers03"/> (26)</ProjektVerwaltung> Download des Beispiels

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

	Web-Referenzen 9: Weiterführende Links und Werkzeuge
	•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)