Scriptum zur Vorlesung e-Business Engineering Motivation und Einführung Was ist e-Business?

Der Begriff des e-Business als Abkürzung des englischsprachigen electronic Business hat sich inzwischen als Subsumption aller für ein Unternehmen wertschöpfenden Aktivitäten im Internet eingebürgert.
Die Sinngebung greift damit weiter als der historisch ältere Begriff e-Commerce , welcher ursprünglich ausschließlich Verkaufsaktivitäten bezeichnete. Inzwischen werden beide Terme jedoch nahezu synonym verwendet. Teilweise findet sich für den Teilbereich des internetgestützten Verkaufs von Waren und Dienstleistungen an Endkunden auch die Bezeichnung e-tailing (für electronic retailing) welcher jedoch nur einen Teilaspekt des e-Commercebegriffes abzudecken vermag.

Electronic Business ist die Gesamtheit aller unternehmerischen Aktivitäten im Internet.

Gemäß dieser allgemeinen Definition werden sämtliche auf das Unternehmensziel gerichtete nach außen wirkende Aktivitäten als e-Business eingeordnet.
Gleichzeitig ergibt sich aus der Abstützung auf der Realisierungstechnik des Internets auch eine interne Sichtweise, sobald diese Technik innerhalb des Unternehmens zum Einsatz kommt.
Die Darstellung der unternimmt den Versuch der Einordnung der sich ergebenen Anwendungsdimensionen des e-Businessbegriffs.

Die naheliegendste Form des e-Business ist der Geschäftsverkehr mit dem (End-)Kunden, als dem typischen Konsumenten der durch ein Unternehmen zur Verfügung gestellten Güter und Dienstleistungen. Dieser Teilbereich wird mit dem Begriff Business-to-Customer (B2C) belegt.
In diese e-Businessvariante fallen alle Interaktionen zwischen Kunde und Unternehmen während des gesamten Lebenszyklus des angebotenen Produkts, angefangen von verkaufsfördernden Maßnahmen (Marketing) über den Verkaufs- bzw. Dienstleistungserbringungsakt selbst bis hin zur Abwicklung der Wartung, soweit nach Art des angebotenen Gutes elektronisch überhaupt möglich.

Entgegengesetzt zum durch ein Unternehmen produzierten ausgehenden Güter- und Dienstleistungsstrom verläuft die Beschaffung von nicht-menschlichen Produktionsfaktoren wie Roh-, Hilfs- und Betriebsstoffen sowie die Interunternehmenskommunikation. Dieser Teilbereich wird mit dem Begriff Business-to-Business (B2B) belegt.
In diese e-Businessvariante fallen die zwischen Unternehmungen ablaufenden elektronischen Kommunikationen. Die Spannbreite reicht hierbei von der kostenfrei nutzbaren statischen Präsentation des Güter- und Dienstleistungsangebots im Stile eines Katalogs über spezialisierte Marktplätze mit Angebots- und Nachfragefunktionalitäten bis hin zu Informationsdienstleistungen welche Zugriff auf die datenhaltenden Systeme des Geschäftspartners gewähren.

Die umfassende Betrachtung der zuvor ausgeklammerten Kommunikation mit potentiellen und bestehenden Mitarbeitern konstituiert die dritte Klasse der e-Businessanwendungen, welche auf die unternehmensinterne Kommunikation mit den Mitarbeitern fokussieren. Dieser Teilbereich wird mit dem Begriff Business-to-Employee (B2E) belegt.
Dieser Sparte werden alle elektronischen Informationsangebote an den Mitarbeiter, wie Auskunft über den aktuellen Gleitzeitstand, Adressstamm- sowie Gehaltsdaten, zugeordnet.

Relevante Techniken und ihre Einordnung

Orthogonal zu den drei Anwendungsdimensionen verdient die ebenfalls in dargestellte Realisierungstechnik Betrachtung.
Hierunter fallen gemäß alle sog. Internettechniken .

Dieser, in der Praxis nicht klar definiert und trennscharf gebrauchte Begriff umfaßt sowohl die Internetbasistechniken zur Datendarstellung und -übertragung als auch verschiedene Techniken zur Realisierung von Anwendungen, die über das Internet angesprochen und benutzt werden können.

Im wesentlichen zielen die eingesetzten Techniken auf die Lösung spezifischer Problemstellungen. stellt die im Rahmen der Vorlesung behandelten Techniken nebst den durch sie betrachteten Problemgebieten und einer Kurzcharakteristik zusammen.

Problemdomäne Technik Charakteristik
Datendarstellung und -zugriff XML Generische Auszeichnungssprache zur Darstellung beliebiger Daten.
XML-Namensräume Syntaxmechanismus zur Unterscheidung von XML-Vokabularen.
XML-Schema Grammatiksprache zur Formulierung von XML-Vokabularen.
XPath Lokatorsprache zur Identikation von Knotenmengen in XML-Dokumenten.
Datenbankzugriff JDBC Durch SUN erarbeiteter Ansatz für den Zugriff auf tabellenartige Datenquellen.
Zumeist für den Zugriff auf relationale Datenbanken benutzt.
JDO Mechanismus zur transparenten Persistierung von Java-Objekten in verschiedenen Datenspeichern.
EJB Durch SUN erarbeitete Komponententechnik.
Hauptfocus in dieser Veranstaltung: Realisierung von Peristenz durch Entity Beans.
Funktionsintegration JMS Durch SUN für Java entwickelte Schnittstelle zur Verarbeitung asynchroner Nachrichten.
RMI Durch SUN für Java adaptierte Variante entfernter Funktionsaufrufe.
REST Interpretations- und Nutzungsvariante des HTTP-Protokolls zur Realisierung einfacher Web-Dienste.
Web Services Ansatz zur Bereitstellung von Funktionalität über das Web mittels Nachrichtenaustausch und entfernter Funktionsaufrufe.
Präsentationsaspekte XHTML und XForms Bekannteste Hypertextsprache und Ansatz zur Realisierung einfacher Web-basierter Eingabeoberflächen.
JSP Durch SUN erarbeiteter Ansatz zur dynamischen serverseitigen Erzeugung von Webseiten.
JSF Durch SUN erarbeiteter Ansatz zur vereinfachten Erstellung von GUI-basierten Web-Dialoganwendungen.
XSLT W3C-Standard zur Transformation von XML-Inhalten.
Sicherheitsaspekte Schlüsselaustausch Erzeugung und Verteilung geheimer und öffentlicher Daten, die den Zugriff auf gesicherte Daten gestatten.
Leitungssicherheit Bereitstellung transparenter Verbindungssicherung im Internet.
Digitale Signatur Sicherung von Datenkonsistenz, Glaubwürdigkeits des Ursprungs, Verbindlichkeit und Berechtigung.
Verschlüsselung Sicherung von Vertraulichkeit.
Architektur moderner e-Business Applikationen

ordnet die zuvor eingeführten Techniken in ein Architekturmodell für e-Business Applikationen ein.

Das Architekturmodell zeigt die im Rahmen der Vorlesung behandelten Techniken als Bestandteil einer hypothetischen Architektur. Sie zeigt die bevorzugten Einsatzbereiche der Einzeltechniken und gibt damit bereits einen Ausblick auf die gegenwärtig in der Praxis etablierte Pragmatik.
Besonders deutlich wird dies anhand der dargestellten Positionierung des Remote-Method-Invocation-Mechanismus. Zwar kann dieser grundsätzlich auch zur systemübergreifenden Kommunikation herangezogen werden. Jedoch wird RMI aktuell vorwiegend für die Realisierung systeminterner Kommunikationsbeziehungen, beispielsweise innerhalb J2EE-basierter Applikationsserver, herangezogen. Dies liegt in zwei Grundfaktoren begründet. Zum einen ist nur ein Teil der verfügbaren e-Business-Systeme unter Nutzung der Programmiersprache Java realisiert, worauf die RMI-Anwendbarkeit faktisch beschränkt ist. Zum anderen ist der RMI inhärent zugrundeliegende Zugriff auf binäre Applikationsschnittstellen unter Sicherheitsrestriktionen als problematisch anzusehen.

 Datendarstellung und -zugriff Extensible Markup Language -- Strukturelle Grundkonzepte

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. XML steht für strukturierte Daten.
    Diese Aussage betont die Rolle von XML als Sprache um Sprachen zu erzeugen. Nicht XML wird innerhalb verschiedenster Applikationen direkt verarbeitet, sondern XML basierte Formate. So steht nicht die XML selbst für all diese Anwendungsdomänen, sondern die jeweiligen problemspezifischen XML-basierten Sprachen. XML selbst dient lediglich der Strukturierung der verschiedensten darzustellenden Daten.
    Gleichzeitig rückt durch Aussage die Rolle der XML als Datenformat in den Vordergrund und läßt so die Weiterentwicklung gegenüber den präsentationsorientierten Vorläufern deutlich werden.
    Die Vorlesungskapitel Strukturelle Grundkonzepte 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.
Artikel in der Online-Ausgabe des Economist über Ted Nelson -- The Babbage of the web COT1800 Public Networks, Lecture 8, Standard Generalised Markup Language Brief History of Document Markup XML, Element Types, DTDs, and All That Clark, J.: Comparison of SGML and XML Browser Timelines Browser Emulator Eine Anwendung der Extensible Markup Language. Ein Vokabular, das aus Symbolen und der ihnen zugewiesenen Bedeutung (Semantik) gebildet wird, ergänzt um Regeln (grammatikalische Struktur und Gültigkeitsregeln für den Inhalt (z.B. Datentypen)) zur Kombination der Vokabularelemente.
Anwendungen einer so neu geschaffenen XML-Sprache L werden als XML-Dokumente, auch: L-Dokumente, bezeichnet. Strukturelle Grundkonzepte

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

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

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

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

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

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

Document Information Item

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

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

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

Die Encoding-Deklaration hat folgendes Aussehen :

               
                  

                     

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

                     

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

                     

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

                     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

               
                  

                     

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

                     

                        [41]
                        Attribute
                        ::=
                        Name Eq AttValue

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

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

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

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

               
                  

                     

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

                     

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

                     

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

                     

                        
                           [7]
                        
                        Nmtoken
                        ::=
                        (NameChar)+
                     

                     

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

Im Beispiel sind Vorlesung, Titel und Hochschule (normale) Elemente, während 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.

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 .

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

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

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

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

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

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

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

Character Information Item

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

Jedes Character Information Item stellt das im Dokument gegebene Zeichen gemäß ISO 10646-Codierung in der Eigenschaft character code dar. Die Werte können hierbei jedoch nur in den durch die Spezifikation vorgegebenen Grenzen variieren . Darüberhinaus genügt bereits die Unterstützung der UTF-8 und -16-Darstellung zur Erfüllung der Spezifikationsanforderungen an konforme Prozessoren.
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.

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

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

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

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

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

                  

                     

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

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

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

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

Processing Instruction Information Item

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

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

Die Syntax einer Processing Instruction lautet:

                  

                     

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

                     

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

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

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

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

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

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

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

Namespace Deklaration Information Item

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

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

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

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

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

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

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

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

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

siehe XML-Spezifikation

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

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

 XML-Namensräume Namensräume

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

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

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

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

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

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

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

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

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

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

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

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

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

                  

                     

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

                     

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

                     

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

                     

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

                     

                        [URI5]
                        opaque_part
                        ::=
                        uric_no_slash uric?
                     

                     

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

                     

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

                     

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

                     

                        
                           [URI8]
                        
                        abs_path
                        ::=
                        "/"  path_segments
                     

                     

                        [URI9]
                        rel_path
                        ::=
                        rel_segment abs_path?
                     

                     

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

                     

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

                     

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

                     

                        [URI12]
                        authority
                        ::=
                        server | reg_name
                     

                     

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

                     

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

                     

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

                     

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

                     

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

                     

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

                     

                        [URI17]
                        host
                        ::=
                        hostname | IPv4address
                     

                     

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

                     

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

                     

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

                     

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

                     

                        [URI22]
                        port
                        ::=
                        digit*
                     

                     

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

                     

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

                     

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

                     

                        [URI26]
                        param
                        ::=
                        pchar*
                     

                     

                        [URI27]
                        pchar
                        ::=
                        unreserved | escaped |
                     

                     

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

                     

                        [URI28]
                        query
                        ::=
                        uric*
                     

                     

                        
                           [URI29]
                        
                        fragment
                        ::=
                        uric*
                     

                     

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

                     

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

                     

                        
                        
                        
                        "$" | ","
                     

                     

                        [URI32]
                        unreserved
                        ::=
                        alphanum | mark
                     

                     

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

                     

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

                     

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

                     

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

                     

                        
                        
                        
                        "8" | "9"
                     

                     

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

                     

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

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

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

Exkurs: URIs, URLs, URNs ...

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

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

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

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

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

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

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

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

               
                  

                     

                        
                           [NS7]
                        
                        Präfix
                        ::=
                        NCName
                     

                     

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

                     

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

                     

                        
                        
                        
                        | CombiningChar
                        
                     

                     

                        
                        
                        
                        | Extender

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

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

                  

                     

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

angegeben.

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

               
                  

                     

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

                     

                        [NS8]
                        LocalPart
                        ::=
                        
                           NCName

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ein Element befindet sich in demjenigem Namensraum ...

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

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

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

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

Zusammenfassend gelten somit folgende Prinzipien:

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

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 2nd edition und den Namensräumen die Basis aller weiteren W3C-XML-Sprachstandards.

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

XSD bildet eine vollständig in XML-Syntax formulierte kontextfreie reguläre Grammatik zur Formulierung beliebiger XML-Strukturen ab. Hierbei handelt es sich um die bekannten Grundprimitive Element und Attribut
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:

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:

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:

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

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

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


XSD definiert ferner folgende Charakteristika für Elemente, die durch Attribute der Elementdeklaration ausgedrückt werden:

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

Nachfolgend sind einige Elementdeklarationen für unstrukturierten Inhalt versammelt

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

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

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

