XML Linking. Abbildung einer vertikal integrierten Wertschöpfungskette in einer Web-Applikation

Inhaltsverzeichnis

Abbildungsverzeichnis

1. Einleitung

2. Problemstellung
2.1. Warum XML Linking?
2.1.1. Neue Möglichkeiten nutzen
2.1.2. Anwendungen verbessern
2.2. Die Applikation
2.2.1. Anwendungsfälle
2.2.2. Das System

3. Die Urheber: Das W3-Konsortium

4. Die Grundlage: XML
4.1. Woher es kommt und wie es aussieht
4.2. Wofür es gut ist
4.3. Aufbau eines XML-Dokuments
4.4. Namensräume
4.5. wohlgeformte Dokumente
4.6. Gültigkeit
4.6.1. DTD
4.6.2. XML Schema
4.6.3. Relax NG

5. XML als Baumstruktur
5.1. Parsing
5.1.1. DOM
5.1.2. SAX
5.1.3. Fazit
5.2. Adressierung: XPath
5.2.1. Modell und Syntax
5.2.2. Definition logischer Ausdrücke
5.2.3. Funktionen
5.3. Konfliktlösung: Das XML Infoset

6. XML Linking
6.1. Exkurs: URI/URL
6.2. XInclude
6.3. XBase
6.4. XPointer
6.4.1. Technik und Möglichkeiten
6.4.2. Umsetzung und Probleme
6.5. XLink
6.5.1. Technik und Möglichkeiten
6.5.2. Umsetzung und Probleme
6.5.3. XLink versus HLink
6.6. XML Linking versus Xanadu

7. XML Metadaten und das semantische Web
7.1. Wofür brauchen wir Metadaten?
7.2. Einige Grundthesen über Metadaten
7.3. XLinks als Metadaten
7.4. Gültigkeitsdefinitionen als Metadaten
7.5. Meta-Metadaten am Beispiel RDDL
7.6. Topic Maps
7.7. Resource Description Framework (RDF)

8. Weiterverarbeitung und Anzeige von XML durch Stylesheets: XSL(T)
8.1. Woher es kommt und was es kann
8.2. XSL als funktionale Programmiersprache
8.3. Das Stylesheet dataCollector.xsl

9. Zusammenfassung und Ausblick

10. Anhang
10.1. Benutzerbeschreibung
10.1.1. Zweck des Programms
10.1.2. Installation
10.1.3. Nutzung
10.2. Screenshot der Einstiegsseite
10.3. Screenshot der Applikation
10.4. Detaildokumentation
10.4.1. Dateien/Klassen
10.4.2. Arbeitsumgebung
10.5. Programmcode
10.5.1. index.html (Einstiegsseite)
10.5.2. vendors.xml
10.5.3. vendors.dtd
10.5.4. linkbase_1.xml
10.5.5. linkbase.rng
10.5.6. index.html (RDDL)
10.5.7. format.css
10.5.8. dataCollector.xsl
10.5.9. Transformer.jsp
10.5.10. NodeSetGrapper.jsp

Literaturverzeichnis

Ehrenwörtliche Erklärung

Abbildungsverzeichnis

Abbildung 1: Wertschöpfungskette der XYZ-Gruppe

Abbildung 2: Anwendungsfalldiagramm

Abbildung 3: Systemübersicht

Abbildung 4: Modell einer 3-Schichten-Architektur

Abbildung 5: Ein XML-Baum

Abbildung 6: Parsing – Prozess

Abbildung 7: XML Schichtenmodell der vorgestellten XML-Techniken

Abbildung 8: Ein Pointer zeigt auf ein Zulieferer-Element

Abbildung 9: XLinks und Ressourcen

Abbildung 10: Link als Tripel

Abbildung 11: Ansicht der RDDL-Datei index.html im IE

Abbildung 12: RDF-Tripel

Abbildung 13: XSL-Processing

Abbildung 14: Screenshot der Einstiegsseite

Abbildung 15: Screenshot der Applikation

1. Einleitung

Der Boom des Internet

Nach der Entwicklung der Auszeichnungssprache HTML (Hypertext Markup Language) von Tim Berners-Lee 1991 am Genfer Hochenergieforschungszentrum CERN und des ersten weit verbreiteten Browsers namens „Mosaic“ durch Marc Andreessen erlebte das Internet einen unvorhersehbaren Boom. Zwar hatte schon so mancher Vordenker eine gemeinsame Nutzung von Ideen und Texten der Menschheit durch das Netz propagiert, doch nur wenige hatten geahnt, dass das vormals nur von Wissenschaftlern und Militärs genutzte Internet im Lauf der 90er Jahre von Millionen von Nutzern geprägt werden würde.

Entscheidenden Anteil daran hatte auch das W3-Konsortium (W3C). Nachdem die Wirtschaft die Potentiale des Internets erkannt hatte, die jedoch abhängig von seiner Verbreitung und der Akzeptanz in der Bevölkerung sind, wurde die Standardisierung des Internets von dem damit überlasteten CERN an das neu gegründete Konsortium W3C übergeben, welches maßgeblich aus Mitgliedern der am Internet beteiligten Unternehmen besteht. Hier wurde HTML standardisiert, so dass jedermann daran teilhaben konnte.

Die Einführung von XML

Vergleichbar mit diesem Schritt ist dem W3C 1998 ein weiterer Coup gelungen: Die Verabschiedung der Datenauszeichnungssprache XML (Extensible Markup Language).

Anfangs war XML nur dafür gedacht, Programmiersprachen zu beschreiben, doch schnell wurde klar, dass XML als frei erweiterbarer Datenhaltungsstandard dem Internet noch weit größeren Nutzen bringt.

