Einführung in XML. von. Prof. Dr. Manfred Dausmann Dipl.-Ing. (FH) Alexander König. Stand: November 2010

Transkript

1 STEINBEIS-TRANSFERZENTRUM SOFTWARETECHNIK Einführung in XML von Prof. Dr. Manfred Dausmann Dipl.-Ing. (FH) Alexander König Stand: November 2010 STZ Softwaretechnik Prof. Dr. Goll und Partner Entennest Esslingen-Zell Leiter: Prof. Dr. Joachim Goll Fon: (07 11) Fax: (07 11)

2 - Vorwort - Vorwort Die hier vorliegende Version des Skriptums zur Vorlesung "Einführung in XML" basiert auf Unterlagen des gleichnamigen Ferienkurses, an denen außer den Autoren auch noch Herr Stefan Burkhardt mitgearbeitet hatte. Des weiteren haben einige Studien- und Diplomarbeiten zu den Erweiterungen und Überarbeitungen des Stoffes beigetragen. Dafür möchten wir uns bei den Herren Michael Bässler, Matthias Book, Christian Feick, Elmar Kubitz, Wolfgang Langner, Stefan Schuster, Holger Steudle und Matthias Trischler ganz herzlich bedanken. Hinweise auf Fehler und Vorschläge für Verbesserungen werden gerne entgegen genommen: Manfred.Dausmann@stz-softwaretechnik.de. Dieses Skript "Einführung in XML" darf in seiner Gesamtheit nur zum privaten Studiengebrauch benützt werden. Das Skript ist in seiner Gesamtheit urheberrechtlich geschützt. Folglich sind Vervielfältigungen, Übersetzungen, Mikroverfilmungen, Scan-Vervielfältigungen, Verbreitungen sowie die Einspeicherung und Verarbeitung in elektronischen Systemen unzulässig. Ein darüber hinausgehender Gebrauch ist zivil- und strafrechtlich unzulässig. - i -

3 - Verzeichnisse - Inhaltsverzeichnis 1 EINLEITUNG ENTSTEHUNG VON XML MARKUP-SPRACHEN SGML HTML DAS WORLD WIDE WEB CONSORTIUM DER XML STANDARD DIE XML GRAMMATIK DOCUMENT TYPE DEFINITION KORREKTHEIT VON XML DOKUMENTEN XML-BASIERTE SPRACHEN XML DOKUMENTE DAS SPRACHKONZEPT AUFBAU VON XML DOKUMENTEN DER PROLOG DER DOKUMENTKÖRPER BEISPIEL: DAS ADRESSBUCH DOKUMENT DOCUMENT TYPE DEFINITION ELEMENTE ATTRIBUTE BEISPIEL: DIE ADRESSBUCH DTD ENTITIES DOCUMENT TYPE DEKLARATION DIE BAUMSTRUKTUR NAMESPACES DEFAULT-NAMENSRAUM NAMENSRÄUME MIT PRÄFIX PROBLEMATIK VON NAMENSRÄUMEN DEFINITION EIGENER NAMENSRÄUME AUFTEILUNG IN PHYSISCHE EINHEITEN XML PARSER UND SCHNITTSTELLEN ÜBERSICHT WOHLGEFORMT VS. GÜLTIG NICHT-VALIDIERENDE PARSER PROGRAMMIERUNG IN JAVA DAS DOCUMENT OBJECT MODEL DAS DOM PROGRAMMIERMODELL DOM IN JAVA PARSEN DES ADRESSBUCHES MIT DOM SIMPLE API FOR XML DAS PROGRAMMIERMODELL VON SAX ii -

4 - Verzeichnisse SAX IN JAVA PARSEN DES ADRESSBUCHES MIT SAX VERGLEICH VON DOM UND SAX WEITERFÜHRENDE ENTWICKLUNGEN SAX + DOM = SAXDOMIX DIE JDOM BIBLIOTHEK DEFERRED PARSING PULL PARSING ZUSAMMENFASSUNG STYLESHEETS DIE VORFAHREN VON XSL CASCADING STYLESHEETS DOCUMENT STYLE SEMANTICS AND SPECIFICATION LANGUAGE ANWENDBARKEIT VON STYLESHEETS DIE EXTENSIBLE STYLESHEET LANGUAGE XPATH PFADAUSDRÜCKE FILTER ACHSEN FUNKTIONEN XSL TRANSFORMATIONS DEFINITION DER TRANSFORMATIONEN DEFAULT TRANSFORMATIONEN BEISPIEL: TRANSFORMATION DES ADRESSBUCH-DOKUMENTES ZUORDNUNG VON STYLESHEETS ZU DOKUMENTEN FORMATIERUNG DES OUTPUT ZUSAMMENFASSUNG PERFORMANCE ASPEKTE ÄNDERUNGEN IM STYLESHEET XSLTC (TRANSLETS) FORMATTING OBJECTS (XSL-FO) AUFBAU EINES FO DOKUMENTES LAYOUTVORLAGEN SEITENSTRUKTURIERUNG SEITENFOLGEN DARSTELLUNG DES INHALTES BEISPIEL VERFÜGBARE XSL-FO PROZESSOREN ZUSAMMENFASSUNG XML SCHEMA ENTWICKLUNG VON XML SCHEMA VORGÄNGER VON XML SCHEMA DEFINITION VON XML SCHEMA VERGLEICH XML SCHEMA DTD VALIDIERUNG ÜBER XML SCHEMA DEFINITIONEN VALIDIERUNG DER XML SCHEMA DEFINITION EINBINDEN EINER SCHEMA DEFINITION IN EIN XML DOKUMENT ZUORDNUNG ZU EINEM NAMESPACE AUFBAU EINER SCHEMA DEFINITION iii -

5 - Verzeichnisse DEFINITION VON ELEMENTEN VORDEFINIERTE TYPEN DEFINITION VON EINFACHEN TYPEN LOKALE, GLOBALE UND ANONYME TYPEN DEFINITION KOMPLEXER TYPEN HIERARCHIE DER ELEMENTE GESCHACHTELTE ELEMENTE UND ATTRIBUTE KOMPLEXE TYPEN FÜR GEMISCHTEN INHALT ERWEITERUNGEN UND EINSCHRÄNKUNG VON KOMPLEXEN TYPEN DOKUMENTATION EINES SCHEMAS XML SCHEMA BEISPIEL XML BINDING FOR JAVA ARBEITSWEISE VON JAXB AUFBAU DER GENERIERTEN KLASSEN JAXB-API BEWERTUNG ZUSAMMENFASSUNG LINKING IN XML ÜBERSICHT XLINK XPOINTER WEB SERVICES WEB SERVICE DESCRIPTION LANGUAGE WSDL AUFBAU EINES WSDL DOKUMENTS WSDL BEISPIEL WSDL FÜR DEN ECHO-SERVICE SIMPLE OBJECT ACCESS PROTOCOL SOAP AUFBAU EINER SOAP NACHRICHT BEISPIELE FÜR SOAP NACHRICHTEN UNIVERSAL DESCRIPTION DISCOVERY AND INTEGRATION UDDI UDDI STRUKTUREN UND SICHTEN UDDI REGISTRIES ZUGRIFF AUF UDDI WEB SERVICES TOOLS ALLGEMEINE ÜBERSICHT ÜBERSICHT ÜBER AXIS ENTWICKELN EIGENER WEB SERVICES VORGEHEN BEI DER BOTTOM-UP ENTWICKLUNG VORGEHEN BEI DER TOP-DOWN ENTWICKLUNG VORGEHEN BEI DER ENTWICKLUNG DES CLIENTS TRANSPORTPROTOKOLLE ZUSAMMENFASSUNG EINSCHRÄNKUNGEN BEI WEB SERVICES BEWERTUNG VON WEB SERVICES ALLGEMEIN AUSBLICK SEMANTIC WEB iv -

