Diese Diplomarbeit befasst sich mit der manuellen Erzeugung von Topic Maps, einem plattformunabhängigen Hilfsmittel zur standardisierten Abbildung von Ordnungsstrukturen, und beschreibt ein Konzept zur Nutzung der XForms-Technologie für die Entwicklung einer Applikation zur Erfassung von einfach strukturierten Topic Maps, das schließlich anhand einer Modellimplementierung geprüft wird.
Den Beginn der Arbeit bildet ein Überblick über Technologien und Konzepte im Bereich der Extensible Markup Language (XML) und Topic Maps. Im Mittelpunkt dieser Beschreibung steht der XForms-Standard zur plattformunabhängigen Definition von formularbasierten Benutzeroberflächen und das XML Topic Map-Format zur Repräsentation von Topic Maps. Danach wird ein Vergleich zwischen der automatischen Generierung und einer manuellen Erfassung von Topic Maps vorgenommen, wobei unter anderem Methoden und Techniken vorgestellt werden, die bei der automatischen Topic Map-Erzeugung Anwendung finden. Aufbauend auf diesen Technologien wird ein Konzept für einen auf dem XForms-Standard basierenden Editor zur Erfassung von Topic Maps im XML Topic Map-Format entwickelt, das anschließend anhand einer Modellimplementierung umgesetzt wird.
Die Ergebnisse dieser Implementierung zeigen, dass eine Kombination der XForms- und der Topic Map-Technologie technisch möglich ist. Da im Zuge der Applikationsentwicklung nicht die gesamte Topic Map-Funktionalität implementiert wurde, bleibt es in weiteren Arbeiten zu untersuchen, ob sich mit XForms-Dokumenten auch komplexe Topic Maps erstellen lassen. Weiters müssen in zukünftigen Arbeiten Usability-Tests zur Überprüfung der Benutzerfreundlichkeit des entwickelten XTM-Editors durchgeführt werden, da diese im Rahmen der Diplomarbeit nicht behandelt werden konnten.
Inhaltverzeichnis
1. Einleitung
1.1 State of the Art
2. Technologischer Hintergrund - Begriffe und Konzepte
2.1 XML und verwandte Technologien
2.1.1 XHTML
2.1.2 XForms
2.2 Das Konzept der Topic Maps
2.2.1 Geschichtliche Entwicklung
2.2.2 Topic Map-Grundlagen
2.2.3 XML Topic Maps 1.0
3. Erstellung von Topic Maps
3.1 Automatische Generierung vs. manuelle Erstellung
4. Entwicklung eines Topic Map-Editors
4.1 Spezifikation der Anforderungen
4.2 Konzept des XTM-Editors
4.3 Erstellung eines XTM 1.0-Grobgerüsts
4.4 Entwurf des XForms-Formulars
4.4.1 Definition des XForms models
4.4.2 Das User Interface des XTM-Editors
5. Überprüfung der Funktion des Editors
5.1 Anzeige des XTM-Editors im X-Smiles Browser
6. Zusammenfassung der Ergebnisse
7. Quellenverzeichnis
8. Anhang
8.1 XML Schema für XTM 1.0-Dokumente
8.2 Beispiel einer Topic Map im XTM-Format
8.3 Cascading Stylesheet für die optische Aufbereitung des XTM-Editors
8.4 Sourcecode des XTM-Editors
8.5 JSP-Code zur Anzeige der mit dem XTM-Editor erstellten Topic Map
Verzeichnis der Abkürzungen
Abbildung in dieser Leseprobe nicht enthalten
Verzeichnis der Abbildungen und Tabellen
Tab. 1: Aufbau der Diplomarbeit
Abb. 1: Einfaches Beispiel eines XML-Dokumentes
Abb. 2: XForms-Formular in einem XHTML-Dokument
Abb. 3: Trennung der Formulardaten vom User Interface (W3C, 2002c)
Abb. 4: XForms-Funktionsweise (W3C, 2002c)
Abb. 5: Topics und deren Typen (Pepper, 2002b)
Abb. 6: Darstellung von Occurrences (Pepper, 2002b)
Abb. 7: Assoziationen zwischen Topics (Pepper, 2002b)
Abb. 8: Auszug aus einer XML Topic Map
Abb. 9: Schematische Vorgehensweise des Ontopia MapMakers (Pepper, 2002a)
Abb. 10: Konzept des XTM-Editors
Abb. 11: Basisstruktur der XTM-Topic Map für den XTM-Editor
Abb. 12: XHTML- Rumpfdatei
Abb. 13: Auszug aus dem XForms model
Abb. 14: Syntax zur Sprachauswahl
Abb. 15: Verwendung des <xforms:itemset>-Elements
Abb. 16: Definition von Buttons zur Erzeugung und Entfernung von Topics
Abb. 17: Formularfelder zur Erfassung eines Assoziationsteilnehmers
Abb. 18: Benutzeroberfläche des XTM-Editors
Abb. 19: Ausgabe der erzeugten XML Topic Map
“In order to achieve the full potential of Topic Maps,
we need tools to integrate these conceptual maps
with our vast repositories of documents and recorded dialog,
as well as tools for manipulating and viewing
these structures in different ways.”
- Douglas C. Engelbart
(Park, 2002)
1. Einleitung
Seitdem die erste standardisierte Topic Map-Notation durch die International Organization for Standardization im Dezember 1999 verabschiedet wurde, begannen sich mit der Zeit immer mehr Firmen und Open Source-Projekte mit diesem Thema zu beschäftigen. Man erhoffte sich dadurch zumindest Ausschnitte aus den ständig anwachsenden Informationsmengen durch diese neue Technologie in geeigneter Weise abbilden und ordnen zu können. Gleichzeitig wollte man auch eine Möglichkeit zur Verfügung stellen, um die Navigation in diesen Ordnungssystemen zu erleichtern.
Parallel dazu arbeitet das World Wide Web Consortium (W3C), das unter anderem Spezifikationen rund um das Thema „Extensible Markup Language (XML)“ veröffentlicht, gerade an einer auf XML basierenden Auszeichnungssprache für die Beschreibung von Formularen, die XForms genannt wird.
Vor diesem Hintergrund und ausgehend von der Problemstellung, dass trotz der relativ weiten Verbreitung des Topic Map-Ansatzes bislang nur eine sehr begrenzte Zahl an Werkzeugen, die nicht mit dem Ankauf von teuren und meist sehr komplexen Softwarepaketen verbunden sind, zur manuellen Erstellung von Topic Maps im XTM (XML Topic Maps)-Austauschformat erhältlich ist, wird in dieser konzeptionellen Arbeit die zentrale Fragestellung untersucht, ob sich auf Grundlage der XForms- und XML Topic Map-Technologie ein generelles Konzept für eine Applikation erarbeiten lässt, die von Benutzern, welche bereits mit der Begriffswelt des Topic Map-Standards vertraut sind, zur manuellen Erstellung von Wissensstrukturen im XML Topic Map-Format verwendet werden kann.
Bezugnehmend auf die oben dargestellte Fragestellung wird folgende Hypothese aufgestellt:
- Aufgrund ihrer gemeinsamen XML-Grundlage und ihrer Konzeption ist es technisch möglich, die XForms- und XTM-Technologie in einer solchen Weise zusammenzuführen, dass sich auf Basis dessen eine neuartige Applikation zur Erstellung von einfach strukturierten Topic Maps entwickeln lässt.
Es wird daher in dieser Arbeit ausgehend von einem generellen Konzept zur Kombination der XForms- und XTM-Technologie im Rahmen einer Modellimplementierung erstmals der Versuch unternommen, einen auf XForms basierenden Editor anzufertigen. Dieser Editor soll es einem bereits mit dem Topic Map-Konzept und den damit verbundenen Begriffen vertrauten User ermöglichen, mit Hilfe einer graphischen Benutzeroberfläche simple XML Topic Maps zu erstellen. Der Fokus dieser Unternehmung liegt dabei lediglich auf der Erfassung von Topic Maps und berücksichtigt weder die Ontologienfindung noch die permanente Speicherung der im Editor erzeugten Topic Map.
In Anbetracht dieses Arbeitsziels richtet sich die vorliegende Diplomarbeit an jene Leser, deren Interesse in der praktischen Anwendung des Topic Map-Ansatzes oder in den neuesten Entwicklungen und Trends der Informationsbeschreibung- und -verarbeitung im Umfeld der Extensible Markup Language liegt. Diese Arbeit soll jedoch auch jene potentiellen Rezipienten ansprechen, die sich im Auftrag der Spezifikations-entwickelnden Konsortien und Arbeitsgruppen mit der praktischen Implementierbarkeit ihrer Standards beschäftigen oder auf der Suche nach neuartigen Ansätzen zur technischen Kombination unterschiedlicher Technologien sind. Angesichts dieser Zielgruppe kann davon ausgegangen werden, dass der Leser bereits mit den Grundlagen der technischen Informationsdarstellung mittels Auszeichnungssprachen oder Markup Languages wie auch mit den damit verbundenen termini technici vertraut ist.
Der grundlegende Aufbau der Diplomarbeit gliedert sich in mehrere aufeinander aufbauende Bereiche. In den ersten Abschnitten werden dem Leser mehrere Technologien, die in engem Zusammenhang mit der Extensible Markup Language (XML) stehen und teilweise schon sehr weite Verbreitung gefunden haben, vorgestellt, wobei der Schwerpunkt nicht auf der jeweiligen Syntax, sondern auf deren wesentlichen Konzepten liegt. Bei näherem Interesse des Lesers an den einzelnen Bestandteilen der in diesem Kapitel vorgestellten Auszeichnungssprachen wird daher an dieser Stelle auf die jeweiligen Sprach-Spezifikationen und Sekundärliteratur verwiesen, deren Bibliographie sich im Literaturverzeichnis der Diplomarbeit befindet.
Ab Kapitel 2.2 erfolgt eine umfassende Einführung in das Thema Topic Maps, in der sowohl die geschichtliche Entwicklung des Standards als auch mehrere Austauschformate wie HyTM (HyTime Topic Map) oder XTM kurz vorgestellt werden. In diesem Zusammenhang werden schließlich auch Unterschiede zwischen diesen Formaten aufgezeigt.
Nach der Beschäftigung mit der theoretischen Seite der Topic Maps soll in Kapitel 3 eine grobe Gegenüberstellung der manuellen und der automatischen Erstellung von Topic Maps erarbeitet werden. Dabei wird auch einer der möglichen Ansätze zur automatischen Generierung anhand einer kommerziellen Applikation genauer beleuchtet. Aufgrund der enormen Komplexität des Themas und des begrenzten Zeit- und Arbeitsumfangs der vorliegenden Diplomarbeit muss allerdings bedacht werden, dass nur ein Ansatz aus vielen zur automatischen Erzeugung von Topic Maps in seinen groben Zügen vorgestellt werden kann.
Der Schwerpunkt der Arbeit liegt jedoch auf der in Kapitel 4 beschriebenen Definition eines Konzepts für die Entwicklung eines Editors zur Erstellung von XML Topic Maps, das anschließend anhand einer Modellimplementierung umgesetzt werden soll. In diesem Kapitel werden dabei nicht nur die wichtigsten Anforderungen festgehalten, sondern auch Einblicke in die verwendete Syntax zur Konstruktion des Tools gegeben wie auch die einzelnen Erstellungsschritte genau dargestellt.
Der in Kapitel 5 durchgeführten generellen Funktionsüberprüfung des erstellten Editors mit Hilfe des X-Smiles Browsers, der die Anzeige von in XForms abgebildeten Formularen ermöglicht, folgt eine Zusammenfassung der Ergebnisse der vorliegenden Diplomarbeit im letzten Abschnitt.
Im beigefügten Anhang finden sich sämtliche Quellcodes, die der Autor im Zuge der Applikationsentwicklung erstellt hat.
Abbildung in dieser Leseprobe nicht enthalten
Tab. 1: Aufbau der Diplomarbeit
1.1 State of the Art
Nachdem das Topic Map-Konzept bereits vor mehreren Jahren einer breiten Öffentlichkeit präsentiert wurde (siehe Kapitel 2.2.1), hat es seit diesem Zeitpunkt nach und nach Einzug in die Welt der Informationstechnologie (IT) gehalten. So erschienen vor allem im Zuge der letzten beiden Jahre vereinzelte Bücher und wissenschaftliche Arbeiten, die sich mit diesem Thema intensiv auseinandersetzen. Während sich der Großteil dieser Schriften mit den grundlegenden Konzepten, der Syntax und den denkbaren Anwendungsfällen befasst, ist bislang nur eine kleine Anzahl an Publikationen erschienen, die sich mit der Kombination von Topic Maps mit anderen bereits bestehenden Technologien beschäftigen. Als einzige Ausnahme muss hier die Verbindung zum Resource Description Framework-Standard genannt werden, die in einigen Arbeiten hinreichend behandelt wurde.
Obwohl viele IT-Experten bereits mit dem theoretischen Aspekt der Topic Maps zumindest oberflächlich vertraut sind, liegt die Hemmschwelle für den Einsatz von Topic Maps in komplexen Projekten oftmals immer noch sehr hoch.
Betrachtet man das Spektrum der vorhandenen Topic Map-Applikationen, wobei unter diesem Begriff jedwede Software verstanden werden soll, die eine Be- oder Verarbeitung von Topic Maps ermöglicht, zeigt sich ein ähnliches Bild. Nur wenige Unternehmen wie zum Beispiel Ontopia, empolis oder Mondeca verschrieben sich seither der Entwicklung von kommerziellen Topic Map-Applikationen. Auch im Open Source-Bereich sind neben dem GooseWorksToolkit und TM4J nur wenige aktive Projekte bekannt, die diesem Zweck dienen.
Trotz dieser begrenzten Produktauswahl und der großteils noch abwartenden Haltung der IT-Experten lässt sich anhand aktueller Projektausschreibungen vor allem im Bereich des „Search and Retrievals“ und der steigenden Besucherzahlen von Konferenzen zum Thema „Topic Maps“ ein steigendes Interesse erkennen. Dementsprechend wurden in letzter Zeit auch vermehrt Case Studies von erfolgreichen Topic Map-Projekten veröffentlicht. Dessen ungeachtet muss bemerkt werden, dass sich das Topic Map-Konzept in Bezug auf den praktischen Projekteinsatz und die Unterstützung durch entsprechende Softwarepakete immer noch im Anfangsstadium befindet.
Während Topic Map-Interessenten zumindest mit grundlegender Literatur in Form von einigen wenigen wissenschaftlichen Arbeiten oder Büchern versorgt werden, ist neben den öffentlichen Spezifikationen des XForms-Standards bislang nur eine spärliche Anzahl an brauchbaren Arbeiten oder Artikeln zu diesem Thema auf verschiedenen Online-Plattformen wie zum Beispiel xml.com erschienen. Diese Gegebenheit lässt sich jedoch darauf zurückführen, dass es sich bei der XForms-Technologie um einen sehr jungen Standard handelt und viele der Mitarbeiter des World Wide Web Consortiums momentan in erster Linie mit der Weiterentwicklung der Spezifikation beschäftigt sind. Obwohl einer der wesentlichen Autoren der XForms-Spezifikation für Mai 2003 ein umfassendes Buch zu diesem Thema ankündigte, wird es aller Voraussicht nach noch eine gewisse Zeit dauern, bis die verschiedenen Aspekte der XForms-Technologie in der wissenschaftlichen Forschung Einzug halten werden.
Aufgrund dieser Tatsache konnten im Zuge der Literatur- und Informationsrecherche zur Erhebung des aktuellen Standes der Forschung im Vorfeld dieser Diplomarbeit keinerlei Materialien gefunden werden, die sich mit einer Kombination der XForms- und Topic Map-Technologie oder mit der Verwendung von XForms-basierten Benutzeroberflächen zur Erzeugung von standardisierten XML-Strukturen befassen.
Die vorliegende Diplomarbeit kann daher als ein erster Forschungsversuch gesehen werden, der sich intensiv mit diesem Thema beschäftigt und die XForms-Technologie hinsichtlich der Möglichkeit einer gemeinsamen Verwendbarkeit mit anderen XML-basierten Standards testet.
2. Technologischer Hintergrund - Begriffe und Konzepte
Um dem interessierten Leser ein besseres und umfassendes Verständnis dieser Diplomarbeit zu ermöglichen, wird in den folgenden Kapiteln ein kurzer Abriss über die dieser Arbeit zugrunde liegenden Technologien und deren wichtigste Konzepte gegeben. Außerdem werden häufig verwendete Fachausdrücke durch Begriffsbestimmungen abgeklärt.
2.1 XML und verwandte Technologien
Die Extensible Markup Language, kurz XML genannt, wurde von einer Arbeitsgruppe des World Wide Web Consortiums (W3C), das – wie bereits in der Einleitung kurz erwähnt - für die Entwicklung und Überwachung von mittlerweile mehr als 35 technischen Spezifikationen und Standards, darunter auch die HyperText Markup Language, kurz HTML, zur Erweiterung der Möglichkeiten des World Wide Webs verantwortlich zeichnet, unter der Leitung von Tim Bray am 10. Februar 1999 als W3C Standard verabschiedet.
Vereinfacht dargestellt lässt sich XML als eine system- und plattformunabhängige Datenbeschreibungssprache bezeichnen, die es auf einfachem Weg ermöglicht, sowohl Rohdaten als auch deren semantische Beschreibung strukturiert innerhalb eines aus reinem Text bestehenden Dokumentes zu erfassen. Diese Beschreibung der Rohdaten erfolgt dabei ähnlich wie in HTML durch Inhaltsauszeichnungen (engl. „markup“). Diese Inhaltsauszeichnungen gliedern sich wiederum in Elemente, die auch „tags“ genannt werden, und Attribute (siehe Abb.1).
Da es in XML keinerlei vordefinierten Inhaltsauszeichnungen wie zum Beispiel in HTML gibt[1], kann der Benutzer beliebig eigene Elemente und Attribute festlegen. Diese enorme Flexibilität und Erweiterbarkeit macht XML zu einer „Metamarkupsprache“, da aufbauend auf den Prinzipien von XML sehr einfach andere Auszeichnungssprachen definiert werden können[2].
Eines der wichtigsten Konzepte der Extensible Markup Language besteht in der strikten Trennung von Inhalt, Struktur und Layout. Während in einem XML-Dokument lediglich Daten und deren Beschreibungen enthalten sind (siehe Abb. 1), wird die Definition der Struktur dieser Daten (DTDs oder XML Schemas) und der graphischen Präsentation an anderer Stelle, meist in einem eigenen Dokument, gespeichert.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Einfaches Beispiel eines XML-Dokumentes
Grundsätzlich kann man zwei Typen von XML-Dokumenten voneinander unterscheiden: wohlgeformte einerseits und gültige oder valide XML-Dokumente anderseits. Streng genommen ist ein nicht wohlgeformtes XML-Dokument kein XML-Dokument im eigentlichen Sinne. Die Wohlgeformtheit definiert die Grenze zwischen XML und nicht-XML, da es sich um symbolische Mindestanforderungen an ein XML-Dokument handelt. Ein XML-Dokument wird erst dann wohlgeformt genannt, wenn es folgende syntaktische Grundregeln erfüllt:
- Das XML-Dokument besteht aus mindestens einem Element.
- Es gibt im gesamten XML-Dokument ein Element, das alle enthaltenen Daten umschließt. Dieses Element wird auch als „Root-Element“ bezeichnet.
- Alle Attributwerte sind entweder in einfachen oder doppelten Anführungszeichen eingeschlossen.
- Innerhalb eines Elementes müssen Attributnamen eindeutig sein.
- Alle Elemente sind logisch korrekt ineinander ohne Überlappungen verschachtelt.
- Elemente müssen entweder ein Start- und Ende- Tag aufweisen (z.B.: <element></element>) oder in sich geschlossen sein (<element/>). Dabei gilt es die Groß- und Kleinschreibung zu berücksichtigen.
Damit eine Applikation ein XML-Dokument verarbeiten kann, muss es sich mindestens um ein wohlgeformtes Dokument handeln. Wird der Applikation kein wohlgeformtes Dokument übergeben, sollte diese einen kritischen Fehler rückmelden.
Im Gegensatz zu rein wohlgeformten verfügen gültige oder valide Dokumente noch über zusätzliche Definitionen bezüglich aller im XML-Dokument erlaubten Elemente und Attribute, Regeln zur hierarchischen Verschachtelung dieser Elemente und etwaige Einschränkungen der möglichen Element- und Attributwerte. Diese Informationen werden, wie bereits weiter oben erwähnt, meistens extern, getrennt von den eigentlichen Daten, gespeichert. Je nach Format und Syntax dieser Regeldefinitionen unterscheidet man Document Type Definitions (DTD) von XML Schemas, die beide über einen entsprechenden Eintrag im XML-Dokument referenziert werden. Erst wenn allen vorhandenen Regeln entsprochen wird, kann man von gültigen oder validen XML-Dokumenten sprechen.
Nachdem in diesem Kapitel die grundlegenden Konzepte und Prinzipien der Extensible Markup Language erläutert wurden, sollen nun in den folgenden Abschnitten weitere Auszeichnungssprachen kurz vorgestellt werden, die auf Basis von XML definiert wurden.
2.1.1 XHTML
Schon bald nach der Verabschiedung des XML-Standards ging die Arbeitsgruppe des World Wide Web Consortiums, die bisher für die Definition der HTML-Spezifikation verantwortlich war, unter Steven Pemberton daran, einen auf XML beruhenden Nachfolger der HyperText Markup Language zu entwerfen.. Diese W3C-Arbeitsgruppe beschreibt XHTML mit den Worten:
“The Extensible HyperText Markup Language (XHTML™) is a family of current and future document types and modules that reproduce, subset, and extend HTML, reformulated in XML. XHTML Family document types are all XML-based, and ultimately are designed to work in conjunction with XML-based user agents. XHTML is the successor of HTML, and a series of specifications has been developed for XHTML.”
(W3C, 2002a)
Durch die strikte Reformulierung von HTML, bei der grundsätzlich alle Auszeichnungselemente und Attribute von HTML 4.01 in XHTML übernommen wurden, existieren nun konkrete Richtlinien für den Aufbau von Webseiten, die auch für gewöhnliche XML-Applikationen verständlich und verarbeitbar sein sollen. Ein weiteres wichtiges Einsatzgebiet von XHTML stellt die Verwendung als Container oder „Host Language“ für Elemente aus anderen auf XML basierenden Standards wie zum Beispiel XForms dar. Um diese Funktionalität noch zu verbessern und auszubauen, wurde in Version 1.1, die am 31. Mai 2001 vom W3C verabschiedet wurde, eine Modularisierung von XHTML vorgenommen. Dabei wurden funktional zusammengehörige Sprachelemente zu Modulen zusammengefasst, die auf einfache Weise mit Modulen anderer Auszeichnungssprachen kombiniert werden können. Wie solch ein Zusammenspiel zwischen verschiedenen Markupsprachen innerhalb von XHTML aussehen kann, soll im nächsten Kapitel anhand eines konkreten Beispiels veranschaulicht werden (Abb. 2).
Momentan arbeitet man gerade an der Version 2.0 von XHTML, in der grundlegende Änderungen vorgenommen werden. Nach Angaben der HTML-Arbeitsgruppe des World Wide Web Consortiums (W3C, 2002a) wird XHTML 2.0 im Gegensatz zu bisherigen XHTML-Spezifikationen nicht mehr mit älteren Versionen kompatibel sein. Gründe für diese Inkompatibilität dürften zum einen die Einführung von neuen Elementen zur Verbesserung der Strukturierung von Webseiten und zum anderen die Ablöse der <form> und <frameset> Elemente sein, deren Funktion von anderen Markupsprachen wie zum Beispiel XForms übernommen werden soll.
Die Entwicklung von XHTML 2.0 wird jedoch noch einige Zeit in Anspruch nehmen.
2.1.2 XForms
Schon seit dem HTML Standard 2.0, der bereits im November 1995 vom W3C verabschiedet wurde und als kleinster gemeinsamer Nenner zwischen den verschiedensten Web- Browsern gilt, wurde die Möglichkeit zur Verfügung gestellt, Formulare für Webseiten zu entwickeln. Seither wurden nur geringfügige Anpassungen bezüglich der zur Verfügung stehenden Bestandteile vorgenommen. Das grundlegende Konzept dieser HTML-Formulare wurde jedoch in dieser Zeit nicht geändert. In vielen Anwendungsbereichen sind uns Web- Formulare sehr vertraut geworden. So werden vor allem im Bereich des E- Commerce viele Transaktionen wie zum Beispiel Bestellungen oder Anfragen mittels Formularen vorgenommen.
Trotz ihrer großen Verbreitung weisen HTML-Formulare jedoch auch viele Nachteile auf, von denen Dubinko (2002) folgende nennt:
- keine Möglichkeit der Integration von XML,
- erhöhter Skriptaufwand für Eingabevalidierungen,
- device dependent, laufen nur zufriedenstellend auf Desktop Clients,
- keine Trennung von Zweck und Präsentation.
Aufgrund dieser und einiger weiterer Unzulänglichkeiten wurde vom W3C eine eigene Arbeitsgruppe unter Micah Dubinko gegründet, welche die Aufgabe hat, einen auf XML beruhenden Nachfolger der HTML-Formulare zu entwickeln. Als erstes Resultat ihrer Bemühungen wurde im Dezember 2000 der erste Entwurf zu XForms 1.0 präsentiert. In der aktuellen Fassung der Spezifikation findet man folgende kurze Beschreibung von XForms:
“XForms is an XML application that represents the next generation of forms for the Web. By splitting traditional XHTML forms into three parts—XForms model, instance data, and user interface—it separates presentation from content, allows reuse, gives strong typing—reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting.
XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML or SVG.”
(W3C, 2002b)
In dieser kurzen Zusammenfassung werden bereits einige sehr wichtige konzeptuelle Neuerungen im Vergleich zu HTML-Formularen angesprochen. Obwohl XForms in einer eigenständigen Spezifikation behandelt wird, stellt die XForms-Arbeitsgruppe klar dar, dass XForms nicht als eigener Dokumenttyp fungieren, sondern in eine andere Containersprache wie zum Beispiel XHTML oder SVG (Scalable Vector Graphics), einer vom W3C standardisierten Markupsprache zur Beschreibung von auf XML basierenden Vektorgraphiken, eingebettet werden soll.
Wie eine solche Einbettung eines XForms-Formulars in ein XHTML-Dokument aussehen kann, soll in Abbildung 2 veranschaulicht werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: XForms-Formular in einem XHTML-Dokument
Eine der grundlegendsten Veränderungen stellt jedoch die strikte Trennung der Präsentation des User Interfaces (Checkboxen, Eingabefelder...) von den eigentlichen Formulardaten, die zusammengefasst XForms model genannt werden, dar.
Diese Abkoppelung des User Interfaces, das ausschließlich die Möglichkeiten der Dateneingabe durch den User umfasst, hat nun den Vorteil, dass - abhängig vom verwendeten Endgerät des Users - unterschiedliche Möglichkeiten der Repräsentation der Formulareingabe gewählt werden können (vgl. Abb. 3). So wäre es zum Beispiel denkbar, dass für mobile Endgeräte wie Mobiltelefone oder PDAs eine andere, weniger aufwendige Darstellung angezeigt wird als in einem herkömmlichen Web- Browser auf einem PC.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3: Trennung der Formulardaten vom User Interface (W3C, 2002c)
Im Gegensatz zum User Interface beinhaltet das XForms model, das zum Beispiel innerhalb des Kopfteiles[3] eines XHTML-Dokuments definiert werden könnte, nun verschiedene Arten von Daten, die den Zweck und die Funktionalität des Formulars beschreiben:
- XForms instance
- Angaben zur Übertragung der Formulardaten
- Eingabeüberprüfung und Validierung
- Verknüpfungen zwischen XForms instance und User Interface
Einen wesentlichen Bestandteil des XForms model bildet die so genannte XForms instance, die als ein in XForms eingelagertes XML-Fragment verstanden werden kann. Bei der Befüllung eines Formulars werden dann die durch den User eingegebenen Formularwerte in Form eines Element- oder Attributwertes innerhalb dieser XForms instance gespeichert. Dabei ist es natürlich auch möglich, dass Werte bereits in der XForms instance abgelegt sind und somit als Vorgabewerte in Formularfeldern verwendet werden können.
Woher weiß allerdings die Applikation, auf welche Weise das User Interface mit der XForms instance verknüpft wird? Die Beantwortung dieser Frage gestaltet sich durchaus schwierig, da in der XForms-Spezifikation mehrere verschiedene Verknüpfungsarten angeführt werden. Zum einen können die Elemente des User Interfaces direkt mit Teilen der XForms instance verbunden werden, und zum anderen existieren eigene <bind> Elemente, die diese Aufgabe übernehmen und zusätzlich Einschränkungen und Abhängigkeiten definieren können. So ist es zum Beispiel möglich, bestimmte Formularteile nur dann anzuzeigen, wenn zuvor bestimmte Einstellungen durch den User vorgenommen wurden. Der User könnte damit nur dann zur Eingabe seiner Kreditkartendaten aufgefordert werden, wenn er beispielsweise zuvor die Zahlungsmöglichkeit mit Kreditkarte ausgewählt hat. Innerhalb der <bind> Elemente kann aber auch angegeben werden, dass bestimmte Teile der XForms instance unbedingt befüllt werden müssen, bevor das Formular abgeschickt werden kann.
Wird das XForms-Formular, nachdem es ausgefüllt wurde, abgeschickt, werden im Gegensatz zu HTML-Formularen nicht nur die eingegebenen Formularwerte mit ihren Bezeichnungen in Form von name- value pairs[4], sondern die komplette XForms instance als vollständiges XML-Dokument übergeben (siehe Abb. 4).
Innerhalb des Elements <submission>, das ebenfalls Bestandteil des XForms model ist, wird nun definiert, wohin die XForms instance beim Abschicken des Formulars gesendet werden soll, welcher Zeichensatz verwendet wurde, oder auch, mit welchem Protokoll die Formulardaten übertragen werden sollen.
Während es bei den HTML-Formularen noch nötig war, eigene Javascripts für Eingabeüberprüfungen zu entwickeln, bietet XForms eigene Mechanismen zur Überprüfung der Richtigkeit von Formulardaten. So besteht zum Beispiel auch die Möglichkeit, ein XML Schema, das der Beschreibung der XForms instance-Daten dienen soll, zur Validierung einzubinden (vgl. Kapitel 2.1). Zu diesem Zweck wurde im XForms model ein Attribut namens „schema“ bereitgestellt, mit dem ein externes Schema über einen Hyperlink referenziert werden kann. Anhand dieses eingebundenen Schemas soll es der Applikation, die das XForms-Formular bearbeitet, ermöglicht werden, Formulareingaben des Users beim Abschicken der Daten zu überprüfen und gegebenenfalls eine Fehlermeldung anzuzeigen, wenn die Validierung Fehler aufgedeckt hat.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4: XForms-Funktionsweise (W3C, 2002c)
Wendet man seine Aufmerksamkeit den einzelnen Elementen des User Interface zu, die auch form controls genannt werden, fällt sofort auf, dass grundsätzlich viele Ansätze von den herkömmlichen HTML-Formularen übernommen wurden. Trotzdem wurden alle form controls auf einer sehr abstrakten Ebene definiert. Dies hat nun zur Folge, dass es der Applikation, die das Formular anzeigen soll, überlassen bleibt, wie die genaue Anzeige des Formulars aussehen soll. Anstatt wie in HTML-Formularen anzugeben, dass ein Formularfeld, in dem nur eine einzige Option gewählt werden kann, als Checkbox- Auswahl angezeigt werden soll, existiert in XForms nur mehr die Möglichkeit, ein <select1> Element zu definieren, wobei es allein der anzeigenden Applikation obliegt, wie sie dieses Element dem User präsentiert. Durch diese enorme Flexibilität in der Darstellung kann für jedes Endgerät in Abhängigkeit von den zur Verfügung stehenden Kapazitäten die optimale Anzeige der Formularteile gewählt werden.
Ein weiterer Teil der XForms-Spezifikation besteht in der Definition bestimmter Funktionen, die formularinterne Berechnungen und Zeitausgaben durchführen können. Ein möglicher Anwendungsfall für solche Funktionen wäre beispielsweise ein Bestellformular, das in der Lage ist, automatisch einen Bestellpreis zu berechnen, der abhängig von bestimmten Eingaben durch den User ist.
Obwohl die Entwicklung der XForms-Spezifikation stetig voranschreitet, wird es voraussichtlich noch einige Zeit dauern, bis XForms 1.0 als verabschiedeter W3C-Standard vorliegt. In der Zwischenzeit ist es wichtig, dass sich möglichst viele Software-Entwickler mit der Implementierung von XForms in ihre Applikationen beschäftigen, um somit der W3C-Arbeitsgruppe wertvolles Feedback über Konzept und Machbarkeit von XForms geben zu können.
2.2 Das Konzept der Topic Maps
Nachdem in den Kapiteln zuvor lediglich Technologien erläutert wurden, die in engem Zusammenhang mit der Extensible Markup Language stehen, soll in den nun folgenden Abschnitten das Konzept der Topic Maps eingehend betrachtet werden. Dabei soll noch vor der Vermittlung von Topic Map-Grundlagen auf die geschichtliche Entstehung und Evolution eingegangen werden, da dieses Wissen für das Verständnis der nachfolgenden Kapitel hilfreich sein kann.
2.2.1 Geschichtliche Entwicklung
Schon bald, nachdem Tim Berners-Lee, der als Begründer des Hyperlink-Verfahrens und des World Wide Webs (WWW) gilt, den Begriff des „Semantic Webs“, das verschiedenartige Informationen – beispielsweise in Form von Webpages - in eine sowohl für Menschen als auch für Computer leicht verarbeitbare semantische Struktur bringen soll, geprägt hatte, tauchte auch das Konzept der Topic Maps erstmals auf.
Obwohl sich bereits Anfang der 90er Jahre verschiedenste Konsortien und Organisationen mit diesem Thema beschäftigt hatten, begann die vielversprechende Entwicklung der Topic Maps erst, als eine eigene Arbeitsgruppe der ISO (International Organization for Standardization) mit dem etwas kryptischen Namen ISO/JTC1/SC18/WG8 im Jahr 1995 alle bisherigen Arbeiten koordinierte und die Standardisierung des Topic Map-Konzepts zügig vorantrieb. Diese von Michel Biezunski und Steven R. Newcomb angeführte Gruppe versuchte nun während der folgenden Zeit, einen Standard zu schaffen, der dem so genannten Biezunski-Prinzip gerecht werden sollte:
“There is no point in creating a standard that nobody can understand.”
(Park & Hunting, 2002)
So wurde nach dreijähriger Arbeitszeit im Jahr 1999 der einfach verständliche Topic Map-Standard finalisiert und ein Jahr später unter dem Namen ISO/IEC 13250:2000 publiziert.
Innerhalb dieses Standards wurde jedoch nur eine Syntax zur Beschreibung und zum Austausch von Topic Maps genauer spezifiziert, die auf dem bereits älteren und mittlerweile durch die auf XML basierende Linking-Sprache XLink abgelösten Linking-Konzept HyTime beruht. Diese Notation wird daher auch als HyTM (HyTime Topic Maps) bezeichnet.
Auf Grund dessen wurde schon bald nach der Publikation des ISO 13250 Standards das unabhängige Konsortium TopicMaps.org von mehreren Mitgliedern der ISO-Arbeitsgruppe und anderen Interessenten gegründet, die sich zum Ziel setzten, in kürzester Zeit ein auf XML und XLink beruhendes Austauschformat für Topic Maps zu entwickeln. Als Ergebnis dieser Bemühungen wurde nur ein Jahr später - im Rahmen der XML 2000-Konferenz in Washington, DC - das XTM (XML Topic Maps) Format vorgestellt.
Nachdem XTM bereits am 2. März 2001 in seiner finalen Version vorlag und auch schon von vielen Firmen in Topic Map-Applikationen implementiert wurde, machte sich nun wiederum die ISO-Arbeitsgruppe daran, ihren ISO 13250 Standard zu adaptieren und diese neue Syntax einzubinden, so dass darin nun zwei mögliche Austauschformate für Topic Maps beschrieben werden. Als daher das Konsortium TopicMaps.org Ende Oktober 2001 seine Arbeit getan hatte, wurden ihre Agenden zur Gänze von OASIS (Organization for the Advancement of Structured Information Standards) übernommen und werden somit auch in Zukunft weitergeführt werden.
2.2.2 Topic Map-Grundlagen
Nachdem nun die Entwicklung des Topic Map-Konzepts bekannt ist, bleibt dennoch die Frage offen, wozu Topic Maps eigentlich dienen und worin ihr Einsatzgebiet zu sehen ist. Um dies beantworten zu können, ist es nötig, sich die gegenwärtige Situation zu veranschaulichen, in der sich zum Beispiel Internet-User täglich befinden.
[...]
[1] vgl. dazu zum Beispiel die HTML-Elemente <h1>, <p>, <table>, u.s.w.
[2] Beispiele für auf XML basierende Markupsprachen wären zum Beispiel XHTML, XForms und XTM, die in den folgenden Kapiteln noch erläutert werden.
[3] In einem XHTML-Dokument befindet sich der Kopfteil innerhalb des <head> Elementes.
[4] Zum Beispiel: Autor=Michael Kay, Titel=XSLT: 2nd Edition
- Arbeit zitieren
- Roman Huditsch (Autor:in), 2003, Implementierung eines auf der XForms-Technologie basierenden Editors zur manuellen Erfassung von XTM 1.0 Topic Maps, München, GRIN Verlag, https://www.grin.com/document/195493
-
-
-
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.