XML stellt in Ergänzung zu HTML eine weitere Stufe in der Entwicklung von Dokumenten und Applikationen für das Internet dar. Es ist nicht nur ein system-, sprachen- und netzübergreifender Datenhaltungsstandard, sondern auch Grundlage für ein sinnvolleres Dokumentenmanagement. Seine größte Stärke ist jedoch seine Erweiterbarkeit und seine Regulierbarkeit. XML ist ganz einfach den Bedürfnissen des Entwicklers anpassbar.

Zwar sind diese Vorzüge für alle Nutzer des Internets interessant, doch gerade die Nutzer, die eine wirtschaftliche Nutzung des Internets (beispielsweise durch E-Commerce) betreiben, werden um XML nicht herumkommen.

Die Ziele um XML herum

XML war von Anfang nicht als Stand-alone-Standard konzipiert. Das W3-Konsortium verfolgte drei Ziele. Zunächst XML als Standard für sich. Als zweites Ziel die Verlinkung von in XML gehaltenen Ressourcen auf neue, verbesserte Art. Drittens, das Design von XML auf Oberflächen. Durch die Erweiterungen, die sich aus diesen Zielen ergeben haben und werden, eröffnen sich laufend neue Aufgabengebiete und Anwendungsmöglichkeiten von XML, die neue Anwendungen für XML aus dem Boden schießen lassen.

Das dritte dieser Ziele ist durch XSL weitgehend umgesetzt und wird hier nur am Rande behandelt (obwohl XSL einen wichtigen Teil der Applikation stellt). Thema dieses Textes soll der zweite Schritt sein, die Verlinkung von XML-Ressourcen.

XML Linking

XML Linking ist die Verbindung von Ressourcen mit XML. Mehrere Standards wurden zu diesem Thema vom W3C-Konsortium entworfen. Steven J. DeRose, XML-Entwickler beim W3C, fasste diese Bemühungen 1999 unter dem Titel „XML Linking“ zusammen.^[1]

Ein alter Entwicklertraum scheint in Erfüllung zu gehen: Ähnlich der neuronalen Verbindungen im Gehirn sollten Menschen Verbindungen bzw. Assoziationen zwischen Dokumenten oder Teilen von Dokumenten anlegen können, um das vielfältige Wissen des Netzes effizienter zu nutzen oder, weitaus visionärer, von Maschinen nutzen zu lassen.

So entwickelte beispielsweise Vannevar Bush 1945 das System „Memex“, welches auf Assoziationen zwischen Texten beruhte oder Ted Nelson um 1970 das Prinzip des Hypertextes und das darauf beruhende Projekt „Xanadu“, welches er jahrzehntelang betrieb, ohne seinen Traum in die Realität umsetzen zu können.^[2] Das Konzept des Hypertextes war seit jeher Grundlage für ein assoziatives Netz. Auf diesem Prinzip basieren auch die Verweise in HTML, jedoch nur unidirektional und nur zu vorgeschriebenen Punkten.

Zwei weitere Spezifikationen des W3C, beide voneinander unabhängig, sollen dies nun auf der Basis von XML ändern: XPointer (XML Pointer Language), welche bislang nur als Candidate Recommendation vorliegt, und XLink (XML Linking Language). XLink und XPointer können einander benutzen, sind jedoch wiederum nicht aufeinander angewiesen.

Außer den privaten Internetnutzern und den Wissenschaftlern und Journalisten kann auch die Wirtschaft -gerade der Marketingbereich (im Bezug auf XLink-Datenbanken)- von den Möglichkeiten des XML Linking profitieren.

Fakt ist aber, dass noch wenig Unterstützung für die Komponenten des XML Linking in Form von Anwendungen vorliegt und auch die Diskussionen der Entwicklergemeinde zum Thema sind noch kontrovers.

Metadaten und XML Linking

Die Semantisierung des Internets ist ein großes Ziel des W3C. Sie ist auf lange Sicht unumgänglich, um der Informationsflut Herr zu werden. Für viele besteht das Internet nur aus Daten, die in verschiedenen Ressourcen, zum Beispiel Dokumenten, gehalten werden. Vielmehr gibt es auch viele Informationen, die diese Daten beschreiben. Beispielsweise geben Meta-Tags in HTML Auskunft über den Autor und andere Dinge das Dokument betreffend. Auch jeder Link ist ein Metadatum, der verschiedene Ressourcen verknüpft. In Zukunft sollen diese Metadaten und viele andere mehr (z.B. restriktive Daten für Validierungen) das Internet bereichern und von Maschinen verarbeitet werden können. Dazu müssen sie strukturiert vorliegen. XML Linking ist einer der Standards, die dafür Sorge tragen.

Unsere Applikation

Um die Strukturierung von Metadaten in Form von XLinks zu demonstrieren, werden wir entlang der Kapitel eine Applikation entwickeln, die auf viele der erklärten Komponenten zurückgreift.

Wir nehmen eine Liste von Zulieferern eines Unternehmens an, die in XML gespeichert wird. Um ihre Lieferbeziehungen abzubilden, die eine vertikal integrierte Wertschöpfungskette darstellen, werden wir XLinks als Metadaten in einer XLink-Datenbank speichern. Auch diese Daten werden wir mit Metadaten beschreiben. Anschließend ermöglichen wir das Traversieren (Überqueren) über die Wertschöpfungskette in einer Web-Applikation, die XSLT und Java Server Pages verwendet.

Über diesen Text

Dieser Text kann keine vollständige Referenz darstellen. Stattdessen verfolgt er drei Ziele:

- Er soll er ein breites Wissen über das Gerüst rund um XML, XML Linking und XML Metadaten in einer der Applikation folgenden aufbauenden Gliederung bereitstellen. Er soll dabei auch ein vom W3C entwickeltes Schichtenmodell vorstellen, dem die erwähnten Komponenten angehören. Auch historische Gegebenheiten und Unregelmäßigkeiten in der Entwicklung von XML sollen herausgearbeitet werden. Denn obwohl die Entwickler von XML Beachtliches vollbringen, können sie nur die richtigen Anstöße geben und auf das Aufgreifen der Ideen durch die Nutzer warten. Mitunter kommt es sogar zu gegensätzlichen Entwicklungen und Meinungsverschiedenheiten.
- Außerdem diskutiert er die Möglichkeiten und die Probleme von XML Linking und seinen Einfluss auf Entwicklungen der nahen Zukunft. Er soll auch XML Linking als eine Schicht im XML-Modell begreiflich machen. Das Verständnis der Interaktionen von XML-Standards ist der Schlüssel zu ihrer erfolgreichen Verwendung.
- Analog soll Schritt für Schritt ein Programm entwickelt werden, welches viele der eingeführten Konzepte verwendet.

Im Teil 2 wird einleitend das W3C-Konsortium vorgestellt. Ein Verständnis der Motive und der Ausgangslage, die zum XML-Standard führten, sollte hilfreich für den Einsatz sein.

Der dritte Teil ist der Applikation gewidmet. Nachdem die Problemstellung erläutert wurde, stelle ich heraus, warum wir XML Linking verwenden und stelle eine Gesamtübersicht zur Verfügung.

Im vierten Teil wird die Sprache XML genauer beleuchtet. Es werden der Aufbau eines XML-Dokuments, Namensräume, Wohlgeformtheit, sowie die Möglichkeit, eigene Strukturen festzulegen, erklärt. Gerade letzteres ist ein essentieller Teil von XML und wird deshalb an eigenen Beispielen demonstriert.

Im folgenden, fünften Teil wird XML als Baumstruktur besprochen, d.h., die Verarbeitung von XML als Objektstruktur durch den Computer. Dabei ist der Parsing-Prozess eine wichtige Grundlage.

Im sechsten Teil werden dann die Möglichkeiten, Probleme und Relationen zu ausgewählten verwandten Themen der Vergangenheit und Zukunft von XPointer und XLink unter der Überschrift „XML Linking“ besprochen.

Der siebte Teil äußert sich zu XML Metadaten im Allgemeinen, wofür sie gut sind, was XML Linking damit zu tun hat und warum sie für unsere Zukunft wichtig sein könnten.

Der achte Teil stellt XSL vor, eine wichtige Technologie zur Verarbeitung von XML und auch für unsere Web-Applikation entscheidend.

Abschließend werden im neunten Teil die Ergebnisse zusammengefasst und in einem Ausblick die weitere Entwicklung von XML Linking und seiner Verwendung skizziert.

Formale Hinweise

Normaler Text dieser Arbeit erscheint in der Times New Roman - Schriftart. Namen von verwendeten Dateien werden kursiv geschrieben. Code als Beispiel oder aus der Applikation wird in der Schriftart Georgia dargestellt.

2. Problemstellung

Viele Sachverhalte der Welt sind äußerst komplex. Systeme zerfallen in Subsysteme, deren Teile miteinander kommunizieren. Die Relevanz einzelner Komponenten ist in der wachsenden Informationsvielfalt schwer auszumachen.

In unserem Beispiel wollen wir uns auf ein relativ übersichtliches Beispiel konzentrieren. XYZ sei ein Konzern, unter dessen Dach viele Subunternehmen Einzelteile des Endprodukts herstellen. Sie sind in einer vertikal integrierten Wertschöpfungskette organisiert. Das bedeutet, auf jeder Ebene des Wertschöpfungsprozesses können mehrere Zwischenproduzenten angesiedelt sein. Die Lieferbeziehungen dieser Zwischenproduzenten stellen ein komplexes Netz von Lieferbeziehungen dar. Oft liefert ein Produzent auch verschiedene Produkte und Nebenprodukte, was hier aber der Verständlichkeit halber nicht dargestellt werden wird.

Seine Wertschöpfungskette vertikal zu erweitern ist ein oft angewandtes Mittel, effizienteres Kostenmanagement zu betreiben und erhöhte Planungssicherheit zu erreichen (das Gegenstück, horizontale Integration, erweitert das Repertoire des Konzerns um weitere Wertschöpfungsstufen).

Wir benutzen hier nur eine einfache Wertschöpfungskette. Oft sind diese Zusammenhänge weitaus komplexer (siehe Abbildung 1, „Wertschöpfungskette der XYZ-Unternehmensgruppe“, Seite 6). Unsere Applikation soll helfen, schnell einen Überblick über die vielen Lieferbeziehungen der XYZ-Gruppe zu gewinnen, indem sie als XLinks abgelegt und über eine Web-Applikation dargestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Wertschöpfungskette der XYZ-Gruppe

2.1. Warum XML Linking?

XML Linking zu verwenden, bedeutet nicht nur, neue Möglichkeiten der Verlinkung zu nutzen. Es bedeutet auch, seine Anwendungen in Systementwicklung und Wartung zu optimieren. Anhand dieser zwei Vorteile soll hier die zu erstellende Anwendung erklärt werden. Dann werden die einzelnen Komponenten vorgestellt, die dann (soweit sie XML betreffen) später im Text schrittweise erklärt werden.

2.1.1. Neue Möglichkeiten nutzen

Die angesprochene komplexe Vernetzung darzustellen, ist mit XML Linking leicht zu erreichen. Wir werden dazu XLink-Datenbanken benutzen. Ohne vorgreifen zu wollen, kann man sie so beschreiben: Eine XLink-Datenbank kann wie eine Beziehungstabelle in einer relationalen Datenbank funktionieren, die n:m-Beziehungen von Elementen zweier Tabellen darstellt. Damit sind sie schon weitaus variabler als HTML Hyperlinks. Weitere Vorteile für Anwendungen liegen aber auf der Hand:

- XLinks sind plattformunabhängig (siehe dazu Kapitel 4, „Die Grundlage: XML“)
- XLinks können Daten jeder Art verbinden
- Sie können Platz sparend als Datei versendet werden

Komplexe Sachverhalte darzustellen, ist für jede Unternehmung ein Vorteil. XLinks sind eine moderne und variable Weise, dies zu tun.

2.1.2. Anwendungen verbessern

Zunächst ist XML ein richtiger Weg, um Anwendungen sinnvoll einzuteilen. Es wird die oft angestrebte 3-Schichten-Architektur (siehe dazu Kapitel 4: „Die Grundlage: XML“) erreicht, die eine bessere Systementwicklung verspricht. Einher geht eine verbesserte Wartbarkeit. Mit XML werden die Daten verfasst, XSL (in unserem Fall) stellt sie dar. Zudem können wir die Datenschicht unterteilen in die Daten selbst und ihre Metadaten, also Daten, die Daten beschreiben. Datenbeschreibungen wie DTDs sind Metadaten, aber Beziehungen sind es ebenso.

XML Linking erlaubt es, diese Trennung auch in Anwendungen vorzunehmen.

Anders als die Beziehungstabelle, die in der gleichen Datenbank sein muss wie die Datentabellen, kann eine XLink-Datenbank theoretisch überall im selben Computernetz sein. Die verbundenen Daten brauchen in keiner Weise beeinflusst werden, um verlinkt sein zu können. Gerade für das Internet, aber auch für firmeneigene Intranets ist das interessant.

Metadaten sind oft auch an einem weiteren Kriterium zu bestimmen: Sie stellen Behauptungen über Ressourcen dar^[3]. Sie sind eine Sichtweise. Deshalb kann es günstig sein, eine weitere Sichtweise einfach in einer weiteren XLink-Datenbank zur Verfügung stellen zu können. Stellen Sie sich eine XLink-Datenbank vor, die die Begegnungen in der nächsten Saison der Fußball-Bundesliga abbildet. Warum sollte nicht eine weitere Saison daneben anwählbar sein? Diese Begegnungen, Sichten auf Daten (die Vereine), sollten einerseits getrennt von den Daten, andererseits auch getrennt und unabhängig voneinander sein.

Unser System macht sich diese Vorteile durch Anwendung von XML Linking zu nutzen und wird also leicht zu warten und leicht erweiterbar sein.

2.2. Die Applikation

2.2.1. Anwendungsfälle

Folgende Aktionen sollen in der Applikation möglich sein:

Durch Anwählen eines Zulieferers sollen seine Daten angezeigt werden. Zudem sollen seine Lieferbeziehungen, also seine Zulieferer wie seine Abnehmer zu sehen sein.

Diese werden als HTML-Links dargestellt und können dadurch wiederum ausgewählt werden. Dadurch ist die dynamische Ansicht der einzelnen Lieferbeziehungen möglich. Natürlich sollte auch eine Gesamtansicht erzeugt werden, aber das ist nicht Teil dieser Arbeit. Betrachten Sie zu den Anwendungsfällen bitte untenstehende Abbildung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Anwendungsfalldiagramm

2.2.2. Das System

Unsere Applikation soll einer 3-Schichten-Architektur folgen. Ziel heutiger Systementwicklung sollte immer die strikte Trennung von Daten, Logik und Präsentation sein. Wie noch zur Sprache kommen wird, ist XML dafür konzipiert worden.

Betrachten Sie zur Systemübersicht bitte Abbildung 3 auf Seite 10.

Datenschicht

Es ist bereits angesprochen worden, dass wir Daten und Metadaten hier ebenfalls trennen wollen. Als Daten dienen uns die Zulieferer innerhalb der Unternehmensgruppe XYZ, die in einer XML-Datei (vendors.xml) abgelegt sind. Zu jedem Zulieferer ist ein Bild der Firma gespeichert. Eine Referenz darauf stellen natürlich XLinks innerhalb von vendors.xml her. Außerdem referenziert ein XLink die Homepage jedes Zulieferers.

In der Metadatenschicht interessiert uns natürlich hauptsächlich die XLink-Datenbank (linkbase_1.xml). In ihr sind die Lieferbeziehungen gespeichert und diese Metadaten sind die Grundlage der Applikation. Es sei noch einmal gesagt: Da diese Beziehungen eine Sicht auf die ursprünglichen Daten darstellen, ist die Trennung der Daten von ihren Beziehungen durchaus erwünscht.

Weitere Metadaten sind nicht lebenswichtig für die Applikation und können separat betrachtet werden. Sie dienen zur Beschreibung von Daten, somit auch zu einer besseren Wartbarkeit, und bieten zudem Möglichkeiten der maschinellen Verarbeitung der Daten (ein wichtiger Zweck von Metadaten, siehe dazu Kapitel 7, „XML Metadaten und das semantische Web“).

Da sind die Gültigkeitsbeschreibung vendors.dtd, welche den Aufbau von vendors.xml festlegt, die etwas modernere Gültigkeitsbeschreibung linkbase.rng, sowie die RDDL-Datei, die linkbase_1.xml und alle ähnlichen Dokumente beschreibt.

Logikschicht

In der Logikschicht finden sich zwei Java-Klassen. Es sind Java Server Pages (JSP), die unsere Applikation zu einer Web-Applikation werden lassen. Beide sind nicht groß und haben nur eine spezifische Aufgabe.

- Transformer.jsp

Diese Klasse führt eine XML-Datei mit einer sie verarbeitenden XSL-Datei zusammen (auch Stylesheet genannt, siehe dazu Kapitel 8, „Weiterverarbeitung und Anzeige von XML: XSL(T)“) und liefert den Output dieser Transformation an den Browser des Clients zurück. Weiter Parameter können über die URL (siehe Kapitel 6.1, „Exkurs: URI/URL“) an das XSL-Stylesheet übergeben werden. So verarbeitet unser XSL-Stylesheet die Linkdatenbank.