6 - Verzeichnisse RESOURCE DESCRIPTION FRAMEWORK RDF WEB ONTOLOGY LANGUAGE OWL ZUSAMMENFASSUNG VORTEILE VON XML XML HARMONIERT MIT HTML, HTTP UND WEBBROWSERN XML IST EINFACH UND PORTABEL XML KANN DOKUMENTE BELIEBIGER KOMPLEXITÄT ABBILDEN XML IST MEHR ALS NUR EINE AUSZEICHNUNGSSPRACHE INTERNATIONALITÄT ANWENDUNGSFELDER FÜR XML XML ALS STANDARDISIERTES DATENAUSTAUSCHFORMAT VERLAGERUNG DER RECHENLEISTUNG VOM SERVER ZUM CLIENT VARIABLE DARSTELLUNG VON INFORMATIONEN INTELLIGENTES SUCHEN IN XML DATENBESTÄNDEN AUSBLICK QUELLENVERZEICHNIS LITERATUR BÜCHER LINKS ZU INFORMATIONSQUELLEN LINKS ZU SOFTWARE HERSTELLERN XML TOOLS XML EDITOREN XEENA MERLOT MORPHON EPCEDIT WEITERE XML EDITOREN XML PARSER XML4J XERCES JAVA API FOR XML PROCESSING XSL TOOLS XSLT PROZESSOREN COCOON XSLT EDITOREN XSL-FO PROZESSOREN v -

7 Abkürzungsverzeichnis - Verzeichnisse - API BIPS COM CORBA DCOM CSS DOM DSSSL DTD ebxml EDI FPI FSML HDML HTML HTTP HTTPR IDL IIOP J2EE JAXB JAXP JMS MathML MIME OFX ORB OTP OWL PDF PICS PNG RDF RPC RTF SAX SDML SGML SMIL SOA SOAP SVG UDDI URI URL W3C Application Programming Interface Bank Internet Payment System Component Object Model Common Object Request Broker Architecture Distributed Component Object Model Cascading Stylesheets Document Object Model Document Style Semantics and Specification Language Document Type Definition electronic business XML Electronic Data Interchange Formal Public Identifier Financial Services Markup Language Handheld Device Markup Language Hypertext Markup Language Hypertext Transfer Protocol Hypertext Transfer Protocol Reliable Interface Definition Language Internet Inter-ORB Protocol Java2 Enterprise Edition Java API for XML Binding Java API for XML Processing Java Message Service Mathematical Markup Language Multipurpose Internet Mail Extension Open Financial Exchange Object Request Broker Open Trade Protocol Web Ontology Language Printable Document Format Platform for Internet Content Selection Portable Network Graphics Resource Description Framework Remote Procedure Call Rich Text Format Simple API for XML Parsing Signed Document Markup Language Standard Generalized Markup Language Synchronized Multimedia Integration Language Service Oriented Architecture Simple Object Access Protocol Scalable Vector Graphics Universal Description, Discovery and Integration Uniform Resource Identifier Universal Resource Location World Wide Web Consortium - vi -

8 - Verzeichnisse - WML WSDL WSIF WWW XHTML XML XQL XSD XSL XSLT XSL-FO Wireless Markup Language Web Service Description Language Web Services Invocation Framework World Wide Web XML based HTML extensible Markup Language XML Query Language XML Schema Definition XML Stylesheet Language XSL Transformations XSL Formatting Objects - vii -

9 - 1. Einleitung - 1 Einleitung Die extensible Markup Language XML ist derzeit in aller Munde. Denn XML hat sich zu einem Standard zur Datenbeschreibung im Internet entwickelt. D.h. mit XML hat man die Möglichkeit, Daten sei es auf Webseiten oder für unterschiedliche Anwendungen allgemeinverständlich zu beschreiben. Viele große Unternehmen wie z.b. IBM, Sun, SAP und Microsoft bieten volle Unterstützung für das neue Datenformat. Das hat dazu beigetragen, die Bekanntheit und Verbreitung maßgeblich zu beschleunigen. Je mehr das Internet als Kommunikationsmedium genutzt wird, um so mehr werden auch XML Technologien eingesetzt, da mit XML eine neue Basis für die Integration verschiedener Partner, Prozesse und Anwendungen existiert. XML ist eine textbasierte Meta-Auszeichnungssprache, die die Beschreibung, den Austausch, die Darstellung und die Manipulation von strukturierten Daten erlaubt, so dass diese vor allem über das Internet von einer Vielzahl von Anwendungen genutzt werden können. XML ist "extensible", da es sich im Gegensatz zu HTML nicht um ein festes Format im Sinne einer bestimmten Auszeichnungssprache, sondern vielmehr um eine Metasprache handelt, die Vorschriften bereit stellt, eine beliebige Vielzahl konkreter Auszeichnungssprachen für die verschiedensten Arten von Dokumenten zu definieren. Neben der Unterstützung des Dokumentenaustausches ermöglicht XML allgemein die flexible Weiterverwendung von Daten und ist die Grundlage für eine Verwendung von Metadaten, was u.a. zu einer erhöhten Interoperabilität unterschiedlicher Anwendungen und mächtigen Retrievalmöglichkeiten führt. In diesem Skriptum werden zuerst die grundlegenden Eigenschaften von XML vorgestellt. Insbesondere werden dabei die Unterschiede zu HTML herausgearbeitet. Jede Anwendung, die XML Dokumente verarbeiten will, muss diese lesen, bzw. schreiben können. Hierfür wurden Schnittstellen definiert, sodass sich nicht jede einzelne Anwendung um die Details der Syntax kümmern muss. Die wichtigsten Schnittstellen, das Document Object Model (DOM) und das Simple API for XML Parsing (SAX), werden im Kapitel 4 vorgestellt. Es folgen Übersichten über zwei wichtige Standards, die sich im Umfeld von XML etabliert haben und ebenfalls das Arbeiten mit XML Dokumenten für Anwendungen vereinfachen: die extensible Stylesheet Language (XSL), eine Sprache zur Beschreibung des Layout von XML Dokumenten, und XML Schema, ein Vokabular mit dem Struktur und Inhalt von XML Dokumenten präzise beschrieben werden können. Die Verlinkung von Dokumenten mit Hilfe von XLink und XPointer folgt im Kapitel 7. Web Services und ihre Technologien, die alle XML-basiert sind, werden dann im Kapitel 8 vorgestellt. Das Kapitel 9 enthält die bereits geschaffenen Möglichkeiten für ein Semantisches Web, die ebenfalls XML-basiert sin. Am Schluss wird ein Ausblick auf zukünftige Entwicklungen und mögliche Anwendungsfelder für XML gegeben. Hinweise auf Tools zur Bearbeitung von XML Dokumenten und Verweise auf Informationsquellen sind dann im Anhang (ToDo) zu finden