XSD prägt den bereits im Kontext der DTD genutzten Typbegriff (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:

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Download der XML-Datei mit dem Beispiel der Graphik

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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 Datenbankzugriff Java Database Connectivity (JDBC) 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 dargestellten Treibertypen gemäß ihrer Charakteristika beschrieben und unterschieden.

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 Treiber s 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 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 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 zeigt die Abfrage von Details der empfangenen und aller eingebetteten Ausnahmeereignisobjekte mittels der durch die JDBC-API vorgesehenen Methoden.

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 spiegelt daher die Standard-API-konforme Realisierung wieder. Zusätzlich wendet die Lösung die Standard-Methode getMessage zur Ermittlung der deskriptiven Fehlerbeschreibung an.

Zugriff auf die Datenbank

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

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

Beispiel 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 zeigt die notwendigen Schritte zur Registrierung eines MysqlDataSource-Objekts, der durch den MySQL-JDBC-Treiber gelieferten Implementierung der Schnittstelle DataSource.

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 gezeigten Verbindungsaufnahme.
Der Code des Beispiels zeigt die notwendigen Schritte zur Ermittlung der Referenz auf das Objekt des Typs DataSource aus dem JNDI-Verzeichnis, sowie die Erzeugung des Connection-Objekts.

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 zeigt eine Umsetzung:

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 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 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 zeigt den Einfügevorgang von acht Werten in die durch die vorangegangenen Beispiele erzeugte Tabelle EMPLOYEE.
Jeder der Einfügevorgänge der Zeilen 36-43 führt im Rahmen einer separaten Datenbankkommunikation sequentiell genau einen Einfügevorgang durch, was durch den Rückgabewert 1 dokumentiert wird.

Zwar ist dieses Verfahren praktikabel und erzielt die angestrebten Resultate, jedoch ist es unter Zeiteffizienzgesichtspunkten inadäquat, da sich Einfüge- und Kommunikationsvorgänge zahlenmäßig entsprechen.

Aus diesem Grunde bietet die Schnittstelle Statement die Möglichkeit zur Bündelung einzelner SQL-Aufrufe in einem sog. Batch an.

Beispiel zeigt die entsprechende Umgestaltung des vorangegangenen Beispiels.

Statt der Einzelübergabe der SQL INSERT-Anweisungen werden diese nun (in Zeile 36-43) in in einem Batch gesammelt. Hierzu werden die SQL-Zeichenketten durch den Aufruf addBatch innerhalb des Statement-Objekts abgelegt und durch Aufruf der Methode executeBatch gesammelt an das DBMS übergeben.
Statt der Einzelresultate wird durch diese Aufrufvariante ein Array geliefert, das die Einzelrückgabewerte der als Batch übergebenen Aufrufe versammelt.

Dies verdeutlicht nochmals das nachfolgende Beispiel. In ihm wird zunächst mittels ALTER TABLE eine neue Tabellenspalte zur Aufnahme des Wochentages der Geburt erstellt und anschließend durch SQL UPDATE-Anweisungen die benötigten Daten aus dem vorhandenen Geburtsdatum ermittelt.
Auch dieses Beispiel bedient sich zur Performancebeschleunigung der Möglichkeiten des Batchaufrufes.

Die Ausführung liefert als Resultat:

Statement No 0 changed 8 rows
Statement No 1 changed 0 rows
Statement No 2 changed 1 rows
Statement No 3 changed 0 rows
Statement No 4 changed 1 rows
Statement No 5 changed 1 rows
Statement No 6 changed 2 rows
Statement No 7 changed 3 rows

So werden durch den ALTER TABLE-Aufruf (Indexnummer 0) alle acht Tupel der Tabelle modifiziert, während die nachfolgenden Aufrufe nur Teilmengen davon verändern.

Die nähere Betrachtung der Zeilen 37-43 des Quellcodes von Beispiel zeigt sich, daß diese im Kern denselben Vorgang ausführen, nur jeweils mit variierenden Parametern.
Zur Behandlung von Fällen dieser Problemstellung definiert die JDBC-API die Schnittstelle PreparedStatement als Spezialisierung von Statement.

Diese Schnittstelle gestattet es, Anweisungen, die später an die Datenbank übermittelt werden sollen, mit Platzhaltern zu versehen und diese vor der Übermittlung mit Werten zu befüllen.
Beispiel zeigt die entprechende Modifikation des vorangegangenen Beispiels.

Im Beispiel wird neben dem Objekt des Typs Statement zusätzlich eines des Typs PreparedStatement erzeugt (Zeile 32).
Die dem Konstruktor übergebene Anweisung enthält als Sonderzeichen zur Markierung der Platzhalter das Fragezeichen (?).
Die Wochentage werde in Zeile 40, des vereinfachten Zugriffs wegen, als Array definiert.
In den Zeilen 42 mit 46 werden die benötigten SQL-UPDATE-Anweisungen dynamisch durch Einsetzen der geeigneten Werte in den vorpräparierten Änderungsausruck erzeugt und einem eigenen Batch zugeordnet. Der Einsetzungsvorgang der benötigten Werte geschieht durch die Methoden setString für zeichenkettenartige bzw. setInt für den ganzzahlige Parameter. Den Methoden wird jeweils die Position des Parameters, gezählt ab 1 sowie die zu wählende Wertbelegung übermittelt.
Zur Ausführung müssen beide Batches getrennt angefordert werden.

Tabellenwertige Zugriffe

Die in der Praxis quantitativ bedeutendste Klasse von Datenbankzugriffen dürfte zweifellos auf die lesende Ermittlung von bestehenden Daten darstellen, kurzum alle Spielarten der SQL SELECT-Anweisung.

Für Anfragen an die Datenbank steht prinzipiell der gesamte durch das DBMS unterstützte SQL-Umfang zur Verfügung.

Anfragen werden im Gegensatz zu den bisher betrachteten lesenden Zugriffen nicht als primivwerte Methoden realisiert, sondern liefern als Resultat immer eine Tabelle zurück.
Diese wird durch den API-Typ ResultSet dargestellt.
Zusätzlich werden Anfragen durch die Methode executeQuery ausgeführt.

Das Beispiel zeigt die generische Extraktion von DB-Daten und den Zugriff auf Metadaten.
Die aus der Datenbank gelesenen Ergebnistupel werden im durch rs benannten ResultSet abgelegt (Zeile 39). Die Resultatmenge wird mithilfe eines Cursors (Datensatzzeiger) traversiert. Hierzu wird der initial auf eine Ausgangsstellung vor dem ersten empfangenen Tupel positionierte Cursor durch Aufruf der Methode next solange weitergerückt, bis der letzte Datensatz verarbeitet wurde.

Der Aufruf der MethodegetMetaData liefert deskriptive Metadaten wie Spaltenzahl sowie deren Bezeichner und Typen für die erstellte Resultattupelmenge.
In Zeile 43 werden diese Metadaten verwendet um die Spaltennamen der extrahierten Attribute anzuzeigen.
Zeile 47-52 liest die einzelnen Werte jedes Tupels mittels getObject aus und stellt sie am Bildschirm dar.

Neben im Beispiel gezeigten Verarbeitung in exakter der Ablagereihenfolge der Datenbank kann auch durch Definition eines Cursors die Traversierung in inverser Ablagerichtung erreicht werden.
Das nachfolgende Beispiel illustriert das entsprechende Vorgehen durch anfängliche Positionierung des Cursors ans Ende der empfangenen Daten (d.h. nach dem letzten Datensatz) und anschließendes schrittweises Rückpositionieren durch Aufruf der Methode previous.

Ferner kann der Cursor wahlfrei auf eine beliebige Position der Ergebnisrelation gesetzt werden.
Das nachfolgende Beispiel zeigt dies. Ferner illustriert es das Vorgehen zur Größenermittlung des resultierenden ResultSets durch das Aufrufpaar last und getRow, welches zunächst den Cursor auf den letzten aus der Datenbank extrahierten Datensatz positioniert und anschließend dessen Nummer liefert.

Wird der benötigte ResultSet geeignet (d.h. mit den Parameter CONCUR_UPDATABLE) (siehe Zeile 49) initialisiert, so können Änderungen, die im Hauptspeicher durch die JDBC-API durchgeführt werden, in die Datenbank persistiert werden.
Beispiel zeigt dies exemplarisch für den Einfügevorgang eines neuen Tupels.

Die Voraussetzungen für Einfüge- und Aktualisierungsvorgänge entstprechen denen von updatable views, d.h. die Daten dürfen nur aus genau einer Tabelle entnommen sein und müssen den Primärschlüssel enthalten.

Auf dieselbe Weise können auch Tupel einer Relation verändert werden. Hierzu stehen eine Reihe von updateXXX-Methoden zur Verfügung, wobei XXX für den Typ des zu aktualisierenden Attributs steht.
Nach durchgeführter Modifikation der hauptspeicherresidenten Werte werden diese durch updateRow in die Datenbank rückgeschrieben.
Beispiel zeigt dies:

Analog vollzieht sich der Löschvorgang mittels deleteRow:

Die bisher betrachteten Varianten extrahieren Daten aus der Datenbank im Stile einer Momentaufnahme (snapshot) zum Zeitpunkt der Anfrage. Die einmal angefragten Inhalte können sich jedoch noch zur Laufzeit der zugreifenden JDBC-Applikation datenbankseitig ändern, wenn sie durch eine andere Applikation neu geschrieben werden. Zur Gewährleistung der Konsistenz des extrahierten Snapshots mit den tatsächlichen Datenbankinhalten steht die Operation rowUpdated zur Verfügung. Sie ermittelt ob der im Hauptspeicher befindliche Wert mit dem aktuellen Datenbankinhalt übereinstimmt, d.h. ob der DB-Inhalt aktualisiert wurde.
Beispiel zeigt ein Umsetzungsbeispiel.

Performancebetrachtungen

Die Abbildung zeigt die Ergebnisse einiger Geschwindigkeitsmessungen als Vergleich zwischen dem Zugriff auf eine MySQL-Datenbank unter Nutzung der Textschnittstelle und der Abwicklung derselben Zugriffe mittels JDBC.

Zur Messung wurde eine nicht-indexierte Datenbank mit 107 Einträgen verwendet die aus der Relation tab bestand. Deren Tupel wurden aus Paaren von 36-Byte großen UUIDs gemäß dem Spezifikationsentwurf der IETF gebildet.

Zur Zeitmessung wurden folgende Einzeloperationen betrachtet:

  • Insert: INSERT INTO tab VALUES(...)
    Die Werte wurden unter Deaktivierung des Autocommit sequentiell eingefügt.
  • Select (ohne Ausgabe): SELECT COUNT(*) FROM tab
    Die ermittelte Gesamtzahl wurde nicht am Bildschirm ausgegeben.
  • Select (mit Ausgabe): SELECT * FROM tab
    Die Resultate wurden durch den Standarclient bzw. eine selbsterstellte (textmode) Java-Implementierung ausgegeben.
  • Update: UPDATE tab SET UUID1="X" WHERE UUID1<>"X"
    Durch die Initialisierung der Werte mit UUID-Einträgen wird sichergestellt, daß alle Tupel aktualisiert werden, da sie in keinem Fall den Wert X enthalten.
  • Delete: DELETE FROM tab WHERE UUID2<>"X"
    Durch die Initialisierung der Werte mit UUID-Einträgen wird sichergestellt, daß alle Tupel aktualisiert werden, da sie in keinem Fall den Wert X enthalten.

Insgesamt zeigt sich ein ausgewogenes Bild, in welchem der JDBC-Zugriff lediglich bei datenintensiven Zugriffen (große Mengen schreibender Zugriffe bei INSERT bzw. große Mengen lesender Operationen bei SELECT) im Bereich von fünf Prozent zurückliegt.

Diese enge Vergleichbarkeit der beiden Zugriffsmodi rührt von den Realisierung des eingesetzten JDBC-Treibers her; insbesondere von der Handhabung der physischen Datenbankverbindung auf Ebene des Netzwerkprotokolls.

SQL3-Datentypen

Die JDBC-API unterstützt mit Zugriffsmethoden auf die Datentypen BLOB, CLOB, ARRAY, Object und Ref bereits eine Untermenge des SQL:1999-Standards. So können, vorausgesetzt das durch JDBC angesprochene DBMS unterstützt dies, große unstrukturierte Binär- oder Textdaten sowie einfache verschachtelte Tabellen, mithin NF2-Strukturen verwaltet werden.

Beispiel zeigt den Zugriff auf ein als eingebettete Tabelle realisiertes mengenwertiges Attribut.
Die Beispieldatenbank wurde hierfür wie folgt modifiziert:

alter table EMPLOYEE ADD CAR SET('53M91','521R4', 'LLO415', 'XNU457');
update EMPLOYEE set CAR='XNU457' where SSN=123456789;
update EMPLOYEE set CAR='XNU457,521R4'  where SSN="999887777";

Das Beispiel unterstreicht die Rolle der mengenwertigen Attribute als eingebettete Tabellen. So erfolgt der Zugriff auf die Einzelwerte des Attributs CAR identisch zur Ermittlung der Resultatmenge der SQL-Anfrage mittels getResultSet. Auch die Traversierung der einzelnen CAR-Elemente erfolgt äquivalent.

Die Aufnahme der large objects in ihrer Ausprägungsform als Character Large Objects (CLOB) oder Binary Large Objects (BLOB) stellen eine der zentralen Erweiterungen des SQL:1999-Standards gegenüber seinen Vorgängern dar.
Zwar ist die Ablage großer unstrukturierter Datenobjekte in relationalen Datenbanken konzeptionell durchaus diskussionswert, jedoch in der Praxis oftmals, trotz der teilweise erheblichen Geschwindigkeitseinbußen im Zugriff (so benötigt die Ausführung der Beispielapplikation mit einem 106 Byte großen Datenstrom 1,1 Sekunden, während dieselbe Operation dateisystembasiert in 0,1 Sekunde abläuft), gewünscht.
Beispiel zeigt die notwendigen Schritte zur Ablage und erneuten Auslese eines aus einer Datei gewonnen Binärdatenstroms in der Datenbank.
Die Beispieldatenbank wurde hierfür um ein Attribut zur Aufnahme binärer Daten erweitert:
ALTER TABLE EMPLOYEE ADD binData blob;

Die Binärdaten können naturgemäß nicht direkt in die SQL-UPDATE-Anweisung eingebunden werden, sie werden daher einer mittels prepareStatement vorerzeugten Anweisung durch Aufruf der Methode setBinaryStream übergeben.

Transaktionssteuerung

Zur Steuerung des transaktionalen Verhaltens einer JDBC-Anfrage bietet die Klasse Connection verschiedene Methoden an:

  • Abfrage der aktuellen Isolationsstufe: getIsolationLevel.
    Hierbei werden fünf Stufen unterschieden:
    • TRANSACTION_NONE: Keinerlei Transaktionsunterstützung
    • TRANSACTION_READ_UNCOMMITTED: Auch nicht durch commit freigegebene Daten werden gelesen. Es können daher dirty reads, Nicht-wiederholbare- und Phantomlesevorgänge auftreten.
    • TRANSACTION_READ_COMMITTED: Nur durch commit freigegebene Daten werden gelesen. nichtwiederholbare- und Phantomlesevorgänge können jedoch auftreten.
    • TRANSACTION_REPEATABLE_READ: Innerhalb einer Transaktion können die verarbeiteten Daten nicht durch eine andere Transaktion verändert werden. Das Auftreten von dirty reads und nichtwiederholbaren Lesevorgängen ist daher ausgeschlossen, Phantomlesevorgänge sind jedoch weiterhin möglich.
    • TRANSACTION_SERIALIZABLE: Strikte Isolation aller Transaktionen, auf dieser Stufe sind auch Phantomlesevorgänge ausgeschlossen.
    Jede Stufe geht zwar mit einer gesteigerten Qualität der durch eine Transaktion verarbeiteten Daten einher, jedoch senkt gleichzeitig eine strikterere Isolationsstufe die Anzahl der gleichzeitigen Zugriffe auf die Datenbank und damit die Gesamtsystemperformance.
  • Setzen der Isolationsstufe: setTransactionIsolation
  • (De-)Aktivierung der automatischen Freigabe: setAutoCommit. Die Übergabe von true bewirkt die Aktivierung des Modus bei dem jede Einzelanweisung sofort persistent übernommen und für andere Transaktionen sichtbar wird.
    Standardmäßig ist diese Option aktiviert. Ihr aktueller Zustand kann per getAutoCommit ermittelt werden.
  • Freigabe von Änderungen: commit.
  • Rücknahme von Änderungen: rollback.
  • Rücknahme von Änderungen bis zu definiertem Sicherungspunkt: rollback(Savepoint s).
  • Setzen eines Sicherungspunktes: setSavepoint.

Beispiel zeigt die Nutzung des Transaktionskonzepts.
Zunächst wird die aktuelle Isolationsstufe ermittelt und geprüft ob das angesprochene DBMS die höchste durch JDBC vorhergesehene Isolationsstufe unterstützt.
Nach Abschaltung der automatischen Änderungsübernahme (setAutoCommit(false)) werden zunächst zwei Tupel in die Tabelle EMPLOYEE eingefügt, die jedoch nur innerhalb der laufenden Transaktion sichtbar werden, für alle anderen Transaktionen innerhalb des DBMS bleiben die neuen Werte (zunächst) unsichtbar.
Eine angenommene Fehlersituation führt zum Rücksetzen der Transaktion durch (rollback).
Nach Abschluß des Programms wurden zwar die beiden ersten Werte lokal in die Datenbank übernommen, aber noch innerhalb der laufenden Transaktion wieder daraus entfernt, weshalb sie zu keinem Zeitpunkt für andere Datenbankbenutzer sichtbar waren.

Neben dem Zurücksetzen einer vollständigen Transaktion bietet die JDBC-API auch die Möglichkeit alle Schritte bis zu einem anwenderdefierten aus der Datenbank zu entfernen.
Beispiel zeigt dies unter Verwendung der Methode setSavepoint zur Definition eines Sicherungspunktes und rollback(sp) zum Zurücksetzen bis zu diesem Sicherungspunkt.

Netzwerkverkehr

Der Netzwerkmitschnitt zeigt den TCP-Kommunikationsverlauf der SQL-Anfrage SELECT * FROM EMPLOYEE;.
Die vom Anfrager an den MySQL-Server übermittelten Datenanteile sind rot hervorgehoben. Zusätzlich sind die für eine gleichwertige native Kommunikation anfallenden Daten berücksichtigt. Ihre Anteile entsprechen den zusätzlich durch Fettdruck hervorgehobenen.

                  0000 4  00 00 00 \n 4  .  0  .  1  2  -  s  t  a  n  d  a  r  d  -  l  o  g  00 '  00 00 00 N  4  V
0020 5  G  D  a  9  00 ,     \b 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 14 00 00 01 87 00 ÿ  ÿ
                     
0040 
                        ÿ  m  a  r  i  o  00 N  W  N  J  S  ]  L  K  00 03 00 00 02 00 00 00 \t 00 00 00 02 j  d  b  c
                     
0060 
                        t  e  s  t  03 00 00 01 00 00 00 
                     0f 00 00 00 03 S  H  O  W     V  A  R  I  A  B  L  E  S  01 00