- NodeSetGrapper.jsp

Diese Klasse führt ebenfalls eine Transformation durch, eine ganz ähnliche sogar wie Transformer.jsp. Nur erwartet sie kein XSL-Stylesheet als verarbeitende Komponente, sondern einen XPath-Ausdruck (eine Abfrage auf XML-Daten, siehe dazu Kapitel 5.2, „Adressierung: XPath“). Sie liefert ein NodeSet zurück, was man sich als Ergebnis des XPath-Ausdrucks vorstellen kann. Hiermit kann unser XSL Stylesheet an die Daten des aktuell ausgewählten Zulieferers aus der Datei vendors.xml gelangen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Systemübersicht

Präsentationsschicht

Hier finden wir den eigentlichen XLink – verarbeitenden Teil der Applikation. Aus Gründen, auf die ich später eingehen werde, ist er bisher eine von wenigen seiner Art.

Der Name des XSL-Stylesheets ist DataCollector.xsl. Es generiert den HTML-Code, der Daten des ausgewählten Zulieferers und Links zu seinen Zulieferern und Abnehmern anzeigt. Der HTML-Output wird durch die Datei format.css formatiert.

3. Die Urheber: Das W3-Konsortium

Weil das Genfer Hochenergieforschungszentrum CERN durch die Pionierarbeit von Tim Berners-Lee, der dort HTML entwickelte, Anfang der Neunziger Jahre eher in die Rolle hineinrutschte, Standards für das Internet zu entwickeln, wurde das W3C als sein Nachfolger zu diesem Zweck gegründet (W3 steht für WWW, das Symbol des Internet, auch als World Wide Web bezeichnet). Einher mit dem rapiden Wachstum des Internets ging der dringende Ruf der beteiligten Nutzern und Entwicklern nach Standards, die von den größten Teilen der Internetgemeinde akzeptiert werden.

Mitglieder des W3C sollten außer anerkannten Wissenschaftlern, die an der Informationstechnologie arbeiteten, auch Firmen werden, die maßgeblich Anwendungen für das Internet entwickelten. Allen voran natürlich Netscape, deren Chef Marc Andreessen den ersten Browser Mosaic mitentwickelt und sein enormes wirtschaftliches Potenzial erkannt hatte. Netscape beherrschte damals den Browsermarkt quasi als Monopolist (und das mit Inbrunst), bis Microsoft die Potenziale des Webs erkannte und einen eigenen Browser herausbrachte. Microsoft ist heute ebenfalls Mitglied des W3C.

Nach zwei internationalen WWW-Konferenzen 1993 und 1994 (beide waren derart gut besucht, dass die Kapazitäten nicht ausreichten) wurde Ende 1994 das W3-Konsortium gegründet und startete mit seinem Werbespruch „leading the web to ist full potential“ seine Arbeit an den Standards des Internets. 2001 zählte es über 500 Mitglieder und ca. 60 feste Mitarbeiter.

Folgende sieben Prinzipien bestimmen seine Arbeit^[4]:

1. Universeller Zugang – Das W3C definiert es als ein Ziel, möglichst vielen Menschen Zugang zum Netz zu verschaffen.
2. Semantik – Bei der Entwicklung des Netzes soll Wert auf die Sinnhaftigkeit und die Möglichkeiten, unsere Probleme zu lösen, gelegt werden.
3. Vertrauen – Im Netz der Anonymität besteht auch immer Interaktion. Es ist wichtig, das Vertrauen der Menschen in das Netz zu erhalten.
4. Interoperabilität – das W3C - Konsortium versteht sich als Anbieter-unabhängige Vereinigung, deren Ziel es ist, dem Nutzer möglichst viel Freiheit bei der Wahl seiner Software zu geben. Dies soll erreicht werden durch offen gelegte Standards und Protokolle, die von möglichst vielen Anbietern unterstützt werden
5. Entwicklung – Auch bei größtmöglicher technischer Raffinesse können wir heute nicht alle Probleme von morgen lösen, da wir sie nicht kennen. Daher plädiert das W3C - Konsortium dafür, nach den Prinzipien Einfachheit, Modularität, Kompatibilität und Erweiterbarkeit zu arbeiten, um heutige Systeme auch morgen an die aktuellen Anforderungen anpassen zu können.
6. Dezentralisierung – Dezentrale Systeme sind flexible Systeme ohne Flaschenhälse. Das wird vom W3C – Konsortium auf nahezu alle Systeme, sei es das Netz oder die Gesellschaft, bezogen. Darum richtet es auch seine Spezifikationen, die Computerprogramme beeinflussen, danach aus.
7. Cooler Multimedia – Das W3C – Konsortium legt Wert darauf, nicht nur wissenschaftliche oder wirtschaftliche Anwendungen zu fördern, sondern auch an die Mediennutzung durch den Endverbraucher zu denken. Kreative Multimedia-Ansätze werden vom Konsortium unterstützt.

Das W3C finanziert sich durch Mitgliedsbeiträge der Mitgliedsunternehmen und Spenden. Mitglieder des W3C erhalten Zugang zu unveröffentlichtem Material und beeinflussen die Entwicklungen des W3C.

Jedes Thema wird von einer eigenen Arbeitsgruppe (engl.: Working Group) bearbeitet.

Das höchst bindende Werk, welches vom W3C herausgegeben werden kann, ist eine Empfehlung (engl.: Recommendation), die eine Spezifikation einer Sprache oder ähnlichem beschreibt. Ein wirklicher Standard kann jedoch nur von Organisationen mit Regierungsauftrag erfolgen.^[5] Dennoch wird in diesem Text von „Standard“ im Zusammenhang mit Empfehlungen des W3C gesprochen, da die Empfehlungen des W3C Anwendungen im jeweiligen Themengebiet standardisieren.