10 - 2. Entstehung von XML - 2 Entstehung von XML 2.1 Markup-Sprachen Die Markierungstechnik, die bei Markup-Sprachen eingesetzt wird, ist heute ein verbreitetes Mittel, um Daten in sequentiellen Dateien oder Streams zu strukturieren. Typischerweise sieht das so aus (hier ein Beispiel aus HTML): <HTML> <HEAD> <TITLE>Informationen zu XML</TITLE> </HEAD> <BODY> XML ist eine Markup Language. </BODY> </HTML> Wie man an obigem Beispiel erkennen kann, werden bei Markup-Sprachen bestimmte Segmente des Textes durch Anfang- und End-Marken markiert und einer bestimmten semantischen Klasse zugeordnet. Dabei können Markierungen entsprechend der verwendeten Sprache auch geschachtelt werden. Die Marken werden auch mit dem entsprechenden englischen Wort Tag bezeichnet. Um diese Tags vom restlichen Text eindeutig zu trennen, werden sie in ein "<"- Zeichen und ">"-Zeichen eingeschlossen. Das führt natürlich dazu, dass man diese Zeichen, wenn man sie im normalen Text verwenden möchte, durch eine andere Zeichenfolge ersetzen muss. Hierfür wählte man die Ersatzzeichenfolgen < für "<" und > für ">", als Abkürzung für "lower than" und "greater than". Start-Tags werden in der Form <TAGNAME> notiert, End-Tags erhalten einen zusätzlichen Slash "/" nach dem "<": </TAGNAME> SGML Schon Anfang der 70er Jahre sahen sich Entwickler mit einer Vielzahl von Markup- Sprachen konfrontiert, die zwar alle auf dem gleichen Prinzip basierten, aber aufgrund unterschiedlicher Marken nicht mit den gleichen Tools zu bearbeiten waren. Daraufhin entschloss man sich, eine neue Sprache zu entwickeln, die es ermöglichen sollte beliebige Markup-Sprachen zu beschreiben, welche dann möglichst mit den gleichen Tools verarbeitet werden können sollten. Da diese Sprache aus logischer Sicht eine Ebene über den mit ihr beschriebenen Sprachen liegt, spricht man hier von einer Metasprache 1. 1 Das "Meta"-Prinzip ist nicht auf eine Ebene festgelegt. Zum Beispiel wäre eine Sprache, die eine Sprache beschreibt, die wiederum wieder andere Sprachen beschreibt, eine Meta-Meta-Sprache

11 - 2. Entstehung von XML - Das Ergebnis dieser Entwicklungen war SGML, die Standard Generalized Markup Language. Diese wurde im Jahre 1986 schließlich als ISO-Standard (ISO-8879) verabschiedet. Nachdem SGML selbst keine vordefinierten Tags kennt, ist es nicht möglich SGML "einfach so" zur Erstellung von Dokumenten zu verwenden. Bevor man den eigentlichen Dokumenten-Inhalt angeben kann, muss erst klargestellt werden, um was für einen Dokumenten-Typ es sich handeln soll. Dazu wird am Anfang eines SGML Dokuments ein Verweis auf die zugehörige Document Type Definition (DTD) angelegt. Erst mit dieser DTD ist die verwendete Sprache definiert, das heißt kann ein Dokument validiert werden. Die dazu notwendigen Konzepte werden im Kapitel 3 vorgestellt werden HTML Die wohl bekannteste Anwendung von SGML ist die Hypertext Markup Language. Die Syntax von HTML ist wie bei allen anderen SGML Anwendungen in einer DTD festgehalten. Diese findet man zum Beispiel in der aktuellen HTML 4.01 Spezifikation auf den Seiten [HTML40]. Obwohl HTML ursprünglich auch die Philosophie verfolgte, mit den Tags lediglich die Bedeutung des markierten Textes zu verdeutlichen, so wurde die Sprache durch proprietäre Erweiterungen und eigenwillige Design-Tools zur reinen Layout-Sprache umfunktioniert. So werden zum Beispiel häufig Text-Segmente mit Überschriften- Tags versehen, damit diese im Browser mit einer größeren Schriftart dargestellt werden. Das Problematische daran ist: Suchmaschinen verwenden bevorzugt Überschriften, um Seiten nach dem Inhalt zu indizieren. Ein anderes Beispiel, wo Struktur und Optik miteinander in Konflikt kommen, ist der BLOCKQUOTE-Tag: HTML Designer verwenden ihn häufig, um einen Teil des Textes einzurücken, was beispielsweise bei einem Text-to-Speech-System dazu führen kann, dass die markierte Stelle als Zitat wiedergegeben wird, was sie ja eigentlich nicht ist. Inzwischen nutzen viele Anwendungen wie etwa Datenbanken mit HTML Frontend das WWW als Oberfläche. Allerdings geht durch die Verwendung von HTML die reiche, innere Struktur der Daten verloren. Komplexere Strukturen wie das Relationenschema einer Datenbank oder Objekthierarchien sind nicht abbildbar. Weiterhin ist es mit HTML nicht möglich, Daten semantisch auszuzeichnen, d.h. den Dokumenten Informationen über ihren Inhalt, jenseits der reinen Darstellung, mitzugeben. "Bei der Umsetzung in Web-Dokumente findet immer ein Informationsverlust statt. Bei einer über das Web abfragbaren relationalen Datenbank etwa verschwindet die auf dem Server vorhandene Strukturierung der Nutzdaten in Felder auf der Client-Seite in einem Meer von Tags. Eine Nutzung der Daten beim Betrachter, die über das Ausschneiden von Text mittels Cut & Paste hinausgeht, ist nicht mehr möglich." [Mach97]. In der folgenden Tabelle werden diese Unterschiede zwischen HTML und XML anhand eines einfachen Beispiels deutlich

12 - 2. Entstehung von XML - HTML XML <P> <strong>bosak, Jon </strong> <?xml version="1.0"?> XML, Java, and the future of the Web<ARTIKEL> </P> <AUTOR>Bosak, Jon</AUTOR> <TITEL>XML, Java, and the future of the Web </TITEL> </ARTIKEL> Tabelle 2-1: HTML versus XML Die häufig als "HTML-Dilemma" bezeichneten Defizite von HTML lassen sich wie folgt zusammenfassen [Bosa97]: 1. Erweiterbarkeit: HTML erlaubt weder das Setzen eigener Tags noch das Spezifizieren individueller Attribute zur semantischen Auszeichnung von Daten. HTML ist damit ein reines Präsentationsformat. Ein in HTML codiertes Dokument enthält nur Informationen, wie Inhalte darzustellen sind; weitergehende Informationen über die Semantik des Inhalts sind nicht abbildbar. 2. Struktur: In HTML können keine Datenstrukturen jenseits von Formatinformationen beschrieben werden. Der Zusammenhang der Daten untereinander ist nicht beschreibbar. 3. Validierung: Bei HTML fehlen Sprachspezifikationen, die den Anwendungen, die HTML-codierte Daten verarbeiten sollen, eine Überprüfung der strukturellen Validität der Daten erlauben, d.h. eine Überprüfung der Korrektheit der Struktur des Markup in HTML Dokumenten. Außerdem weist HTML noch andere Mängel auf, die den Einsatz von HTML als Markup-Sprache außerhalb eines Browsers nahezu unmöglich machen: Beispielsweise haben proprietäre Erweiterungen den Standard inzwischen weitgehend verwässert. So stand man nach mehreren Jahren der Benutzung von HTML vor dem Problem, dass andere Tools den heutigen HTML Code nicht sinnvoll interpretieren können und dass beliebige anwendungsspezifische Strukturen in HTML nicht abbildbar sind. Man erkannte, dass man die Meta-Eigenschaft von SGML auch im Web verwenden sollte, um die Sprache dem Verwendungszweck anpassen zu können und damit unter anderem auch dem Missbrauch vordefinierter Tags vorzugreifen. Allerdings ist SGML sehr komplex. Darum ist es auch keine einfache Aufgabe, SGMLverarbeitende Tools zu entwickeln. Daraufhin entschloss man sich, eine vereinfachte Version von SGML zu kreieren, die zwar gleich mächtig wie SGML, aber einfacher zu - 4 -