0080 00 01 02 19 00 00 02 00 \r V  a  r  i  a  b  l  e  _  n  a  m  e  03 1e 00 00 01 þ  03 01 00 1f
00a0 11 00 00 03 00 05 V  a  l  u  e  03 00 01 00 01 þ  03 01 00 1f 01 00 00 04 þ  \f 00 00 05 \b b
00c0 a  c  k  _  l  o  g  02 5  0  7  00 00 06 07 b  a  s  e  d  i  r  .  /  o  p  t  /  r  a  i  d
00e0 /  m  y  s  q  l  -  s  t  a  n  d  a  r  d  -  4  .  0  .  1  2  -  p  c  -  l  i  n  u  x  -
0100 i  6  8  6  /  18 00 00 07 11 b  i  n  l  o  g  _  c  a  c  h  e  _  s  i  z  e  05 3  2  7  6
0120 8     00 00 \b 17 b  u  l  k  _  i  n  s  e  r  t  _  b  u  f  f  e  r  _  s  i  z  e  07 8  3
0140 8  8  6  0  8  15 00 00 \t \r c  h  a  r  a  c  t  e  r  _  s  e  t  06 l  a  t  i  n  1  á  00
0160 00 \n 0e c  h  a  r  a  c  t  e  r  _  s  e  t  s  Ñ  l  a  t  i  n  1     b  i  g  5     c  z
0180 e  c  h     e  u  c  _  k  r     g  b  2  3  1  2     g  b  k     l  a  t  i  n  1  _  d  e
01a0 s  j  i  s     t  i  s  6  2  0     u  j  i  s     d  e  c  8     d  o  s     g  e  r  m  a  n
01c0 1     h  p  8     k  o  i  8  _  r  u     l  a  t  i  n  2     s  w  e  7     u  s  a  7     c
01e0 p  1  2  5  1     d  a  n  i  s  h     h  e  b  r  e  w     w  i  n  1  2  5  1     e  s  t  o
0200 n  i  a     h  u  n  g  a  r  i  a  n     k  o  i  8  _  u  k  r     w  i  n  1  2  5  1  u  k
0220 r     g  r  e  e  k     w  i  n  1  2  5  0     c  r  o  a  t     c  p  1  2  5  7     l  a  t
0240 i  n  5  15 00 00 0b 11 c  o  n  c  u  r  r  e  n  t  _  i  n  s  e  r  t  02 O  N  12 00 00 \f
0260 0f c  o  n  n  e  c  t  _  t  i  m  e  o  u  t  01 5  17 00 00 \r 15 c  o  n  v  e  r  t  _  c
0280 h  a  r  a  c  t  e  r  _  s  e  t  00 <  00 00 0e 07 d  a  t  a  d  i  r  3  /  o  p  t  /  r
02a0 a  i  d  /  m  y  s  q  l  -  s  t  a  n  d  a  r  d  -  4  .  0  .  1  2  -  p  c  -  l  i  n
02c0 u  x  -  i  6  8  6  /  d  a  t  a  /  13 00 00 0f 0f d  e  l  a  y  _  k  e  y  _  w  r  i  t
02e0 e  02 O  N  19 00 00 10 14 d  e  l  a  y  e  d  _  i  n  s  e  r  t  _  l  i  m  i  t  03 1  0
0300 0  1b 00 00 11 16 d  e  l  a  y  e  d  _  i  n  s  e  r  t  _  t  i  m  e  o  u  t  03 3  0  0
0320 18 00 00 12 12 d  e  l  a  y  e  d  _  q  u  e  u  e  _  s  i  z  e  04 1  0  0  0  \n 00 00 13
0340 05 f  l  u  s  h  03 O  F  F  \r 00 00 14 \n f  l  u  s  h  _  t  i  m  e  01 0  !  00 00 15 11
0360 f  t  _  b  o  o  l  e  a  n  _  s  y  n  t  a  x  0e +     -  >  <  (  )  ~  *  :  "  "  &  |
0380 12 00 00 16 0f f  t  _  m  i  n  _  w  o  r  d  _  l  e  n  01 4  14 00 00 17 0f f  t  _  m  a
03a0 x  _  w  o  r  d  _  l  e  n  03 2  5  4  1c 00 00 18 18 f  t  _  m  a  x  _  w  o  r  d  _  l
03c0 e  n  _  f  o  r  _  s  o  r  t  02 2  0  1c 00 00 19 10 f  t  _  s  t  o  p  w  o  r  d  _  f
03e0 i  l  e  \n (  b  u  i  l  t  -  i  n  )  \f 00 00 1a \b h  a  v  e  _  b  d  b  02 N  O  0f 00
0400 00 1b \n h  a  v  e  _  c  r  y  p  t  03 Y  E  S  10 00 00 1c 0b h  a  v  e  _  i  n  n  o  d
0420 b  03 Y  E  S  0e 00 00 1d \t h  a  v  e  _  i  s  a  m  03 Y  E  S  \r 00 00 1e \t h  a  v  e
0440 _  r  a  i  d  02 N  O  16 00 00 1f \f h  a  v  e  _  s  y  m  l  i  n  k  \b D  I  S  A  B  L
0460 E  D  10 00 00    \f h  a  v  e  _  o  p  e  n  s  s  l  02 N  O  15 00 00 !  10 h  a  v  e  _
0480 q  u  e  r  y  _  c  a  c  h  e  03 Y  E  S  0b 00 00 "  \t i  n  i  t  _  f  i  l  e  00 (  00
04a0 00 #  1f i  n  n  o  d  b  _  a  d  d  i  t  i  o  n  a  l  _  m  e  m  _  p  o  o  l  _  s  i
04c0 z  e  07 2  0  9  7  1  5  2  !  00 00 $  17 i  n  n  o  d  b  _  b  u  f  f  e  r  _  p  o  o
04e0 l  _  s  i  z  e  \b 1  6  7  7  7  2  1  6  -  00 00 %  15 i  n  n  o  d  b  _  d  a  t  a  _
0500 f  i  l  e  _  p  a  t  h  16 i  b  d  a  t  a  1  :  1  0  M  :  a  u  t  o  e  x  t  e  n  d
0520 16 00 00 &  14 i  n  n  o  d  b  _  d  a  t  a  _  h  o  m  e  _  d  i  r  00 19 00 00 '  16 i
0540 n  n  o  d  b  _  f  i  l  e  _  i  o  _  t  h  r  e  a  d  s  01 4  18 00 00 (  15 i  n  n  o
0560 d  b  _  f  o  r  c  e  _  r  e  c  o  v  e  r  y  01 0  1c 00 00 )  19 i  n  n  o  d  b  _  t
0580 h  r  e  a  d  _  c  o  n  c  u  r  r  e  n  c  y  01 8  !  00 00 *  1e i  n  n  o  d  b  _  f
05a0 l  u  s  h  _  l  o  g  _  a  t  _  t  r  x  _  c  o  m  m  i  t  01 1  18 00 00 +  14 i  n  n
05c0 o  d  b  _  f  a  s  t  _  s  h  u  t  d  o  w  n  02 O  N  15 00 00 ,  13 i  n  n  o  d  b  _
05e0 f  l  u  s  h  _  m  e  t  h  o  d  00 1c 00 00 -  18 i  n  n  o  d  b  _  l  o  c  k  _  w  a
0600 i  t  _  t  i  m  e  o  u  t  02 5  0  17 00 00 .  13 i  n  n  o  d  b  _  l  o  g  _  a  r  c
0620 h  _  d  i  r  02 .  /  17 00 00 /  12 i  n  n  o  d  b  _  l  o  g  _  a  r  c  h  i  v  e  03
0640 O  F  F  1f 00 00 0  16 i  n  n  o  d  b  _  l  o  g  _  b  u  f  f  e  r  _  s  i  z  e  07 8
0660 3  8  8  6  0  8  1d 00 00 1  14 i  n  n  o  d  b  _  l  o  g  _  f  i  l  e  _  s  i  z  e  07
0680 5  2  4  2  8  8  0  1c 00 00 2  19 i  n  n  o  d  b  _  l  o  g  _  f  i  l  e  s  _  i  n  _
06a0 g  r  o  u  p  01 2  1d 00 00 3  19 i  n  n  o  d  b  _  l  o  g  _  g  r  o  u  p  _  h  o  m
06c0 e  _  d  i  r  02 .  /  1d 00 00 4  1a i  n  n  o  d  b  _  m  i  r  r  o  r  e  d  _  l  o  g
06e0 _  g  r  o  u  p  s  01 1  1a 00 00 5  13 i  n  t  e  r  a  c  t  i  v  e  _  t  i  m  e  o  u
0700 t  05 2  8  8  0  0  18 00 00 6  10 j  o  i  n  _  b  u  f  f  e  r  _  s  i  z  e  06 1  3  1
0720 0  7  2  19 00 00 7  0f k  e  y  _  b  u  f  f  e  r  _  s  i  z  e  \b 1  6  7  7  7  2  1  6
0740 L  00 00 8  \b l  a  n  g  u  a  g  e  B  /  o  p  t  /  r  a  i  d  /  m  y  s  q  l  -  s  t
0760 a  n  d  a  r  d  -  4  .  0  .  1  2  -  p  c  -  l  i  n  u  x  -  i  6  8  6  /  s  h  a  r
0780 e  /  m  y  s  q  l  /  e  n  g  l  i  s  h  /  17 00 00 9  13 l  a  r  g  e  _  f  i  l  e  s
07a0 _  s  u  p  p  o  r  t  02 O  N  10 00 00 :  \f l  o  c  a  l  _  i  n  f  i  l  e  02 O  N  15
07c0 00 00 ;  10 l  o  c  k  e  d  _  i  n  _  m  e  m  o  r  y  03 O  F  F  \b 00 00 <  03 l  o  g
07e0 03 O  F  F  0f 00 00 =  \n l  o  g  _  u  p  d  a  t  e  03 O  F  F  0b 00 00 >  07 l  o  g  _
0800 b  i  n  02 O  N  16 00 00 ?  11 l  o  g  _  s  l  a  v  e  _  u  p  d  a  t  e  s  03 O  F  F
0820 15 00 00 @  10 l  o  g  _  s  l  o  w  _  q  u  e  r  i  e  s  03 O  F  F  11 00 00 A  \f l  o
0840 g  _  w  a  r  n  i  n  g  s  03 O  F  F  13 00 00 B  0f l  o  n  g  _  q  u  e  r  y  _  t  i
0860 m  e  02 1  0  19 00 00 C  14 l  o  w  _  p  r  i  o  r  i  t  y  _  u  p  d  a  t  e  s  03 O
0880 F  F  1b 00 00 D  16 l  o  w  e  r  _  c  a  s  e  _  t  a  b  l  e  _  n  a  m  e  s  03 O  F
08a0 F  1b 00 00 E  12 m  a  x  _  a  l  l  o  w  e  d  _  p  a  c  k  e  t  07 1  0  4  7  5  5  2
08c0 !  00 00 F  15 m  a  x  _  b  i  n  l  o  g  _  c  a  c  h  e  _  s  i  z  e  \n 4  2  9  4  9
08e0 6  7  2  9  5  1b 00 00 G  0f m  a  x  _  b  i  n  l  o  g  _  s  i  z  e  \n 1  0  7  3  7  4
0900 1  8  2  4  14 00 00 H  0f m  a  x  _  c  o  n  n  e  c  t  i  o  n  s  03 1  0  0  16 00 00 I
0920 12 m  a  x  _  c  o  n  n  e  c  t  _  e  r  r  o  r  s  02 1  0  17 00 00 J  13 m  a  x  _  d
0940 e  l  a  y  e  d  _  t  h  r  e  a  d  s  02 2  0  1d 00 00 K  13 m  a  x  _  h  e  a  p  _  t
0960 a  b  l  e  _  s  i  z  e  \b 1  6  7  7  7  2  1  6  19 00 00 L  \r m  a  x  _  j  o  i  n  _
0980 s  i  z  e  \n 4  2  9  4  9  6  7  2  9  5  15 00 00 M  0f m  a  x  _  s  o  r  t  _  l  e  n
09a0 g  t  h  04 1  0  2  4  17 00 00 N  14 m  a  x  _  u  s  e  r  _  c  o  n  n  e  c  t  i  o  n
09c0 s  01 0  12 00 00 O  0e m  a  x  _  t  m  p  _  t  a  b  l  e  s  02 3  2     00 00 P  14 m  a
09e0 x  _  w  r  i  t  e  _  l  o  c  k  _  c  o  u  n  t  \n 4  2  9  4  9  6  7  2  9  5  *  00 00
0a00 Q  1f m  y  i  s  a  m  _  m  a  x  _  e  x  t  r  a  _  s  o  r  t  _  f  i  l  e  _  s  i  z
0a20 e  \t 2  6  8  4  3  5  4  5  6  %  00 00 R  19 m  y  i  s  a  m  _  m  a  x  _  s  o  r  t  _
0a40 f  i  l  e  _  s  i  z  e  \n 2  1  4  7  4  8  3  6  4  7  1b 00 00 S  16 m  y  i  s  a  m  _
0a60 r  e  c  o  v  e  r  _  o  p  t  i  o  n  s  03 O  F  F     00 00 T  17 m  y  i  s  a  m  _  s
0a80 o  r  t  _  b  u  f  f  e  r  _  s  i  z  e  07 8  3  8  8  6  0  8  17 00 00 U  11 n  e  t  _
0aa0 b  u  f  f  e  r  _  l  e  n  g  t  h  04 8  1  9  2  14 00 00 V  10 n  e  t  _  r  e  a  d  _
0ac0 t  i  m  e  o  u  t  02 3  0  13 00 00 W  0f n  e  t  _  r  e  t  r  y  _  c  o  u  n  t  02 1
0ae0 0  15 00 00 X  11 n  e  t  _  w  r  i  t  e  _  t  i  m  e  o  u  t  02 6  0  \b 00 00 Y  03 n
0b00 e  w  03 O  F  F  13 00 00 Z  10 o  p  e  n  _  f  i  l  e  s  _  l  i  m  i  t  01 0  F  00 00
0b20 [  \b p  i  d  _  f  i  l  e  <  /  o  p  t  /  r  a  i  d  /  m  y  s  q  l  -  s  t  a  n  d
0b40 a  r  d  -  4  .  0  .  1  2  -  p  c  -  l  i  n  u  x  -  i  6  8  6  /  d  a  t  a  /  l  i
0b60 n  u  x  .  p  i  d  0b 00 00 \  \t l  o  g  _  e  r  r  o  r  00 \n 00 00 ]  04 p  o  r  t  04
0b80 3  3  0  6  14 00 00 ^  10 p  r  o  t  o  c  o  l  _  v  e  r  s  i  o  n  02 1  0  18 00 00 _
0ba0 10 r  e  a  d  _  b  u  f  f  e  r  _  s  i  z  e  06 1  3  1  0  7  2  1c 00 00 `  14 r  e  a
0bc0 d  _  r  n  d  _  b  u  f  f  e  r  _  s  i  z  e  06 2  6  2  1  4  4  14 00 00 a  11 r  p  l
0be0 _  r  e  c  o  v  e  r  y  _  r  a  n  k  01 0  1a 00 00 b  11 q  u  e  r  y  _  c  a  c  h  e
0c00 _  l  i  m  i  t  07 1  0  4  8  5  7  6  13 00 00 c  10 q  u  e  r  y  _  c  a  c  h  e  _  s
0c20 i  z  e  01 0  14 00 00 d  10 q  u  e  r  y  _  c  a  c  h  e  _  t  y  p  e  02 O  N  \f 00 00
0c40 e  \t s  e  r  v  e  r  _  i  d  01 1  17 00 00 f  11 s  l  a  v  e  _  n  e  t  _  t  i  m  e
0c60 o  u  t  04 3  6  0  0  19 00 00 g  15 s  k  i  p  _  e  x  t  e  r  n  a  l  _  l  o  c  k  i
0c80 n  g  02 O  N  14 00 00 h  0f s  k  i  p  _  n  e  t  w  o  r  k  i  n  g  03 O  F  F  17 00 00
0ca0 i  12 s  k  i  p  _  s  h  o  w  _  d  a  t  a  b  a  s  e  03 O  F  F  13 00 00 j  10 s  l  o
0cc0 w  _  l  a  u  n  c  h  _  t  i  m  e  01 2  17 00 00 k  06 s  o  c  k  e  t  0f /  t  m  p  /
0ce0 m  y  s  q  l  .  s  o  c  k  18 00 00 l  10 s  o  r  t  _  b  u  f  f  e  r  _  s  i  z  e  06
0d00 5  2  4  2  8  0  0b 00 00 m  \b s  q  l  _  m  o  d  e  01 0  0f 00 00 n  0b t  a  b  l  e  _
0d20 c  a  c  h  e  02 6  4  12 00 00 o  \n t  a  b  l  e  _  t  y  p  e  06 I  N  N  O  D  B  14 00
0d40 00 p  11 t  h  r  e  a  d  _  c  a  c  h  e  _  s  i  z  e  01 0  14 00 00 q  \f t  h  r  e  a
0d60 d  _  s  t  a  c  k  06 1  9  6  6  0  8  1d 00 00 r  \f t  x  _  i  s  o  l  a  t  i  o  n  0f
0d80 R  E  P  E  A  T  A  B  L  E  -  R  E  A  D  0e 00 00 s  \b t  i  m  e  z  o  n  e  04 C  E  S
0da0 T  18 00 00 t  0e t  m  p  _  t  a  b  l  e  _  s  i  z  e  \b 3  3  5  5  4  4  3  2  \r 00 00
0dc0 u  06 t  m  p  d  i  r  05 /  t  m  p  /  1c 00 00 v  07 v  e  r  s  i  o  n  13 4  .  0  .  1
0de0 2  -  s  t  a  n  d  a  r  d  -  l  o  g  13 00 00 w  \f w  a  i  t  _  t  i  m  e  o  u  t  05
0e00 2  8  8  0  0  01 00 00 x  þ  11 00 00 00 03 S  E  T     a  u  t  o  c  o  m  m  i  t  =  1  03
0e20 00 00 01 00 00 00 
                        18 00 00 00 03 S  E  L  E  C  T     *     F  R  O  M     E  M  P  L  O  Y  E
                     
0e40 
                        E  ;  01 00 00 01 \n 19 00 00 02 \b E  M  P  L  O  Y  E  E  05 F  N  A  M  E  03 \n 00 00 01 ý
0e60 03 01 00 00 19 00 00 03 \b E  M  P  L  O  Y  E  E  05 M  I  N  I  T  03 01 00 00 01 þ  03 00 00
0e80 00 19 00 00 04 \b E  M  P  L  O  Y  E  E  05 L  N  A  M  E  03 \n 00 00 01 ý  03 01 00 00 17 00
0ea0 00 05 \b E  M  P  L  O  Y  E  E  03 S  S  N  03 \t 00 00 01 03 03 01 00 00 19 00 00 06 \b E  M
0ec0 P  L  O  Y  E  E  05 B  D  A  T  E  03 \n 00 00 01 \n 03 00 00 00 1b 00 00 07 \b E  M  P  L  O
0ee0 Y  E  E  07 A  D  D  R  E  S  S  03 1e 00 00 01 ý  03 00 00 00 17 00 00 \b \b E  M  P  L  O  Y
0f00 E  E  03 S  E  X  03 01 00 00 01 þ  03 00 01 00 1a 00 00 \t \b E  M  P  L  O  Y  E  E  06 S  A
0f20 L  A  R  Y  03 07 00 00 01 05 03    00 02 1c 00 00 \n \b E  M  P  L  O  Y  E  E  \b S  U  P  E
0f40 R  S  S  N  03 \t 00 00 01 03 03 00 00 00 17 00 00 0b \b E  M  P  L  O  Y  E  E  03 D  N  O  03
0f60 01 00 00 01 03 03 00 00 00 01 00 00 \f þ  R  00 00 \r 04 J  o  h  n  01 B  05 S  m  i  t  h  \t
0f80 1  2  3  4  5  6  7  8  9  \n 1  9  6  5  -  0  1  -  0  9  18 7  3  1     F  o  n  d  r  e  n
0fa0 ,     H  o  u  s  t  o  n  ,     T  X  01 M  \b 3  0  0  0  0  .  0  0  \t 3  3  3  4  4  5  5
0fc0 5  5  01 5  R  00 00 0e \b F  r  a  n  k  l  i  n  01 T  04 W  o  n  g  \t 3  3  3  4  4  5  5
0fe0 5  5  \n 1  9  5  5  -  1  2  -  0  8  15 6  3  8     V  o  s  s  ,     H  o  u  s  t  o  n  ,
1000    T  X  01 M  \b 4  0  0  0  0  .  0  0  \t 8  8  8  6  6  5  5  5  5  01 5  T  00 00 0f 06 A
1020 l  i  c  i  a  01 J  06 Z  e  l  a  y  a  \t 9  9  9  8  8  7  7  7  7  \n 1  9  6  8  -  0  7
1040 -  1  9  17 3  3  2  1     C  a  s  t  l  e  ,     S  p  r  i  n  g  ,     T  X  01 F  \b 2  5
1060 0  0  0  .  0  0  \t 9  8  7  6  5  4  3  2  1  01 4  W  00 00 10 \b J  e  n  n  i  f  e  r  01
1080 S  07 W  a  l  l  a  c  e  \t 9  8  7  6  5  4  3  2  1  \n 1  9  4  1  -  0  6  -  2  0  17 2
10a0 9  1     B  e  r  r  y  ,     B  e  l  l  a  i  r  e  ,     T  X  01 F  \b 4  3  0  0  0  .  0
10c0 0  \t 8  8  8  6  6  5  5  5  5  01 4  V  00 00 11 06 R  a  m  e  s  h  01 K  07 N  a  r  a  y
10e0 a  n  \t 6  6  6  8  8  4  4  4  4  \n 1  9  6  2  -  0  9  -  1  5  18 9  7  5     F  i  r  e
1100    O  a  k  ,     H  u  m  b  l  e  ,     T  X  01 M  \b 3  8  0  0  0  .  0  0  \t 3  3  3  4
1120 4  5  5  5  5  01 5  S  00 00 12 05 J  o  y  c  e  01 A  07 E  n  g  l  i  s  h  \t 4  5  3  4
1140 5  3  4  5  3  \n 1  9  7  2  -  0  7  -  3  1  16 5  6  3  1     R  i  c  e  ,     H  o  u  s
1160 t  o  n  ,     T  X  01 F  \b 2  5  0  0  0  .  0  0  \t 3  3  3  4  4  5  5  5  5  01 5  S  00
1180 00 13 05 A  h  m  a  d  01 V  06 J  a  b  b  a  r  \t 9  8  7  9  8  7  9  8  7  \n 1  9  6  9
11a0 -  0  3  -  2  9  17 9  8  0     D  a  l  l  a  s  ,     H  o  u  s  t  o  n  ,     T  X  01 M
11c0 \b 2  5  0  0  0  .  0  0  \t 9  8  7  6  5  4  3  2  1  01 4  G  00 00 14 05 J  a  m  e  s  01
11e0 E  04 B  o  r  g  \t 8  8  8  6  6  5  5  5  5  \n 1  9  3  7  -  1  1  -  1  0  16 4  5  0
1200 S  t  o  n  e  ,     H  o  u  s  t  o  n  ,     T  X  01 M  \b 5  5  0  0  0  .  0  0  û  01 1
1220 01 00 00 15 þ

Die Analyse des Datenverkehrs zeigt, daß im Falle der JDBC-basierten Kommunikation ein gegenüber der nativen Schnittstelle um 3529 Byte vergrößertes Datenaufkommen ausgetauscht wird. Diese zusätzliche Datenmenge fällt jedoch nur einmal zum Zeitpunkt des JDBC-Verbindungsaufbaus statisch an. (Vgl. Mitschnitt der mehrfachen Ausführung einer SQL-Anfrage innerhalb einer bestehenden JDBC-Verbindung)
Zusätzlich offenbart Zeile 0x40 des Datenverkehrs die verschlüsselte Übermittlung des Paßwortes des Anwenders mario. Allerdings werden die per Anfrage ermittelten Nutzdaten (ab Zeile 0xe40) unverschlüsselt über die Netzwerkschnittstelle übertragen und stellen somit ein potentielles Angriffsziel dar.
Abhilfe hierfür kann die Tunnelung des Datenverkehrs, beispielsweise mittels SSH, durch eine sichere Verbindung bieten.

Zugriff mit JDBC auf nicht-relationale Quellen

Zwar legt die JDBC-Schnittstelle inhärent eine relationale und damit tabellenorientierte Sicht der zu verarbeitenden Datenquelle zugrunde, jedoch ist die Nutzung der JDBC keinesweges auf jeden Anwendungsfall beschränkt.
Beispielsweise steht mit dem Produkt Sunopsis XML Driver (JDBC Edition) ein JDBC-Treiber für den dateibasierten Zugriff auf XML-Inhalte zur Verfügung.
Der Code des Beispiels zeigt die Verwendung.

Als Beispiel dient folgende XML-Datei:

<?xml version="1.0" encoding="ISO-8859-1"?>
<Employees>
	<Employee>
		<FName>John</FName>
		<Minit>B</Minit>
		<LName>Smith</LName>
	</Employee>
	<Employee>
		<FName>Franklin</FName>
		<Minit>T</Minit>
		<LName>Wong</LName>
	</Employee>
	<Employee>
		<FName>Alicia</FName>
		<Minit>J</Minit>
		<LName>Zelaya</LName>
	</Employee>
	<Employee>
		<FName>Jennnifer</FName>
		<Minit>S</Minit>
		<LName>Wallace</LName>
	</Employee>
	<Employee>
		<FName>Ramesh</FName>
		<Minit>K</Minit>
		<LName>Narayan</LName>
	</Employee>
	<Employee>
		<FName>Joyce</FName>
		<Minit>A</Minit>
		<LName>English</LName>
	</Employee>	
</Employees>
JDBC @ SUN JDBC learning center @ SUN JDBC Tutorial JDBC FAQ @ JGuru.com G. Reese: Database Programming with JDBC and Java. O'Reilly, 1997 Verhältnis von X/Open CLI und ODBC Enterprise Java Beans (EJB)

Neben den bereits aus anderen Veranstaltungen bekannten Servlets und den davon abgeleiteten Java Server Pages bildet die Technik der Enterprise Java Beans (EJB) einen weiteren zentralen Baustein der Java 2 Enterprise Plattform. Als serverseitige Komponenten kommt den EJBs heute große Bedeutung in der Realisierung komplexer Anwendungen, insbesondere durch Umsetzung der sog. Business Logik, d.h. den nicht-interaktiven fachlichen Anwendungsteilen, zu.

Der Begriff der Enterprise Java Bean stützt sich auf dem historisch älteren der Java Bean . Eine solche stellt eine abgeschlossene wiederverwendbare Softwarekomponente dar, die nach ihrer Erstellung über festgelegte Schnittstellen parametrisiert und manipuliert werden kann. Hierzu muß eine Bean eine festgelegte Interaktionsschnittstelle bieten, die durch die Java Bean Spezifikation definiert ist. Es handelt sich dabei um eine Reihe von Konventionen, der eine Bean gehorchen muß, jedoch um keine festgelegte API, die durch eine Komponente zu implementieren ist.
Der Begriff der Enterprise Java Bean greift diese inhaltliche Fundierung auf und präzisiert gleichzeitig die technische Umsetzung. So stellt eine Enterprise Java Bean eine Softwarekomponente dar, die in einer festgelegten Ausführungsumgebung, welche durch die EJB-Spezifikation festgelegte Dienste zur Nutzung durch die Beans anbieten kann. Eine solche Ausführungsumgebung wird als Container bezeichnet.
Ziel der Trennung in Komponente und Ausführungsumgebung ist die Zielsetzung, die Enterprise Java Bean ausschließlich zur Umsetzung fachlicher Aufgaben heranzuziehen und alle infrastrukturellen Fragestellungen wie Betriebsmittelverwaltung, Persistenz oder Sicherheit durch die Ausführungsumgebung in gleicher Weise für alle Komponenten bereitzustellen.
Ein EJB-Container wird zumeist im Rahmen eines Application-Servers bereitgestellt.
Die gelegentlich anzutreffende Hervorhebung der anfänglich für Java Beans intendierten visuellen Manipulationsmöglichkeit trifft für Enterprise Java Beans nicht zu und hat sich für Java Beans auch nur begrenzte Bedeutung erlangt.

Spezifikationsgemäß können EJB-Container folgende Eigenschaften offerieren:

  • Betriebsmittelverwaltung
    Typischerweise verwaltet ein einziger EJB-Container gleichzeitig eine Reihe verschiedener Enterprise Java Beans. Zur Organisation und Aufrechterhaltung der Ausführbarkeit obliegt dem Container die Zuteilung von Betriebsmitteln wie Hauptspeicher, CPU-Zeit oder Netzwerkressourcen an die verwalteten EJB. Hierunter fällt insbesondere auch die Einlagerung, Instanziierung und Entfernung der EJBs selbst.
  • Zustandsverwaltung
    In praktischen Anwendungen ist oft die Nutzung zustandsbehafteter Kommunikation, die sich über verschiedene Einzelinteraktionen erstreckt gewünscht. Die hierfür notwendigen technischen Voraussetzungen (Zustandsspeicherung, Korrelation der Einzelinteraktionen) werden durch den Container bereitgestellt.
  • Transaktionsverwaltung
    Erweiterung der Zustandsverwaltung. Zur Gewährleistung des benötigten Verhaltens müssen EJBs keine eigenen Implementierungen zur Verfügung stellen, sondern können vorhandene Dienste des Containers nutzen.
  • Sicherheit
    Die Sicherheit von EJBs kann durch Vergabe von Zugriffsrechten und Rollen auf Containerebene gesteuert werden.
  • Persistenz
    Der interne Zustand einer verwalteten EJB kann wahlfrei in persistiert und zu einem späteren Zeitpunkt wiederhergestellt werden.
  • Entfernter Zugriff
    Der Zugriff auf EJBs erfolgt mittels Remote Method Invocation und ist daher Lokationstransparent.

Neben den in der Aufzählung dargestellten Eigenschaften dürfen Container zusätzlich Weitere wahlfrei implementieren.

EJB-Typen

Grundsätzlich lassen sich alle EJBs drei Typen zuordnen: Session Beans, Entity Beans und Message Driven Beans. Während erstere hauptsächlich zur Abbildung von Abläufen eingesetzt werden, dienen Entity Beans der Abwicklung von Zugriffen auf Daten. Eine Sonderstellung nehmen die Message Driven Beans ein, die lediglich hinsichtlich ihres Kommunikationsverhaltens festgelegt sind.

Session Beans dienen der Abbildung von Abläufen im Rahmen der Programmierung der sog. Business Logik. Die Lebensdauer (d.h. Zeitspanne zwischen Erzeugung im und Entfernung aus dem Hauptspeicher) ist daher identisch mit der einer durch den Client erfolgenden Anfrage. Jede zu einem Zeitpunkt existierende Session Bean repräsentiert daher eine zugehörige Clientinstanz.
Nach ihrer internen Ausgestaltung werden stateless und statefull Session Beans unterschieden. Während Erstere keinen über einen einzigen Aufruf hinausgehenden Zustand verwalten und daher seiteneffektfrei lediglich auf den durch den Aufruf übermittelten Daten operieren erhält das zustandserhaltende Pendant die Daten eines Aufrufs und kann diese auch in nachfolgenden Aufrufen verarbeiten.

Entity Beans sind programmiersprachliche Stellvertreter datenbankresidenter Objekte. Sie dienen dem erleichterten Zugriff auf persistent vorliegende Datenbestände. Ihre interne Realisierung ist eng mit der Technik relationaler Datenbankmanagement System verbunden. So werden Sie durch einen anwenderdefinierten Primärschlüssel dauerhaft identifiziert.

Message Driven Beans sind hinsichtlich ihres Kommunikationsverhaltens auf asynchrone Aufrufe beschränkt. Die Realisierung des eigentlichen Verhaltens wird durch eine Ausprägung eines der anderen Beantypen geboten.

Session Beans

Konzeptionell umfaßt jede EJB-Anwendung, die Session Beans einsetzt, die in dargestellten Teile:

  • Implementierung der EJB selbst.
  • Remote-Schnittstelle zum Zugriff auf die durch die Bean publizierten Methoden.
  • Home-Schnittstelle zur Ermittlung einer Referenz auf das Bean-Objekt.

Gegenüber der Realisierung als RMI-Anwendung benötigt die Umsetzung als zustandslose Session Bean die Erstellung einer sog. Home-Schnittstelle (Home Interface), welche die Operation create zur Instanziierung des serverseitigen EJB-Objekts bietet.
Sie ist im Beispiel dargestellt.

Die anwenderdefinierte Home-Schnittstelle erweitert die durch die Standard-API vorgegebene Schnittstelle EJBHome. Diese definiert Operationen zur Entfernung existierender EJB-Objekte aus dem Hauptspeicher (remove) sowie zur Ermittlung von Metadaten (getEJBMetaData) oder zum Erhalt eines netzwerkunabhängigen Verweises auf das EJB-Objekt (getHomeHandle).
Im Einzelnen sind dies die Operationen:

  • EJBMetaData getEJBMetaDate()
    Liefert ein EJBMetaData-Objekt welches einzelne Eigenschaften einer EJB näher beschreibt. Hierzu zählen:
    • Klasse der Home-Schnittstelle
    • Klasse des Primärschlüssels (nur vorhanden sofern es sich um eine Entity Bean handelt)
    • Klasse der Remote-Schnittstelle
    • Boole'scher Wert, der angibt, ob es sich um eine Session Bean handelt
    • Boole'scher Wert, der angibt, ob es sich um eine zustandslose Session Bean handelt
  • HomeHandle getHomeHandle()
    Liefert ein Objekt des Typs HomeHandle zurück, welches eine netzwerkunabhängige Abstraktion des Verweises auf das Home-Objekt realisiert.
  • void remove (Handle h)
    Entfernt ein durch den Objektverweis (Handle) identifiziertes EJB-Objekt aus dem Hauptspeicher.
  • void remove (Object pk)
    Entfernt ein durch das übergebene Primärschlüsselobjekt identifiziertes EJB-Objekt aus dem Hauptspeicher.

Interessanterweise definiert die Schnittstelle zwar Operationen zur Ermittlung von Daten über bestehende Objekte und zur Entfernung dieser Objekte aus dem Hauptspeicher, nicht jedoch zu ihrer Erzeugung.
Dies liegt in der durch die Programmiersprache Java angestrebten statischen Typsicherheit begründet, die es nicht gestattet Operationen mit variablen Parameterlisten --- wie sie für die zum API-Erstellungszeitpunkt unbekannten spezifischen Initialisierungsparameter aller denkbaren EJBs benötigt würden --- zu versehen.
Aus diesem Grunde definiert die EJB-Spezifikation informell, daß ein diese Schnittstelle erweiternde eigene Home-Schnittstelle zusätzlich die Methode create, deren Signatur als Rückgabetyp den Typ der Remote-Schnittstelle vorsehen muß definiert. Zusätzlich enthält diese Operation die zur Initialisierung der Bean benötigten Parameter in ihrer Parameterliste.

Die im Beispiel ist Remote-Schnittstelle dargestellt, deren Ausprägungen von Home-Objekten angesprochenen werden:

Schnittstellen dieses Typs enthalten ausschließlich die fachlichen Operationen, d.h. die Signaturen der Methoden, die später durch den Client benutzt werden.
Jede Remote-Schnittstelle erweitert zusätzlich die vorgegebene Schnittstelle EJBObject, welche, ähnlich zur Home-Schnittstelle, einige Operationen zur Verwaltung eines EJB-Objektes vorgibt:

  • EJBHome getEJBHome()
    Liefert die Home-Schnittstelle einer EJB.
  • Handle getHandle()
    Liefert ein Objekt des Typs HomeHandle zurück, welches eine netzwerkunabhängige Abstraktion des Verweises auf das Home-Objekt realisiert.
  • Object getPrimaryKey()
    Liefert das Primärschlüsselobjekt einer Entity Bean.
  • boolean isIdentical(EJBObject eo)
    Prüft ob das übergebene EJB-Objekt dasselbe wie das Objekt ist auf dem die Methode ausgeführt wird.
  • void remove()
    Entfernt das EJB-Objekt aus dem Bean-Container.

Beispiel zeigt die Implementierung der Bean selbst:

Die programmiersprachliche Umsetzung der Bean enthält die Methoden der in der Remote-Schnittstelle bekanntgegebenen fachlichen Operationen. Zusätzlich muß ein Konstruktur expliziert werden, dessen Parameterliste mit den für die Operation create des Home-Interfaces gegebenen übereinstimmen.
Spezifikationsgemäß muß jede Session Bean die gleichnamige API-Schnittstelle implementieren. Diese definiert einige Operationen zur Behandlung unterschiedlicher Lebenszyklusstadien einer EJB. Hierunter fallen Methoden, die beim Erzeugen (ejbCreate), Entfernen (ejbRemove), bei der Passivierung (d.h. Auslagerung auf Hintergrundspeicher) (ejbPassivate) und dessen Reaktivierung (ejbActivate) eines EJB-Objekts durch die Ausführungsumgebung aufgerufen werden.

Bei der zwingend zu implementierenden Schnittstelle SessionBean handelt es sich nicht nur um eine Konvention um die Umsetzung der Lebenszyklusschnittstelle sicherzustellen, sondern auch um die Kategorisierung der Bean selbst. So stellt die im Beispiel verwandte Schnittstelle SessionBean neben EntityBean und MessageDrivenBean eine Spezialisierung der (operationslosen) Schnittstelle EnterpriseBean dar, deren Implementierung durch eine Klasse lediglich zur Kennzeichnung dieser als EJB herangezogen wird.
Die genannten Spezialisierungen dieser Schnittstelle erfüllen daher sowohl den Zweck der Ausübung des Implementierungszwanges für die in ihnen aufgeführten Operationen als auch den der typisierenden Kennzeichnung.
Darüberhinaus ist EnterpriseBean als Spezialisierung der Standard-Schnittstelle Serializable angelegt. In der Konsequenz muß jedes EJB-Objekt durch die Javasprachmechnismen serialisierbar sein. Diese Eigenschaft wird insbesondere für die Passivierung und im Rahmen der Entity Beans genutzt.

Konzeptionell erinnert die Trennung in publizierte fachliche Schnittstelle (Remote-Schnittstelle) und deren technischer Umsetzung durch die EJB an die aus der Betrachtung des Remote Method Invocation Mechanismus bekannte Struktur.
Allerdings weicht die Umsetzung der Bean von der dort anzutreffenden Konvention ab, die publizierte Schnittstelle selbst durch die realisierende Klasse zu implementieren. Dies liegt vor allem an der gegenüber RMI veränderten Struktur der publizierten Schnittstelle begründet. Während RMI für die Schnittstelle die Spezialisierung der operationslosen Standardschnittstelle Remote fordert die EJB-Spezifikation die Erweiterung der Schnittstelle EJBObject, welche selbst die oben dargestellten Operationen definiert. Aus diesem Grunde würde die Aufnahme der Remote-Schnittstelle, obwohl konzeptionell durchaus zu rechtfertigen, in die Umsetzungsliste der EJB gleichzeitig die Implementierung von zumindest leeren Methodenrümpfen für die in EJBObject definierten Operationen notwendig werden lassen.
Abgesehen von dieser Ausnahme rekonstruiert das Verhältnis zwischen EJB und deren Remote-Schnittstelle die aus RMI bekannte Beziehung zwischen Schnittstelle und Umsetzung.

Die Nutzung einer durch eine Java Bean angebotenen Funktionalität erfolgt gemäß dem in dargestellten Schema. Ein dies umsetzender Client ist in Beispiel dargestellt.

Zunächst ermittelt der Client unter Nutzung der JNDI-API eine Referenz auf die EJB. Dies geschieht durch Anfrage (lookup) an den JNDI-Dienst unter Übergabe des bekannten Klarnamens (helloBean).
Die erhaltene generische Referenz wird durch Aufruf der statischen Methode narrow der Klasse PortableRemoteObject typsicher in eine Ausprägung der Home-Schnittstelle konvertiert.
Der Aufruf der in dieser Schnittstelle durch den Anwender definierten create-Methode sorgt für die serverseitige Instanziierung der EJB, die als Ausprägung der Remote-Schnittstelle geliefert wird. Tatsächlich wird nicht das EJB-Objekt selbst durch den Methodenaufruf retourniert, sondern lediglich ein netzwerktransparenter Verweis darauf, der jedoch clientseitig einer lokalen Objektreferenz gleichgestellt verwendet werden kann.
Ferner wird serverseitig zur Kommunikation mit der EJB ein Home-Objekt erzeugt, welchem eine Stellvertreterrolle für den anfragenden Client zukommt.
Der Aufruf der durch die EJB zur Verfügung gestellten Methode erfolgt identisch zu dem einer Lokalen.

Entity Beans

Die zweite zentrale Klasse von Enterprise Java Beans bilden die zur serverseitigen Persistierung von Objekten dienenden Entity Beans.
Sie kapseln Datenbankinhalte durch Objekte, die gemäß der EJB-Spezifikation instanziierbar und zugreifbar sind. Die Verwaltung der gekapselten Dateninhalte erfolgt durch ein frei festlegbares Datenbankmanagementsystem, die der Objekte selbst durch den EJB-Container.
Ziel dieser Technik ist es die Komplexität der Persistenzlogik für den Verwender der bereitgestellten Bean vollkommen transparent zu gestalten und serverseitig zu realisieren.
Die Familie der Entity Beans selbst zerfällt in zwei Untertypen, welche sich entlang des Realisierungspunktes der Persistenzlogik separieren: Bean Managed Persistence, der Bean obliegt die Umsetzung der Persistenzlogik, und Container Managed Persistence, hierbei wird die Persistenzlogik durch den EJB-Container realisiert.

Das nachfolgende Beispiel zeigt die Umsetzung einer Entity Bean mit Bean Managed Persistence. Es kapselt die Verwaltung und den Zugriff auf Objekte, die Personen beschreiben. Jedes Personen-Objekt enthält Daten zu Name, Geburtsdatum und Wohnstraße. Der Name dient als eindeutige Identifikation und daher datenbankseitig als Primärschlüssel. Die notwendige Datenbanktabelle wurde erzeugt durch den SQL-Ausdruck: 

CREATE TABLE PERSON( Name VARCHAR(20) PRIMARY KEY, Birthdate DATE, Street VARCHAR(30));

Wie bereits für die Realisierung von Session Beans eingeführt, werden auch zur Publikation der extern zugänglichen Schnittstellen Home und Remote Interfaces benötigt.

Struktur und Aufbau der Home-Schnittstelle ähnelt konzeptionell der für Session Beans eingeführten. Dieser Schnittstellentyp dient auch für Entity Beans zur Aufnahme der Verwaltungsoperationen zur Erzeugung (create) und zur Suche existierender EJBs (findByPrimaryKey).
Beispiel zeigt die Home-Schnittstelle des Beispiels.

Die Home-Schnittstelle zeigt die create-Operation zur Erzeugung einer neuen EJB-Instanz. Ihre Übergabeparameter dienen zur Konstruktion des neuen Objekts und werden durch die Bean-Implementierung interpretiert.
Ferner enthält die Schnittstelle mit findByPrimaryKey eine Operation, deren Implementierung eine Entity-Bean anhand ihres Primärschlüssels identifiziert und liefert. Aus diesem Grunde erhält die Methode den zu suchenden Wert vom Typ des Primärschlüssels übergeben.
Hinsichtlich der verwendeten Typen zeigt sich bereits hier, daß eine Abbildung der durch die Programmiersprache Java bereitgestellten Typen auf die des eingesetzten Persistenzsystems stattfinden muß. In der im Beispiel gewählten Ausführungsform der durch die EJB selbst verwalteten Persistenz muß diese Abbildung manuell durch den Programmierer bereitgestellt werden.

Die Remote-Schnittstelle gibt die für Nutzer der Bean zugänglichen Geschäftsfunktionen wieder. Daher enthält dieser Schnittstellentyp lediglich Operationen zum Zugriff auf die verwalteten Daten, nicht jedoch zur technischen Verwaltung und Interaktion mit dem Bean-Container.
Per Konvention muß diese Schnittstelle als Spezialisierung der Schnittstelle EJBObject definiert sein. Diese Standardschnittstelle definiert allgemeine Interaktionsformen, wie Löschen (remove), Vergleich (isIdentical) und Ermittlung des Primärschlüsselwertes (getPrimaryKey) die für alle Entity Bean Objekte gleichermaßen benötigt werden.
isIdentical liefert den Vergleich zweier serverseitiger EJB-Objekte und ermittelt so, ob zwei Java-Objektreferenzen auf dasselbe Datenbankobjekt zugreifen.
getPrimaryKey ermittelt den Wert des Primärschlüssels eines gegebenen EJB-Objekts aus der Datenbank.
Zur Lösung von datenbankresidenten Objekten wird remove eingesetzt. Der Aufruf dieser Methode entfernt ausschließlich die durch die EJB repräsentierten Datenbanktupel, die programmiersprachliche Objektrepräsentation bleibt jedoch über die gesamte Laufzeit (sofern nicht durch Gültigkeitsbereiche oder explizite NULL-Setzung explizit anders gehandhabt) intakt.

Beispiel zeigt den vollständigen Code der Bean. Sie implementiert mit EntityBean die Standardschnittstelle aller Entity Beans, welche als Spezialisierung der ausschließlich markierenden Schnittstelle EnterpriseBean die notwendigen Basisoperationen zur Abwicklung der persistenten Speicherung bieten.

Im Falle einer Bean Managed Persistence enthalten die Methoden der durch die Schnittstelle definierten und der zusätzlich im Rahmen der Spezifikation textuell definierten Operationen die notwendigen Aufrufe zur Ablage eines Objekts in der Datenbank und zu seiner späteren Extraktion daraus.
Im Einzelnen sind dies die Operationen:

Operation Semantik Zugehörige SQL-Anweisung
ejbCreate Wird nach dem Erzeugen eines Java-Objektes aufgerufen um dieses in der Datenbank abzulegen.
Diese Operation ist nicht Bestandteil der Schnittstelle, da ihre Parameter, die den Übergabeparametern des Objektkonstruktors entsprechen, zum Schnittstellenerzeugungszeitpunkt nicht feststehen. 		INSERT
ejbFindByPrimaryKey Liefert den Wert des Primärschlüssels zurück, sofern ein Datenbankeintrag existiert, der durch diesen Primärschlüssel identifiziert wird.
Diese Operation ist nicht Bestandteil der Schnittstelle, da ihre Parameter, die in Typ, Name und Reihenfolge der Zusammensetzung des Primärschlüssels entsprechen, zum Schnittstellenerzeugungszeitpunkt nicht feststehen.
Diese Methode wird nicht durch den Anwender direkt aufgerufen, sondern stattdessen auf einer Ausprägung der Home-Schnittstelle das dort zur Verfügung stehende Analogon findByPrimaryKey, welches das durch den Primärschlüssel identifizierte EJB-Objekt zurückliefert. Diese Methode greift intern auf ausschließlich den Schlüssel liefernde Methode der Bean zu. 		SELECT
ejbRemove Entfernt das EJB-Objekt aus der Datenbank. DELETE
ejbStore Synchronisiert das Java-Objekt mit dem EJB-Objekt und aktualisiert so die Datenbankinhalte.
Diese Methode wird nach jedem Zugriff mittels einer in der Remote-Schnittstelle aufgeführten Operation auf das EJB-Objekt ausgeführt. 		UPDATE

Zusätzlich enthält die Bean des Beispiels mit getAge eine zwar in der Remote-Schnittstelle veröffentlichte Operation, die keinen direkt abgespeicherten Wert liefert, sondern diesen dynamisch zur Ausführungszeit anhand der verfügbaren Daten berechnet.

Alle anderen in der Remote-Schnittstelle aufgeführten Operationen (etwa: getStreet, setStreet) modifizieren lediglich, den durch die Attribute repräsentierten Java-Objektzustand und greifen nicht direkt auf die Datenbank zu.

Innerhalb der Datenbankzugreifenden Methoden muß durch den Anwender die Abbildung der Java-Datentypen auf die des verwendeten Datenbankmanagementsystems erfolgen. Die mit dem Präfix ejb versehenden Methoden zeigen dies für die lesenden und schreibenden DB-Zugriffe. So kann die im Beispiel für name und street verwendete Java-Repräsentation String vergleichsweise leicht in den SQL-Typ VARCHAR abgebildet werden, sofern alle Methoden, die Datenbankinhalte schreiben, sicherstellen, daß nur zum Datenbankschema konforme Werte eingefügt werden. Die Beispielimplementierung zeigt dies examplarisch anhand der Methoden ejbCreate und setStreet.
Für programmiersprachliche Typen, die nicht direkt in DB-Typen abbildbar sind, muß im Falle der Bean Managed Persistence der Bean-Entwickler selbst Sorge für die adäquate Abbildung tragen. Das Beispiel illustriert dies anhand des Java-Datumstyps GregorianCalendar, der manuell in die durch das DBMS erwartete ISO 8601-konforme Darstellung zu überführen ist.

Einige der möglichen Interaktionen mit der Bean zeigt der Code des Clients aus Beispiel :

Der Client ermittelt zunächst per JNDI eine Referenz auf die Bean, welche unter dem Namen personBean im Verzeichnisdienst registriert ist.
Die erhaltene generische Referenz wird durch Aufruf der statischen Methode narrow der Klasse PortableRemoteObject typsicher in eine Ausprägung der Home-Schnittstelle (PersonHome) konvertiert.
Der Aufruf der in dieser Schnittstelle durch den Anwender definierten create-Methode sorgt für die serverseitige Instanziierung der EJB, die als Ausprägung der Remote-Schnittstelle geliefert wird. Tatsächlich wird nicht das EJB-Objekt selbst durch den Methodenaufruf retourniert, sondern lediglich ein netzwerktransparenter Verweis darauf, der jedoch clientseitig einer lokalen Objektreferenz gleichgestellt verwendet werden kann.
Ferner wird serverseitig zur Kommunikation mit der EJB ein Home-Objekt erzeugt, welchem eine Stellvertreterrolle für den anfragenden Client zukommt.
Der Aufruf der durch die EJB zur Verfügung gestellten Methode erfolgt identisch zu dem einer Lokalen.

So dient der Aufruf der Methode create zur Erzeugung von serverseitig instanziiert und transparent persistierten EJB-Objekten sowie den lokalen Java-(Stellvertreter-)Objekten für den Zugriff darauf.
Der Aufruf von getAge zeigt die Nutzung einer in der Remote-Schnittstelle veröffentlichten Zugriffsmethode. Mit getPrimaryKey wird die, in der durch die Remote-Schnittstelle erweiterten Schnittstelle EJBObject angesiedelte, Operation zur Ermittlung des Primärschlüsselwertes eines EJB-Objektes aufgerufen.
Die Methode remove stellt dagegen eine durch die Home-Schnittstelle definierte Operation dar. Durch den Aufruf dieser Methode auf dem durch p1 referenzierten Objekt wird durch Ausführung der Beanmethode ejbRemove die die Bean serverseitig repräsentierenden Datenbankeinträge entfernt sowie der durch die Bean belegte Speicherbereich als frei markiert. Alle Versuche nach Aufruf dieser Methode auf der clientseitigen hauptspeicherrepräsentation Wertänderungen durchzuführen führen daher zu einem Fehler.
Die Ermittlung von Referenzen auf existierende EJB-Objekte erfolgt durch die in der Remote-Schnittstelle definierte Methode findByPrimaryKey. Der EJB-Container stellt sicher, daß verschiedene Referenzen auf dasselbe EJB-Objekt synchronisiert in die Datenbank abgebildet werden, so daß keine Inkonsistenzen entstehen.

Für den Betrieb einer Enterprise Java Bean ist neben den bisher betrachteten Schnittstellen-Komponenten und der Realisierung der Bean selbst auch ein als Deployment Deskriptor bezeichnetes XML-Konfigurationsfile notwendig, welches verschiedene Einstellungsdaten sowie die Schnittstellendaten enthält.
Beispiel zeigt ein Beispiel hierfür:

 Java Data Objects (JDO) Grundidee

Hintergrund des Ansatzes der Java Data Objects (JDO) ist es, die bestehenden Schnittstellenmechanismen dahingehend weiterzuentwickeln, daß die Persistenz von Objekten und Objektgraphen für den Programmierer vollständig transparent durch Komponenten der Laufzeitumgebung zur Verfügung gestellt werden.
Gleichzeitig etabliert JDO eine Abstraktion der verschiedenen Speicherungsmöglichkeiten und erlaubt es beispielsweise die dateibasierte Ablage innerhalb des Programmes identisch zur Objektspeicherung in einem Datenbankmanagementsystem zu handhaben. Auf dieser Basis läßt sich im Bedarfsfalle den Persistenzdienstleister auszutauschen ohne Änderungen am Programmcode zu erfordern.
Plakativ wird der Ansatz daher, in Anlehnung an die Zielsetzung der Programmiersprache Java des write once -- run anywhere, als write once -- store anywhere charakterisiert.

Technik

Um die weitestgehend transparente Handhabung der Objektpersistenz zu gewährleisten bedient sich JDO eines Ansatzes der über das alleinige Angebot einer Programmierschnittstelle hinausreicht. Die Zielsetzung der möglichst einfach handzuhabenden Interaktion mit den generischen Persistenzmechanismen läßt sich zwar durch das Angebot von durch den Programmierer zu implementierenden Schnittstellen und Persistenzklassen erreichen, jedoch ist der Einsatz signifikant komplexer als der bestehenden Persistenzschnittstellen. Darüberhinaus konterkariert der Zwang bei der Programmerstellung vorgegebene Schnittstellen zu berücksichtigen die Zielsetzung weitestgehender Transparenz der angebotenen Speichermechanismen.

Daher führt JDO die Technik der sog. Bytecodeanreicherung (engl. bytecode enhancing) ein. Hierbei wird durch eine Programmkomponente vorübersetzer Bytecode so abgeändert, daß die notwendigen Persistenzanweisungen in den bereits erzeugten ausführbaren Bytecode eingewoben werden.
Die benötigte Übersetzerkomponente wird durch die jeweilige JDO-Implementierung zur Verfügung gestellt und muß durch den Programmierer im Bedarfsfalle lediglich geeignet parametrisiert werden.

Im Falle der Referenzimplementierung müssen daher alle Klassen, die Objekte ausprägen, welche persistiert werden sollen, mit dem Werkzeug entsprechend nachbearbeitet werden. Der notwendige Aufruf hat folgende Struktur: java com.sun.jdori.enhancer.Main -d enhanced de/jeckle/jdotest/Employee.class de/jeckle/jdotest/Employee.jdo.
Dieser Aufruf reichert die bereits übersetzte Klasse Emplyoee innerhalb der Pakethierarchie de.jeckle.jdotest um Persistenzdaten an und legt das Ergebnis innerhalb des Dateisystemkatalogs de/jeckle/jdotest ab. Zur Anreicherung wird die Konfigurationsdatei Employee.jdo herangezogen, die im selben Pfad abgelegt ist wie die Quellcodedatei.

Alternativ zu diesem Ansatz steht auch die Möglichkeit zur Verfügung die benötigten Anweisungen bereits im Quellcode vorzusehen um so dasselbe Resultat zu erzielen, welches durch den Anreicherungsprozeß erzeugt wird. Diese Vorgehensweise hat jedoch wegen der damit verbundenen Aufwände kaum praktische Bedeutung erlangt und wird daher im folgenden nicht vertieft betrachtet.

Die Beispiele dieses Kapitels basieren auf der kostenfrei verfübaren JDO-Referenzimplementierung von SUN. Diese beschränkt zwar die unterstützten Persistenzmechanismen auf ausschließlich dateibasierte Speicherung und sieht keine Ablage in Datenbankmanagmenetsystemen vor.
Konzeptionell und programmierseitig ist die Interaktion mit dieser Implementierung jedoch identisch zu kommerziell verfügbaren Lösungen und können daher ohne weiteres auf diese und damit beliebige Persistenzdienstleister übertragen werden.

Konfiguration des Persistenzdienstleisters

Die Abbildung der in der Programmiersprache formulierten Interaktionen auf den konkreten physischen Persistenzdienstleister erfolgt sinnvollerweise an einer für alle JDO-nutzenden Applikationen zugänglichen Stelle im Rahmen einer Property-Datei.
Die Inhalte dieser Datei unterscheiden naturgemäß bei den verschiedenen JDO-Herstellen und inhärent mit dem gewählten Persistenztyp. So benötigt die dateibasierte Objektablage offenkundig andere Festlegungen als der Zugriff auf ein relationales Datenbankmanagementsystem.
Beispiel zeigt die notwendigen Einstellung zur Konfiguration der dateibasierten Speicherung mit der SUN-Referenzimplementierung. Dort wird mit der PersistenceManagerFactoryClass diejenige Klasse innerhalb des JDO-Rahmenwerkes benannt, welche dem Programmierer die Persistenzdienste zur Verfügung stellt. ConnectionURL bildet das Bindeglied der Abbildung auf die physische Datei und benennt daher den Speicherort aller persistierten Objekte. Die zusätzlichen Angaben dienen der Authentisierung und Zugriffssteuerung beim Zugriff auf die erstellte Datei.

Struktur der JDO-API

Die JDO-API ist im Rahmen des Java Community Prozesses als Java-Schnittstellensammlung nebst zugehöriger Semantikdefinition spezifiziert. Die Implementierung der Schnittstellen erfolgt durch den Anbieter der jeweiligen JDO-Implementierung und erfolgt auf den jeweiligen Persistenztyp abgestimmt.
zeigt die grundlegenden Schnittstellen der JDO-API sowie die sie anbietenden Klassen der Referenzimplementierung.

Die Schnittstelle PersistenceCapable bildet das Rückgrat der gesamten Persistenzbemühungen. Jede Klasse, deren Speicherung durch JDO verwaltet werden soll (in Beispiel die Klasse Employee) muß diese Schnittstelle zwingend implementieren.
Typischerweise erfolgt diese Implementierung jedoch nicht direkt durch den Applikationsprogrammierer, sondern wird im Rahmen der Bytecodeanreicherung nachträglich hinzugefügt.
Zur Interaktion mit Klassen, deren Implementierung der in PersistenceCapable deklarierten Methoden erst nach dem initialen Übersetzungsvorgang hinzugefügt werden kann der JDO-Anbieter die Hilfsklasse JDOHelper anbieten. Diese definiert verschiedene, ausschließlich als statisch deklarierte, Methoden um mit Objekten von Klassen zu operieren, als würden diese die Schnittstelle PersistenceCapable umsetzen, ohne deren Klassen zur tatsächlichen Schnittstellenimplementierung verpflichten.
Damit stellt JDOHelper die unabdingbare Voraussetzung zur Anwendungsentwicklung unter Verwendung der Bytecodeanreicherung dar, da diese erst nach dem Übersetzungsvorgang Implementierungen derjenigen Schnittstellen hinzufügt, die bereits im Code verwendeten wurden. Ferner bietet die Klasse die Möglichkeit den aktuellen Persistenzzustand eines JDO-verwalteten Objektes auszulesen.

Zur Erzeugung von Objekten, die später den Zugriff auf das physische Speichermedium regeln dienen die Umsetzungen der Schnittstelle PersistenceManagerFactory. Sie erlaubt die Parametrisierung und Verwaltung der Verbindung zum Persistenzmedium. Bereitgestellt wird die Implementierung, im Falle der Referenzimplementierung, durch die Klasse com.sun.jdori.fostore.FOStorePMF.
Die Verbindung zwischen Schnittstelle und tatsächlicher Implementierung wird im Rahmen der in Beispiel gezeigten JDO-Konfiguration definiert. Zum Wechsel des Persistenzanbieters -- etwa von der durch die Referenzimplementierung angebotenen dateibasierten Speicherung auf eine datenbankgestützte Umsetzung -- genügt im die Abänderung dieses Eintrages in der Konfigurationsdatei.

Klassen, welche die Schnittstelle PersistenceManagerFactory implementieren, werden zur Erzeugung von sog. PersistenceMangern herangezogen. Umsetzungen dieser Schnittstelle (im Falle der Referenzimplementierung ist dies die Klasse com.sun.jdori.common.PersistenceManagerWrapper) dienen zur Interaktion mit der Persistenzveraltung innerhalb der JDO nutzenden Applikation. Alle Änderungen des Zustandes eines persistenten Objektes werden durch diese Klasse abgewickelt.

JDO wickelt sämtliche Zugriffe auf die persistenten Daten transaktionsgesichert ab. Dieser Mechanismus wird auf der abstrakten Ebene der API durch die Schnittstelle Transaction definiert und steht daher für alle Persistenzanbieter gleichermaßen zur Verfügung.
Die Schnittstelle definiert alle zur Transaktionssteuerung benötigten Operationen (darunter begin, commit und rollback) an.
Im Falle der Referenzimplementierung wird die Schnittstelle durch die Klasse com.sun.jdori.common.query.QueryImpl umgesetzt.

Zusätzlich sieht JDO eine abstrakte Möglichkeit zur Formulierung von Anfragen auf den verwalteten Datenbestand vor. Die notwendige Schnittstelle wird durch Query bereitgestellt.
Hierfür müssen die verschiedenen JDO-Implementierungen ebenfalls eigene Umsetzungen vorsehen.

Erzeugen eines persistenten Objektspeichers

Zur Erzeugung eines Objektspeichers ist bereits die Nutzung der Implementierungen der zentralen JDO-Schnittstellen sowie die der Transaktionssteuerung notwendig.
Das Beispiel zeigt die notwendigen Schritte zur Erzeugung eines persistenten Objektspeichers.
Zunächst lädt das Beispiel die Konfiguration aus der Eigenschaftsdatei des Beispiels . Anschließend wird durch die mit true belegte implementierungsspezifische Eigenschaft com.sun.jdori.option.ConnectionCreate festgelegt, daß im Rahmen des Verbindungsaufbaus auch notwendigenfalls der Objektspeicher neu erzeugt wird.
Die Interaktion mit JDO beginnt durch die Erzeugung eines PersistenceManagerFactory konformen Objektes durch den Aufruf getPersistenceManagerFactory unter Auswertung der zuvor geladenen und ergänzten Konfigurationseigenschaften.
Nach der Erzeugung des Factory-Objektes kann mittels diesem durch den Aufruf getPersistenceManager ein Objekt erzeugt werden, das die Interaktion mit dem Objektspeicher bereitstellt. Durch die Ermittlung des Persistenzmanagers wird gleichzeitig eine Verbindung zum Persistenzanbieter aufgebaut.
Ausgehend von diesem Verwaltungsobjekt kann durch Definition einer leeren Transaktion -- d.h. einer Transaktion, die jenseits der Erzeugung des transaktionalen Kontexts und seines Abschlusses mit committ, keine Operationen definiert -- der Objektspeicher erzeugt werden.
Den Abschluß der Interaktion mit dem Objektspeicher bildet die Beendigung der Verbindung durch Ausführung der Methode close des Verbindungsobjektes.

Parametrisierung der Persistenz

Grundsätzlich können Ausprägungen jeder beliebigen Javaklasse durch JDO persistiert werden, solange diese Klassen die Schnittstelle PersistentCapable explizit im Quellcode implementieren oder die benötigte Implementierung im Rahmen der Bytecodeanreicherung hinzugefügt wird.
Zur Steuerung des konkreten Persistenzverhaltens wird eine zusätzliche Konfigurationsdatei benötigt. Diese bedient sich der bekannten XML-Sytnax und definiert das Persistenzverhalten der durch JDO zu verwaltenden Klasseninstanzen näher.
Beispiel zeigt zunächst die zu persistierende Klasse Employee.

Die Nutzung JDO-gestützter Objektpersistenz impliziert keinerlei Modifikationen oder Ergänzungen am Quellcode. Ebenso sind keinerlei Umsetzungskonventionen einzuhalten, die im Beispiel definierten get- und set-Methoden dienen lediglich der vereinfachten Interaktion.

Das Beispiel illustriert eine Parameterdatei zur Definition des spezifischen Persistenzverhaltens von Objekten der Klasse Employee.

Die XML-Datei definiert zunächst den Paket- und Klassennamen der zu persistierenden Klasse mittels des Attributs name der XML-Elemente package und class.
Innerhalb eines class-Elements kann für jedes Attribut der Javaklasse ein mit field benanntes Element zur näheren Charakterisierung des Speicherungsverhaltens angegeben werden.
Ein solches Element trägt zunächst im Attribut name den klassenweit eindeutigen Namen des Attributs und erlaubt die Festlegung des spezifischen Persistenzverhaltes mittels der Belegung des Attributs persistence-modifier. Ist dieses mit dem Wert persistent versehen, so wird ein so gekennzeichnetes Attribut durch JDO im Datenspeicher persistiert. Trägt das XML-Attribut den Wert none, so wird das Javaattribut bei der Abbildung in den JDO-Datenspeicher ignoriert.
Zusätzlich besteht die Möglichkeit durch die Belegung mit transactional die Zwischenspeicherung des Attributwertes während der Abarbeitung einer Transaktion zu erzwingen, um so eine spätere Wiederherstellung (nach einem Aufruf von rollback) zu gewährleisten. Jedoch werden Felder, die so gekennzeichnet sind, nicht persistent in den Datenspeicher übernommen, sondern stehen nur während der Programmlaufzeit zur Verfügung.
Fehlt diese Spezifikation zu einem Attribut in der XML-Datei, so wird vorgabegemäß die Belegung mit persistent angenommen, sofern es in der beherbergenden Javaklasse nicht als static, transient oder final ausgewiesen ist.

Attribute vom Typ einer Sammlungsklasse, wie sie durch die Collection API definiert werden müssen zusätzlich mit einem collection-Element, welches innerhalb des field-Elements plaziert ist, charakterisiert. Das collection-Element spezifiziert durch sein Attribut element-type den Typ der Elemente in der Sammlung festlegt. Zusätzlich kann durch das Boole'sche-Attribut embedded-element gesteuert werden, ob die Inhalte des Sammlungsobjektes zusammen mit dem die Sammlung referenzierenden Objekt persistiert werden sollen.

Das Beispiel legt für alle Attribute der Klasse Employee ihre persistente Speicherung fest (Belegung des XML-Attributs persistence-modifier für alle Attribute persistent); ebenso wird die in Objekten des Typs Employee, unter dem Namen projects, enthaltene Sammlungsinstanz einschließlich ihrer Inhaltsobjekte des Standard-API-Typs String dauerhaft abgespeichert.

Über diese Festlegungen hinaus gestattet das Parametrisierungsformat die Festlegung spezifischer Konsistenzsemantik in Gestalt der Auszeichnung eines Primärschlüssels. Dieses aus dem relationalen Modell bekannte Konstrukt fordert die Eindeutigkeit eines Attributs oder einer Kombination von Attributen über die gesamte Menge der Ausprägungen eines Typs.
Durch die Unterstützung als abstraktes JDO-Konstrukt steht dieses Konzept zur Konsistenzsicherung auch für Applikationen zur Verfügung, die sich nicht relationaler Datenbanken als Persistenzdienstleister bedienen.
Zur Realisierung des Primärschlüsselkonzeptes ist das als Schlüssel zu interpretierende Attribut in der XML-Beschreibung zusätzlich mit dem XML-Attribut primary-key zu versehen, welches den Wert true tragen muß. Zusätzlich ist innerhalb des Elements class diejenige Klasse anzugeben, welche das Attribut beherbergt, das als Schlüssel herangezogen werden soll.
zeigt die notwendigen Modifikationen an der Parameterdatei des Beispiels um das Java-Attribut name als Primärschlüssel festzulegen. Die primärschlüsselanbietende Klasse ist in diesem Falle die Klasse Employee selbst, weshalb sich ihr Name auch im XML-Attribut objectid-class des class-Elements findet.

Konsequenz der Einführung eines Primärschlüsselattributs ist die Überwachung der damit einhergehenden Konsistenzbedingungen durch das JDO-Laufzeitsystem. So führen Versuche zwei Objekte, die sich in der Belegung des als Primärschlüssel definierten Attributs nicht unterscheiden ebenso zu Fehlern wie schreibende Zugriffe auf dergestalt ausgezeichnete Attribute.

Anreicherung des Bytecodes

Voraussetzung der Persistenzverwaltung eines Objektes durch JDO ist die entsprechende Modifikation dieses Objektes, konkret die Implementierung der in PersistenceCapable festgelegten Operationen durch Methoden der objekterzeugenden Klasse.
Dies wird jedoch nur in Ausnahmefällen durch den Applikationsprogrammierer direkt vorgenommen. Häufigste Eionsatzform der JDO-API ist die Anwendung der Bytecodeanreicherung, welche die Implementierung der notwendigen Funktionalität automatisiert vornimmt und diese nach dem eigentlichen Übersetzungsvorgang in den erstellten Bytecode einbringt.
zeigt die daher notwendigen zwei Übersetzungsschritte.

Die Illustration versammelt die zur Erzeugung und Anreicherung des Bytecodes der per JDO zu persistierenden Klasse Employee aus Beispiel . Zur Anreicherung des Bytecodes werden die in Beispiel getroffenen Parametrisierungen herangezogen.
Zunächst wird der im Paket de.jeckle.jdotest abgelegte Quellcode Employee.java mit dem Javacompiler in (gewöhnlichen) Bytecode übersetzt.
Anschließend wird dieser vermöge des in der JDO-Referenzimplementierung vorhandenen Werkzeuges Enhancer um die Implementierung der in der Schnittstelle PersistenceCapable definierten Operationen angereichert. Hierzu wird dem Enhancer (bereitgestellt durch die Klasse com.sun.jdori.enhancer.Main zunächst das Zielverzeichnis des zu erzeugenden Bytecodes mittels des Parameters d übergeben. Naheliegernderweise kann der aus dem ursprünglichen Bytecode durch Erweiterung erzeugte nicht die Ausgangsdatei überschreiben, daher wird der angereicherte Bytecode im Verzeichnis enhanced gespeichert. Zusätzlich ist dem Enhancer der vollqualifizierte Name der anzureichernden Klasse sowie der vollqualifizierte Pfad der Parameterdatei (im Beispiel: de/jeckle/jdotest/Employee.jdo) zu übergeben. Diese muß im Falle des Einsatzes der Referenzimplementierung zwingend die Extension jdo besitzen.

Status JDO-verwalteter Objekte

Im Zusammenspiel zwischen transienter Objektverwaltung durch die Applikation im Hauptspeicher und persistenter Objektverwaltung durch JDO im Hintergrundspeicher werden verschiedene Status eines verwalteten Objekts unterschieden zwischen denen explizite Übergänge durch API-Aufrufe vorgegeben sind bzw. implizit durch Operationen auf den involvierten Objekten bestehen.
Im Detail werden folgende Status unterschieden:

  • Transient: Instantiierte Objekte im Hauptspeicher. Hierunter fallen alle noch nicht innerhalb von Transaktionen persistierten Objekte ebenso wie unangereicherte Javaobjekte und solche die ausschließlich über Attribut verfügen, die als in der XML-Parametrisierungsdatei als transient gekennzeichnet sind.
  • Persistent (neu): Objekte, die innerhalb einer laufenden (d.h. weder durch commit noch rollback abgeschlossenen) Transaktion erzeugt wurden.
    Endet eine Transaktion, etwa durch Programmabbruch, in diesem Zustand, so werden die Objekte mit diesem Status nicht dauerhaft gespeichert.
  • Persistent (gelöscht): Objekte, die in einer noch nicht abgeschossenen Transaktion persistiert und anschließend gelöscht wurden.
    Endet eine Transaktion, etwa durch Programmabbruch, in diesem Zustand, so werden die Objekte mit diesem Status nicht dauerhaft gespeichert, da sowohl der Persistierungs- als auch der anschließende Löschvorgang noch nicht durch commit bestätigt wurden.
  • Dauerhaft persistiert und ungelesen (hollow): Objekte, die durch Abschluß einer Transaktion mit commit dauerhaft gespeichert wurden und auf die noch kein Zugriff (weder lesend noch schreibend) erfolgte.
  • Persistent und gelesen (clean): Objekte, die persistent im Hintergrundspeicher abgelegt wurden und auf die bisher lediglich lesende Zugriffe erfolgten.
  • Persistent verändert und unsynchronisiert (dirty): Persistentes Objekt, dessen Inhalt im Rahmen einer noch nicht abgeschlossenen Transaktion verändert wurde.
    Wurden zwar Attributinhalte eines persistenten Objektes verändert, jedoch keine Wertänderungen vorgenommen, d.h. in ein Attribut wird mit demselben Wert belegt, den es bereits enthält, dann steht es dem JDO-Implementierer frei diese Schreiboperation so zu implementieren, daß nicht der Zustand dirty eingenommen wird.
    Zusätzlich kann jedes Objekt durch Aufruf der API-Methode makeDirty manuell in diesen Zustand versetzt werden.
    Als Folge der Schreiboperation im Hauptspeicher differieren dessen Inhalte von denen des persistenten Objektspeichers.
    Durch Aufruf der API-Methode refresh werden die Inhalte von Haupt- und Hintergrundspeicher synchronsiert, d.h. Inhalte des Hintergrundspeichers werden in den Hauptpeicher übernommen.
  • Persistent gelöscht und unsynchronisiert (deleted): Persistentes Objekt, das im Rahmen einer noch nicht abgeschlossenen Transaktion gelöscht wurde.
    Als Folge der Löschoperation im Hauptspeicher differieren dessen Inhalte von denen des persistenten Objektspeichers und alle Leseoperationen auf nicht-Primärschlüsselfelder führen zu Laufzeitfehlern.

zeigt die verschiedenen JDO-Status sowie die Ereignisse, die zu Zustandsübergängen führen, in der Übersicht.

Speicherung von Objekten

Zur Speicherung von Objekten, deren Klassen durch den Bytecodeanreicherungsprozeß nachbearbeitet wurden, bietet die JDO-API die Aufrufe makePersistent und makePersistentAll an. Diese werden innerhalb eines Transaktionskontextes als Methoden eines PersistenceManager-Objekte ausgeführt.
Beispiel zeigt die Speicherung von drei Objekten der Klasse Emplyoee, deren übersetzter Bytecode durch Anreicherung zur JDO-Kompatibilität modifiziert wurde.
Zunächst wird mit empCol vom Standardtyp Vector eine Sammlungsobjekt zur Aufnahme von Objektreferenzen definiert. Dieser Objektsammlung werden die Referenzen auf die erzeugten Emplyoee-Objekte (emp1, emp2 und emp3) hinzugefügt.
Als Voraussetzung der Interaktion mit dem Objektspeicher muß zunächst eine Transaktion eröffnet werden. Hierzu muß zunächst durch Aufruf der Methode currentTransaction die der PersistenceManager-Instanz zugeordnete Transaktion ermittelt werden. Ausgehend vom gelieferten Ergebnisobjekt kann durch Ausführung der Methode begin eine neuer Transaktionskontext eröffnet werden.
Der Aufruf von makePersistentAll persistiert bei Übergabe der Objektsammlung alle in der Sammlung referenzierten Objekte. Alternativ können Einzelobjekte durch die Methode makePersistent in den Zustand dauerhafter Speicherung überführt werden.
Zur Übernahme in den Hintergrundspeicher muß der Transaktionskontext durch Aufruf von commit abgeschlossen werden. Der Aufruf von rollback würde stattdessen alle in der Transaktion vorgenommenen Änderungen verwerfen und auf den im Hintergrundspeicher verwalteten Datenzustand zurückgesetzt.

Würde wie im Beispiel gezeigt das Attribut name der Klasse Employee als Primärschlüssel definiert sein, so würde der Persistierungsversuch des durch emp3 referenzierten Objektes einen Laufzeitfehler liefern, da mit emp2 bereits ein Objekt mit derselben Belegung des Attributs name persistiert wurde.

Rücksetzen von Transaktionen

Treten während der Interaktion mit dem Persistenzspeicher, d.h. während eines noch nicht mit commit abgeschlossenen Transaktionskontextes Fehler auf, so können durch Aufruf der Methode rollback alle im aktuellen Kontext vorgenommen Änderungen auf den Stand vor Beginn der Transaktion zurückgesetzt werden.
Beispiel zeigt das Verhalten der Methode rollback am Beispiel. Durch die Schreiboperation innerhalb der geöffneten Transaktion wird der Wert des Attributs name zwar verändert, jedoch durch Aufruf von rollback wieder auf den ursprünglichen Wert zurückgesetzt.

Die Ausführung des Beispiels liefert folgende Ausgabe:

Employee named Marta Mayer works in department null
works in projects:
Martha gets married and changes her name
Employee named Marta Smith works in department null
works in projects:
Suppose and error happens now ...
Rolling back
Employee named Marta Mayer works in department null
works in projects:

Schreiboperationen ohne Transaktionsschutz

Ist in bestimmten Anwendungsfällen die Arbeit ohne Transaktionsschutz -- und damit ohne die Möglichkeit der expliziten Rücksetzung von Änderungen mittels rollback oder der impliziten Rücksetzung nach einem Systemausfall -- gewünscht, so kann dies durch Aktivierung der Schreibfunktionalität ohne Transaktionsschutz erreicht werden.
Hierzu muß de Methode setNontransactionalWrite mit dem Übergabeparameter true für eine Transaktion aufgerufen werden.
Das nachfolgende Beispiel zeigt als Modifikation von Beispiel die persistente Übernahme einer Wertänderung ohne Transaktionsschutz.

Traversierung des persistenten Objektbestandes

Zugriffe auf alle im Hintergrundspeicher verwalteten Objekte werden ebenfalls einheitlich durch Methoden der Implementierung der Schnittstelle PersistenceManager abgewickelt. Zur Traversierung des vollständigen Bestandes aller Instanzen einer Klasse bietet diese Schnittstelle die Operation getExtent an. Sie liefert alle Elemente der Extension (d.h. der Gesamtheit von Ausprägungen) einer gegebenen Klasse.
Beispiel zeigt die Verwendung der Methode. Als Parameter wird diejenige Klasse übergeben, deren Ausprägungen zu ermitteln sind. Zusätzlich kann durch einen Boole'schen Schalter gesteuert werden, ob auch Subklassen der übergebenen Klasse retourniert werden sollen.
Der Aufruf liefert eine Sammlung von Objekten des Typs, welcher der Methode getExtent übergeben wurde.

Anfragen an den persistenten Objektbestand

Als mächtige Alternative zur manuellen Traviersierung einer Objektextension spezifiziert JDO die Verwendung einer eigenen Anfragesprache auf Basis des Standards der Object Query Language (OQL) der Object Database Management Group (ODMG).
Diese -- als JDO Object Query Language (JDOQL) bezeichnete -- Anfragesprache ist direkt in die JDO-API integriert und wird über verschiedene Einzelmethoden genutzt. Aus diesem Grunde sind JDOQL-Anfragen nicht direkt mit den konsizsen SQL- oder OQL-Anfragen vergleichbar.
Beispiel zeigt die Einbettung der Anfragesprache in die JDO-API.

Das Beispiel illustriert eine Anfrage, die alle Employee-Objekte liefert, deren department-Attribut mit dem Wert B042 belegt ist und liefert die nach dem Inhalt des Attributes name in aufsteigender Reihenfolge sortiert.
Hierzu wird zunächst die vollständige Extension der Klasse Employee ermittelt. Allerdings Extrahiert dieser Aufruf noch keine Werte aus dem persistenten Objektspeicher, sondern schafft nur die Grundlagen einer späteren manuellen Traversierung oder der Anfrage via JDOQL.
Zur Vorbereitung der tatsächlichen physischen Anfrage wird zunächst eine Zeichenkette geeignet belegt, um als Filterausdruck dienen zu können, der auf die vollständige Extension angewandt wird. Im Beispiel ist dieser Filterausdruck mit department == \"B042\" belegt. Aus Gründen der Zeichenkettenverarbeitung in Java muß hierzu der notwendige Einschluß des zu suchenden Wertes in Anführungszeichen geeignet maskiert werden.
Nach diesen Vorbereitungsschritten kann durch den Aufruf der durch das PersistenceManager-kompatible Objekt bereitgestellten Methode newQuery ein neues Anfrageobjekt (vom Typ Query) erzeugt werden.
Dieses Objekt erlaubt nach der gezeigten Festlegung des Anfrageumfanges die Parametrisierung der Anfrage. Das Beispiel illustriert dies am Aufruf der Methode setOrdering, die es erlaubt eine bestimmte Sortierreihenfolge der gelieferten Ergebnisse vorzugeben.
Zusätzlich kann durch die optionale Ausführung der Methode compile eine Prüfung der zusammengestellten Anfrage erfolgen, die zusätzlich auch interne implementierungsspezifische Optimierungen vornehmen kann.
Abschließend erfolgt die Ausführung der Anfrage durch Aufruf der Methode execute, welche die Anfrageergebnisse konform zur Standardschnittstelle Collection zurückliefert.

Löschen von Objekten

Zur Entfernung eines Objektes aus dem Objektspeicher stellt die Schnittstelle PersistenceManager die Methode deletePersistent zur Verfügung, welche ein einzelnes hauptspeicherresidentes Objekt aus dem persistenten Speicher löscht, bzw. mit deletePersistentAll eine Möglichkeit alle durch eine Sammlung referenzierten Objekte zu entfernen.
Da es sich hierbei um einen schreibenden Zugriff handelt, muß dieser in einen Transaktionskontext eingebettet werden oder explizit transaktionslos durchgeführt werden wie in Beispiel gezeigt.
Beispiel zeigt die Löschung unter Verwendung eines Transaktionskontextes.

Migration zu einem anderen Persistenzdienstleister

Der JDO-Ansatz tritt mit dem Versprechen auf vollständig sowohl unabhängig vom verwendeten Persistenzmedium (etwa: Datenbank, Dateisystem, etc.) als auch der eingesetzten JDO-Implementierung zu sein. Diese Zielsetzung wird nachfolgend auf Basis des im vorhergehenden diskutierten Employee-Beispiels untersucht. Hierzu wird die frei verfügbare JDO-Implementierung TJDO eingesetzt, welche verschiedene Datenbankmanagementsysteme zur Speicherung der Javaobjekte heranziehen kann. Im Beispiel wird das DBMS MySQL Persistierung der Applikationsobjekte genutzt.

Zur Portierung der bestehenden Applikation ist lediglich die Anpassung der JDO-Eigenschaften (Property-Datei) vorzunehmen, um den neuen Persistenzdienstleister sowie die verschiedenen DBMS-Spezifika zu berücksichtigen.
Beispiel zeigt die neuen Inhalte.

Zunächst werden die bereits in der Konfiguration der Referenzimplementierung durch Beispiel genutzten Eigenschaften zur Identifikation derjenigen Klasse, welche die JDO-Schnittstelle PersistenceManagerFactory implementiert sowie zur Festlegung der Verbindungs-URL und des zu verwendenden Benutzernamens uns Passwortes an die neuen Gegebenheiten adaptiert. Konkret wird die durch TJDO bereitgestellte Klasse com.triactive.jdo.PersistenceManagerFactoryImpl als PersistenceManagerFactory konforme Implementierung sowie die Identifikation der zu verwendenden Datenbank nebst Benutzername und Anmeldekennwort bekanntgegeben.
Zusätzlich wird mit com.triactive.jdo.autoCreateTables eine implementierungsspezifische Eigenschaft mit true belegt, die TJDO veranlaßt im Bedarfsfalle benötigte Tabellenstrukturen automatisiert zu erzeugen.

Zusätzlich erfordert die verwendete JDO-Implementierung die Adaption der im Rahmen des Bytecodeanreicherungsprozesses herangezogenen Konfigurationsdatei (Beispiel ). Auf diesem Wege wird dem Programmierer die Möglichkeit eröffnet die Abbildung auf relationale Tabellenstrukturen beeinflussen. In der Konsequenz erfordert der Wechsel der JDO-Implementierung die Wiederholung des Anreicherungslaufes für den Bytecode der zu persistierenden Klassen.

Weitere Änderungen an den zu persistierenden Klassen oder den mit deren Objekten operierenden Applikationen ist nicht notwendig, alle Zugriffe werden nach den oben beschriebenen Änderungen transparent und ohne Neuübersetzung datenbankbasiert abgewickelt.

Vergleich der verschiedenen Persistenzansätze

Abschließend seien die charakteristischen Eigenschaften der drei diskutierten Persistenzansätze JDBC, EJB und JDO kurz vergleichend nebeneinandergestellt.

Transaktionsunterstützung Anfragemöglichkeit Standardisiertes API Standardanfragesprache
SQL
SQL/EJBQL
JDOQL Unterstützte
Hintergrundspeicher RDBMS RDMBS
Integrationsmiddleware RDBMS, ORDBMS
Integrationsmiddleware,
Dateisystem,
bel. andere Transparenter Zugriff
auf persistierte Daten Berücksichtigung existierender
relationaler Strukturen
bei bean managed persistence
allerdings nicht im Standard vorgesehen

Die Tabelle zeigt klar, daß alle drei Persistenzmechanismen grundlegende Eigenschaften teilen, sich jedoch auch in zentralen Charakteristika unterscheiden.
Während sowohl JDBC als auch EJBs die direkte Verwendung von SQL-Anfragen gestatten bietet JDO mit JDOQL eine eigenständige Anfragesprache, die direkt in die Sprach-API eingebettet ist. Für EJBs existiert neben den in Kapitel 1.2 gezeigten Mechanismen auch die Möglichkeit der Verwendung der EJB-spezifischen Anfragesprache EJBQL, die jedoch hier nicht betrachtet wurde.
Hinsichtlich der jeweils unterstützten Hintergrundspeicherarchitekturen zur Realisierung der Persistenz treten jedoch deutliche Unterschiede zu Tage. So ist der Einsatz der JDBC-API auf relationale Datenquellen, bzw. Datenquellen die eine relationale Sicht anbieten, beschränkt. Innerhalb der EJB-Architektur können hingegen neben den -- hier diskutierten JDBC-basierten Mechanismen -- auch die Dienste einer Integrationsmiddleware zu Speicherung herangezogen werden und so eine gewisse Unabhängigkeit vom physischen Speichermedium erreicht werden. Einzig JDO bietet durch seine starke Abstraktion die Möglichkeit beliebige Persistenzdienstleister zu nutzen.
Zur effizienten Abwicklung dieses speicherformunabhängigen Zugriffs etabliert JDO notwendigerweise eine stark abstrahierte API, deren Funktionen keinerlei Rückschlüsse auf den verwendeten Persistenzmechanismus zulassen. Für EJB läßt sich dies prinzipiell auch realisieren, allerdings müssen für die Variante der bean managed persistence innerhalb der Entity Bean die Interaktionen mit dem Persistenzdienstleister expliziert werden, beispielsweise durch JDBC. Daher verhält sich dieser Ansatz intern ähnlich zur direkten Verwendung der JDBC-API, die inhärent jeden angebundenen Persistenzmechanismus mit relationaler Zugriffssemantik belegt.
Aufgrund des vorherrschenden relationalen Speicherparadigmas kann die Einbindung bestehender Tabellenstrukturen in den API-Mechanismus gewünscht sein. Dies ist ausschließlich mit Ansätzen möglich, welche die anwenderdefinierte Strukturierung der Zugriffsausdrücke -- etwa durch die Verwendung von SQL -- gestatten. Dies ist ausschließlich für JDBC und EJB (sofern bean managed persistence verwendet wird) möglich; JDO sieht dies generell nicht vor.

Abschließend lassen sich die vorgestellten Schnittstellen hinsichtlich ihrer Möglichkeiten zur Bereitstellung eines transparenten Zugriffs auf den Hintergrundspeicher und der manuellen Eingriffsmöglichkeiten zur Kontrolle der Persistenz durch den Programmierer kategorisieren.
Prinzipiell läßt sich festhalten, daß diese Eigenschaftstypen konkurrierende Zielsetzungen darstellen. So bietet JDBC zweifelsohne die größten Möglichkeiten zum steuernden Eingriff durch den Programmierer, wobei dieser Ansatz in der Interaktion auch die größte Menge Wissen des Programmierers über die etablierten Speicherstrukturen erfordert. Daher realisiert JDBC generell die geringste Transparenz im Zugriff auf den Objektspeicher.
Auf der anderen Seite realisiert JDO die größtmögliche Transparenz im Objektzugriff, wobei dieser Freiheitsgrad zu generell zu Lasten der Eingriffsmöglichkeiten durch den Programmierer umgesetzt werden.

TJDO -- eine freie JDO-Implementierung JDO @ SUN JDOCentral.com -- Die Anlaufstelle der JDO-Entwickler JDO-Spezifikation Funktionsintegration Java Message Service (JMS) Einführung und Motivation

Der Austausch von Daten zwischen Rechnersystem ist so alt wie die Vernetzung zunächst separierter Rechnersysteme selbst. Während die Abwicklung des Austausches von Nachrichten zwischen den vernetzen Systemen anfänglich individuell für jede Plattform, d.h. spezifisch für jede Programmiersprache, das zugrundeliegende Betriebssystem und die zur physischen Datenübertragung eingesetzte Netzwerkinfrastruktur, gelöst werden mußte bildeten sich zur Steigerung der Interoperabilität und Portabilität bei gleichzeitiger Komplexitätsreduktion im Laufe der Zeit eigenständige generische Kommunikationskomonenten heraus, die zum Versand beliebiger Nachrichten eingesetzt werden können.

Ziel dieser -- als message-oriented Middleware bezeichneten -- Softwareinfrastruktur ist die deutliche Komplexitätsreduktion bei der Erstellung vernetzt kommunizierender Applikationen durch Einführung einer standardisierten, plattformübergreifend verfügbaren Lösung, welche dem Applikationsprogrammierer eine abstrahierte und vergleichsweise simple Programmierschnittstelle anbietet.

Zentrales Architekturmerkmal nachrichtenorientierter Middlewarekomponenten ist die gleichzeitige Betrachtung von ausschließlich zwei kommunizierenden Partnern, die als client und server bezeichnet werden, die in asynchroner Weise miteinander Nachrichten austauschen.
Im Rahmen der abgewickelten Interaktion versendet der Client dabei beliebige Daten an den Server, oder empängt diese von ihm. Der Server ist dabei die Message-orientierte Middleware, welche Sender und tatsächlichen Empfänger physische voneinander entkoppelt.
Die Begriffsbildung asynchron bezeichnet hierbei einen Kommunikationsstil, der die beteiligten Kommunikationspartner weder zeitlich noch prozedural koppelt.

Das Verhältnis zwischen Clients und Server, sowie das Zusammenspiel der verschiedenen physischen Architekturelemente ist in dargestellt.
Die Abbildung zeigt JMS-API, welche seitens der beteiligten Clients den Zugriff auf die systemspezifische Schnittstelle der verwendeten Middlware-Implementierung kapselt. Durch Pfeile ist der Ablauf eines Nachrichtenversandes von Applikation1 an Applikation2 dargestellt. Zunächst wird die Nachricht, durch Nutzung der involvierten Schnittstellen, an das MOM-System übertragen, welches es anschließend an den durch Applikation2 vorgehaltenen Client ausliefert bzw. diesem zur Abholung bereitstellt.
Entlang des Pfades, welchen eine versandte Nachricht zurücklegt können auch mehrere MOM-System hintereinandergeschaltet auftreten. Diese agieren dann als Client bezüglich der in der Nachrichtenkette angrenzenden MOM-Systeme.

Zusätzlich zeigt die Abbildung die typischerweise in MOM-Systemen präsente Datenbankkomponente, welche zur Sicherstellung der verläßlichen Nachrichtenübertragung dient. Im Normalfall wird dem versendenden Client erst die korrekte Übernahme der Nachricht in das MOM-System signalisiert, wenn sie persistent in der Datenbank abgelegt wurde. Im selben Sinne wird eine datenbankresidente Nachricht erst dann dauerhaft gelöscht, wenn sie dem Zielclient korrekt übermittelt wurde.
Durch diese Mimik entsteht, auch im Falle des Hintereinanderschaltens einzelner MOM-Systeme, eine verlässliche Nachrichtenstrecke, welche den Versand der Nachricht auch im Falle des Ausfalls einzelner Streckenabschnitte (d.h. MOM-Systeme) sicherstellen kann.

Abbildung zeigt, als Ausschnitt der Untersuchungen des W3C zu Web-Service-Architekturen, eine aktuelle Bestandsaufnahme der Komponenten einer Nachrichten-orientierten Architektur:

Address Zielpunkt an den der Nachrichtentransportmechanismus die Nachricht ausliefert.
Der syntaktische Aufbau einer Zieladresse kann vom verwendeten Transportprotokoll abhängen. Delivery Policy Art der Abwicklung des Nachrichtenversandes.
Hierunter fallen qualitative Aspekte wie einzuhaltende Sicherheitsrestriktionen sowie die garantierte Auslieferung der Nachricht bis zu einem vorbestimmten Zeitpunkt. Message Logisches Konstrukt, das die auszuliefernde Nachricht repräsentiert. Sie besteht aus dem Nutzdateninhalt (Message Body) und optionalen beschreibenden Metadaten (Message Header). Message Body Der durch den Anwender festlegbare Nutzdateninhalt einer Nachricht. Message Correlation Einordnung einer Nachricht in einen Kontext. Korrelationsmechanismen stellen sicher, das zustandsbehaftete Protokolle -- die mehr als genau einer Kommunikation bedürfen -- über zustandslose Transportmechanismen korrekt abgewickelt werden können. Message Envelope Physische Implementierung der logischen Nachricht, daß Nachrichtenköpfe und Nutzdaten beinhaltet. Message Header Eine Datenstruktur, die deskriptive Metainformation über Teile einer Nachricht beinhaltet. Message Exchange Pattern Stil der Kommunikationsabwicklung hinsichtlich temoraler und logischer Abhängigkeiten.
Synchrone und asynchrone Kommunikation sind zwei Beispiele konkreter Nachrichtenaustauschmuster.
In gewissem Sinne stellen Nachrichtenaustauschmuster eine leichtgewichtige Korrelationsform dar. Message Receiver Agent, der die Nachricht entgegenimmt. Message Reliability Grad der Verläßlichkeit, daß eine Nachricht sicher zugestellt wird. Zwischen Sender und Empfänger muß diesbezüglich eine Übereinkunft hinsichtlich der Operationalität des Begriffs bestehen. Message Sender Agent, der in der Rolle als Client die Nachricht versendet. Message Sequence Geordnete Menge einzelner Nachrichten. Message Transport Technischer Mechanismus, der durch Agenten zum physischen Nachrichtenversand genutzt wird.

Innerhalb der Java-J2EE-API bietet die Programmierschnittstelle Java Message Service (JMS) einfachen Zugriff auf die Prinzipien Nachrichten-orientierter Kommunikation, die durch beliebige Implementierungen Nachrichten-orientierter-Middleware-Systeme zur Verfügung gestellt werden können.
Für die nachfolgenden Codebeispiele wurde die Implementierung der Sun Java Message Queue, welche als Bestandteil der J2EE-Referenzimplementierung ausgeliefert wird, genutzt. Die Beispiele sollten sich jedoch mit geringem Anpassungsaufwand auch auf andere Middlwaresysteme übertragen lassen.

Äquivalenz von synchroner und asynchroner Kommuniktion

Die JMS-API

Die JMS-API besteht aus einer Reihe von Java-Schnittstellenspezifikationen, die durch das verwendete Middlewaresystem implementiert werden.

Nachfolgend ist eine Übersicht der zentralen Schnittstellen und der durch sie angebotenen Funktionalität gegeben.

Connection Repräsentiert die Verbindung eines Clients zu einem Server über die Nachrichten versandt werden können. ConnectionFactory Kapselt verschiedene Konfigurationseinstellungen und wird clientseitig zur Erzeugung eines Connection-Objekts eingesetzt. Destination Dient der Repräsentation einer Transportmechanismen-spezifischen Adresse. MessageProducer Stellt dem Client die zum Nachrichtenversand nötigen Operationen zur Verfügung. MessageConsumer Stellt dem Client die zum Nachrichtenempfang benötigten Operationen zur Verfügung.> Queue Repräsentiert eine Nachrichtenstrecke. Session Liefert die logische Umgebung zum Versand und Empfang von Nachrichten. TextMessage Die zu versendene Nachricht. JMS gestatt spezifikationsgemäß ausschließlich die Übermittlung von Nachrichten, die durch Objekte der Standard-Klasse String repräsentiert werden. Topic Repräsentiert eine semantische Untermenge von Nachrichten in Form eines logischen Kanals. TopicConnection Repräsentiert einen logischen Kanal der durch Abonennten subscribiert werden und an alle abonnierenden Clients spontan Nachrichten versenden kann. TopicConnectionFactory Kapselt verschiedene Konfigurationseinstellungen und wird zur Erzeugung eines TopicConnection-Objekts eingesetzt. Destination Dient der Repräsentation einer Transportmechanismen-spezifischen Adresse. MessageProducer Stellt dem Client die zum Nachrichtenversand nötigen Operationen zur Verfügung. MessageConsumer Stellt dem Client die zum Nachrichtenempfang benötigten Operationen zur Verfügung. TopicPublisher Durch den Client eingesetzte Schnittstelle, die zum Versand von Nachrichten an abonnierte Kanäle dient. TopicSubscriber Durch den Client eingesetzte Schnittstelle, die zum Abruf von Nachrichten dient, welche an abonnierte Kanäle versandt wurden. TopicSession Schnittstelle, die Operationen zur Erzeugung von TopicPublisher-, TopicSubscriber- und TemporaryTopic-Objekten bereitstellt. Synchroner Nachrichtenverkehr

Das Beispiel zeigt die notwendigen Schritt zur Implementierung eines Clients zum synchronen Nachrichtenversand.
Zunächst ermitteln die Zeilen 29 bis 53 durch Nutzung des JNDI-Mechanismus die Referenz auf das zur Verbindungserzeugung zum Server benötige Objekt des Typs Connection Factory. Davon ausgehend wird in Zeile 56 ein Connection-Objekt erzeugt, welches die Verbindung zum Server verwaltet.
Der in Zeile 57 erfolgende Aufruf der API-Funktion createSession liefert eine Ausprägung des Typs Session, welches die logische Verbindung zum Server etabliert. Die in Zeile 57 des Beispiels genutzten Übergabeparameter erzeugen eine Session, die nicht transaktionsgestützt (erster Parameter) arbeitet und durch die als zweiten Übergabeparameter spezifierte Konstante AUTO_ACKNOWLEDGE dazu führt, daß die Verbindung (d.h. das Session-Objekt) den Nachrichtenempfang selbständig bestätigt, sobald der Client seine receive-Methode aufgerufen hat oder die Nachricht aus dem Nachrichtenspeicher entnommen wurde.
Ausgehend von der erzeugten Session erzeugt die Methode createProducer ein Objekt des Typs MessageProducer, welches zum Versand von Nachrichten an einen gegebene Adresse dient.
Zeile 60 erzeugt eine neue Nachricht des Typs TextMessage zum Versand. Dieser wird anschließend, durch die API-Funktion setText, textueller Nachrichteninhalt zugewiesen.
Der tatsächliche Sendevorgang findet (in Zeile 65) durch den Aufruf send statt. Die Implementierung des Beispiels wiederholt diesen Sendevorgang (mit unterschiedlichen Nutzdateninhalten) so oft, wie per Aufrufparameter spezifiziert.
Zum Abschluß der Kommunikation versendet der Client eine Nachricht mit leerem Nutzdateninhalt (sie besteht nur aus verwaltender Headerinformation) an den Server. Diese dient als Endemarkierung des kompletten Sendevorganges.

Aufruf des Beispiels mit: j2ee14/bin/appclient -client SProducer.jar jms/Queue queue 5

Beispiel zeigt die Umsetzung eines nachrichtenempfangenden Clients.
Auch er ermittelt zunächst, ebenfalls unter Nutzung von JNDI, die relevanten Umgebungsdaten und erzeugt ausgehend von der ConnectionFactory eine Verbindung (Zeile 55) und eine Session zur Abwicklung des nachrichtenverkehrs.
Zur Kommunikation mit dem Client, welcher im vorhergehenden Beispiel zum Abschicken der Nachrichten diente, muß derjenige Client, der die Nachrichten entgegennimmt, an dieselbe Adresse gebunden werden, die bereits im Client als Nachrichtenendpunkt diente. Entsprechend wird dem Aufruf der JMS-API-Methode createConsumer dieselbe Endpunktidentifikation übergeben, die zuvor für den sendenden Client Verwendung f