4. Die Grundlage: XML

4.1. Woher es kommt und wie es aussieht

XML ist keine von Grund auf neu entwickelte Sprache. Vielmehr ist XML eine Teilmenge von SGML (Standard Generalized Markup Language), die bereits seit 1986 international zertifiziert ist. Die Empfehlung für XML 1.0 wurde am 10. Februar 1998 veröffentlicht. Ebenso wie SGML ist XML ursprünglich eine Metasprache, die andere Sprachen beschreiben kann, da ihre Elemente beliebig selbst gestaltet werden können. Inzwischen hat das W3C beispielsweise XHTML 1.0 veröffentlicht, die Beschreibung von HTML 4.0 in XML.

Anders als das komplizierte SGML ist XML einfach konzipiert. Das W3C hat entsprechend seiner Ziele (siehe Kapitel 3, „Die Urheber: Das W3C – Konsortium) für die Entwicklung von XML 10 Grundsätze benannt. Sie laufen darauf hinaus, XML für Menschen einfach verständlich, lesbar und entwickelbar zu halten. Außerdem sollte es ein möglichst breites Spektrum von Anwendungen unterstützen und die Entwicklung von späteren Anwendungen für XML erleichtern.

Die Anwendbarkeit für den Menschen zu betonen, lenkt oft davon ab, dass XML noch immer auch für die Verarbeitung durch Maschinen konzipiert ist. XML-Daten sind für Menschen als Text sichtbar, für Maschinen werden sie durch verarbeitende Programme in eine Objektstruktur umgewandelt (siehe auch Kapitel 5, „XML als Baumstruktur“). Diese Wandelbarkeit ist einer der großen Vorteile von XML, der es auch für verteilte Systeme prädestiniert, denn in Netzwerken lassen sich Text-Dokumente weitaus effizienter verschicken.

XML ist eine Auszeichnungssprache (engl.: Markup Language), wie es auch HTML ist. Eine Auszeichnungssprache enthält so genannte tags (engl. Für Markierung), die durch eine „kleiner-als“-Zeichen eröffnet und durch ein „größer-als“-Zeichen geschlossen werden. Grob umrissen bezeichnen diese Tags sprachenspezifische Merkmale, die von einer Anwendung erkannt werden. Sie können weitere tags oder einfachen Text enthalten.

Ein öffnendes und ein schließendes Tag begrenzen ein XML-Element. Ein Element für einen Zulieferer sollte also so aussehen (Beachten Sie, wie es geschlossen wird):

<vendor>Name</vendor>

Während von HTML-Tags umschlossener Text dadurch formatiert, also zum Beispiel farbig dargestellt wird, wird von XML-Tags umschlossener Text dadurch zu einem adressierbaren Datum. Durch korrekte Verschachtelung (siehe dazu Kapitel 4.5, „wohlgeformte XML-Dokumente“) entwickeln XML-Dokumente immer eine hierarchische Baum-Struktur.

Als einfaches Beispiel sehen wir uns die Datei an, in der alle Zulieferer gespeichert sind, vendors.xml. Ohne Daten, die wir später in Attributen halten, und nur mit 2 Zulieferern sieht sie so aus:

Später werden Attribute für jeden einzelnen Zulieferer dazukommen, ein Kommentar und auch eine Gültigkeitsbeschreibung. Aber alles zu seiner Zeit.

Noch ein paar Worte zur Bearbeitung und Ansicht von XML-Dokumenten: Wie es auch das Ziel des W3C – Konsortiums war, kann jeder mit einem Computer in kürzester Zeit ein XML-Dokument erstellen. Alles, was er dafür benötigt, ist ein simpler Text-Editor, denn XML-Dateien sind nichts anderes als Text-Dateien.

Ein XML-Prozessor, auch als Parser bezeichnet, erzeugt dann ein für Anwendungen als Objekt verwertbares XML-Dokument (siehe dazu Kapitel 5.1, „Parsing“).

Schon Explorer wie der MS Internet Explorer oder der Netscape Browser können eine XML-Datei prozessieren. Sie funktionieren dabei aber nicht als validierende Prozessoren, das heißt, sie überprüfen nicht die Gültigkeit des Dokuments, sondern nur seine Wohlgeformtheit.

Browser dienen allerdings nur zur Anzeige des Dokuments und nicht zur Weiterverarbeitung. Da Browser per Javascript das Dokument anzeigen und dafür mindestens JavaScript ab Version 1.2 vorliegen muss, sind mindestens der Netscape Navigator bzw. der MS Internet Explorer ab Version 4.0 notwendig.^[6] (Vorsicht ist geboten beim MS Internet Explorer 5.x. Einige Versionen, beispielsweise die Version 5.50.4134.0100 im Betriebssystem Windows Millenium, funktionieren beim Prozessieren von XML-Daten nur bedingt.)

4.2. Wofür es gut ist

XML dient nicht nur zur Beschreibung von Sprachen wie XHTML.

Die einfache Handhabung von XML, die plattformunabhängige Verbreitung seines Standards und seine gewaltige Gestaltungsmöglichkeit machen XML an sich zu dem Datenhaltungsstandard der Zukunft. Der obige Vergleich von XML und HTML zeigt weiterhin, dass XML die Trennung von Daten und ihrer Präsentation ermöglicht. Das ist ein wichtiger Schritt für das Dokumentenmanagement in 3-Schichten-Architekturen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Modell einer 3-Schichten-Architektur

Werden die Daten von der Verarbeitung und der Präsentation getrennt, können Änderungen leichter durchgeführt werden und die Wartung führt zu weniger Fehlern. Weiterhin ist es möglich, einzelne Schichten auszutauschen (egal ob dies nötig ist oder erwünscht), ohne die Komponenten der anderen zu behelligen. Es gibt viele Logikschichten, die auf eine XML-Datenschicht aufsetzen können.