13 - 2. Entstehung von XML - verarbeiten sein sollte. Das Ergebnis dieser Bestrebungen war XML, die extensible Markup Language, die lediglich eine Untermenge von SGML ist Das World Wide Web Consortium Um die Bedeutung von XML richtig einschätzen zu können, soll nun zuerst das Konsortium, das den Standard verabschiedet hat, vorgestellt werden, bevor auf die Syntax von XML eingegangen wird. Die Spezifikation von XML so wie andere für XML notwendige Technologien wurde vom World Wide Web Consortium (W3C) entwickelt. Die entsprechenden Spezifikationen werden dort auch weiter gepflegt. Abbildung 2-1: Das Logo des W3C Das W3C ist eine Institution, die im Oktober 1994 von Tim Berners-Lee (dem "Erfinder" des Web) am MIT (Massachusetts Institute of Technology) in Zusammenarbeit mit dem CERN (European Organization for Nuclear Research) gegründet wurde. 2 Während die Spezifikation von SGML weit über hundert Seiten umfasst, begnügt sich die XML Spezifikation mit 30 Seiten

14 - 2. Entstehung von XML - Das W3C hat zum Ziel, Protokolle zu entwickeln, die das WWW weiter verbessern sollen. Dabei wird besonderer Wert darauf gelegt, dass alle Spezifikationen offengelegt sind, dass der neueste Stand der Technologie berücksichtigt wird und immer lauffähiger Code und Beispiele zur Verfügung gestellt werden. Bis eine Spezifikation vom W3C verabschiedet wird, muss sie mehrere Stadien durchlaufen: I. Note II. Working Draft III. Candidate Recommendation IV. Proposed Recommendation V. Recommendation Über 20 Spezifikationen haben in der Zwischenzeit das Recommendation-Stadium erreicht. Unter anderem zählen dazu: HTML 3.2, 4.0 und 4.01 PNG (Portable Network Graphics) CSS1 und CSS2 (Cascading Style Sheets) XML 1.0 DOM (Document Object Model) Namespaces in XML XSLT 1.0 (XSL Transformations) Der Einfluss des W3C also auch die Durchsetzungskraft der verabschiedeten Spezifikationen ist sehr groß, was sich vor allem durch die immense Anzahl wichtiger Mitglieder im Konsortium begründet. Zu den inzwischen weit über 400 Mitgliedern zählen Technologiehersteller (u.a. Sun, IBM, Intel, Microsoft), Anbieter von (Web) Inhalten, Regierungen, Benutzerorganisationen und Forschungseinrichtungen. Die XML Spezifikation hat im Februar 1998 das Recommendation-Stadium erreicht. Die zugehörige Spezifikation von XML Namespaces folgte im Januar

15 - 2. Entstehung von XML Der XML Standard Wie bereits erwähnt, ist XML lediglich eine Untermenge von SGML. Das bedeutet, dass es auch in XML keine vordefinierten Tags gibt. Genau wie in SGML muss ein Dokumententyp zuerst durch eine DTD definiert werden, bevor dazugehörige XML Files erstellt werden können. Abbildung 2-2: Beziehung zwischen SGML/XML und Anwendungen - 7 -

16 - 2. Entstehung von XML Die XML Grammatik Die Syntax von XML entspricht einer vereinfachten SGML Syntax. Das W3C bezeichnet XML als "regulärer". Die Folgen für Dokumente erkennt man an einem Vergleich von XML und HTML am besten. HTML Es gibt Tags ohne oder mit optionalem Ende-Tag: <P> Attributwerte müssen nicht in Anführungszeichen stehen: <TD ALIGN=LEFT> Es gibt Attribute ohne Wert: <TABLE BORDER> HTML ist nicht case-sensitive XML Jedes Tag muss durch ein Ende-Tag beendet werden: <P>... </P> Attributwerte müssen immer in Anführungszeichen stehen: <TD ALIGN="LEFT"> Jedes Attribut hat einen Wert XML ist case-sensitive Tabelle 2-2: Unterschiede zwischen XML und HTML Dokumenten Anfangs- und Ende-Tags, die keinen Text einschließen, können zur Vereinfachung zusammengezogen werden: <P/>. Ein solches Tag kann Attribute enthalten und kann somit außer der Struktur auch noch Bedeutung tragen Document Type Definition Wie bereits angedeutet, ermöglicht es eine Document Type Definition (DTD), eine eigene Markup-Sprache zu definieren, in der dann die eigentlichen Dokumente verfasst werden können. Die Möglichkeiten einer DTD zur Definition von Sprachelementen werden später ausführlich erläutert. Zum Grundverständnis ist es wichtig zu wissen, dass es eine DTD erlaubt, mit einer Art erweiterter Backus-Naur-Form die Struktur eines XML Dokumentes zu beschreiben. Damit liegen 2 Grammatiken vor, anhand derer die Korrektheit von XML Dokumenten überprüft werden kann: die allgemeine Grammatik für XML und die für eine spezielle XML-basierte Sprache entworfene DTD. Ein XML Dokument, das den Regeln einer bestimmten DTD genügt, ist dann ein Dokument der entsprechenden XML-basierten Sprache

17 - 2. Entstehung von XML Korrektheit von XML Dokumenten Die Tatsache, dass es möglicherweise 2 Grammatiken gibt, die bei der Prüfung der syntaktischen Korrektheit von XML Dokumenten konsultiert werden müssen, hat weitreichende Konsequenzen. Soll etwa die syntaktische Korrektheit von XML Dokumenten beurteilt werden, so wird konsequenterweise auch zwischen zwei Stufen unterschieden: Well-formed (wohlgeformt) ist ein Dokument, das: der XML Syntax genügt, genau ein Wurzelelement hat, korrekt geschachtelt ist. Die Entscheidung, ob ein Dokument well-formed ist, kann also ohne die DTD getroffen werden, wichtig sind nur die allgemeinen syntaktischen Regeln von XML selbst. Valid (gültig) ist ein Dokument, das: well-formed ist, über eine DTD verfügt, dieser DTD entspricht. Um über die Gültigkeit eines Dokumentes entscheiden zu können, muss daher eine DTD verfügbar sein. Ein gültiges Dokument muss also den zwei syntaktischen Regelwerken genügen: den allgemeinen Regeln von XML selbst und den in der DTD festgehaltenen Regeln. 2.4 XML-basierte Sprachen Die folgende unvollständige Liste zeigt, welche Bedeutung XML inzwischen bereits erreicht hat. XML-basierte Sprachen wurden praktisch in allen Anwendungsgebieten definiert, wo es um einen portablen Datenaustausch in einer heterogenen Landschaft geht. XML Umfeld XSL (XML Stylesheet Language) XSD (XML Schema Definition) GUI Umfeld XSL-FO (XSL Formatting Objects) XHTML (XML based HTML) SVG (Scalable Vector Graphics) SMIL (Synchronized Multimedia Integration Language) - 9 -

