Abbildungsverzeichnis
Abkürzungsverzeichnis
1. Einleitung
1.1 Ziel der Arbeit
1.2 Aufbau der Arbeit
1.3 Begriffsklärung
2. Grundlagen von XML
2.1 XML im Überblick
2.1.1 Erweiterbare Auszeichnungssprache
2.1.2 Abgrenzung zu HTML
2.1.3 Teilmenge von SGML
2.1.4 Ziele von XML
2.1.5 Aktuelle Version
2.2 Leistungsmerkmale von XML
2.2.1 Erweiterbarkeit und eindeutige Struktur
2.2.2 Trennung von Inhalt und Layout
2.2.3 Verbreitung durch Einfachheit
2.3 Nachteile von XML
2.3.1 Hoher Speicherbedarf
2.3.2 Niedrige Verarbeitungsgeschwindigkeit
2.3.3 Vielzahl von Derivaten
2.4 Aufbau von XML-Dokumenten
2.4.1 Wohlgeformte und gültige Dokumente
2.4.2 Prolog eines Dokuments
2.4.3 Elemente
2.4.4 Attribute
2.4.5 Zeichendaten
2.4.6 Kommentare und Prozessor-Anweisungen
2.4.7 Entities
2.5 XML begleitende Standards
2.5.1 DTD versus XML-Schema
2.5.2 Namensräume
2.5.3 XLinks und XPointer
2.5.4 Stylesheets
2.5.5 XHTML
2.6 Schritte der Verarbeitung von XML-Dokumenten
2.6.1 Editor
2.6.2 Parser
2.6.3 Anwendung
3. Grundlagen von Content Management Systemen
3.1 Definition des Begriffes Content Managment System
3.1.1 Content
3.1.2 Content-Life-Cycle
3.1.3 Content Management System
3.1.4 Abgrenzung
3.2 Einsatzründe und Anforderungen an ein CMS
3.2.1 Aktualität und Qualität
3.2.2 Pflege ohne technische Kenntnisse
3.2.3 Versions- und Konsistenzprüfung
3.2.4 Wiederverwendung von Inhalten
3.3 Bestandteile eines CMS
3.3.1 Contentverwaltung
3.3.2 Workflowmanagement
3.3.3 Benutzer- und Zugriffsverwaltung
3.3.4 Schnittstellen
3.3.5 Server und Clients
3.4 Problembereiche von CMS
3.4.1 Motivation und Akzeptanz
3.4.2 Sicherheit
3.4.3 Hoher Anfangsaufwand
3.4.4 Refinanzierung und Messbarkeit des Nutzens
3.5 Derzeitige Trends im Bereich von CMS
3.5.1 Konsolidierung und Verschmelzung
3.5.2 Personalisierung, Cross-Media und Usability
3.5.3 Integration
4. Leistungen von XML für EAI und CMS
4.1 XML als Pflichtkriterium für CMS
4.1.1 CMS und XML
4.1.2 Datenspeicherung in XML
4.2 Gründe für die Integration von CMS und Unternehmenssoftware
4.2.1 Redundanzen und Medienbrüche
4.2.2 Reaktionszeiten
4.2.3 Funktionsnutzung und Contentgenerierung
4.3 XML als Format zum Datenaustausch
4.3.1 Grundlagen von Enterprise Application Integration
4.3.2 EAI und XML
4.3.3 Grenzen von XML
4.4 Auf XML basierende Formate zum Datenaustausch
4.4.1 RDF
4.4.2 NewsML
4.4.3 ICE
4.5 Datentransformation
4.5.1 Extract, Transform and Load
4.5.2 XSLT
4.6 Fazit
Literaturverzeichnis
Anhang A: Einfaches Beispiel für ein wohlgeformtes XML-Dokument
Anhang B: Beispiel zur Verwendung von Entity-Verweisen
Anhang C: Beispiel für eine DTD
Anhang D: Beispiel für ein XHTML Dokument
Abb. 1: Syntax eines Container-Elementes
Abb. 2: Syntax eines leeren Elementes
Abb. 3: Benutzung von externen Entities
Abb. 4: Phasen des Content-Lifecycles
Abbildung in dieser Leseprobe nicht enthalten
Seit seiner Einführung in den späten 90er Jahren ist XML zu einem der wichtigsten Themen für Unternehmen aus dem Bereich der Informationstechnologien (IT) geworden. In den Pflichtenheften der Anwender besitzt eine Kompatibilität zu XML höchste Priorität. Und nahezu alle namhaften Softwarehersteller arbeiten mit Hochdruck daran eine XML-Unterstützung in ihre Produkte zu integrieren. Die schnelle Verbreitung führte jedoch auch zu einigen Missverständnissen, wie z. B. dem Glauben XML stelle einen Ersatz für HTML dar.1
Parallel dazu hat sich mit Content Management Systemen eine neue Klasse von Anwendungssoftware entwickelt. Nachdem diese zunächst vornehmlich zur Verwaltung von umfangreichen Websites Anwendung fanden, beginnen nun auch immer mehr Unternehmen die keine eigene Website betreiben ein solches System zu installieren.2
Beide Themen werden in dieser Arbeit behandelt. Dabei liegt der Schwerpunkt auf der Betrach- tung von XML. Content Management Systeme, und im speziellen die Integration dieser in die weitere IT-Landschaft eines Unternehmens, dienen hierbei als Beispiel einer Anwendungsmög- lichkeit von XML.
Nach dieser Einleitung wird im 2. Kapitel damit begonnen XML und den damit verbundenen Konzepten im Allgemeinen näher zu kommen. Hierzu werden u. a. Begriffsabgrenzungen vorge- nommen und die Vor- und Nachteile sowie die Syntax von XML betrachtet. Kapitel 3 befasst sich dann mit den Grundlagen von Content Managment Systemen. D. h., es wird z. B. näher auf die Bestandteile und die Einsatzgründe eines Content Management Systems ein- gegangen.
Nach dieser zunächst isolierten Annäherung an die beiden Themengebiete wird dann in Kapitel 4 die Synthese vollzogen. Dabei wird aufbauend auf den beiden vorausgehenden Kapiteln zu Beginn die Nützlichkeit von XML für Content Management Systeme im Allgemeinen erörtert. Anschließend wird der Fokus dann auf die Integration gelenkt.
Im Rahmen dieser Arbeit werden des öfteren die Begriffe Ableitung bzw. Derivat verwendet. Diese stellen hier lediglich ein Synonym für eine auf XML basierende Auszeichnungssprache dar. Trotz ähnlicher Verwendung dieser Begriffe im Rahmen der Objektorientierung sind die dahinter stehenden Konzepte nur eingeschränkt vergleichbar.
XML existiert seit 1998 als Empfehlung des World Wide Web Consortium (W3C). Die Abkürzung XML steht für extensible Markup Language.3 Was übersetzt so viel heißt wie erweiterbare Auszeichnungssprache. Zur Definition von XML soll im Folgenden die Bedeutung dieser beiden Wörter erläutert werden.
Eine Auszeichnungs- oder Markup-Sprache stellt eine Menge von Symbolen zur Verfügung, um einen Text zu strukturieren.4 D. h., den einzelnen Teilen eines Textes können mittels dieser Sym- bole Metainformationen zugeordnet werden. Eine solche Metainformation kann z. B. der Nach- name des Autors oder die Information, dass es sich beim Wort um eine Überschrift handelt, sein.
Ein populäres Beispiel für eine Auszeichnungssprache ist die Hypertext Markup Language (HTML).Sie wurde 1989 von Tim Berners-Lee entwickelt. Intention war es, den Informationsaus- tausch über unterschiedliche Hard- und Softwaresysteme hinweg zu ermöglichen.5 Die Syntax von XML ähnelt der von HTML. Beide verwenden so genannte Tags zur Auszeich- nung. Allerdings verwendet XML eine strengere Syntax als HTML (s. a. Abschnitt 2.5.5).6 Trotz der ähnlichen Syntax unterscheiden sich Beide grundlegend. HTML besitzt einen fest vor- gegebenen Satz von Auszeichnungselementen, während XML es erlaubt, sich seine eigenen Aus- zeichnungselemente zu definieren.7 Hierin liegt der Ursprung des Wortes erweiterbar (extensible) im Namen von XML. Genauer genommen ist XML selbst sogar keine Auszeichnungssprache, sondern vielmehr ein Werkzeug um sich eine eigene, auf die individuellen Bedürfnisse zuge- schnittene Markup-Sprache zu erstellen.8
Das Gerücht, dass XML einen Ersatz für HTML darstellt, ist somit von der Hand zu weisen. Vielmehr dient XML bereits dazu eine sauberere Version von HTML mit dem Namen XHTML zu definieren (s. Abschnitt 2.5.5).9
Die Erweiterbarkeit ist auch Leistungsmerkmal von SGML, der Standard Generalized Markup Language. Sie wurde 1986 als ISO-Standard 8879 veröffentlicht.10
SGML stellt genau wie XML eine Metasprache dar. Eine Metasprache ist ein Werkzeug zur Erstellung eigener Auszeichnungssprachen.11 Mittels sogenannten Dokumenttyp Definitionen (DTD) wird es in SGML ermöglicht, sich eigene Auszeichnungselemente zu definieren und diese zur Strukturierung eigener Texte anzuwenden. Eine DTD sorgt dafür, dass ein SGML-Dokument selbsterklärend ist.12
Wenn also schon vor 1998 ein solches Mittel existierte, stellt sich die Frage nach der Existenzberechtigung von XML. Zu begründen ist diese durch die Komplexität von SGML. Diese ermöglicht es nur Experten ihre Texte mit strukturierten Auszeichnungen zu versehen. XML stellt eine Teilmenge von SGML dar. Der Funktionsumfang ist geringer, dementsprechend aber auch die Komplexität der Sprache. Dies erleichtert den Einsatz von XML im Vergleich zu SGML.13 Neben dem Bestreben die Erstellung von eigenen Auszeichnungssprachen zu erleichtern, waren noch weitere Ziele bei der Entwicklung von XML richtungsweisend.
Die folgenden Ziele von XML sind Bestandteil der XML-Empfehlung des W3C:14
- XML soll unkompliziert über das Internet nutzbar sein.
- XML soll von möglichst vielen Anwendungen unterstützt werden.
- XML soll kompatibel zu SGML sein.
- Es soll einfach sein, Programme zur Verarbeitung von XML zu schreiben.
- Die Zahl der optionalen Elemente soll auf ein Minimum reduziert werden.
- XML-Dokumente sollen für Menschen lesbar und einfach verständlich sein.
- Der XML-Entwurf soll möglichst kurz gehalten werden.
- Der XML-Entwurf soll präzise und formal formuliert sein, um eine Verbreitung von XML zu fördern.
- XML-Dokumente sollen einfach zu erstellen sein.
- Die Schaffung von Möglichkeiten zur Abkürzung des XML-Codes ist unwichtig.
Die XML-Empfehlung des W3C liegt seit 06. Oktober 2000 in der Version 1.0 (Second Edition) vor. Die Second Edition stellt keine komplett neue Empfehlung des W3C dar, sondern korrigiert lediglich einige kleinere Fehler, die seit der Veröffentlichung der ursprünglichen Empfehlung am 10. Februar 1998 aufgefallen sind.15 Es wurde keine neue Version benötigt, da sich die Definition von wohlgeformten Dokumenten (s. a. Abschnitt 2.4.1) nicht geändert hat.16
Die Version 1.1 des XML-Standards befindet sich gerade im Entwicklungsprozess. Sie lag zum Zeitpunkt der Erstellung dieser Arbeit als Vorschlag zu einer Empfehlung (Candidate Recommendation) beim W3C vor.17 Von den beinhalteten Änderungen gegenüber der Version 1.0 sollen die Wesentlichsten im Folgenden kurz vorgestellt werden.
Unter anderem wird für die Unterstützung von Unicode 3.1 gesorgt. Eine Veränderung der Restriktionen bei der Namensvergabe von Elementen sorgt dafür, dass ab Version 1.1 alle Zeichen, die nicht ausdrücklich verboten sind, für Elementnamen Verwendung finden dürfen. Zur Unterstützung von Großrechnern werden weitere Zeilenabschlußzeichen zur Spezifikation hinzugefügt. Im Gegensatz zu den früheren Änderungen wird für diese Änderungen ein Versionssprung nötig, da Dokumente in XML-Version 1.1 von Software nach XML-1.0-Spezifikation nicht mehr als wohlgeformt akzeptiert werden würden.18
Im vorherigen Abschnitt wurde bereits die Erweiterbarkeit von XML angesprochen. Sie ist als das bedeutenste Leistungsmerkmal von XML zu sehen.19 Die Möglichkeit, sich für jedes Anwen- dungsgebiet eine spezielle Auszeichnungssprache zu schaffen, ist nicht zu unterschätzen. Zum einen kann die Bezeichnung, Art und Anzahl der Strukturierungselemente so gewählt wer- den, dass sie zur jeweiligen Gegebenheit passt. Dies fördert die Lesbarkeit von XML- Dokumenten für Menschen und gewährleistet die Übertragbarkeit von XML auf jegliche Art von Anwendungsfällen.20
Zum Zweiten wird so ein entscheidender Beitrag zur Zukunftssicherheit von XML geleistet. Es ist jederzeit möglich, mit XML definierte Auszeichnungssprachen an wechselnde Umstände und Anforderungen der Nutzer anzupassen.21
Die Erweiterbarkeit für sich alleine wäre jedoch von begrenzter Nützlichkeit, wenn darunter die Kompatibilität zu auf XML basierender Software leiden würde. XML-Dokumente sollen trotz aller gewährten Freiheit von jeder der XML-Spezifikation entsprechenden Applikation gelesen werden können. Dazu bedarf es einiger strenger Regeln für die Struktur von Dokumenten. Diese erschweren zunächst die Erstellung von XML-Dokumenten. Gehorcht jedoch ein Dokument diesen Regeln so gilt es als wohlgeformt (s. a. Abschnitt 2.4.1) und kann von jeder XML- Software verarbeitet werden.22
Das Konzept der strukturierten Auszeichnung sieht eine klare Trennung von Inhalt und Layout vor. Dieses Prinzip ist prägend für XML. Ein XML-Dokument beschreibt also lediglich die Struk- tur von Informationen. Aussagen über die Darstellungsweise können nicht getroffen werden. Hierfür sind weitere Dokumente, die so genannten Stylesheets, von Nöten.23 Die Trennung von Darstellungsweise und tatsächlichem Inhalt einer Information hat die folgenden Vorteile: Die Formatierungsinformationen aus einem Stylesheet können auf eine Vielzahl von Dokumenten angewandt werden. Somit kann ohne großen Aufwand ein einheitliches Erscheinungsbild von mehreren Dokumenten erreicht werden. Eine spätere Änderung des Designs kann zentral vorge- nommen werden und muss nicht für jedes Dokument einzeln durchgeführt werden.24 Plattformunabhängigkeit und Wiederverwendbarkeit sind weitere Vorteile dieses Ansatzes. So kann für jede Anwendung oder auch Plattform eine spezifische Darstellungsform gewählt wer- den. Die Ausgabe auf dem Drucker kann anders gestaltet werden, als die Bildschirmansicht, die Ausgabe auf dem Display eines Personel Digital Assitent (PDA) oder gar die Sprachausgabe. Eine neue Datei mit Darstellungsinformationen genügt, um alle Dokumente für die Darstellung auf einer weiteren Plattform umzugestalten.25
Alle bisher beschriebenen Leistungsmerkmale von XML treffen auch auf SGML zu. Der entscheidende Vorteil von XML gegenüber SGML liegt jedoch, wie schon im Überblick angedeutet, in der Einfachheit. Beim Entwurf von XML wurde bewußt einiges vom Funktionsumfang von SGML geopfert, um die Benutzung einfach zu gestalten. Nach kurzer Einarbeitung bereitet weder die Erstellung einer eigenen Auszeichnungssprache auf Basis von XML noch die Programmierung von Software zur Verarbeitung von XML Probleme.26
Die Einfachheit ist auch als Hauptgrund für die rapide Verbreitung von XML zu sehen.27 Kaum andere Technologien haben in so kurzer Zeit eine so große Unterstützung erlangt. Mittlerweile gibt es für nahezu jeden Anwendungsfall eine auf XML basierende Markupsprache. Die Vielzahl von Anwendungen, die XML mittlerweile unterstützen, ist somit ein weiterer Pluspunkt von XML.28
Trotz der vielen Vorteile ist XML noch lange kein Allheilmittel, wenn es um die Strukturierung und Speicherung von Daten geht. Nachfolgend sollen deshalb nun einige Nachteile von XML dargelegt werden:
XML ist textbasiert und verwendet den Unicodezeichensatz. Alleine dies führt zu einem Speicherbedarf von 2 Byte pro Zeichen. Der American Standard Code for Information Interchange (ASCII) benötigt im Vergleich dazu nur 1 Byte pro Zeichen.29
Viele Auszeichnungen innerhalb eines Dokumentes erhöhen den Speicherbedarf zusätzlich. XML verfügt aber nicht über ein integriertes Komprimierungssystem. D. h. komprimierte XMLDokumente sind mit keinem XML-Werkzeug mehr benutzbar. Resultierend daraus ist der Speicherbedarf im Vergleich zu anderen Formaten relativ hoch. Es ergeben sich somit Nachteile bei begrenztem Speicherplatz oder Übertragungsvolumen.30
Neben dem hohen Speicherbedarf bringt die Datenhaltung in XML-Dokumenten auch noch eine niedrige Verarbeitungsgeschwindigkeit mit sich.
Dies liegt zum einen daran, dass XML nicht wie z. B. relationale Datenbanken über Optimierungsmechanismen wie Indizes und Hash-Tabellen verfügt.31
Zum anderen müssen XML-Dokumente immer erst komplett eingelesen werden, bevor die eigentliche Verarbeitung beginnen kann. Die Ursache hierfür liegt in der Wohlgeformtheitsprüfung, die erst vollzogen werden kann, wenn das gesamte Dokument eingelesen worden ist.32
Die als Leistungsmerkmal dargestellte Einfachheit und Verbreitung von XML hat auch Nachteile. Es existieren mittlerweile so viele auf XML basierende Auszeichnungssprachen, dass es nicht leicht ist, die richtige für die eigenen Zwecke auszuwählen.33
Viele Software-Anbieter neigen zudem dazu, ihre eigenen Markupsprachen von XML abzuleiten. Somit ist zwar die Unterstützung von XML prinzipiell gegeben, für den Datenaustausch mit An- wendungen anderer Hersteller ist aber weiterhin eine Transformation in das jeweils andere For- mat notwendig.34
Dokumente sind einer der zentralen Aspekte von XML. Ein XML-Dokument besteht nicht zwin- gend nur aus einer Datei, sondern kann sich aus den Inhalten von mehren Dateien zu einer logi schen Einheit zusammensetzen. Man unterscheidet in XML zwischen wohlgeformten und gültigen Dokumenten.35
Wohlgeformte Dokumente entsprechen den in der XML-Spezifikation des W3C definierten Re- geln.36 Die Spezifikation schreibt auch vor, dass jeder XML-Parser (s. a. Abschnitt 2.6.2) ein Do- kument zurückweisen muss, sobald es nicht wohlgeformt ist.37 Die strenge Auslegung ist von Nöten, um zu gewährleisten, dass XML-Parser trotz der Erweiterbarkeit von XML vorhersehbare Ergebnisse liefern.38 Ein Beispiel für ein wohlgeformtes XML-Dokument befindet sich in An- hang A.
Gemäß Empfehlung des W3C39 hat ein wohlgeformtes XML-Dokument den folgenden Aufbau.
- Es ist textbasiert, d. h., es besteht aus Zeichen- und nicht aus Binärdaten.
- Es besteht aus einem Prolog und mindestens einem Element, dem Wurzelelement.
- Das Wurzelelement ist in keinem anderen Element enthalten.
- Start- und End-Tag jedes anderen Elements befinden sich innerhalb desselben Elternele- ments.
- Alle in der Spezifikation aufgestellten Regeln werden eingehalten.
Die Wohlgeformtheitsprüfung gewährleistet, dass ein Dokument den syntaktischen Regeln von XML gehorcht. Um jedoch eine wirkliche eigene Auszeichnungssprache erstellen zu können, muss es auch die Möglichkeit geben, die zulässigen Elemente und ihre semantische Bedeutung festzulegen. Genau diese Aufgabe kommt der Gültigkeitsprüfung mittels Dokumentenmodellen zu.40
Ein Dokumentenmodell ist nichts anderes als eine Darstellung von Konvention über die Bedeutung und Verwendungsmöglichkeiten einzelner Auszeichnungselemente.41 Solche Konventionen sind die Grundlage zur Erstellung eigener Auszeichnungssprachen. Somit stellt auch erst ein Dokumentenmodell die Defintion einer auf XML basierenden Auszeichnungssprache dar.42 Wohlgeformte XML-Dokumente, so genannte Dokumenten-Instanzen, werden mittels Dokumentenmodell auf ihre Gültigkeit hin überprüft. Ein Dokument ist gültig, wenn es wohlgeformt ist und denselben Aufbau hat, wie ihn das Dokumentenmodell vorschreibt.43
Dokumentenmodelle sind immer dann erforderlich, wenn mit XML strukturierte Informationen von mehreren Programmen oder Menschen benutzt bzw. gelesen werden sollen. Ein Dokumen- tenmodell stellt dann sicher, dass alle dieselben Elemente und Attribute in der gleichen Art und Weise benutzen. Gerade für die Verwendung von XML zum Datenaustausch, welcher ja elemen- tarer Bestandteil dieser Arbeit ist, spielen Dokumentenmodelle also eine wichtige Rolle.44 Es existieren momentan zwei ernstzunehmende Ansätze zur Modellierung von Dokumenten: Do- kumenttyp-Definitionen (DTD) und XML-Schemas. Beide werden im Abschnitt 2.5.1 näher be- schrieben.
Nachfolgend sollen nun die einzelnen Bestandteile eines XML-Dokumentes vorgestellt werden. Zur weiteren Abgrenzung der Begriffe gültig und wohlgeformt wird in diesem Zuge ihr Einfluß auf Gültigkeit und Wohlgformtheit von Dokumenten verdeutlicht. Dabei stellt die Beschreibung der Syntax grundsätzlich Wohlgeformtheitsregeln dar, während Gültigkeitsbeschränkungen ex- plizit erwähnt werden.
Der angesprochene Prolog eines Dokumentes kann optional leer bleiben. Er sollte aber zumindest die XML-Deklaration enthalten.45 Diese gibt an, dass es sich bei dem Dokument um ein XMLDokument handelt. Sie enthält ebenfalls Informationen über die verwendete XML-Version. Ein Beispiel für eine XML-Deklaration wäre dementsprechend:
<?xml version=“1.0“?>
Die Bedeutung der Versionsangabe wird spätestens mit angekündigter Version 1.1 des XML- Standards deutlich. XML-Parsern wird es so ermöglicht, zwischen den einzelnen XML- Versionen, und somit auch den unterschiedlichen Wohlgeformtheitsbeschränkungen, zu unter- scheiden.46
Weitere mögliche Angaben in der Deklaration sind die verwendete Zeichenkodierung des Unico- dezeichensatzes (encoding) und der Parameter standalone. Letzterer gibt an, ob das Doku- ment unabhängig verwendbar ist oder ob weitere Dateien hinzugeladen werden müssen.47 Der zweite Teil des Prologes ist die Dokumenttyp-Deklaration. Hier können verschiedene Para- meter zur Überprüfung der Gültigkeit des Dokumentes hinterlegt werden. Dies sind der Name des Wurzelelemts, der Uniform Ressource Identifier (URI) eines Dokumentenmodells sowie interne Markup- und Entity-Deklarationen (s. a. 2.4.7). Die Angabe der Dokumenttyp-Deklaration ist optional, wird sie jedoch angegeben, muss mindestens der Name des Wurzelelementes enthalten sein.48 Existiert keine Dokumenttyp-Deklaration, so kann keine Gültigkeitsprüfung für das Do- kument durchgeführt werden. Sie ist somit von elementarer Bedeutung für die Gültigkeit eines Dokumentes.49
Bestandteil eines jeden XML-Dokuments sind Elemente. Sie dienen zur Strukturierung der ei- gentlichen Information. Unterschieden werden können leere und Container-Elemente. Ein Con- tainer-Element versieht seinen jeweiligen Inhalt mit Metainformationen, während ein leeres Ele- ment eine bestimmte Stelle im Dokument kennzeichnet. Beispielsweise um dort später eine Gra- fik einzufügen.50
Wohlgeformte Container-Elemente zeichnen sich dadurch aus, dass sie sowohl ein Start-Tag (Abb. 1, Punkt 1) als auch ein End-Tag (Abb. 1, Punkt 8) besitzen. Beide umschließen den Inhalt des Elementes (Abb. 1, Punkt 6). Dieser kann aus Zeichendaten, weiteren Elementen, Prozessor- Anweisungen, Kommentaren, Entities oder einem Gemisch von allem bestehen. Die möglichen Inhalte können mittels Dokumentenmodell noch eingeschränkt werden. Der Name des Start- und des Endtags müssen identisch sein (Abb. 1, Punkte 2 und 7). Das End-Tag enthält jedoch zusätz- lich einen Schrägstrich.51
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Syntax eines Container-Elementes, eigene Darstellung in Anlehnung an Ray, E. T. (2001), S. 41
Ein wohlgeformtes leeres Element besteht aus nur einem Tag (Abb. 2, Punkt 1). Dieses enthält mindestens den Namen des Elements (Abb. 2, Punkt 2) sowie einen Schrägstrich vor der abschließenden spitzen Klammer (Abb. 2, Punkt 4). Optional kann ein leeres Element noch Attribute enthalten (Abb. 2, Punkt 3).52
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Syntax eines leeren Elementes, eigene Darstellung in Anlehnung an Ray, E. T. (2001), S. 42
Beide Elemententypen haben gemeinsam, dass sie einen Namen besitzen. Ein Elementname muss mit einem Buchstaben beginnen. Danach kann eine beliebige Zahl von Buchstaben, Zahlen Punk- ten, Bindestrichen und Unterstrichen folgen. Dank der Unicodeunterstützung von XML ist es möglich, als Buchstaben alle Schriftzeichen der Welt zu verwenden. Voraussetzung ist allerdings, dass sie sich innerhalb der in der XML-Deklaration angegebenen Zeichenkodierung befinden.53
Der Name eines Elementes darf theoretisch auch Doppelpunkte enthalten. Aus Gründen der Kompatibilität zu Namensräumen (s. a. 2.5.2) sollte davon allerdings abgeraten werden.54 Damit ein Dokument gültig ist, müssen sämtliche verwendeten Elemente vor Ihrer Verwendung deklariert worden sein. Ihre Inhalte müssen außerdem den in der Deklaration zugelassenen ent- sprechen.55
Es gibt Situationen, in denen mehr Informationen über ein Element erforderlich sind, als der Name des Elements oder sein Inhalt liefern können. In diesem Fall ist es möglich den Elementen noch Attribute zu geben.56
Attribute bestehen aus einem Attributnamen (s. Abb. 1, S. 9, Punkt 4), einem Gleichheitszeichen und einem Attributwert (s. Abb. 1, S. 9, Punkt 5). Für den Namen von Attributen gelten dieselben Beschränkungen wie für Elementnamen. Attributwerte müssen auf jeden Fall in Anführungszei- chen stehen. Der Wert eines Attributes darf zudem keinen externen Entityverweis entahlten (s. a. 2.4.7).57
Bei leeren Elementen stehen die Attribute innerhalb des einzigen Tags (s. Abb. 2, Punkt 3). Ana- log dazu müssen sie sich bei Container-Elementen innerhalb des Start-Tags (s. Abb. 1, S. 9, Punkt 3) befinden. Die Attribute müssen dem Elementnamen folgen und von ihm und von anderen Attributen durch ein Leerzeichen getrennt sein. Die Zahl der Attribute eines Elementes ist genauso wie die Reihenfolge beliebig. Es ist jedoch nicht zulässig, dass ein Attribut innerhalb eines Elementes mehrmals vorkommt.58
Attribute müssen für ein Element deklariert worden und vom deklarierten Typ sein. Im abweichenden Fall gilt ein Dokument nicht als gültig.59
Nachfolgend ein Beispiel für ein Container-Element mit mehreren Attributen:
Abbildung in dieser Leseprobe nicht enthalten
Das Beispiel sagt es aus, der Inhalt eines Container-Elementes kann aus Zeichendaten bestehen. Bei Zeichendaten handelt es sich um den eigentlichen Text bzw. die Daten, die strukturiert werden sollen. Sie können jedes beliebige Zeichen des Zeichensatzes enthalten, welcher in der XMLDeklaration angegeben wurde.60
Einige Zeichen sind allerdings reserviert. D. h., sie dürfen nicht verwendet werden, weil dies bei der Verarbeitung zu Problemen führen würde. Ein Beispiel hierfür ist die öffnende spitze Klammer. Sie ist für Element-Tags reserviert. Reservierte und auf einer Tastatur nicht vorhandene Zeichen können über sogenannte Zeichenentities eingefügt werden (s. a. 2.4.7). Sie werden beim Verarbeiten des Dokumentes durch das entsprechende Zeichen ersetzt.61
Eine wichtige Eigenschaft von Zeichendaten in XML ist, dass alle Zeichen erhalten bleiben. So werden in manchen Auszeichnungssprachen, wie z. B. HTML, mehrere aufeinanderfolgende Trennzeichen zu einem einzigen zusammengefasst. Dies ist bei XML nicht der Fall. In XML bleiben standardmäßig alle Leerzeichen, Tabulatoren und Zeilenvorschübe erhalten.62 Abschnitte, die viele reservierte Zeichen enthalten, können als Abschnitte mit Zeichendaten de- klariert werden. Alles innerhalb eines solchen Abschnittes wird als Zeichendaten interpretiert und direkt an die verarbeitende Anwendung weitergereicht. Begonnen wird ein solcher Abschnitt durch die Zeichenkette <![CDATA[ . Beendet wird er mit folgender Zeichenfolge: ]]> .63
Neben Zeichendaten und Elementen mit ihren Attributen gibt es noch weitere Dinge, die im Hauptteil eines XML-Dokumentes stehen können. So z. B. Kommentare und Prozessor- Anweisungen.
Kommentare dienen, wie in Programmiersprachen auch, dazu, den XML-Quelltext mit Bemerkungen zu versehen. Kommentare gehören im Gegensatz zu den Zeichendatenabschnitten aus Punkt 2.4.5, nicht zum eigentlichen Dokument. Markupbefehle innerhalb eines Kommentares werden dementsprechend ignoriert. Bei Kommentaren bleibt es dem jeweiligen Parser überlassen, ob er sie weiterreicht oder nicht (s. a. 2.6.2).64
Die Syntax von Kommentaren in XML entspricht exakt der von Kommetaren in HTML. Sie beginnen mit den Zeichen <!-- und enden mit --> .65
Genauso wie Kommentare gehören Prozessor- oder Steueranweisungen nicht zum eigentlichen XML-Dokument. Im Unterschied zu Kommentaren müssen sie aber an die verarbeitende Anwendung übergeben werden.66
Die Weitergabepflicht hat auch einen Grund. Prozessor-Anweisungen dienen nämlich dazu, In- formationen zur Verarbeitungsform an bestimmte Anwendungen weiterzureichen. Dies wider- spricht zwar eigentlich dem Prinzip des strukturierten Markup, welches eigentlich vorsieht, sämt- liche Informationen zur Darstellung und Verarbeitung aus dem Dokument herauszuhalten, ist aber in einigen Fällen unvermeidlich. Ein solcher Fall wäre z. B. die Speicherung einer Seitenzahl zur Generierung eines Inhaltsverzeichnisses.67
Steueranweisung beginnen mit einer öffnenden spitzen Klammer und einem Fragezeichen. Dem folgt ohne Leerzeichen ein Ziel, d. h., ein Name, an dem die verarbeitende Anweisung erkennt, dass die Anweisung für sie bestimmt ist. Abgeschlossen wird die Prozessor-Anweisung durch ein Fragezeichen und eine schließende spitze Klammer. Zwischen Ziel und Abschlußbegrenzer können noch beliebige Daten für die verarbeitende Anwendung stehen. Lediglich Entityverweise sind nicht möglich, da sie vom Parser nicht aufgelöst würden.68
Ein gutes Beispiel für das Aussehen einer Steueranweisung ist die XML-Deklaration aus Abschnitt 2.4.2. Sie stellt nämlich selbst eine Prozessor-Anweisung dar und teilt dem XMLProzessor mit, dass es sich um ein Dokument im XML-Format handelt.69
Der letzte hier angesprochene Bestandteil eines XML-Dokumentes sollen die Entities sein. Allgemein gesprochen sind Entities Platzhalter, die später durch andere Inhalte ersetzt werden. Diese Inhalte reichen von nicht auf der Tastatur befindlichen Zeichen über oft verwendete Textstükke bis hin zu Dateien, die später an einer bestimmten Stelle eingebunden werden sollen. Grob untergliedern kann man sie in allgemeine und Parameter-Entities.70
Parameter-Entities können ausschließlich in DTDs verwendet werden. Sie dienen dazu die War- tung von DTDs zu erleichten. Dies geschieht, indem z. B. häufig benötigte Inhaltslisten für Ele- mente einmal zentral deklariert und dann bei den Definitionen der Elemente referenziert werden (s. a. 2.5.1).71
Allgemeine Entities finden im eigentlichen XML-Dokument Anwendung. Sie lassen sich feiner unterteilen in Zeichenentities, Entities mit gemischtem Inhalt und ungeparste Entities.72 Die schon in Abschnitt 2.4.5 angesprochenen Zeichenentities, sind Platzhalter für einzelne Zeichen. Diese sind erforderlich bei reservierten Zeichen ( < oder & )73 und Zeichen, die auf der Tastatur nicht vorhanden sind.74
Entities mit gemischtem Inhalt können zum einen Zeichenketten enthalten. Diese Zeichenketten dürfen Markup-Befehle beinhalten, die nach der Ersetzung sogar noch ausgewertet werden. Zum anderen können Entities mit gemsichtem Inhalt auf ganze Dateien zeigen. Entity-Referenzen, die auf Dateien zeigen, werden zur Laufzeit durch den gesamten Inhalt der Datei ersetzt. Wie bei den Zeichenketten werden auch hier enthaltene Markupbefehle anschließend noch ausgewertet.75 Verweist ein Entity auf eine andere Datei, so spricht man auch von einem externen Entity. Sie eigenen sich z. B. dazu Inhalte zu übernehmen, die in vielen Dokumenten Anwendung finden. In diesem Fall würde der Inhalt in einer zentralen Datei stehen und bräuchte von anderen Dateien nur importiert zu werden (s. a. Abb. 3). So können Redundanzen sinnvoll vermieden werden. Alle Entities, die nicht auf eine andere Datei zeigen, werden interene Entities genannt.76
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3: Benutzung von externen Entities, eigene. Darstellung in Anlehnung an Ray, E. T. (2001), S. 57
Externe Daten können auch direkt vom Parser an den XML-Prozessor weitergereicht werden. Dies ist erforderlich, wenn die externe Datenquelle Daten im Binär-Format (z. B. Grafik- oder Audio-Dateien) enthält oder aber Markup-Befehle nicht ausgewertet werden sollen. Man spricht dann von einem ungeparsten Entity. Diese Art von Entities darf nur als Attributwert verwendet werden.77
Zum Einfügen eines Entity-Verweises in ein XML-Dokument wird die Zeichnekette &Name; verwendet. Wobei Name durch den Namen des jeweiligen Entities erstetz werden muss. Beim oben beschriebene Parameter-Entity wird das Kaufmanns-Und (&) durch ein Prozentzeichen er- setzt (%Name;). Vor der Verwendung muss ein Entity deklariert werden.78 Die Deklaration einer Entity kann im Prolog des Dokumentes oder in der DTD erfolgen. Die da- für benötigte Syntax stellt sich wie folgt dar: Begonnen wird sie mit der Zeichenkette <!ENTITY, anschließend folgt ein Leerzeichen und der Name des Entity. Für Entity-Namen gelten dieselben Beschränkungen wie für Namen von Elementen. Nach einem weiteren Leerzeichen wird in An- führungszeichen die Zeichenkette, durch die das Entity später ersetzt werden soll, angegeben. Abgeschlossen wird die Entity-Deklaration durch eine schließende spitze Klammer.79 Parameter-Entities enthalten zwischen Anfangsbegrenzer und Entity-Namen noch ein Porzentzei- chen. Dies kennzeichnet, dass es sich um ein Parameter-Entity handelt.
[...]
1 Vgl. Solomon, H. S. (2001), S. 1ff.
2 Vgl. Zschau, O./Traub, D./Zahradka, R. (2002), S. 73ff.
3 Vgl. Bray, T. u. a. (2000)
4 Vgl. Ray, E. T. (2001), S. 3, Solomon, H. S. (2001), S. 4
5 Vgl. Zschau, O./Traub, D./Zahradka, R. (2002), S. 23
6 Vgl. Ray, E. T. (2001), S. 44
7 Vgl. Solomon, H. S. (2001), S. 6
8 Vgl. Ray, E. T. (2001) S. 12
9 Vgl. Ray, E. T. (2001), S. IX
10 Vgl. Behme, H./Mintert, S. (2001); S. 37, Ray, E. T. (2001) S. 11
11 Vgl. Pott, O./Wielage G. (2000), S. 34
12 Vgl. Solomon, H. S. (2001), S. 6
13 Vgl. Ray, E. T. (2001) S. 14; Pott, O./Wielage G. (2000), S. 34
14 Vgl. Bray, T. u. a. (2000); Pott, O/Wielage, G. (2000), S. 51; Walsh, N. (1998)
15 Vgl. Bray, T. u. a. (2000)
16 Vgl. Cowan, J., (2002)
17 Vgl. Cowan, J. (2002)
18 Vgl. Cowan, J. (2002)
19 Vgl. Behme, H./Mintert, S. (2001), S. 26; Ray, E. T. (2001), S. 157
20 Vgl. Ray, E. T. (2001), S. 12
21 Vgl. Pott, O./Wielage, G. (2001), S. 24
22 Vgl. Ray, E. T. (2001), S. 13
23 Vgl. Behme, H./Mintert, S. (2001), S. 124
24 Vgl. Ray, E. T. (2001), S. 13
25 Vgl. Behme, H./Mintert, S. (2001); Pott, O./Wielage, G.(2000), S. 28
26 Vgl. Ray, E. T. (2001), S. 14; Morgenthal, J. P.,(2001a), S. 4
27 Vgl. Ray, E. T. (2001), S. 14
28 Vgl. Solomon, H. S. (2001), S. 4f
29 Vgl. Ray, E. T. (2001), S. 288ff.
30 Vgl. Linthicum, D. S. (2001), S.271; Ray, E. T. (2001), S. 300
31 Vgl. Ray, E. T. (2001), S. 300
32 Vgl. Morgenthal (2001b)
33 Vgl. Solomon, H. S., (2001), S. 3
34 Vgl. Morgenthal (2001b); Linthicum, D. S., (2001), S. 265
35 Vgl. Ray, E. T. (2001), S. 4 ff; Solomon, H. S. (2001), S. 42 ff
36 Vgl. Bray, T. u. a. (2000)
37 Vgl. Bray, T. u. a. (2000)
38 Ray, E. T. (2001), S. 14
39 Vgl. Bray, T. u. a. (2000)
40 Vgl. Ray, E. T. (2000), S. 6f
41 Vgl. Solomon, H. S. (2001), S. 6; Ray, E. T.(2000), S. 157ff
42 Vgl. Ray, E. T. (2001), S. 6f
43 Vgl. Pott, O./Wielage, G.(2000), S. 81; Bray, T. u. a. (2000)
44 Vgl. Ray, E. T. (2001), S. 158f; Behme, H./Mintert, S. (2001), S. 222
45 Vgl. Behme, H./Mintert, S. (2001), S. 67; Bray, T. u. a. (2000)
46 Vgl. Bray, T. u. a. (2000)
47 Vgl. Ray, E. T. (2001), S. 39
48 Vgl. Bray, T. u. a. (2000); Ray, E. T. (2001), S. 39f.
49 Vgl. Pott, O./Wielage, G. (2000), S.81
50 Vgl. Pott, O./Wielage, G. (2000), S.96f.
51 Vgl. Bray, T. u. a. (2000)
52 Vgl. Bray, T. u. a. (2000)
53 Vgl. Ray, E. T. (2001), S. 42
54 Vgl. Ray, E. T. (2001), S. 42
55 Vgl. Bray, T. u. a. (2000)
56 Vgl. Pott, O./Wielage, G. (2000) S. 102; Ray, E. T. (2001), S. 44
57 Vgl. Bray, T. u. a. (2000)
58 Vgl. Bray, T. u. a. (2000)
59 Vgl. Bray, T. u. a. (2000)
60 Vgl Behme, H./Mintert, S. (2001), S. 70ff.; Ray, E. T. (2001), S.43
61 Vgl Behme, H./Mintert, S. (2001), S. 70ff.; Ray, E. T. (2001), S.43
62 Vgl. Bray, T. (2000); Ray, E. T. (2001), S.43
63 Vgl Behme, H./Mintert, S. (2001), S. 71f.; Ray, E. T. (2001), S.62
64 Vgl. Bray, T. (2000); Behme, H./Mintert, S. (2000), S. 72f.
65 Vgl. Bray, T. (2000); Münz, S.; (2001)
66 Vgl. Bray, T. (2000)
67 Vgl. Ray, E. T. (2001), S. 62ff.; Behme, H./Mintert, S. (2001), S.74f
68 Vgl. Bray, T. (2000)
69 Vgl. Pott, O./Wielage, G. (2000), S. 78; Behme, H./Mintert, S. (2001), S. 75
70 Vgl. Ray, E. T. (2001), S. 51ff.
71 Vgl. Pott, O./Wielage, G. (2000), S. 90
72 Vgl. Ray, E. T. (2001), S. 52
73 Vgl. Bray, T. u. a. (2000)
74 Vgl. Ray, E. T. (2001), S. 54f.
75 Vgl. Ray, E. T. (2001), S. 55ff.
76 Vgl. Pott, O./Wielage, G. (2001), 91f.; Ray, E. T. (2001), S. 55f.
77 Vgl. Pott, O./Wielage, G. (2001), S. 91f.; Bray, T. u. a. (2000)
78 Vgl. Ray, E. T. (2001), S. 53f.
79 Vgl. Bray, T. u. a. (2000)