Ein Beispiel für eine 3-Schichten-Architektur könnte wäre folgendes Szenario: Über eine HTML-Oberfläche (Präsentationsschicht) werden Java Servlets angesprochen (Logikschicht), die aus XML-Dateien (Datenschicht) auslesen oder diese bearbeiten. So sieht auch unsere Applikation im Groben aus.

Besonders als Austauschformat für Daten über das Internet oder zwischen verschiedenen Systemen (z.B. Content Management Systeme und deren Umwelt) ist XML in der Praxis zurzeit eine der wichtigsten neuen Technologien. Dank seiner Erweiterbarkeit und dynamischen Anpassungsfähigkeit zieht es immer Software-Entwickler und ihre Arbeitgeber in seinen Bann und die Anwendungsmöglichkeiten von XML sind noch lange nicht erschöpft. Beispielsweise entwickelt die Wissenschaft bereits weitere Sprachen unter Zuhilfenahme von XML (so zum Beispiel die Sprache Math ML, Math Markup Language). Auch Tools zu Be- und Weiterverarbeitung von XML werden laufend entwickelt. Diese werden wir später betrachten und einsetzen (siehe Kapitel 8, „Weiterverarbeitung und Anzeige von XML durch Stylesheets: XSL(T)“).

Wieder einmal hat sich gezeigt, wie erfolgreich das Prinzip sein kann, einen einfachen Standard zur Verfügung zu stellen, der dann - nicht ohne Beteiligung der Nutzer - der Realität entsprechend angepasst und weiterentwickelt wird.

4.3. Aufbau eines XML-Dokuments

Jedes XML-Dokument kann laut der W3C-Empfehlung in logischer oder physikalischer Sicht betrachtet werden.

Physikalisch baut sich ein XML-Dokument aus einer Reihe von Einheiten auf, so genannten „Entities“ (in anderen Standards, welche die Baumstruktur ansprechen, wird auch von „Knoten“ gesprochen). Diese können auch auf außerhalb des Dokuments gelegene Einheiten verweisen, die somit in das Dokument eingebunden werden. Ein Knoten kann mehrere andere Knoten beinhalten.

Logisch unterteilt man das Dokument in Elemente, Attribute, Text, Kommentare, Zeichenreferenzen, Verarbeitungsanweisungen und Deklarationen. Diese Bestandteile sind durch explizites Markup ausgezeichnet und werden später in diesem Kapitel näher erklärt.

Eine Grundregel der Empfehlung lautet, dass physische und logische Struktur korrekt ineinander verschachtelt sind. Das bedeutet, dass kein logisches Element in irgendeinem physischen Element, den Entities, beginnt und in einem anderen endet. Siehe dazu auch Kapitel 4.5, „wohlgeformte Dokumente“.

Elemente

Elemente enthalten den eigentlichen Inhalt des Dokuments. Jedes Dokument muss mindestens ein Element enthalten, welches als Wurzel-Element fungiert und alle anderen Elemente enthält. In vendors.xml heißt dieses Element deshalb theRoot.

Ein Element wird durch so genannte „tags“ erstellt, die bereits aus HTML bekannt sind. Es benötigt ein Start- und ein End-Tag. Enthält ein Element zwischen Start- und Endtag keine weiteren Knoten (möglich wären hier weitere Elemente oder Text), kann man ein Element auch so darstellen, wie wir es mit dem pic - Element tun:

<pic />.

Attribute

Ein Element kann auch Attribute besitzen, die im Start-Tag deklariert sind und einen Wert zugewiesen bekommen. Sinnvoll ist dies beispielsweise, wenn alle Elemente gleicher Art eine Eigenschaft haben sollen wie eine ID oder der mögliche Wert über die DTD (siehe Kapitel 4.6.1, „DTD“) eingegrenzt werden soll. Wir haben alle Eigenschaften der Zulieferer bis auf das Bild über die Attribute definiert. Eines, id, dient zur Identifizierung. name, location und product enthalten spezifische Daten und die Attribute mit dem Präfix xlink stellen einen einfachen XLink zur Webseite der Firma (bzw. im Unterelement pic zu einem Bild des Firmensitzes) dar, den wir natürlich ausführlich im Kapitel 6.5, „XLink“, besprechen. Lassen Sie sich also nicht von den XLink-Attributen verwirren. Hier der erste Zulieferer:

Wie in HTML können auch in XML Kommentare verfasst werden, die von einem Prozessor nicht als Textknoten, sondern als eigenständiger Knoten betrachtet werden. Sie haben folgende Form, die der für HTML gültigen Kommentare entspricht:

Zeichenreferenzen

Geschützte Zeichen wie die öffnende spitze Klammer sind geschützt und dürfen deshalb nicht außerhalb des Markups verwendet werden. Als Alternative bieten sich Zeichenreferenzen an, die das gewünschte Zeichen zur Anzeige bringen. Für oben genanntes Zeichen kann dies zum Beispiel die interne Einheit &lt ; sein (lt steht für „less than“ – kleiner als).

Verarbeitungsanweisungen

Verarbeitungsanweisungsknoten (engl.: Processing Instructions) erlauben es einem Dokument, Anweisungen für einen Anwendung zu spezifizieren. Hierin kann die Anwendung auch benannt werden. So kann ein XSL Stylesheet benannt werden, welches das Dokument transformieren soll.

Auch der Typ des Dokuments selbst kann definiert werden. Dies wird vom W3C-Konsortium empfohlen, falls eventuelle spätere Versionen unterschieden werden sollen.

Ein Dokument nach der Spezifikation XML 1.0 sollte so beginnen, wie wir es weiter oben schon gesehen haben:

<?xml version="1.0"?>

Deklarationen