18 - 2. Entstehung von XML - Java Umfeld J2EE Deployment Descriptor Web Services WSDL (Web Service Description Language) UDDI (Universal Description, Discovery and Integration) SOAP (Simple Object Access Protocol) ebxml (electronic business XML) Financial Services FSML (Financial Services Markup Language) BIPS (Bank Internet Payment System) SDML (Signed Document Markup Language) Divers MathML (Mathematical Markup Language) HDML (Handheld Device Markup Language) WML (Wireless Markup Language) PICS (Platform for Internet Content Selection) Von den hier aufgelisteten Sprachen spielen die meisten im Folgenden keine Rolle mehr. Nur die im XML Umfeld selbst benutzten Sprachen: XSL und XSD un die Web Service Technologien werden später in diesem Manuskript vorgestellt. Die Liste erhebt keinen Anspruch auf Vollständigkeit und soll nur die inzwischen weite Verbreitung von XML dokumentieren

19 - 3. XML Dokumente - 3 XML Dokumente 3.1 Das Sprachkonzept XML ist eine textbasierte Meta-Auszeichnungssprache, die die Beschreibung, den Austausch, die Darstellung und die Manipulation von strukturierten Daten erlaubt, so dass diese von einer Vielzahl von Anwendungen genutzt werden können. Abbildung 3-1: Das Sprachkonzept von XML XML basiert genau wie SGML auf der Idee des strukturierten Auszeichnens von Daten. Das Grundkonzept von XML ist die Trennung von Inhalt, Struktur und Layout. XML Dokumente unterscheiden sich auf den ersten Blick nicht wesentlich von HTML Dokumenten. Auch XML Dokumente bestehen aus durch Tags ausgezeichneten Inhalten. Während die Anzahl und Benennung der Tags für HTML aber vorgegeben sind, können für XML Dokumente beliebig viele und frei ("semantisch") benannte Tags verwendet werden. Somit besteht der wesentliche Unterschied darin, dass die Tags Informationen über den Inhalt enthalten können und die Verschachtelung der Tags ineinander die Struktur der Daten abbilden kann. Die Layout-Information für die Präsentation wird aus den eigentlichen XML Dokumenten herausgezogen und in sogenannten Stylesheets definiert. Diese werden später in einem eigenen Kapitel vorgestellt

20 - 3. XML Dokumente - XML unterscheidet sich in den folgenden drei Punkten grundsätzlich von HTML [Bosa97]: Tags und Attribute können individuellen Anforderungen entsprechend definiert und benannt werden. Dokumentenstrukturen können in beliebiger Komplexität abgebildet werden. XML Dokumente können müssen aber nicht eine formale Beschreibung ihrer Grammatik enthalten. Die rechte Teil der Tabelle 2-1 beschreibt ein vollständiges XML Dokument. Die Bedeutung des Inhaltes der Tags ergibt sich aus der semantischen Auszeichnung, die Verschachtelung gibt die Struktur der Daten wieder, im Beispiel hat der Artikel einen Titel und einen Autor. Während HTML Dokumente in erster Linie beschreiben, wie der Inhalt der Tags darzustellen ist, kann ein XML Dokument Aussagen über die Bedeutung des Inhaltes enthalten. Die logische Struktur wird also von der Anordnung der Tags im Dokument bestimmt. Die in einem XML Dokument verwendeten Tags werden sozusagen als benannte Klammer verwendet, um den Inhalt der Elemente zu gliedern. Ein XML Dokument kann unabhängig von der logischen Struktur in beliebig viele physische Einheiten zerlegt werden. Allerdings müssen alle in einer physischen Einheit geöffneten Tags auch in dieser wieder geschlossen werden. Hiermit besteht die Möglichkeit, im Netzwerk verteilte XML Daten in einem XML Dokument zusammenzutragen. Der nächste Abschnitt geht nun auf die Einzelheiten des Aufbaus von XML Dokumenten ein. 3.2 Aufbau von XML Dokumenten XML Dokumente sind in zwei Bereiche gegliedert: den Prolog und den Dokumentkörper (document body). Der Prolog enthält für den Leser (im Wesentlichen ein XML Prozessor) notwendige Informationen über das Dokument. Das eigentliche Dokument befindet sich im Dokumentkörper, der also die tatsächlichen Daten enthält. Theoretisch kann am Ende auch ein Epilog folgen, der jedoch praktisch nie benutzt wird

21 - 3. XML Dokumente Der Prolog Das erste, das man in einem XML Dokument zu lesen bekommt, ist die XML Deklaration. Diese beinhaltet die Information über die verwendete XML Version (es gibt bis jetzt nur 1.0) und den verwendeten Zeichencode. Beginnt ein Dokument mit: <?xml version="1.0" encoding="utf-16"?> so bedeutet dies, dass es sich um ein XML Dokument der Version 1.0 handelt, das in der Unicode-Codierung UTF-16 geschrieben wurde. XML verlangt, dass alle Parser Unicode beherrschen, d.h. bei den üblichen Unicode-Codierungen (UTF-8 oder UTF-16) darf es keine Probleme geben. Die Benutzung anderer Zeichencodes ist abhängig vom gewählten Parser. Auf die Deklaration folgt die Zuordnung zum Dokumententyp: <!DOCTYPE HTML SYSTEM "XHTML.DTD"> Bei diesem Dokument handelt es sich um ein XHTML Dokument und die DTD findet sich im File XHTML.DTD. Die DTD kann an dieser Stelle auch direkt angegeben werden, allerdings ist es üblich, sie in ein *.DTD File auszulagern. Auf den Aufbau und den Inhalt einer DTD wird später eingegangen. Ein Dokument muss nicht unbedingt einer DTD zugeordnet sein, d.h. die DOCTYPE-Instruktion kann auch fehlen. Nun können noch sogenannte Processing-Instructions (in <?...?> eingeschlossen) folgen, die speziellen Applikationen Hinweise darüber geben können, wie das Dokument zu verarbeiten ist. Um beispielsweise ein Stylesheet einem XML Dokument zuzuordnen, kann folgende Processing-Instruction verwendet werden: <?xml-stylesheet href="mystyle.xsl" type="text/xsl"?> Die Attribute sind vom Ziel der Processing-Instruction abhängig, das in diesem Fall xml-stylesheet bildet. Auf den Aufbau und den Inhalt von XSL Stylesheets sowie auf die Bedeutung dieser Instruktion wird später eingegangen

