Einführung in XML - IT

Transcrição

S T E I N B E I S -T R A N S F E R Z E N T R U M
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 2
73730 Esslingen-Zell
Leiter: Prof. Dr. Joachim Goll
Fon: (07 11) 305 111 50
Fax: (07 11) 305 111 12
- 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:
[email protected].
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.
STEINBEIS-TRANSFERZENTRUM
SOFTWARETECHNIK
Einführung in XML
-i-
©
Prof. J. Goll
- Verzeichnisse -
Inhaltsverzeichnis
1 EINLEITUNG...................................................................................................................................1
2 ENTSTEHUNG VON XML ............................................................................................................2
2.1
2.1.1
2.1.2
2.2
2.3
2.3.1
2.3.2
2.3.3
2.4
MARKUP-SPRACHEN ...................................................................................................................2
SGML ....................................................................................................................................2
HTML ....................................................................................................................................3
DAS WORLD WIDE WEB CONSORTIUM .....................................................................................5
DER XML STANDARD .................................................................................................................7
DIE XML GRAMMATIK ..........................................................................................................8
DOCUMENT TYPE DEFINITION ...............................................................................................8
KORREKTHEIT VON XML DOKUMENTEN ..............................................................................9
XML-BASIERTE SPRACHEN........................................................................................................9
3 XML DOKUMENTE .....................................................................................................................11
3.1
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.4
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.6
DAS SPRACHKONZEPT ..............................................................................................................11
AUFBAU VON XML DOKUMENTEN ..........................................................................................12
DER PROLOG ........................................................................................................................13
DER DOKUMENTKÖRPER......................................................................................................14
BEISPIEL: DAS ADRESSBUCH DOKUMENT ...........................................................................15
DOCUMENT TYPE DEFINITION .................................................................................................16
ELEMENTE ............................................................................................................................16
ATTRIBUTE ...........................................................................................................................18
BEISPIEL: DIE ADRESSBUCH DTD .......................................................................................19
ENTITIES ...............................................................................................................................19
DOCUMENT TYPE DEKLARATION ........................................................................................21
DIE BAUMSTRUKTUR ................................................................................................................21
NAMESPACES .............................................................................................................................23
DEFAULT-NAMENSRAUM .....................................................................................................23
NAMENSRÄUME MIT PRÄFIX ................................................................................................24
PROBLEMATIK VON NAMENSRÄUMEN .................................................................................24
DEFINITION EIGENER NAMENSRÄUME .................................................................................25
AUFTEILUNG IN PHYSISCHE EINHEITEN ..................................................................................25
4 XML PARSER UND SCHNITTSTELLEN .................................................................................26
4.1
4.1.1
4.1.2
4.2
4.3
4.3.1
4.3.2
4.3.3
4.4
4.4.1
ÜBERSICHT ................................................................................................................................26
WOHLGEFORMT VS. GÜLTIG ................................................................................................27
NICHT-VALIDIERENDE PARSER ............................................................................................27
PROGRAMMIERUNG IN JAVA ....................................................................................................28
DAS DOCUMENT OBJECT MODEL ............................................................................................29
DAS DOM PROGRAMMIERMODELL .....................................................................................29
DOM IN JAVA.......................................................................................................................31
PARSEN DES ADRESSBUCHES MIT DOM ..............................................................................32
SIMPLE API FOR XML .............................................................................................................36
DAS PROGRAMMIERMODELL VON SAX...............................................................................37
SOFTWARETECHNIK
Einführung in XML
- ii -
©
Prof. J. Goll
- Verzeichnisse 4.4.2
SAX IN JAVA ........................................................................................................................37
4.4.3
PARSEN DES ADRESSBUCHES MIT SAX ...............................................................................39
4.5
VERGLEICH VON DOM UND SAX ............................................................................................42
4.6
WEITERFÜHRENDE ENTWICKLUNGEN ....................................................................................42
4.6.1
SAX + DOM = SAXDOMIX ...............................................................................................42
4.6.2
DIE JDOM BIBLIOTHEK .......................................................................................................43
4.6.3
DEFERRED PARSING .............................................................................................................44
4.6.4
PULL PARSING ......................................................................................................................44
4.7
ZUSAMMENFASSUNG .................................................................................................................45
5 STYLESHEETS..............................................................................................................................46
5.1
5.1.1
5.1.2
5.1.3
5.2
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.4.6
5.5
5.5.1
5.5.2
5.6
5.6.1
5.6.2
5.6.3
5.6.4
5.6.5
5.6.6
5.6.7
5.6.8
DIE VORFAHREN VON XSL ......................................................................................................47
CASCADING STYLESHEETS ...................................................................................................47
DOCUMENT STYLE SEMANTICS AND SPECIFICATION LANGUAGE .......................................47
ANWENDBARKEIT VON STYLESHEETS .................................................................................47
DIE EXTENSIBLE STYLESHEET LANGUAGE ............................................................................48
XPATH .......................................................................................................................................51
PFADAUSDRÜCKE .................................................................................................................51
FILTER ..................................................................................................................................53
ACHSEN ................................................................................................................................53
FUNKTIONEN ........................................................................................................................55
XSL TRANSFORMATIONS .........................................................................................................56
DEFINITION DER TRANSFORMATIONEN................................................................................56
DEFAULT TRANSFORMATIONEN ..........................................................................................57
BEISPIEL: TRANSFORMATION DES ADRESSBUCH-DOKUMENTES.........................................58
ZUORDNUNG VON STYLESHEETS ZU DOKUMENTEN ............................................................60
FORMATIERUNG DES OUTPUT ..............................................................................................60
ZUSAMMENFASSUNG............................................................................................................61
PERFORMANCE ASPEKTE .........................................................................................................62
ÄNDERUNGEN IM STYLESHEET ............................................................................................62
XSLTC (TRANSLETS) ..........................................................................................................64
FORMATTING OBJECTS (XSL-FO) ..........................................................................................65
AUFBAU EINES FO DOKUMENTES ........................................................................................67
LAYOUTVORLAGEN ..............................................................................................................68
SEITENSTRUKTURIERUNG ....................................................................................................69
SEITENFOLGEN .....................................................................................................................71
DARSTELLUNG DES INHALTES .............................................................................................71
BEISPIEL ...............................................................................................................................72
VERFÜGBARE XSL-FO PROZESSOREN ................................................................................72
ZUSAMMENFASSUNG............................................................................................................73
6 XML SCHEMA ..............................................................................................................................74
6.1
ENTWICKLUNG VON XML SCHEMA ........................................................................................74
6.1.1
VORGÄNGER VON XML SCHEMA ........................................................................................74
6.1.2
DEFINITION VON XML SCHEMA ..........................................................................................75
6.1.3
VERGLEICH XML SCHEMA – DTD ......................................................................................76
6.2
VALIDIERUNG ÜBER XML SCHEMA DEFINITIONEN ...............................................................78
6.2.1
VALIDIERUNG DER XML SCHEMA DEFINITION ...................................................................80
6.2.2
EINBINDEN EINER SCHEMA DEFINITION IN EIN XML DOKUMENT ......................................80
6.2.3
ZUORDNUNG ZU EINEM NAMESPACE ...................................................................................81
6.3
AUFBAU EINER SCHEMA DEFINITION ......................................................................................82
SOFTWARETECHNIK
Einführung in XML
- iii -
©
Prof. J. Goll
- Verzeichnisse 6.3.1
DEFINITION VON ELEMENTEN ..............................................................................................82
6.3.2
VORDEFINIERTE TYPEN .......................................................................................................84
6.3.3
DEFINITION VON EINFACHEN TYPEN....................................................................................85
6.3.4
LOKALE, GLOBALE UND ANONYME TYPEN .........................................................................87
6.3.5
DEFINITION KOMPLEXER TYPEN ..........................................................................................88
6.3.6
HIERARCHIE DER ELEMENTE ...............................................................................................89
6.3.7
GESCHACHTELTE ELEMENTE UND ATTRIBUTE....................................................................91
6.3.8
KOMPLEXE TYPEN FÜR GEMISCHTEN INHALT .....................................................................92
6.3.9
ERWEITERUNGEN UND EINSCHRÄNKUNG VON KOMPLEXEN TYPEN ...................................92
6.3.10
DOKUMENTATION EINES SCHEMAS ....................................................................................92
6.4
XML SCHEMA BEISPIEL...........................................................................................................93
6.5
XML BINDING FOR JAVA .........................................................................................................95
6.5.1
ARBEITSWEISE VON JAXB...................................................................................................95
6.5.2
AUFBAU DER GENERIERTEN KLASSEN .................................................................................96
6.5.3
JAXB-API............................................................................................................................97
6.5.4
BEWERTUNG.........................................................................................................................98
6.6
ZUSAMMENFASSUNG .................................................................................................................98
7 LINKING IN XML.......................................................................................................................100
7.1
7.2
7.3
ÜBERSICHT ..............................................................................................................................100
XLINK ......................................................................................................................................101
XPOINTER................................................................................................................................102
8 WEB SERVICES ..........................................................................................................................104
8.1
8.1.1
8.1.2
8.1.3
8.2
8.2.1
8.2.2
8.3
8.3.1
8.3.2
8.3.3
8.4
8.4.1
8.4.2
8.5
8.5.1
8.5.2
8.5.3
8.6
8.7
8.7.1
8.7.2
8.7.3
WEB SERVICE DESCRIPTION LANGUAGE – WSDL ..............................................................105
AUFBAU EINES WSDL DOKUMENTS..................................................................................105
WSDL BEISPIEL .................................................................................................................106
WSDL FÜR DEN ECHO-SERVICE ........................................................................................108
SIMPLE OBJECT ACCESS PROTOCOL – SOAP ......................................................................109
AUFBAU EINER SOAP NACHRICHT ....................................................................................110
BEISPIELE FÜR SOAP NACHRICHTEN ................................................................................111
UNIVERSAL DESCRIPTION DISCOVERY AND INTEGRATION – UDDI ...................................113
UDDI STRUKTUREN UND SICHTEN ....................................................................................113
UDDI REGISTRIES ..............................................................................................................114
ZUGRIFF AUF UDDI ...........................................................................................................114
WEB SERVICES TOOLS ...........................................................................................................114
ALLGEMEINE ÜBERSICHT ..................................................................................................115
ÜBERSICHT ÜBER AXIS ......................................................................................................115
ENTWICKELN EIGENER WEB SERVICES ................................................................................117
VORGEHEN BEI DER BOTTOM-UP ENTWICKLUNG .............................................................118
VORGEHEN BEI DER TOP-DOWN ENTWICKLUNG ...............................................................118
VORGEHEN BEI DER ENTWICKLUNG DES CLIENTS.............................................................118
TRANSPORTPROTOKOLLE ......................................................................................................118
ZUSAMMENFASSUNG ...............................................................................................................119
EINSCHRÄNKUNGEN BEI WEB SERVICES ...........................................................................119
BEWERTUNG VON WEB SERVICES ALLGEMEIN .................................................................120
AUSBLICK ...........................................................................................................................120
9 SEMANTIC WEB.........................................................................................................................121
SOFTWARETECHNIK
Einführung in XML
- iv -
©
Prof. J. Goll
- Verzeichnisse 9.1
9.2
RESOURCE DESCRIPTION FRAMEWORK – RDF ...................................................................121
WEB ONTOLOGY LANGUAGE – OWL ...................................................................................121
10 ZUSAMMENFASSUNG ............................................................................................................122
10.1
VORTEILE VON XML ............................................................................................................122
10.1.1
XML HARMONIERT MIT HTML, HTTP UND WEBBROWSERN .........................................122
10.1.2
XML IST EINFACH UND PORTABEL...................................................................................122
10.1.3
XML KANN DOKUMENTE BELIEBIGER KOMPLEXITÄT ABBILDEN ...................................123
10.1.4
XML IST MEHR ALS NUR EINE AUSZEICHNUNGSSPRACHE...............................................123
10.1.5
INTERNATIONALITÄT........................................................................................................124
10.2
ANWENDUNGSFELDER FÜR XML.........................................................................................124
10.2.1
XML ALS STANDARDISIERTES DATENAUSTAUSCHFORMAT ............................................125
10.2.2
VERLAGERUNG DER RECHENLEISTUNG VOM SERVER ZUM CLIENT ................................125
10.2.3
VARIABLE DARSTELLUNG VON INFORMATIONEN ...........................................................125
10.2.4
INTELLIGENTES SUCHEN IN XML DATENBESTÄNDEN ....................................................126
10.3
AUSBLICK ..............................................................................................................................126
11 QUELLENVERZEICHNIS .......................................................................................................127
11.1
11.2
11.3
11.4
LITERATUR ............................................................................................................................127
BÜCHER..................................................................................................................................128
LINKS ZU INFORMATIONSQUELLEN .....................................................................................129
LINKS ZU SOFTWARE HERSTELLERN ..................................................................................130
12 XML TOOLS ..............................................................................................................................131
12.1
XML EDITOREN ....................................................................................................................131
12.1.1
XEENA ..............................................................................................................................131
12.1.2
MERLOT............................................................................................................................132
12.1.3
MORPHON .........................................................................................................................132
12.1.4
EPCEDIT ...........................................................................................................................133
12.1.5
WEITERE XML EDITOREN ...............................................................................................134
12.2
XML PARSER ........................................................................................................................135
12.2.1
XML4J .............................................................................................................................135
12.2.2
XERCES.............................................................................................................................135
12.2.3
JAVA API FOR XML PROCESSING ....................................................................................135
12.3
XSL TOOLS ............................................................................................................................136
12.3.1
XSLT PROZESSOREN .......................................................................................................136
12.3.2
COCOON ...........................................................................................................................137
12.3.3
XSLT EDITOREN ..............................................................................................................137
12.3.4
XSL-FO PROZESSOREN ....................................................................................................138
SOFTWARETECHNIK
Einführung in XML
-v-
©
Prof. J. Goll
- Verzeichnisse -
Abkürzungsverzeichnis
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
SOFTWARETECHNIK
Einführung in XML
- vi -
©
Prof. J. Goll
- 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
SOFTWARETECHNIK
Einführung in XML
- vii -
©
Prof. J. Goll
- 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.
SOFTWARETECHNIK
Einführung in XML
-1-
©
Prof. J. Goll
- 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>.
2.1.1 SGML
Schon Anfang der 70er Jahre sahen sich Entwickler mit einer Vielzahl von MarkupSprachen 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 Metasprache1.
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.
SOFTWARETECHNIK
Einführung in XML
-2-
©
Prof. J. Goll
- 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.
2.1.2 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 263 – 311 [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 ÜberschriftenTags 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.
SOFTWARETECHNIK
Einführung in XML
-3-
©
Prof. J. Goll
- 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
SOFTWARETECHNIK
Einführung in XML
-4-
©
Prof. J. Goll
- 2. Entstehung von XML verarbeiten sein sollte. Das Ergebnis dieser Bestrebungen war XML, die eXtensible
Markup Language, die lediglich eine Untermenge von SGML ist2.
2.2 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.
SOFTWARETECHNIK
Einführung in XML
-5-
©
Prof. J. Goll
- 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 1999.
SOFTWARETECHNIK
Einführung in XML
-6-
©
Prof. J. Goll
2.3 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
SOFTWARETECHNIK
Einführung in XML
-7-
©
Prof. J. Goll
2.3.1 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
XML
Es gibt Tags ohne oder mit
optionalem Ende-Tag:
<P>
Jedes Tag muss durch ein Ende-Tag
beendet werden:
<P> ... </P>
Attributwerte müssen nicht in
Anführungszeichen stehen:
<TD ALIGN=LEFT>
Attributwerte müssen immer in
Anführungszeichen stehen:
<TD ALIGN="LEFT">
Es gibt Attribute ohne Wert:
<TABLE BORDER>
Jedes Attribut hat einen Wert
HTML ist nicht case-sensitive
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.
2.3.2 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.
SOFTWARETECHNIK
Einführung in XML
-8-
©
Prof. J. Goll
2.3.3 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)
SOFTWARETECHNIK
Einführung in XML
-9-
©
Prof. J. Goll
- 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.
SOFTWARETECHNIK
Einführung in XML
- 10 -
©
Prof. J. Goll
- 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.
SOFTWARETECHNIK
Einführung in XML
- 11 -
©
Prof. J. Goll
- 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.
SOFTWARETECHNIK
Einführung in XML
- 12 -
©
Prof. J. Goll
3.2.1 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.
SOFTWARETECHNIK
Einführung in XML
- 13 -
©
Prof. J. Goll
3.2.2 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:

SOFTWARETECHNIK
Einführung in XML
- 14 -
©
Prof. J. Goll
3.2.3 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:
<!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">0711654321</Nummer>
<Nummer Anschluss="mobil">017287654321</Nummer>
</Telefon>
</Adresse>
<Adresse>
<Name>
<Vorname>John</Vorname>
<Nachname>Dough</Nachname>
</Name>
<Telefon>
<Nummer Anschluss="festnetz">0711123456</Nummer>
</Telefon>
<Email>
<Emailadresse>[email protected]</Emailadresse>
<Emailadresse>[email protected]</Emailadresse>
</Email>
</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
SOFTWARETECHNIK
Einführung in XML
- 15 -
©
Prof. J. Goll
- 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 TagNamen 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.
3.3.1 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
Empfängerinformation gefolgt vom Nachrichtentext.
•
gefolgt
von
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.
SOFTWARETECHNIK
Einführung in XML
- 16 -
©
Prof. J. Goll
- 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 Text1, fettmarkierten Text2 oder Links3 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.
<B> steht in HTML für bold.
3
Mit <A> werden in HTML Web-Links markiert.
2
SOFTWARETECHNIK
Einführung in XML
- 17 -
©
Prof. J. Goll
- 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.
3.3.2 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
Kennzeichen
CDATA
CDATA
#IMPLIED
#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
3.3.1.
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.
SOFTWARETECHNIK
Einführung in XML
- 18 -
©
Prof. J. Goll
3.3.3 Beispiel: Die Adressbuch DTD
Das folgende Beispiel soll die Struktur eines Adressbuches beschreiben. Ein
Beispieldokument war in 3.2.3 bereits zu sehen.
Die Adressen innerhalb des Adressbuches sollen ein Namens-, ein Telefon- und
optional ein Emailsegment 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, (Email)?)>
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Name ((Anrede)?, (Vorname)?, Nachname)>
Anrede (#PCDATA)>
Vorname (#PCDATA)>
Nachname (#PCDATA)>
<!ELEMENT Telefon (Nummer)+>
<!ELEMENT Nummer (#PCDATA)>
<!ATTLIST Nummer
Anschluss (mobil|festnetz) #REQUIRED>
<!ELEMENT Email (Emailadresse)+>
<!ELEMENT Emailadresse (#PCDATA)>
3.3.4 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.
SOFTWARETECHNIK
Einführung in XML
- 19 -
©
Prof. J. Goll
Es gibt eine Reihe von Standard-Entities, die immer verfügbar sind, also nicht
definiert werden müssen:
•
<
<
(less than)
•
>
>
(greater than)
•
&
&
(ampersand)
•
'
'
(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.
SOFTWARETECHNIK
Einführung in XML
- 20 -
©
Prof. J. Goll
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.
3.3.5 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
SOFTWARETECHNIK
Einführung in XML
- 21 -
©
Prof. J. Goll
- 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
SOFTWARETECHNIK
Einführung in XML
- 22 -
©
Prof. J. Goll
3.5 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 xmlnsAttribut 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.
3.5.1 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.
SOFTWARETECHNIK
Einführung in XML
- 23 -
©
Prof. J. Goll
<?xml version="1.0"?>
<html xmlns="http://www.w3.org/TR/REC-html40">
<head>
<title>XML Namespaces></title>
</head>
<body>
XML Namespaces Recommendation, siehe
<a href="http://www.w3.org/TR/2006/REC-xml-names-20060816">
hier.
</a>
</body>
</html>
3.5.2 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:
<buch xmlns:isbn="urn:ISBN:0-395-36341-6">
<titel>Es ist schön</titel>
<autor>Hans Dampf</autor>
<isbn:number>1234567890</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.
3.5.3 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
SOFTWARETECHNIK
Einführung in XML
- 24 -
©
Prof. J. Goll
- 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:
http://www.w3.org/1999/XSL/Transform
bzw.
http://www.w3.org/2001/XMLSchema.
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.
3.5.4 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
SOFTWARETECHNIK
Einführung in XML
- 25 -
©
Prof. J. Goll
- 4. XML Parser -
4 XML Parser und Schnittstellen
Soll sich XML als Standard durchsetzen, so müssen natürlich möglichst viele
Applikationen XML verstehen und XML nutzen, um Dokumente zu speichern. XML
Dokumente zu verstehen bedeutet, die Struktur eines XML Dokumentes zu erkennen
und den Inhalt zu lesen. Das Erkennen einer Struktur erledigt in der Regel ein
sogenannter Parser, wie er beispielsweise auch in Compilern für
Programmiersprachen enthalten ist. Damit nicht jeder Entwickler einen eigenen XML
Parser schreiben muss, hat man sich entschlossen, Standard-Schnittstellen, also
Application Programming Interfaces (APIs), zu XML Parsern zu definieren.
Das W3C hat hier das Document Object Model (DOM) geschaffen, was allerdings
für einfache Applikationen ein zu komplexes Interface darstellen kann. Aus diesem
Grund wurde in der XML-dev-Mailing-Liste [XMLdev] ein alternativer Standard
entwickelt, der zwar vom W3C unabhängig ist, sich aber trotzdem als de-facto
Standard durchgesetzt hat. Um die Einfachheit dieses API hervorzuheben wurde sie
Simple API for XML (SAX) getauft. Von beiden APIs gibt es in der Zwischenzeit
Version 2, auf die sich die folgenden Ausführungen beziehen.
Generell gilt, dass diese APIs Programmiersprachen-unabhängig definiert wurden.
Die Benutzung der APIs in einer bestimmten Programmiersprache wird durch
sogenannte Bindings geregelt. In diesem Skript wird Java als Programmiersprache
gewählt. Das ist nicht zufällig, sondern Java und XML bilden ein Tandem, was die
Programmierung im Internet betrifft: Java sorgt für den portablen Code und XML für
die Portabilität von Daten. Nach der Übersicht über die Parsingmechanismen wird
daher Java API for XML Processing (JAXP) vorgestellt, das heute am häufigsten
benutzte Paket mit XML Schnittstellen für Java, das zuerst nur in der J2EE Plattform
verfügbar war, seit Version 1.4 aber zur Standardprogrammierumgebung von Java,
dem JDK (Java Development Kit), gehört.
4.1 Übersicht
Ein XML Parser ist ein XML Prozessor, der einen XML Stream, beispielsweise eine
XML Datei, lesen kann und eine geeignete Repräsentation dieser Daten für andere
Anwendungen erzeugen kann. Die Anwendung erhält Zugriff auf die XML Daten
über definierte Schnittstellen, sogenannte APIs (Application Programming
Interfaces).
SOFTWARETECHNIK
Einführung in XML
- 26 -
©
Prof. J. Goll
- 4. XML Parser -
XML
Applikation
XML
Parser
API
XML
Dokument
Abbildung 4-1: Lesen von XML Dokumenten
4.1.1 Wohlgeformt vs. Gültig
Generell muss man bei allen Parsern noch unterscheiden, auf Grund welcher Syntax
sie entscheiden, ob ein Dokument korrekt ist oder nicht. Es wurde ja bereits erwähnt,
dass es im Allgemeinen zwei Grammatiken gibt, die für ein XML Dokument gelten
können: die Grammatik für XML selbst und die DTD für eine bestimmte XML-basierte
Sprache. Hier wurden schon die Begriffe wohlgeformt (well-formed) und gültig (valid)
eingeführt.
Daran anlehnend spricht man im Bereich der XML Parser von einem validierenden
Parser, wenn er neben der XML Grammatik auch noch die Gültigkeit eines
Dokumentes bezüglich seiner DTD überprüft. Ein nicht-validierender Parser prüft
nur die Wohlgeformtheit des Dokumentes, also nur die XML Grammatik. XML
Dokumente, die nicht wohlgeformt sind, können in der Regel nicht verarbeitet
werden.
Wenn statt DTDs zukünftig XML Schema Definitionen, die später noch erläutert
werden, zur Spezifikation von XML Dokumenten benutzt werden, dann können
Parser prüfen, ob ein gegebenes XML Dokument mit dem Schema übereinstimmt
(Schema Validation).
Bei den meisten Parsern kann der Level der Prüfungen eingestellt werden.
4.1.2 Nicht-validierende Parser
Die Benutzung eines nicht-validierenden Parsers, bzw. das Ausschalten der
Validierung, kann einige wichtige Konsequenzen nach sich ziehen. Zum Beispiel
braucht ein solcher Parser die sogenannten externen Entities (siehe 3.3.1) nicht zu
lesen, er muss nur der Anwendung mitteilen, dass er welche gesehen hat.
SOFTWARETECHNIK
Einführung in XML
- 27 -
©
Prof. J. Goll
- 4. XML Parser Informationen, die in der externen Entity spezifiziert werden, sind damit nicht für die
Anwendung zugreifbar. Der Grund für dieses Verhalten ist, dass ein XML Browser
Entity Referenzen nutzen kann, um symbolhaft die Existenz einer externen Entity
anzuzeigen, aber nicht die external entity selbst anzeigen muss. Man denke hier
einfach an einen Link als externe Entity.
Validierende und nicht-validierende Parser unterscheiden sich natürlich auch
deutlich in der Performanz. Die heutigen in der Praxis eingesetzten Parser erlauben
daher, die Validierung gemäß einer DTD über einen Schalter an- bzw. abzuschalten.
Damit kann die Anwendung entscheiden, ob das Dokument validiert werden muss,
oder ob dieser Vorgang überflüssig ist, wenn beispielsweise das Dokument von
einer vertrauenswürdigen Quelle stammt. Vertrauenswürdig heißt in diesem Falle,
dass sichergestellt ist, dass die Quelle nur gültige Dokumente erstellt.
4.2 Programmierung in Java
In der Regel stellen alle Parser-Hersteller Java-APIs zur Verfügung. Im Bereich von
DOM und SAX sind diese APIs standardisiert, was in den folgenden Kapiteln
dargestellt wird. Die Benutzung und Konfiguration der Parser war jedoch häufig
unterschiedlich. SUN hat mit dem Java API for XML Processing (JAXP) einen
Standard innerhalb der Java Plattform geschaffen. Seit der Version 1.4 ist JAXP
Bestandteil des JDK.
Unter http://java.sun.com/xml/jaxp ist die Spezifikation und auch ein Tutorial
verfügbar, mit dessen Hilfe die Benutzung der API klar wird.
JAXP stellt einen Plugging-Layer zur Verfügung, der es erlaubt, SAX und DOM
Parser, sowie XSLT Prozessoren zu integrieren. Daneben gibt es die Standard-APIs
zum Zugriff auf den DOM Baum und die SAX Events.
JAXP bietet einen Factory-Mechanismus an, um eine entsprechende Parser-Instanz
zu erzeugen, die dann im weiteren Verlauf einer Applikation genutzt werden kann.
Neben JAXP gehören noch weitere APIs zum JDK, die das Arbeiten mit XML Daten
erleichtern, wie etwa JAXB, dem Java API for XML Binding, das später noch
vorgestellt wird, JAXR, dem Java API for XML Registries, das im Zusammenhang mit
Webservices beispielsweise gebraucht wird, sowie JAXM (Java API for XML
Messaging) und JAX-RPC (Java API for XML-based RPC), die im Zusammenhang
mit der XML-basierten Kommunikation zum Einsatz kommen können.
SOFTWARETECHNIK
Einführung in XML
- 28 -
©
Prof. J. Goll
- 4. XML Parser -
4.3 Das Document Object Model
Beim Document Object Model (DOM) handelt es sich nicht nur um ein ParserInterface sondern um eine komplette Schnittstelle für den Umgang mit XML
Dokumenten.
Bei DOM werden XML Dokumente in einer Baumstruktur (DOM Baum) repräsentiert.
Diese Repräsentation ist aber nicht direkt verfügbar, sondern es gibt ein Application
Programming Interface (API) mit den Schnittstellen um auf die Baumstruktur
zuzugreifen. Das DOM API (Level 2) ermöglicht:
Navigation in XML Dokumenten
Ändern von Knoten
Erzeugen von neuen Knoten
Einfügen von Knoten
Löschen von Knoten
Die Knoten des DOM Baums werden als Objekte, die ein spezifisches Verhalten und
eine Identität haben, dargestellt. DOM spezifiziert
wie XML Dokumente als Objekte modelliert werden,
welche Objekte es gibt,
und welche Methoden für den Zugriff auf diese Objekte zur
Verfügung stehen.
Da die Spezifikation von DOM Plattform- und Programmiersprachen-unabhängig sein
sollte, wählte man die Interface Definition Language (IDL) der Object
Management Group (OMG), die auch vom Thema CORBA her bekannt sein dürfte.
DOM Level 3 wird noch mehr Funktionalität bieten. Allerdings haben noch nicht alle
Teile den Recommendation Status erreicht. DOM Level 3 Core hat seit April 2004
den Status einer W3C Recommendation. Die Recommendation für das Load-andSave Modul wurde im April 2007 verabschiedet. Damit stehen nun auch
standardisierte Methoden bereit, die das Serialisieren (Speichern) von DOM Bäumen
in Form von XML Dokumenten unterstützen und umgekehrt.
4.3.1 Das DOM Programmiermodell
Die folgende Abbildung zeigt das Verhältnis der beteiligten Komponenten beim
Arbeiten mit dem DOM. In dem zugrunde liegenden Programmiermodell liest ein
DOM Parser das ganze XML Dokument ein und stellt es intern als Baumstruktur dar.
Die Applikation erhält Zugriff auf die Wurzel des Dokumentes und kann dann über die
Methoden des API mit dem Dokument arbeiten.
SOFTWARETECHNIK
Einführung in XML
- 29 -
©
Prof. J. Goll
- 4. XML Parser -
Abbildung 4-2: Zusammenspiel Parser/DOM/Applikation
Mit den Methoden kann auch das Dokument verändert werden, bzw. ein ganz neues
XML Dokument kann von einer Applikation im Arbeitsspeicher erzeugt werden. Dies
erfordert, dass am Ende die Baumdarstellung wiederum in eine Textform gewandelt
und in einer Datei, bzw. einem Stream, gespeichert werden muss. Man spricht auch
vom Serialisieren eines Dokumentes. Diese Aufgabe ist eng mit dem Parsen
verwandt, die entsprechende Komponente heißt im Englischen Renderer. Häufig
SOFTWARETECHNIK
Einführung in XML
- 30 -
©
Prof. J. Goll
- 4. XML Parser werden Parser und Renderer nicht unterschieden und man redet, wie auch im Bild zu
sehen, von einem DOM Parser, der beide Aufgaben zu bewältigen hat.
4.3.2 DOM in Java
Die für die Verwendung von DOM notwendigen Interfaces befinden sich in dem Java
Package org.w3c.dom. Um eine Parserinstanz anlegen zu können, müssen
zusätzliche
Klassen
aus
dem
JAXP
Package
importiert
werden
(javax.xml.parsers).
In dem zugrunde liegenden Programmiermodell liest ein DOM Parser das ganze
Dokument ein und gibt dann ein Objekt vom Typ Document zurück, an dem der
komplette DOM Baum hängt.
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder parser = factory.newDocumentBuilder();
Document mydoc = parser.parse(args[0]);
Document ist wie die meisten Interfaces in DOM von Node (=Knoten) abgeleitet. Die
verknüpften Nodes bilden den DOM Baum. Das Node-Interface bietet z.B. folgende
Methoden an:
o java.lang.String getNodeName()
gibt den Element-Namen zurück.
o short getNodeType()
gibt den Typ eines Knotens zurück, z.B.: ATTRIBUTE_NODE,
COMMENT_NODE, ELEMENT_NODE, TEXT_NODE.
o java.lang.String getPrefix()
gibt das Namespace-Präfix zurück, null wenn keines angegeben
wurde.
o boolean hasChildNodes()
prüft auf Vorhandensein von Kind-Knoten.
o NodeList getChildNotes()
gibt eine Liste mit den Kind-Knoten zurück.
o boolean hasAttributes()
prüft auf Vorhandensein von Attribut-Knoten.
o NamedNodeMap getAttributes()
gibt eine Liste (auf deren Elemente über Strings zugegriffen werden
kann) mit den Attribut-Knoten zurück.
SOFTWARETECHNIK
Einführung in XML
- 31 -
©
Prof. J. Goll
- 4. XML Parser -
o java.lang.String getNodeValue()
gibt den Wert eines Knotens zurück, hängt vom Knoten-Typ ab, z.B.
wird bei TEXT_NODE der Text zurückgeliefert.
Zusätzlich zu Node kennt DOM auch (von Node abgeleitete) Interfaces entsprechend
den XML Sprachelementen (z.B. Element, Document, Entity, ProcessingInstruction, etc.). Diese bieten zusätzliche Methoden, die eben nur für den
jeweiligen Knotentyp zulässig sind. Um diese erweiterten Interfaces zu nutzen, muss
man das Node-Objekt in die entsprechende Klasse "casten", nachdem man z.B. mit
getNodeType() geprüft hat, dass es sich um den entsprechenden Typ handelt.
Mit der bis jetzt erläuterten Funktionalität kann man den ganzen DOM Baum
durchlaufen und evaluieren. Zusätzlich gibt es viele Möglichkeiten, einen DOM Baum
zu verändern und zu erweitern. Folgende Methodenliste (wieder Methoden des
Node-Interface) gibt einen Überblick über die Einsatzmöglichkeiten:
o Node appendChild(Node newChild)
fügt einen neuen Kind-Knoten zum betreffenden Knoten hinzu.
o Node insertBefore(Node newChild, Node refChild)
fügt den neuen Knoten an der Position vor dem Referenz-Knoten ein.
o Node removeChild(Node oldChild)
entfernt einen Kind-Knoten.
o void setNodeValue(java.lang.String nodeValue)
ermöglicht es den Wert (=Text) eines Knotens zu ändern.
o void setPrefix(java.lang.String prefix)
setzt den Namespace für den Knoten.
4.3.3 Parsen des Adressbuches mit DOM
Das folgende DOM Beispiel ist direkt auf die in der Adressbuch-DTD spezifizierten
Dokumenten-Struktur zugeschnitten. Der abgedruckte Code bildet lediglich den
DOM-relevanten Teil der Applikation.
Die Klassen Adressbuch, Adresse, Telefon und Email entsprechen den XML
Elementen der DTD. Es gibt keine Klasse Name, da Anrede, Vorname und
Nachname als Member-Variablen von Adresse modelliert wurden. Ein Adressbuch
enthält eine Liste von Adressen. Eine Adresse wiederum enthält eine Liste von
Telefonnummern und Emailadressen. Die Elemente dieser Listen lassen sich jeweils
über die Methoden addAdresse(), addTelefon() und addEmail() zur
entsprechenden Liste hinzufügen. Alle Klassen verfügen jeweils über eine Methode
print(), die die relevanten Informationen zu den Objekten ausgibt und die
print()-Methode der tiefergelegenen Objekte triggert.
SOFTWARETECHNIK
Einführung in XML
- 32 -
©
Prof. J. Goll
- 4. XML Parser Der folgende Code startet in der main()-Methode den Parser und "baut" dann ein
Applikations-spezifisches Objekt-Modell mit den oben angegebenen Klassen nach,
während er (depth-first) mit den DOM-Methoden durch den vom Parser erzeugten
Baum (mydoc) wandert.
import org.w3c.dom.*;
import javax.xml.parsers.*
public class AbDOM{
public static Email analyzeEmail(Node node)
{
Email email = new Email();
email.setAdr(node.getFirstChild().getNodeValue());
return email;
}
public static Telefon analyzeTelefon(Node node)
{
Telefon tel = new Telefon();
tel.setNummer(node.getFirstChild().getNodeValue());
return tel;
}
public static Adresse analyzeAdresse(Node node)
{
Adresse adr = new Adresse();
for (int i=0; i<node.getChildNodes().getLength(); i++)
{
Node child=node.getChildNodes().item(i);
if (child.getNodeType()==Node.ELEMENT_NODE)
{
if (child.getNodeName().equals("Name"))
{
for (int t=0; t<child.getChildNodes().getLength();
t++)
{
Node subchild=child.getChildNodes().item(t);
SOFTWARETECHNIK
Einführung in XML
- 33 -
©
Prof. J. Goll
- 4. XML Parser if (subchild.getNodeName().equals("Anrede"))
adr.setAnrede(subchild.getFirstChild().getNodeValue());
if (subchild.getNodeName().equals("Nachname"))
adr.setName(subchild.getFirstChild().getNodeValue());
if (subchild.getNodeName().equals("Vorname"))
adr.setVorname(subchild.getFirstChild().getNodeValue());
}
}
if (child.getNodeName().equals("Email"))
{
for (int t=0; t<child.getChildNodes().getLength();
t++)
{
if (subchild.getNodeType()==Node.ELEMENT_NODE)
{
adr.addEmail(analyzeEmail(subchild));
}
}
}
if (child.getNodeName().equals("Telefon"))
{
for (int t=0; t<child.getChildNodes().getLength(); t++)
{
if (subchild.getNodeType()==Node.ELEMENT_NODE)
{
adr.addTelefon(analyzeTelefon(subchild));
}
}
}
}
}
return adr;
}
SOFTWARETECHNIK
Einführung in XML
- 34 -
©
Prof. J. Goll
- 4. XML Parser public static Adressbuch analyzeAdressbuch(Node node)
{
Adressbuch adrbuch = new Adressbuch();
for (int i=0; i<node.getChildNodes().getLength(); i++)
{
Node child=node.getChildNodes().item(i);
adrbuch.addAdresse(analyzeAdresse(child));
}
return adrbuch;
}
public static void analyzeDocument(Document doc)
{
Adressbuch myAdr;
for (int i=0; i<doc.getChildNodes().getLength(); i++)
{
Node child=doc.getChildNodes().item(i);
{
myAdr=analyzeAdressbuch(child);
System.out.println("Adressbuch:");
myAdr.print();
}
}
}
public static void main(String args[])
throws Exception
{
/* Parser instanzieren */
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
DocumentBuilder parser = factory.newDocumentBuilder();
/* File parsen - Baum-Aufbau */
Document mydoc = parser.parse(args[0]);
/* Applikations-spezifische Routine aufrufen
analyzeDocument(mydoc);
}
}
SOFTWARETECHNIK
Einführung in XML
- 35 -
©
Prof. J. Goll
- 4. XML Parser -
Die Ausgabe des Programms bietet nicht viel Aufklärung, da die print()-Methoden
hier nicht abgedruckt sind (die Java-Quellen sind im Verzeichnis mit den
Adressbuch-Beispielen komplett enthalten). Trotzdem sei sie der Vollständigkeit
wegen und um das erfolgreiche Parsen bzw. Wandern durch den Baum zu
demonstrieren aufgeführt:
Adressbuch:
Adresse Nr.0
Anrede: Herr, Name: Maier, Vorname: Max
Telefon: 0711654321
Telefon: 017287654321
Adresse Nr.1
Anrede: null, Name: Dough, Vorname: John
Telefon: 0711123456
Email: [email protected]
Email: [email protected]
4.4 Simple API for XML
Die Simple API for XML (SAX) ist wie der Name sagt eine einfache API zur
Verarbeitung von XML Dokumenten. Sie hebt sich von dem Modell DOM in sofern
ab, als dass sie lediglich ein eventbasiertes Framework zum Einlesen und
Verarbeiten von XML Dokumenten darstellt. SAX stellt eine API zur Verfügung, mit
deren Hilfe eine Applikation auf Ereignisse, die der Parser beim Parse-Vorgang
ausgibt, reagieren kann. Solche Ereignisse können beispielsweise sein:
•
•
•
•
•
•
•
Öffnendes Tag wurde gefunden.
Schließendes Tag wurde gefunden.
PCDATA (Parsable Character Data) wurde gefunden.
CDATA (Character Data) wurde gefunden.
Processing Instruction wurde gefunden.
Kommentar wurde gefunden.
Entity Deklaration wurde gefunden.
SAX bietet keine Möglichkeit zum Navigieren in einem XML Dokument oder zu
dessen Modifikation. Daher ist dieses Programmiermodell nur beschränkt einsetzbar.
Die Vorteile von SAX liegen in seiner Einfachheit. Es ist einfach zu programmieren
und verbraucht sehr wenig Speicher und ist daher speziell zum Einlesen und
Validieren von großen Dokumenten geeignet, da es nicht wie DOM einen Baum des
XML Dokuments im Speicher aufbaut.
SOFTWARETECHNIK
Einführung in XML
- 36 -
©
Prof. J. Goll
- 4. XML Parser -
4.4.1 Das Programmiermodell von SAX
Die Simple API for XML (SAX) arbeitet Event-basiert, d.h. während der Parser das
File analysiert, benachrichtigt er die Applikation durch Ereignisse über gefundene
Tags, Text, etc.
Abbildung 4-3: Funktionsweise eines SAX Parsers
4.4.2 SAX in Java
Die für die Verwendung eines SAX Parsers notwendigen Klassen importiert man
über die Standardpackages:
import org.xml.sax.*;
import org.xml.sax.helpers.*;
Die SAX Events werden in Java selbstverständlich über Methodenaufrufe an die
Applikation übermittelt. Um dies zu ermöglichen, muss die Applikation einen eigenen
Handler anbieten, der von org.xml.sax.helpers.DefaultHandler abgeleitet
wird. Diese Klasse bietet z.B. die folgenden Methoden an, die von der Handlerklasse
der Applikation überschrieben werden können, wenn die Applikation auf die
entsprechenden Ereignisse reagieren möchte.
SOFTWARETECHNIK
Einführung in XML
- 37 -
©
Prof. J. Goll
- 4. XML Parser Die wichtigsten Methoden von DefaultHandler sind:
o void startDocument()
wird vom Parser zum Beginn des Lesens aufgerufen.
o void endDocument()
signalisiert, dass das Ende des Dokuments erreicht wurde.
o void startElement(java.lang.String uri,
java.lang.String localName,
java.lang.String qName,
Attributes attributes)
signalisiert das Start-Tag eines Elements. Der Parser übergibt über die
Parameter folgende Informationen an die Anwendung: Namespace
(uri), Tag-Name ohne (localName) und mit Präfix (qName) sowie die
Attributliste.
o void endElement( java.lang.String uri,
java.lang.String qName)
signalisiert das End-Tag eines Elements. Die Parameter haben die
gleiche Bedeutung wie bei startElement().
o void characters(char[] ch, int start, int length)
wird beim Auftreten von Text im Dokument vom Parser aufgerufen. Der
Text wird im Array ch an der Stelle start mit der Länge length
übergeben.
Der eigentliche Parser ist eine Instanz von org.xml.sax.XMLReader. Bei dieser
Klasse handelt es sich natürlich nur um ein Interface, die Klasse des ParserHerstellers befindet sich also in einem anderen Package. Um den Applikations-Code
von Parser-spezifischem Code freizuhalten, wurde die Parser-Factory eingeführt, mit
der es möglich wird, den gewünschten Parser als String anzugeben.
XMLReader Parser = XMLReaderFactory.createXMLReader(
"org.apache.xerces.parsers.SAXParser");
Dem so instanzierten Parser muss nun über setContentHandler() eine
Referenz auf eine Instanz des Applikations-spezifischen Handlers gegeben werden.
Danach kann der Parser über die Methode parse() entweder auf einen Stream
oder eine Ressource (über deren URI) angesetzt werden.
SOFTWARETECHNIK
Einführung in XML
- 38 -
©
Prof. J. Goll
- 4. XML Parser -
4.4.3 Parsen des Adressbuches mit SAX
Es folgt nun ein kleines, aber vollständiges SAX Beispiel. Die Tag-Namen werden
hier nicht berücksichtigt, weshalb es sich hier also nicht um eine Adressbuchspezifische Anwendung handelt.
Als erstes soll die Handlerklasse betrachtet werden. Der Handler gibt für Start- und
End-Tags sowie für dazwischen stehenden Text Informationen auf der Konsole aus.
Zusätzlich werden die Tags entsprechend der Dokumenten-Struktur eingerückt,
hierzu dient die zusätzliche Methode recalcOutBuffer().
/* File: AbSAXHandler.java */
import java.lang.*;
public class AbSAXHandler extends DefaultHandler
{
String space = new String("
int indent = 0;
String outBuffer = new String("");
");
private void recalcOutBuffer()
{ if (indent>0)
{ outBuffer= new String(space.substring(0, indent*3));
}
else outBuffer = new String("");
}
public void startElement(java.lang.String uri,
java.lang.String qName,
Attributes attributes)
{ System.out.println(outBuffer + "[TAG-BEGIN] "+ qName);
indent++;
recalcOutBuffer();
}
public void endElement(java.lang.String uri,
java.lang.String qName)
{ indent--;
recalcOutBuffer();
System.out.println(outBuffer + "[ TAG-END ] "+ qName);
}
SOFTWARETECHNIK
Einführung in XML
- 39 -
©
Prof. J. Goll
- 4. XML Parser public void characters(char[] ch, int start, int length)
{
String data = new String(ch, start, length);
data=data.trim();
if (data.length()>0)
System.out.println(outBuffer + "[ DATA
] "+ data);
}
}
Die eigentliche Applikation entspricht in ihrer Struktur einer typischen SAX
Anwendung:
/* File: AbSAXApp.java */
public class AbSAXApp
{
public static void main(String args[])
throws Exception
{
/* Parser instanzieren */
XMLReader Parser = XMLReaderFactory.createXMLReader(
"org.apache.xerces.parsers.SAXParser");
/* Handler instanzieren */
AbSAXHandler Handler = new AbSAXHandler();
/* Handler dem Parser als ContentHandler bekannt machen. */
Parser.setContentHandler(Handler);
/* Parsen starten. */
Parser.parse("file:" + args[0]);
}
}
Wird diese Applikation nun gestartet mit:
java AbSAXApp ab.xml
und verarbeitet in diesem Fall das File ab.xml aus Kapitel 3, so erhalten wir
folgende Ausgabe:
SOFTWARETECHNIK
Einführung in XML
- 40 -
©
Prof. J. Goll
- 4. XML Parser [TAG-BEGIN] Adressbuch
[TAG-BEGIN] Adresse
[TAG-BEGIN] Name
[TAG-BEGIN] Anrede
[ DATA
] Herr
[ TAG-END ] Anrede
[TAG-BEGIN] Vorname
[ DATA
] Max
[ TAG-END ] Vorname
[TAG-BEGIN] Nachname
[ DATA
] Maier
[ TAG-END ] Nachname
[ TAG-END ] Name
[TAG-BEGIN] Telefon
[TAG-BEGIN] Nummer
[ DATA
] 0711654321
[ TAG-END ] Nummer
[TAG-BEGIN] Nummer
[ DATA
] 017287654321
[ TAG-END ] Nummer
[ TAG-END ] Telefon
[ TAG-END ] Adresse
[TAG-BEGIN] Adresse
[TAG-BEGIN] Name
[TAG-BEGIN] Vorname
[ DATA
] John
[ TAG-END ] Vorname
[TAG-BEGIN] Nachname
[ DATA
] Dough
[ TAG-END ] Nachname
[ TAG-END ] Name
[TAG-BEGIN] Telefon
[TAG-BEGIN] Nummer
[ DATA
] 0711123456
[ TAG-END ] Nummer
[ TAG-END ] Telefon
[TAG-BEGIN] Email
[TAG-BEGIN] Emailadresse
[ DATA
] [email protected]
[ TAG-END ] Emailadresse
[TAG-BEGIN] Emailadresse
[ DATA
] [email protected]
[ TAG-END ] Emailadresse
[ TAG-END ] Email
[ TAG-END ] Adresse
[ TAG-END ] Adressbuch
SOFTWARETECHNIK
Einführung in XML
- 41 -
©
Prof. J. Goll
- 4. XML Parser -
4.5 Vergleich von DOM und SAX
Interessiert man sich für die Struktur von Dokumenten oder möchte man diese gar
verändern, so erweist sich SAX als extrem umständlich. Für Applikationen, die
jedoch relativ einfach strukturierte XML Dokumente verarbeiten sollen, bringt SAX
auch Vorteile:
•
Da der Parse-Baum nicht aufgebaut wird, wird auch kaum Speicher
verbraucht.
•
SAX kann daher auch sehr große Dokumente parsen.
•
Durch das Event-Modell und das Speicher-Handling ist das Parsen von
XML Streams möglich.
•
Wie der Name sagt, ist die Schnittstelle bei SAX sehr einfach und darum
leicht anzuwenden.
DOM ist offensichtlich deutlich mächtiger als SAX: diese Schnittstelle unterstützt
Navigieren, Verarbeiten und Aufbau von XML Bäumen. Der Umgang mit DOM
erfordert darum auch mehr Aufwand als ein einfacher SAX Handler. Es hängt also
von der Problemstellung ab, welcher Parser zum Einsatz kommen sollte.
Anmerkung: Die DOM Parser selbst verwenden meistens einen SAX Parser zur
Erstellung des DOM Baums.
4.6 Weiterführende Entwicklungen
4.6.1 SAX + DOM = SAXDOMIX
SAXDOMIX ist ein neu ins Leben gerufenes Open-Source Framework, das die
beiden API’s von SAX und DOM kombiniert anwendet. Es vereint sozusagen die
Vorteile der objektorientierten Verarbeitung von DOM und der schnellen,
ereignisgesteuerten Verarbeitung von SAX. Das SAXDOMIX Framework enthält
spezielle Klassen und Packages, die beide API’s sinnvoll kombinieren. Das Ziel
dieses Projektes ist es, die Verarbeitung von XML-Dokumenten weiter zu
vereinfachen und flexibler zu gestalten.
Das Prinzip von SAXDOMIX ist am besten an Hand eines kleinen Beispiels zu
erklären. Es soll eine große Menge an Datensätzen in einem XML Dokument sortiert
verarbeitet und gezählt werden. Für das Zählen wäre in unserem Beispiel SAX
prädestiniert, für das Sortieren hingegen DOM.
SOFTWARETECHNIK
Einführung in XML
- 42 -
©
Prof. J. Goll
- 4. XML Parser SAXDOMIX geht nun folgendermaßen vor: Mit Hilfe von SAX wird ein minimaler
DOM Baum aufgebaut, der genau soviele Informationen enthält, wie für das Sortieren
notwendig ist. Dies stellt nur einen kleinen Teil des tatsächlichen Dokumentes dar,
lässt sich daher schnell verarbeiten und benötigt nur wenig Speicher. Ein weiterer
Vorteil dabei ist, dass SAXDOMIX während des Parsens auf weitere Informationen
zugreifen kann, wie zum Beispiel das Elternelement, was SAX alleine nicht könnte.
Der Vorteil besteht nun darin, dass anhand des Elternelements die
Elementinformationen
geholt
werden
können
und
mit
Hilfe
dieser
Zusatzinformationen entschieden werden kann, ob weitere Teile des Dokumentes
geholt werden müssen. Diese können dann temporär für eine spätere Verwendung
im Speicher abgelegt werden. Wenn die zusätzlichen gespeicherten Informationen im
weiteren Verlauf nicht mehr benötigt wird, kann das Objekt wieder aus dem Speicher
gelöscht und somit Ressourcen freigegeben werden. Eine Verarbeitung auf diese
Weise ist in diesem Anwendungsfall bedeutend schneller, wie die Verwendung von
nur einer Parse-Methode.
Durch die neue Verarbeitungsmethode von SAXDOMIX besteht die Möglichkeit
komplexe XML Dokumente effizient und schnell verarbeiten zu können. Durch das
Zusammenlegen der API’s kann genauer implementiert werden, was Ressourcen
und Verarbeitungszeit schont.
Weiter Informationen und die Implementation zu SAXDOMIX sind unter der WebAdresse: http://www.devsphere.com/xml/saxdomix/ zu finden.
Ein Performancevergleich zwischen SAX, DOM und SAXDOMIX ist unter der WebAdresse: http://www.devsphere.com/xml/benchmark/ zu finden.
4.6.2 Die JDOM Bibliothek
Die Autoren des JDOM Projektes waren der Ansicht, dass es noch keine Java nahe,
bzw. auf Java optimierte API zur XML Bearbeitung gibt, die zugleich einfach und
doch leistungsfähig ist. JDOM ist keine Erweiterung oder eine weitere
Abstraktionsebene für SAX und DOM, auch wenn es diese selbstverständlich
unterstützt. Das JDOM Projekt will eine einfache, aber doch leistungsfähige
Bibliothek zur Verfügung stellen, um XML zu verarbeiten und zu erzeugen.
Dieses Ziel scheint recht gut erreicht zu sein, wie man der steigenden Verbreitung,
der wachsenden Artikelanzahl zu dem Produkt und den Kommentaren auf der
Homepage des Projektes entnehmen kann.
Die Webadresse dieser Homepage ist: http://www.jdom.org/
SOFTWARETECHNIK
Einführung in XML
- 43 -
©
Prof. J. Goll
- 4. XML Parser -
4.6.3 Deferred Parsing
Deferred Parsing bezeichnet das verzögerte (aufgeschobene) Parsen des XML
Dokuments. Dabei wird vom XML Dokument ein Baum aufgebaut, jedoch wird nur
der jeweils benötigte Teil geparst. Es ist praktisch identisch mit der Vorgehensweise
bei SAXDOMIX. Das Ziel dieser Ansätze ist eine universellere Baumschnittstelle zu
schaffen, die ein einfaches Bearbeiten auch größerer XML Dokumente ermöglicht.
Beim Xerces Parser wird es bei der nächsten Version möglich sein DOM in einem
"deferred" Modus zu betreiben. Dabei wird der Baum nicht vollständig aufgebaut,
sondern die entsprechenden Teile erst bei Bedarf geparst. Jedoch ist dies noch in
der Entwicklung und wenig dokumentiert.
Weitere Informationen zu Xerces sind zu finden unter der Webadresse von Apache:
http://xml.apache.org/xerces2-j/.
4.6.4 Pull Parsing
Vom Ziel her ist das sogenannte Pull Parsing vergleichbar mit dem Deferred Parsing:
es soll nur das geparst werden, was wirklich notwendig ist. Der Begriff Pull Parsing
rührt daher, dass der Parser "gezogen" (pull) werden muss, um etwas zu tun. Bei
SAX startet man den Parser, der dann mit einem Event sagt, was er geparst hat.
Man könnte auch sagen, man "push"t den Parser, der die komplette Kontrolle erhält
und sich bei der Applikation über ein Event meldet. Im Gegensatz dazu sagt man
dem Pull Parser, was man als nächstes gern haben möchte. Der Zwischenbereich
kann dann vom Parser übersprungen werden. Während man mit einem SAX Parser
zwar den Rest eines Dokumentes ungeparst lassen kann, wenn man sein Ergebnis
gefunden hat, kann man mit einem Pull Parser auch Teilbäume zwischendrin
überspringen, wenn man weiß, dass darin das gesuchte Ergebnis garantiert nicht zu
finden ist.
Beim Pull Parser XPP gibt es die Möglichkeit einen Baum des XML Dokumentes
aufzubauen. Dabei wird ein spezielle Schnittstelle des XPP verwendet, die nicht zu
DOM kompatibel ist. Anstatt der Verwendung von newNode() bei der
XmlPullParserFactory wird newPullNode() verwendet. Dadurch wird der
Aufbau des Baumes verzögert und erfolgt erst bei Bedarf.
Weitere Informationen zu XPP und dem Pull-Parsing sind zu finden unter der
Webadresse: http://www.extreme.indiana.edu/xgws/xsoap/xpp/.
SOFTWARETECHNIK
Einführung in XML
- 44 -
©
Prof. J. Goll
- 4. XML Parser -
4.7 Zusammenfassung
Im Rahmen einer Studienarbeit [BäLa02] wurde ein Performancevergleich
verschiedener Parsemethoden für XML durchgeführt. Um dieses Ziel zu erreichen
wurden verschiedene, typische Aufgabenstellungen (Applikationsszenarien) definiert
und mit Hilfe der Parsemethoden DOM und SAX sowie der neuen Methode des Pull
Parsens mit XPP iimplementiert. Anhand dessen wurde der Performancevergleich
durchgeführt um die verschiedenen Parser zu vergleichen und die neue Pull Methode
einzuordnen.
Nach der Auswertung der Testresultate wurde deutlich, dass der Pull Parser seine
Vorteile klar bei der Verarbeitung kleiner Dokumente hat. Wegen seiner geringen
Bibliotheksgröße ist er daher besonders gut für Handys und Kleingeräte (Palm)
geeignet. Werden dagegen sehr große Dokumente verarbeitet, ist SAX derzeit die
beste Lösung. Muss mit einem XML Dokument gearbeitet (Einfügen, Löschen,
Ändern) werden, ist DOM die am besten geeignete Methode. Die wohl effizienteste
Verarbeitung wäre ein Mittelweg aus den dargestellten Methoden.
In der Studienarbeit wurde auch festgestellt, dass die freie Wahl einer
Parserimplementation nicht immer gegeben ist. Denn es gibt starke Unterschiede
darin, was einzelne Parser vom XML Standard unterstützen. Daher kann nicht immer
auf den performantesten Parser zurückgegriffen werden, wenn beispielsweise bei
komplexen Dokumenten die Konformität zum Standard wichtiger ist.
Derzeit sind viele Ansätze für einen Mittelweg zwischen DOM und SAX in der
Entwicklung. Denn die Industrie hat klar erkannt, dass dieser Schritt notwendig ist um
XML weitere Einsatzgebiete zu eröffnen. Beispielprojekte hierfür sind das erwähnte
SAXDOMIX, aber auch Xerces deferred und XPP XMLPullNode. Es wird interessant
sein zu beobachten, welcher der Ansätze sich in Zukunft durchsetzen wird.
Ein weiterer Ansatz, der in eine ganz andere Richtung geht, sind die sogenannten
XML Bindings, die in einem späteren Kapitel ausführlicher vorgestellt werden.
SOFTWARETECHNIK
Einführung in XML
- 45 -
©
Prof. J. Goll
- 5. Stylesheets -
5 Stylesheets
Wer mit XML Dokumenten arbeitet, steht häufig vor dem Problem, die in dem
Dokument enthaltenen Daten zu visualisieren, oder sie in ein anderes Format zu
transformieren. Speziell für diesen Prozess der Transformation bzw. Formatierung
wurde das Stylesheet Konzept entwickelt.
Dieses Konzept sieht vor, spezielle Formatierungs- bzw. Transformationsregeln für
Elemente eines XML Dokuments in einem Stylesheet vorzuhalten. Ein Stylesheet
Prozessor kann dann mit Hilfe dieses Stylesheets das XML Dokument in eine andere
Form umwandeln (z.B. HTML).
Abbildung 5-1: Das Stylesheet Konzept
Mit XSL der eXtensible Stylesheet Language hat das W3C einen einheitlichen
Standard für XML Stylesheets vorgelegt.
SOFTWARETECHNIK
Einführung in XML
- 46 -
©
Prof. J. Goll
- 5. Stylesheets -
5.1 Die Vorfahren von XSL
Wie XML selbst, so hat auch XSL seine Vorgänger: die Cascading Stylesheets
(CSS) und die Document Style Semantics and Specification Language (DSSSL).
5.1.1 Cascading Stylesheets
Die Cascading Stylesheets (CSS) waren eine Reaktion des W3C auf die
zunehmende Aufweichung des HTML Standards. Ursprünglich wurden sie für HTML
entwickelt, und sollten Webdesignern ermöglichen, wieder semantisch korrekte
HTML Dokumente zu schreiben und sie über CSS trotzdem "hübsch" darzustellen.
Die Möglichkeiten von CSS1/2 sind jedoch sehr eingeschränkt:
•
Es handelt sich um eine reine Layout-Sprache.
•
Ein Element wird auf genau ein Layout-Objekt abgebildet.
•
Löschen, Umgruppieren, Sortieren von Elementen ist nicht möglich.
•
Es basiert auf einem simplen kasten-orientierten Formatierungs-Modell.
Es ist zu erwarten, dass mit dem Ende von HTML auch die Cascading Stylesheets
an Bedeutung verlieren, obwohl sie auch für XML anwendbar sind. Der Umstieg auf
XSL dürfte sich allerdings einfach gestalten: CSS sind leicht in XSL Stylesheets
übersetzbar (auch automatisch).
5.1.2 Document Style Semantics and Specification Language
Die Document Style Semantics and Specification Language (DSSSL) wurde als
Layout-Sprache für SGML Dokumente entwickelt. Wie SGML selbst, so wurde auch
DSSSL zu einem ISO-Standard. Da DSSSL für SGML entwickelt wurde, ist es
natürlich (aufgrund der Untermengen-Beziehung) auch XML-fähig.
DSSSL ist sehr mächtig, basiert allerdings auf Scheme1 und ist darum wie Scheme
selbst sehr kompliziert.
5.1.3 Anwendbarkeit von Stylesheets
Die folgende Abbildung zeigt beispielhaft, welche Art von Stylesheets auf welche Art
von Dokumenten anwendbar ist.
1
Scheme ist ein Nachfahre von LISP, einer funktionalen Programmiersprache, die
Anfang der 60er Jahre am MIT entwickelt wurde.
SOFTWARETECHNIK
Einführung in XML
- 47 -
©
Prof. J. Goll
- 5. Stylesheets -
Abbildung 5-2. Die Anwendbarkeit von Stylesheets auf Dokumente
D.h. auf XML als Untermenge von SGML sind alle oben genannten Arten von
Stylesheets anwendbar. Wie bereits erwähnt haben Cascading Stylesheets in der
Praxis immer noch eine Bedeutung, da sie im HTML Umfeld eingesetzt werden und
daher einem breiten Personenkreis bekannt sind. Im Folgenden wird aber nur noch
auf die XML Stylesheet Language eingegangen.
5.2 Die eXtensible Stylesheet Language
Die eXtensible Stylesheet Language (XSL) wurde speziell für XML entwickelt,
sogar die Stylesheets selbst sind XML Dokumente. Die Transformation wird über
Template-Regeln, die im Stylesheet formuliert werden, bewerkstelligt. Mögliche
Ausgabeformate einer XSL Transformation sind z.B. XML selbst, also eine andere
XML-basierte Sprache, HTML aber auch RTF oder TeX – im Prinzip kann es auch
beliebiger Text sein.
Der Gewinn durch die Trennung von Inhalt und Layout-Information ist die
Möglichkeit, über verschiedene Stylesheets dasselbe XML Dokument auf
unterschiedliche Ausgabevarianten abzubilden, wie im folgenden Bild zu sehen.
SOFTWARETECHNIK
Einführung in XML
- 48 -
©
Prof. J. Goll
- 5. Stylesheets -
Abbildung 5-3. Mehrere Abbildungen eines Dokumentes
Es ist also nicht nötig die Information redundant in mehreren Dokumenten
vorzuhalten, nur das XML Dokument muss gewartet werden.
XSL hat gegenüber CSS den Vorteil, dass es transformieren kann, d.h. Elemente
mehrmals an verschiedenen Positionen verwenden kann, Reihenfolgen vertauschen
kann, oder auch Verzeichnisse erstellen kann.
XSL ist eine Sprache zum Erstellen von Stylesheets. XSL besteht aus drei
Komponenten:
SOFTWARETECHNIK
Einführung in XML
- 49 -
©
Prof. J. Goll
- 5. Stylesheets •
XSL Transformations (XSLT), einer Sprache mit der Transformationen von XML
Dokumenten beschrieben werden,
•
XML Path Language (XPath), einer Sprache zur Formulierung von Ausdrücken,
die es gestatten auf Elemente in XML Dokumenten Bezug zu nehmen, bzw. diese
Elemente zu adressieren,
•
XSL Formatting Objects (XSL-FO), ein Vokabular zur Spezifikation von Layout.
XSLT und XPath wurden in eigenen Spezifikationen definiert, da ihre
Anwendungsmöglichkeiten über XSL, also die Definition von Stylesheets
hinausgehen. Die Formatting Objects werden in der XSL Spezifikation mit definiert.
Ein XSL Stylesheet ist ein XML Dokument, das spezifiziert, wie eine Klasse von XML
Dokumenten dargestellt werden soll, indem beschrieben wird, wie ein XML
Dokument dieser Klasse transformiert wird in ein anderes XML Dokument, das nun
aber das Formatierungs-Vokabular benutzt. XSL ist vergleichbar mit CSS2, die
Syntax aber ist unterschiedlich.
Das XSL-FO Vokabular wurde entworfen im Hinblick darauf, dass XML Dokumente
auf einer Vielzahl von Medien (Bildschirm, Papier, Sprache ...) dargestellt werden
können. Um die vielfältigen Möglichkeiten von XSL-FO zu nutzen, muss ein
Formatter (z.B. ein Browser für XML Dokumente oder ein Übersetzer nach PDF)
dieses Vokabular natürlich kennen.
Im Folgenden wird zuerst XPath vorgestellt und dann XSLT, das auf XPath basiert.
Anschließend wird auf XSL-FO eingegangen.
SOFTWARETECHNIK
Einführung in XML
- 50 -
©
Prof. J. Goll
- 5. Stylesheets -
5.3 XPath
Beim Design der Working-Drafts von XPointer und XSL stellte man fest, dass man
für beide Spezifikationen eine Möglichkeit zur Adressierung von Lokationen in XML
Dokumenten brauchen würde. Um hier zu einem einheitlichen Standard zu kommen,
wurde XPath, die XML Path Language, am 16. November 1999 in einer gesonderten
W3C-Recommendation manifestiert. XPath wird nun in XSLT, XPointer und XQL
(einer Anfragesprache für XML Dokumente) eingesetzt.
Mit XPath kann man Lokationen in XML Dokumenten beschreiben und den XML
Baum mit Pfadausdrücken traversieren. Diese Pfadausdrücke können zwar sehr
umfangreichen werden, im Normalfall aber ist es möglich das Gewünschte sehr kurz
zu formulieren. XPath bezieht sich auf XML Dokumente in ihrer Baumstruktur. Dabei
existieren wie im DOM Modell folgende Knotentypen:
•
Wurzelknoten
•
Elementknoten
•
Textknoten
•
Attributknoten
•
Namespace-Knoten
•
Processing-Instruction-Knoten
•
Kommentarknoten
Außerdem kennt XPath einen Kontext: der aktuelle Knoten stellt den Kontext für
relative Pfadausdrücke dar.
5.3.1 Pfadausdrücke
Man unterscheidet zwei Arten von Pfadausdrücken: absolute und relative. Ein
Vergleich mit Dateinamen in Filesystemen, beispielsweise dem von UNIX, kann
dabei sehr hilfreich sein.
Absolute Pfadausdrücke können
•
mit / beginnen, d.h. an der Wurzel des Baumes beginnen,
•
oder über id("123") einen Knoten mit einer bestimmten ID im Dokument
auswählen.
SOFTWARETECHNIK
Einführung in XML
- 51 -
©
Prof. J. Goll
- 5. Stylesheets -
Relative Pfadausdrücke können z.B.
•
Elemente über elementname
•
Attribute über @attributname
•
den aktuellen Knoten über .
•
den Elternknoten über ..
•
sonstige Knoten über (ToDo: prüfen)
text()
comment()
node()
processing-instruction()
in Relation zum aktuellen Knoten, also dem Kontext, referenzieren.
Pfadausdrücke können (ähnlich wie Pfade in Filesystemen) auch zusammengesetzt
werden:
/Adressbuch/Adresse/Name/@Nachname
../title
Erweiterte Pfadausdrücke ermöglichen es Zwischenebenen zu vernachlässigen, d.h.
beliebig viele Ebenen zu überspringen:
//Vorname
book//author
Adressbuch//Nummer
Mit Hilfe dieser Pfadausdrücke ist es möglich eine Menge von Knoten (keinen, einen
oder mehrere) in einem XML Dokument zu bestimmen.
Pfadausdrücke können über | (oder) verbunden werden, was bedeutet, dass die
jeweiligen Knotenmengen der Einzelausdrücke vereinigt werden.
book | journal
Das sind also Elementknoten mit den Namen book oder journal.
SOFTWARETECHNIK
Einführung in XML
- 52 -
©
Prof. J. Goll
- 5. Stylesheets -
5.3.2 Filter
XPath unterstützt auch verschiedene Filter, um die Menge der selektierten Knoten
zu reduzieren. Filter können
•
auf das Vorhandensein eines Attributes prüfen:
article[@version]
article[@*]
•
auf das Vorhandensein eines Elementes prüfen:
book[editor]
book[*]
•
Vergleiche evaluieren:
article[@language='en']
article[author='Hans Dampf']
book[@year>=2000]
•
mehrere Filter kombinieren:
article[author='Hans Dampf'][@year='2000']
•
Funktionsaufrufe evaluieren: (ToDo: prüfen)
//Adresse/Email/Emailadresse[position()!=last()]
//book//para[contains(text(), 'alles') and
not(contains(text(), 'gut'))]
Zu beachten ist die Schreibweise mit dem einfachen Apostroph ('). Er muss
deswegen benutzt werden, da die XPath Ausdrücke häufig als Attributwerte stehen,
die ja dann mit dem Doppelapostroph (") gekennzeichnet sind.
5.3.3 Achsen
Bei der Auswertung von XPath Ausdrücken spielen die Achsen eine wichtige Rolle.
Sie wurden in den bisherigen Beispielen auch schon – allerdings in einer einfachen
Schreibweise – benutzt. Damit waren die oben gezeigten Formulierungen sehr
eingängig und vergleichbar mit UNIX Dateinamen. Die Schreibweise von XPath
Ausdrücken wird allerdings ein wenig komplexer, wenn man verschiedene Achsen
explizit selbst auswählen will.
Es folgt nun die Auflistung aller Achsen, die XPath kennt.
•
self (der Kontextknoten selbst)
•
child (alle direkten Kinder – direkte Nachkommen – des Kontextknotens)
•
parent (der Vaterknoten des Kontextknotens)
•
ancestor (die Vorfahren des Kontextknotens, rekursiv)
SOFTWARETECHNIK
Einführung in XML
- 53 -
©
Prof. J. Goll
- 5. Stylesheets •
ancestor-or-self (wie ancestor, sowie der Kontextknoten selbst)
•
descendant (alle Nachkommen des Kontextknotens, rekursiv)
•
descendant-or-self (wie descendant, sowie der Kontextknoten
selbst)
•
following (die auf das Ende-Tag des Kontextknotens folgenden Knoten)
•
following-sibling
Geschwisterknoten)
•
preceding (die vor dem Beginn-Tag des Kontextknotens stehenden
Knoten)
•
preceding-sibling
Geschwisterknoten)
•
attribute (die Attributknoten des Kontextknotens)
•
namespace (alle Namensräume, die am Kontextknoten verfügbar sind)
(die
(die
dem
vor
dem
Kontextknoten
Kontextknoten
folgenden
stehenden
Eine dieser Achsen kann als Präfix vor dem Knotennamen im Pfadausdruck
angegeben werden: achse::elementname. Auch bei den vorher angegebenen
Beispielen spielen die Achsen eine Rolle, sie wurden lediglich in ihrer vereinfachten
Form angegeben.
•
Die child-Achse ist die default-Achse, d.h. der Ausdruck
Adresse/Name
ist nur eine abgekürzte Schreibweise für
child::Adresse/child::Name
•
Die attribute-Achse wird durch @ abgekürzt, d.h. der Ausdruck
book[@year='2000']
entspricht
child::book[attribute::year='2000']
•
Die self-Achse wird durch . abgekürzt.
•
Die parent-Achse wird durch .. abgekürzt
•
Die descendant-or-self-Achse wird durch // abgekürzt.
Will man eine Achse auswählen, die keine Abkürzung hat wie etwa die followingAchse, muss man die Präfixschreibweise verwenden: following::.
Die descendant-or-self-Achse – also // – ist mit Vorsicht zu benutzen: sie verursacht
eine Durchsuchung des kompletten Unterbaums des aktuellen Kontextknotens.
SOFTWARETECHNIK
Einführung in XML
- 54 -
©
Prof. J. Goll
- 5. Stylesheets Das Zeichen * fungiert als "Wildcard": damit werden alle Knoten der entsprechenden
Achse ausgewählt. Das war auch schon in den obigen Beispielen zu sehen: @* etwa
selektiert alle Attributknoten.
5.3.4 Funktionen
XPath unterstützt auch Funktionen. Einige davon sind vordefiniert, es können aber
auch eigene Funktionen definiert werden. Einige werden auch vom Kontext (z.B.
XSLT oder XPointer) bereitgestellt. Bei der Nutzung selbstdefinierter Funktionen ist
Vorsicht geboten, da dieses Feature nicht von allen XSLT Prozessoren unterstützt
wird. Die von XPath definierten Funktionen liefern Knoten und Knotenmengen, die
über normale Eltern-Kind- oder Element-Attribut-Beziehungen nicht zu berechnen
sind. Außerdem ermöglichen sie den Umgang mit Strings und Zahlen, was sowohl
zum Suchen in einem Dokument, als auch zur Ausgabe genutzt werden kann. Zu
den vordefinierten Funktionen zählen beispielsweise:
•
number last(), number position()
number number(object), number count(nodeSet)
•
string string(object),
boolean contains(string, string),
string name()
•
boolean boolean(object), boolean not(boolean),
boolean true()
Die letzte Gruppe erlaubt das Arbeiten mit boolschen Werten, sodass damit auch
Entscheidungen möglich werden.
Die Funktion count liefert als Ergebnis die Anzahl der Knoten in der als Parameter
übergebenen Knotenmenge, im folgenden Beispiel die Anzahl der Kind-Elemente
des Kontextknotens, die ein Attribut name haben.
count (child::*[@name])
Die Bedeutung der übrigen Funktionen und deren Parameter müssen bei Bedarf
nachgeschlagen werden.
SOFTWARETECHNIK
Einführung in XML
- 55 -
©
Prof. J. Goll
- 5. Stylesheets -
5.4 XSL Transformations
Auch die XSL Transformations (XSLT) wurden in einer W3C-Recommendation
manifestiert. Bei XSLT wird das Eingabe- und das Ausgabe-Dokument als Baum
angesehen, d.h. der Source-Tree wird in einen Result-Tree überführt.
Die typische Anwendung von XSLT ist die Transformation eines XML Dokumentes in
ein anderes XML Dokument, mit einem anderen Vokabular. Die heutigen Browser
haben beispielsweise alle ein Stylesheet, mit dem sie ein XML Dokument in ein
HTML Dokument transformieren, das sie dann wiederum darstellen können.
5.4.1 Definition der Transformationen
Die eigentliche Abbildung wird über sogenannte Template-Regeln realisiert. Die
möglichen Tags und Attribute wurden einem Namensraum des W3C zugeordnet.
Dieser muss am Anfang eines Stylesheet erwähnt werden. Das Präfix kann
normalerweise frei gewählt werden, aber xsl ist üblich.
Diese Templates bestehen aus einem Pattern und einem Aktionsteil. Sie werden in
einem XSL Stylesheet so formuliert:
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="...">
...
</xsl:template>
<xsl:template match="...">
...
</xsl:template>
</xsl:stylesheet>
Hier wird deutlich, dass es sich bei einem XSL Stylesheet auch um ein XML
Dokument handelt. Der Pattern-Teil einer Template-Regel wird bei der Anwendung
des Stylesheets mit dem Source-Tree verglichen. Diese Patterns werden in einer
erweiterten Form von XPath angegeben.
Will man nun eine Regel für ein Element Fahrgast angeben, so sieht die
zugehörige Regel so aus:
<xsl:template match="Fahrgast">
...
</xsl:template>
Im Aktionsteil einer Regel (hier durch ... dargestellt) wird die Ausgabe beschrieben,
die erzeugt werden soll, wenn das Muster zutrifft. Im Wesentlichen wird der Inhalt
SOFTWARETECHNIK
Einführung in XML
- 56 -
©
Prof. J. Goll
- 5. Stylesheets des template-Elementes in die Ausgabe (Result-Tree) kopiert, wobei durch weitere
XSL Elemente die Ausgabe dynamisch gestaltet werden kann.
Soll zum Beispiel der Text des Elementes em im HTML Dokument kursiv dargestellt
werden, so lässt sich das mit folgender Regel bewerkstelligen:
<xsl:template match="em">
<I> <xsl:value-of select="." /> </I>
</xsl:template>
Das Element xsl:value-of dient dazu, Information zu einem Knoten aus dem
Source-Tree zu holen und in den Result-Tree einzufügen. Es wird daher häufig
gebraucht. Im obigen Beispiel wird also der Text (PCDATA) des aktuellen Knotens
(select=".") genommen und an Stelle des Elementes xsl:value-of in den
Result-Tree eingebaut, d.h. der Text wird in Italic-Schrift (<I>) ausgegeben.
Will man auch die Templates für tiefer gelegene Elemente zur Ausführung bringen,
so kann man diese Aktion mit <xsl:apply-templates/> auslösen. Im folgenden
Beispiel sollen die Telefonnummern einer Adresse in einem Absatz einfach
aufgezählt werden (Telefon: Nummer1, Nummer2, Nummer3...):
<xsl:template match="Telefon">
<P> Telefon: <xsl:apply-templates/> </P>
</xsl:template>
<xsl:template match="Nummer">
<I> <xsl:value-of select="."/>, </I>
</xsl:template>
Die Ausgabe der Templates der tiefer gelegenen Elemente, wird an der Aufrufstelle
eingesetzt, so dass der gewünschte Effekt entsteht.
Wenn mehrere Templates auf ein und denselben Knoten zutreffen, wird ein Template
nach bestimmten Prioritätsregeln ausgewählt und ausgeführt. Generell gilt, dass die
am spezifischste Regel die höchste Priorität hat gegenüber den allgemeineren. Es ist
auch möglich die Priorität einer Regel festzulegen. Die Details dieser Prioritätsregeln
müssen bei Bedarf nachgeschlagen werden.
5.4.2 Default Transformationen
XSLT hat einige Default-Regeln, die das Arbeiten erleichtern:
•
Jeder Knoten des Baumes wird besucht.
•
Auch die Kinder jedes Knotens werden abgearbeitet:
<xsl:template match="*|/">
<xsl:apply-templates/>
SOFTWARETECHNIK
Einführung in XML
- 57 -
©
Prof. J. Goll
- 5. Stylesheets </xsl:template>
•
Text wird in den Result-Tree kopiert:
<xsl:template match="text()">
<xsl:value-of select="."/>
</xsl:template>
Diese Default-Regeln können allerdings vom Stylesheet überschrieben werden. D.h.
sie werden nur für die Knoten angewandt, für die keine spezielle Regel definiert
wurde. Die Default-Regeln haben sozusagen die niedrigste Priorität.
Der Effekt dieser Default-Regeln ist der, dass aus dem Source-Dokument der reine
Inhalt (also ohne Tags und Attribute) herausgezogen wird und in das ResultDokument kopiert wird.
5.4.3 Beispiel: Transformation des Adressbuch-Dokumentes
Nun folgt als komplettes Beispiel ein Stylesheet (ab.xsl) für AdressbuchDokumente entsprechend der Adressbuch-DTD in Kapitel 3. Das Ziel der
Transformation ist HTML und die Darstellung der einzelnen Adressen soll in einer
Tabelle erfolgen.
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="Adressbuch">
<HTML>
<TITLE>Adressbuch</TITLE>
<BODY>
<TABLE border="5" width="100%" align="center">
<THEAD>
<TH>Name</TH>
<TH>Telefon</TH>
<TH>eMail</TH>
</THEAD>
</TABLE>
</BODY>
</HTML>
</xsl:template>
<xsl:template match="Adresse">
<TR>
</TR>
SOFTWARETECHNIK
Einführung in XML
- 58 -
©
Prof. J. Goll
- 5. Stylesheets </xsl:template>
<xsl:template match="Anrede">
</xsl:template>
<xsl:template match="Name|Telefon|Email">
<TD>
<CENTER>
</CENTER>
</TD>
</xsl:template>
<xsl:template match="Nummer">
<I> (<xsl:value-of select="@Anschluss"/>) </I> <BR/>
</xsl:template>
<xsl:template match="Emailadresse">
<A>
<xsl:attribute name="HREF">mailto:<xsl:apply-templates/>
</xsl:attribute>
</A>
<BR/>
</xsl:template>
</xsl:stylesheet>
Wendet man dieses XSLT Stylesheet nun auf das Beispiel Adressbuch-Dokument
aus Kapitel 3 an, so wird das resultierende HTML File im Browser wie folgt
angezeigt.
Abbildung 5-4: Anzeige des transformierten XML Dokumentes
SOFTWARETECHNIK
Einführung in XML
- 59 -
©
Prof. J. Goll
- 5. Stylesheets -
5.4.4 Zuordnung von Stylesheets zu Dokumenten
In den allermeisten Fällen wird ein XML Dokument und ein XSLT Stylesheet
zusammen einem XSLT Prozessor übergeben. Der Aufrufer ist für die richtige
Zuordnung verantwortlich. Wie im Bild 5-3 zu sehen war, kann es auch durchaus
sinnvoll sein, bei unterschiedlichen Aufrufen mit unterschiedlichen Stylesheets zu
arbeiten.
Die gewollte Zuordnung kann aber auch im XML Dokument spezifiziert werden. Dies
ist immer dann wichtig, wenn beispielsweise ein Browser auf ein XML Dokument trifft
und es darstellen möchte. Der Browser wird ja in diesem Falle nicht mit
irgendwelchen Parametern aufgerufen, er muss die richtige Information im Dokument
selbst finden.
Diese Zuordnung von Stylesheets zu Dokumenten wurde in der W3CRecommendation festgehalten. Realisiert wird die Zuordnung über eine ProcessingInstruction im Prolog des Dokumentes. Ziel der Processing-Instruction ist xmlstylesheet mit den folgenden Attributen.
•
href mit der URL des Stylesheets
•
type mit der Sprache des Stylesheets (in MIME)
•
und anderen wie z.B. title, media, alternate
Die Stylesheet Referenz im Prolog eines XML Dokumentes kann dann z.B. so
aussehen:
<?xml-stylesheet href="meinstylesheet.xsl" type="text/xsl"?>
Unter href ist also der Dateiname zu finden und unter type ist angegeben, um
welchen Dateityp und um welche Art von Stylesheet es sich handelt.
ToDo: AB Beispiel
5.4.5 Formatierung des Output
XSLT ist am besten dann einzusetzen, wenn als Output XML Dokumente erzeugt
werden sollen. Soll der Output jedoch als Text formatiert werden, also mit
Einrückungen und/oder Leerzeichen, dann wird das Stylesheet schnell
unübersichtlich. Um die gewünschte Formatierung zu erzeugen, muss mit der
Anordnung der XSLT Elemente experimentiert werden.
Die Formatierung von XML Output kann – je nach Prozessor – über Schalter
und/oder Attribute eingestellt werden.
SOFTWARETECHNIK
Einführung in XML
- 60 -
©
Prof. J. Goll
- 5. Stylesheets -
5.4.6 Zusammenfassung
XSLT spielt eine wichtige Rolle in der Verarbeitung von XML Dokumenten. Dies soll
an zwei Beispielen erläutert werden.
1) Wenn jemand eine Website einrichtet, beispielsweise mit irgendwelchen
Nachrichten, natürlich in Form von XML Dokumenten, dann möchte und sollte er sich
nicht darum kümmern müssen, was die Empfänger der Nachrichten damit machen.
Die einen möchten bestimmte Nachrichten selbst in ihre Webseiten einbauen, die
anderen möchten zusätzliche Kommentare dazu abgeben, wieder andere wollen die
Nachricht nur in ihre Datenbank aufnehmen. An alle möglichen Nutzungsmöglichkeiten kann der Publisher gar nicht denken, geschweige denn alle bei der
Erstellung der XML Struktur berücksichtigen. Das ist nun auch gar nicht nötig. Er
kann sich konzentrieren auf seine ureigene Arbeit und die XML Struktur so
definieren, wie sie für ihn am geeignetsten ist. Jeder Empfänger der Nachricht kann
auf Grund der Kenntnis dieser Struktur ein XSLT Stylesheet schreiben, das das
angekommene XML Dokument prozessiert und in die gewünschte Zielform für die
Weiterverarbeitung transformiert.
2. Wenn Firmen untereinander Dokumente austauschen, die elektronisch
weiterverarbeitet werden sollen, dann war es bisher notwendig, dass sie sich auf ein
gemeinsames "Formular" einigen. In den beteiligten Firmen ist jede Menge Software
anzupassen, die einmal das neue Formular erzeugt, zum anderen solche Formulare
lesen kann. Mit XML und XSLT ist das nun nicht mehr notwendig. Jeder erzeugt XML
Dokumente in einer ihm geeigneten Struktur. Die Partner müssen nur ein kleines
XSLT Stylesheet schreiben, das ein empfangenes Dokument an ihre
Dokumentenstruktur anpasst.
Viele Firmen haben das inzwischen erkannt und XML und XSLT spielen eine
wichtige Rolle in der Konzeption neuer Middleware.
Zum Schluss noch eine Bemerkung zu der "Programmiersprache" XSLT. Ja, XSLT
ist eine Art Programmiersprache, in der formuliert wird, wie ein Source-Tree in einen
Result-Tree zu transformieren ist. XSLT ist aber nicht zu vergleichen mit den
"üblichen" Programmiersprachen, wie C, C++, Java,... Diese Programmiersprachen
sind imperative Programmiersprachen: darin werden Befehle formuliert, die dem
Computer sagen, was er tun soll. XSLT ist eine deklarative Programmiersprache. In
XSLT wird nur beschrieben, wie der Result-Tree aussehen soll, der XSLT Prozessor
findet selbst heraus, wie er das Ergebnis herstellen kann. Das hat zwei
Konsequenzen: (1) Der Entwickler selbst braucht nicht so viel zu beschreiben, da ihm
der Prozessor viel Arbeit abnimmt. (2) Es ist wichtig, auf den richtigen XSLT
Prozessor zu achten, da die sich doch deutlich unterscheiden, beispielsweise was
die Performanz betrifft, mit der bestimmte Konstrukte umgesetzt werden, vgl.
[Brand04].
SOFTWARETECHNIK
Einführung in XML
- 61 -
©
Prof. J. Goll
- 5. Stylesheets -
5.5 Performance Aspekte
Da XSL eine deklarative Sprache ist, kann in einem XSL Stylesheet auch nur
angegeben werden, „was“ und „wodurch“ etwas geändert werden soll. Die eigentliche
Bearbeitung, also das „wie“ unterliegt dem XSLT Prozessor, der das XSL Stylesheet
zur Laufzeit analysiert und interpretiert. Dies führt in jedem Fall zu einem
Flaschenhals, der die Performance einer XSL Transformation beeinträchtigt. Möchte
man nun diesen Flaschenhals umgehen, der gerade bei Transformationen mehrerer
XML Dokumente mit ein und dem selben XSL Stylesheet unnötig viel Zeit kostet,
sollte man XSLTC (eXtensible Stylesheet Language Transformations Compiled)
verwenden. Alternativ lässt sich eine Performanceverbesserung auch durch
Änderungen am Stylesheet erreichen.
5.5.1 Änderungen im Stylesheet
Um Änderungen an einem Stylesheet vornehmen zu können, müssen zunächst
Schwachstellen im XSLT Stylesheet erkannt werden. Dazu muss das Stylesheet
genau analysiert werden. Begründet liegt dies in der Eigenschaft von XSL
Dokumenten, da diese den Grundsätzen der funktionalen Programmierung folgen.
Das bedeutet: Variablen lassen sich zwar definieren, dürfen aber ihren Wert nicht
wieder ändern. Somit werden Seiteneffekte ausgeschlossen und es dem XSLT
Prozessor überlassen, in welcher Reihenfolge er die Befehle abarbeitet. Die Auswahl
der Reihenfolge ist so verschieden wie die Auswahl der XSLT Prozessoren.
Somit bleibt das Hauptproblem der Laufzeitoptimierung bei der Entwicklung von
XSLT Stylesheets: Der Entwickler muss also die Stellen im Code ausfindig machen,
die die meiste Zeit für ihre Ausführung benötigen. Und genau hierbei liegt das große
Problem. Zwar lassen sich durch Tracingfunktionen relativ einfach Programmanweisungen ermitteln, die häufig ausgeführt werden. Ein genaue Aussage über
deren Laufzeit ist dennoch nicht möglich.
Um genaue Aussagen über die Laufzeit von Programmanweisungen treffen zu
können benötigt man einen „Profiler“, der die Verweildauer eines Prozessors in jeder
Anweisung ermitteln kann. CatchXSL [24] ist ein in Java geschriebener XSLT
Profiler, der es ermöglicht Laufzeiten von XSL Anweisungen zu ermitteln. Dabei
liefert der Profiler nicht nur eine Angabe der benötigten Zeit pro Anweisung, sondern
außerdem eine Liste von Hot Spots und tiefergehende Einblicke in den Ablauf einer
Transformation. Problematisch ist derzeit die noch fehlende Schnittstelle an XSLT
Prozessoren, mit deren Hilfe sich solch ein Profiler einfacher ankoppeln liese. Daher
bedient sich CatchXSL der von manchen Herstellern angebotenen Tracing
Schnittstelle, über die verschiedene Events durch einen Listener abgefangen werden
können.
SOFTWARETECHNIK
Einführung in XML
- 62 -
©
Prof. J. Goll
- 5. Stylesheets Diese Events sind:
• Style-Event: startet beim Aufruf von Style Elementen.
• Write-Event: startet beim Generieren von Resultattext.
• Select-Event: tritt ein bei der Auswahl von Nodesets.
• Run- und Processing-Events: zur Kapselung von Transformationsabläufen.
Die Auswertungskomponente in CatchXSL analysiert die Zeitstempel dieser Events
und berechnet daraus die Laufzeiten der einzelnen Anweisungen. Desweiteren
werden Zeiten für die Toplevel Elemente des Stylesheets ausgegeben, etwa für
Variablendeklarationen am Anfang einer XSL Datei. Die so gewonnenen Ergebnisse
lassen sich als XML oder HTML Datei ausgeben und weiterverarbeiten.
Durch die, mit Hilfe des Profilers, erhaltenen Informationen lassen sich gezielt
Anweisungen mit hoher Laufzeit auffinden und optimieren. Diese Optimierungen sind
allerdings von Prozessor zu Prozessor verschieden und lassen sich nicht
verallgemeinern. So bewirken Veränderungen am XSLT Stylesheet bei einem
Prozessor eine Leistungssteigerung um ein Vielfaches, während die selbe Änderung
dem anderen Prozessor eher schadet.
Dies lässt sich am Besten mit Hilfe eines Beispiels aus dem iX Magazin 08/2002
[Hub02] verdeutlichen:
Erste Definition:
<xsl:variable name=“node-set“ select=“expression“/>
<xsl:for-each select=”$node-set”>
... Gesamtanzahl <xsl:value-of select=”count($node-set)”/>
</xsl:for-each>
Zweite Definition:
<xsl:variable name=“node-set“ select=“expression“/>
<xsl:variable name=“summe“ select=“count($node-set)“/>
<xsl:for-each select=”$node-set”>
... Gesamtanzahl <xsl:value-of select=”summe”/>
</xsl:for-each>
Beide Definitionen liefern identische Ausgabeergebnisse. Der einzige Unterschied
innerhalb der beiden gezeigten Listings besteht darin, dass in der ersten Definition
die Anzahl der Knoten bei jedem Schleifendurchgang neu berechnet werden muss.
Diese Summe wird in der zweiten Definition schon vor der Schleife berechnet und in
einer separaten Variablen gehalten.
In [Brand04] wurde gezeigt, dass die Unterschiede in der Verarbeitung beider
Versionen sehr groß sein können. Die Ursache dafür liegt in der internen Abarbeitung
der einzelnen Anweisungen. Die Ergebnisse zeigten aber auch sehr deutlich, dass
man für jeden verwendeten Prozessor anders optimieren oder entwickeln muss.
Wenn auch die Unterschiede bei einzelnen Transformationen nur gering sind, so
SOFTWARETECHNIK
Einführung in XML
- 63 -
©
Prof. J. Goll
- 5. Stylesheets addieren sich diese Unterschiede
Transformationen sehr schnell auf.
bei
vielen
oder
häufig
durchgeführten
5.5.2 XSLTC (Translets)
Bei der Verwendung eines XSLTC Prozessors (im folgenden Beispiel Xalan-J) wird
das zu verwendende XSL Stylesheet in eine Stylesheet Klasse überführt. Diese
Klasse nennt man im Zusammenhang mit XSL auch Translet.
Soll dann dieses XSL Stylesheet auf mehrere XML Dokumente angewendet werden,
wird das XSL Stylesheet nicht jedesmal neu übersetzt, sondern aus der schon
übersetzten Klassendatei geholt, da hier das Stylesheet schon im Bytecode vorliegt.
Abbildung 5-5: Prinzip von Translets
XSLT Translets sind in die TrAX (Transformation API for XML) / JAXP (Java API for
XML Processing) 1.2 API integriert. Dadurch ist es möglich direkt auf die
TransformerFactory zuzugreifen und ein Transformer Objekt zu erzeugen, welches
das Translet kompiliert und startet.
Eine Anwendung kann XSLTC entweder durch seine native API oder durch seine
Implementierung der TrAX API ausführen. Der Compiler erstellt dann ein oder
mehrere Java Klassen (die Translets), welche entweder abgespeichert oder als
Objekte im Speicher gehalten werden. Die XSLTC Laufzeit Bibliothek enthält die
SOFTWARETECHNIK
Einführung in XML
- 64 -
©
Prof. J. Goll
- 5. Stylesheets benötigten Klassen, die diese erstellten Translets laden und zur Transformation von
XML Dokumenten verwenden können.
Bei einem Performancevergleich [Brand04] wurden mit Xalan-J verschiedene
Transformationen jeweils mit und ohne Translets durchgeführt. Dabei wurde jeweils
eine .xml Datei 25 mal transformiert. Es zeigte sich deutlich, dass die Verwendung
eines Translets in jedem Testfall enorme Zeitvorteile bringt. Die mit Translets
benötigte Zeit lag hierbei lediglich zwischen 25% und 61% der benötigten Zeit ohne
Translets.
5.6 Formatting Objects (XSL-FO)
Die Formatierungssprache XSL-FO (XSL Formatting Objects) ist ein XML Vokabular
für die Anwendung von Formatierungsangaben auf XML Dokumente. FO ist der Teil
von XSL, mit dem unter Verwendung von Formatierungsobjekten Dokumente
millimetergenau formatiert werden können. Mittels dieser Formatierungsobjekte ist es
möglich, die physischen Bestandteile einer Dokumentation, also Seiten, Bereiche,
Tabellen, Kopf- und Fußzeilen, genau festzulegen. Auf diese Weise lassen sich
rechnerunabhängige Ausgabeformate definieren, die insbesondere für Printmedien
geeignet sind.
HTML ist ein Ausgabeformat, das speziell für den Bildschirm zugeschnitten ist. Ein
HTML Dokument wird beim Ausdrucken allerdings auf unvorhersehbar viele Seiten
verteilt. Für die Ausgabe auf ein Printmedium ist dieses Format daher nur bedingt
geeignet, da der Inhalt weder genau platziert, noch einzelnen Seiten zugewiesen
werden kann.
Durch die Verwendung von Formatierungsobjekten der aktuellen XSL Spezifikation
kann dieses Problem behoben werden. Da XSL-FO speziell für Druckformate
entworfen wurde, orientiert es sich auch eher am klassischen Buchdruck und bietet
daher beispielsweise extra Methoden zur Definition von Fußnoten, Seitenangaben,
Kopf- und Fußzeilen.
Für die Verarbeitung der Formatierungsanweisungen bedarf es allerdings, ebenso
wie bei XSLT, eines Prozessors, der die Formatierungsobjekte interpretieren kann
und ein entsprechendes Ausgabedokument erzeugen kann, wie im folgenden Bild
dargestellt.
SOFTWARETECHNIK
Einführung in XML
- 65 -
©
Prof. J. Goll
<fo:flow>
<fo:block font-size="20pt"
font-family="Arial">
Diplomarbeit
</fo:block>
<fo:block font-size="18pt"
font-style="bold">
Thema:
</fo:block>
</fo:flow>
Thema:
XSL-FO - 5. Stylesheets
Prozessor
XSL-FO
Entwickeln eines
generischen Anzeigemoduls
zur Erzeugung von
graphischen...
PDF Datei
Bild 5-6: Umwandlung von XSL-FO in PDF
Für das Portable Document Format (PDF) von Adobe wurde von der Apache
Software Foundation ein freier FO Prozessor (fop) entwickelt, der aus einem XSL-FO
Dokument direkt eine PDF Datei erzeugen kann. Prozessoren für andere Formate,
wie beispielsweise TeX sind mittlerweile ebenso verfügbar. Da die XSL-FO
Spezifikation jedoch recht komplex und sehr umfangreich ist, ist derzeit noch kein
Prozessor in der Lage, alle definierten (verfügbaren) Formatierungsobjekte
umzusetzen.
Der XSL-FO Prozessor gliedert sich hierbei noch in einen XSL Transformer, der die
Anweisungen und Daten auf das gewünschte Zielformat umsetzt und einen XSL
Formatter, der die eigentliche Platzierung der Inhalte im entsprechenden Zielformat
vornimmt.
XSL-FO wird im XML Format beschrieben und enthält im aktuellen Namensraum
(http://www.w3.org/1999/XSL/Format) bisher 56 Objekte mit insgesamt
über 250 Attributen. Mit diesen Formatting Objects können Dateninhalte im
Dokument exakt platziert werden. Durch die entsprechenden Attribute, den
Formatting Properties, können diese an eigene Bedürfnisse des Layouts und der
Darstellung des Dokumentes angepasst werden. Über diese Attribute werden
Einstellungen wie z.B. Schriftart, -größe, -farbe oder Abstände vorgenommen.
Die Erzeugung von XSL-FO sollte jedoch nicht manuell geschehen, sondern am
besten unter Verwendung von XSLT und entsprechenden Stylesheets. Dadurch
wird der Inhalt und das Layout getrennt. Über die Stylesheets werden die
Formatierungen bestimmt und mit dem Inhalt aus XML zu einer FO Datei
transformiert. Da bei einem FO Dokument eine Unmenge an Formatierungsanweisungen anfallen kann, wird es schnell sehr lang und unübersichtlich. Daher
empfiehlt es sich die Erzeugung dieser Dokumente durch Vorlagen und
entsprechende Prozessoren zu realisieren.
Da XSL-FO ein XML Format ist, kann es von XML Parsern verarbeitet und auch
validiert werden.
SOFTWARETECHNIK
Einführung in XML
- 66 -
©
Prof. J. Goll
- 5. Stylesheets -
5.6.1 Aufbau eines FO Dokumentes
Durch das eigentliche Anwendungsgebiet geprägt, arbeitet XSL-FO generell
seitenorientiert. Das Formatierungsmodell von FO basiert dabei auf sogenannten
Regionen. Diese Regionen, teilweise auch Boxen genannt, sind rechteckige
Bereiche, die den eigentlichen Inhalt in Form von Text, Bildern oder weiteren
Formatierungsobjekten enthalten können.
Ein XSL-FO Dokument beginnt wie jedes XML Dokument zunächst mit einer XMLDeklaration. Darauf folgt das Wurzelelement, in dem auch gleich der entsprechende
Namensraum zugewiesen werden kann. In diesem Fall wäre das
xmlns:fo="http://www.w3.org/1999/XSL/Format".
Für
diesen
Namensraum wird üblicherweise das Namenspräfix fo, für Formatting Objects
verwendet. Gemäß der Spezifikation enthält dieser Namensraum alle Elemente und
Attribute, die zur Verwendung in einem XSL-FO Dokument genutzt werden können.
Im weiteren Verlauf des Textes wird bei den XSL-FO Elementen der Namensraum
stets mit fo bezeichnet.
Nachstehend ist die Struktur eines XSL-FO Dokumentes mit den wichtigsten
Elementen aufgestellt. Sie bietet eine gute Übersicht, durch welche FO Elemente
sich ein Dokument formatieren lässt und wie diese zusammenhängen.
fo:root
fo:layout-master-set
fo:declarations
fo:color-profile
fo:simple-page-master
fo:regionbody
fo:regionend
fo:page-sequence
fo:title
fo:static-content
fo:flow
fo:page-sequence-master
fo:regionafter
fo:repeatable-page-master-reference
fo:repeatable-page-master-alternatives
fo:regionstart
fo:regionbefore
fo:simple-page-master-reference
fo:conditional-page-master-reference
Bild 5-7: XSL-FO Dokument als Baumstruktur
Das Wurzelelement jedes XSL-FO Dokumentes bildet das <fo:root>-Element. Es
umschließt die gesamten Definitionen und Inhalte des FO Dokumentes. Die
SOFTWARETECHNIK
Einführung in XML
- 67 -
©
Prof. J. Goll
- 5. Stylesheets Spezifikation legt fest, dass im root-Element zwingend die beiden Knoten
<fo:layout-master-set> und <fo:page-sequence> anzugeben sind. Diese
Elemente gliedern ein FO Dokument zunächst in zwei grundlegende Bereiche:
Im ersten Teil werden im sogenannten <fo:layout-master-set> die Seiten
formatiert und die Seitenfolge festgelegt, also somit das generelle Layout des
gesamten Dokumentes bestimmt. Bei der Definition der Seiten werden die
eigentliche Blattgröße und die Seitenränder angegeben, sowie die Regionen
definiert, die eine grobe Einteilung der Seiten über das ganze Dokument hinweg
festlegen. Die Regionen werden dann später den eigentlichen Inhalt des
Dokumentes aufnehmen.
Im zweiten Teil der FO Datei erfolgt dann die Angabe der darzustellenden Inhalte
und wie diese auf der Seite verteilt werden sollen. Dieser Teil besteht aus einer
Reihe von <fo:page-sequence> Elementen.
In einem optionalen dritten Teil können noch mit <fo:declarations> Angaben
zum Farbprofil gemacht oder es können globale Anweisungen festgelegt werden,
die auch über den Namensraum hinaus gehen können.
5.6.2 Layoutvorlagen
Zunächst soll nun das <fo:layout-master-set> mit den Seitenformatierungen
betrachtet werden. Zur Definition der Seitenformatierungen besteht das
<fo:layout-master-set> generell aus mindestens einem <fo:simple-pagemaster> und gegebenenfalls einem oder mehreren <fo:page-sequencemaster>. Die <fo:simple-page-master> sind dabei Vorlagen für die
verwendeten Seiten. So ist beispielsweise für ein Dokument vorstellbar, drei separate
Seitenlayouts zu bestimmen, wobei die Titelseite, sowie gerade und ungerade Seiten
jeweils gleiche Abmessungen haben, jedoch unterschiedliche Seitenränder und
verschiedene Formatierungen erhalten können. Jede Seite wird dabei durch ein
<fo:simple-page-master> definiert, in dem dann die Angaben zur Seitengröße
und den Seitenrändern festgelegt werden. Dabei erhält jedes <fo:simple-pagemaster> einen eindeutigen Namen als Attribut, mit dem dieses Layout dann später
im Dokument einer einzelnen Seite zugewiesen werden kann.
Die Angaben in einem <fo:simple-page-master> erfolgen als Attribute und als
untergeordnete XSL-FO Elemente (Kindelemente).
Die Maßangaben der Attribute können dabei in den Einheiten cm (Zentimeter), mm
(Millimeter), in (Inches), px (Pixel), pt (Punkte: 1/72 Inch), pc (Picas: 1/6 Inch), em
(Schriftgröße des Buchstaben m der verwendeten Schrift) und ex (Höhe des
Zeichens x der Schrift) angegeben werden. Durch diese Vielzahl der möglichen
Einheiten wird die internationale Verwendung des XSL-FO Formates ermöglicht.
SOFTWARETECHNIK
Einführung in XML
- 68 -
©
Prof. J. Goll
- 5. Stylesheets -
5.6.3 Seitenstrukturierung
Durch die Attribute des <fo:simple-page-master> werden die Seitenränder und
die Seitengröße des Dokuments, wie im folgenden Bild dargestellt, definiert. Eine
Seite besteht dabei zunächst einmal aus der content area und den umgebenden
Seitenrändern.
margin-top
margin-left
content area
height
margin-right
margin-bottom
width
Bild 5-8: Definition der Seitenränder und -maße eines Blattes
Durch weitere Attribute des <fo:simple-page-master> wird nun die content
area in einer Seite festgelegt. Diese wird nun jedoch nochmals weiter unterteilt.
SOFTWARETECHNIK
Einführung in XML
- 69 -
©
Prof. J. Goll
- 5. Stylesheets Die content area gliedert sich in fünf Regionen, die mit <fo:region-body>,
<fo:region-before>, <fo:region-after>, <fo:region-start> und
<fo:region-end> bezeichnet werden. Diese sind XSL-FO Elemente, die als
Kindelemente im <fo:simple-page-master> enthalten sein können. Die
Anordnung dieser Regionen innerhalb einer Seite ist im folgenden Bild dargestellt.
fo:region-body
fo:region-end
fo:region-start
fo:region-before
content-area
fo:region-after
Bild 5-9: Gliederung der content-area
In diesen Regionen der content area kann dann der eigentliche Inhalt platziert
werden. Dabei kann <fo:region-before> beispielsweise die Kopfzeile mit der
Angabe zum gegenwärtigen Kapitel enthalten und in <fo:region-after> die
aktuelle Seitenzahl dargestellt werden. Der laufende Text wird dann in den Bereich
<fo:region-body> eingefügt. Die Zuweisung der verwendeten Region zum
darzustellenden Inhalt erfolgt später in den <fo:page-sequence>-Bereichen des
XSL-FO Dokuments.
In den Layoutvorgaben <fo:layout-master-set> kann neben dem Element
<fo:simple-page-master> noch ein <fo:page-sequence-master> definiert
werden. Dieser ist notwendig, falls mehr als ein Seitenformat gewählt wird. Hier
können beispielsweise verschiedene Seitenformate für gerade und ungerade Seiten
zugewiesen werden. Da die Formatierung mit mehreren Seitenformaten jedoch sehr
umfangreich ist, kann hier nicht näher darauf eingegangen werden. Weitere
Kindelemente sind für das Element <fo:simple-page-master> nicht definiert.
SOFTWARETECHNIK
Einführung in XML
- 70 -
©
Prof. J. Goll
- 5. Stylesheets -
5.6.4 Seitenfolgen
Der eigentliche Inhalt des Dokumentes wird in sogenannten Seitenfolgen, den
<fo:page-sequence>-Objekten angegeben. Dabei steht in einem Element vom
Typ <fo:page-sequence> eine Folge von Seiten, die die gleichen Charakteristika
haben. So kann z.B. ein Kapitel eines Buches in einem Element <fo:pagesequence> angegeben werden.
Für den Inhalt kann
Kindelemente enthalten.
das
Element
<fo:page-sequence>
verschiedene
Für den eigentlichen fortlaufenden Text eines Dokumentes muss das Objekt
<fo:page-sequence> genau ein <fo:flow> Element enthalten. Innerhalb dieses
Elementes wird der eigentliche Inhalt eines Dokumentes angegeben. Text, der sich in
diesem Element befindet, wird bei der Anzeige fortlaufend dargestellt und relativ in
der Seite, bzw. der Region platziert. Dabei wird mit dem einzigen Attribut von
<fo:flow>, dem flow-name, auf die Region verwiesen, in der der Inhalt eingefügt
werden soll. Üblicherweise ist das der Bereich <fo:region-body>. Das Element
heißt so, weil der Text in ihm "fließt" und vom anzeigenden Programm automatisch
so angeordnet wird, dass er auf die Seite passt.
Zur weiteren Gruppierung des Inhaltes, also zum Darstellen von Absätzen,
Formatieren von Überschriften aber auch zur eigentlichen Formatierung der Schrift
werden innerhalb von <fo:flow> und <fo:static-content> Kindelemente vom
Typ <fo:block> verwendet.
5.6.5 Darstellung des Inhaltes
Um den tatsächlichen Inhalt in das Dokument einzufügen und in einer speziellen
Schriftart darzustellen, stehen weitere XSL-FO-Elemente zur Verfügung, die
unterschiedliche Granularitäten aufweisen. Die wichtigsten sind <fo:block>,
<fo:inline>, <fo:character>.
Der eigentliche textuelle Seiteninhalt wird innerhalb von <fo:flow> zunächst mit
den Objekten vom Typ <fo:block> eingeteilt. Eine weitere Gruppierung oder
Umformatierung kann dann innerhalb der block-Objekte mit Elementen vom Typ
<fo:inline> und <fo:character> erfolgen.
SOFTWARETECHNIK
Einführung in XML
- 71 -
©
Prof. J. Goll
- 5. Stylesheets -
5.6.6 Beispiel
Ein einfaches XSL-FO Dokument ist demnach wie folgt aufgebaut:
<?xml version="1.0" encoding="iso-8859-1"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master
page-master-name="Haupt-Seite"
height="29.7cm"
width="21cm"
margin-top="1cm"
margin-bottom="1.5cm"
margin-left="2cm"
margin-right="2cm">
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-name="Haupt-Seite">
<fo:flow flow-name="xsl-region-body">
<fo:block>Hallo Welt!</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
Dieses Beispiel definiert im layout-master-set eine Seite (Format DIN A4) mit
dem Namen Haupt-Seite. Im zweiten Abschnitt page-sequence wird für diese
Seite eine flow-Box im region-body eingerichtet, die einen Block beinhaltet. In
diesem Block wird der Text Hallo Welt! ausgegeben.
5.6.7 Verfügbare XSL-FO Prozessoren
Derzeit sind schon einige Prozessoren zur Umwandlung von XSL-FO verfügbar. Es
handelt sich dabei sowohl um Open-Source Implementierungen als auch um
kommerzielle Produkte. Von den Prozessoren werden zum Teil unterschiedliche
Zielformate unterstützt. Als Ausgabeformat steht das PDF Format an erster Stelle.
Aber auch andere Dokumentenformate, wie RTF, HTML, PS oder sogar TeX können
von manchen Prozessoren erzeugt werden.
SOFTWARETECHNIK
Einführung in XML
- 72 -
©
Prof. J. Goll
- 5. Stylesheets -
5.6.8 Zusammenfassung
Die wichtigsten FO Elemente zur Erstellung von einfachen XSL-FO Dokumenten
wurden hier erklärt. Es gibt aber noch eine Vielzahl weiterer Formatierungselemente,
mit denen sich Links, Listen, Tabellen, dynamische Effekte usw. erzeugen lassen.
Hier kann aber nicht auf alle 56 Elemente eingegangen werden. Die verfügbaren
Elemente mit ihren jeweiligen Attributen lassen sich in der Spezifikation
nachschlagen. Da es allerdings noch keinen Prozessor gibt, der alle Elemente samt
deren spezifizierten Eigenschaften unterstützt, sollte die Auswahl der verwendeten
Formatierungselemente vorsichtig vorgenommen werden und dabei ebenso der zur
Verfügung stehende FO Prozessor berücksichtigt werden.
Das Interessante an XSL-FO ist, dass man theoretisch völlig frei vom Zielformat ist.
Das heißt, es ist nur noch vom Prozessor abhängig, welches Ausgabeformat erzeugt
werden soll, das eigentliche Dokument sieht aber immer gleich aus, egal ob man ein
PDF Dokument erstellt, ein RTF Format, oder eine MS-Word Datei. Leider bedarf es
bis dahin noch einer verbesserten Umsetzung der Spezifikation in den Prozessoren
und neue Implementierungen für weitere Ausgabeformate. So ist beispielsweise
derzeit noch kein FO Prozessor erhältlich, der Word-Dateien erstellen kann.
Viele Aspekte von FO erinnern stark an die Font-Tags von HTML, allerdings gibt es
einen entscheidenden Unterschied zwischen XSL-FO und HTML. Da XSL-FO
Anweisungen im Gegensatz zu den CSS von HTML direkt im Text eingebunden
werden, wird XSL-FO nur als Endprodukt einer Konvertierung verwendet. Eine
Änderung der Formatierungseigenschaften durch eine externe Datei, wie es bei
HTML mit CSS erfolgen kann, ist bei XSL-FO nicht möglich. Dazu ist bei XML eben
auch der andere Teil von XSL, nämlich XSLT zuständig.
SOFTWARETECHNIK
Einführung in XML
- 73 -
©
Prof. J. Goll
- 6. XML Schema -
6 XML Schema
Da XML Dokumente gerade für den Austausch von Daten besonders gut geeignet
sind, bietet sich der Einsatz von XML z.B. im Zusammenhang mit Datenbanksystemen geradezu an. Allerdings stellte sich hier früh heraus, dass die für XML
üblichen DTDs einige Mängel aufweisen, die dieses Unterfangen deutlich
erschweren:
•
•
•
DTDs entsprechen nicht der XML Syntax (d.h. die DTDs selbst sind keine
XML Dokumente).
DTDs weisen mangelhafte Kompatibilität zu den XML Namespaces auf.
DTDs kennen keine Möglichkeit, Elementen oder Attributen Datentypen
zuzuweisen. Gerade dieser Mangel macht den Einsatz von XML zum
Austausch von Daten zwischen Datenbanksystemen sehr problematisch.
Aufgrund dieser Nachteile entstanden Bestrebungen neue Wege zu finden, die
Grammatik für XML Dokumente zu definieren, ohne die genannten Mängel in Kauf
nehmen zu müssen.
Das Ergebnis dieser Initiativen bildet die Spezifikation des XML Schema. XML
Dokumente werden einer sogenannten XML Schema Definition (XSD) zugeordnet,
anstelle einer DTD.
6.1 Entwicklung von XML Schema
6.1.1 Vorgänger von XML Schema
Es gab diverse Ansätze, um neue Definitionssprachen zu entwickeln, welche die
Mängel der DTD beheben sollten, bzw. um neue Ideen einfließen zu lassen. Im
Folgenden werden einige aufgezählt, die wichtig waren und die Entwicklung von XML
Schema beinflusst haben.
•
RELAX – REgular LAnguage Description for XML von Murata Makoto
•
TREX – Tree Regular Expressions for XML von James Clark
•
RELAX NG – TREX und RELAX Nachfolger
•
DDML – Document Definition Markup Language
•
Schematron – von Rick Jelliffe
Die Definitionssprachen können in kontextfreie Grammatiken und regelbasierte
Sprachen aufgeteilt werden, wobei lediglich Schematron als regelbasiert zu nennen
ist. Schematron basiert auf XPath-Ausdrücken, die sogenannte Assertions
(Behauptungen) aufstellen. Eine Vielzahl von Behauptungen bilden dann ein
Schema. Alles was nicht explizit verboten ist, ist erlaubt. Hier lässt sich Komplexes
sehr einfach darstellen (z.B. Regeleinschränkungen). Der Nachteil jedoch ist, dass
einfache, aber bei XML notwendige Tätigkeiten, wie das Definieren von Strukturen
SOFTWARETECHNIK
Einführung in XML
- 74 -
©
Prof. J. Goll
- 6. XML Schema und Datentypen, sehr kompliziert und unübersichtlich wird. In dieser Hinsicht sind die
kontextfreien Grammatiken wesentlich besser geeignet.
Die Idee von XML Schema war, die bereits vorher bestehende, als Basis zu sehende
Technologie der DTD zu verbessern und zu erweitern. Das war ein wesentlicher
Punkt in dieser Konkurrenz und so erreichte XML Schema, das ursprünglich auf
einem Vorschlag von Microsoft basierte, am 2. Mai 2001 den Recommendation
Status durch das W3C. Dadurch, dass der Standard von offizieller Seite längerfristig
anerkannt wurde und klar zu erkennen ist, wo die Vorteile liegen, verbreitet er sich
immer mehr. Dort wo präzise Definitionen von Daten in Anwendungsgebieten gefragt
sind, wird in aller Regel nur noch mit XML Schema gearbeitet statt mit DTDs.
6.1.2 Definition von XML Schema
Das Wort Schema kommt aus dem Griechischen (σχηµα) und bedeutet Form/Figur.
Dieser Bedeutung entsprechend definiert XML Schema die Gestalt einer XMLbasierten Sprache. XML Schema ist ein auf Grammatiken basiertes Regelwerk. Die
Regeln definieren sowohl Struktur als auch Inhalt eines XML Dokuments. Damit
können wiederum wie im Falle der DTD Gültigkeitsprüfungen durchgeführt werden.
XML Schema macht einen entscheidenden Schritt von der bisherigen dokumentenorientierten Sichtweise hin zur daten-orientierten Sichtweise. Die Erweiterungen
gegenüber einer DTD können im Wesentlichen in zwei Punkten zusammengefasst
werden:
•
Darstellung des Inhaltes über Typisierung
Dieser Punkt bezieht sich hauptsächlich auf die Erweiterung der
Ausdrucksmöglichkeiten hinsichtlich struktureller, als auch inhaltlicher
Merkmale. So halten Konzepte aus der Objektorientierung Einzug und die
Zuweisung von Datentypen wird massiv ausgeweitet. Neben Zeichenketten
können jetzt auch Integerwerte, Fließkommazahlenwerte, Datumswerte und
viele andere Datentypen zugewiesen werden.
•
XML-konforme Syntax
XML Schema ist im Gegensatz zur DTD in der XML Syntax selbst gehalten.
Dies garantiert zum einen eine schnelle Einarbeitung für den Anwender und
zum anderen ermöglicht es auch Parsern und anderen XML-verarbeitenden
Applikationen, XML Schema Dokumente wie jedes andere XML Dokument zu
behandeln und keine Spezialtechniken anwenden zu müssen.
SOFTWARETECHNIK
Einführung in XML
- 75 -
©
Prof. J. Goll
- 6. XML Schema Die Spezifikation durch das W3C besteht aus 3 Teilen:
•
XML Schema Part 0: Primer
Dieses nicht-normative Dokument soll den einfachen Zugang zu der XML
Schema Sprache auf Basis von Beispielen und einfachen Erläuterungen
geben.
•
XML Schema Part 1: Structures
Dieses Dokument bildet die vollständige normative Beschreibung der
Strukturen von XML Dokumenten in XML Schema.
•
XML Schema Part 2: Datatypes
Dieses Dokument beschreibt die Möglichkeiten zum Definieren von
Datentypen, welche beim XML Schema wie auch in anderen XML
Spezifikationen verwendet werden können.
Da die momentane Spezifikation bereits 345 Seiten umfasst, kann hier nicht
detailliert auf das Erstellen/Verwenden von XML Schema eingegangen werden. Es
soll lediglich ein Überblick vermittelt werden.
6.1.3 Vergleich XML Schema – DTD
In der Tabelle 6-1 ist eine ausführliche Gegenüberstellung der Unterschiede
zwischen DTDs und XML Schema zu finden.
Der Hauptunterschied zwischen XML Dokumenten, die über eine DTD definiert sind,
und solchen, die über ein Schema definiert sind, besteht in der Typisierung der
einzelnen Elemente: während eine DTD nur einen Typ kennt, nämlich String
(CDATA, bzw. PCDATA) verfügt XML Schema über reichhaltige Möglichkeiten zur
Typisierung, die weiter unten erläutert werden. Hier soll jedoch an Hand eines
kleinen Beispiels die Problematik der fehlenden Typisierung in DTDs aufgezeigt
werden.
<etwas>
<wert>45.76</wert>
</etwas>
Jede Anwendung, die dieses kleine XML Dokument verarbeitet, wird sich fragen, was
das Element wert bedeutet. Die Befragung der DTD kann als Antwort nur ergeben,
dass Strings (PCDATA) dort stehen dürfen. Doch welche Art von Strings und wie
lange die etwa sein können, das kann aus der DTD nicht ausgelesen werden. Eine
Anwendung kann nur “raten”, wenn in diesem Dokument Zahlen vorkommen, dann
vielleicht auch in den anderen, die der gleichen DTD entsprechen. Aber geprüft
werden kann diese Annahme nicht. Die Anwendung kann es auch nicht in der DTD
spezifizieren, dass sie an der Stelle nur Zahlen möchte.
SOFTWARETECHNIK
Einführung in XML
- 76 -
©
Prof. J. Goll
- 6. XML Schema -
XML Schema
+ XML-konforme Sprache
+ Datentypen können besser
spezifiziert werden, wie z.B.
Integer, Boolean, Datum, ...
DTD
- Eigene, nicht XML-konforme Syntax
- Vernachlässigung von Datentypen
(weder semantische Bedingungen
noch Wertebereiche); Versteifung auf
den Datentyp string
+ Festlegen von Beschränkungen
einfach und flexibel
+ Beschränkungen des
Inhaltsmodells für generische
Datenformate.
+ Komplexe Strukturen können
einfach dargestellt werden ->
Ausdrucksmächtigkeit
+ Einführung von Typen
(complexType) für das Definieren
von Elementen; dieser kann auf
mehrere Elemente angewendet
werden.
+ Unterstützung von
Musterdefinitionen (reguläre
Ausdrücke) mittels Element
<pattern> (simpleType)
+ Vererbung ist möglich.
+ Konzepte aus Programmier- und
Datenbanksprachen
+ Erweiterbar durch die Nutzung
mehrerer Schemas und auch von
DTDs
- Deklaration von Entities nicht
möglich
+ Hinter einem Schema steht eine
DTD, die die benutzte Grammatik
überprüft.
- Ausdrücke, um komplexe Strukturen
darzustellen sind unzureichend. Sie
müssen umständlich nachempfunden
werden.
- Es können keine eigenen Typen
(Klassen) für ein Element festgelegt
werden.
- Nur geringfügig erweiterbar
- Nicht für große Applikationen
geeignet
+ Deklarieren von Entities
- Hinter einer DTD kann keine weitere
Datei zur Überprüfung der eigenen
Grammatik stehen.
Tabelle 6-1: Vergleich DTD – XML Schema
SOFTWARETECHNIK
Einführung in XML
- 77 -
©
Prof. J. Goll
- 6. XML Schema -
Selbst wenn man sich auf Zahlen einigt, bleibt immer noch das Problem, welche Art
von Zahlen hier stehen können. Ausgehend vom obigen Beispiel gibt es folgende
Möglichkeiten:
-
ein dezimaler Währungstyp wie in COBOL,
eine Festpunktzahl,
eine unendlich genaue Gleitpunktzahl wie bei java.math.BigDecimal,
eine double-Zahl nach IEEE754,
eine double Zahl nach Java,
eine float Zahl nach IEEE754,
eine Gleitpunktzahl nach VAX Fortran REAL,
build 67 of version 45 of MS Word,
ein regulärer Ausdruck, der auf alle Strings zutrifft, die mit der Zeichenfolge 45
beginnen, dann ein beliebiges Zeichen haben, und abgeschlossen werden mit
der Zeichenfolge 67.
Weitere Interpretationen sind zweifellos möglich. Diesem Problem begegnet man in
XML Schema, in dem alle Elemente typisiert werden. Damit werden die möglichen
Interpretationen eines Strings stark eingeschränkt. Ein Parser kann prüfen, ob ein
gegebener String, der sich in einem Element befindet, dem im Schema spezifizierten
Typ entspricht. Anwendungen können sich dann darauf verlassen, dass sie ohne
Probleme den String gemäß dem Typ interpretieren können. Fehlerhafte Dokumente
werden schon vom Parser zurückgewiesen, die Anwendung braucht sich nicht mehr
darum zu kümmern.
6.2 Validierung über XML Schema Definitionen
Bei XML Schema werden XML Dokumente nun nicht mehr einer DTD zugeordnet,
sondern einem Schema, genauer gesagt einer XML Schema Definition (XSD).
Dieses Schema selbst ist auch ein XML Dokument, also in der XML Syntax
geschrieben. Das benutzte Vokabular ist in einer DTD, bzw. einer weiteren Schema
Definition, die im Hintergrund eingebunden ist, definiert. Der genaue Validierungszyklus wird in der folgenden Abbildung verdeutlicht.
Damit wird sichergestellt, dass die Ausdrücke für die Deklaration eines XML
Dokuments einen Standard haben und dass der bestimmten Regeln (vordefinierten
Strukturen und Datentypen) entsprechen muss. Fehler im Schema selbst führen zu
einem Abbruch durch den Parser.
SOFTWARETECHNIK
Einführung in XML
- 78 -
©
Prof. J. Goll
- 6. XML Schema -
Abbildung 6-1: Validierungszyklus eines XML Dokumentes über XML Schema
SOFTWARETECHNIK
Einführung in XML
- 79 -
©
Prof. J. Goll
- 6. XML Schema -
6.2.1 Validierung der XML Schema Definition
Die Validierung einer XSD Datei gegenüber der DTD (bzw. dem Schema) für XML
Schema erfolgt durch die Einbindung des Schema Namespaces im Wurzelelement
der Schema Definition. Dieser Namespace für Schema Definitionen hat die URI
http://www.w3.org/2001/XMLSchema. Hier gilt wie vorhin, dass das Präfix
beliebig gewählt werden kann. Üblich ist jedoch schon der Name xsd, wie im
folgenden Beispiel zu sehen. Der Name des Wurzelelements eines Schemas ist
immer schema.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="Liste" type="xsd:string"/>
...
</xsd:schema>
Dies ist der Inhalt der Datei liste.xsd. Damit wird ein Schema definiert: In einem
Instanzdokument können Elemente mit dem Tag-Namen Liste vorkommen, deren
Inhalt den Typ xsd:string hat. Die möglichen Typen einer Schema Definition
werden weiter unten erläutert.
6.2.2 Einbinden einer Schema Definition in ein XML Dokument
Bevor ein XML Dokument gegen ein Schema validiert werden kann, muss es,
äquivalent zur DOCTYPE-Angabe bei der Nutzung einer DTD, bekannt machen,
dass überhaupt ein Schema vorhanden ist. Parallel wird der Pfad definiert, in dem
das Schema (*.xsd) zu finden ist. Das folgende Beispiel zeigt fragmentarisch ein
XML Dokument zu dem weiter oben eingeführten Schema liste.xsd.
<Liste xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="liste.xsd">
Inhalt
</Liste>
Diese Angaben erfolgen also, indem dem Wurzelelement des XML Dokumentes eine
Namespace-Definition für XML Schema Instanzen und das Attribut
xsi:noNamespaceSchemaLocation hinzugefügt wird. Der Wert dieses Attributes
gibt die URL des Schemas an. Der Namespace (in diesem Fall xsi) muss auf die
URI http://www.w3.org/2001/XMLSchema-instance verweisen. Solange der
Namespace auf diese URI verweist, darf das Präfix jeden beliebigen Namen
annehmen.
Mit diesen Angaben kann das XML Dokument jedem Parser übergeben werden, der
den neuen Stand der Gültigkeitsprüfung über XML Schema unterstützt. Ein solcher
SOFTWARETECHNIK
Einführung in XML
- 80 -
©
Prof. J. Goll
- 6. XML Schema Parser wird auch als Schema Validator (oder als schema aware) bezeichnet. Seine
Arbeit geht weit über das normale Parsen hinaus und umfasst beispielsweise
Typprüfungen gemäß dem Schema. Ein XML Dokument, das einem Schema genügt,
wird manchmal auch Instanzdokument des Schemas genannt.
Das Attribut xsi:noNamespaceSchemaLocation hat folgende Bedeutung: das
Schema ist keinem Namensraum zugeordnet (no Namespace) und der Wert dieses
Attributes ist die Location (URL), unter der das Schema zu finden ist. XML Schema
Definitionen sind mit Blick auf XML Namespaces entworfen worden, während die
DTDs noch von SGML stammen. Im nächsten Abschnitt wird kurz erläutert, wie man
eine XML Schema Definition einem eigenen Namensraum zuordnet.
6.2.3 Zuordnung zu einem Namespace
Einem XML Schema kann ein bestimmter Namensraum zugewiesen werden, indem
man innerhalb der Schema Definition einen „Target-Namespace“ definiert. Man kann
auch definieren, ob die Elemente im Instanzdokument voll qualifiziert angegeben
werden sollen, d.h. mit Namespace-Präfix, oder ob sie ohne Präfix angegeben
werden können. Dies kann für Attribute und Elemente getrennt angegeben werden.
Hier folgt ein Beispiel, in dem ein Target-Namespace angegeben wurde. Die
Elemente im Instanzdokument müssen voll qualifiziert und die Attribute können
unqualifiziert angegeben werden. Diese Einstellungen entsprechen auch dem
Defaultwert der beiden Attribute.
<xsd:schema
targetNamespace="http://www.hs-esslingen.de/EssListe"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
...
</xsd:schema>
Ein XML Dokument, das sich auf dieses Schema bezieht, muss nun den hier
definierten Namespace ebenfalls benutzen. Dafür ist das Attribut SchemaLocation
vorgesehen. Das entsprechende Instanzdokument sieht damit folgendermaßen aus:
SOFTWARETECHNIK
Einführung in XML
- 81 -
©
Prof. J. Goll
- 6. XML Schema <?xml version="1.0"?>
<lst:Liste
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:lst="http://www.hs-esslingen.de/EssListe"
xsi:SchemaLocation=
"http://www.hs-esslingen.de/EssListe liste.xsd">
Inhalt
</lst:Liste>
Zuerst wird der bereits bekannte Namensraum für Instanzdokumente von XML
Schemas eingeführt. Dann wird der spezielle Namensraum für Esslinger Listen
(http://www.hs-esslingen.de/EssListe) eingeführt mit dem Präfix lst.
Zuletzt wird über das Attribut SchemaLocation der mit dem Präfix lst eingeführte
Namensraum einer Schema Definition zugeordnet, die in der Datei liste.xsd zu
finden ist. D.h. der Wert des Attributes SchemaLocation ist ein Paar bestehend aus
Namespace (URI) und einer Datei (XSD).
6.3 Aufbau einer Schema Definition
Weiter oben war bereits ein erstes Beispiel einer Schema Definition zu sehen.
Wichtig ist, dass im Wurzelelement ein Namespace vergeben wird mit der URI
http://www.w3.org/2001/XMLSchema. Als Präfix wird meist xsd gewählt, der
Name ist allerdings freigestellt. Der Name des Wurzelelements eines Schemas ist
immer <schema>.
... Hier die Schema Definition ...
</xsd:schema>
Eine Schema Definition enthält dann vordefinierte Elemente und Attribute, die
wiederum die Struktur eines anderen Dokumentes beschreiben. Wie die DTD ist also
auch die Schema Definition ein Meta-Dokument.
6.3.1 Definition von Elementen
Eine Schema Definition startet mit der Definition der Elemente, die ein XML
Dokument beinhalten kann. Dabei wird der Tag-Name definiert und der Inhalt des
Elementes typisiert:
<xsd:element name="Datum" type="xsd:date"/>
Das erste Beispiel wurde oben bereits erläutert, das Element Liste enthält Strings
(xsd:string). Diese Definition könnte genau so gut und so präzise in einer DTD
SOFTWARETECHNIK
Einführung in XML
- 82 -
©
Prof. J. Goll
- 6. XML Schema abgefasst werden. Das zweite Beispiel zeigt nun aber eine präzisere Typisierung:
Das Element Datum kann nun nicht mehr beliebige Strings enthalten, sondern nur
noch welche, die dem Typ xsd:date genügen. Der Präfix zeigt an, dass es sich um
einen Typ aus XML Schema selbst handelt. Dort wird beispielsweise definiert, dass
ein Datum vom Typ xsd:date in der Form yyyy-mm-dd geschrieben werden muss.
xsd:date und xsd:string gehören zu den sogenannten vordefinierten Typen
(built-in types), die also in XML Schema selbst definiert sind. Weiter unten ist eine
Übersicht darüber zu finden.
Darüber hinaus können eigene Typen in einer Schema Definition definiert werden.
Bei den Typen unterscheidet man zwischen einfachen Typen (simple types) und
zusammengesetzten Typen (complex types). Sämtliche vordefinierte Typen sind
einfache Typen. Attribute müssen über zusammengesetzte Typen spezifiziert
werden. Zusammengesetzte Typen werden auch benötigt, wenn man die
Schachtelung von Elementen ausdrücken will.
Auf Grund der Forderung der XML Grammatik, dass ein Dokument genau ein
Wurzel-Element haben darf, sind alle anderen Elemente auf irgendeine Weise darin
geschachtelt. Das führt dazu, dass eine Schema Definition auf der obersten Ebene
genau ein Element einführt (das Wurzel-Element), das einen komplexen Typ hat, in
dem die Schachtelung weiterer Elemente spezifiziert wird. Der allgemeine Aufbau
einer Schema Definition folgt damit dem folgenden Muster:
<xsd:element name="myRoot" type="rootType"/>
<xsd:complexType name="rootType">
... Definition der geschachtelten Elemente ...
</xsd:complexType>
... gegebenfalls weitere Typdefinitionen ...
</xsd:schema>
ToDo: mehrere Elemente??
SOFTWARETECHNIK
Einführung in XML
- 83 -
©
Prof. J. Goll
- 6. XML Schema -
6.3.2 Vordefinierte Typen
Die folgende Abbildung zeigt die einfachen Datentypen, welche in XML Schema
definiert sind (built-in) sowie deren Beziehungen untereinander. Alle komplexen
Datentypen müssen selbst definiert werden, aber auch einfache Datentypen können
selbst definiert werden.
Abbildung 6-2: Hierarchie der Built-In Datentypen
SOFTWARETECHNIK
Einführung in XML
- 84 -
©
Prof. J. Goll
- 6. XML Schema -
6.3.3 Definition von einfachen Typen
Einfache Typen entstehen in sogenannten simpleType-Definitionen. In der
einfachsten Form gibt man einem bereits existierenden Typ einfach nur einen
anderen Namen (wie bei einem typedef in C):
<xsd:simpleType name="Test" type="xsd:string"/>
Damit wird ein neuer Typ mit dem Namen Test definiert, der aber nichts anderes ist
als xsd:string. Der neue Name kann selbst wieder in weiteren Typdefinitionen
benutzt werden:
<xsd:simpleType name="Test2" type="Test"/>
Eine solche simpleType-Definition kann noch mit Einschränkungen versehen werden,
die den möglichen Wertebereich des Grundtyps betreffen. Man spricht dann auch
von einem abgeleiteten Typ (derived type), der Mechanismus ist durchaus
vergleichbar mit der Vererbung in objekt-orientierten Sprachen. Die simpleTypeDefinition erhält dann folgende Form:
<xsd:simpleType name="telefonNum">
<xsd:restriction base="xsd:string">
Art der Einschränkung über Facetten
</xsd:restriction>
</xsd:simpleType>
Es wird also angegeben, dass man eine Einschränkung machen will und auf welchen
Typ (base). Als Kind-Elemente des restriction-Elementes können dann die
eigentlichen Einschränkungen (Facetten) spezifiziert werden, die allerdings vom
Grundtyp (base type) abhängen. Mögliche Facetten sind:
•
•
•
•
•
•
•
•
•
•
die Länge (length)
die minimale Länge (minLength)
die maximale Länge (maxLength)
ein Muster (pattern)
eine Aufzählung (enumeration)
maximale Werte (maxInclusive, bzw. maxExclusive)
minimale Werte (minInclusive, bzw. maxInclusive)
Anzahl der Ziffern (totalDigits)
Anzahl der Nachkommastellen (fractionDigits)
Behandlung von Whitespace (whiteSpace)
Einige Beispiele sollen die Möglichkeiten von Facetten zur Typdefinition aufzeigen.
In folgendem Beispiel wird ein neuer Typ definiert, welcher vom Datentyp
xsd:string abgeleitet ist. Der neue Typ wird über den regulären Ausdruck im
Attribut value der Facette pattern eingeschränkt.
SOFTWARETECHNIK
Einführung in XML
- 85 -
©
Prof. J. Goll
- 6. XML Schema -
<xsd:pattern value="\p{Nd}+\-\p{Nd}+"/>
</xsd:restriction>
</xsd:simpleType>
Die regulären Ausdrücke, die hier angegeben werden können, lehnen sich an die
Möglichkeiten von Perl an mit den Unicode-Erweiterungen aus Perl 5.6. Im obigen
Beispiel kommen die folgenden Pattern vor:
Menge der dezimalen Ziffern im Unicode
ein Auftreten eines Zeichens aus der Unicode Menge A
Minuszeichen
Wiederholung des Ausdrucks A 1 bis n mal
Nd
\p{A}
\A+
Weitere häufig gebrauchte Pattern erinnern auch an die Schreibweise für reguläre
Ausdrücke in dem UNIX-Tool lex:
A*
A?
[a-e]
[aeiou]
[^0-9]
.
(A|B)
A{2,4}
Wiederholung des Ausdrucks A 0 bis n mal
Ausdruck A ist optional
Menge der Zeichen a, b, c, d und e
Menge der Zeichen a, e, i, o und u
Komplementärmenge der Zeichen 0 bis 9
irgendein Zeichen
Ausdruck A oder B
Wiederholung des Ausdrucks A mindestens 2 höchstens 4 mal
Eine andere Art von Facette ist die Aufzählung, hier im Beispiel die möglichen Werte
eines Elementes, das einen Medien-Typ besitzt:
<xsd:simpleType name="mediaType">
<xsd:enumeration value="8mm" />
<xsd:enumeration value="vhs" />
<xsd:enumeration value="vhsc" />
<xsd:enumeration value="digital" />
<xsd:enumeration value="audio" />
</xsd:restriction>
</xsd:simpleType>
Ein letztes Beispiel zeigt die Einschränkung des Wertebereiches bei ganzen Zahlen
auf das Intervall [1,9999]:
<xsd:simpleType name="myNumber">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="1" />
<xsd:maxInclusive value="9999" />
</xsd:restriction>
</xsd:simpleType>
SOFTWARETECHNIK
Einführung in XML
- 86 -
©
Prof. J. Goll
- 6. XML Schema Wie bereits erwähnt hängen die erlaubten Facetten vom Grundtyp ab. So macht es
etwa keinen Sinn, für Strings einen Min- oder Max-Wert zu definieren, bzw. für eine
ganze Zahl ein Muster anzugeben.
Die so entstandenen neuen einfachen Typen können wie die built-in Typen
verwendet werden. D.h. sie können zur Definition eines Elements verwendet werden:
<xsd:element name="newNumber" type="myNumber"/>
oder, wie im folgenden Beispiel in einer Typdefinition weiter eingeschränkt werden.
<xsd:simpleType name="yourNumber">
<xsd:restriction base="myNumber">
</xsd:restriction>
</xsd:simpleType>
Aus dem Typ myNumber wird der Typ yourNumber mit einem noch kleineren
Intervall.
6.3.4 Lokale, Globale und Anonyme Typen
In den bisherigen Beispielen wurden die neuen Typen immer mit einem Namen
versehen. Über diesen Namen können sie dann in Element- oder
Attributdeklarationen verwendet werden.
<xsd:simpleType name="myNumber">
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="newNumber" type="myNumber"/>
Ist die Definition (hier das simpleType-Element) ein direkter Abkömmling des
schema-Elementes, dann spricht man von einer globalen Deklaration und der
Typname ist praktisch überall sichtbar.
Globale Deklarationen wird man dann benutzen, wenn ein Typ häufig vorkommt,
beispielsweise haben Attribute häufig den gleichen Typ. Im folgenden Beispiel wird
der Typ nameType eingeführt und hinterher für die Elemente Name und Vorname
benutzt. Die Bedeutung von komplexen Typen und vom sequence-Element wird
weiter unten erläutert.
SOFTWARETECHNIK
Einführung in XML
- 87 -
©
Prof. J. Goll
- 6. XML Schema <xsd:simpleType name="nameType">
...
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="VorundNachname>
<xsd:sequence>
<xsd:element name="Vorname" type="nameType"/>
<xsd:element name="Nachname" type="nameType"/>
</xsd:sequence>
</xsd:complexType>
Auch dieser neu entstandene komplexe Typ wäre ein globaler Typ, wenn er direkter
Abkömmling des schema-Elementes wäre.
Ist eine Typdefinition tiefer in der Schema-Definition eingebettet, also nicht direkter
Abkömmling des schema-Elementes, dann spricht man von lokalen Definitionen.
Lokale Namen sind nur auf der gleichen Ebene oder in noch tiefer liegenden
Unterbäumen sichtbar. Somit kann man eine gewisse Lokalität von Namen erreichen,
was sicher für umfangreiche Schema Definitionen wichtig ist. Lokale Namen spielen
in dieser Einführung keine Rolle.
Viele Strukturen wird es in einer Schema Definition genau einmal geben. In diesen
Fällen braucht man sich keinen Namen zu überlegen und sich nicht um die Frage
lokal oder global zu kümmern, sondern man kann die Typdefinition genau dort
einfügen, wo sie gebraucht wird, ohne ihr einen Namen zu geben. Man spricht von
anonymen Typen. Sie können dann aber natürlich auch nicht wieder verwendet
werden. Das einleitende Beispiel zu diesem Abschnitt könnte mit einem anonymen
Typ folgendermaßen formuliert werden:
<xsd:element name="newNumber">
<xsd:simpleType>
</xsd:restriction>
</xsd:simpleType>
<xsd:element/>
Eingeschlossen in die element-Definition ist nun eine simpleType-Definition ohne
Namen. Beispiele für die Verwendung solcher anonymen Typen sind im Folgenden
häufig zu finden.
6.3.5 Definition komplexer Typen
Eine der Restriktionen von einfachen Typen ist, dass diese Elemente keine Attribute
haben können. Ebenso können Elemente von einfachen Typen keine Kind-Elemente
haben. In beiden Fällen muss man komplexe Typen definieren.
SOFTWARETECHNIK
Einführung in XML
- 88 -
©
Prof. J. Goll
- 6. XML Schema Die einfachste Art, um Attribute zu definieren, besteht darin, der Element-Definition
noch eine complexType-Definition hinzuzufügen:
<xsd:element name ="telefon">
<xsd:complexType>
<xsd:attribute name="Anschluss" type="xsd:string"/>
<xsd:attribute name="Netz" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
In diesem Falle wurde ein sogenannter anonymer Typ definiert, denn der komplexe
Typ im Inneren der Element-Definition hat keinen Namen. Natürlich kann auch ein
komplexer Typ benannt werden und damit über den Namen an anderen Stellen
wieder benutzt werden:
<xsd:complexType name="telefonType">
<xsd:attribute name="Anschluss" type="xsd:string"/>
<xsd:attribute name="Netz" type="xsd:string"/>
</xsd:complexType>
Mit komplexen Typen können also Elemente definiert werden, die Struktur (also
geschachtelte Elemente) und/oder Attribute besitzen. Mit einfachen Typen hingegen
können nur Elemente beschrieben werden, die einen einfachen Text als Inhalt
haben. Die verschiedenen Möglichkeiten von komplexen Typen werden nun in den
folgenden Abschnitten beschrieben
6.3.6 Hierarchie der Elemente
Wenn man eine Hierarchie von Elementen definieren will, dann geht das ebenfalls
über complexType-Definitionen. Im Wesentlichen kann man dabei vier Fälle
unterscheiden: Folgen von Elementen (sequence), Auswahl zwischen mehreren
Möglichkeiten (choice), Wiederholungen (occurs) und Mengen (all), bei denen
die Reihenfolge keine Rolle spielt.
Um auszudrücken, dass ein Element ein oder mehrere Kind-Elemente haben kann,
definiert man einen komplexen Typ (auch hier wieder der Einfachheit halber
anonym), in dem die möglichen Elemente der Reihenfolge nach aufgezählt werden in
einer sogenannten sequence-Definition:
<xsd:element name="Name">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Anrede"
type="xsd:string"/>
<xsd:element name="Vorname" type="xsd:string"/>
<xsd:element name="Nachname" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Ein Element Name enthält Kind-Elemente mit den Tag-Namen Anrede, Vorname,
Nachname. Sie müssen auch in dieser Reihenfolge erscheinen.
SOFTWARETECHNIK
Einführung in XML
- 89 -
©
Prof. J. Goll
- 6. XML Schema -
Leider benötigt man schon im einfachen Fall, dass ein Element in einem anderen
geschachtelt auftreten kann, eine sequence-Definition in einem komplexen Typ.
Während die sequence-Definition alle möglichen Kind-Elemente aufzählt und ihre
Reihenfolge festlegt, kann mit Hilfe der choice-Definition eine Auswahl unter
Alternativen spezifiziert werden:
<xsd:element name="Adressenteil">
<xsd:complexType>
<xsd:choice>
<xsd:element name="Postfach"
<xsd:element name="Strasse"
</xsd:choice>
</xsd:complexType>
</xsd:element>
type="xsd:string"/>
type="xsd:string"/>
In einem solchen Adressenbestandteil kann entweder nur das Postfach oder die
Strasse erscheinen.
Oft gibt es Elemente, die optional sind oder mehrfach auftreten können, von denen
die Häufigkeit des Auftretens bekannt sein kann oder nicht. Dies kann durch
occurs-Zusätze bei der Element-Deklaration spezifiziert werden:
<xsd:complexType name="TelefonType">
<xsd:sequence>
<xsd:element name="Nummer" type="telefon"
minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
Das Element mit dem Namen Nummer muss mindestens einmal erscheinen, es kann
beliebig oft (unbounded) erscheinen.
<xsd:complexType name="AdresseType">
<xsd:sequence>
<xsd:element name="Name"
type="NameType"
minOccurs="1"
maxOccurs="1"/>
<xsd:element name="Telefon"
type="TelefonType"
minOccurs="0"
maxOccurs="1"/>
<xsd:element name="Email"
type="EmailType"
minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
Die Elemente Telefon und Email sind optional, während der Name genau einmal
erscheinen muss. Letzteres kann natürlich einfacher ausgedrückt werden: wenn
keine Wiederholung angegeben wird, wie in den ersten Beispielen zu sehen. Denn
SOFTWARETECHNIK
Einführung in XML
- 90 -
©
Prof. J. Goll
- 6. XML Schema die Defaultwerte für beide Attribute sind 1 und diese Kombination bedeutet ja gerade,
dass das Element genau einmal vorkommen muss.
Eine weitere Möglichkeit den Inhalt eines Elementes zu beschreiben, ist das allElement. Alle Elemente in der Gruppe können einmal oder gar nicht auftreten, und
zwar in beliebiger Reihenfolge. Die Kind-Elemente dürfen nur einzeln auftreten, d.h.
wenn maxOccurs steht, muss es den Wert 1 haben. minOccurs kann den Wert 0
haben, wenn das Element optional ist.
<xsd:all>
type="NameType"/>
<xsd:element name="Telefon"
type="TelefonType"/>
<xsd:element name="Email"
type="EmailType"/>
</xsd:all>
</xsd:complexType>
6.3.7 Geschachtelte Elemente und Attribute
Wenn ein Element sowohl geschachtelte Elemente und Attribute haben kann, können
in der Definition des komplexen Typs für ein solches Element neben der HierarchieDefinition auch Attribut-Definitionen stehen:

<xsd:sequence>
<xsd:element name="Name" type="NameType"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="Telefon" type="TelefonType"
<xsd:element name="Email" type="EmailType"
</xsd:sequence>
<xsd:attribute
name="Art" type="EintragsArt">
</xsd:complexType>
Das Beispiel geht über das ursprüngliche Adressbuch hinaus und würde es erlauben,
dass man die Einträge nach ihrer Art, etwa privat und beruflich, unterscheiden kann.
Dazu dient das Attribut Art, das in der complexType-Definition zu finden ist.
SOFTWARETECHNIK
Einführung in XML
- 91 -
©
Prof. J. Goll
- 6. XML Schema -
6.3.8 Komplexe Typen für gemischten Inhalt
In den bisherigen Beispielen gab es die Einschränkung, dass ein Element entweder
nur Attribute oder nur Kind-Elemente besitzt, oder beides, aber es konnte
insbesondere keinen eigenen Inhalt haben.
Um innerhalb eines Elements sowohl Text als auch Subelemente als Inhalt zu
erlauben, wird bei der Definition des complexType das Attribut mixed auf true
gesetzt.
<xsd:element name="Adresse">
<xsd:complexType mixed="true">
<xsd:sequence>
type="xsd:string"/>
<xsd:element name="Telefon" type="xsd:string"/>
<xsd:element name="Email" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Ein Dokument kann damit wie folgt aussehen:
<Adresse>
Hier kann jetzt beispielsweise irgendein text stehen
<Name> Manfred Mustermann </Name>
oder hier <Telefon> 0815-4711 </Telefon> oder hier
<Email>[email protected]</Email>
oder auch noch hier.
</Adresse>
6.3.9 Erweiterungen und Einschränkung von komplexen Typen
Neben den einfachen Typen können auch komplexe Typen eingeschränkt, oder aber
auch erweitert werden. Darauf kann in dieser Einführung nicht eingegangen werden.
6.3.10 Dokumentation eines Schemas
Um die Lesbarkeit und die Verständlichkeit eines Schemas zu erhöhen, kann ein
Schema-Dokument auch mit Hinweisen und Kommentaren versehen werden. XML
Schema stellt dazu das xsd:annotation Element zur Verfügung.
Für Erklärungen, die von Menschen gelesen werden sollen, wird das
documentation-Element empfohlen. Für Hinweise, die von verarbeitenden
Programmen gelesen werden sollen, wird das appinfo-Element verwendet.
SOFTWARETECHNIK
Einführung in XML
- 92 -
©
Prof. J. Goll
- 6. XML Schema <xsd:annotation>
<xsd:documentation>
Beispiel fuer eine Dokumentation
</xsd:documentation>
<xsd:appinfo>
use Adressbuch.xsl to transform
</xsd:appinfo>
</xsd:annotation>
6.4 XML Schema Beispiel
Das folgende Schema ist in der Datei Adressbuch.xsd enthalten und beschreibt
die gleichen Adressbuchdokumente, die bisher durch Adressbuch.dtd
beschrieben wurden.

<xsd:element name="Adressbuch" type="AdressbuchType"/>

<xsd:complexType name="AdressbuchType">
<xsd:sequence>
<xsd:element
name="Adresse" type="AdresseType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:sequence>
<xsd:element
name="Name"
type="NameType"/>
<xsd:element
name="Telefon" type="TelefonType/>"
<xsd:element
name="Email"
type="EmailType"
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="NameType">
<xsd:sequence>
<xsd:element
name="Anrede"
type="xsd:string"
<xsd:element
name="Vorname" type="xsd:string"/>
<xsd:element
name="Nachname" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
SOFTWARETECHNIK
Einführung in XML
- 93 -
©
Prof. J. Goll
- 6. XML Schema 
<xsd:complexType name="TelefonType">
<xsd:sequence>
<xsd:element
name="Nummer" type="NummerType"
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="EmailType">
<xsd:sequence>
<xsd:element
name="Emailadresse" type="xsd:string"
</xsd:sequence>
</xsd:complexType>

<xsd:simpleType name="AnschlussType">
<xsd:enumeration value="privat"/>
<xsd:enumeration value="mobil"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="NummerType">
<xsd:simpleContent>
<xsd:extension base="telefonNum">
<xsd:attribute name="Anschluss" use="required"
type="AnschlussType"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>

<xsd:pattern value="\p{Nd}+\-\p{Nd}+"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
SOFTWARETECHNIK
Einführung in XML
- 94 -
©
Prof. J. Goll
- 6. XML Schema -
6.5 XML Binding for Java
JAXB (XML Binding for Java) ist eine von SUN implementierte weitere Variante zur
Bearbeitung von XML Dokumenten in Java. JAXB ermöglicht es aufgrund eines XML
Schemas Java-Klassen zu erstellen, die dessen Struktur nachbilden. Wurden diese
Java-Klassen erstellt, können XML Dokumente, die dem zugrunde liegenden XML
Schema gehorchen, in die Java-Klassen eingelesen werden und dort, im Vergleich
zu DOM, sehr komfortabel und einfach bearbeitet werden.
JAXB ist im Paket JAXB verfügbar und kann somit in jedem Java JDK seit 1.4
benutzt werden.
6.5.1 Arbeitsweise von JAXB
Bevor eine XML-verarbeitende Applikation in JAXB erstellt werden kann, müssen
zunächst die Klassen generiert werden, die das XML Dokument später
repräsentieren. Für die Erstellung dieser Klassen wird zunächst ein XML Schema
benötigt, dem das später zu bearbeitende XML Dokument gehorcht. D.h. für jedes
Schema, also für jede XML Dokumentenklasse, gibt es einen eigenen Satz von
Klassen, mit denen man Instanzdokumente bearbeiten kann. DOM ist dagegen ein
allgemeines Interface, das es erlaubt, alle XML Dokumente zu verarbeiten.
Das folgende Bild aus [HoUl01] zeigt die prinzipielle Arbeitsweise von JAXB:
Abbildung 6-3: Arbeitsweise von JAXB
Benötigt wird demnach ein Schema Compiler, der aus dem Ausgangsschema eine
Menge von abhängigen Klassen generiert, sowie ein Binding Framework, auf
welchem die erzeugten Klassen aufbauen. Die vom Binding Framework
bereitgestellten Klassen implementieren grundlegende Operationen wie das Lesen
(unmarshal) und Speichern (marshal) von XML Dokumenten, also die Abbildung von
Instanzen der erzeugten Klassen auf XML Dokumente und umgekehrt, sowie das
Validieren der Objekte und Dokumente.
SOFTWARETECHNIK
Einführung in XML
- 95 -
©
Prof. J. Goll
- 6. XML Schema -
6.5.2 Aufbau der generierten Klassen
Um den Aufbau der generierten Klassen zu zeigen, wird wieder das Beispiel des
Adressbuches verwendet. In der Adressbuch-Schema-Definition werden insgesamt
fünf
ComplexTypes
(AdressbuchType,
AdresseType,
NameType,
TelefonType, EmailType) definiert. Aus jedem dieser ComplexTypes wird
jeweils ein Interface generiert. Jedes dieser Interfaces definiert get- und setMethoden, mit denen die Unterelemente eines solchen ComplexTypes geholt oder
gesetzt werden können. Auch für jedes Attribut eines ComplexTypes werden set- und
get-Methoden erstellt.
Hier folgt als Beispiel das generierte Interface für AdresseType:
//AdresseType.java
import generated.*;
public interface AdresseType {
generated.EmailType getEmail();
void setEmail(generated.EmailType value);
generated.TelefonType getTelefon();
void setTelefon(generated.TelefonType value);
generated.NameType getName();
void setName(generated.NameType value);
}
Hier werden die Schnittstellen definiert, mit denen der Programmierer die Möglichkeit
hat ein AdresseType-Element zu bearbeiten. Bei get-Methoden wird jeweils ein
Objekt des jeweiligen Subelements zurückgegeben, für die ja ebenfalls Klassen und
Interfaces erzeugt wurden. Bei den set-Methoden wird jeweils ein Objekt des
jeweiligen Subelements als Parameter übergeben.
Ein weiteres Beispiel zeigt die Umsetzung des Wurzelelements, also das zu
AdressbuchType generierte JAXB-Interface:
//AdressbuchType.java
import generated.*;
public interface AdressbuchType {
java.util.List getAdresse();
}
Ein AdressbuchType-Element ist aus einer unbestimmten Anzahl an
Unterelementen des Typs AdressseType aufgebaut. Das Adressbuch kann also
SOFTWARETECHNIK
Einführung in XML
- 96 -
©
Prof. J. Goll
- 6. XML Schema eine unbestimmte Anzahl an Einträgen beinhalten. In dem Interface wird nun lediglich
die get-Methode getAdresse() definiert, die ein List-Objekt als Rückgabewert
besitzt. Über diese Methode kann sich der Programmierer die Liste aller bereits in
das Adressbuch eingetragenen Adressen holen um diese auszulesen oder zu
bearbeiten. Diese Liste beinhaltet Objekte der Klasse AdresseType, die jeweils eine
einzelne Adresse darstellen. Um eine neue Adresse anzuhängen muss lediglich mit
den in Java bekannten List-Methoden ein AdresseType-Objekt in die Liste
eingefügt werden.
Die generierten Interface-Klassen der restlichen ComplexType-Elemente sind nach
demselben Muster mit set- und get-Methoden aufgebaut. Diese Methoden sind die
einzigen Methoden, die ein Programmierer zur Bearbeitung eines XML Dokuments
benötigt. Dies macht die Programmierung recht einfach, da fast ausschließlich
klassische Java-Kenntnisse über die Arbeit mit Klassen und deren set- und getMethoden sowie die Arbeit mit Listen benötigt werden. Spezifische JAXB-Klassen
und Methoden kommen nur recht selten zum Einsatz und sind zudem nicht sehr
komplex. Im Folgenden werden die wichtigsten Klassen erläutert.
6.5.3 JAXB-API
Die JAXB-API stellt das eigentliche Binding Framework dar. Die wichtigsten Klassen
und Interfaces der JAXB-API befinden sich im Paket javax.xml.bind.*. Im Einzelnen
sind dies:
•
Interface Unmarshaller: In diesem Interface werden alle für den UnmarshallerVorgang notwendigen Methoden definiert. Unter diesem Vorgang versteht man
das Einlesen von XML-Daten in die von JAXB erstellten Klassen.
•
Interface Marshaller: In diesem Interface werden alle für den MarshallerVorgang notwendigen Methoden definiert. Unter diesem Vorgang versteht man
die Ausgabe der XML-Daten aus den von JAXB erstellten Klassen.
•
Interface Validator: Im Gegensatz zur Validierung beim Einlesen der XML-Daten
gibt es in JAXB auch die Möglichkeit der sogenannten. On-Demand Validation.
Dabei können während der Laufzeit der JAXB-Applikation, die in den JAXBKlassen befindlichen Daten gegen die Schema-Defnition validiert werden. Für
diese Zwecke benötigt man eine Instanz des Interfaces Validator.
•
Die abstrakte Klasse JAXBContext: Mit dieser Klasse lassen sich Instanzen der
Interfaces Marshaller, Unmarshaller und Validator erstellen. Sie bildet daher die
Basis einer jeden JAXB-Applikation.
SOFTWARETECHNIK
Einführung in XML
- 97 -
©
Prof. J. Goll
- 6. XML Schema -
6.5.4 Bewertung
Einer der Vorteile von JAXB ist, dass der Programmierer, nachdem die XML Daten in
die Java-Klassen eingelesen wurden, fast ausschließlich die recht einfach zu
durchschauenden Methoden der erstellten Klassen benutzen kann um sein XML
Dokument zu bearbeiten. Die JAXB eigenen Methoden aus der JAXB-API müssen
nur recht selten verwendet werden. Somit muss der Programmierer sich nicht erst
langwierig in eine neue API und Vorgehensweise einarbeiten, sondern kann auf
seine bekannten Programmierkenntnisse zurückgreifen. Außerdem muss der
Programmierer über keine großen XML Kenntnisse verfügen. Beispielapplikationen
mit dem Adressbuch wurden im Rahmen einer Studienarbeit [Tri03] entworfen und
mit dem Vorgehen in DOM und SAX verglichen.
Ein weiterer Vorteil von JAXB liegt in der Validierung der Daten. Es ist jederzeit
möglich die im Speicher befindlichen Daten zu validieren, also nicht nur beim
Einlesen, wie bei DOM und SAX. Bei DOM Level 3 ist das inzwischen allerdings auch
möglich.
Ein Nachteil von JAXB ist, dass die JAXB-Klassen lediglich aufgrund von SchemaDefinitionen erstellt werden können. Es ist also nicht möglich mit den etwas
einfacheren DTDs zu arbeiten. Ansätze für XML Bindings basierend auf DTDs sind
allerdings auf dem Markt verfügbar [HoUl01].
6.6 Zusammenfassung
XML Schema bringt unter anderem folgende Features, die die Einschränkungen von
DTDs überwinden:
•
•
•
•
•
Datentypen
Mächtigere Strukturierungsmöglichkeiten mit abstrakten Typen
Bedingte Teilstrukturen
Minimale/Maximale Vorkommen für Elemente
Kardinalität
Leider führen diese neuen Möglichkeiten auch dazu, dass Definitionen mit XML
Schema deutlich komplexer ausfallen als DTDs. Die Komplexität und die neuen
Möglichkeiten haben auch Auswirkungen auf die Performance beim Arbeiten mit
XML Dokumenten.
In einer Studienarbeit [Book02] wurde ein Performance-Vergleich durchgeführt, um
die zeitlichen Auswirkungen bei einer Validierung von XML Dokumenten gegen XML
Schema Definitionen statt gegen Document Type Definitions zu untersuchen.
Dieser Performance-Test erbrachte folgende Erkenntnisse: Bei der Validierung
ergeben sich gravierend verlängerte Parse-Zeiten, wenn eine Validierung gegen eine
XML Schema Definition erfolgen soll. Der Faktor, um den sich die Parse-Zeit eines
Dokumentes gegenüber einer Validierung gegen eine DTD vergrößert, liegt zwischen
2 und 3 (in Abhängigkeit von der Größe des jeweils geparsten XML Dokumentes).
SOFTWARETECHNIK
Einführung in XML
- 98 -
©
Prof. J. Goll
- 6. XML Schema Auf Grund der gegenüber DTDs erweiterten Sprachmittel der XSDs ist der
Validierungsaufwand bei XSDs von Natur aus höher. Bei dem genannten Faktor
lohnt sich allerdings eine Überlegung, ob unbedingt gegen eine XML Schema
Definition validiert werden muss oder ob eine Validierung gegen eine DTD nicht doch
ausreichend ist.
Unter diesem Hintergrund werden Schema Definitionen auf Grund ihrer Präzision
und ihrer Möglichkeiten häufig nur für eine genaue Beschreibung benutzt, quasi als
Schnittstellen-Dokumentation, während für die Validierung eine DTD bereitgestellt
wird. Bei verlässlichen Quellen (z.B. aus getesteten Software-Systemen) kann man
sich sogar auf eine reine well-formed-Prüfung ohne DTD beschränken.
SOFTWARETECHNIK
Einführung in XML
- 99 -
©
Prof. J. Goll
- 7. Linking in XML -
7 Linking in XML
7.1 Übersicht
XML unterstützt ein wesentlich weitergehendes Linking, als es von HTML bekannt ist.
Das W3C entwickelte ein Linking-Modell für XML, das aus XML Linking Language
(XLink) und XML Pointer Language (XPointer) besteht. Das Modell soll neben
unidirektionalen Links (wie sie heute in HTML verwendet werden) auch
multidirektionale Links, die auf mehrere Ressourcen gleichzeitig verweisen, und
bidirektionale Links, die in beide Richtungen referenzieren, unterstützen.
XLink spezifiziert neben den aus HTML bekannten einfachen, unidirektionalen Links
auch erweiterte Links. Diese erweiterten Links eröffnen die Möglichkeit, gleichzeitig
auf mehrere andere Dokumente oder Dateien zu verweisen. Die referenzierten
Dokumente öffnen sich dann z.B. bei einem Webbrowser wahlweise alle in einem
Browserfenster oder in getrennten Fenstern. Daneben sind in der XLink-Spezifikation
auch bidirektionale Links vorgesehen, die in beide Richtungen referenzieren können.
Hinzu kommt noch die Möglichkeit, Links außerhalb des Dokumentes, zu dem sie
gehören, verwalten zu können.
XPointer stellen daneben ein weiteres mächtiges Modell für das Linking in XML
Dokumenten dar. Mit XPointer ist es möglich, auf bestimmte Elemente einer XML
Instanz zu verweisen und zuzugreifen. Es wird ermöglicht, direkt auf der
Baumstruktur eines XML Dokumentes zu navigieren. Mit XPointer hat man somit
auch die Möglichkeit, ähnlich wie mit SQL, Abfragen aus Datenbeständen
vorzunehmen.
Abbildung 7-1: Linking in XML
Ein XML Dokument kann unabhängig von seiner logischen Struktur aus beliebig
vielen physischen Einheiten bestehen. Dies ermöglicht es – im Zusammenspiel von
XLink und XPointer – in einem Netzwerk verteilte Daten zu einem einzigen XML
Dokument zusammenzufügen. Die Möglichkeiten dieser Linking-Modelle sind noch
SOFTWARETECHNIK
Einführung in XML
- 100 -
©
Prof. J. Goll
- 7. Linking in XML weit vielfältiger, allerdings zeigen bereits diese Ausführungen die Mächtigkeit der
Linking-Möglichkeiten in XML.
Die W3C-Recommendations zu XPointer und XLink detailliert zu beleuchten würde
zu weit führen, darum sollen hier lediglich die Grundfunktion der Spezifikationen und
die bedeutendsten Features aufgezeigt werden.
7.2 XLink
Xlink stellt eine Menge von Attributen zur Verfügung, die bei allen Elementen stehen
können, um einen Link zu beschreiben. Der Namespace für diese Attribute ist
http://www.w3.org/1999/xlink. Meist wird als Präfix xlink verwendet, was
aber wie bereits bekannt nicht zwingend ist.
Hier nun eine Übersicht über diese Attribute:
type
gibt den Typ des XLink-Elementes an.
href
gibt die URI an, unter der die Ressource gefunden werden kann.
role
spezifiziert die Funktion des Links in einer maschinen-lesbaren Form.
title
spezifiziert die Funktion des Links in einer menschen-lesbaren Form.
show
gibt an, wie die Ressource angezeigt wird, wenn sie gefunden ist.
actuate
gibt an, wann die Ressource gesucht werden soll.
from, to
spezifizieren die Link-Richtung, da die Xlinks nicht notwendigerweise
unidirektional sind.
Welches Attribut überhaupt benutzt werden kann, hängt vom type ab, den man
gewählt hat. Es gibt insgesamt 6 Typen von Links:
simple, extended, locator, arc, resource und title.
Simple Links und Extended Links definieren die eigentlichen Links, während die
anderen benutzt werden im Kontext eines Extended Links, um zusätzliche
Information über den Link zur Verfügung zu stellen.
SOFTWARETECHNIK
Einführung in XML
- 101 -
©
Prof. J. Goll
- 7. Linking in XML Die einfachste Art eines XLinks ist somit gar nicht sehr verschieden von einem HTML
Link:
<Adresse>
...
<picture xlink:type="simple"
xlink:href="picture.jpg"
xlink:actuate="onRequest"
xlink:show="embed"
xlink:title="Click to see picture!">
Click here to see a picture!
</picture>
</Adresse>
Auf diese Art könnte man in das Adressbuch auch Links auf Bilder der Leute
einbauen. In diesem Beispiel erscheint das Bild allerdings nur, wenn auf den Text
des Elementes picture, nämlich Click here to see picture! geclickt wird.
Der Text wird dann durch das Bild ersetzt. Dieses Verhalten wird durch die
entsprechenden Attributwerte von actuate und show herbeigeführt.
Die insgesamt möglichen Attributwerte sowie die komplexen Extended Links müssen
bei Bedarf nachgeschlagen werden.
7.3 XPointer
Mit XLinks kann man auf beliebige Dokumente, nicht nur auf XML Dokumente,
verweisen. Manchmal möchte man jedoch auf ein ganz bestimmtes Teil,
bespielsweise ein Kapitel oder eine Textstelle in einem anderen Dokument
verweisen. Dazu dient XPointer, allerdings mit der Einschränkung, dass XPointer nur
auf Teile eines XML Dokumentes verweisen kann.
XPointer definiert sogenannte XPointer Ausdrücke, die an einen URI angehängt
werden können, sodass sie damit im Kontext von Links (href) benutzt werden
können. Anstatt auf das Adressbuch in ab.xml zu verweisen, ist es mit XPointer
möglich auf das Name-Element in dieser Datei zu verweisen, bei dem der Vorname
gleich "Max" ist.
Diese Ausdrücke basieren auf XPath. Alle Knoten, die über XPath Ausdrücke
erreichbar sind, können auch in XPointer adressiert werden. Dazu kommen aber
noch einzelne Punkte und ganze Bereiche in einem XML Dokument.
Die Syntax von XPointer wird an folgendem Beispiel ersichtlich:
http://www.hs-esslingen.de/ab.xml#xpointer(//Vorname)
Der URI zeigt auf die Datei ab.xml, daran angehängt ist nun ein XPointer Ausdruck
in den Klammern, in diesem Fall ein einfacher XPath Ausdruck //Vorname. Eine
SOFTWARETECHNIK
Einführung in XML
- 102 -
©
Prof. J. Goll
- 7. Linking in XML Xpointer-Applikation ist dann nur noch mit Vorname-Elementen aus dem Adressbuch
beschäftigt.
Diese Konstruktion kann in Zusammenhang mit einem Link benutzt werden:
<AlleVornamen xlink:type="simple"
xlink:href=
"http://www.hs-esslingen.de/ab.xml#xpointer(//Vorname)"
xlink:actuate="onLoad"
xlink:show="embed"
xmlns:xlink="http://www.w3.org/1999/xlink"/>
In diesem Fall würde beim Laden alle Vorname-Elemente aus der Datei ab.xml in
das AlleVornamen-Element eingefügt.
Im Unterschied zu HTML braucht man aber hier das XML Dokument ab.xml nicht zu
verändern. In HTML müsste man in ab.xml einen Anker mit <a> einbauen, auf den
man sich in einer URL beziehen kann. Das ist aber eine ganz wichtige Eigenschaft,
dass man das Dokument, auf das man sich beziehen möchte, nicht ändern braucht.
Oft kann man es ja auch gar nicht ändern, weil es einem gar nicht gehört.
XPointer dient zur Lokalisation von Sub-Ressourcen in XML Dokumenten und
ermöglicht Links in XML Dokumente hinein, auch in das eigene. Es kann im XML
Baum suchen, kann Knoten des Baumes adressieren, kann Teile von Elementen
adressieren und kann Abschnitte im Text addressieren. Es geht weit über das
URL#nnn-Konzept von HTML hinaus. Auch hier wird für Einzelheiten auf
Fachliteratur verwiesen.
ToDo: Zusammenfassung
SOFTWARETECHNIK
Einführung in XML
- 103 -
©
Prof. J. Goll
- 8. Web Services -
8 Web Services
Hinter Web Services steht die Idee, bereits vorhandene, offene Technologien
zusammenzufassen und für die Kommunikation zwischen Anwendungen und
Anwendungsteilen zu nutzen. Bereits bestehende Anwendungen sollen mit geringem
Aufwand integriert werden können. Es existieren eine Reihe von anderen
Technologien wie etwa CORBA oder DCOM, die ebenfalls für die Integration von
Anwendungen entwickelt wurden. Diese Technologien sind jedoch häufig auf
bestimmte Plattformen beschränkt, oder kompliziert zu implementieren.
Mit Web Services können Service-orientierte Architekturen verwirklicht werden, d.h.
es stehen nicht mehr Anwendungen im Vordergrund, sondern Dienste. Diese Dienste
lassen sich sowohl innerhalb eines Unternehmens, als auch zwischen Unternehmen
anbieten und verwenden. Web Services stellen solche Dienste dar. Sie sind zudem
auf den Einsatz im Web optimiert. Als weiteres Merkmal werden Web Services nur
durch ihre Schnittstelle beschrieben, die Implementierung bleibt dem Nutzer
verborgen.
Zu diesem Zweck existiert eine eigene Beschreibungssprache, WSDL (Web Service
Description Language). Diese Beschreibungssprache basiert auf XML. Da XML leicht
zu parsen ist, kann aus WSDL Dokumenten leicht automatisch Programmcode
erzeugt werden, um den Entwicklungsprozess zu beschleunigen und Fehler zu
vermeiden.
Web Services verwenden häufig SOAP (Simple Object Access Protocol) als Protokoll
für den Datenaustausch, auch SOAP basiert auf XML. Da für nahezu alle Plattformen
SOAP Implementierungen vorhanden sind oder entwickelt werden können, ist damit
die Plattform-Unabhängigkeit gewährleistet. Sogar für mobile Geräte wie zum
Beispiel Handys gibt es SOAP Implementierungen. Das Transportprotokoll für SOAP
ist nicht festgelegt, doch meistens wird für Web Services HTTP verwendet.
Um sowohl eigene als auch von anderen Unternehmen angebotene Web Services
leicht finden zu können, ist UDDI (Universal Description, Discovery and Integration)
entwickelt worden. UDDI sind die gelben Seiten der Web Service Welt, hier kann ein
Unternehmen die von ihm angebotenen Services publizieren, die andere dann
nutzen können. UDDI basiert ebenfalls auf XML.
Beispielsweise bietet der Suchdienst Google [GOO] seine Suchfunktion auch als
Web Service an. Dieser Dienst kann von Entwicklern genutzt werden, die InternetSuchfunktionen in ihre Programme integrieren wollen. Ein weiteres Beispiel für einen
Web Service bietet die Nasdaq (Ein US Aktienmarktplatz). Dort können aktuelle
Börsenkurse per Web Service abgefragt werden. Dieser Service lässt sich
beispielsweise in einem Programm zur Depotverwaltung integrieren.
SOFTWARETECHNIK
Einführung in XML
- 104 -
©
Prof. J. Goll
- 8. Web Services Web Services haben also die folgenden Eigenschaften:
•
•
•
Selbstbeschreibend (mit WSDL)
Plattform-unabhängig (durch SOAP als Datenprotokoll)
Lokalisierbar (mit UDDI)
Auf diese 3 Technologien wird nun im Folgenden eingegangen.
Eine gute Übersicht über Web Services mit praktischen Anwendungen ist in
[Schu2003] zu finden. Die folgenden Auschnitte und insbesondere die Beispiele sind
daraus entnommen.
8.1 Web Service Description Language – WSDL
Ein wichtiges Prinzip in der Softwareentwicklung, speziell bei verteilten
Anwendungen, ist der Interface-getriebene Entwurf. Dabei werden Schnittstellen
vereinbart, gegen die implementiert wird. Um diese Schnittstellen zu beschreiben,
wird bei Web Services eine auf XML basierende Sprache eingeführt – WSDL. Bei
anderen Technologien gibt es ähnliche Ansätze, etwa IDL bei CORBA. Die WSDL
Spezifikation ist erreichbar im Internet [WSDL].
WSDL kann automatisch ausgewertet werden, damit können zum einen
Überprüfungen durchgeführt werden, zum anderen kann Code generiert werden.
Dies geschieht in der Regel zur Entwicklungszeit eines Web Services oder eines
Web Services Clienten, es gibt aber auch Ansätze für sog. dynamische oder stubless
Web Services, bei denen WSDL zur Laufzeit ausgewertet wird. Das WSIF (Web
Service Invocation Framework) Toolkit bietet zum Beispiel die Möglichkeit Web
Services Clients zu entwickeln, die dynamisch auf Schnittstellenänderungen
reagieren. Weitere Informationen zu WSIF gibt es unter [WSIF].
8.1.1 Aufbau eines WSDL Dokuments
Ein WSDL Dokument enthält die folgenden Elemente:
•
•
•
•
•
•
•
Typen
Nachrichten
Operationen
Port Typen
Bindings
Ports
Services
Diese Elemente referenzieren sich gegenseitig. Ein Service kann z.B. auf Basis
mehrerer Binding-Elemente definiert werden. Komplexe Datentypen können
geschachtelt werden, dabei wird auf den inneren Typ verwiesen, ohne dass dieser
nochmals beschrieben wird. Die einzelnen Elemente werden nachfolgend an einem
Beispiel beschrieben.
SOFTWARETECHNIK
Einführung in XML
- 105 -
©
Prof. J. Goll
- 8. Web Services -
8.1.2 WSDL Beispiel
Das folgende Beispiel zeigt das WSDL Dokument für einen Service, der komplexe
Datentypen enthält. Ein WSDL Dokument baut auf XML auf, und muss deshalb die
entsprechenden Angaben zur Version und Kodierung machen. Außerdem werden
am Anfang des Dokuments Namespaces festgelegt, um mehrdeutige Elementnamen
zu vermeiden.
<wsdl:definitions
targetNamespace=
"http://localhost:8080/AxisWorkshopServer/services/ComplexTypeService"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl=
xmlns:intf=
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="local"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Im folgenden Abschnitt werden die Typen definiert. Der hier beschriebene Service
verwendet zwei komplexe Typen, die geschachtelt sind (Der Typ ”outerCplx” enthält
den Typ ”innerCplx”). Elementare Datentypen (String, Int,...) werden als solche
beschrieben. Da für die Datenübertragung die Reihenfolge der Elemente
entscheidend ist, wird diese durch das XML Schema Sprachmittel ”sequence”
festgelegt. Das Attribut ”nillable” legt fest, ob das Element weggelassen werden darf.
<wsdl:types>
<schema targetNamespace="local"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="outerCplx">
<sequence>
<element name="cplx2" nillable="true"
type="tns1:innerCplx"/>
<element name="id" type="xsd:int"/>
<element name="name" nillable="true"
type="xsd:string"/>
</sequence>
</complexType>
<complexType name="innerCplx">
<sequence>
<element name="id" type="xsd:int"/>
<element name="name" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
<element name="outerCplx" nillable="true" type="tns1:outerCplx"/>
</schema>
</wsdl:types>
Das Message Element fasst die Typen zu abstrakten Nachrichten zusammen.
Abstrakt bedeutet, dass keine Angaben über das verwendete Nachrichtenformat
SOFTWARETECHNIK
Einführung in XML
- 106 -
©
Prof. J. Goll
- 8. Web Services gemacht werden. Damit ist WSDL nicht auf SOAP beschränkt, und für zukünftige
Formate offen. Der hier beschriebene Web Service bietet eine Methode an, somit
sind zwei Nachrichten notwendig, eine für die Anfrage, eine für die Antwort (Request
und Response).
<wsdl:message name="getComplexTypeRequest">
</wsdl:message>
<wsdl:message name="getComplexTypeResponse">
<wsdl:part name="getComplexTypeReturn" type="tns1:outerCplx"/>
</wsdl:message>
Die Nachrichten werden zu abstrakten Ports zusammengefasst. Ein Port ist später
unter einer bestimmten URL zu erreichen (bei HTTP als Transportprotokoll), oder
entspricht einer Message Queue (bei JMS). Bei den abstrakten Port Types wird noch
keine Angabe über das Protokoll gemacht. Innerhalb eines Port Types werden die
Operationen (eine Operation entspricht einer Methode des Web Services) festgelegt.
<wsdl:portType name="ComplexTypeService">
<wsdl:operation name="getComplexType">
<wsdl:input message="impl:getComplexTypeRequest"
name="getComplexTypeRequest"/>
<wsdl:output message="impl:getComplexTypeResponse"
name="getComplexTypeResponse"/>
</wsdl:operation>
</wsdl:portType>
Das Binding Element legt das verwendete Protokoll fest (hier SOAP über HTTP). Zu
einem Port Type können mehrere Bindings existieren, falls der Service über mehrere
Protokolle angeboten wird.
<wsdl:binding name="ComplexTypeServiceSoapBinding"
type="impl:ComplexTypeService">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getComplexType">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getComplexTypeRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace=
use="encoded"/>
</wsdl:input>
<wsdl:output name="getComplexTypeResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace=
use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Nachdem die Bindings festgelegt sind, werden diese mit einer konkreten Adresse
verbunden. Damit entsteht der eigentliche Service. Die Adresse kann für die
verschiedenen Protokolle sehr unterschiedlich aussehen, bei JMS würde z.B. der
Name einer Queue angegeben, sowie die IP Adresse des JNDI Managers.
SOFTWARETECHNIK
Einführung in XML
- 107 -
©
Prof. J. Goll
- 8. Web Services <wsdl:service name="ComplexTypeServiceService">
<wsdl:port binding="impl:ComplexTypeServiceSoapBinding"
name="ComplexTypeService">
<wsdlsoap:address
location=
"http://localhost:8080/AxisWorkshopServer/services/ComplexTypeService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
8.1.3 WSDL für den Echo-Service
Nachfolgend ist ein komplettes WSDL Dokument abgedruckt. Es beschreibt den
Echo-Service, der weiter unten im Text benutzt wird.
<wsdl:definitions
targetNamespace=
"http://localhost:8080/AxisWorkshopServer/services/EchoService"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl=
xmlns:intf=
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types/>
<wsdl:message name="echoRequest">
<wsdl:part name="in" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="echoResponse">
<wsdl:part name="echoReturn" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name="EchoService">
<wsdl:operation name="echo" parameterOrder="in">
<wsdl:input message="intf:echoRequest"
name="echoRequest"/>
<wsdl:output message="intf:echoResponse"
name="echoResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="EchoServiceSoapBinding"
type="intf:EchoService">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="echo">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="echoRequest">
<wsdlsoap:body encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
SOFTWARETECHNIK
Einführung in XML
- 108 -
©
Prof. J. Goll
- 8. Web Services namespace=
use="encoded"/>
</wsdl:input>
<wsdl:output name="echoResponse">
<wsdlsoap:body encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
namespace=
use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="EchoServiceService">
<wsdl:port binding="intf:EchoServiceSoapBinding"
name="EchoService">
<wsdlsoap:address location=
/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
8.2 Simple Object Access Protocol – SOAP
SOAP verwendet XML, um Methoden entfernter Objekte aufzurufen. Dadurch ist die
Kommunikation leicht nachzuvollziehen. In den folgenden Abschnitten wird SOAP
anhand von Beispielen erklärt. Die vollständige SOAP Spezifikation kann im Internet
unter [SOAP] erreicht werden.
SOFTWARETECHNIK
Einführung in XML
- 109 -
©
Prof. J. Goll
- 8. Web Services -
8.2.1 Aufbau einer SOAP Nachricht
Abbildung 1 zeigt den Aufbau einer SOAP Nachricht und deren Position in einem
HTTP Request.
Abbildung 1: Aufbau einer SOAP Nachricht
Ein Umschlag (Envelope) enthält einen Kopf (Header) und den eigentlichen Körper
(Body), in dem der Methodenaufruf zu finden ist.
SOFTWARETECHNIK
Einführung in XML
- 110 -
©
Prof. J. Goll
- 8. Web Services -
8.2.2 Beispiele für SOAP Nachrichten
Ein Beispiel für eine Anfrage an den Echo Service sieht so aus: Die SOAP Nachricht
wird über HTTP übertragen, deshalb startet das Beispiel mit dem HTTP Header. Als
Content Type wird text/xml angegeben, da SOAP auf XML aufbaut. Um auch lange
Nachrichten versenden zu können, wird die HTTP POST Methode verwendet. Um
Probleme mit Proxy Servern zu vermeiden, wird das Cache-Control Feld auf ”nocache” gesetzt.
POST /AxisWorkshopServer/services/EchoService HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.0
Host: localhost
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 474
Wie oben erwähnt, stellt eine SOAP Nachricht ein XML Dokument dar, deshalb
werden die entsprechenden Informationen über XML Version und Kodierung
angegeben.
Danach beginnt das ”soapenv:Envelope” Element, das als Klammer für die gesamte
Nachricht dient. Dieses Element macht auch Angaben über XML Schemata, die zur
Validierung von SOAP Nachrichten verwendet werden können.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Das ”soapenv:Body” Element enthält den Methodenaufruf, in diesem Fall die echo
Methode des Services. Diese Methode hat nur einen Parameter, einen String. Der
Parameter wird im Element ”in” übergeben, dort wird auch der Typ des Parameters
spezifiziert. Dies ist notwendig, um überladene Methoden unterscheiden zu können.
Der Wert des Parameters ist ”Hallo”.
<soapenv:Body>
<ns1:echo
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1=
"http://localhost:8080/AxisWorkshopServer/services/EchoService">
<in xsi:type="xsd:string">Hallo</in>
</ns1:echo>
</soapenv:Body>
</soapenv:Envelope>
SOFTWARETECHNIK
Einführung in XML
- 111 -
©
Prof. J. Goll
- 8. Web Services Die Antwort vom Echo Service hat dann etwa folgendes Aussehen: Die Antwort auf
den vorhergegangenen Request startet mit einem HTTP Protokoll-Header. Dort
werden eventuelle Fehlermeldungen des Servers (nicht des Services selbst!)
eingetragen, wenn alles funktioniert hat, ist der Code ”200 OK”.
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Date: Thu, 01 May 2003 20:30:40 GMT
Server: Apache Tomcat/4.0.6 (HTTP/1.1 Connector)
Connection: close
Das ”soapenv:Envelope” Element ist wie bei der Anfrage an den Service eine
Klammer um die SOAP Nachricht.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Im Body ist die Antwort des Web Service enthalten. Der Rückgabewert wird im
”echo-Response” Element zurückgeliefert.
<soapenv:Body>
<ns1:echoResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1=
"http://localhost:8080/AxisWorkshopServer/services/EchoService">
<echoReturn xsi:type="xsd:string">Hallo</echoReturn>
</ns1:echoResponse>
</soapenv:Body>
</soapenv:Envelope>
Wie hier zu sehen ist, werden die Parameter einer Methode nicht wieder
zurückgegeben, es kann also kein call-by-reference erfolgen. Sollen mehrere
Informationen zurückgegeben werden, muss als Returntyp ein komplexer Typ
verwendet werden, wie es das Beispiel in 8.1.2 zeigt.
SOFTWARETECHNIK
Einführung in XML
- 112 -
©
Prof. J. Goll
- 8. Web Services -
8.3 Universal Description Discovery and Integration – UDDI
Die Aufgabe von UDDI ist es, Web Services leicht auffindbar zu machen. Zu diesem
Zweck definiert UDDI eine Reihe von Strukturen, in denen Informationen zu Web
Services gespeichert werden können, sowie Schnittstellen, über die eine UDDI
Registry kommunizieren kann. Diese Schnittstellen sind ihrerseits als Web Services
implementiert.
8.3.1 UDDI Strukturen und Sichten
Die wichtigsten UDDI Strukturen sind:
•
businessEntity
Enthält Informationen über das Unternehmen, das den Service anbietet.
•
businessService
Nicht-technische Informationen über den Service, z.B. Geschäftsmodell, Kosten
etc.
•
bindingTemplate
Technische Informationen über den Service, z.B. wo der Service zu erreichen ist
und Informationen zu den Methoden.
•
tModel
Technische Spezifikationen, hier wird auch das WSDL Dokument zum Service
hinterlegt.
Es gibt noch einige weitere Strukturen, die die oben angegebenen verfeinern oder
verknüpfen. Diese Strukturen sind in der UDDI Spezifikation [UDDI] erklärt.
Mit Hilfe dieser Strukturen bietet UDDI für verschiedene Anwender verschiedene
Sichten auf die gespeicherten Daten. Diese Sichten werden Pages genannt und nach
verschiedenen Farben unterschieden.
•
White Pages
Diese Sicht liefert Daten für nicht-technische Benutzer, etwa die Informationen
über das Unternehmen und Kontaktadressen.
•
Yellow Pages
Diese Sicht konzentriert sich auf die Services, nicht auf die Unternehmen. Die
Informationen sind ebenfalls nicht-technischer Natur.
•
Green Pages
Diese Seiten liefern technische Informationen zu den Services.
Abbildung 2 zeigt die Zusammenhänge zwischen den Datenstrukturen und den
Sichten.
SOFTWARETECHNIK
Einführung in XML
- 113 -
©
Prof. J. Goll
- 8. Web Services -
Abbildung 2: UDDI Pages und Strukturen
8.3.2 UDDI Registries
Die Unternehmen, die an der Entwicklung von Web Services maßgeblich beteiligt
sind, betreiben auch gemeinsam eine weltweite UDDI Registry, in der jedes
Unternehmen seine Web Services publizieren und nach anderen Web Services
suchen kann. Physikalisch besteht diese weltweite Registry aus mehreren Knoten,
die ihre Informationen regelmäßig replizieren.
Auch dieser Datenaustausch innerhalb von UDDI erfolgt über Web Services. Ein
Knoten ist beispielsweise erreichbar unter: https://uddi.ibm.com/ubr/registry.html.
Innerhalb von Unternehmen macht auch eine eigene private UDDI Registry Sinn. Ein
Entwickler, der einen speziellen Service benötigt, hat so einen zentralen Punkt, an
dem er Services suchen kann.
8.3.3 Zugriff auf UDDI
Wie schon weiter oben erwähnt, kann auf jede UDDI Registry mit Web Services
Clients zugegriffen werden. Es existieren auch Toolkits, die diese Funktionalität
kapseln. Ein Beispiel dafür ist UDDI4J, das den Zugriff auf UDDI aus Java
Programmen heraus ermöglicht. Weitere Informationen zu UDDI4J gibt es unter
[UDDI4J].
Viele private UDDI Registries bringen auch eine Web Oberfläche mit, zum Beispiel
die Registry von IBM oder Systinet. Auch manche Entwicklungsumgebungen (z.B.
WebSphere Application Developer) bringen einen UDDI Explorer mit.
8.4 Web Services Tools
SOFTWARETECHNIK
Einführung in XML
- 114 -
©
Prof. J. Goll
- 8. Web Services -
8.4.1 Allgemeine Übersicht
Axis ist ein Open Source Projekt der Apache Software Foundation. Axis wird von
einigen führenden Herstellern von Application Servern eingesetzt und unterstützt. Da
der Quellcode verfügbar ist, können alle Details der Kommunikation zwischen Web
Service und Client nachvollzogen werden. Axis wird weiter unten detailliert
vorgestellt.
Zu Axis gibt es einige Alternativen, sowohl Open Source als auch kommerzielle.
Microsoft hat Web Services als festen Bestandteil der Architektur in die .NET
Umgebung integriert, und liefert die entsprechende Entwicklungsumgebung mit Tools
für die Erstellung von Web Services aus. Diese Tools umfassen auch
Codegeneratoren ähnlich den WSDL Tools von Axis. Als Sprache zur
Implementierung von Web Services auf der .NET Plattform wird C# empfohlen, es
kann aber jede Sprache verwendet werden, die vom .NET Framework unterstützt
wird.
Für die Java Plattform existieren eine Reihe von kommerziellen Toolkits (IBM Web
Services Toolkit, SUN Web Services Development Kit, ...). Oft wird in diesen Kits
intern eine speziell an die Produkte der Hersteller angepasste Version von Axis
verwendet. Dadurch werden Versionskonflikte bei von Axis und der
Laufzeitumgebung des Herstellers gemeinsam genutzten Bibliotheken vermieden.
(Ein häufiges Problem bei der Verwendung von Axis ist der XML Parser, der meist in
der Laufzeitumgebung schon vorhanden ist, aber nicht in einer passenden Version.
Der Austausch dieses Parsers kann einige Probleme bereiten).
Aktuelle Application Server bringen solche Toolkits meist mit und auch in vielen
Entwicklungsumgebungen (IBMWebSphere Studio, Together, ...) sind sie bereits
integriert.
8.4.2 Übersicht über Axis
Das Axis System ist sehr modular aufgebaut, die einzelnen Komponenten
kommunizieren über definierte Schnittstellen. Es ist auch möglich, Axis an
verschiedenen Stellen durch eigene Module zu erweitern. Diese Module sind im
wesentlichen Klassen, die ein bestimmtes Interface implementieren müssen, und
deren Namen in der Konfiguration von Axis angegeben werden. Der Kern des
Systems lädt die Klassen dann mit Hilfe des Java Classloader. Abbildung 3 zeigt die
einzelnen Komponenten von Axis.
SOFTWARETECHNIK
Einführung in XML
- 115 -
©
Prof. J. Goll
- 8. Web Services -
Abbildung 3: Axis Sub Systeme
Die Komponenten haben dabei die folgenden Aufgaben:
•
admin
Die Adminkomponente von Axis ist für das Deployment der verschiedenen
Services auf dem Server zuständig. Diese Komponente liest den Web Service
Deployment Descriptor aus, und steuert das Routing der Nachrichten zu dem
zugeordneten Service.
•
service
Normale Web Services verwenden SOAP, um die entfernten Methodenaufrufe zu
realisieren. Axis erweitert dieses Modell um weitere Möglichkeiten, entfernte
Methoden aufzurufen. Damit leidet jedoch die Interoperabilität mit anderen
Toolkits, deshalb wird hier nicht weiter auf diese Möglichkeiten eingegangen.
•
provider
Der eigentliche Service kann auf verschiedene Arten implementiert werden, etwa
als normale Java Klasse, Enterprise Java Bean (EJB) oder als Message Driven
Bean (MDB). Je nach Implementierung des Services wird ein spezieller Provider
verwendet, der den Service aufruft, und die Daten aus dem SOAP Aufruf
übergibt.
•
transport
In der Architektur von Web Services ist das Transportprotokoll nicht festgelegt.
Um flexibel zu bleiben, ist der protokollabhängige Teil von Axis in dieses Modul
ausgelagert. Module für eigene Transportprotokolle können eingebunden werden.
•
encoding
Bevor die Daten eines Services übertragen werden können, müssen sie in ein
einheitliches Format gebracht werden. Dazu ist auch eine Umsetzung der
sprachspezifischen (bei Axis: Java-spezifischen) Datentypen in SOAP Datentypen notwendig. Diese Aufgabe erledigt der encoding Teil der Axis Architektur.
Dieser Teil kann durch eigene Module erweitert werden, die Serializer und
Deserializer.
•
message model
SOFTWARETECHNIK
Einführung in XML
- 116 -
©
Prof. J. Goll
- 8. Web Services Nachrichten, die im Axis System verarbeitet werden, werden in ein Message
Objekt ”verpackt”. Dadurch können einer Nachricht innerhalb des Axis Systems
weitere Informationen mitgegeben werden (Zeitstempel etc). Das Message Modell
spielt eine wichtige Rolle bei der Entwicklung eigener Handler.
•
WSDL Tools
Axis stellt Tools zur Verfügung, um aus WSDL Java Code zu generieren, und aus
Java Klassen WSDL Dateien. Diese Dienste sind in den WSDL Tools
zusammengefasst: Mit WSDL2Java können aus einem WSDL Dokument
verschiedene Java Klassen, bzw. Rahmen erzeugt werden. Mit dem Java2WSDL
Tool kann aus bestehenden Klassen eine WSDL Datei erzeugt werden. In dieser
WSDL Datei werden dann die Methoden der Klasse als Web Service
beschrieben. Der Einsatz dieser Tools beim Entwickeln eigener Web Services
wird im Folgenden erläutert.
Axis benötigt weitere Komponenten, um funktionsfähig zu sein: Einen JAXP konformen XML Parser, z.B. Apache Xerces. Bei der Verwendung von HTTP als
Transportprotokoll wird eine Servlet Engine wie Apache Tomcat benötigt.
8.5 Entwickeln eigener Web Services
In diesem Abschnitt wird das Vorgehen bei der Entwicklung eigener Web Services
mit Axis erklärt. Generell kann bei der Entwicklung in zwei Richtungen vorgegangen
werden:
•
Bottom-Up Entwicklung: Bei diesem Vorgehen existiert schon eine Anwendung,
diese soll ganz oder teilweise als Web Service zur Verfügung gestellt werden.
•
Top-Down Entwicklung: Hier wird Interface getrieben vorgegangen, d.h. zuerst
wird die Schnittstelle des Web Services spezifiziert, dann wird die Anwendung
entsprechend implementiert.
Die dritte noch zu untersuchende Vorgehensweise ist:
•
Entwicklung eines Clients auf Grund einer in einer UDDI Registry gefundenen
WSDL Beschreibung, um den entsprechenden Web Service aufzurufen.
Axis unterstützt diese Vorgehensweisen mit den bereits erwähnten Tools
WSDL2Java und Java2WSDL. Das wird nun im Folgenden beschrieben.
SOFTWARETECHNIK
Einführung in XML
- 117 -
©
Prof. J. Goll
- 8. Web Services -
8.5.1 Vorgehen bei der Bottom-Up Entwicklung
1. Festlegen, welche Methoden als Web Service zur Verfügung gestellt werden.
2. Sammeln dieser Methoden in einer Fassade-Klasse (Anwendung des Fassade
Entwurfsmusters)
3. Analyse der zu übertragenden Datentypen:
Ist die Umsetzung in JavaBean-konforme Klasse möglich?
Ist die Entwicklung von eigenen Serializern / Deserializern notwendig?
4. Implementieren der Fassade-Klasse, bei Umsetzung der Datentypen in Beans wird
dies auch in der Fassade-Klasse erledigt.
5. Deployment des Services mit Axis, Generierung des WSDL Dokuments durch den
Aufruf des Services mit angehängtem ?wsdl.
6. Publizieren des Services in einer UDDI Registry.
8.5.2 Vorgehen bei der Top-Down Entwicklung
1. Festlegen der Methoden, die der Web Service anbieten soll. Dazu gehört auch das
Design der Datentypen, die übertragen werden sollen.
2. Erstellen eines WSDL Dokuments, das den Service beschreibt.
3. Generieren von Skelettklasse mit WSDL2Java. Diese Klasse enthält leere
Methodenrümpfe.
4. Implementieren der Servicelogik in der Skelettklasse.
5. Deployment des Services mit Axis.
6. Publizieren des Services in einer UDDI Registry.
8.5.3 Vorgehen bei der Entwicklung des Clients
1. Generieren der Client Stubs mit WSDL2Java.
2. Implementieren des Clients unter Verwendung der Stub-Klassen.
8.6 Transportprotokolle
Um SOAP Nachrichten zu transportieren, kann jedes Protokoll eingesetzt werden,
das den Austausch von XML Daten gestattet. Zurzeit verwenden die meisten Web
Services HTTP, das eine Reihe von Vorteilen bietet:
•
Einfacher Aufbau
HTTP ist ein relativ einfach aufgebautes Protokoll. Es wird nur ein Port
verwendet, was die Firewallkonfiguration vereinfacht.
•
Vorhandene Infrastruktur
Eine Infrastruktur für HTTP ist meist schon vorhanden (Webserver, DNS, Proxies,
Firewall).
•
Unterstützung durch Servlet Engines
SOFTWARETECHNIK
Einführung in XML
- 118 -
©
Prof. J. Goll
- 8. Web Services HTTP wird von allen Servlet Engines unterstützt, so dass die Kommunikation
nicht selbst implementiert werden muss.
Den oben aufgeführten Vorteilen steht als größter Nachteil entgegen, dass HTTP ein
verbindungsloses Protokoll ist. Eine Anfrage kann daher nicht ohne weiteres einem
Benutzer zugeordnet werden. Um dieses Problem zu lösen, gibt es verschiedene
Ansätze. Möglich ist z.B. Sessionhandling durch Cookies, oder auf SOAP Ebene.
Ein weiterer Nachteil von HTTP ist die fehlende Verlässlichkeit, d.h. es kann nicht
garantiert werden, dass eine Nachricht den Empfänger erreicht. Verlässlichere
Protokolle sind auf dem Vormarsch, Beispiele sind der Java Messaging Service
(JMS) und HTTP Reliable (HTTPR, siehe dazu [HTTPR]).
Der Java Messaging Sevice (JMS) ist eine Spezifikation für eine Schnittstelle in Java,
mit der zuverlässig Nachrichten ausgetauscht werden können. Diese Nachrichten
können jede Art von Objekten enthalten, wenn diese serialisiert werden können. Der
Vorteil bei der Verwendung von JMS liegt in der Zuverlässigkeit, es kann im
Gegensatz zu HTTP sichergestellt werden, dass Nachrichten den Empfänger
erreichen oder eine entsprechende Fehlerbenachrichtigung erfolgt.
8.7 Zusammenfassung
8.7.1 Einschränkungen bei Web Services
Manche Anforderungen von Anwendungen sind nicht mit ”reinen” Web Services zu
realisieren. Das soll heißen, dass nur Technologien verwendet werden, die
abschließend standardisiert worden sind, und damit von allen Toolkits angeboten
werden. Werden andere Technologien verwendet (z.B. spezielle Axis Features), wird
dadurch die Interoperabilität eingeschränkt.
Die wichtigsten Einschränkungen sind:
•
Session Handling
Es gibt noch keinen Standard für Web Services, mit dem Sessions abgebildet
werden können.
•
Sicherheit auf XML Ebene
Es gibt bereits Ansätze, Sicherheit auf XML Ebene zu realisieren, allerdings
existiert noch kein abschließender Standard.
•
Übertragung großer binärer Objekte (Bilder, Sound)
SOAP mit Attachements ist eine Möglichkeit, diese Anforderung zu realisieren,
jedoch ist im Web Services Umfeld noch nicht klar, ob sich dies als Standard
durchsetzt.
SOFTWARETECHNIK
Einführung in XML
- 119 -
©
Prof. J. Goll
- 8. Web Services •
Andere Übertragungsprotokolle als HTTP
Das Problem hierbei ist die Spezifizierung der Serviceadresse in WSDL. IBM hat
ein Format dafür eingeführt, das aber nicht von anderen Unternehmen unterstützt
wird.
•
Transaktionsunterstützung
Web Services unterstützen keine Transaktionen.
Axis beispielsweise bietet Möglichkeiten, mit deren Hilfe die Einschränkungen
umgangen werden können. Dabei muss aber immer bedacht werden, dass der
Einsatz dieser Features eine Festlegung auf Axis bedeutet, da andere Toolkits nicht
die selben Möglichkeiten bieten.
8.7.2 Bewertung von Web Services allgemein
Web Services ermöglichen in vielen Fällen eine einfache und schnelle Integration
von Anwendungen. Ihre Entwicklung kann in hohem Grad toolgestützt erfolgen, was
die Entwicklungszeit erheblich verkürzt. Dass Web Services Kommunikation über
Plattformgrenzen hinweg ermöglichen, erhöht die Investitionssicherheit, da keine
Festlegung auf eine einzelne Plattform oder Middleware besteht. Auch Anwendungen
in einem heterogenen IT Umfeld können integriert werden.
Diese Flexibilität wird mit einer gegenüber anderen Technologien (CORBA, DCOM)
schlechteren Performance und einem eingeschränkten Funktionsumfang erkauft.
8.7.3 Ausblick
Die Standards im Web Services Umfeld sind in Bewegung. Bei SOAP sind Sessions
und die Übertragung von großen, binären Datenmengen (etwa Bild Dateien) wichtige
Themen, an deren Standardisierung gearbeitet wird.
Ein weiteres Thema ist die Sicherheit von Web Services. Einige Hersteller (IBM,
Microsoft, Verisign und andere) arbeiten daran, Sicherheitsfunktionen zu
standardisieren. Der kommende Standard heißt WS-Security. Weitere Informationen
dazu gibt es unter [WSS].
SOFTWARETECHNIK
Einführung in XML
- 120 -
©
Prof. J. Goll
- 9. Semantic Web -
9 Semantic Web
9.1 Resource Description Framework – RDF
Das RDF (Resource Description Framework) soll eine Infrastruktur zur Nutzung von
Metadaten zwischen verschiedenen Web-Anwendungen bieten und somit die
Interoperabilität zwischen unabhängig entwickelten Webservern und -clients
verbessern. RDF vereinigt verschiedene webbasierte Metadaten-Initiativen und nutzt
XML als Austausch-Syntax. Metadaten, also Daten zur Beschreibung von Daten,
sind notwendig, da über das Web ausgetauschte Daten zwar maschinenlesbar, aber
zunächst nicht unbedingt maschinenverständlich sind, was einer gewünschten
Automatisierung entgegensteht. Als Metadaten im Rahmen der RDF-Initiative werden
sämtliche Daten bezeichnet, die Web-Ressourcen beschreiben. RDF wird unter dem
Dach der W3C entwickelt. RDF hat seit Februar 2004 den Status einer
Recommendation.
Das RDF wird Grundlage für eine Vielzahl von Anwendungen sein können. Das W3C
nennt etwa verbesserte Suchmaschinen durch die Verfügbarkeit von mehr bzw.
besserer Information, Austausch und gemeinsame Verwendung von Wissen durch
intelligente Softwareagenten, allgemein die Verbindung von Metadaten mit Inhalten
im Internet (content rating; Beispiel: PICS, Platform for Internet Content Selection,
ebenfalls vom W3C definiert, hilft beispielsweise Eltern zu kontrollieren, zu welchen
Inhalten im Internet ihre Kinder Zugriff haben) oder die Beschreibung von
Urheberrechten und Sicherheitsrichtlinien einer Webseite. Im Zusammenhang mit
digitalen Signaturen soll das RDF ein "key to building the Web of Trust" sein.
Das RDF basiert auf einem graphenbasierten Datenmodell, das aus Knoten und
zugehörigen Attributen/Wertepaaren besteht. Die Knoten stellen beliebige WebRessourcen dar (Seiten, Server etc., letztlich alles, das durch eine URI, wie die
bekannten URLs, ansprechbar ist). Im Gegensatz zu vielen bisherigen Versuchen
der Metadaten-Standardisierung verlangt das RDF durch die Verwendung von URIs
nicht unbedingt ein zentrales Register aller Attribute.
9.2 Web Ontology Language – OWL
Inzwischen gibt es noch eine weitere Entwicklung des W3C: OWL, die Web Ontology
Language. Auch hier steht die Verarbeitung von Information durch Computer im
Vordergrund und nicht das Verstehen der Information durch Menschen. OWL ist
selbst wieder eine XML-basierte Sprache. In dieser Sprache kann die Bedeutung von
Begriffen in Form einer Ontologie festgehalten werden. Eine solche Ontologie
besteht aus einem Vokabular für die Begriffe und Beziehungen zwischen diesen
Begriffen. Damit bietet OWL wesentlich mehr Möglichkeiten, um Bedeutung und
Semantik zu definieren als mit reinem XML oder mit RDF. OWL ist seit Februar 2004
im Status einer Recommendation. Es bietet derzeit die mächtigsten Möglichkeiten,
um Inhalte im Web in maschinenlesbarer Form zu definieren.
SOFTWARETECHNIK
Einführung in XML
- 121 -
©
Prof. J. Goll
- 10. Zusammenfassung -
10 Zusammenfassung
10.1 Vorteile von XML
XML ist durch das W3C entwickelt worden mit dem Ziel, ein offenes Datenformat für
über das Web nutzbare Dokumente zu bieten. Dabei, so zwei der Designziele, solle
es sich im Internet auf einfache Weise nutzen lassen und ein breites Spektrum von
Anwendungen unterstützen. Diese durch XML angestrebten Ziele sind sicherlich
unbestreitbar wünschenswert; allerdings ist XML nicht die einzige Möglichkeit, diese
Ziele zu unterstützen. So sind möglicherweise Remote Procedure Calls (RPC) oder
IIOP (Internet Inter-ORB Protocol) effizienter bzgl. Bandbreite oder
Verarbeitungsgeschwindigkeit als HTTP in Verbindung mit XML. Doch die Vorteile
der Verwendung von XML können erheblich sein. Nachfolgend werden die
wesentlichen Gründe vorgestellt, die XML zu einer breiten Verwendung und damit
zum zukünftigen Internetstandard verhelfen könnten.
10.1.1 XML harmoniert mit HTML, HTTP und Webbrowsern
Ein Vorteil der XML Konzeption beruht auf der enormen Verbreitung des WWW.
Viele Millionen Web-Autoren beherrschen HTML und warten auf Möglichkeiten,
dessen Beschränkungen zu überwinden. Diese Millionen sind mit dem Auszeichnen
von Daten vertraut und werden wenig Probleme haben, die XML Philosophie zu
verstehen und zu nutzen. Die Menge dieser HTML Autoren führte bereits jetzt zu
einer Fülle frei angebotener XML Tools wie Parser, Editoren etc. aller großen
Softwareanbieter. Die Menge der erwarteten Nutzer (installed base) ist daher
möglicherweise der entscheidende Faktor der Diffusion von XML.
Darüber hinaus gibt es – auch wenn HTTP primitiver ist als beispielsweise
CORBA/IIOP – wesentlich mehr HTTP-basierte Produkte. Die Verfügbarkeit
leistungsfähiger Browser macht das Web oder HTTP in Verbindung mit XML zu einer
weltweiten Plattform für strukturierte Daten. Ziel von XML ist nicht BitmengenEffizienz, sondern breite Anwendbarkeit.
10.1.2 XML ist einfach und portabel
XML soll Dokumente beliebiger Struktur im Web sowie eine Austauschbarkeit der
enthaltenen Daten unterstützen. Für wirklich portable Dokumente waren bislang
beispielsweise reine ASCII-Dateien geeignet, die sich mit fast allen Editoren
bearbeiten lassen, unabhängig von der Anwendung, mit der sie erstellt wurden. Die
von WYSIWYG-Editoren erzeugten Dokumente unterscheiden sich nun derart von
diesen ASCII-Dateien, dass von Kompatibilität, teilweise sogar zwischen
unterschiedlichen Versionen der gleichen Anwendung, nicht mehr gesprochen
werden kann. Mit XML wurde ein Markup-Ansatz entwickelt, da ein Vorteil der
expliziten Auszeichnung von Dokumentteilen, z.B. im Gegensatz zu Binärdateien, die
leichte Lesbarkeit und die Möglichkeit der Bearbeitung mit Editoren, die überall zur
SOFTWARETECHNIK
Einführung in XML
- 122 -
©
Prof. J. Goll
- 10. Zusammenfassung Verfügung stehen, ist. Der ausgezeichnete Inhalt ist für Autoren und Nutzer
wesentlich einfacher zugänglich. Um XML zu verstehen, ist so z.B. kein Umgang mit
hexadezimalen Datenmengen erforderlich. "In the Internet world, the rule of the game
is openness" [Maru98]. Die Einfachheit und antizipierte Verbreitung von XML führte
dazu, dass viele Initiativen zur Definition von Austauschformaten auf der Basis von
XML neu aufgelegt worden sind.
10.1.3 XML kann Dokumente beliebiger Komplexität abbilden
Bei aller Einfachheit ist es mit XML möglich, auch sehr komplexe Datenstrukturen
abzubilden. So können beispielsweise EDI Nachrichten als XML Dokumente
dargestellt werden. Es wurde gezeigt, dass XML Dokumente grundsätzlich eine
Baumstruktur aufweisen. Tabellen als logische Datenstruktur gängiger relationaler
Datenbanksysteme können in die XML Baumstruktur abgebildet werden. So kann
eine Zeile als Unterbaum und die ganze Tabelle als Abfolge derartiger Teilbäume
beschrieben werden. Das RDF stellt darüber hinaus ein graphenbasiertes
Datenmodell zur Verfügung. XML ist der Versuch, ein günstiges Verhältnis zwischen
Reichhaltigkeit auszuzeichnender Datenstrukturen und Einfachheit zu finden.
10.1.4 XML ist mehr als nur eine Auszeichnungssprache
Der vielleicht mächtigste Vorteil von XML liegt darin, dass es sich nicht nur um eine
Auszeichnungssprache mit relativ einfachen Spezifikationen handelt. Vielmehr ist
XML ein Paket an Funktionalität gemäß den Anforderungen an einen netzbasierten,
weltweiten Datenaustausch. So erhält XML seine Mächtigkeit aus dem
Zusammenspiel seiner zugehörigen Linking- und Zugriffsmodelle (XLink, XPointer,
DOM) mit der Möglichkeit, Daten einfach auszuzeichnen, Dokumenttypen zu
definieren (DTDs) und deren Instanzen zu nutzen und über bestehende Netze und
verfügbare Protokolle (HTTP) auszutauschen.
Traditionelle Standards wurden im Hinblick auf eine optimale Funktionserfüllung
innerhalb eines vergleichsweise fest umrissenen Anwendungsrahmens entwickelt.
XML soll letztlich allen Nutzern im Internet dienen und ist dementsprechend breiter
angelegt. Hier wird auch - gerade im Vergleich beispielsweise zu EDIFACT – ein
geändertes Selbstverständnis der Standardisierungsorganisationen bzw. eine
geänderte grundsätzliche Einstellung gegenüber der Bedeutung von Standards
sichtbar, indem das W3C konsequent Kompatibilität und Offenheit in den
Vordergrund seiner Bemühungen stellt.
SOFTWARETECHNIK
Einführung in XML
- 123 -
©
Prof. J. Goll
10.1.5 Internationalität
Ein häufig unterschätztes Argument für XML ist darüber hinaus die Unterstützung
internationaler Zeichensätze. Das Internet und die weltweite Kommunikation
überwinden Länder- und Sprachgrenzen. Daher unterstützt XML in der Version 1.0
den erweiterten Unicode-Zeichensatz ISO-10646 und verlangt, dass alle XML
Prozessoren mindestens zwei "encodings" unterstützen, nämlich UTF-8 und UTF-16.
10.2 Anwendungsfelder für XML
Da XML noch sehr jung ist, sind die meisten Implementierungen derzeit eher
prototypisch. Auch wenn alle größeren Firmen Unterstützung für XML oder
Schnittstellen für XML angekündigt haben, verhalten viele sich auch abwartend. Wie
bei jeder neuen Technologie besteht auch bei XML Unsicherheit, wie und wofür die
Sprache sich wird durchsetzen können. An einigen der kritischen Faktoren für eine
Durchsetzung wird derzeit noch gearbeitet, wie etwa an der Performanz der Tools
und an notwendigen Ergänzungen des Standards.
Einige Innovationen dürften auch aus der Verbindung mit Java zu erwarten sein. So
ist XML genau wie Java unabhängig von der verwendeten Plattform einsetzbar. Der
berühmte Satz des Mitentwicklers von XML, Jon Bosak, nämlich "XML gives Java
something to do" [Bosa97], resultiert aus der Fähigkeit von XML, nicht nur Textdaten,
sondern "grundsätzlich beliebige, textuell kodierbare (also theoretisch alle) Formen
von Daten zu speichern. (...) Praktisch könnte es so aussehen, dass ein Web-Server
neben den in XML kodierten Daten auch gleich das passende Java Programm
mitschickt. XML könnte also neben der universellen, system-unabhängigen Sprache
Java das universelle Datenformat des Web werden." [BeMi98]. Für die Kombination
Java/XML wurde schon das Schlagwort geprägt: "Portable Code – Portable Data".
Das soll heißen, was Java im Bereich der Programmierung geschaffen hat, das kann
XML im Bereich der Daten auch schaffen: Portabilität.
Vor dem Hintergrund der oben beschriebenen allgemeinen Vorteile einerseits und
der Beschränktheit von HTML andererseits lassen sich vier besonders geeignete
Anwendungsfelder für XML identifizieren, die im Folgenden etwas genauer erläutert
werden.
SOFTWARETECHNIK
Einführung in XML
- 124 -
©
Prof. J. Goll
10.2.1 XML als standardisiertes Datenaustauschformat
XML kann als Datenaustauschformat zwischen unterschiedlichen Datenbeständen
dienen. Bislang gingen die meisten Überlegungen zur Gestaltung des XML-basierten
Datenaustausches zwischen verschiedenen Systemen mit unterschiedlichen
Datenformaten, die interessengruppen-spezifisch standardisiert werden können
(etwa Bestellung und Rechnung), davon aus, dass die auszutauschenden
Dokumente eine im Industriestandard spezifizierte DTD als Grundlage nutzen. Diese
DTDs werden in Repositories zur Verfügung gestellt. Damit können Dokumente von
jeder empfangenden Anwendung validiert und verarbeitet werden. Neuere Ansätze
gehen auch andere Wege und nutzen beispielsweise wohlgeformte XML Dokumente
als flexiblere Grundlage für den Datenaustausch.
Beispiele für die Anwendung von XML als Datenaustauschformat sind Krankenakten,
kooperatives CAD/CAM oder Terminmanagement sowie allgemein jeder
Datenaustausch zwischen verschiedenen Datenbanken wie auch Workflow-Systeme.
Konkrete Anwendungen sind etwa der Datenaustausch mit Electronic Data
Interchange über das WWW (XML/EDI) oder das Open Trade Protocol (OTP), das
ein standardisiertes Verfahren für den Handel mit Privatkunden zur Verfügung stellt.
Microsoft hat in die neuen Office-Versionen XML als (internes) Datenformat
integriert, um so den Dokumenten- und Datenaustausch zwischen den einzelnen
Office-Anwendungen und über das WWW zu erleichtern.
10.2.2 Verlagerung der Rechenleistung vom Server zum Client
Durch die Möglichkeit, alle Daten, die zu einem Dokument gehören, in XML zu
codieren, können alle zum Verarbeiten des Dokumentes notwendigen Informationen
übertragen werden und beim Client entsprechend ausgeführt werden. Hier wird auch
die Bedeutung der bereits angesprochenen Kombination der Netzsprache Java und
XML deutlich (z.B. Electronic Banking, Electronic Commerce).
10.2.3 Variable Darstellung von Informationen
Auf XML Dokumente können in Abhängigkeit vom jeweiligen Anwendungszweck
unterschiedliche Sichten genommen werden. Aus einer Softwaredokumentation
können z.B. nur die für das jeweilige Betriebssystem interessanten Informationen
angezeigt werden. Dokumente können unterschiedlich angezeigt und ausgedruckt
werden, andere Beispiele sind zur Laufzeit generierte Inhaltsverzeichnisse,
mehrsprachige Informationen, die nur in der jeweils gewünschten Sprache angezeigt
werden, verschiedene Behandlung von Fußnoten in Dokumenten, eine Sortierung
von Telefonbüchern je Wunsch nach Name, Nummer, Vorname etc.
SOFTWARETECHNIK
Einführung in XML
- 125 -
©
Prof. J. Goll
10.2.4 Intelligentes Suchen in XML Datenbeständen
Intelligente Softwareagenten können die Bedeutung von in XML codierten
Informationen verstehen. So wird z.B. eine bessere Indizierung von Webseiten
(allgemeiner von Produkten) möglich, um das bekannte Problem der Fehltreffer aus
Homonymen und Synonymen in Suchmaschinen zu lösen. Allgemein bilden
strukturierte Daten eine Grundlage für eine individuelle Nutzung von Massenmedien
über Netze. "Information needs to know about itself, and information needs to know
about me" [Bosa97]. Mögliche Anwendungen sind personalisierte FernsehProgrammzeitungen, die aus einer Vielzahl von Angeboten die den individuellen
Präferenzen entsprechenden finden, bzw. eine Beschreibung der Programmangebote derart, dass diese von Interessierten überhaupt gefunden werden können.
Auch wenn wirklich intelligente Agenten sicherlich nicht in nächster Zukunft verfügbar
sein werden, werden sie eine zunehmend bedeutende Rolle spielen; auf jeden Fall
und in jeder Ausbaustufe benötigen sie Daten in einem Format, das für sie
verständlich ist, und dies kann XML bieten.
10.3 Ausblick
XML ist durch das W3C entwickelt worden mit dem Ziel, ein offenes Datenformat für
über das Web nutzbare Dokumente zu bieten. Dabei, so zwei der Designziele, solle
es sich im Internet auf einfache Weise nutzen lassen und ein breites Spektrum von
Anwendungen unterstützen. Auch wenn XML noch nicht lange den Status eines
Standards besitzt, ist es derzeit in aller Munde. Bislang fehlte eine Möglichkeit,
Daten, sei es auf Webseiten oder für unterschiedliche Anwendungen,
allgemeinverständlich zu beschreiben. Es fehlte ein universelles Datenformat. Sollte
sich die Erfolgsgeschichte von XML weiter fortsetzen, was allgemein erwartet wird,
könnte sich die Sprache zu dem zukünftigen Standard zur Datenbeschreibung im
Internet entwickeln. Inzwischen sind bereits weit über 100 in XML definierte
Sprachen entwickelt worden, siehe [OASIS], und täglich entstehen neue XML
Anwendungen. Die Einfachheit von XML katalysiert branchenübergreifende Ansätze
zur Entwicklung interoperabler Lösungen und ermöglicht es einer großen Anzahl an
Nutzern – Technikern wie Nichttechnikern – bei der Definition und Nutzung neuer
Markup-Sprachen zusammenzuarbeiten.
Die zunehmende Bedeutung des Internet als Kommunikationsmedium wird
vermutlich der Durchsetzung von XML noch weiter Vorschub leisten, da mit XML eine
neue Basis für die Integration verschiedener Partner, Prozesse und Anwendungen
existiert. Die offene Struktur von XML könnte einen Beitrag zu einer Öffnung von
Kommunikations- und Kooperationsnetzen leisten.
SOFTWARETECHNIK
Einführung in XML
- 126 -
©
Prof. J. Goll
- 11. Quellenverzeichnis -
11 Quellenverzeichnis
11.1 Literatur
[BäLa02] Michael Bässler, Wolfgang Langner: Vergleich von verschiedenen ParseVerfahren für XML Dokumente, Studienarbeit, HS Esslingen, FB Informationstechnik,
SS2002.
[BeMi98] Behme, Henning; Mintert, Stefan: XML in der Praxis: Professionelles WebPublishing mit der Extensible Markup Language. Bonn 1998.
[Book02] Matthias Book: Untersuchung Schema-validierender XML Parser,
Studienarbeit, HS Esslingen, FB Informationstechnik, SS2002.
[Bosa97] Bosak Jon: XML, Java and the future of the Web.
http://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.html, 1997-10-03.
[GOO] Google Suchmaschine.
http://www.google.com.
[HoUl01] Holubek, Andreas; Ulbricht, Frank: XML leicht gemacht - Die Java
Architecture for XML Binding (JAXB) in der Praxis. Java Magazin 10/2001.
[HTML40] Definition von HTML 4.0.
http://www.w3.org/TR/html401/html40.pdf.gz
[HTTPR] HTTPR Specification.
http://www-106.ibm.com/developerworks/webservices/library/wshttprspec/.
[Mach97] Macherius, Ingo: XML: Professionelle Alternative zu HTML.
http://www.heise.de/ix/artikel/1997/06/106/.
[Maru98] Maruyama, H./Uramoto, N./Tamura, K. (IBM Research): The Power of
XML: XML's Purpose and Use in Web Applications.
http://www.software.ibm.com/xml/education/xmlpower/xmlpower.pdf.
[OASIS] Oasis and Robin Cover: The SGML/XML Web Page – Web Site Index –
Expanded Outline.
http://www.oasis-open.org/cover/siteIndex.html.
[Schu03] Stefan Schuster: Web Services mit Axis, Studienarbeit, HS Esslingen, FB
Informationstechnik, SS2003.
[SOAP] Simple Object Access Protocol.
http://www.w3.org/TR/SOAP/.
SOFTWARETECHNIK
Einführung in XML
- 127 -
©
Prof. J. Goll
- 11. Quellenverzeichnis [Tri03] Matthias Trischler: Untersuchung der Java Architecture for XML Binding
(JAXB) im Vergleich mit anderen Datenmodellen für XML, Studienarbeit, HS
Esslingen, FB Informationstechnik, SS2003.
[UDDI] About UDDI.
http://www.uddi.org/about.html.
[UDDI4J] Uddi4j project.
http://www-124.ibm.com/developerworks/oss/uddi4j/top.htm.
[W3C] Die Website des W3C.
http://www.w3c.org/.
[WSDL] Web Services Description Language.
http://www.w3.org/TR/wsdl.
[WSIF] WSIF project homepage.
http://www.alpaworks.com/wsif.
[WSS] Microsoft, IBM und andere: Web Services Security (WS-security). April 2002.
http://www-106.ibm.com/developerworks/library/ws-secure/.
[XMLdev] XML-dev-Mailing-Liste in: http://lists.xml.org/archives/xml-dev/. Heute wird
die Mailing Liste von OASIS weitergeführt: http://www.oasis-open.org/
(ToDo) In diesem Download ist auch eine Beschreibung enthalten: Fordin, Scott: The
Java Architecture for XML Binding User´s Guide. Sun Microsystems, February 2003.
http://java.sun.com/webservices/downloads/webservicespack.html
11.2 Bücher
Dies ist eine unvollständige Liste, der Markt wächst ständig!
"Professional XML" Didier Martin et al., Wrox Press Ltd.
"The XML Handbook" C. Goldfarb, P. Prescod, Prentice Hall.
"The XML Bible" E.R. Harold, IDG Books
“XML in 21 days” S. North, P. Hermans, SAMS, MacMillan Publishing.
“Das XML Einsteigerseminar” M. Seeboerger-Weichselbaum, bhv.
“XML kompakt” T. Michel, Hanser Verlag.
“XML” M. Stein, I. Dellwig, Addison-Wesley
“Just XML” J.E. Simpson, Prentice-Hall
"Beginning XML" D. Hunter et al., Wrox Press Ltd
SOFTWARETECHNIK
Einführung in XML
- 128 -
©
Prof. J. Goll
11.3 Links zu Informationsquellen
•
http://www.w3c.org/ the standards body that defines all core XML standards
•
http://www.w3.org/XML/ explains all W3C activities around XML, and has links
to software resources.
•
http://www.xml.com/ good base to enter the world of XML
•
http://www.megginson.com/ is well worth a trip for up-to-date information on
SAX
•
http://www.ibiblio.org/xml/ Cafe con Leche: news and resources
•
http://msdn.microsoft.com/library/
•
http://www.newsnow.co.uk/cgi/NewsNow/NewsFeed.htm?Topic=*.Tech&ASe
arch=XML&Section=ASearchW&Search=XML news portal
•
http://www.perfectxml.com/
•
http://www.w3schools.com/xml/ one of the WWW schools
•
http://www.xmlmag.com/ with in-depth articles
•
http://www.cetus-links.org/oo_xml.html presents many links to XML resources
in a suitable classification.
•
http://www.oasis-open.org/cover/ provides a detailed overview of all ongoing
XML activities.
•
http://www.xmltree.com/index.html index of XML sites on the Internet.
•
http://www.xmlinfo.com/
•
http://www.xslinfo.com/
•
http://www.xmlsoftware.com/
•
http://www.zvon.org/
SOFTWARETECHNIK
Einführung in XML
- 129 -
©
Prof. J. Goll
11.4 Links zu Software Herstellern
•
http://xml.apache.org/ The Apache Software Foundation has stepped up its
involvement in XML with 5 subprojects. Part of the suite is Xerces, a Java
XML parser donated by IBM (formerly the XML4J parser).
•
http://msdn.microsoft.com/code/default.asp?url=/code/topic.asp?URL=/msdnfiles/028/000/072/topic.xml free tools from Microsoft to create an XML
document, including validation support.
•
http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=
u28000438 XML Portal from Microsoft
•
http://alphaworks.ibm.com/ IBM's free XML and Java tools.
•
http://www-106.ibm.com/developerworks/xml/ XML Portal from IBM
•
http://www.oracle.com/xml/
•
http://www.jclark.com/xml/expat.html James Clark's (author of the XSLT W3C
recommendation) expat is a non-validating XML parser written in C. expat has
been used for the XML support in the Mozilla browser.
•
http://www.xmloperator.org/ a free Java XML editor.
•
http://www.tibco.com/ XML and XSL Tools
•
http://www.sun.com/software/xml/ XML Portal from Sun
•
http://java.sun.com/j2ee/ J2EE released by Sun contains a lot of XML
software
•
http://www.topxml.com/xsltester/
information
•
http://www.induslogic.com/ Tools for XML and XSLT (XMLWiz)
Open
Source
Project
with
tools
and
Siehe dazu auch den folgenden Abschnitt mit ausführlicheren Beschreibungen
einzelner Tools.
SOFTWARETECHNIK
Einführung in XML
- 130 -
©
Prof. J. Goll
- 12. XML Tools -
12 XML Tools
12.1 XML Editoren
Da das Erstellen von XML Files besonders fehleranfällig ist (Tippfehler bei den Tags,
falsche Gliederung, etc.), gibt es gerade hierfür einige Tools.
Alle hier vorgestellten Editoren sind DTD-aware, d.h. sie validieren die gelesenen
XML Dokumente und unterstützen den Autor beim Editieren. Es können dann an
bestimmten Stellen immer nur die Tags eingefügt werden, die die DTD dafür vorsieht.
12.1.1
Xeena
Hersteller: IBM
kostenpflichtig, kostenfreie Evaluationsphase
in Java, XML Schema Support
Abbildung 11-1: Das Adressbuch in Xeena
SOFTWARETECHNIK
Einführung in XML
- 131 -
©
Prof. J. Goll
- 12. XML Tools -
12.1.2
Merlot
Open-Source
gesponsort von ChannelPoint Inc.
in Java
zu finden auf dem Webserver (http://www.merlotxml.org/) des Projekts.
Abbildung 11-2: Das Adressbuch in Merlot
12.1.3
Morphon
Hersteller: Lunatech Research
kostenpflichtig, freie Beta erhältlich
in Java
zu finden bei Morphon (http://www.morphon.com/).
SOFTWARETECHNIK
Einführung in XML
- 132 -
©
Prof. J. Goll
- 12. XML Tools -
Abbildung 11-3: Das Adressbuch in Morphon
12.1.4
EpcEdit
Hersteller: Koch Consulting & Software
kostenpflichtig, freie Beta erhältlich
für Windows und Linux verfügbar
kann XML und SGML
Im Gegensatz zu den anderen Editoren wird hier das Dokument nicht tagweise sondern komplett dargestellt, daher eignet sich dieser Editor
besonders für Text-Dokumente.
SOFTWARETECHNIK
Einführung in XML
- 133 -
©
Prof. J. Goll
- 12. XML Tools -
Abbildung 11-4: Dieses Skript in EpcEdit
12.1.5
Weitere XML Editoren
Wordperfect von Corel (http://www.corel.com/Office2000/index.htm)
Arbortext (http://www.arbortext.com/)
Framemaker von Adobe (http://www.adobe.com/products/framemaker/)
Oxygen (http://www.oxygenxml.com) lässt sich auch als Plugin in die
Eclipse-IDE integrieren
SOFTWARETECHNIK
Einführung in XML
- 134 -
©
Prof. J. Goll
- 12. XML Tools -
12.2 XML Parser
12.2.1
XML4J
XML Parser für Java (XML 4 Java)
Hersteller: IBM
kostenpflichtig
Die Version 1.0 wurde dem Apache-Projekt gespendet. Seitdem werden
XML4J und Xerces parallel entwickelt. XML4J 3.0 basiert jedoch wieder auf
den Xerces-Sourcen.
SAX, SAX2, DOM, DOM Level 2
zu finden auf IBM's Alphaworks-Server.
12.2.2
Xerces
Hersteller: Apache-Projekt
Open-Source
basiert auf XML4J
erhältlich für Java, C++ und Perl
SAX, SAX2, DOM, DOM Level 2
zu finden auf den XML Seiten des Apache-Projekts.
12.2.3
Java API for XML Processing
Hersteller: SUN
Referenz-Implementation für Java API, gehört inzwischen zu J2EE
SAX, DOM, XML Namespaces
zu finden auf den Java/XML Seiten von SUN.
SOFTWARETECHNIK
Einführung in XML
- 135 -
©
Prof. J. Goll
- 12. XML Tools -
12.3 XSL Tools
12.3.1
XSLT Prozessoren
Xalan-J [1] ist ein Open Source XSLT Prozessor der Apache Software Foundation
(ASF) und kann unter Berücksichtigung der ASF Lizenzbedingungen auch in
kommerziellen Projekten eingesetzt werden. Xalan bietet die Verwendung von
XSLTC (eXtensible Stylesheet Language Transformations Compiled). Hier kann der
Compiler die zu verwendenden Stylesheets in Java Bytecode (sogenannte Translets)
übersetzen. Den Xalan XSLT Prozessor gibt es auch in einer C++ Implementierung,
die den Geschwindigkeitsvorteil von C++ gegenüber Java nutzt. Xalan verdankt
seinen Namen einem seltenen Musikinstrument und ist voll kompatibel zum XSLT 1.0
Standard.
SAXON [2] entstand "on top of SAX", der API (Application Programming Interface) für
XML Parsing. Ihr verdankt SAXON auch seinen Namen. SAXON ist ein Open Source
XSLT Prozessor und steht unter der Mozilla Public License Version 1.0 [3] zur
Verfügung. SAXON wird in vielen Quellen und Benchmarks als schnelle XSLT
Implementierung aufgeführt und zeichnet sich durch zahlreiche Erweiterungen aus,
von denen einige in EXSLT (Extensions to XSLT) [4] eingeflossen sind.
Für Windows gibt es einen abgespeckten SAXON ohne Quellen und API
Dokumentation. Instant SAXON [5] läuft mit der VM (Virtuellen Maschine) von
Microsoft, ist jedoch gegenüber seinem „großen“ Bruder um ca. Faktor 3 langsamer.
Aufgrund seiner Größe und unkomplizierten Installation kann der Instant SAXON für
kleinere Projekte eine Alternative sein.
XT [6] ist ein in Java implementierter Open Source XSLT Prozessor, der sich durch
eine extrem hohe Verarbeitungsgeschwindigkeit auszeichnet, XSLT aber nicht voll
unterstützt. Bei einfachen Stylesheets, die keinen Gebrauch von den nicht
unterstützten Features machen, kann XT eine Alternative sein, wenn die
Geschwindigkeit der Transformation entscheidend ist.
Der Altova XSLT Prozessor [9] ist voll kompatibel mit der W3C XSLT 1.0
Spezifikation [10]. Geliefert wird der Prozessor als Windows .exe File, welcher mittels
der Komandozeile ausgeführt wird. Dadurch ist der Prozessor sowohl für Client als
auch für serverseitige Anwendungen geeignet. Die Altova XSLT Engine entspricht
voll und ganz der Version, welche im XMLSpy von Altova verwendet wird und
unterliegt keinen Einschränkungen.
Sablotron [13] ist mit C++ realisiert. Binaries für Linux und Windows können von der
Ginger Alliance Website heruntergeladen werden. Er ist ein Open Source Toolkit für
XML und enthält neben DOM Level 2 und XPath Unterstützung einen eigenen XSLT
Prozessor. Zudem existieren für Perl, PHP, Python, Object Pascal, Ruby, Erlang, Tcl
und Ada Wrapper, die es ermöglichen Sablotron in diesen Sprachen zu verwenden.
Erweiterungen für Sablotron können über ein DOM API in JavaScript realisiert
werden.
SOFTWARETECHNIK
Einführung in XML
- 136 -
©
Prof. J. Goll
- 12. XML Tools -
Für das „Gnome Projekt“ wurde libxslt [15], eine XSLT Bibliothek in C von Daniel
Veillard entwickelt. Die Bibliothek kann in eigene Projekte eingebunden werden.
Neben dem Source Code gibt es fertige Binaries für Windows.
Die Microsoft(R) XML Core Services [16] bieten neben einem Parser und Schema
Unterstützung auch einen XSLT Prozessor. MSXML ist zunächst nur eine Bibliothek
in Form einer DLL, die in eigenen Programmen verwendet werden kann. Der
Wrapper MSXSL ist für die Kommandozeile als separater Download von Microsoft
erhältlich. Voraussetzung ist eine installierte Version von MSXML 2.6 oder höher.
MSXML kann vom Internet Explorer für Client-seitige XSLT Transformationen
verwendet werden.
12.3.2
Cocoon
Cocoon, das Web Publishing Framework der Apache Software Foundation, gehört zu
den wichtigsten Projekten der Apache Group. Es ist ein Unterprojekt des Apache
XML Projektes
Cocoon ist ein Servlet aus mehreren Komponenten. Das Java-basierte XML
Publishing Framework dient als Übersetzer zwischen den Clients, die die Daten in
einem bestimmten Format anfordern und den eigentlichen Daten. Diese können aus
einer oder mehreren XML Dateien oder auch aus einer Datenbank stammen. Mit den
dazugehörigen XSL Dateien lassen sich die Inhalte in ein beliebiges Ausgabeformat,
wie zum Beispiel HTML, TXT, RTF, PDF transformieren.
Näheres zu den Features, Einsatzmöglichkeiten und Ausgabeformaten ist unter
http://cocoon.apache.org/2.1/features.html zu finden.
12.3.3
XSLT Editoren
ToDo
SOFTWARETECHNIK
Einführung in XML
- 137 -
©
Prof. J. Goll
- 12. XML Tools -
12.3.4
XSL-FO Prozessoren
fop ist ein freier XSL-FO Prozessor von der Apache Software Foundation. Die
aktuelle Version erzeugt unter anderem die Formate PDF, PCL, PS, SVG, XML und
TXT. (http://xml.apache.org/fop/index.html)
XEP ist ein kostenpflichtiger FO-Prozessor von der Firma RenderX.
(http://www.renderx.com/FO2PDF.html)
PassiveTeX ist eine Bibliothek von TeX Makros zur Umsetzung von XSLFormatierungsobjekten. (http://www.tei-c.org.uk/Software/passivetex/)
WH2FO ist eine frei verfügbare Anwendung, um HTML-Dokumente aus Word nach
XML-FO zu transformieren. (http://wh2fo.sourceforge.net/)
XSL Formatter von Antenna House Inc. stellt ein komplettes Toolkit zur Verfügung,
um aus XML mittels Formatting Objects PDF-Dokumente zu erstellen.
(http://www.antennahouse.com/)
Unicorn Formatting Objects ist ein in C++ geschriebenes Toolkit inklusive XSL-FO
Prozessor zur Erzeugung von PDF, PS und HTML, das kostenlos verwendet werden
kann. (http://www.unicorn-enterprises.com/products_ufo.html)
REXP (Rendering Engine from XML/XSL into PDF) ist ein plattformunabhängiges
Toolkit, das auf fop basiert. (http://www.esng.dibe.unige.it/REXP/)
jfor ist ein in Java programmierter Open-Source XSL-FO Prozessor zur Generierung
von RTF-Dokumenten. (http://www.jfor.org/)
Apoc XSL-FO, ein Prozessor für Microsoft .NET, basiert ebenfalls auf fop.
(http://www.chive.com/index.html)
XMLmind FO Converter ist ein Java Programm zur Erzeugung von RTF Dokumenten
aus FO. (http://www.xmlmind.com)
SOFTWARETECHNIK
Einführung in XML
- 138 -
©
Prof. J. Goll

Einführung in XML - IT

Transcrição

Documentos relacionados

Übungsblatt 11

Carte client • Kundenkarte

XSL, XSLT, FO - Einstieg für XML

baden-baden airport + shuttle

Einsatz der Extended Markup Language (XML) (68k PDF)

internet adresse szeged

XSL Schulung/ Seminar/ Training (FO, Apache FOP, PDF

Sentier Stanislas-Kléber GR534 - Office de Tourisme de Molsheim

www.adam-touring.ch

java script xsl zaehler