Einheiten eines XML-Dokuments können deklariert werden, es kann also ihre Gültigkeit beschrieben werden. Dies ermöglicht, selbst erstellte Dokumente wartbarer und portabel zu machen. Ist eine Gültigkeitsdefinition wie zum Beispiel eine DTD eingebunden (auch interne Deklarationen sind möglich), so finden sich dort Deklarationen für Einheiten und enthaltene Einheiten Folgender Knoten ist ein Top-Level-Knoten, das heißt, er steht auf der gleichen Ebene wie Verarbeitungsanweisungen und Root-Element:

Außerdem wurde hier die physische Einheit pref deklariert. Die Benutzung dieser Einheit ist ein kleiner Trick, denn sie wird als Parameter-Einheit benutzt. Wofür wir sie brauchen, sei später verraten, im Kapitel zur Gültigkeit.

Text

Der Rest des Dokuments ist Text, der (außer Attribut-Werten) die eigentlichen Daten des Dokuments darstellt. Hierbei ist darauf zu achten, keine gesperrten Zeichen zu verwenden, die der Prozessor als XML-Zeichen interpretiert (dazu werden Zeichenreferenzen verwendet, s.o.). Soll ein größerer Textabschnitt nicht vom Prozessor prozessiert werden, kann ein CDATA – Abschnitt helfen, die den Text enthält. Ein CDATA - Abschnitt hat folgende Form: <![CDATA[ Text ]]>

4.4. Namensräume

Ein wichtiges Konzept von XML sind die so genannten Namensräume (Namespaces). Da XML-Dokumente unterschiedlicher Herkunft Elemente gleichen Namens enthalten können, bietet XML die Möglichkeit, jedes Element einem Namensraum zuzuweisen.

Ein weiterer Grund sind die für eine Anwendung (beispielsweise XSL, siehe Kapitel 8, „Weiterverarbeitung und Anzeige: XSL(T)“) vordefinierten Elemente. Sie müssen von den vom Entwickler des Dokuments frei wählbaren Elementen unterschieden werden. Durch ein Namensraum-Präfix kann dies geschehen.

XML Namespaces ist eine eigene Spezifikation aus dem Jahr 1998. XML 1.0 kennt das Konzept der Namensräume noch nicht, ebenso wie die DTD (siehe Kapitel 4.6.1, „DTD“).

Namespaces verwenden eine URI (siehe Kapitel 6.1, „Exkurs: URI/URL“), um eindeutige Zeichenketten zu definieren. Ob dahinter eine erreichbare Ressource liegt, ist hier nicht von Bedeutung. Da aber viele Entwickler(-Firmen) eigene Webadressen haben, ist bei Verwendung der URL wenig Gefahr gegeben, dass Dritte die gleiche Zeichenkette wählen. Als zusätzlicher, aber non-funktionaler Aspekt ist Zuordnung zum Verfasser gegeben (Es gab trotzdem Diskussionen, eine erreichbare Ressource bereitzustellen. Siehe dazu Kapitel 7.5, „Meta-Metadaten am Beispiel RDDL“).

Namensräume werden für Elemente und Attribute zugeordnet und von diesen an ihre Nachkommen vererbt, sollten diese sie nicht mit einem eigenen Namensraum überschreiben.

Die Definition eines Namensraumes erfolgt immer mit "xmlns". Mit einem Doppelpunkt kann einem Namensraum hier auch ein Präfix zugeordnet werden, welches Elemente später an Stelle der Definition verwenden können. Die Definition der im Dokument verwendeten

Namensräume erfolgt meist im Root-Element. Es folgt ein Beispiel für eine Deklaration eines XLink-Namensraumes und seiner Verwendung:

Abbildung in dieser Leseprobe nicht enthalten

4.5. wohlgeformte Dokumente

„Ein Datenobjekt ist ein XML -Dokument, wenn es im Sinne dieser Spezifikation wohlgeformt ist.“^[7]

Dieser Satz aus der XML-Spezifikation deutet auf die Regeln hin, denen sich jedes XML-Dokument zu unterwerfen hat. Durch Bestehen auf einigen festen Regeln, die einem XML-Dokument mehr abverlangen als einem HTML-Dokument, wurde eine geringere Fehlerdichte in XML-Dokumenten und in Folge dessen eine bessere und schnellere Verarbeitung derselben durch Maschinen angestrebt. Zudem wird der Programmierer gezwungen, stärker auf den Aufbau seines Dokuments zu achten.

Zunächst muss ein Dokument mindestens ein Element enthalten, welches als Wurzel-Element fungiert und das einzige Element auf dieser höchsten Ebene ist.

Während ein HTML-Tag nicht geschlossen zu werden braucht, ist dies in XML zwingend nötig. Dies ist auch eine zwingende Vorraussetzung für die folgende Regel: Wird ein Element b in einem anderen Element a geöffnet, so muss es auch in diesem geschlossen werden. Diesen Vorgang nennt man Verschachtelung (engl.: nesting). Nur auf diese Art und Weise kann sich die klassische Baum-Struktur entwickeln, die XML kennzeichnet.

Folgendes Beispiel zeigt ein nicht wohlgeformtes Dokument.

Es wird deutlich, warum aus diesem Dokument keine Baumstruktur entwickelt werden kann: In welchem Element ist das Element Nummer2 enthalten? Es wird im Element Nummer1 geöffnet, jedoch im Element wurzel geschlossen.

Abbildung in dieser Leseprobe nicht enthalten

Jeder Prozessor muss auf Wohlgeformtheit bestehen.

[...]

---

^[1] Vgl DeRose, S. (1999)

^[2] vgl. Rotermund, H. (1995)

^[3] vgl. Berners-Lee, T. (1997)

^[4] vgl. Bray, T. u.a. (1998)

^[5] vgl. Kay, M (2001), S.27

^[6] vgl Münz, S (2001)

^[7] Bray, T. u.a. (1998)