22 - 3. XML Dokumente Der Dokumentkörper Der Dokumentkörper besteht lediglich aus Markup und dem Text. Der Text darf enthalten: Beliebige Zeichen aus dem Code Entity-Referenzen wie z.b. < Andere Zeichen mit Hilfe von Escape-Sequenzen, z.b.: als dezimale Codierung für Leerzeichen als hexadezimale Codierung ebenfalls für das Leerzeichen Außerdem besteht mit CDATA (character data) die Möglichkeit "uninterpretierte" Textsegmente in das Dokument zu integrieren: <![CDATA[ ]]> Alles was hier steht ist Text. Selbst >, &, <, " und ' sind hier nur Text. Die einzige verbotene Zeichenfolge in CDATA-Abschnitten ist ]]>. Mit dieser Sequenz wird der CDATA-Abschnitt beendet. Für das Markup gelten folgende Regeln: Jedes Tag muss geschlossen werden: <TAG>Text</TAG> Attribute stehen im Anfangs-Tag und ihre Werte werden in Anführungszeichen eingeschlossen: <kapitel titel="analyse">text</kapitel> Auch leere Elemente haben einen Anfangs- und einen Ende-Tag, allerdings können diese zusammengeschrieben (ohne Raum für Text) werden: <IMG SRC="bild.jpg"/> Das Ende-Tag wird hier durch /> dargestellt. Das Dokument darf lediglich ein Wurzelelement enthalten (z.b. Adressbuch im folgenden Beispiel). Die Elemente müssen alle korrekt ineinander verschachtelt sein, es dürfen also keine Überlappungsbereiche vorhanden sein. Überall, wo im Dokument Text stehen darf, dürfen auch Kommentare stehen. Diese müssen in <! > eingeschlossen sein und dürfen die Zeichenfolge -- nicht enthalten. Beispiel: <!-- Ja, ich bin ein Kommentar -->

23 - 3. XML Dokumente Beispiel: Das Adressbuch Dokument Als Beispiel für ein XML Dokument betrachten wir ein Adressbuch-Dokument (Datei ab.xml), das etwa folgendermaßen aussehen kann: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE Adressbuch SYSTEM "ab.dtd"> <?xml-stylesheet href="ab.xsl" type="text/xsl"?> <Adressbuch> <Adresse> <Name> <Anrede>Herr</Anrede> <Vorname>Max</Vorname> <Nachname>Maier</Nachname> </Name> <Telefon> <Nummer Anschluss="festnetz"> </Nummer> <Nummer Anschluss="mobil"> </Nummer> </Telefon> </Adresse> <Adresse> <Name> <Vorname>John</Vorname> <Nachname>Dough</Nachname> </Name> <Telefon> <Nummer Anschluss="festnetz"> </Nummer> </Telefon> < > < adresse>john.dough@gmx.de</ adresse> < adresse>jd@somewhere.com</ adresse> </ > </Adresse> </Adressbuch> Der (überflüssige) Whitespace vor den Tags soll helfen, die hierarchische Struktur des Dokuments zu verdeutlichen. Da jede hierarchische Struktur als Baumstruktur dargestellt werden kann, wird durch die Einrückung auch diese Baumstruktur deutlich. Hier kann man sich nun fragen, woher denn nun die Tag-Namen kommen und welche Struktur die einzelnen Elemente haben müssen. Damit diese Fragen

24 - 3. XML Dokumente - beantwortet werden können, gibt es die sogenannte Document Type Definition (DTD). Diese kann direkt in einem XML Dokument erscheinen oder in eine Datei ausgelagert werden. Die Zuornung zu einer DTD erfolgt in einer DOCTYPE-Definition im Prolog eines Dokumentes. Im Beispiel wird definiert, dass die zugehörige DTD in der Datei ab.dtd zu finden ist und das Wurzelelement den Namen Adressbuch hat. 3.3 Document Type Definition Wie bereits angedeutet, ermöglicht es eine DTD, eine eigene Markup-Sprache zu definieren, in der dann wiederum XML Dokumente verfasst werden können. In einer DTD werden mit Hilfe einer erweiterten Backus-Naur-Form beschrieben, wie der Dokumentkörper eines XML Dokumentes aufgebaut sein muss, also welche Tag- Namen erlaubt sind, welche Elemente wie geschachtelt sein dürfen, welche Elemente welche Attribute haben dürfen, etc. Im Folgenden werden nun die Möglichkeiten zur Definition von XML Dokumenten erläutert Elemente Das entscheidende Strukturprinzip in XML bilden die Elemente. Ein Element wird über seinen Namen identifiziert und hat einen definierten Inhalt: <!ELEMENT Name Inhalt> Der Inhalt eines Elements kann aus einer Kombinationen von anderen Elementen und/oder Text bestehen oder leer sein. Es existieren mehrere Möglichkeiten der Kombination: Sequenz <!ELEMENT Nachricht (Absender, Empfänger, Nachrichtentext)> Eine Nachricht ist zusammengesetzt aus Absenderinformation gefolgt von Empfängerinformation gefolgt vom Nachrichtentext. Option <!ELEMENT Nachrichtentext (Betreff?, Textkörper)> Das Element Nachrichtentext kann ein Betreff-Element vor dem Textkörper aufnehmen. Alternative <!ELEMENT Block (PARA TABLE IMG)> Ein Block besteht entweder aus einem Absatz oder einer Tabelle oder einem Bild

