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 2: 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 und 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.
   
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.
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 3: 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 4: 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 5: 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) <Pflichtfach/> (4) SS2003 (5) <Titel beginn="2003-03-17T14:00:00+01:00">eBusiness-Engineering</Titel> (6) <Hochschule>Fachhochschule Furtwangen</Hochschule> (7) <Praktikum>Kein Ü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.

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

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 3: 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 4: 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 4 faßt die syntaktischen Elemente abgekürzt zusammen:

	Web-Referenzen 3: 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 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 Pflichtfach 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, 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 5 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.
Häufig werden white-spaces (Leerzeichen, Tabulator, Zeilenvorschub, Wagenrücklauf) 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 5: Vordefinierte Textersetzungsmuster
	Entitätsreferenz Ausgedrücktes Zeichen &amp; & &lt; < &gt; > &apos; ' &quot; "

	Web-Referenzen 4: 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.

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.

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

	Beispiel 6: 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 7: 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 8: 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 7: 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 9: 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 10 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 5: 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 10: 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 11: 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 8: 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 12: 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 13: 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 14 und 15 befinden sich alle ausnahmslos im Namensraum http://www.example.com.

	Beispiel 14: 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 15: 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 16 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 16: 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 17 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 17: 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 18: 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 18 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 19 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 19: 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 9: 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 20 zeigt gültige IRIs und jeweils dahinter in Klammern angegeben die daraus resultierende URI-Darstellung.

	Beispiel 20:
	(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 6: 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 in der Vergangenheit zur Sprachdefinition verwendeten 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 Inhaltsmodelle: child elements, PCDATA, mixed content sowie das leere Inhaltsmodell EMPTY.
• Unzureichende Strukturierungsunterstützung.
  Zwar erlauben die Operatoren zur Steuerung der Auftrittshäufigkeit („?“, „+“ und „*“) 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 .
  Eine Nutzung in anderen Dokument-Typ-Definitionen als der definierenden ist nicht vorgesehen.
• 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.
• Nur rudimentärer Referenzierungsmechanismus.
  Die offerierten Verknüpfungsmechanismen 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
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.

Schemareferenz:
Jedes XML-Schema bildet als XML-Dokument eine eigenständige Speichereinheit, üblicherweise eine Datei.
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 21: 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.

Aufbauend auf dem Begriff der Wohlgeformtheit definiert XML-Schema den der Schemagültigkeit als höhere Qualitätsstufe eines XML-Vokabulars:

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

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

Während die DTD für unstrukturierten Inhalt ausschließliche uninterpretierte Zeichenketten unterstützt, wird die Ausdrucksmächtigkeit durch XML-Schema deutlich gesteigert.
XML-Schema Part 2 definiert insgesamt 44 Primitivtypen. Darunter finden sich die bereits in der DTD angebbaren 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 6: 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:12.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"/> 

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 22:
	(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 (dort beschränkt er sich lediglich auf verschiedene Darstellungsformen uninterpretierter Zeichenketten) 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. 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.
Zur Festlegung der Elementreihenfolge definiert XML-Schema das Element sequence, welches die Angabe der Kindelemente in genau der im Schema angegebenen Reihenfolge erzwingt.
Das Auswahlinhaltsmodell (auch: Selektionsmodell) --- welches alternativ das Auftreten beliebiger Elemente definiert --- wird entsprechend durch das XSD-Element choice ausgedrückt.
Eine besondere Variante des Selektionsmodells stellt die all-Gruppe dar. Es erlaubt die Angabe der Kindelemente in beliebiger Reihenfolge.
Die drei Ausgangsvarianten können im Rahmen einer Elementdefinition beliebig geschachtelt und auf diesem Wege kombiniert werden.
Am Beispiel der Elementdefinitionen der Projektverwaltung:

Beispiel 23: 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. Die Elemente müssen 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).
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.
XML-Schema bietet 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 24: 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 25: 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 7: 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 26: 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 27: 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 28: 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 29: 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 8: Ü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 9: Ü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 10: 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 11: 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 12: 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 13: 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 14: Separatoren
  	symbolische Darstellung Bedeutung Z Alle Separatoren Zs (Space) Trennende Leerzeichen Zl (Line) Zeilentrenner (#x2028) Zp (Paragraph) Absatztrenner (#x2029)

  
  

  

  
  

  	Tabelle 15: 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 16: 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 17: 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 30: 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 31: 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 32: 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 7: 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)

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

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

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

	Beispiel 33: XPath-Ausdruck zur Lokalisierung aller Vornamen
	XPath-Ausdruck: /ProjektVerwaltung/Person/Vorname Ergebnis: <Vorname>Hans</Vorname>, <Vorname>Franz</Vorname>, <Vorname>Xaver</Vorname>, <Vorname>Fritz</Vorname>

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

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

	Beispiel 34: Platzhalter in Lokalisierungsschritten
	XPath-Ausdruck: /ProjektVerwaltung/Person/Qualifikationsprofil/*/Qualifikation Ergebnis: <Qualifikation>Programmierung</Qualifikation> <Qualifikation>Projektleiterfunktion</Qualifikation>

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

Definition 11: Lokalisierungsschritt

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

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

	Beispiel 35: Hierarchieunabhänigige Knoten-Lokalisierung
	XPath-Ausdruck: /ProjektVerwaltung/Person/Qualifikationsprofil//Qualifikation Ergebnis: <Qualifikation>Programmierung</Qualifikation> <Qualifikation>Entwickler</Qualifikation> <Qualifikation>Projektleiterfunktion</Qualifikation>

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

Download der XML-Datei mit dem Beispiel der Graphik

Tabelle 18: XPath-Achsen und ihre Bedeutung

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

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

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

	Beispiel 36: Selektion unter Anwendung eines Prädikats
	XPath-Ausdruck: //Person[Qualifikationsprofil]/Nachname Ergebnis: <Nachname>Obermüller</Nachname>

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

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

Beispiel 37: Schrittweise Berechnung einer Selektion unter Verwendung mehrerer Prädikate

XPath-Ausdruck: //Person[parent::ProjektVerwaltung]/Vorname[starts-with(following::Nachname,'O')] Ausgewerteter XPath://Person Ergebnis: <Person PersID="Pers01" mitarbeitInProjekt="Prj01"> ... </Person> <Person PersID="Pers02" mitarbeitInProjekt="Prj02"> ... </Person> <Person PersID="Pers03" mitarbeitInProjekt="Prj02"> ... </Person> Ausgewerteter XPath://Person[parent::ProjektVerwaltung] Ergebnis: <Person PersID="Pers01" mitarbeitInProjekt="Prj01"> ... </Person> <Person PersID="Pers02" mitarbeitInProjekt="Prj02"> ... </Person> <Person PersID="Pers03" mitarbeitInProjekt="Prj02"> ... </Person> Ausgewerteter XPath://Person[parent::ProjektVerwaltung]/Vorname Ergebnis: <Vorname>Hans</Vorname> <Vorname>Franz</Vorname> <Vorname>Xaver</Vorname> <Vorname>Fritz</Vorname> Ausgewerteter XPath://Person[parent::ProjektVerwaltung]/Vorname[following::Nachname] Ergebnis: <Vorname>Hans</Vorname> <Vorname>Franz</Vorname> <Vorname>Xaver</Vorname> <Vorname>Fritz</Vorname> Ausgewerteter XPath: //Person[parent::ProjektVerwaltung]/Vorname[starts-with(following::Nachname,'O')] Ergebnis: <Vorname>Franz</Vorname> <Vorname>Xaver</Vorname>

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

Tabelle 19: XPath-Funktionen für Knotenmengen (node-sets)

Funktionsprototyp Funktionalität number last() Liefert die Größe der aktuellen Knotenmenge; damit den Index des letzten Elements number position() Liefert die Position des aktuellen Knotens innerhalb der Knotenmenge. Die erste Knoten trägt die Positionsnummer 1. number count(node-set) Liefert Elementzahl der übergebenen Knotenmenge node-set id(object) Liefert denjenigen Knoten, dessen ID-typisiertes Attribut den Argumentwert aufweist. Anmerkung: Zur Nutzung dieser Funktion muß zwingend eine Dokument-Grammatik (DTD oder Schema) zum Eingangsdokument vorliegen. string local-name (node-set?) Liefert den local name (oder die Menge der Namen) der übergebenen Knotenmenge. Wird keine Knotenmenge übergeben, dann wird der aktuelle Knoten als Argument genutzt. string namespace-uri (node-set?) Liefert die Namensraum-URI der übergebenen Knotenmenge. Wird keine Knotenmenge übergeben, dann wird der aktuelle Knoten als Argument genutzt. Anmerkung: Handelt es sich nicht um einen Element- oder Attributknoten, so ist die retournierte Zeichenkette leer. string name (node-set?) Liefert die QName(n) (=qualifizierte(r) Name(n) aus Namensraumkürzel und local name) der übergebenen Knotenmenge, oder des aktuellen Knotens bei leerer Knotenmenge. Anmerkung: Nur für Element- und Attributknoten liefert name andere Resultate als local-name.

Tabelle 20: XPath-Funktionen für Zeichenketten

Funktionsprototyp Funktionalität string string (object)? Liefert Zeichenkettenrepräsentation einer Knotenmenge. Dabei wird der Zeichenkettenwert des ersten Knotens in der Dokumentreihenfolge zurückgegeben, andernfalls die leere Zeichenkette. string concat (string, string, string*) Verkettet mindestens zwei Zeichenketten. boolean starts-with (string1, string2) Liefert true falls string1 das zweite Argument string2 als Präfix enthält; andernfalls false boolean contains (string1, string2) Liefert true falls string1 die Zeichenkette aus string2 enthält; andernfalls false. string substring-before (string1, string2) Liefert denjenigen Teil der Zeichenkette string1, der sich vor dem ersten Auftreten der Zeichenkette string2 befindet. string substring-after (string1, string2) Liefert denjenigen Teil der Zeichenkette string1, der sich nach dem ersten Auftreten der Zeichenkette string2 befindet. string substring (string, number1, number2?) Liefert eine Zeichenkette der Länge number2 aus string, beginnend mit der Position number1. Fehlt das dritte Argument, so wird der Teilstring bis zum Ende der Zeichenkette string zurückgegeben. Anmerkung: Das erste Zeichen trägt die Indexnummer 1, nicht 0 wie in Java und C üblich. number string-length(string?) Liefert die Länge der übergebenen Zeichenkette. Wird kein Argument übergeben, so wird die Länge des zuvor in eine Zeichenkette konvertierten aktuellen Knotens zurückgegeben. string normalize-space (string?) Liefert die übergebene Zeichenkette unter Entfernung führender, schließender und mehrfacher Leerzeichen zurück. Ferner werden noch evtl. in der Argumentzeichenkette enthaltenen Entitätsreferenzen aufgelöst. Anmerkung: Der Normalisierungsvorgang entspricht damit der Attributwertenormalisierung nach Abschnitt 3.3.3 der XML-Spezifikation. string translate (string1, string2, string3) Liefert die Zeichenkette string1 wobei jedes Zeichen aus string2 durch das Zeichen an derselben Position aus string3 ersetzt wurde.

Tabelle 21: Boole'sche XPath-Funktionen

Funktionsprototyp Funktionalität boolean boolean (object) Liefert die Boole'sche Repräsentation des übergebenen Arguments. Hierbei gilt: •Eine Zahl wird genau dann nach true konvertiert, wenn sie weder Null (unbeachtlich ihres Vorzeichens) noch eine nicht darstellbare Zahl (NaN) ist. •Eine Knotenmenge ergibt true, wenn sie nicht leer ist. •Eine Zeichenkette ergibt true, wenn sie nicht leer (d.h. Länge größer Null) ist. •Die Konvertierung anderer Typen ist typabhängig, und nicht durch den Standard festgelegt boolean not (boolean) Negiert das übergebene Argument boolean true() Liefert statisch den Wert true boolean false() Liefert statisch den Wert false boolean lang (string) Liefert true wenn der aktuelle Knoten ein xml:lang-Attribut gemäß der als Argument übergebenen Sprache besitzt

Tabelle 22: Zahlenorientierte XPath-Funktionen

Funktionsprototyp Funktionalität number number (object?) Konvertiert ein Objekt in eine Zahl gemäß folgender Regeln: •Eine Zeichenkette wird in eine Fließkommazahl gemäß IEEE 754 konvertiert, wenn sie aus einem optionalen Leerzeichen, gefolgt durch ein optionales Minuszeichen, gefolgt von einem optionalen Leerzeichen und einer Ziffernfolge besteht. •Der Boole'sche Wert true wird zu 1, der Wert false zu 0 konvertiert. •Eine Knotenmenge wird zunächst in eine Zeichenkette übersetzt, und dann gemäß der oben definierten Regeln umgesetzt. •Die Konvertierung anderer Typen erfolgt typabhängig, und ist nicht durch den Standard geregelt. Wird kein Argument übergeben, so wird stattdessen der aktuelle Knoten als einziges Element einer Knotenmenge interpretiert. number sum (node-set) Liefert die Summe aller Elemente der übergebenen Knotenmenge, die zuvor in eine Zahl konvertiert werden. number floor (number) Liefert die größte ganze Zahl, die nicht größer als das Argument ist. Anmerkung: Entspricht dem Abschneiden beliebiger Nachkommastellen number ceiling (number1) Liefert die kleinste ganze Zahl, die nicht kleiner als das Argument ist. Anmerkung: Entspricht floor(number1+0.999...) number round (number) Liefert das Argument auf die nächste ganze Zahl gerundet. Gibt es zwei solche -- wie bei Nachkommastelle gleich 0.5 immer der Fall -- so wird die größere zurückgeliefert.

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

Tabelle 23: Mathematische Operatoren

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

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

Beispiel 38: Erweiterte Projektverwaltung

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

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

Übung 2: Einige Übungen

Welches Ergebnis liefern folgende XPath-Ausdrücke? (a) //Person[//child::Qualifikationsprofil]/Nachname (b) //Person[parent::ProjektVerwaltung]/Vorname[following-sibling::Vorname] (c) /ProjektVerwaltung/Person[attribute::PersID='Pers01']//Nachname Wie muß ein XPath-Ausdruck lauten, um folgendes zu selektieren? (d) Selektion aller Personen mit Nachnamen „Obermüller“. (e) Selektion aller Nachnamen von Personen die über mehr als eine Qualifikation verfügen. (f) Selektion der Nachnamen aller Projektleiter.

Anwendungsbeispiel: Integritätsbedingungen in XML-Schema

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

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

(1)<xsd:unique name="aName">
(2)	<xsd:selector xpath="aValidXPath"/>
(3)	<xsd:field xpath="aFieldStatement"/>
(4)	... 
(5)</xsd:unique>

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

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

Beispiel 39: Unique-Einschränkung

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xsd:schema (3) xmlns:xsd="http://www.w3.org/2001/XMLSchema" (4) elementFormDefault="qualified" (5) attributeFormDefault="unqualified"> (6)<xsd:element name="ProjektVerwaltung"> (7) <xsd:complexType> (8) <xsd:sequence> (9) <xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/> (10) <xsd:element name="Projekt" type="ProjektType" maxOccurs="unbounded"/> (11) </xsd:sequence> (12) <xsd:attribute name="version" type="xsd:string" fixed="1.0"/> (13) </xsd:complexType> (14) <xsd:unique name="uniquenessPersID"> (15) <xsd:selector xpath="Person"/> (16) <xsd:field xpath="@PersID"/> (17) </xsd:unique> (18)</xsd:element> (19) (20)<xsd:complexType name="PersonType"> (21) <xsd:attribute name="PersID" type="xsd:token"/> (22)</xsd:complexType> (23) (24)<xsd:complexType name="ProjektType"/> (25) (26)</xsd:schema> Download des Beispiels

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

Beispiel 40: Zusammengesetzter Schlüssel innerhalb eines unique-Elements

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xsd:schema (3) xmlns:xsd="http://www.w3.org/2001/XMLSchema" (4) elementFormDefault="qualified" (5) attributeFormDefault="unqualified"> (6)<xsd:element name="ProjektVerwaltung"> (7) <xsd:complexType> (8) <xsd:sequence> (9) <xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/> (10) <xsd:element name="Projekt" type="ProjektType" maxOccurs="unbounded"/> (11) </xsd:sequence> (12) <xsd:attribute name="version" type="xsd:string" fixed="1.0"/> (13) </xsd:complexType> (14) <xsd:unique name="uniquenessPersID"> (15) <xsd:selector xpath="Person"/> (16) <xsd:field xpath="Vorname"/> (17) <xsd:field xpath="Nachname"/> (18) </xsd:unique> (19)</xsd:element> (20) (21)<xsd:complexType name="PersonType"> (22) <xsd:sequence> (23) <xsd:element name="Vorname" type="xsd:token" minOccurs="1" maxOccurs="unbounded"/> (24) <xsd:element name="Nachname" type="xsd:token" maxOccurs="1"/> (25) </xsd:sequence> (26)</xsd:complexType> (27) (28)<xsd:complexType name="ProjektType"/> (29) (30)</xsd:schema> Download des Beispiels

Zur Realisierung von wertdefinierenden Schlüsselbeziehungen bietet XML-Schema die Elemente key und keyref an. Sie werden verwendet um sicherzustellen, daß ein Element oder Attribut nur einen Wert annehmen darf, der bereits an anderer Stelle im Instanzdokument auftritt.
Hierzu lokalisiert key auf der Basis eines XPath-Ausdruckes eine Referenzmenge, während keyref diejenige Knotenmenge lokalisiert, in der ausschließlich Elemente der Referenzmenge enthalten sein dürfen.
Das Beispiel zeigt die Anwendung auf das Element ProjektVerwaltung. Der mit projectKey benannte Schlüssel definiert die Referenzmenge als das Ergebnis der Anfrage Projekt/@ID, worauf die projectReference Bezug nimmt.

Beispiel 41: Schlüsselbasierte Referenzierung

(1)<?xml version="1.0" encoding="UTF-8"?> (2)<xsd:schema (3) xmlns:xsd="http://www.w3.org/2001/XMLSchema" (4) elementFormDefault="qualified" (5) attributeFormDefault="unqualified"> (6) <xsd:element name="ProjektVerwaltung"> (7) <xsd:complexType> (8) <xsd:sequence> (9) <xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/> (10) <xsd:element name="Projekt" type="ProjektType" maxOccurs="unbounded"/> (11) </xsd:sequence> (12) <xsd:attribute name="version" type="xsd:string" fixed="1.0"/> (13) </xsd:complexType> (14) (15) <xsd:key name="projectKey"> (16) <xsd:selector xpath="Projekt"/> (17) <xsd:field xpath="@ID"/> (18) </xsd:key> (19) <xsd:keyref name="projectReference" refer="projectKey"> (20) <xsd:selector xpath="Person"/> (21) <xsd:field xpath="@mitarbeitInProjekt"/> (22) </xsd:keyref> (23) </xsd:element> (24) (25) <xsd:complexType name="PersonType"> (26) <xsd:attribute name="mitarbeitInProjekt" type="xsd:token"/> (27) </xsd:complexType> (28) <xsd:complexType name="ProjektType"> (29) <xsd:attribute name="ID" type="xsd:token"/> (30) </xsd:complexType> (31)</xsd:schema> Download des Beispiels

	Web-Referenzen 8: Weiterführende Links
	•XPath Spezifikation •Deutsche Übersetzung der XPath-Spezifikation •XPath Visualisierer (Java-basiert) •Visual XPath (.NET Windows-Applikation) Originalbezugsquelle •XPath Explorer (Java-basiert) Originalbezugsquelle •Online Experimentieren mit XPath

Motivation

Häufig besteht der Wunsch oder die Notwendigkeit, auf bereits vorliegende Datenbestände, die durch ein Datenbankmanagementsystem (DBMS) verwaltet werden, in einer Applikationsprogrammiersprache zuzugreifen. Dabei soll die Anbindung der benötigten Datenquelle nicht problemspezifisch wieder und wieder neu entwickelt werden, sondern sollte sich auf ähnliche Datenanbindungsprobleme übertragen lassen.
Vor diesem Hintergrund liegt es nahe, sich an den Typen der verfügbaren und kommerziell bedeutsamen DBMS zu orientieren und herstellerspezifische Entwicklungen außer Acht zu lassen. Gleichzeitig offenbaren sich hierbei Standardisierungsbemühungen wie die Sprache SQL zum Zugriff auf relationale DBMS als lohnenswerter Ansatz der Etablierung einer generischen und übertragbaren Schnittstelle.

Die Idee zur Schaffung einer solchen generischen Schnittstelle für den Zugriff auf relationale DBMS geht zurück auf eine Initiative der SQL Access Group, welche später in der Vereinigung mit der X/Open Group aufging, die zwischenzeitlich in Open Group umbenannt wurde. Das dort konzipierte programmiersprachenunabhängige SQL Call Level Interface (SQL/CLI) konnte sich dank der Umsetzung unter dem Namen Open Database Connectivity (ODBC) durch die Firma Microsoft und die parallel erfolgte internationale Normierung unter dem Titel SQL/CLI breit am Markt etablieren.

Die für die Programmiersprache Java adaptierte Variante des Zugriffs auf relationale DBMS wird durch SUN Microsystems unter dem Namen Java Database Connectivity (JDBC) propagiert und stellt eine auf ODBC konzeptionell aufbauende und auf die spezifischen Bedürfnisse dieser Applikationsprogrammiersprache optimierte Untermenge des SQL/CLI-Standards dar.

Konzept und Grundidee

Von den Vorgängeransätzen übernommene Grundidee der Schnittstelle ist es den physischen Zugriff auf das Datenbankmanagementsystem durch eine von der Applikation spearierte wiederverwendbare Softwarekomponente, den sog. JDBC-Treiber, abzuwickeln.

Dieser Treiber vermittelt zwischen der Javaapplikation und dem verwendeten DBMS. Hierbei muß für jedes DBMS ein auf es abgestimmter JDBC-Treiber verwendet werden, da lediglich die Schnittstelle zur Applikation, nicht jedoch die zum DBMS, standardisiert ist.

Diesem Treiber obliegt die Abwicklung der gesamten Kommunikationsvorgänge mit dem DBMS. Er setzt jedoch selbst keine datenbankspezifischen Funktionalitäten, wie Syntax- oder Plausibilitätsprüfungen der übermittelten Kommandos um. Etwaige Fehlerprüfungen können, ebenso wie Anfrageoptimierungen, daher erst seitens des DBMS vorgenommen werden.
Der Vorteil dieses Vorgehens liegt in der Generizität des JDBC-Treibers. Er kann ohne aufwendige Logikanteile als reine uninterpretierende Vermittlungsschicht zwischen Applikation und DBMS umgesetzt werden, wodurch schlanke Implementierungen ermöglicht werden.

Die JDBC-Spezifikation detailliert den Treiberbegriff zusätzlich hinsichtlich der gewählten technischen Umsetzung aus. So werden die vier in Abbildung 3 dargestellten Treibertypen gemäß ihrer Charakteristika beschrieben und unterschieden.

Abbildung 3: JDBC-Treibertypen

(click on image to enlarge!)

Die historisch älteste Variante bildet der Typ 1 Treiber. Strenggenommen verkörpert er selbst keinen Datenbanktreiber, sondern lediglich eine Umsetzungsschicht die einem existierenden ODBC-Treiber vorgeschaltet wird.
Die Abbildung belegt diesen Treibertyp daher mit dem Begriff JDBC-ODBC-Bridge, da er lediglich den Brückenschlag zwischen den beiden Standards vornimmt und sich in der konkreten Anwendung auf die Umsetzung zwischen den beiden Protokollen beschränkt, ohne realen Zugriff auf die Datenbank zu erhalten.
Dieser ist dem ODBC-Treiber vorbehalten, der im allgemeinen Falle mit einer weiteren Umsetzungsstufe kommuniziert, welche die generischen ODBC-Aufrufe in konkrete DBMS-spezifische wandelt.
Während sowohl der JDBC-ODBC-Brückentreiber als auch der ODBC-Treiber selbst für verschiedene DBMS verwendet werden können, muß für jedes konkrete DBMS eine herstellerspezifische, d.h. an das verwendete DBMS angepaßte, Bibliothek vorliegen.

Für den Fall eines Typ 2 Treibers entfällt diese durch ODBC geschaffene zusätzliche Indirektionsstufe zugunsten der Adaption der Konversionskomponente, welcher die Wandlung der Aufrufe in das DBMS-native Protokoll obliegt, an das JDBC-Protokoll und ihrer Integration in den JDBC-Treiber selbst.
Die Natur der Kommunikation des Java-Anteils des Treibers mit den Nativen ist im Rahmen der durch die JDBC-Spezifikation gegebenen Definition nicht festgelegt.
Durch die integration der DBMS-nativen Treiberanteile in den JDBC-Treiber muß dieser für jedes anzusprechende DBMS neu erstellt werden. Eine Wiederverwendung der JDBC-spezifischen Anteile, die für die Clientkommunikation eingesetzt werden, kann hierbei nicht erfolgen.

Der Fall der (partiellen) Konkretisierung dieser Kommunikationsbeziehung zu einem beliebigen DBMS-neutralen Protokoll wird durch einen Typ 3 Treiber aufgegriffen.
Hier wird die DBMS-spezifische Komponente (in der Abbildung grau dargestellt) als vom JDBC-Treiber separiertes Modul aufgefaßt, daß mit diesem mittels eines festgelegten neutralen Protokolls kommuniziert.
Durch diese Separierung, die auch durch Installation auf physisch getrennten Maschinen --- der DBMS-spezifische Anteil könnte beispielsweise auf einem Middleware-Server untergebracht werden --- fundiert werden kann, gelingt die Wiederverwendung des JDBC-Treiberanteils, der mit verschiedenen DBMS-spezifischen Bibliotheken über das gewählte Protokoll kommunizieren kann.

Der Typ 4 Treiber stellt die letzte durch die JDBC-Spezifikation vorgesehene Ausprägung dar. Er konzipiert eine vollständig in Java implementierte Zugriffsschicht, die in sich geschlossen ist. Sie besitzt daher lediglich die notwendige JDBC-Schnittstelle zur Kommunikation mit der Java-Applikation und eine DBMS-Spezifische zum Zugriff auf die Datenquelle.
Die Vorteile dieser Architekturvariante liegen in ihrer Portabilität und den geringen Installations und Wartungsaufwänden, die aus der Reduktion der Kommunikationsbeziehungen resultieren. So kann ein solcher Treiber durch einfache Integration in die Java-Applikation verwendet werden und bedarf keiner Installationen oder Modifikationen an der verwendeten Ausführungsumgebung.
Gleichzeitig offenbart sich diese Lösung jedoch als technisch aufwendig in der Umsetzung, sobald DBMS verschiedener Hersteller angesprochen werden sollen, da die JDBC-Anteile des Treibers nicht separat wiederverwendet werden können.

Hinsichtlich des Laufzeitverhaltens zeigt sich deutlich die Schwäche der Typ 1 Treiber, welche in der inhärent notwendigen Doppelkonversion (JDBC zu ODBC und ODBC zu nativem Aufruf) begründet liegt. Daher sind Treiber dieses Typs als Übergangserscheinung hin zu „echten“ JDBC-Treibern, d.h. Treibern der restlichen Typen, anzusehen und sollten in Produktivumgebungen nicht eingesetzt werden.
Die Vorteile der Typ 2 und 3 Treiber seitens der Ausführungsgeschwindigkeit liegen in den nativen Codeanteilen begründet, welche für das jeweilige verwendete DBMS optimiert werden können.
Zwar spricht der leichte Installations- und Adminstrationsaufwand eindeutig für Typ 4 Treiber, jedoch fallen diese in ihrer Leistungsfähigkeit durch die ausschließliche Verwendung der Programmiersprache Java teilweise deutlich hinter Treiber des Typs 2 und 3, mit unter sogar hinter solche des Typs 1, zurück. Sie verkörpern jedoch den aus konzeptioneller Sicht zu bevorzugenden Ansatz hinsichtlich Portabilität und Vergleichbarkeit der erzielten quantitativen Ergebnisse.
Typischerweise kommen im produktiven Einsatz jedoch Treiber der Typen 2 und 4 zum Einsatz, die entweder durch den Hersteller des DBMS mitgeliefert werden (Typ 2) oder auf der Basis publizierter Schnittstellen plattformunabhängig für genau ein spezifisches DBMS entwickelt wurden (Typ 4).

Generell formuliert das JDBC-Konzept auf dieser Ebene noch keine Einschränkung hinsichtlich der unterstützten DBMS-Typen und ist generell auf verschiedenste Datenquellen anwendbar. Durch die Struktur des API und die verfügbaren Treiber kristallisieren sich jedoch relationale DBMS als Hauptanwendungsgebiet dieser Zugriffsschnittstelle heraus.

Im folgenden wird die Verwendung des Typ 4 Treibers Connector/J im Zusammenspiel mit dem RDBMS MySQL betrachtet.

Die Beispiele basieren auf einer Demodatenbank, deren Struktur und Inhalte nachfolgend angegeben sind.

Die Tabelle EMPLOYEE

+----------+-------+---------+-----------+------------+--------------------------+------+----------+-----------+------+
| FNAME    | MINIT | LNAME   | SSN       | BDATE      | ADDRESS                  | SEX  | SALARY   | SUPERSSN  | DNO  |
+----------+-------+---------+-----------+------------+--------------------------+------+----------+-----------+------+
| John     | B     | Smith   | 123456789 | 1965-01-09 | 731 Fondren, Houston, TX | M    | 30000.00 | 333445555 |    5 |
| Franklin | T     | Wong    | 333445555 | 1955-12-08 | 638 Voss, Houston, TX    | M    | 40000.00 | 888665555 |    5 |
| Joyce    | A     | English | 453453453 | 1972-07-31 | 5631 Rice, Houston, TX   | F    | 25000.00 | 333445555 |    5 |
| Ramesh   | K     | Narayan | 666884444 | 1962-09-15 | 975 Fire Oak, Humble, TX | M    | 38000.00 | 333445555 |    5 |
| James    | E     | Borg    | 888665555 | 1937-11-10 | 450 Stone, Houston, TX   | M    | 55000.00 |      NULL |    1 |
| Jennifer | S     | Wallace | 987654321 | 1941-06-20 | 291 Berry, Bellaire, TX  | F    | 43000.00 | 888665555 |    4 |
| Ahmad    | V     | Jabbar  | 987987987 | 1969-03-29 | 980 Dallas, Houston, TX  | M    | 25000.00 | 987654321 |    4 |
| Alicia   | J     | Zelaya  | 999887777 | 1968-07-19 | 3321 Castle, Spring, TX  | F    | 25000.00 | 987654321 |    4 |
+----------+-------+---------+-----------+------------+--------------------------+------+----------+-----------+------+

Umsetzung in der Java-API

Das Klassendiagramm der Abbildung 4 zeigt die zentralen Klassen des Paketes java.sql.
Auffallend ist, daß alle Elemente des dargestellten Pakets -- abgesehen von den definierten Exceptionklassen -- als Schnittstellen ausgelegt sind. Durch diese Mimik wird die Organisation der JDBC-Schnittstelle deutlich. Die API legt lediglich das Verhalten hinsichtlich seiner Semantik und die Einzeloperationen durch Definition ihrer Parameter fest, die konkrete DBMS-spezifische Implementierung dieser Operationen wird durch den JDBC-Treiber bereitgestellt.

Zentrale Klasse der JDBC-API ist die Schnittstelle Connection. Sie bildet die Kommunikationsverbindungen zum DBMS ab und bietet notwendige Verwaltungsoperationen.
Hierunter fallen insbesondere auch die Aufrufe zur Transaktionssteuerung.

Die Schnittstelle Statement realisiert genau eine aus Javasicht atomare Datenbankaktion. Diese muß hierbei aus minimal einem Aufruf an das DBMS bestehen, kann aber eine Reihe separater Aufrufe zu einem Batch bündeln.
Als Sonderform sieht die API die Spezialisierung PreparedStatement vor, die es gestattet, parametrisierte Anfragen zwischenzuspeichern, die nach Belegung der Parameterfelder an das DBMS übergeben werden. Hierdurch wird ein einfacher Mechanismus zur Wiederverwendung von DBMS-Aufrufen etabliert.

Liefert eine DBMS-Anfrage Ergebnistupel, so werden diese konform zur Schnittstelle ResultSet verwaltet. Diese Schnittstelle erlaubt die lesende Traversierung der vom DBMS gelieferten Tupel ebenso wie ihre Aktualisierung im Hauptspeicher und das anschließende Zurückschreiben in die Datenbank.
Die in der Abbildung nur durch getXXX und updateXXX angedeuteten Operationen existieren in Ausprägungen für alle unterstützten Datentypen, wobei XXX den Namen des Typs bezeichnet.

Ferner definiert die API mit SQLWarning eine Ausnahme zur Behandlung auftretender Fehlersituationen sowie eine Reihe weiterer, in der Abbildung 4 nicht dargestellter Klassen wie beispielsweise verschiedene Datentypen.

Die Klasse SQLException bietet durch ihre Methoden getErrorCode und getSQLState Möglichkeiten an um die nähere Ursache eines datenbankseitigen Fehlers zu ermitteln.
Zusätzlich gestatten Objekte dieses Ausnahmetyps die Verschachtelung von Ausnahmen, d.h. die rekursive Einbettung eines Ausnahmeereignisobjekts in ein bestehendes. Auf diesem Wege können aufgetretene Fehler durch mehrere Ausnahmeobjekte näher spezifiziert werden.
Beispiel 42 zeigt die Abfrage von Details der empfangenen und aller eingebetteten Ausnahmeereignisobjekte mittels der durch die JDBC-API vorgesehenen Methoden.

	Beispiel 42: Ermittlung von Fehlerdetails
	(1)try { (2) // JDBC code (3)} catch (SQLException e) { (4) while (e != null) { (5) System.err.println("SQLState: " + e.getSQLState()); (6) System.err.println("Message: " + e.getMessage()); (7) System.err.println("Vendor: " + e.getErrorCode()); (8) System.err.println("-----"); (9) e = e.getNextException(); (10) } (11)} Download des Beispiels

Mit der Version 1.4 der Java-Standard-Edition wurde die zuvor nur in der JDBC-API zur Verfügung stehende Möglichkeit zur Schachtelung von Ausnahmeereignissen auch für beliebige Ausnahmeereignisobjekte des Typs Throwable definiert.
Anders als die JDBC-API sieht die generische Lösung jedoch die Nutzung der Methode getCause zur Extraktion der eingebetteten Ausnahmeereignisobjekte vor.
Der Code des Beispiels 43 spiegelt daher die Standard-API-konforme Realisierung wieder. Zusätzlich wendet die Lösung die Standard-Methode getMessage zur Ermittlung der deskriptiven Fehlerbeschreibung an.

	Beispiel 43: Standard-API-konforme Ermittlung von Fehlerdetails
	(1)try { (2) // Normal code (3)} catch (SQLException e) { (4) Throwable t = e; (5) while (t != null) { (6) System.err.println("Type: " + t.getClass().getName()); (7) System.err.println("Message: " + t.getMessage()); (8) System.err.println("-----"); (9) t = t.getCause(); (10) } (11)} Download des Beispiels

Abbildung 4: Zentrale JDBC-Klassen der Java-API

(click on image to enlarge!)

Zugriff auf die Datenbank

Beispiel 44 zeigt den Ablauf zur Aufnahme einer Verbindung mit der Datenbank jdbctest auf dem lokalen Rechner (localhost).

Zunächst muß die Klasse des gewählten JDBC-Treibers (im Beispiel com.mysql.jdbc.Driver vor ihrer Verwendung geladen werden. Dies geschieht durch den Aufruf der statischen Methode forName auf der Klasse Class.
Der zu ladende Treiber muß hierbei die JDBC-Schnittstellenklasse Driver implementieren um später durch die JDBC-API verwendet werden zu können.
Gleichzeitig mit dem dynamischen Ladevorgang erfolgt die Registrierung des Treibers beim JDBC-DriverManager, der die Verwaltung der geladenen DB-Treiber übernimmt.

Nach dem erfolgreichen Laden des Treibers wird durch den Aufruf von getConnection (Zeile 16) die Verbindung zur Datenbank hergestellt. Die anzusprechende Datenbank wird hierbei durch eine URI der Form jdbc:mysql://DB-Server/DB-Name repräsentiert (Zeile 17). Zusätzlich können ein zur Anmeldung am DB-System benötiger Benutzer (Zeile 18) und sein Paßwort (Zeile 19) übergeben werden.

Beispiel 44: Aufbau einer Datenbankverbindung

(1)import java.sql.DriverManager; (2)import java.sql.SQLException; (3)import com.mysql.jdbc.Connection; (4) (5)public class JDBCConnect { (6) public static void main(String[] args) { (7) try { (8) Class.forName("com.mysql.jdbc.Driver"); (9) } catch (ClassNotFoundException e) { (10) System.err.println("Driver class not found"); (11) e.printStackTrace(); (12) } (13) Connection con = null; (14) try { (15) con = (16) (Connection) DriverManager.getConnection( (17) "jdbc:mysql://localhost/jdbctest/", (18) "mario", (19) "thePassword"); (20) } catch (SQLException e1) { (21) System.err.println("Error establishing database connection"); (22) Throwable t = e1; (23) while (t != null) { (24) System.err.println("Type: " + t.getClass().getName()); (25) System.err.println("Message: " + t.getMessage()); (26) System.err.println("-----"); (27) t = t.getCause(); (28) } (29) } (30) } (31)} Download des Beispiels

Zusätzlich stellen die Klassen Driver und DriverManager die Möglichkeit der Abfrage von verbindungsunabhängigen Verwaltungsinformationen zur Verfügung.

Beispiel 45: Ermittlung von Informationen über Treiber und Treibermanager

(1)import java.sql.Driver; (2)import java.sql.DriverManager; (3)import java.util.Enumeration; (4) (5)public class JDBCDriver { (6) (7) public static void main(String[] args) { (8) try { (9) Class.forName("com.mysql.jdbc.Driver"); (10) } catch (ClassNotFoundException e) { (11) System.err.println("Driver class not found"); (12) e.printStackTrace(); (13) } (14) (15) System.out.println( (16) "DriverManager:\nlogin timeout=" + DriverManager.getLoginTimeout()); (17) (18) Enumeration e = DriverManager.getDrivers(); (19) while (e.hasMoreElements()) { (20) Driver drv = (Driver) e.nextElement(); (21) (22) System.out.println( (23) "Driver=" (24) + drv.getClass().getName() (25) + "\nmajor version=" (26) + drv.getMajorVersion() (27) + "\nminor version=" (28) + drv.getMinorVersion() (29) + "\nJDBC compliant=" (30) + drv.jdbcCompliant()); (31) } (32) (33) } (34)} Download des Beispiels Download der Ergebnisdatei

Beispiel 45 zeigt die Ermittlung des durch den DriverManager für alle durch ihn verwalteten Treiber global definierten Login Timouts, der angibt wie lange beim Anmeldevorgang an der Datenbank auf eine Rückmeldung gewartet wird.
Zusätzlich werden für alle verwalteten Treiber der Klassenname sowie Daten zur Version und zum Stand der JDBC-Unterstützung ermittelt und ausgegeben.
Der JDBC-Unterstützungsstand gibt an, ob ein gegebener Treiber die Konformitätstests der Firma SUN bestanden hat. Voraussetzung hierfür ist u.a. die vollständige Unterstützung des SQL 92-Standards (entry level).
Diese Interpreatation von Spezifikationskonformität verwundert etwas, da alle JDBC-Treiber mit Ausnahme der inhärent DB-neutralen Typ 1 Treiber DBMS-spezifisch realisiert sind. Aus diesem Grunde bewertet der Konformitätstest vielmehr den Umsetzungsgrad des SQL-Standards in dem via JDBC genutzten DBMS als die Güte des JDBC-Treibers selbst.

Seit der JDBC-Schnittstellenversion 2 ist neben der „klassischen“ Zugriffsvariante auch eine auf dem Java Naming and Directory Interface (JNDI) basierende Zugriffsmethodik definiert, deren Verwendung --- abgesehen von der geänderten Mimik im Aufbau der DB-Verbindung --- identisch gestaltet ist.

Jedoch ist, wie in JNDI üblich, vor dem Zugriff ein benanntes Objekt beim JNDI-Dienst zu registrieren.
Im Falle von JDBC ist dies ein Objekt welches die Schnittstelle DataSource implementiert.

Der Code des Beispiels 46 zeigt die notwendigen Schritte zur Registrierung eines MysqlDataSource-Objekts, der durch den MySQL-JDBC-Treiber gelieferten Implementierung der Schnittstelle DataSource.

Beispiel 46: Ablage von Verbindungsinformation in einem JNDI-Verzeichnis

(1)import java.util.Hashtable; (2)import javax.naming.Context; (3)import javax.naming.InitialContext; (4)import javax.naming.NamingException; (5)import com.mysql.jdbc.jdbc2.optional.MysqlDataSource; (6) (7)public class JDBCConnect2Server { (8) (9) public static void main(String[] args) { (10) Hashtable env = new Hashtable(); (11) env.put( (12) Context.INITIAL_CONTEXT_FACTORY, (13) "com.sun.jndi.fscontext.RefFSContextFactory"); (14) env.put(Context.PROVIDER_URL, "file:/tmp/registry"); (15) (16) MysqlDataSource ds = new MysqlDataSource(); (17) ds.setDatabaseName("jdbctest"); (18) Context ctx = null; (19) try { (20) ctx = new InitialContext(env); (21) } catch (NamingException ne) { (22) ne.printStackTrace(); (23) } (24) (25) try { (26) ctx.rebind("jdbc/mySrc", ds); (27) } catch (NamingException ne) { (28) ne.printStackTrace(); (29) } (30) } (31)} Download des Beispiels

Entsprechend der modifizierten Ablage der Verwaltungsinformation ändert sich die Erzeugung der Datenbankverbindung beim Zugriff. Hier wird nun zunächst über einen Zugriff auf den JNDI-Verzeichnisdienst das benannte DataSource-Objekt (es trägt den Namen jdbc/mySrc ermittelt.
Anschließend wird durch das dem Verzeichnisdienst entnommene DataSource-Objekt die Datenbankverbindung (d.h. das Connection-Objekt) erzeugt.
Alle weiteren Schritte zur Interaktion mit der Datenbank verlaufen dann identisch zur im Beispiel 44 gezeigten Verbindungsaufnahme.
Der Code des Beispiels 47 zeigt die notwendigen Schritte zur Ermittlung der Referenz auf das Objekt des Typs DataSource aus dem JNDI-Verzeichnis, sowie die Erzeugung des Connection-Objekts.

Beispiel 47: Verbindungsaufbau unter Nutzung von JNDI

(1)import java.sql.Connection; (2)import java.sql.SQLException; (3)import java.util.Hashtable; (4)import javax.naming.Context; (5)import javax.naming.InitialContext; (6)import javax.naming.NamingException; (7)import javax.sql.DataSource; (8) (9)public class JDBCConnect2 { (10) public static void main(String[] args) { (11) Hashtable env = new Hashtable(); (12) env.put( (13) Context.INITIAL_CONTEXT_FACTORY, (14) "com.sun.jndi.fscontext.RefFSContextFactory"); (15) env.put(Context.PROVIDER_URL, "file:/tmp/registry"); (16) Context ctx = null; (17) try { (18) ctx = new InitialContext(env); (19) } catch (NamingException ne) { (20) ne.printStackTrace(); (21) } (22) DataSource ds = null; (23) try { (24) ds = (DataSource) ctx.lookup("jdbc/mySrc"); (25) } catch (NamingException ne) { (26) ne.printStackTrace(); (27) } (28) Connection con = null; (29) try { (30) con = ds.getConnection("mario", "thePassword"); (31) } catch (SQLException sqle) { (32) Throwable t = sqle; (33) while (t != null) { (34) System.err.println("Type: " + t.getClass().getName()); (35) System.err.println("Message: " + t.getMessage()); (36) System.err.println("-----"); (37) t = t.getCause(); (38) } (39) } (40) } (41)} Download des Beispiels

Auffallend ist die Ablage des Datenbanknamens im Verzeichnisdienst mittels des Methodenaufrufs setDatabaseName. Diese Verschiebung der Information wird durch die geänderte Mimik der Erzeugung des Connection-Objekts impliziert. So sieht die Implementierung dieser Methode für die Klasse DataSource keine Möglichkeit zur gleichzeitigen Übergabe von Anmeldenamen, Paßwort und Datenbank vor.
Vielmehrnoch ist es sogar möglich diese Daten allesamt innerhalb des JNDI-Verzeichnisdienstes abzulegen. (Für diesen Zweck stehen die Methoden setUser bzw. setPassword zur Verfügung.) Als Konsequenz hiervon kann der Verbinungswunsch durch Aufruf der Methode getConnection ohne weitere Parameter erfüllt werden.
Diese Umsetzungsweise ist vor ihrer Realisierung hinsichtlich des damit eintretenden Verlustes an Sicherheit zu prüfen, da in ihrer Folge eine Datenbankverbindung allein durch Kenntnis des JNDI-residenten Namens des DataSource-Objektes erfolgen kann.

Generell wählen JDBC-Umsetzungen den Weg, jede Ausprägung eines Connection-Objekts in eine physische Datenbankverbindung abzubilden. Dieses, durchaus der intuitiven Semantik der Connection-Klasse entsprechende Vorgehen kann jedoch in realen Applikationen, begründet in der Vielzahl der durch das DBMS zu verwaltenden Verbindungen, zu Zugriffsengpässen führen.
Aus diesem Grunde definiert die JDBC-Schnittstelle Operationen zur Zusammenfassung „gleichartiger“ Zugriffe. Hierzu zählen Zugriffe die unter derselben Nutzerkennung auf dieselbe Datenbank abgewickelt werden. Diese Zugriffsform tritt insbesondere bei Anwendungen auf, die über nur einen in der Datenbank eingetragenen Anwender verfügen und die gesamte Nutzerverwaltung datenbanktransparent applikationsseitig abwickeln.
Zur Optimierung von Zugriffen dieser Natur sieht die JDBC-Schnittstelle das sog. Connection Pooling vor, welches gleichartige Zugriffe bündelt.
Das Beispiel 48 zeigt eine Umsetzung:

Beispiel 48: Verbindungsaufbau unter Nutzung von Connection Pooling

(1)import java.sql.DriverManager; (2)import java.sql.SQLException; (3)import javax.sql.PooledConnection; (4)import com.mysql.jdbc.Connection; (5)import com.mysql.jdbc.jdbc2.optional.MysqlPooledConnection; (6) (7)public class JDBCConnection3 { (8) public static void main(String[] args) { (9) try { (10) Class.forName("com.mysql.jdbc.Driver"); (11) } catch (ClassNotFoundException cnfe) { (12) System.err.println("Driver class not found"); (13) cnfe.printStackTrace(); (14) } (15) Connection con = null; (16) try { (17) con = (18) (Connection) DriverManager.getConnection( (19) "jdbc:mysql://localhost/jdbctest/", (20) "mario", (21) "thePassword"); (22) } catch (SQLException e1) { (23) System.err.println("Error establishing database connection"); (24) Throwable t = e1; (25) while (t != null) { (26) System.err.println("Type: " + t.getClass().getName()); (27) System.err.println("Message: " + t.getMessage()); (28) System.err.println("-----"); (29) t = t.getCause(); (30) } (31) } (32) (33) PooledConnection pc = new MysqlPooledConnection(con); (34) (35) java.sql.Connection con1 = null; (36) try { (37) con1 = pc.getConnection(); (38) } catch (SQLException sqle) { (39) Throwable t = sqle; (40) while (t != null) { (41) System.err.println("Type: " + t.getClass().getName()); (42) System.err.println("Message: " + t.getMessage()); (43) System.err.println("-----"); (44) t = t.getCause(); (45) } (46) } (47) } (48)} Download des Beispiels

Statt für jede gewünschte Datenbankverbindung ein zusätzliches Objekt des Type Connection zu erzeugen, wird die erzeugte Verbindung zur Konstruktion eines Objektes, welches Konform zur Schnittstelle PooledConnection definiert ist, verwendet. Dieses sorgt für die Verwaltung der DB-Verbindung und stellt dieselbe physische Verbindung verschiedenen Anfragern zur Verfügung.
Konsequenterweise wird daher eine neue Verbindung nicht mehr vom DriverManager angefordert, sondern durch die Methode getConnection der aus der Verwaltungsstruktur entnommenen PooledConnection beantragt.

Aufgrund der Unterstützung des SQL-Sprachumfanges, durch unveränderte textuelle Propagation an das DBMS sind durch JDBC im Allgemeinen alle Facetten der Datenbanksprache nutzbar, sofern sie durch das verwendete DBMS Unterstützung finden. Hierunter fallen:

• Data Definition Language.
  Zur Erzeugung eines Datenmodells.
• Data Manipulation Language.
  Zur Modifikation der verwalteten Daten.
• Data Retrieval Language.
  Zur Anfrage der in einer Datenbank gespeicherten Daten.
• Data Control Language.
  Zur Festlegung und Kontrolle von Zugriffsberechtigungen.

JDBC reflektiert jedoch nicht diese Sprach(-sub-)klassen selbst in der API, sondern sieht vielmehr ausschließlich zwei Formen des Zugriffs vor. Solche die tabellenwerte Resultate liefern und solche, deren Ausführung lediglich primitivwertige Rückgabewerte liefert.

Primitivwertige Zugriffe

Primitivwertige Datenbankzugriffe liefern, abgesehen von Fehler- oder Warnmeldungen, lediglich die Anzahl der geänderten Tupel, falls zutreffend, oder 0 zurück.
Aus dieser Festlegung lassen sich diejenigen SQL-Anweisungstypen ableiten, welche als primitivwertiger Zugriff realisiert sind. Hierunter fallen alle Operationen der Datendefinition wie CREATE oder ALTER TABLE sowie alle Einfüge- (INSERT) Änderungs- (UPDATE) und Löschvorgänge (DELETE). Darüberhinaus alle Operationen zur Administration der Datenbank durch Rechtevergabe (GRANT, REVOKE).

Zugriffe dieser Art werden generell durch die Methode executeUpdate, oder einer Abart davon, realisiert.

Beispiel 49: Erstellung einer neuen Tabelle

(1)import java.sql.DriverManager; (2)import java.sql.SQLException; (3)import com.mysql.jdbc.Connection; (4)import com.mysql.jdbc.Statement; (5) (6)public class JDBCCreateTable { (7) public static void main(String[] args) { (8) try { (9) Class.forName("com.mysql.jdbc.Driver"); (10) } catch (ClassNotFoundException e) { (11) System.err.println("Driver class not found"); (12) e.printStackTrace(); (13) } (14) Connection con = null; (15) (16) try { (17) con = (18) (Connection) DriverManager.getConnection( (19) "jdbc:mysql://localhost/jdbctest/", (20) "mario", (21) "thePassword"); (22) } catch (SQLException e1) { (23) System.err.println("Error establishing database connection"); (24) Throwable t = e1; (25) while (t != null) { (26) System.err.println("Type: " + t.getClass().getName()); (27) System.err.println("Message: " + t.getMessage()); (28) System.err.println("-----"); (29) t = t.getCause(); (30) } (31) } (32) (33) Statement stmt = null; (34) try { (35) stmt = (Statement) con.createStatement(); (36) } catch (SQLException e2) { (37) System.err.println("Error creating SQL-Statement"); (38) Throwable t = e2; (39) while (t != null) { (40) System.err.println("Type: " + t.getClass().getName()); (41) System.err.println("Message: " + t.getMessage()); (42) System.err.println("-----"); (43) t = t.getCause(); (44) } (45) } (46) String createTab = new String("CREATE TABLE EMPLOYEE(" + (47) "FNAME VARCHAR(10) NOT NULL," + (48) "MINIT VARCHAR(1)," + (49) "LNAME VARCHAR(10) NOT NULL," + (50) "SSN INTEGER(9) NOT NULL," + (51) "BDATE DATE," + (52) "ADDRESS VARCHAR(30)," + (53) "SEX ENUM('M','F')," + (54) "SALARY REAL(7,2) UNSIGNED," + (55) "SUPERSSN INTEGER(9)," + (56) "DNO INTEGER(1));"); (57) try { (58) System.out.println("result="+stmt.executeUpdate(createTab)); (59) } catch (SQLException e3) { (60) System.err.println("Error creating table EMPLOYEE"); (61) Throwable t = e3; (62) while (t != null) { (63) System.err.println("Type: " + t.getClass().getName()); (64) System.err.println("Message: " + t.getMessage()); (65) System.err.println("-----"); (66) t = t.getCause(); (67) } (68) } (69) } (70)} Download des Beispiels Download der Ergebnisdatei

Beispiel 49 zeigt die notwendigen Schritte zur Erstellung der Tabelle EMPLOYEE in der Datenbank.

Nach dem (üblichen) Verbindungsaufbau (Zeile 8-24) wird in Zeile 27 eine Variable des Typs Statement deklariert. Auch bei Statement handelt es sich um eine durch die JDBC-API vordefinierte Schnittstelle, die als Bestandteil des JDBC-Treibers von einer Klasse implementiert wird.
Ausgehend von der etablierten Datenbankverbindung wird durch Aufruf der Methode createStatement eine konkrete Ausprägung konform zur Statement-Schnittstelle erzeugt (Zeile 29).

Der Aufruf von executeUpdate übergibt das als Zeichenkette abgelegte SQL-Kommando an die Datenbank zur Ausführung.
Da durch CREATE TABLE keine Tupeländerungen vorgenommen werden ist das Resultat des Aufrufs der Rückgabewert 0.

Beispiel 50 zeigt mit dem ALTER TABLE-Kommando eine weitere Anwendung der executeUpdate-Methode.
Auch in diesem Falle wird als Resultat 0 geliefert, da die Definition des Primärschlüssels keine Änderungen an den verwalteten Datensätzen vornimmt.

Beispiel 50: Modifikation der Tabellendefinition

(1)import java.sql.DriverManager; (2)import java.sql.SQLException; (3)import com.mysql.jdbc.Connection; (4)import com.mysql.jdbc.Statement; (5) (6)public class JDBCAlterTable { (7) public static void main(String[] args) { (8) try { (9) Class.forName("com.mysql.jdbc.Driver"); (10) } catch (ClassNotFoundException e) { (11) System.err.println("Driver class not found"); (12) e.printStackTrace(); (13) } (14) Connection con = null; (15) (16) try { (17) con = (18) (Connection) DriverManager.getConnection( (19) "jdbc:mysql://localhost/jdbctest/", (20) "mario", (21) "thePassword"); (22) } catch (SQLException e1) { (23) System.err.println("Error establishing database connection"); (24) Throwable t = e1; (25) while (t != null) { (26) System.err.println("Type: " + t.getClass().getName()); (27) System.err.println("Message: " + t.getMessage()); (28) System.err.println("-----"); (29) t = t.getCause(); (30) } (31) } (32) (33) Statement stmt = null; (34) try { (35) stmt = (Statement) con.createStatement(); (36) } catch (SQLException e2) { (37) System.err.println("Error creating SQL-Statement"); (38) Throwable t = e2; (39) while (t != null) { (40) System.err.println("Type: " + t.getClass().getName()); (41) System.err.println("Message: " + t.getMessage()); (42) System.err.println("-----"); (43) t = t.getCause(); (44) } (45) } (46) String createTab = (47) new String("ALTER TABLE EMPLOYEE ADD PRIMARY KEY (SSN);"); (48) try { (49) System.out.println("result=" + stmt.executeUpdate(createTab)); (50) } catch (SQLException e3) { (51) System.err.println("Error altering table EMPLOYEE"); (52) Throwable t = e3; (53) while (t != null) { (54) System.err.println("Type: " + t.getClass().getName()); (55) System.err.println("Message: " + t.getMessage()); (56) System.err.println("-----"); (57) t = t.getCause(); (58) } (59) } (60) } (61)} Download des Beispiels Download der Ergebnisdatei