Leseprobe
Inhaltsverzeichnis
1. Einleitung
1.1. Motivation
1.2. Ziel der Arbeit
1.3. Kapitelübersicht
2. Die Applikation „handyEngine“
2.1. Umfeld und Intention
2.2. Funktionsumfang
2.2.1. Nutzer - Interface
2.2.2. Admin - Interface
3. XML und Substandards
3.1. Ziele und Begriffe
3.1.1. Entwicklung
3.1.2. Ziele von XML
3.1.3. wellformed XML
3.1.4. valid XML
3.1.5. Namespaces
3.2. Dokumenttypdefinition
3.2.1. DTD
3.2.2. XML Schema
3.3. Parser
3.3.1. Begriffsdefinition
3.3.2. SAX
3.3.3. DOM
3.3.4. Einbindung
3.4. XPath
3.5. XSL
3.5.1. Transformations
3.5.2. Formatting Objects
4. Architektur von Webapplikationen
4.1. Evolution
4.2. n-Tier Konzeption
4.2.1. Einordnung
4.2.2. Data- / Backend Tier
4.2.3. Application Server Tier
4.2.4. Presentation Layer
4.3. Model - View - Controller
5. Implementierung der Applikation „handyEngine“
5.1. Vorbemerkungen
5.1.1. Abgrenzung
5.1.2. Runtime Environment
5.2. Design
5.2.1. Model
5.2.2. Controller
5.2.3. View
5.3. Projektstatus
6. Ausblick
6.1. WebServices
6.1.1. Herausforderung
6.1.2. SOAP
6.1.3. WSDL
6.1.4. UDDI
6.1.5. Schlussfolgerung
6.2. komponentenbasierte Frameworks
6.2.1. J2EE
6.2.2. .NET
6.2.3. SunONE
7. Schlussbetrachtung
Literaturverzeichnis
Anhang
Erklärung
Verzeichnis der Abbildungen
Abbildung 1: Komponentendiagramm EHB
Abbildung 2: Screenshot handyEngine Startseite
Abbildung 3: Screenshots handyEngine Funktionsseiten
Abbildung 4: Sequenzdiagramm Modellreferenzierung
Abbildung 5: Screenshot handyEngine-Admin Interface
Abbildung 6: Aufbau eines XML Dokuments
Abbildung 7: SAX Parser-Events
Abbildung 8: Aufbau eines DOM
Abbildung 9: Syntax eines XPath-Ausdrucks
Abbildung 10: XSLT Einsatzbeispiele
Abbildung 11: Beispiel einer XSLT - Transformation
Abbildung 12: XSL Spezifikationen
Abbildung 13: Architektur eines XSL Prozessors
Abbildung 14: Ablauf eines XSL:FO Renderings
Abbildung 15: Prinzip der CGI Programmierung
Abbildung 16: fastCGI Einbindung
Abbildung 17: Architektur der Servlet-Schnittstelle
Abbildung 18: 3-tier Konzeption
Abbildung 19: Die Rolle des Application Server
Abbildung 20: Komposition eines Presentation Layers
Abbildung 21: Anforderungen an clientbasierte Technologien
Abbildung 22: MVC - Desing Pattern
Abbildung 23: Anwendungsfalldiagramm handyEngine
Abbildung 24: Klassendiagramm Datenbeans
Abbildung 25: Klassendiagramm Controller
Abbildung 26: Sequenzdiagramm Referenzierung
Abbildung 27: verteilte Anwendung
Abbildung 28: Aufbau einer SOAP Message
Abbildung 29: Einsatz von UDDI
Abbildung 30: Architektur des .NET Frameworks
Abbildung 31: Bestandteile des SunONE Frameworks
Verzeichnis der Abkürzungen
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
1.1. Motivation
Am 15.11.2001 wurde der Mikroprozessor 30 Jahre alt1 und am 13.01.2001 das World Wide Web 10 Jahre2. Betrachtet man rückblickend die exponentielle Entwicklung, die dieses Medium in der relativ kurzen Zeit sowohl quantitativ als auch qualitativ genommen hat, kann man eine Vorstellung davon entwickeln, welche Entwicklungssprünge wir in Zukunft erleben werden. Allein im Jahr 2001 wurden 195 RFC veröffentlicht3, die die Entwicklung von Webanwendungen direkt oder indirekt beeinflussen. Diese Situation ist freilich nicht ungewöhnlich, zumal im IT - Bereich. In ihrer Massivität stellt die Entwicklung jedoch eine neue Qualität dar, der mit adäquaten Methoden begegnet werden muss. Das der präferierte Ansatz zur Beherrschung der Situation selbst ein Standard ist, erscheint nur auf den ersten Blick seltsam: XML ist mit dem Anspruch entwickelt worden, als eine Art Metastandard zunächst die Syntax zu vereinheitlichen. Das dieses Ziel auf den ersten Blick eher bescheiden ausfällt, darf dessen enormen Nutzen nicht marginalisieren.
Trotz der Bemühung einer Vereinheitlichung ist vor allem im Onlinebereich eine stetige Zunahme der Komplexität von Anwendungen zu verzeichnen, zumal auch ein Metastandard wie XML implementiert und beherrscht werden muss. Dies ist vor allem der vielerorts angestrebten vollständig browserbasierten Bedienung von Unternehmensanwendungen zuzuschreiben.
1.2. Ziel der Arbeit
Dabei kommt wirkt sich positiv aus, dass alle eingesetzten Standards nicht im luftleeren Raum entwickelt wurden, sondern immer ein dediziertes Problem adressieren und damit quasi einen „best practice“ - Ansatz für ihren Einsatz mitliefern. Diesen an einem konkreten Beispiel zu verdeutlichen soll Ziel der vorliegenden Arbeit sein. Einzelne Technologien und Konzepte sollen gezielt herausgegriffen werden um ihre Bedeutung innerhalb des „big picture“ darzustellen.
1.3. Kapitelübersicht
Da in der Darstellung immer wieder auf die Referenzapplikation „handyEngine“ zurückgegriffen werden wird, dient es der Verständlichkeit, eine kurze Einführung in diese Anwendung an den Anfang zu stellen. Kapitel 2 beschreibt deshalb das Userinterface für Administratoren und Nutzer.
Die in diesem Szenario verwendeten Technologien XML und Web Development werden in den beiden folgenden Kapiteln 3 und 4 fundiert dargestellt und erläutert. Der Schwerpunkt liegt dabei immer auf den Aspekten, die im Beispiel zum Tragen kommen. Die Metasprache XML wird dabei im Bottom - Up - Prinzip erläutert, d.h. zunächst werden elementare Regeln eingefügt um darauf aufbauend fortgeschrittenere Anwendungen wie XSL darzustellen. Der Themenkomplex Web Development im Kapitel 4 wird zunächst historisch betrachtet, da sich viele Gründe für die aktuellen Architekturprinzipien aus Erfahrungen in der Vergangenheit ableiten. Im Anschluss wird das MVC - Paradigma vorgestellt, welches heute als dominierendes Architekturprinzip gilt.
Im Kapitel 5 wird auf Basis der zuvor eingeführten Technologien und Paradigmen das anfangs eingeführte Beispiel im Detail beschrieben und dabei insbesondere auf die Verbindung von Theorie und Praxis abgestellt.
Im letzten Kapitel werden aktuelle Entwicklungen und Frameworks vorgestellt, die die Art und Weise der Entwicklung von Applikationen im Umfeld des Internets erheblich verändern werden. Hier soll vor allem deutlich werden, dass die vorliegende Arbeit lediglich ein Schnappschuss des gegenwärtigen Stands der Technik in einem sich permanent weiterentwickelnden Umfeld ist.
2. Die Applikation „handyEngine“
2.1. Umfeld und Intention
Das Mobilfunkunternehmen ePlus betreibt im Rahmen des Customer Relationship Managements eine Telefonhotline als 1st Level Support. Um die Kundenzufriedenheit auf einem hohen Niveau zu halten, ist es für die Hotline Agents essentiell schnell und umfassend zu allen Fragen der Kunden Auskunft erteilen zu können. Nicht nur die, zum Teil sehr komplexen, Vertragsarten und rechtlichen Rahmenbedingungen müssen jedem Agent bekannt sein, sondern auch aktuelle Informationen wie zum Beispiel Netzstörungen oder Aktionen des Kampagnenmanagements.
Neben der intensiven Schulung aller Call Center Mitarbeiter werden diese durch das Informationsportal „EHB“ bei Ihrer täglichen Arbeit unterstützt. Dieses bietet direkten Zugriff auf rund 8000 Seiten redaktionell bearbeiteter Texte und Grafiken. Zur Pflege dieses Pools unterhält ePlus ein etwa 20 Personen starkes Team technischer Redakteure, die, jeweils mit eigenem Kompetenzbereich, Fakten sammeln und aufbereiten.
Zur optimalen Unterstützung dieses Teams wurde ein leistungsfähiges Content Management System entwickelt, das durch die konsequente Trennung von Inhalt und Layout, die medienunabhängige Erstellung von so genannten „InfoObjekten“ in einem Repository erlaubt und Workflowfunktionen für deren Pflege bereitstellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Komponentendiagramm EHB
„Kanalredakteure“ nutzen die so verfügbaren Inhalte um damit beispielsweise Webseiten mit einheitlichem Layout zu publizieren. Einer der so versorgten Kanäle ist das, vor allem in den Call Centern genutzte, „elektronische Handbuch (EHB)“. Ein großer Teil der von den Call Centern bearbeiteten Kontakte lässt sich dem Themenkomplex Mobiltelefonauswahl und -benutzung zuordnen. Insbesondere Schwierigkeiten bei der Bedienung der Geräte nehmen einen wichtigen Platz ein und fordern die Mitarbeiter der Hotline besonders, da sich die Zahl der von ePlus vertriebenen Modelle auf inzwischen nahezu 100 summiert hat. Die redaktionelle Betreuung dieses Bereichs wurde bisher von 2 technischen Redakteuren übernommen, die über die spezifischen Kompetenzen verfügen. Die Publikation erfolgte im Rahmen des „EHB“. Da die Strukturierung der Inhalte - in diesem Fall vor allem Bedienungsanleitungen - für jedes Telefon ähnlich erfolgt, ergeben sich perpetuierte Arbeitsabläufe bei der Pflege von Ablagestrukturen im Repository sowie der Komposition von Webseiten. Eine weitergehende Unterstützung durch das System stellt also ein offensichtliches Rationalisierungspotenzial dar. Wird dieses genutzt, kann sich der Redakteur seiner eigentlichen Aufgabe widmen.
Neben den Vorteilen, die eine gesonderte Berücksichtigung des Bereichs „Mobiltelefone“ für den Redakteur mit sich bringt, kann auch der Leser von einem angepassten Layout profitieren. Die bisherige Lösung im Rahmen des „EHB“ erlaubt zwar die Nutzung spezifischer Templates, kann jedoch lediglich eine eindimensionale Navigation in Form der hierarchischen Kategorisierung von Webseiten bieten da es sich hier um eine contentunabhängige Universallösung handelt. Insbesondere inhaltliche Faktoren, wie zum Beispiel technische Daten können für Orientierungsfunktionen nicht genutzt werden.
Motiviert durch diese, für alle Seiten unbefriedigende, Situation wurde eine Vision entwickelt, die zwei Ziele definiert:
− Masterstruktur: uniforme Inhalte sollen nur einmal strukturiert werden müssen − spezialisiertes Interface: contentbasierte Funktionalität generiert Mehrwert
Die Aufgabe umfasst also eine vollständig vertikal integrierte Lösung, die vom Zugriff auf das Repository über die Aufbereitung der Inhalte bis zur Bereitstellung erweiterter Suchfunktionen alle Aspekte einer webbasierten Applikation tangiert.
2.2. Funktionsumfang
2.2.1. Nutzer - Interface
Da es in der täglichen Praxis des Call Centers meist um Fragen zu bereits verkauften Mobiltelefonen geht, steht der schnelle Zugriff auf ein bekanntes Modell im Vordergrund. Das Layout der Anwendung trägt dem Rechnung, indem sichergestellt ist, dass jedes Modell mit maximal 2 Nutzeraktionen erreichbar ist.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Screenshot handyEngine Startseite
Grundsätzlich gliedert sich das Interface dazu in 2 Bereiche, die als HTML Frames implementiert wurden. Der obere Frame erlaubt den Zugriff auf die Hauptfunktionen „Übersicht“, „Berater“ und „Vergleich“ sowie einen Schnellzugriff mittels Auswahl von Hersteller und Modellname (optional). Dieser Frame bleibt in jeder Situation unverändert, so dass dem Nutzer immer die Möglichkeit bleibt, zur Ausgangssituation zurückzukehren. Der untere Frame bietet Platz um die Ein- und Ausgaben der jeweiligen Funktion darzustellen. So können hier beispielsweise Suchergebnisse in Form von Thumbnails oder die Bedienungsanleitungen eines selektierten Modells eingeblendet werden. Bei Bedarf ist dieser Frame vertikal scrollbar. Grundsätzlich kann durch Klick auf ein Thumbnail immer zur Detailseite eines Modells gesprungen werden, um technische Daten und Bedienungsanleitungen abzurufen.
Da als unternehmensweiter Standard Netscape Navigator 4.7x vorgegeben ist, wurde das Layout für diesen Browser optimiert, dabei jedoch auch die Darstellung in alternativen Browsern berücksichtigt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Screenshots handyEngine Funktionsseiten
Als Mimimalanforderung können die Unterstützung von HTML 3.2 sowie von CSS 1 genannte werden. Sofern verfügbar, werden Javascript- und Cookie - Unterstützung genutzt, um Angaben im „Handyberater“ persistent beim Nutzer zu hinterlegen und ihm so eine erneute Eingabe bei wiederholtem Aufruf der Seite zu ersparen.
Die Steuerung der Anwendung erfolgt vollständig über URL - Parameter. Das heißt, alle Zustände in den einzelnen Frames können mittels spezifischer URLs reproduziert werden. Dies gilt auch für die komplexen Suchabfragen im „Handyberater“. Dieser Umstand ermöglicht es dem Nutzer auch, einzelne Zustände als Link in seine „Bookmark“ - Liste aufzunehmen. Im folgenden sind die Hauptfunktionen kurz umrissen:
− Übersicht im unteren Frame werden alle als „im Shop verfügbar“ gekennzeichneten Handymodelle als Thumbnails aufgeführt.
− Berater im unteren Frame wird eine detaillierte Parameterauswahl angezeigt, die es ermöglicht, spezialisierte Selektionen in der Modelldatenbank vorzunehmen. Das Ergebnis der Suche wird im Stil der Übersicht dargestellt.
− Vergleich im unteren Frame werden die Parameter von zwei Modellen tabellarisch gegenübergestellt. Die Auswahl der Modelle erfolgt im Stil des Schnellzugriffs
− Schnellzugriff im oberen Frame ermöglichen zwei Drop - Down - Listen die Auswahl von Hersteller und Modell. Nach erfolgter Selektion des Herstellers wird die Modellliste mit passenden Einträgen gefüllt. Der Klick auf „auswählen“ führt bei selektiertem Hersteller auf eine „Thumbnail“ - Übersicht der Modelle des jeweiligen Herstellers und bei bereits gewähltem Modell direkt zur Detailseite dieses Modells.
− Details Wurde auf einem der beschriebenen Wege ein Modell eindeutig selektiert, wird dieses mit Abbildung und technischen Daten im unteren Frame präsentiert. Am rechten Rand ist eine 2 - stufige hierarchische Mikronavigation verfügbar, die Bedienungsanleitungen thematisch sortiert anbietet.
Zusätzlich sind zur optimalen Unterstützung der Bedienungsanleitungen Macromedia Flash - Animationen implementiert. Da diese jedoch vom System, abgesehen von der Einbindung in die HTML - Seiten, wie gewöhnliche Abbildungen behandelt werden, sollen sie ihr nicht weiter betrachtet werden. Sowohl Seiten mit statischem als auch solche mit dynamischen Inhalten sind das Ergebnis von XSLT Transformationen und somit leicht modifizierbar.
2.2.2. Admin - Interface
Wie im Kapitel 2.1 bereits ausgeführt, lässt sich die vorgestellte Anwendung konzeptionell zwischen Repository und Client PC anordnen. Sie macht dem Client die Inhalte des Repositorys zugänglich indem sie diese mithilfe von Templates in ein sinnvolles Layout einpasst und weitere Funktionen zur Navigation hinzufügt. Es ist offensichtlich, dass in dieser Situation viele Funktionen parametrisiert sein müssen, um den langfristigen Betrieb gewährleisten zu können. Zu diesem Zweck wurde eine leistungsfähige Administrationskomponente entwickelt, mit der in erster Linie das Erscheinungsbild den aktuellen Gegebenheiten angepasst werden kann.
Im Wesentlichen sind hier die verfügbaren Modelle sowie das spezifische Layout inklusive der Gestaltungselemente, wie zum Beispiel die verwendeten Grafiken, zu nennen. Zusätzlich besteht die Möglichkeit, die in der Suche angebotenen Modellmerkmale in Schlagwortlisten zu pflegen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Sequenzdiagramm Modellreferenzierung
Damit ein Modell in der Anwendung berücksichtigt wird, muss es dem System bekannt gemacht werden. Hierzu wird ein „InfoObjekt“ aus dem Repository referenziert. Dabei werden der Name des Modells, der Hersteller sowie die SAP - Materialnummer als eindeutiger Schlüssel übernommen. Diese Stammdaten werden durch Bewegungsdaten, etwa die aktuelle Verfügbarkeit in den Shops, ergänzt. Der Anwendung ist das jeweilige Modell nun inklusive aller technischen Daten (aus dem referenzierten InfoObjekt) bekannt. Gegebenenfalls vorhandene Bedienungsanleitungen können nun mittels der, ebenfalls im Administrationstool hinterlegten, „Masterstruktur“ gefunden werden.
Diese Struktur definiert allgemeingültig die, für alle Modelle gleich strukturierte, Ablage von „InfoObjekten“ für Bedienungsanleitungen. Dazu wird für jeden Navigationseintrag in der Mikromavigation der „Handydetailseite“ der Ablagepfad zum korrespondierenden „InfoObjekt“ im Repository angegeben.
Abbildung in dieser Leseprobe nicht enthalten
Zusätzlich besteht die Möglichkeit, jeder Handydetailseite ein Template zuzuordnen. Diese werden ebenfalls, zusammen mit dem Templates für Systemseiten, als XSLT - Dokumente im Administrationstool gepflegt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: Screenshot handyEngine-Admin Interface
Da als Application Server für die Gesamtanwendung Lotus Domino vorgegeben wurde, konnte bei der Implementierung des Administrationstools auf die RAD Funktionen dieser Plattform zurückgegriffen werden, was den Entwicklungsaufwand erheblich reduzierte.
3. XML und Substandards
3.1. Ziele und Begriffe
3.1.1. Entwicklung
Der Bedarf nach Möglichkeiten Informationen mit weiteren Angaben, zum Beispiel ihrer Darstellung in einem spezifischen Medium anzureichern, besteht schon sehr lange. Waren es am Anfang Schriftsetzer, die mittels eines einheitlichen Satzes von Zeichen den zu druckenden Text auszeichneten, war es spätestens mit der Einführung der IT in der Dokumentenverarbeitung unumgänglich, neben dem reinen Text weitere Vorgaben zur Art und Weise des Drucks zu machen.
Der Schritt von physikalischen Angaben, wie zum Beispiel „Arial, 9pt, bold“, hin zur logischen Auszeichnung mit zentraler Formatierung, wie zum Beispiel „.header“ - auch bekannt als „Formatvorlage“ in Textverarbeitungssystemen, ist dann nicht mehr weit. Da zunächst jedes verfügbare System eine eigene Konvention für diese Form der Auszeichnung vorsah („generic coding“), kam es, insbesondere in großen Organisationen, schnell zu Problemen beim Austausch entsprechender Dokumente. Um diesem Missstand zu begegnen, gab es schon früh Bestrebungen, einen einheitlichen Satz von Markierungen zu entwickeln, den jedes System „versteht“. Die erste Übereinkunft in diesem Zusammenhang stellt GML („Generalized Markup Language“)4 dar. Die Entwicklung geht auf eine Arbeitsgruppe bei IBM zurück, die 1969 bereits bekannte Verfahren vereinheitlichte und zusätzlich das Konzept eines formal definierten Dokumententyps mit eingebetteten Elementen einführte. Da IBM zu diesem Zeitpunkt der weltweit zweitgrößte Verlag war, etablierte sich mit GML quasi ein Industriestandard.
10 Jahre später begannen sich auch die wichtigen Standardisierungs- organisationen mit diesem Thema zu beschäftigen. Das erste Komitee richtete 1978 das American National Standards Institute (ANSI) ein, das 1980 einen ersten „working draft“ der „Standard Generalized Markup Language (SGML)“ veröffentlichte und 1986, nachdem es von der International Organisation for Standardization (ISO) anerkannt worden war, den endgültigen Text als ISO8879:1986 publizierte. Dieser basierte auf GML, enthielt jedoch Konzepte für „short references“ und „link processes“ sowie einige andere Erweiterungen.
Weitere 10 Jahre später, 1996, ergriff Jon Bosak von Sun Microsystems die Initiative und rief eine Arbeitsgruppe beim W3C ins Leben, die sich zum Ziel setzte, eine für das Internet geeigneten Adaption von SGML zu entwickeln. Die komplexe Spezifikation von SGML war für die schnelle Verbreitung im Netz kontraproduktiv, da es kaum Implementierungen gab. Folglich wurde eine Reduktion von Komplexität und Implementierungsaufwand auf etwa 20% vorgenommen bei der jedoch 80% der SGML Funktionalität erhalten blieb5. Dieses 100% SGML konforme Arbeitsergebnis wurde 1998 als „Recommendation“ veröffentlicht und „eXtensible Markup Language (XML)“6 genannt. Wie SGML handelt es sich um eine Metasprache, die genutzt werden kann, um eigene Auszeichnungssprachen zu definieren. Diese Definitionen können, sofern sie vom W3C ebenfalls als „Recommendation“ veröffentlicht sind, zu XML Substandards werden. Ein gutes Beispiel hierfür ist XHTML.
3.1.2. Ziele von XML
Bei der Entwicklung von XML verfolgte das W3C verschiedene Ziele, die sämtlich einer höheren Akzeptanz im Internet dienen sollen. Deshalb gilt:
− XML soll sich im Internet auf einfache Weise nutzen lassen.
− XML soll ein breites Spektrum von Anwendungen unterstützen. − XML soll zu SGML kompatibel sein.
− Es soll einfach sein, Programme zu schreiben, die XML-Dokumente verarbeiten. − Die Zahl optionaler Merkmale in XML soll minimal sein, Idealerweise Null. − XML-Dokumente sollten für Menschen lesbar und angemessen verständlich sein. − Der XML-Entwurf sollte zügig abgefasst sein.
− Der Entwurf von XML soll formal und präzise sein.
− XML-Dokumente sollen leicht zu erstellen sein.
− Knappheit von XML-Markup ist von minimaler Bedeutung.
3.1.3. wellformed XML
Wie oben bereits dargestellt, handelt es sich bei XML um eine Metasprache, die allgemeine Regeln zur Definition anderer Sprachen bereitstellt. Eine dieser Regeln wird als „wellformedness“ bezeichnet und umfasst die wesentlichen syntaktischen Regeln, die beim Erstellen eines XML Dokuments beachtet werden müssen.
Zunächst muss jedes XML Dokument einem definierten Aufbau folgen:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: Aufbau eines XML Dokuments
Im Prolog werden „Processing Instructions“ festgelegt sowie die „Document Typ Definition“ definiert, auf die sich das Dokument bezieht. Danach folgen die Elemente des Dokuments, die die eigentlichen Nutzdaten enthalten. Alle Elemente werden in „Tags“ eingeschlossen. Dabei gilt7:
− Alle Elementattributwerte müssen in Anführungsstrichen eingeschlossen sein. − Ein Element muss sowohl ein Start-Tag als auch ein Ende-Tag besitzen, es sei denn es ist ein leeres Element.
− Wenn ein Tag ein allein stehendes leeres Element ist, muss es einen schließenden Schrägstrich (/) vor dem Ende des Tags enthalten. − Alle Start-Tags und Ende-Tags müssen richtig ineinander geschachtelt sein. − Isolierte Markup - Zeichen sind im laufenden Text nicht erlaubt. < oder & müssen stattdessen Entity - Referenzen benutzen. Außerdem muss die Zeichenfolge „]]>“ als „]]>“ geschrieben werden, wenn sie als regulärer Text benutzt wird.
− Wohlgeformte XML - Dokumente ohne eine entsprechende DTD dürfen defaultmäßig nur Attribute des Typs CDATA besitzen.
Die Einhaltung dieser Regeln stellt sicher, dass jeder Parser das XML Dokument fehlerfrei einlesen kann. Umgekehrt bedeutet es für alle Parser, das sie die beschriebenen Funktionen implementieren müssen. Es handelt sich also um eine rein technische Konvention mit der eine möglichst weitgehende Interoperabilität sichergestellt werden soll. Hierzu zählt im Übrigen auch die Unterstützung von UTF-8 und UTF-16 (Angabe im Prolog) für die Codierung des im Text verwendeten Zeichensatzes, was vor allem der einheitlichen Behandlung von Sonderzeichen zu Gute kommt.
3.1.4. valid XML
Wie oben bereits ausgeführt, enthält jedes XML Dokument im Prolog eine „Document Type Defnition (DTD)“. Diese kann „inline“ im Dokument definiert sein, als externe Quelle referenziert werden oder beide Formen verbinden. Die Angabe erfolgt in einer Instruktion der Form <!DOCTYPE Wurzel-Element SYSTEM | PUBLIC [„ Name “] „ URI_der_DTD “> Das XML Dokument ist damit fest einem Dokumententyp zugeordnet und soll die dort hinterlegten Vorschriften erfüllen. Sofern das der Fall ist, spricht man von gültigem XML. Für diesen Check wird ein validierender Parser benötigt. Insbesondere für den Austausch von Dokumenten, ist es wichtig, dass beide Seiten sich an eine vorher vereinbarte Struktur halten. Damit dies sichergestellt werden kann, wird eine Schnittstellenbeschreibung in Form einer DTD oder eines Schemas festgehalten, sodass beide Seiten automatisiert prüfen können, ob ein XML Dokument der Vereinbahrung entspricht. Würde beispielsweise das Fehlen eines Elements im empfangenden System einen schwerwiegenden Fehler hervorrufen, kann mittels des vorherigen valid - Check das Dokument sofort zurückgewiesen werden.
Die Möglichkeit selbst definierte Standards automatisch zu validieren trägt maßgeblich zur Stabilität und Zuverlässigkeit der gesamten IT - Infrastruktur bei.
Alternativ existiert jedoch auch die Option mit dem Attribut „standalone=yes“ explizit auf die Verknüpfung mit einem Dokumenttyp zu verzichteten.
3.1.5. Namespaces
Da XML seinen wirklichen Nutzen nur zeigt, wenn man konsequent von dessen Erweiterbarkeit Gebrauch macht, das heißt aufbauend auf XML eigene Markupsprachen entwickelt, gibt es eine nicht koordinierbare Entwicklung von unterschiedlichsten Dokumenttypen. Da für XML außerdem die Konvention geprägt wurde, für Tags möglichst „sprechende“ Bezeichnungen zu wählen führt dies bei der Vielzahl von Dokumenttypen, die zum Teil auch für gleiche Themengebiete eingesetzt werden, automatisch zu Überschneidungen bei der Benennung von Tags. Eine häufig auftretende Situation ist die Verwendung des Elements „<name>“, der in fast jedem Kontext sinnvoll eingesetzt werden kann. Um trotzdem Elemente aus beiden Dokumenttypen in einem Dokument nutzen zu können ist es erforderlich, eine erweiterte Notation zu verwenden. Mit der XML Spezifikation wurde deshalb das Konzept der Namespaces eingeführt, das es erlaubt, jedem Tag den verwendeten Namensraum voranzustellen. Beispielweise können so XSL Elemente von den XHTML Elementen im selben Dokument unterschieden werden.
Abbildung in dieser Leseprobe nicht enthalten
Um das Kennzeichen für einen Namensraum nutzen zu können, muss dieser als Attribut „xmlns“ eines Elements angegeben werden. Dabei wird das Kürzel in Verbindung mit einer URI deklariert.
Abbildung in dieser Leseprobe nicht enthalten
Die URI ist nicht notwendigerweise eine URL. Es geht vielmehr darum eine eindeutige Identifikation sicherzustellen. Da eine URL qua Definition eindeutig (unique ressource locator) ist, hat sich diese Verwendung als Konvention durchgesetzt.
Wird auf die Angabe eines Kürzels verzichtet, handelt es sich um den „Default Namespace“ der allen Elementen ohne eigene Namensraumangabe zugewiesen wird.
3.2. Dokumenttypdefinition
Bei der Beschreibung des Begriffs „valid XML“ ist bereits dargestellt worden, welche Vorteile die eindeutige Definition des Dokumenttyps hat. Diese beschreibt in formalisierter Form die Struktur eines XML Dokuments des entsprechenden Dokumenttyps.
3.2.1. DTD
Aufgrund der SGML - Historie wird für die Dokumenttypdefinition der Standard „Document Type Definition (DTD)“ verwendet. Diese Beschreibung der Grammatik eines XML Dokuments listet alle verfügbaren Elemente mit ihren Attributen, Wiederholungen und Typen sowie der hierarchischen Struktur auf. Dazu wird eine eigene Notation verwendet, welche durch das folgende Beispiel verdeutlicht werden soll:
Abbildung in dieser Leseprobe nicht enthalten
Das Element <firma> enthält ein Element <name> und mindestens ein Element <arbeiter>. Dieses wiederum kann ein Attribut „anrede“ enthalten das die Werte „Herr“ und „Frau“ annehmen kann.
Neben den im Beispiel vorgestellten Elementen einer DTD können weiter Angaben zu Entities und Notationen eufgenommen werden.
3.2.2. XML Schema
Die Verwendung einer DTD ist eine bewährte Methode zur Definition des Dokumententyps und wird im SGML Kontext bereits seit langem eingesetzt. Der breiter werdende Einsatz im Zuge der dynamischen Entwicklung von XML brachte jedoch einige konzeptionelle und praktische Nachteile zum Vorschein, denen mit dem neuen Standard XML Schema8 begegnet werden soll. So schränkt vor allem die fehlende Möglichkeit eine differenzierte Festlegung von Datentypen die Möglichkeiten einer exakten Definition sehr ein. So stehen den 10 möglichen Typen beim Einsatz einer DTD 45 Typen in XML Schema gegenüber. Dabei kann zwischen verschiedenen numerischen Typen, Datum und Boolean unterschieden werden und es lassen sich eigene komplexe Typen aus diesen zusammenstellen. Einen konzeptionellen Nachteil stellt auch die eigene Notation für DTD dar. XML Schema nutzt dagegen selbst wellformed XML und kann deshalb von den vorhandenen Parsern gelesen werden, was den Implementierungsaufwand reduziert. Zur Demonstration wird auch hier Beispiel gegeben:
Abbildung in dieser Leseprobe nicht enthalten
[...]
1 http://www.heise.de/newsticker/data/ciw-15.11.01-001/default.shtml
2 http://www.heise.de/newsticker/data/fr-13.01.01-001/default.shtml
3 http://www.ietf.org/iesg/1rfc_index.txt
4 http://www.oasis-open.org/cover/sgmlhist0.html
5 http://www.softwareag.com/germany/news/01_01/xml_co_t4.htm
6 http://www.w3.org/TR/REC-xml
7 nach Eckstein, R. (2000), S.19.
8 http://www.w3.org/XML/Schema