25 - 3. XML Dokumente - Iteration <!ELEMENT Liste (Name, Item+)> Eine Liste hat einen Namen und enthält mindestens ein Item. <!ELEMENT Bus (Fahrgast*)> Ein Bus kann beliebig viele (also auch keine) Fahrgäste aufnehmen. Text-Inhalt <!ELEMENT Name (#PCDATA)> Das Element Name enthält lediglich Text (PCDATA steht für parsable character data). gemischter Inhalt <!ELEMENT PARA (#PCDATA I B A)*> Ein Abschnitt kann in beliebiger Reihenfolge Text, kursiv-markierten Text 1, fettmarkierten Text 2 oder Links 3 enthalten. beliebiger Inhalt <!ELEMENT Divers ANY> leere Elemente <!ELEMENT BR EMPTY> Die Tag-Namen (Element-Namen) können frei gewählt werden, um die semantische Bedeutung (des Inhalts) eines Elementes dem Leser zu verdeutlichen. Es gibt nur wenige Regeln, die die Bildung von Namen einschränken: - Namen müssen mit Buchstaben oder mit dem Zeichen "_" beginnen. - Danach können Buchstaben, Ziffern oder die Zeichen "_", "-" und "." kommen. - Leerzeichen und Doppelpunkt sind in Namen nicht erlaubt. - Namen dürfen nicht mit der Zeichenfolge "xml" beginnen, auch nicht in Großbuchstaben oder gemischt geschrieben. Diesen Regeln müssen alle Namen, die in einem XML Dokument möglich sind, genügen, also nicht nur Tag-Namen sondern beispielsweise auch Attribut-, Entityund Namespace-Namen. Groß- und Kleinschreibung wird bei XML unterschieden, sodass tag und Tag unterschiedliche Namen für ein Element darstellen. Wenn aber beispielsweise diese beiden Schreibweisen durch eine DTD ermöglicht würden, würde sicher bei 1 <I> steht in HTML für italic. 2 <B> steht in HTML für bold. 3 Mit <A> werden in HTML Web-Links markiert

26 - 3. XML Dokumente - menschlichen Lesern eines entsprechenden Instanzdokumentes Konfusion entstehen. Bei der Wahl der Namen sollte man also immer davon ausgehen, dass es sowohl maschinelle Leser (Applikationen) aber auch menschliche Leser von XML Dokumenten geben kann Attribute Elemente in XML können jedoch nicht nur einen Inhalt haben: zusätzlich besteht die Möglichkeit, sie mit Attributen zu versehen. In der DTD wird dies dadurch definiert, dass einem Element Attributlisten zugewiesen werden. <!ATTLIST Bus Fahrzeugtyp CDATA #IMPLIED Kennzeichen CDATA #REQUIRED> ATTLIST steht hier als Abkürzung für Attributliste. Ein Bus hat also das Attribut Fahrzeugtyp, welches in einem XML Dokument angegeben werden kann (IMPLIED), und das Attribut Kennzeichen, das angegeben werden muss (REQUIRED). Beide Attribute können beliebige Strings (CDATA steht für character data) als Wert annehmen. <!ATTLIST Fahrgast id ID #REQUIRED stammkunde (ja nein) "nein"> Das Attribut vom Typ ID hat in XML eine besondere Bedeutung: keine ID eines Fahrgast-Elements darf den gleichen Wert haben wie die ID irgend eines anderen Fahrgast-Elements. Diese Eigenschaft wird auch vom Parser überprüft. Ein solches Attribut spielt damit die Rolle eines eindeutigen Schlüssels (vergleichbar mit einem Primärschlüssel) und kann beim Suchen und Navigieren entsprechend ausgenutzt werden. Für IDs gelten die gleichen Regeln für den Aufbau wie bei Namen, siehe Das Attribut Stammkunde ist ein Aufzählungstyp und kann die Werte "ja" oder "nein" annehmen. Wird dieses Attribut bei einem Fahrgast-Element nicht explizit angegeben, so ist sein Wert als "nein" anzusehen. Bei Attribut-Deklarationen wird CDATA (character data) angegeben im Gegensatz zu PCDATA bei Element-Deklarationen. PCDATA steht für parsable character data. Im Gegensatz zu PCDATA wird CDATA nicht mehr vom Parser analysiert. Dadurch werden innerhalb von CDATA keine Markup-Zeichen wie spitze Klammern erkannt

27 - 3. XML Dokumente Beispiel: Die Adressbuch DTD Das folgende Beispiel soll die Struktur eines Adressbuches beschreiben. Ein Beispieldokument war in bereits zu sehen. Die Adressen innerhalb des Adressbuches sollen ein Namens-, ein Telefon- und optional ein segment haben. Mit der Information aus dem vorherigen Abschnitt sollte die DTD eigentlich leicht zu verstehen sein. Die DTD für das Adressbuch (zu finden in der Datei ab.dtd): <!ELEMENT Adressbuch (Adresse)*> <!ELEMENT Adresse (Name, Telefon, ( )?)> <!ELEMENT Name ((Anrede)?, (Vorname)?, Nachname)> <!ELEMENT Anrede (#PCDATA)> <!ELEMENT Vorname (#PCDATA)> <!ELEMENT Nachname (#PCDATA)> <!ELEMENT Telefon (Nummer)+> <!ELEMENT Nummer (#PCDATA)> <!ATTLIST Nummer Anschluss (mobil festnetz) #REQUIRED> <!ELEMENT ( adresse)+> <!ELEMENT adresse (#PCDATA)> Entities Entities können in der DTD definiert und dann in einem XML Dokument über &Entityname; referenziert werden. Beim Parsen des XML Dokumentes wird diese Referenz durch den in der DTD angegebenen Text ersetzt. Eine Entity-Definition in der DTD sieht aus wie folgt: <!ENTITY SW "Softwaretechnik"> Diese Entity kann dann im XML Dokument z.b. so verwendet werden: <PERSON>Hans Müller, Studiengang: &SW;</PERSON> Der Begriff Entity wird in XML in einer etwas untypischen Art verwendet und sollte nicht mit anderen bekannten Bedeutungen aus der Informatik (beispielsweise dem E/R-Modell) assoziiert werden. Entities in XML entsprechen eher dem #define in C oder anderen sogenannten Makromechanismen

28 - 3. XML Dokumente - Es gibt eine Reihe von Standard-Entities, die immer verfügbar sind, also nicht definiert werden müssen: < < (less than) > > (greater than) & & (ampersand) &apos; ' (apostrophe) " " (quotation mark) Diese Entities (built-in entities) werden häufig gebraucht, da die entsprechenden Zeichen in der XML Syntax eine besondere Rolle spielen. Will man ein Zeichen in ein Dokument einfügen, das schwierig zu schreiben ist, kann man dies ebenfalls über den Entity-Mechanismus tun: bedeutet, dass das Zeichen mit der Nummer 169 aus dem im Prolog angegebenen Code im Unicode wäre das also eingefügt wird (character entity). Die oben bereits vorgestellten allgemeinen Entities (general entities) können prinzipiell beliebig groß sein und können insbesondere auch XML Fragmente enthalten. Es gelten allerdings ein paar Bedingungen: der String muss wohlgeformt sein und darf keinen Bezug auf sich selbst beinhalten. Um große Strings, die durch ein Entity repräsentiert werden sollen, auch außerhalb des Dokumentes unterzubringen, gibt es noch die sogenannten externen Entities (external entities): Sie verweisen auf Dateien im System (SYSTEM mit Dateinamen) oder im Web (PUBLIC mit Dateinamen und URI). Das folgende Beispiel zeigt den ersten Fall, die Entity adressen steht für das komplette Adressbuch: <ENTITY adressen SYSTEM "ab.xml"> Auch hier gilt natürlich die Forderung, dass der Inhalt der Datei wohlgeformt sein muss. Ein validierender Parser wird das prüfen, und den Inhalt der Datei an der Stelle einfügen, wo die Entity (im Beispiel durch &adressen;) referenziert wird. Nicht-validierende Parser brauchen das nicht zu tun, sie müssen externe Entities noch nicht einmal ersetzen! Soll der Inhalt eines externen Entities nicht geprüft werden, weil beispielsweise eine Binärdatei, etwa ein Bild, eingefügt werden soll, dann kann das durch den Zusatz NDATA (Notation Data) gekennzeichnet werden. Ein Parser wird dann die externe Entity nicht prüfen

29 - 3. XML Dokumente - Weiterhin gibt es noch Parameter-Entities, die in der DTD selbst referenziert werden können. Die bisherigen Entities waren ja als Abkürzungen für Texte gedacht, die im eigentlichen XML Dokument stehen sollen. Parameter-Entities und ihre Verwendung müssen bei Bedarf nachgeschlagen werden Document Type Deklaration Im Adressbuchbeispiel war die Document Type Deklaration zu sehen. Hier wurde die DTD in einer externen Datei gehalten. Sie hatte die Form: <!DOCTYPE Adressbuch SYSTEM "ab.dtd"> Es wird dabei das Wurzelelement angegeben und hinter SYSTEM steht eine URL, die es erlaubt auf die DTD zuzugreifen. In diesem Falle war es eine lokale Datei. In manchen Fällen kann es sinnvoll sein, die DTD direkt in das XML Dokument mit einzuschließen, beispielsweise wenn Dokumente verschickt werden, um den zusätzlichen Zugriff auf die DTD zu vermeiden. Hier hat dann die DOCTYPE Deklaration die Form: <!DOCTYPE Adressbuch [...]> und zwischen den eckigen Klammern stehen die Element- und Attributdefinitionen usw., also die gesamte DTD. Eine weitere Möglichkeit bietet sich für "öffentliche" DTDs: <!DOCTYPE Adressbuch PUBLIC "W3C//DTD XHTML 1.0 Strict//EN"> Hinter PUBLIC steht ein sogenannter Formal Public Identfier (FPI), der die DTD identifizieren muss. Da hierbei keine Möglichkeit besteht auf die DTD zuzugreifen, muss ein validierender Parser diese DTD kennen, d.h. sie muss in seinem Code bereits vorhanden sein. 3.4 Die Baumstruktur Ein XML Dokument besitzt immer eine baumartige Struktur, die bei einem eindeutigen Wurzelelement beginnt. Diese Struktur wurde beim Adressbuch-Beispiel im vorangegangenen Abschnitt durch Einrückungen hervorgehoben. Diese Struktur, die im Wesentlichen durch die Schachtelung der Tags gegeben ist, kann auch graphisch als Baumstruktur gezeichnet oder im Speicher aufgebaut werden (DOM Baum, siehe Kapitel 4). Der eigentliche Text sowie die Attribute eines Elementes werden ebenfalls als Knoten in diesen Baum aufgenommen und mit dem entsprechenden Element als Vaterknoten verknüpft. Text- und Attributknoten sind

30 - 3. XML Dokumente - immer Blätter in dieser Baumstruktur. Sie werden von den Elementknoten im folgenden Bild durch Form, bzw. Farbe unterschieden. Das folgende Bild zeigt das Adressbuch-Beispiel in dieser Baumdarstellung. Abbildung 3-2: Das XML Dokument als Baum

31 - 3. XML Dokumente Namespaces Die Flexibilität von XML kann allerdings Probleme mit sich bringen: Will man mehrere Tag-Sets in einem Dokument verwenden, so kann es zu Kollisionen zwischen den Element- und Attributnamen der verwendeten Sprachen kommen. Beispielsweise werden in XSL Transformationen (siehe Kapitel 5) 3 verschiedene Tag-Sets (oder Vokabulare) benutzt: das Quell- und das Zielvokabular, sowie das Vokabular von XSL. Dieses Problem wurde früh erkannt und am 14. Januar 1999 verabschiedete das W3C die Recommendation Namespaces in XML. Mit dem Namespace-Konzept wird es möglich, entweder einzelne Tags oder ganze Segmente in einem Dokument einem Namensraum zuzuordnen. Die Wahl des Namensraumes wird mit dem Attribut xmlns (Abkürzung für XML NameSpace) getroffen. Der Namensraum an sich wird in Form eines URI (Uniform Resource Identifier) angegeben. Die Wahl gilt für das Element, dem das Attribut zugeordnet ist, und alle untergeordneten Tags. Damit können auch Teile eines Dokumentes unterschiedlichen Namensräumen zugeordnet werden. D.h. ein durch ein xmlns- Attribut eingeführter Namensraum, kann schon bei dem Element selbst, bei dem das Attribut steht, und in dem kompletten dazugehörigen Unterbaum benutzt werden. Man unterscheidet zwei verschiedene Formen, je nachdem ob man einen Präfix einführt, der den Namensraum kennzeichnet, oder ob generell alle Namen einem Default-Namensraum zugeordnet werden. Allerdings hat die Benutzung von Namespaces auch Probleme, die am Ende dieses Kapitels angesprochen werden Default-Namensraum Werden Element- oder Attributnamen ohne Zusatz benutzt (wie es in allen bisherigen Beispielen der Fall war), dann gehören diese Namen zum Default-Namensraum. Ohne weitere Angabe ist das der lokale Namensraum, der beispielsweise durch die DTD gegeben ist. Dieser Default-Namensraum kann aber auch für einzelne Teile eines XML Dokumentes geändert werden. Es folgt ein Beispiel für Namespace Defaulting, d.h. es wird ein Namensraum gewählt (hier der von HTML), dem alle untergeordneten Tags per Default zugeordnet werden. Die Verwendung von Tags wie beispielsweise <head> oder <title> wird damit zulässig

32 - 3. XML Dokumente - <?xml version="1.0"?> <html xmlns=" <head> <title>xml Namespaces></title> </head> <body> XML Namespaces Recommendation, siehe <a href=" hier. </a> </body> </html> Namensräume mit Präfix Alternativ besteht auch die Möglichkeit bestimmte Namensräume einem Präfix zuzuordnen, das dann bei Tags in der Form <präfix:tagname> eingesetzt werden kann. Das wird in folgendem Beispiel gezeigt: <?xml version="1.0"?> <buch xmlns:isbn="urn:isbn: "> <titel>es ist schön</titel> <autor>hans Dampf</autor> <isbn:number> </isbn:number> <preis>20.-</preis> </buch> Während die Tags ohne Präfix hier aus dem Default-Namensraum stammen, ist number dem isbn-namensraum entnommen. Da der Default-Namensraum nicht festgelegt wurde, sind die Tags ohne Präfix dem lokalen Namensraum entnommen. Das Attribut xmlns kann auch mehrfach bei einem Element auftreten. So können dann über verschiedene Präfixe auch mehrere Namensräume parallel verwendet werden Problematik von Namensräumen Ein Namensraum wird nur durch eine URI bestimmt. Was sich dahinter verbirgt, ist jedoch nicht weiter festgelegt. Es kann sich dort eine DTD, eine einfache Tag- und Attributsnamensliste oder ein Textdokument mit einer verbalen Beschreibung befinden, es kann aber auch gar nichts dort sein. Ein Parser ist deswegen nicht in der Lage, Informationen über den Namespace zu beziehen, da gar nicht geklärt ist, welche Art von Information einen Namespace

33 - 3. XML Dokumente - beschreibt. Selbst wenn dies klar wäre, bräuchte man beim Parsen eine offene Internetverbindung, um auf die Information zuzugreifen. Wenn man also mit Namensräumen arbeitet, kann die Gültigkeit eines Dokumentes nur noch eingeschränkt geprüft werden. Die meisten Parser bieten Schalter an, mit denen eingestellt werden kann, ob überhaupt Namensräume beachtet werden oder nicht. Betrachtet man Namensräume, die vom W3C selbst definiert wurden, dann kann man diese Problematik beispielhaft studieren. Die Beispiele werden im Verlauf dieses Manuskripts noch auftauchen: Das W3C hat Namensräume im Zusammenhang mit XSL und XML Schema definiert. Die entsprechenden URIs sind: bzw. Gibt man diese URIs in einem Browser an, erhält man einen kleinen Text angezeigt mit Links auf wichtige Informationen im Zusammenhang mit XSLT, bzw. mit XML Schema. Das Auftreten dieser Namespaces veranlaßt einen Parser nun keineswegs auf diese URI zuzugreifen. Wenn er auf Schema-Validierung eingestellt ist, prüft er diese URI und die Versionsangabe, ob diese Informationen mit seinem Code zur Behandlung von Schema-Definitionen übereinstimmen. Ähnlich für XSL Prozessoren: sie enthalten bereits den Code zur Interpretation der XSL Anweisungen. In beiden Fällen erlauben die Präfixe jeweils ein schnelles Finden der für die jeweiligen Prozessoren vorgesehenen Tags Definition eigener Namensräume Die Recommendation für die XML Namenspaces wurde nach der XML Spezifikation, in der auch die DTDs spezifiziert werden, verabschiedet. DTDs sind daher mit Namespaces inkompatibel. Erst mit Schema-Definitionen, die in einem eigenen Kapitel später noch behandelt werden, wird es möglich, eigene Namensräume zu definieren und sich in Instanzdokumenten darauf zu beziehen. Hinweise dazu sind in dem entsprechenden Kapitel zu finden. 3.6 Aufteilung in physische Einheiten ToDo