Upload
arno-huetter
View
856
Download
2
Embed Size (px)
Citation preview
Implementierung eines Editors zur Erstellung
generischer und dynamischer Hypertexte
Diplomarbeit zur Erlangung des akademischen Grades Diplom-Ingenieur
in der Studienrichtung Informatik
Angefertigt am Institut für Technische Informatik und Telematik,
Abteilung Telekooperation
Von:
Mag. Arno Hütter
Betreuung:
o.Univ.-Prof. Dipl.-Ing. Dr. J. Volkert
Mitbetreuung:
Dipl.-Ing. T. Kopetzky
Linz, Juli 2001
Eidesstattliche Erklärung
„Ich erkläre an Eides Statt, daß ich die Diplomarbeit mit dem Titel 'Implementierung eines
Editors zur Erstellung generischer und dynamischer Hypertexte' selbständig und ohne
fremde Hilfe verfaßt, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und
alle den benutzten Quellen wörtlich oder sinngemäß entnommenen Stellen als solche kennt-
lich gemacht habe.“
Linz, den 30. Juli 2001 (Arno Hütter)
Zusammenfassung
Seit Vannevar Bush 1945 in seinem visionären Artikel "As we may think" mit der Idee eines
"Memex" eine Maschine beschrieb, welche gigantische Informationsmengen adäquat zu orga-
nisieren und damit den menschlichen Intellekt zu unterstützen suchte (und bereits alle wesent-
lichen Eigenschaften des heute gültigen Hypertext-Paradigmas enthielt), hat das anbrechende
Informationszeitalter tatsächlich sämtliche technische Voraussetzungen geschaffen, um diese
Idee umzusetzen und einer breiten Allgemeinheit zugänglich zu machen. Inwieweit der Hy-
pertext-Ansatz in der Zwischenzeit selbst konzeptionelle Weiterentwicklung erfahren hat, ist
jedoch kritisch zu hinterfragen.
Der im Zuge dieser Diplomarbeit entwickelte Hypertext-Editor geht auf einen Ansatz zur Er-
weiterung des Hypertext-Konzepts zurück, einen Formalismus namens "WebStyles", welcher
von Martin Richartz von der Universität Karlsruhe in seiner Dissertationsschrift (dort noch
unter dem Namen "PreScript") vorgelegt wurde. Das WebStyles Modell ermöglicht eine effi-
zientere Erstellung von Hypertexten durch Ableitung generischer Vorlagen und enthält dane-
ben ein regelbasiertes System zur Unterstützung des Benutzers bei Navigation durch den Hy-
pertext.
Der Editor wurde mit dem Ziel realisiert, dem Hypertext-Autor ein möglichst einfach zu
handhabendes Werkzeug zur Verfügung zu stellen, das dennoch die gesamte Mächtigkeit des
WebStyles-Ansatzes unterstützt. Eine Voraussetzung dafür ist eine intuitive graphische Be-
nutzeroberfläche, wobei der Hypertext in abstrakter Weise und losgelöst von etwaigen kon-
kreten Hypertext-Architekturen bearbeitet werden kann. Es werden unterschiedliche Export-
Formate unterstützt, als Referenzimplementierung wurden Java Servlets unter Verwendung
von HTML-Vorlagen gewählt.
Abstract
In 1945, Vannevar Bush described a machine called "Memex" in his visionary article "As we
may think". The Memex was able to organize an enormous amount of information in order to
encourage the human intellect. The concept included all essential properties of today's hyper-
text paradigms. Since then the information technology era has laid the basis to implement
these ideas and share them among a large community of individuals. But from a critical point
of view it is questionable whether the hypertext approach has conceptually improved from the
early days until present.
The hypertext editor implemented in this diploma thesis is based on an approach to enrich the
hypertext concept with a formalism called "WebStyles", introduced by Martin Richartz in his
doctoral thesis at the University of Karlsruhe (originally under the name "PreScript"). The
WebStyles model allows an efficient construction of hypertexts derived from generic tem-
plates and includes a controller-based system to support the user during navigation in the hy-
pertext.
The editor has been developed to provide the hypertext author with a tool that on the one hand
is simple to use and on the other hand contains all the power that the WebStyles approach
offers. An intuitive graphical user interface forms the preliminary for editing hypertext in an
abstract way, independent of any concrete hypertext architecture. Different export formats are
supported. Java Servlets and HTML-templates were chosen as a reference implementation.
Inhaltsverzeichnis
Inhaltsverzeichnis
1. Einleitung ___________________________________________1
1.1 Motivation _________________________________________________________1
1.2 Ausgangspunkt dieser Arbeit__________________________________________3
1.3 Gliederung _________________________________________________________4
2. Hypertext - Geschichte und gegenwärtige Systeme__________5
2.1 Begriffsbestimmung _________________________________________________5
2.2 Historischer Hintergrund_____________________________________________7
2.2.1 Vorgeschichte__________________________________________________7
2.2.2 Pionierarbeiten _________________________________________________8
2.2.2.1 Vannevar Bush: Memex __________________________________8
2.2.2.2 Douglas C. Engelbart: NLS/Augment_______________________11
2.2.2.3 Theodor Nelson: Xanadu_________________________________12
2.2.3 Hypertext im Zeitalter des Personal Computers ______________________15
2.2.3.1 HyperCard ____________________________________________16
2.2.3.2 NoteCards ____________________________________________17
2.2.3.3 Intermedia ____________________________________________18
2.2.3.4 Dexter Hypertext-Referenzmodell _________________________19
2.2.3.5 Digital LinkWorks______________________________________20
2.2.3.6 World Wide Web_______________________________________20
2.2.3.7 Hyper-G / HyperWave___________________________________25
2.2.3.8 Aktuelle Technologien und Werkzeuge _____________________27
2.2.3.9 Schlußfolgerungen______________________________________29
3. Das WebStyles Modell ________________________________31
3.1 Überblick _________________________________________________________31
3.2 Benutzerrollen _____________________________________________________32
3.3 Hypertext-Komponenten ____________________________________________32
Inhaltsverzeichnis
3.3.1 Hypertext-Objekt ______________________________________________33
3.3.2 Hypertext-Knoten______________________________________________33
3.3.3 Aggregat-Knoten ______________________________________________34
3.3.4 Hypertext-Link________________________________________________34
3.3.5 Hypertext-Anker_______________________________________________35
3.4 Generische Netze ___________________________________________________36
3.4.1 Generische Knoten_____________________________________________36
3.4.2 Generische Links ______________________________________________39
3.4.3 Stränge ______________________________________________________41
3.4.4 Hypertext-Konstruktion _________________________________________46
3.5 Navigationsmodell __________________________________________________48
3.6 Prozeduren________________________________________________________51
3.7 Zusammenfassung__________________________________________________53
4. Implementierung ____________________________________54
4.1 Wahl von Entwicklungssprache und -umgebung_________________________54
4.2 Systemarchitektur __________________________________________________55
4.2.1 Java Packages_________________________________________________58
4.3 Objektorientierte Entwurfsmuster ____________________________________59
4.3.1 Observer _____________________________________________________59
4.3.2 Singleton ____________________________________________________62
4.3.3 Model-View-Controller _________________________________________65
4.3.4 Memento ____________________________________________________67
4.4 Ausgewählte Implementierungsproblemstellungen _______________________68
4.4.1 Interaktive Bearbeitung des WebStyles-Graphen _____________________68
4.4.2 Vorschau-Ansicht in Dateidialogen ________________________________69
4.4.3 Hypertext-Dokumenteditor ______________________________________71
4.4.4 WebStyles-Laufzeitumgebung____________________________________73
5. Anwendung _________________________________________77
5.1 Graphische Benutzeroberfläche_______________________________________77
Inhaltsverzeichnis
5.1.1 Menü File ____________________________________________________78
5.1.2 Menü Edit____________________________________________________79
5.1.3 Menü View___________________________________________________79
5.1.4 Menü Tools __________________________________________________80
5.1.5 Symbolleiste__________________________________________________81
5.1.6 Knoten- und Link-Kontextmenüs _________________________________82
5.1.7 Knoten-Properties _____________________________________________83
5.1.7.1 Generischer Knoteninhalt ________________________________84
5.1.8 Hypertext-Dokumenteditor ______________________________________87
5.1.9 Link-Properties________________________________________________88
5.2 Beispiele für Hypertext-Entwürfe _____________________________________90
5.2.1 Konstruktionsbeispiel Firmenpräsentation___________________________90
5.2.2 Konstruktionsbeispiel Computer Based Training (CBT)________________93
6. Resümee und Ausblick_______________________________102
Quellenverzeichnis_____________________________________104
Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung 1: Die Idee des Memex im Verständnis seiner Zeit________________________10
Abbildung 2: Historische Notizen von Theodor Nelson: Links zwischen Dateien_________13
Abbildung 3: Xanadu: Paralleles Bearbeiten mehrerer Dokumente, graphische Darstellung
von Links _________________________________________________________________14
Abbildung 4: Hypertext-Browser, Hypertext-Server und Hypertext-Gateway ____________22
Abbildung 5 : Generische Knotentypen und mögliche Ableitungen____________________37
Abbildung 6: Generische Linktypen und mögliche Ableitungen ______________________40
Abbildung 7: Markierungen des Strang-Algorithmus _______________________________42
Abbildung 8: Mehrfachinstantiierung von Sequenzknoten ___________________________43
Abbildung 9: Mehrfachinstantiierung von Fächerlinks______________________________44
Abbildung 10: Zusammenführung von Strängen über einen Fächerlink_________________45
Abbildung 11: Beispiel für eine Strang-Instantiierung ______________________________46
Abbildung 12: Klassendiagramm (Ausschnitt) ____________________________________56
Abbildung 13: Java-Packages des WebStyles-Editors ______________________________58
Abbildung 14: Das Observer-Entwurfsmuster ____________________________________60
Abbildung 15: Das Model-View-Controller Schema _______________________________65
Abbildung 16: Dateidialog mit Vorschau-Ansicht _________________________________69
Abbildung 17: Graphische Benutzeroberfläche des WebStyles-Editors _________________77
Abbildung 18: Das Menü File _________________________________________________78
Abbildung 19: Das Menü Edit_________________________________________________79
Abbildung 20: Das Menü View________________________________________________79
Abbildung 21: Das Menü Tools _______________________________________________80
Abbildung 22: Symbolleiste __________________________________________________81
Abbildung 23: Knoten-Kontextmenü ___________________________________________82
Abbildung 24: Link-Kontextmenü _____________________________________________82
Abbildung 25: Knoten-Properties ______________________________________________83
Abbildung 26: Generischer Knoteninhalt ________________________________________85
Abbildung 27: Der Hypertext-Dokumenteditor____________________________________87
Abbildung 28: Link-Properties ________________________________________________88
Abbildungsverzeichnis
Abbildung 29: Hypertext-Konstruktion Firmenpräsentation (Schritt 1) _________________90
Abbildung 30: Hypertext-Konstruktion Firmenpräsentation (Schritt 2) _________________91
Abbildung 31: Definition von Inhaltsschablonen __________________________________92
Abbildung 32: Hypertext-Konstruktion Firmenpräsentation (Schritt 3) _________________93
Abbildung 33: Hypertext-Konstruktion CBT (Schritt 1)_____________________________94
Abbildung 34: Hypertext-Konstruktion CBT (Schritt 2)_____________________________95
Abbildung 35: Hypertext-Konstruktion CBT (Schritt 3)_____________________________96
Abbildung 36: Hypertext-Konstruktion CBT (Schritt 4)_____________________________97
Abbildung 37: Definition von Navigationsregeln __________________________________98
Abbildung 38: Festlegung von Links im Hypertext-Dokumenteditor___________________99
Abbildung 39: Kontextabhängige Sichtweise des Knoteninhalts (1) __________________100
Abbildung 40: Kontextabhängige Sichtweise des Knoteninhalts (2) __________________101
Einleitung 1
1. Einleitung
1.1 Motivation
Das World Wide Web (WWW) ist zwar das mit Abstand meistgenutzte Hypertext-System -
und damit ein De-facto-Standard - aber bei weitem nicht das ausgereifteste. Die Ansprüche an
moderne Hypertexte können von den dem WWW zugrundeliegenden Bausteinen Hypertext
Markup Language (HTML) und Universal Resource Locator (URL) alleine nicht erfüllt
werden. Einige über die bestehenden Konzepte hinausgehende Forderungen sind von besonde-
rer Bedeutung: [TRTJ97]
Bei der Erstellung von Hypertexten
• Umfassende Styleguides (Entwurfsrichtlinien) für die Konstruktion von Hypertexten
• Mächtigere Entwicklungs- und Beschreibungssprachen (über aktuelle Ansätze wie JavaSc-
ript oder Cascading Style Sheets hinausgehend)
• Autoren-Werkzeuge, deren Einsatz tatsächliche Effizienzsteigerungen mit sich bringt
• Systematische Testmethoden
Bei der Verwendung von Hypertexten
• Navigationsunterstützung für den Benutzer (Stichwort: "Lost in Hyperspace")
• Verknüpfungshilfen
• Integrierte Suchfunktionen
• Informationsrepräsentierung durch den Hypertext in Form eines semantischen Netzwerks
Einleitung 2
Vor der Globalisierung des Hypertexts durch das WWW wurden Hypertext-Dokumente all-
gemein als eine in sich geschlossene Menge von Knoten und Links aufgefaßt (so bedeutet
auch der Begriff "Website" nicht nur den physischen Standort, sondern eine Menge von mit-
einander in Beziehung stehenden Links und Knoten). Unter HTML sind Links jedoch darauf
beschränkt, von einem Dokument bzw. Dokumentabschnitt zum nächsten zu führen. Das
World Wide Web kann - kritisch betrachtet - als eine Sammlung von lose verknüpften Sub-
netzen (in der Folge als "Hypertexte" bezeichnet) gesehen werden.
Es gab bisher kaum Anstrengungen, das Potential einer einheitlichen Strukturierung und Typi-
sierung von Hypertexten zu nutzen - es fehlen auch die dazu nötigen Standards. Bemühungen,
Aufbau und Funktionalität von HTML-Hypertexten zu verbessern, beschränkten sich bisher
hauptsächlich auf die Einführung neuer Typen von HTML-Tags (Marken) und einige enga-
gierte Ansätze wie RDF (Resource Description Framework, dient der Beschreibung und dem
Austausch von Metadaten). Die Wiederverwendung und Aufbereitung von Inhalten kann
durch geeignete serverbasierte Ansätze (Content Management Systeme, Datenbank/Web-
Gateways, etc.) verbessert werden. Eines der Hauptprobleme des WWW liegt jedoch weiter-
hin in der mangelnden Struktur, was neben der fehlenden konzeptuellen Unterstützung auch
auf die manuelle Erstellung und Wartung von HTML-Dokumenten zurückzuführen ist. Viele
Web Authoring Werkzeuge sind im Grunde Textverarbeitungsprogramme, die um das Kon-
zept des Universal Resource Locator erweitert wurden [MHK98]. Erst in letzter Zeit finden
auch vermehrt umfassendere Site-Management Tools Verwendung.
Unter HTML gibt es bereits eine primitive Form der Typisierung, indem Knoteninhalten Me-
dientypen und Dateiformate zugeordnet werden können. Auch Attributierung, wie sie im Fall
von HTML durch das sogenannte Meta-Tag erreicht wird, kann als eine Art von Typkonzept
betrachtet werden. Fortgeschrittenere Systeme unterstützen einen objektorientierten Ansatz
durch die Spezifikation von Methoden auf Objekttypen. In offenen Hypertextsystemen sind
Ankertypen von besonderer Bedeutung, da dadurch die Integration von Anwendungen (E-
Mail, Kalender, etc.) bewerkstelligt werden kann. Typisierung ermöglicht die Klassifizierung
und Indizierung der Hypertext-Elemente und eine nahtlose und konsistente Integration in ei-
nen größeren Kontext.
Einleitung 3
Auf Hypertextebene müssen Knoten- und Linktypen zu einer aussagekräftigen Gesamtstruktur
zusammengefügt werden. Ein einfacher Ansatz zur Lösung dieses Problems wäre eine Klassi-
fikation von Tupeln in der Form Knoten-Link-Knoten. Die Anforderungen an moderne Hyper-
text-Systeme gehen jedoch darüber hinaus: Hypertext-Typen sollten einen Bauplan für korres-
pondierende konkrete Hypertexte repräsentieren.
Die Vorteile eines solchen Konzepts sind vielfältig. Wann immer Wissen in einen Hypertext-
Typ einfließt, kann dieses Know-How bei jeder folgenden Konstruktion wiederverwendet
werden. Dies führt zu konsistenten Hypertext-Strukturen, da die Ersteller gewissen Vorgaben
folgen müssen. Neue Hypertext-Netze können durch komponentenweises Zusammenfügen
existierender Netze entstehen. Ein solches Modell erlaubt die Entfaltung eines gemeinsamen
"Look & Feels" von Hypertexten innerhalb einer Organisation. Der dadurch gewonnene Wie-
dererkennungseffekt reduziert den kognitiven Overhead beim Benutzer. Indizierung und
Suchstrategien werden verbessert, da darin nun Struktur- und Inhaltsaspekte einfließen. Ganze
Anwendungen können auf Basis der Kenntnis des Hypertext-Typs entstehen, etwa lernende
Systeme, die ausgehend von Strategievorschriften benutzerspezifische Navigationsmuster
unterstützen. [MHK98]
Bei der Erweiterung bestehender Hypertext-Paradigmen ist aber auch Vorsicht geboten. Denn
die Idee des Hypertexts lebt von ihrer konzeptionellen Schlichtheit. Sie stellt einen Mecha-
nismus dar, in dem der Informationsmodellierung praktisch keine Grenze gesetzt sind, und
den auch Computer-Laien in kürzester Zeit erlernen können.
1.2 Ausgangspunkt dieser Arbeit
1995 veröffentlichte Martin Richartz an der Universität Karlsruhe seine Dissertation über ein
erweitertes Hypertext-Konzept namens "PreScript". PreScript geht auf ein gemeinsames For-
schungsprojekt mit der Firma Digital Equipment zurück, in dem Hypertexte zur Informati-
onsmodellierung im computergestützten Unterricht eingesetzt wurden.
Einleitung 4
PreScript enthält Strukturierungs- und Orientierungshilfen für Autoren und Benutzer von Hy-
pertexten durch
• ein Konstruktionsprinzip für Hypertexte durch Ableitung von Hypertexttypen,
• ein regelbasiertes System zur Unterstützung bei der Navigation durch den Hypertext, und
• ein prozedurales Paradigma durch einen Scripting-Ansatz.
Das Projekt wurde an der Abteilung für Telekooperation der Universität Linz unter dem Titel
"WebStyles" weitergeführt, und resultierte schließlich in der konkreten Implementierung im
Rahmen dieser Arbeit.
1.3 Gliederung
Kapitel 2 beschäftigt sich mit den Ursprüngen und der Geschichte von Hypertext, und unter-
zieht bestehende Hypertext-Modelle einer kritischen Betrachtung. In Kapitel 3 wird der
WebStyles-Ansatz in einem für das Verständnis dieser Arbeit adäquaten Detaillierungsgrad
erläutert. Das darauffolgende Kapitel skizziert die bei der Implementierung des WebStyles-
Editors eingesetzten Softwaretechniken. Kapitel 5 beschreibt die Anwendung des Editors an-
hand einiger konkreter Beispiele. In Kapitel 6 werden die gewonnenen Erkenntnisse zusam-
mengefaßt, und die Arbeit mit einem kurzen Ausblick abgeschlossen.
Hypertext - Geschichte und gegenwärtige Systeme 5
2. Hypertext - Geschichte und gegenwärtige Systeme
2.1 Begriffsbestimmung
Der Versuch, eine allgemein akzeptierte Definition des Begriffs des Hypertexts zu finden,
gestaltet sich schwierig. Es lassen sich jedoch zwei Kategorien von Beschreibungsansätzen
identifizieren, nämlich jene, die typischerweise in populärwissenschaftlichen Medien oder
Marketingschriften verwendet werden, und jene der technisch-wissenschaftlichen Literatur
[Bardini97].
Folgende Auslegungen sind der ersten Gruppe zuzuordnen:
• Hypertexte funktionieren eher über Assoziation als Indizierung.
• Hypertexte sind ein Format für die nicht-sequentielle Darstellung von Ideen.
• Hypertexte sind die Aufhebung des traditionellen, linearen Ansatzes der Informationsdar-
stellung und -verarbeitung.
• Der Inhalt von Hypertexten ist nicht an Strukturen oder Organisationen gebunden.
Wissenschaftliche Definitionsansätze sind:
• Hypertext ist ein Ansatz zur Erstellung von Systemen zur Repräsentation und zum Mana-
gement von Informationen über ein Netzwerk von Knoten, die durch typisierte Links mit-
einander verbunden sind. [Halasz88]
• Hypertext ist ein elektronisches Dokument, ein Ansatz des Informationsmanagements,
wobei Daten in einem Netz von Knoten und Links abgelegt werden. Ein Hypertext kann
Hypertext - Geschichte und gegenwärtige Systeme 6
durch interaktive Browser betrachtet, und durch Struktureditoren manipuliert werden.
[SM88]
• Hypertext stellt eine Technik zur Organisation von textuellen Informationen auf eine kom-
plexe, nicht-lineare Weise und zur raschen, explorativen Zugänglichmachung von großen
Wissensbasen zur Verfügung. [WS88]
Konzeptuell kann ein Hypertext als ein gerichteter Graph betrachtet werden, wobei jeder Kno-
ten ein Textstück darstellt, und die Kanten des Graphen miteinander in Beziehung stehende
Textstücke verbinden. Dem Benutzer wird eine Schnittstelle angeboten, über welche Text
betrachtet und Links überquert werden können, wenn neue Interessensbereiche in den Vorder-
grund rücken
Die Wortschöpfung "Hypertext" geht auf Theodor H. Nelson zurück. Für Nelson war Hyper-
text ursprünglich ein für seine Arbeit als Autor gedachtes Werkzeug, das er wie folgt be-
schrieb:
"[A tool that] allows you to see alternative versions on the same screen on
parallel windows and mark side by side what the differences are. Not by scan-
ning but by analysis of data structure. Now the system I started designing in
the 1960s, allows you, would have allowed you, will allow you to see connec-
tions between the contents of different windows, like rubber bands between the
middles of the windows" [Bardini97]
Geprägt wurde der Begriff auch von der Bedeutung des Worts "hyper" in der Mathematik, wo
es oftmals als Synonym für "erweitert" und "verallgemeinert" verwendet wird.
Die Abkehr von der traditionellen Linearität war für Nelson eines der wichtigsten Merkmale
von Hypertexten - er sprach selbst nannte sie auch eine Form des "Non-Sequential Writings".
Nelson sah darin die Automatisierung von in der gedruckten Literatur üblichen Querverwei-
Hypertext - Geschichte und gegenwärtige Systeme 7
sen, mit dem Unterschied, daß diese nunmehr zum Hauptstrukturmerkmal von Texten wur-
den.
In einem Hypertext werden Informationen eines engeren Sinnzusammenhangs zu überschau-
bare Einheiten aufgesplittet, die als Knoten bezeichnet werden. Diese Informationseinheiten
können durch Links erreicht werden. Links sind gerichtete Verweise zwischen den Knoten,
und stellen den strukturellen Teil der Information dar.
Ein Link kann zu vertiefenden, übergeordneten oder verwandten Informationen führen. Diese
Allgemeinheit ist es auch, die beim praktischen Einsatz des Hypertextkonzepts Probleme ver-
ursacht.
Als Anker bezeichnet man den Zielpunkt eines Links. Dieser Zielpunkt muß nicht notwendi-
gerweise immer ein ganzer Knoten sein, vielmehr kann auch eine Teilmenge des Knotenin-
halts als Anker fungieren.
2.2 Historischer Hintergrund
2.2.1 Vorgeschichte
Bemühungen, Wissen zu sammeln und in einer für den Menschen geeigneter Form zugänglich
zu machen, gibt es schon lange, ebenso wie die Tradition des Einsatzes technischer Hilfsmittel
zu diesem Zweck.
Die geschichtlichen Wurzeln des Hypertext-Konzepts liegen in einem für die Informatik prä-
historischen Zeitalter. Im Mittelalter wurde das stetig wachsende Wissen der Menschheit
hauptsächlich in klösterlichen Bibliotheken verwaltet. Während der Renaissance konstruierten
Mönche ein Gerät, welches aus einem Räderwerk bestand, auf dem mehrere Bücher befestigt
Hypertext - Geschichte und gegenwärtige Systeme 8
wurden. Somit war es möglich, beim Lesen schnell zwischen verschiedenen Werken hin- und
herzuspringen. Nicht umsonst bedeutet der Begriff "Enzyklopädie" wörtlich übersetzt "Rad
des Lernens".
2.2.2 Pionierarbeiten
2.2.2.1 Vannevar Bush: Memex
Vannevar Bush war während des Zweiten Weltkriegs Präsident des Massachusetts Institute for
Technology (MIT) in Cambridge und einer der hochrangigsten Militärberater der US-
Regierung. Als das Ende des Krieges absehbar war, veröffentlichte er 1945 den visionären
Artikel "As We May Think", in dem er die Idee eines "Memex" (Memory Extenders) be-
schrieb, das den Menschen bei sich wiederholenden Denkvorgängen unterstützen sollte.
Bushs akademisches Hauptinteresse galt dem Gebiet der wissenschaftlichen Kommunikation.
Seine Sorge war, daß die stetig wachsende Menge an wissenschaftlicher Literatur nicht mehr
richtig genutzt werden könnte.
"The real heart of the matter of selection, however, goes deeper than a lag in
the adoption of mechanisms by libraries, or a lack of development of devices
for their use. Our ineptitude in getting at the record is largely caused by the ar-
tificiality of systems of indexing. When data of any sort are placed in storage,
they are filed alphabetically or numerically, and information is found (when it
is) by tracing it down from subclass to subclass. It can be in only one place,
unless duplicates are used; one has to have rules as to which path will locate
it, and the rules are cumbersome. Having found one item, moreover, one has to
emerge from the system and re-enter on a new path. The human mind does not
work that way. It operates by association. With one item in its grasp, it snaps
instantly to the next that is suggested by the association of thoughts, in accor-
dance with some intricate web of trails carried by the cells of the brain. It has
Hypertext - Geschichte und gegenwärtige Systeme 9
other characteristics, of course; trails that are not frequently followed are
prone to fade, items are not fully permanent, memory is transitory. Yet the
speed of action, the intricacy of trails, the detail of mental pictures, is awe-
inspiring beyond all else in nature." [Bush45]
Bush kritisierte, daß die meisten existierenden Indexmöglichkeiten auf hierarchischen, alpha-
betischen oder numerischen Strukturen basierten. Diese Strukturen wären aber nicht auf spezi-
fische menschliche Fähigkeiten zugeschnitten, wie etwa jene, Assoziationen zu knüpfen. Nach
Bush's Auffassung benötigte man anstelle der traditionellen Lagerungs- und Indizierungsme-
thoden der Bibliotheken ein natürlicheres System, welches eher der Funktionsweise des
menschlichen Gehirns entsprechen sollte. Das Memex war ein solches fiktives System, um
große Mengen von Informationen zu verwalten. Eine der Ideen dahinter bestand in der Nut-
zung von „Natural human principles“ für die Ablage und das Wiederfinden von Dokumen-
ten. In seinem Manuskript bezeichnete Bush dieses Prinzip als "Selection by association".
Das Memex selbst beschrieb Bush wie folgt:
"Consider a future device for individual use, which is a sort of mechanized
private file and library. It needs a name, and, to coin one at random, 'memex'
will do. A memex is a device in which an individual stores all his books, re-
cords, and communications, and which is mechanized so that it may be con-
sulted with exceeding speed and flexibility. It is an enlarged intimate supple-
ment to his memory.
It consists of a desk, and while it can presumably be operated from a distance,
it is primarily the piece of furniture at which he works. On the top are slanting
translucent screens, on which material can be projected for convenient read-
ing. There is a keyboard, and sets of buttons and levers. Otherwise it looks like
an ordinary desk.
Hypertext - Geschichte und gegenwärtige Systeme 10
In one end is the stored material. The matter of bulk is well taken care of by
improved microfilm. Only a small part of the interior of the memex is devoted
to storage, the rest to mechanism. Yet if the user inserted 5000 pages of mate-
rial a day it would take him hundreds of years to fill the repository, so he can
be profligate and enter material freely." [Bush45]
Abbildung 1: Die Idee des Memex im Verständnis seiner Zeit [HT98]
Die Idee des Memex basiert auf den damals aktuellen Technologien der Feinmechanik und der
Mikrophotographie. Wesentlicher als dieser Umstand ist jedoch, daß das Memex in einem
Hypertext - Geschichte und gegenwärtige Systeme 11
direkten Schritt assoziative Verknüpfungen erlaubt, indem aus einem Dokument heraus ohne
Verzögerung ein anderes ausgewählt werden kann. Der Benutzer kann diese Verbindungen
herstellen, indem er sie mit einem Namen versieht und in ein Codebuch einträgt. Über eine
Tastatur wird die Verknüpfung bestätigt und besteht von da an dauerhaft.
Wird später eines der beiden verknüpften Dokumente erneut aufgerufen, kann direkt über ei-
nen Tastendruck auf das andere zugegriffen werden. Ganze Listen von verketteten Dokumen-
ten können in beliebiger Geschwindigkeit durchgesehen werden, und ergeben in ihrer Ge-
samtheit wiederum neue Dokument. Das Memex erlaubt auch das Einfügen persönlicher No-
tizen, und verfügt damit über alle wesentlichen Eigenschaften, die der heutige Hypertext-
Ansatz vorsieht. Einen Versuch, das von Vannevar Bush beschriebene System zur Unterstüt-
zung des menschlichen Intellekts zu verwirklichen, hat es jedoch nie gegeben. Es hat aller-
dings allein durch seine Konzeption die Entwicklung vieler späterer Hypertextsysteme maß-
geblich beeinflußt.
2.2.2.2 Douglas C. Engelbart: NLS/Augment
Inspiriert von Vannevar Bushs Artikel begann Douglas C. Engelbart Anfang der fünfziger
Jahre eine bis heute andauernde Arbeit an der Vision eines "Conceptual Framework for the
Augmentation of Man’s Intellect". Am Stanford Research Institute in Palo Alto, Kalifornien
entwickelte er später das System NLS/Augment. Es enthielt bereits eine Vielzahl von Elemen-
ten, die heute ganz selbstverständlich auf modernen Arbeitsplatzrechnern eingesetzt werden.
Dokumente und Informationen wurden in drei Bereichen, die mit unterschiedlichen Zugriffs-
arten versehen waren, abgelegt: einem Bereich für Wegwerfnachrichten, Briefe und Notizen,
einem weiteren für gemeinsam benutzte Dokumente, und einem dritten Bereich für eingefro-
rene, bibliotheksähnliche Dokumente. Zwischen den Dokumente und über die Grenzen der
einzelnen Bereiche hinaus bestanden Querverweise. Jeder Benutzer verfügte über einen per-
sönlichen Arbeitsplatz, von dem aus er auf die Dokumente zugreifen und sie parallel mit an-
deren Benutzern betrachten konnte.
Hypertext - Geschichte und gegenwärtige Systeme 12
Engelbart wird berechtigterweise als geistiger Vater des Personal Computers und von Compu-
ter Supported Cooperative Work (CSCW) bezeichnet. Von ihm stammt u.a. die erste Imple-
mentierung eines Fenstersystems, er erfand die Maus als Eingabegerät, in seinem System gab
es erstmals elektronische Post, Textverarbeitung und die integrierte Darstellung von Grafiken.
Vieles was nicht von ihm selbst stammt, wurde von seinen ehemaligen Mitarbeitern später am
XEROX Palo Alto Research Center entwickelt [Richartz95].
2.2.2.3 Theodor Nelson: Xanadu
Theodor H. Nelson begann Mitte der sechziger Jahre Beiträge zu seiner Vorstellung eines
Hypertexts zu veröffentlichen. Eine wegweisende Arbeit aus dem Jahr 1965 trug den Titel
"The Hypertext". Weiters beschäftigte sich Nelson mit der verteilten Speicherung großer Da-
tenmengen, und mit durch den verbreiteten Computereinsatz entstehenden Liberalisierungsef-
fekten.
Nelsons Ansätze zum Thema Hypertext sind die ambitioniertesten der drei Pioniere, und des-
halb wohl auch am schwersten umzusetzen. Das von Nelson initiierte Xanadu Projekt steht für
ein Netzwerk eines weltumspannenden elektronischen Docuverse (Dokumenten-Universum),
in dem alle Dokumente publiziert werden. Ähnlich wie unter NLS/Augment gibt es persönli-
che und öffentliche Dokumentenbereiche, ebenso wie persönliche und öffentliche Links.
Links sind gerichtet, aber immer von beiden Seiten aus sichtbar und verfolgbar.
"A link is simply a connection between parts of text or other material. It is put
in by a human. Links are made by individuals as pathways for the reader's ex-
ploration; thus they are part of the actual document, part of a writing." [Nel-
son99]
Hypertext - Geschichte und gegenwärtige Systeme 13
Abbildung 2: Historische Notizen von Theodor Nelson: Links zwischen Dateien [Maurer01]
Später entwickelte Nelson Links zu sogenannten Transclusions weiter. Transclusions erlauben
es, Dokumente oder Teile von Dokumenten in andere Dokumente einzubetten, ohne sie zu
kopieren. Dies vermeidet redundante Speicherung und garantiert, dass die eingebetteten Do-
kumente immer auf aktuellem Stand sind. Das Prinzip der Transclusions entspricht in etwa
eingebetteten Dokumenten in modernen Textverarbeitungssystemen.
Hypertext - Geschichte und gegenwärtige Systeme 14
Abbildung 3: Xanadu: Paralleles Bearbeiten mehrerer Dokumente, graphische Darstellung
von Links [Nelson99]
Xanadu ist bisher nur in Teilbereichen realisiert. Durch den Siegeszug des World Wide Web
gerieten Nelsons Arbeiten etwas in Vergessenheit, dennoch verfolgt er mit unverminderter
Vehemenz die Verwirklichung seiner Idee weiter. Einer eventuellen Zusammenführung von
Xanadu und World Wide Web steht Nelson kritisch gegenüber:
"The World Wide Web was not what we were working toward, it was what we
were trying to 'prevent'. The Web displaced our principled model with some-
thing far more raw, chaotic and short-sighted. Its one-way breaking links glo-
rified and fetishized as 'websites' those very hierarchical directories from
Hypertext - Geschichte und gegenwärtige Systeme 15
which we sought to free users, and discarded the ideas of stable publishing,
annotation, two-way connection and trackable change." [Nelson99]
2.2.3 Hypertext im Zeitalter des Personal Computers
In den siebziger Jahren beschäftigten sich nur sehr wenige Arbeiten mit Hypertext. Erwäh-
nenswert sind das auf Andries van Dams zurückgehende Projekt FRESS (File Retrieval and
Editing), ein im Lehrbetrieb eingesetztes Hypertextsystem, mit dem Studenten in einer verteil-
ten Umgebung Texte am Bildschirm studieren und mit Kommentaren versehen konnten. Die
Bedienung war allerdings relativ umständlich und ausschließlich textbasiert. Ein Prototyp von
FRESS wurde später an die NASA verkauft, und dort tatsächlich für die Dokumentation der
Apollo-Raumfahrtmissionen eingesetzt.
ZOG war ein Hypertext-System, in dem erstmals Menüs eingesetzt wurden, um Links mit
schneller Antwortzeit zu verfolgen und weitere Dokumente abzurufen. 1980 wurde es an Bord
eines amerikanischen Flugzeugträgers auf 28 Workstations installiert, wo es zu Dokumentati-
onszwecken, als Wartungshandbuch und als Schnittstelle zu einem Expertensystem für die
Einsatzplanung von Flugzeugen verwendet wurde.
Das Jahr 1987 bedeutete den Durchbruch von Hypertext in Wissenschaft und Forschung. Jeff
Conklin veröffentlichte den Artikel "Hypertext: An Introduction and Survey" [Conklin87]. Er
gab darin einen Überblick über alle wesentlichen, bis dahin in der Forschung entstandenen
Systeme, und wies auch auf Probleme beim Hypertext-Einsatz hin. Conklin prägte auch den
Term des "Getting lost in hyperspace" - so bezeichnete er das Problem der Desorientierung
beim Navigieren durch den Hypertext, und identifizierte damit den kognitiven Mehraufwand
der entsteht, wenn verschiedene Aufgaben bzw. Wege durch den Hypertext gleichzeitig zu
bewältigen sind. [Richartz95]
Hypertext - Geschichte und gegenwärtige Systeme 16
Ein weiterer wichtiger Meilenstein war eine erstmals im November 1987 auf Initiative der
ACM (Association for Computing Machinery) an der Universität von North Carolina abgehal-
tene Konferenz namens "Hypertext ’87". Diese sollte alle wesentlichen Forschungsanstren-
gungen in diesem Bereich zusammenführen, und aus den Kleinprojekten einiger Forscher und
Utopisten ein weitverbreitetes populäres Thema machen. Praktisch alle namhaften Wissen-
schafter dieses Gebiets waren anwesend, die Hälfte aller potentiell interessierten Teilnehmer
mußte aus Platzmangel abgewiesen werden. Diese Hypertext-Konferenz findet seither alle
zwei Jahre statt. [Nielsen95]
2.2.3.1 HyperCard
Das erste wirklich populäre Hypertext-System ist das auf Bill Atkinson zurückgehende Hy-
perCard. HyperCard wurde 1987 von Apple für seine Macintosh-Rechner vorgestellt und kos-
tenlos mit den Rechnern ausgeliefert. Dies war vermutlich auch der entscheidende Grund für
dessen hohe Popularität. Ein simples Benutzerinterface gestattete es, auf relativ einfache Wei-
se multimediale Präsentationen zu gestalten. Die Informationen wurden als Stapel von elekt-
ronischen Karten organisiert. Das System enthielt eine einfach zu erlernende, nicht allzu kom-
plexe Programmiersprache (Hypertalk), die es zu einem universellen System machte. Es man-
gelte allerdings an ausgereiften Strukturierungswerkzeugen zur Unterstützung der Hypertext-
Autoren, so daß sich HyperCard kaum für komplexe Anwendungen anbot, sondern eher für
kleine Informationssysteme, zum Prototyping und Experimentieren [Weinreich97].
Hypertext - Geschichte und gegenwärtige Systeme 17
2.2.3.2 NoteCards
NoteCards wurde am XEROX Palo Alto Research Center entwickelt, und auf einem Xerox
Lisp-System realisiert. Ziel war es, Autoren und Wissenschafter dabei zu unterstützen, zu-
nächst unstrukturierte Gedanken und Ideen zu ordnen. NoteCards besteht aus den Komponen-
ten NoteCards, Links, Browser und Fileboxes.
Eine NoteCard ist das elektronische Pendant einer Karteikarte, und mit ähnlichen Einschrän-
kung behaftet: ihr Inhalt wird durch die Größe ihrer Bildschirmdarstellung begrenzt.
Quell- und Zielkarten werden über unidirektionale Links miteinander verbunden. Links sind
an der Quellkarte durch ein Symbol gekennzeichnet, durch das Anklicken wird die Zielkarte
auf den Bildschirm gebracht. Benutzer können Links mit einem Etikett versehen, das den Typ
des Links zeigt.
Browser bieten eine graphische Darstellung eines NoteCard-Netzes durch Knoten und Kanten
an, und können für die Navigation verwendet werden. Die Diagramme werden automatisch
durch das System erstellt. Fileboxes sind selbst wiederum NoteCards, die der Organisation
von Kartenkollektionen dienen. Auch eine einfache Suchmöglichkeit nach Karteninhalten ist
vorgesehen.
NoteCards ist voll in die XEROX Lisp Programmierumgebung eingebettet, und verfügt damit
über eine umfangreiche Funktionsschnittstelle. Dieser ermöglicht die Erstellung neuer Karten-
typen, die Manipulation von Hypertext-Netzen und die Integration anderer Lisp-Programme.
Hypertext - Geschichte und gegenwärtige Systeme 18
2.2.3.3 Intermedia
Intermedia wurde zwischen 1984 und 1992 an der Brown University entwickelt, und stellt
eines der umfassendsten Projekte der frühen Hypertext-Phase der achtziger Jahre dar. Es ori-
entiert sich an der damaligen Software-Architektur der Macintosh-Computer, ist objektorien-
tiert aufgebaut und trennt strikt zwischen Struktur und Inhalten.
Inhalte werden als Dokumente im Dateisystem des zugrundeliegenden Betriebssystems abge-
legt. Da Intermedia als Hypermedia-System konzipiert ist, können Texte, Zeichnungen, Bil-
dern, Zeitachsen und 3D-Modelle als Knoteninhalte erstellt werden.
Die Navigation wird durch eine graphische Darstellung der Hypertext-Netze (sogenannte
Web-Views) vereinfacht. Verweisstrukturen befinden sich in eigenen Web-Dokumenten, und
werden graphisch visualisiert und manipuliert. Auf diese Weise können persönliche und ge-
meinsam genutzte Netze erstellt werden. Eine Erweiterung von Intermedia erlaubte die Ver-
wendung von Templates zur Unterstützung der Hypertext-Konstruktion. Templates sind Teil-
netze eines Hypertextes, von denen durch Kopieren Instanzen erzeugt werden.
Intermedia sieht ein Hypertext-Austauschformat vor, das von den Inhalten des Hypertexts
abstrahiert, und ausschließlich auf den Austausch der Verweisstrukturen ausgerichtet ist. Für
den Austausch von Dokumenteninhalten wurde auf existierende Standards zurückgegriffen.
Hypertext - Geschichte und gegenwärtige Systeme 19
2.2.3.4 Dexter Hypertext-Referenzmodell
Das Dexter Hypertext-Referenzmodell ist das Ergebnis mehrerer von der Dexter-Gruppe or-
ganisierter Workshops, und stellt eine umfassende Referenzarchitektur für Hypertexte dar. Es
basiert auf einer Drei-Schichten-Architektur:
• Runtime Layer: Darstellung des Hypertexts, Benutzerinteraktion, Dynamik
• Storage Layer: Datenbasis für ein Netz von Knoten und Links
• Within-Component Layer: Inhalt bzw. Struktur eines Knotens
Auf der Ebene des Storage Layers sind die Knoteninhalte opak. Ihre innere Struktur offenbart
sich erst im Within-Component Layer. Als Schnittstelle dieser beiden Schichten dient das
sogenannte Anchoring. Es ermöglicht über indirekte Adressierung, daß Verweise innerhalb
von Knoten entspringen und Ziele innerhalb von Knoten haben können, ohne daß im Storage
Layer Information über die Struktur der Knoteninhalte vorhanden sein muß.
Ein zweiter wichtiger Aspekt ist ein Hypertext-Datenmodell. Es benennt atomare Komponen-
ten, Links und zusammengesetzte Komponenten als fundamentale Objekte. Das Modell trennt
klar zwischen dem Inhalt der Knoten und der Bildung des Hypertext-Netzes aus diesen Kno-
ten.
Diese Trennung ist Voraussetzung für die Offenheit des Modells. Offenheit bedeutet hier die
Möglichkeit, das System um neue Typen von Knoteninhalten zu erweitern. Wie Intermedia
macht auch das Dexter-Modell bewußt keine Vorgaben für die Darstellung der Knoteninhalte.
[HS94]
Hypertext - Geschichte und gegenwärtige Systeme 20
2.2.3.5 Digital LinkWorks
Digital LinkWorks ist eine konkrete Umsetzung des Dexter-Referenzmodells. Die Trennung
von Struktur und Inhalt wird gewährleistet, indem ein Strukturdienst quasi auf Ebene des Be-
triebssystems agiert, und von Applikationen in Anspruch genommen werden kann. Über eine
offene Programmier-Schnittstelle können bereits existierende, weitverbreitete Applikationen
integriert, und damit der Bedarf an speziellen Editoren für Inhaltsdokumente abgedeckt wer-
den. Die Applikation hinterlegt bei LinkWorks die Identität von Dokumenten sowie den An-
ker innerhalb des Dokuments als Surrogat, und kann so Dokument und Anker bei Bedarf spä-
ter wiederfinden. LinkWorks selbst speichert nur die Links, von denen der Benutzer beliebig
viele erzeugen kann. Linkdokumente lassen sich zu einer gemeinsamen Sicht überlagern.
Wenn der Benutzer einen Link verfolgt, der zu einem Dokument führt, dessen zugehörige
Applikation noch nicht gestartet ist, so startet LinkWorks diese. Über eine Ereignisnachricht
erhält die Anwendung den Befehl zur Darstellung des entsprechenden Dokuments, wobei ge-
gebenenfalls auf den Zielanker positioniert wird. [Richartz95]
2.2.3.6 World Wide Web
Tim Berners-Lee arbeitete 1980 als Consultant am europäischen Teilchenphysik Zentrum
CERN in Genf. In seiner täglichen Arbeit frustrierte ihn der Umstand, daß sein Terminkalen-
der, sein Telefonbuch und seine Dokumente in unterschiedlichen Datenbasen abgelegt waren,
was einen simultanen Zugriff unmöglich machte. Heute erinnert er sich: "I wanted a program
that could store random associations between arbitrary pieces of information" [Feizabadi96].
Sein erster Lösungsansatz war ein Programm namens "Enquire", das aber bald wieder in Ver-
gessenheit geriet.
Berners-Lee verließ in der Zwischenzeit das CERN, arbeitete im Bereich des Networking und
lieferte Beiträge zu RPC-Systemen (Remote Procedure Call). 1984 wurden am CERN TCP/IP
und das Internet eingeführt. Anfang 1989 kehrte Berners-Lee an das CERN (das mittlerweile
über die größte Internet Site in Europa verfügt) zurück. Die dortige Computerkultur war gera-
Hypertext - Geschichte und gegenwärtige Systeme 21
de im Umbruch begriffen und wurde nunmehr durch neue verteilte, objektorientierte Soft-
wareparadigmen wie jene von NeXT Software, und durch den Einsatz weiterentwickelter
UNIX Umgebungen geprägt.
Berners-Lee verfaßte einen Artikel unter dem Titel "Information Management: A Proposal".
Darin führt er die Nachteile der existierenden hierarchischen Informationssysteme an, und
schlägt als Alternative ein verteiltes, hypertext-basiertes System vor:
"[...] a single user-interface to many large classes of stored information such
as reports, notes, data-bases, computer documentation and on-line systems
help [...]" [Berners89]
Und weiter:
"Let us see what components a hypertext system at CERN must have. The only
way in which sufficient flexibility can be incorporated is to separate the infor-
mation storage software from the information display software, with a well-
defined interface between them. Given the requirement for network access, it is
natural to let this clean interface coincide with the physical division between
the user and the remote database machine." [Berners89]
Hypertext - Geschichte und gegenwärtige Systeme 22
Hypertext Server
Dummy hypertext server makes existing database look like hypertext to the browser
Generic browser
Abbildung 4: Hypertext-Browser, Hypertext-Server und Hypertext-Gateway [Berners89]
Berners-Lee's Vorschlag enthält folgende Komponenten:
• Ein einfaches Protokoll für den Netzwerk-Zugriff auf für den Menschen lesbare Informa-
tionen in verteilten Systemen.
• Ein Protokoll für den automatischen Datenaustausch zwischen Informationsanbieter und -
konsument.
• Anzeigefunktionen für Text und Graphik unter Verwendung der diesbezüglich bereits am
CERN existierenden Technologien.
• Erstellung und Wartung von Dokumentensammlungen, in welche die Benutzer selbst Do-
kumente ablegen können.
Hypertext - Geschichte und gegenwärtige Systeme 23
• Verknüpfung von Dokumenten oder Dokumentensammlungen durch vom Benutzer er-
stellte Hyperlinks.
• Eine Option, welche die Suche von Inhalten nach Schlüsselworten ermöglicht, und über
Hyperlinks erreichbar ist.
• Den Einsatz von frei verfügbarer Software wo immer möglich, Bereitstellung von Schnitt-
stellen zu existierenden, proprietären Systemen.
• Die kostenlose Bereitstellung der benötigten Programme.
"As it happened many times in the history of science, the most impressive re-
sults of the super-large scale scientific efforts were far from the main direc-
tions of these efforts. I hope you agree that Web was a side effect of the CERN's
scientific agenda. After World War 2, the nuclear centers of [...] developed
countries around the world became the places with highest rate of the concen-
tration of talented people per square of Labs. Some of the most talented per-
sons among the national scientists usually were invited to the international
CERN's Laboratories. The specific kind of the CERN's intellectual 'entire cul-
ture' was constantly growing from one generation of the scientists and engi-
neers to another during about four decades." [Feizabadi96]
1990 wurde der Vorschlag Berners-Lees unter dem Projekttitel "World Wide Web" umge-
setzt. Die ersten WWW-Server und ein Browser wurden unter Verwendung von NeXTSTEP
implementiert. Der Browser erlaubte neben der Anzeige auch WYSIWYG-Editierung von
Hypertexten. Als Kommunikationsprotokoll zwischen Client und Server wurde das Hypertext
Transport Protocol (HTTP) eingesetzt, Hyper Text Markup Language (HTML) und Universal
Resource Locator (URL) dienten der Erstellung von Web-Dokumenten. Die Software wurde
1991 auf andere Plattformen portiert und schließlich für die Öffentlichkeit freigegeben.
Marc Andreesen war zu dieser Zeit am National Center for Supercomputing Applications
(NCSA) der University of Illinois beschäftigt. Er leitete eine kleine Gruppe von Diplomanden,
Hypertext - Geschichte und gegenwärtige Systeme 24
die im Februar 1993 eine Alpha-Version ihrer Weiterentwicklung des CERN Browsers veröf-
fentlichten: "Mosaic for X". Im August desselben Jahres folgten frei erhältliche Versionen von
Mosaic für Windows und Apple Macintosh. Zum ersten Mal in der Geschichte des World
Wide Web existierte ein Webclient mit einem konsistenten und einfach zu handhabenden
"Point-And-Click" Benutzerinterface für die drei häufigsten Betriebssysteme. Im Herbst 1993
machte der WWW Netzwerkverkehr dennoch erst etwa 1% des Gesamtverkehrs auf dem NSF
(Nation Science Foundation) Backbone aus.
Andreesen plante ursprünglich keine Weiterentwicklung von Mosaic. Anfang 1994 initiierte
er dann aber gemeinsam mit Eric Bina und dem Gründer von SGI, Jim Clark, die "Mosaic
Communications Corporation", die heute als Netscape bekannt ist.
Dem World Wide Web liegt die Idee eines Universum von Dokumenten zugrunde, wobei
jedes Dokument über einen Universal Resource Locator eindeutig referenzierbar ist. Dieser
Mechanismus baut auf den Namensdiensten des Internet auf.
HTML basiert auf den Konzepten von SGML (Standard Generalized Markup Language), ist
aber stark vereinfacht. Verschiedene Arten von Klienten, meist graphische Browser wie Inter-
net Explorer oder Netscape, lösen URI-Adressen auf und fordern HTML-Dokumente und dar-
in eingebundene Objekte von HTTP-Servern an. HTML-Dokumente enthalten eingebettete
Links in Form von weiteren URIs, die vom Benutzer angewählt werden können.
Dieses Konzept nimmt große Einschränkungen zugunsten eines weltweiten, einfach zu erwei-
ternden Dokumenten-Universums in Kauf. So gibt es keinen Mechanismus zur Konsistenzer-
haltung. Die Folge sind Links, deren Ziel einfach nicht mehr existiert. Links sind keine eigen-
ständigen Objekte, sondern lediglich in Form von Ankern in das Quell-Dokument eingebettet.
Die Zurückverfolgung von Links vom Ziel zu Quelle ist demzufolge nicht möglich. Ebenso-
wenig können Teilnetze manipuliert oder graphisch dargestellt werden.
Hypertext - Geschichte und gegenwärtige Systeme 25
Als einzige Navigationshilfe machen die WWW-Klienten Links auf Dokumente, die bereits
einmal gesehen wurden, kenntlich - allerdings unabhängig davon, ob sie zwischenzeitlich ge-
ändert wurden. Außerdem wird eine einfache Navigationshistorie mitgeführt. Ein weiteres
Problem ist die unbekannte Kommunikationsbandbreite. Der Benutzer kann von einem Link
aus oft nicht erkennen, was mit der Selektion des Links ausgelöst wird. Ein Verweis von ei-
nem lokalen Dokument kann durchaus das Laden mehrerer Megabyte von Informationen von
der anderen Seite des Erdballs auslösen. [Richartz95]
2.2.3.7 Hyper-G / HyperWave
Hyper-G / HyperWave wurde in der ersten Hälfte der neunziger Jahre am Institut für Informa-
tionsverarbeitung und computergestützte Medien (IICM) der Technischen Universität Graz
entwickelt. 1996 wurde Hyper-G in HyperWave umgetauft, und wird seither auch kommer-
ziell angeboten.
Der Entwurf von Hyper-G verlief weitgehend parallel und unabhängig vom World Wide Web,
wobei aber zweifellos einige Konzepte verschiedener Internet-Dienste miteingeflossen sind.
Hyper-G ist verteiltes, mehrbenutzerfähiges Client/Server System. Dabei kommt ein eigenes,
verbindungsorientiertes Protokoll zum Einsatz.
Hyper-G Dokumente werden in Form einer SGML-Variante namens Hyper-G Text Format
(HTF) kodiert, und in hierarchischen Kollektionshierarchien (Dokumentensammlungen) ge-
speichert. Links werden in einer eigenen Datenbasis abgelegt. Sie sind von beiden Seiten aus
sichtbar und traversierbar, können graphisch veranschaulicht und auf Konsistenz geprüft wer-
den. Darüber hinaus ist eine Suche über Attribute und Inhalt von Dokumenten vorgesehen.
Hyper-G Server ermöglichen den Zugriff auf Dokumente und Links, und stehen untereinander
in Verbindung. Jeder Server besitzt ein HTTP-Gateway, so daß auch mit WWW-Browsern auf
die Informationen eines Hyper-G Servers zugegriffen werden kann. Dabei gehen aber einige
Hypertext - Geschichte und gegenwärtige Systeme 26
Orientierungs- und Navigationshilfen verloren, die in den systemeigenen Clients angeboten
werden.
Der am weitesten entwickelte Client für HyperWave heißt "Harmony" und ist für verschiede-
ne Unix-Plattformen erhältlich. Der Client für Microsoft Windows wird "Amadeus" genannt
und bietet im Vergleich zu Harmony etwas eingeschränkte Navigations- und Orientierungshil-
fen. Ein Herzstück von Harmony ist der sogenannte Session Manager, der die augenblickliche
Position in der Kollektionshierarchie anzeigt. Eine Besonderheit ist die Unterstützung von
dreidimensionalen Szenen als Hyper-G Dokumente, in denen der Benutzer navigieren und
Dokumente auswählen kann.
Harmony wird durch verschiedene Anzeige-Programme ergänzt. Das am häufigsten benutzte
ist der Hypertext-Viewer, der auch HTML-Dokumente anzeigen kann. Dazu kommen Postsc-
ript-Viewer, MPEG- und Audio-Decoder, usw.
Gegenüber dem World Wide Web läßt sich Hyper-G wie folgt abgrenzen [Weinreich97]:
• Sitzungen sind verbindungsorientiert. Benutzer können sich anmelden, und verfügen über
eine persönliche Konfiguration.
• Es werden zu jedem Zeitpunkt Hilfestellungen zur Orientierung und zur Navigation durch
das Informationsangebot angeboten.
• Inhalte können nur in strukturierter Form und unter Verwendung der Hyper-G Clients in
einen Server eingebracht werden.
• Alle Dokumente werden in einer objektorientierten Datenbank erfaßt und dabei gleich
voll-textindiziert.
• Links bestehen als unabhängige Einträge in einer eigenen Datenbank und sind bidirektio-
nal.
Hypertext - Geschichte und gegenwärtige Systeme 27
• Links sind nicht an einen Objekttyp gebunden, sondern können von allen Dokumenttypen
ausgehen, also auch von Tondokumenten, Bildern, Videos und 3D-Szenen.
• Das System unterstützt Mehrsprachigkeit. Benutzer können eine bevorzugte Sprache wäh-
len.
• Es existiert ein hierarchisches Benutzer- und Gruppenkonzept, wodurch ein granuliertes
Zugriffsrecht-System ermöglich wird.
• Die Netzbelastung durch Verwendung von Caches reduziert.
Hyper-G war von den Entwicklern als das Internet-Informationssystem der zweiten Generati-
on gedacht. Trotz der zahlreichen Vorteile konnte es sich jedoch nicht durchsetzen - bis heute
gibt es weltweit nur einige hundert Server.
2.2.3.8 Aktuelle Technologien und Werkzeuge
Heute existiert eine Vielzahl von Authoring-Systemen, welche die Erstellung professioneller
WWW-Seiten vereinfachen. Traditionellerweise sind diese Werkzeuge entweder für Power-
User gedacht und ermöglichen die komfortable Kodierung und Prüfung von HTML, oder aber
es wird eine bequeme WSYIWYG-Benutzerschnittstelle ("What you see is what you get")
angeboten, sodaß keinerlei HTML-Kenntnisse erforderlich sind. In letzter Zeit ist zu beobach-
ten, daß diese beiden konträren Ansätze wieder vermehrt zusammenwachsen, indem etwa
zwischen WSYIWYG- und reiner Code-Ansicht hin- und hergeschaltet werden kann. Die De-
signarbeit kann außerdem durch die Verwendung von übergeordneten Layouts, vorgefertigten
Komponenten für Navigation oder für Messageboards, und die Integration von externen Da-
tenquellen vereinfacht werden.
Moderne Webauthoring-Programme benötigen aber auch zahlreiche Funktionen, die über das
Erstellen und Modifizieren einzelner Seiten hinausgehen. Selbst für wenig komplexe Hyper-
text-Strukturen ist eine effiziente Site-Verwaltung und die werkzeugunterstützte Aktualisie-
Hypertext - Geschichte und gegenwärtige Systeme 28
rung von Inhalten und Links ein Muß. Oft wird auch ein automatischer Abgleich mit dem
Web-Server angeboten.
Zu den meistverwendeten Tools zählen Macromedia Dreamweaver (intuitiver graphischer
Designer, Unterstützung vieler Standards, Kompatibilität zu allen wichtigen Web-Browsern,
Datenaustausch mit anderen Macromedia Produkten), NetObjects Fusion (integriertes Site-
Management, Link-Prüfung, konsistente Visualisierung, automatische Erstellung von Naviga-
tions-Leisten) und Microsoft Frontpage (einfache Handhabung, Wizards und Vorlagen, In-
tegration mit Microsoft Office).
Der Arbeitsaufwand für die Entwicklung, aber vor allem auch die Pflege von WWW-Seiten,
ist beim Einsatz klassischer Web-Publishing Werkzeuge dennoch beträchtlich. Die dynami-
sche Erstellung von Hypertexten - etwa über eine Datenbankanbindung - war ein erster Ansatz
zur Entkopplung von Daten und deren Darstellung. Content Management Systeme beruhen
auf einem ähnlichen Prinzip, gehen aber noch darüber hinaus. Sie ermöglichen die Abdeckung
des gesamten Entwicklung- und Wartungsprozesses, inklusive Versionierung, Link-
Management, Internationalisierung, Einhaltung von Corporate Identity und Abbildung des
Publishing-Workflows.
Innerhalb von Content Management Systemen werden Vorlagen und Inhalte (Texte, Bilder
und andere Bestandteile) separat in einer Datenbank abgelegt. Der Ablauf der Seitenerstellung
wird durch ein Rollenkonzept und ein Berechtigungssystem unterstützt, wodurch die ver-
schiedenen Mitarbeiter konfliktfrei in Teilbereichen (Layout, Sitestruktur oder an einzelnen
Dokumenten) arbeiten können. Weitere wichtige Merkmale sind Importfähigkeiten, die Er-
weiterbarkeit mittels Skriptsprachen und Modulen, Personalisierung vom Webinhalten, XML-
Fähigkeiten, Content Syndication (der Austausch von Inhalten zwischen Websites) und Re-
portingfunktionen.
Besonders interessant ist Content-Syndication für Websites, die ihr Angebot mit unterneh-
mensrelevanten Informationen aufwerten wollen, beispielsweise mit Branchen-News, Börsen-
Hypertext - Geschichte und gegenwärtige Systeme 29
kursen oder aktuellen Nachrichten, oder die bestimmte Inhalte von anderen Sites automatisch
beziehen. Grundlage dafür ist das sogenannte Information and Content Exchange Protokoll
(ICE). Dieses bidirektionale Protokoll versendet zur Übertragungssteuerung XML-basierte
Nachrichten zwischen den beteiligten Systemen. ICE ist formatunabhängig, das heißt, es kön-
nen Texte, Bilder oder andere Binärdaten übertragen werden. ICE wird voraussichtlich auch
als Standard durch das W3C (WWW Konsortium) ratifiziert. [Eike00]
Bekannte Content Management Produkte sind Vignette Storyserver (Highend-Lösung),
Gauss VIP (Integration externer Datenbanksysteme, Verwendung von professionellen Web-
Editoren) und Network Productivity System (Design-Vorlagen, Datenbankanbindung über
Common Gateway Interface, Verwaltung und Bedienung via Web-Browser). [Zschau01]
2.2.3.9 Schlußfolgerungen
Während bei den Ansätzen von HyperCard, NoteCards und Intermedia Knoteninhalte in ei-
nem bestimmten Format vorliegen müssen, wird in den Konzepten von Dexter und Link-
Works von den Datentypen der Knoteninhalten abstrahiert - somit kann jede nur denkbare
Applikation angebunden werden. Diese Hypertextsysteme befassen sich vorrangig mit der
Repräsentation der Hypertextstruktur, wobei die Bedeutung des Knotens mehr (LinkWorks)
oder weniger (Dexter) weit zurücktritt. Auch werden hier Links konsequent als eigenständige
Objekte im Hypertextsystem behandelt, so daß ihnen Attribute zugeordnet werden können und
sie von beiden Seiten sichtbar sind.
Das World Wide Web macht die Problematik der Link-Sichtbarkeit und Aktualität besonders
deutlich. In verteilten Systemen wird es mit zunehmender Größe immer schwerer möglich,
Links speziell zu verwalten. Im WWW werden Links in Dokumente eingebettet. Daraus resul-
tiert ein weiteres Problem: wird ein Knoten gelöscht, können hängende Links entstehen, die
auf ein nicht existierendes Ziel zeigen.
Hypertext - Geschichte und gegenwärtige Systeme 30
Norman Meyrowitz, der Entwickler von Intermedia, formulierte dies - in Analogie zu Edger
Dijkstras Bemerkungen über unstrukturierte Programmiertechnik - so: "Pure hypertext is like
spaghetti code with GOTOs". Laura de Young ging noch einen Schritt weiter und wählte für
einen Artikel den provokanten Titel "Linking Considered Harmful" [DeYoung90].
Es ist festzustellen, daß viele bestehende Hypertextsysteme vornehmlich für die Entwicklung
informeller (unstrukturierte Daten) bzw. semi-formaler Strukturen geeignet sind. Regelmäßig
wiederkehrende Strukturmuster müssen oftmals manuell erzeugt werden. Dies ist vor allem
bei der Erstellung von umfangreichen Hypertexte problematisch. Zweifellos ist ein strukturier-
tes Vorgehen bei der Erstellung von Hypertexten unabdingbar. [Richartz95]
"Betrachtet man die im praktischen Einsatz befindlichen sog. Autorensysteme,
so fallen hier starke Defizite auf. Die meisten Systeme erlauben zwar das Edi-
tieren der monomedialen Medien [...] sie erlauben die Verwendung von Scrip-
ting-Sprachen oder Icon-basierte Kontrollfluß-Sprachen. Der Hauptar-
beitsaufwand liegt in der Implementierung der Hypermedia-Anwendung, d.h.
der Erzeugung und Synchronisation multimedialer Daten, dem Schreiben von
Scripte, dem Entwurf von Layouts etc. Der Rückgriff auf bestehende Strukturen
wird nicht unterstützt, allenfalls der Rückgriff auf einzelne Elemente früherer
Projekte; insofern fängt jedes Projekt mit einem weißen Blatt Papier an." [Ri-
chartz95]
Das WebStyles Modell 31
3. Das WebStyles Modell
3.1 Überblick
Das WebStyles-Modell erfüllt die Forderung nach verbesserter Benutzerunterstützung bei
Konstruktion von und Navigation in Hypertexten durch:
• Effiziente Erstellung von Hypertext-Dokumenten und -Anwendungen.
• Verbessertes Navigationsverhalten.
• Strukturkonsistenz von Hypertext-Dokumenten durch Typbeschreibungen.
• Trennung von Navigation und Inhalt.
• Wiederverwendbarkeit unabhängiger Hypertext-Typen und der darin enthaltenen Naviga-
tionsstrategien.
Das WebStyles-Modell umfaßt drei wesentliche Bestandteile. Generische Netze, regelbasier-
te Navigationsunterstützung und Prozeduren. Eine konkrete Kollektion dieser drei Kom-
ponenten stellt eine Typdefinition für Hypertext-Anwendungen dar. Ergänzt wird der Ansatz
durch eine Einbettung in ein klassen- oder prototypbasiertes Objektmodell und die Abbildung
auf existierende Hypertext-Architekturen.
Das WebStyles Modell 32
3.2 Benutzerrollen
Drei Benutzerrollen sind für den Einsatz von WebStyles charakteristisch:
Der WebStyles-Autor erstellt Hypertext-Typdefinitionen einschließlich Navigationsregeln
und Prozeduren. Er spezifiziert Attribute und Regeln, und zwar überall dort, wo später bei der
Erstellung der konkreten Hypertext-Anwendung Vererbung stattfindet. Damit legt er den
Grundstein für die Qualität der daraus entstehenden Hypertexte.
Der Hypertext-Autor verfaßt Hypertexte auf Basis einer von ihm ausgewählten Hypertext-
Typdefinition, die sämtliche Struktur- und Inhaltsvorgaben enthält, durch sukzessives Erwei-
tern. Er erzeugt also hauptsächlich Inhalt. In den meisten Szenarien wird diese Rolle von ei-
nem Fachexperten eingenommen.
Der Hypertext-Benutzer konsumiert den entstandenen Hypertext, indem er durch ihn navi-
giert. Im Hintergrund wertet das WebStyles-Laufzeitsystem Navigationsregeln und Prozedu-
ren aus, und aktualisiert das Benutzer-Modell. Die Existenz der WebStyles nimmt der Benut-
zer jedoch nur durch das dynamische Navigationsverhalten des Hypertexts wahr.
3.3 Hypertext-Komponenten
Der WebStyles-Ansatz basiert auf einem formalen Modell, auf dem alle weiteren Elemente
aufbauen. Aus diesem Modell ergeben sich auch die Anforderungen an konkrete Hypertext-
systeme, auf deren Grundlage das WebStyles-Modell realisiert werden kann.
Eine wichtige Eigenschaft von WebStyles ist die Objektorientierung. Hypertext-Objekte re-
flektieren immer Zustand und Verhalten. Die Realisierung kann auf einem prototyp- oder ei-
nem klassenbasierten Objektmodell beruhen.
Das WebStyles Modell 33
3.3.1 Hypertext-Objekt
Das Hypertext-Objekt ist das grundlegende Element von Hypertexten. Es stellt den Basistyp
für alle in Hypertexten enthaltenen Objekte dar. In einem klassenbasierten Modell ist dies eine
abstrakte Klasse, das heißt es können keine Instanzen von Hypertext-Objekten erzeugt, son-
dern nur Unterklassen abgeleitet werden. Ein Hypertext besteht aus den vom Hypertext-
Objekt abgeleiteten Knoten und Links.
Das WebStyles-Modell setzt voraus, daß Hypertext-Objekten eine Menge von Attributen zu-
geordnet werden können. Ein Attribut ist ein Name/Wert-Paar. Als Namen werden Bezeichner
verwendet, wie sie auch in Programmiersprachen üblich sind, als Werte müssen zumindest
Ganzzahlen, Wahrheitswerte, Zeichenketten, Arrays und Referenzen auf Hypertext-Objekte
zulässig sein.
Hypertext-Objekte entsprechen damit den in objektorientierten Systemen üblichen Dictiona-
ries, das heißt der Attributname stellt einen eindeutigen Schlüssel für den zugehörigen Wert
dar. Dieser Umstand kommt auch einer Realisierung mit einem prototyp-basierten Objektmo-
dell entgegen, da die Attribute als "Slots" der Objekte modelliert werden können.
Die von Hypertext-Objekten abgeleiteten Knoten- und Link-Objekte können beliebig viele
zusätzliche Attribute besitzen. Durch bestimmte Attribute wird der anwendungsbezogene Typ
des Hypertext-Objekts definiert. Somit ergibt sich die Möglichkeit, eine Reihe von Typinfor-
mationen anzugeben, welche von der Hypertextanwendung unterschiedlich interpretiert wer-
den.
3.3.2 Hypertext-Knoten
Ein Knoten ist ein Hypertext-Objekt, das durch ein spezielles Inhaltsattribut ausgezeichnet
ist. Da der WebStyles-Ansatz unabhängig von der Art des Inhalts von Knoten anwendbar ist,
Das WebStyles Modell 34
ist auch eine nähere Betrachtung des Wertebereichs für den Knoteninhalt nicht relevant. Es ist
auch unwesentlich, ob der Knoten selbst die Inhaltsinformation enthält oder nur einen Ver-
weis auf eine externe Inhaltsinformation darstellt. Knoten haben außerdem die Eigenschaft,
daß ihnen für die Darstellung des Inhalts ein Präsentationsobjekt zugeordnet werden kann.
Für die Modellierung der Navigation benötigt man die Definition der Adjazenzmengen eines
Knotens. Diese enthalten alle aus- und eingehenden Links eines Knotens, repräsentieren also
die lokale Nachbarschaft eines Knotens.
3.3.3 Aggregat-Knoten
Eine Sonderstellung nimmt der Aggregat-Knoten ein. Er besitzt als Knoteninhalt einen wei-
teren Hypertext. Aggregat-Knoten können auch als Abstraktion oder Generalisierung des ent-
haltenen Hypertextes verstanden werden. Ein Aggregat-Knoten ist also ein spezieller Knoten
mit einem eingebetteten Hypertext und einer Menge von Zugangslinks des eingebetteten Hy-
pertexts, die in weiterer Folge auf ein- und ausgehende Links des Aggregat-Knoten abgebil-
det werden.
3.3.4 Hypertext-Link
Ein Link ist ein spezielles Hypertext-Objekt, das vereinfacht betrachtet genau einen Quell-
knoten mit einem Zielknoten assoziiert. Nach dieser Definition besteht zunächst keine weitere
Beziehung zwischen dem Inhalt des Quell- bzw. Zielknotens, das heißt Links sind lediglich
am Knoten als Ganzes angebracht. Für die meisten Anwendungen reicht dies nicht aus. Es
wird gefordert, daß Links an bestimmten Punkten des Knoteninhalts angebunden werden. Sol-
che Teilmengen sind üblicherweise Selektionen innerhalb des Knoteninhalts. Die Adjazenz-
Knotenmenge eines Links besteht aus den beiden Knoten, die über den Link verbunden sind.
Das WebStyles Modell 35
3.3.5 Hypertext-Anker
Die Anbindung von Links an Knoten wird über Anker realisiert. Ein Anker ist ein Anbin-
dungspunkt, abgebildet als Surrogat der Selektion innerhalb des Inhalts des Knotens. Dieses
Surrogat wird durch die WebStyles-Umgebung nicht interpretiert, sondern nur als transparente
Information gehalten. Bei der Aktivierung des Knotens wird das Surrogat unverändert an die
Inhaltsdomäne der konkreten Anwendung zurückgegeben, so daß diese den Anbindungspunkt
entsprechend identifizieren und darstellen kann.
Ein Anker ist im übrigen kein vollwertiges Hypertext-Objekt im oben angeführten Sinne, das
heißt er kann keine weiteren Attribute besitzen. Durch die Einbeziehung von Ankern ändert
sich die Definition von Links. Links können als spezielle Hypertext-Objekte mit einem Quell-
anker und einem Zielanker betrachtet werden, wobei Quellknoten und Zielknoten des Links
über die Anker identifiziert werden. Ein Link gilt dann als konsistent, wenn Quell- und Ziel-
anker definiert sind. Ein Link, der diese Bedingung nicht erfüllt, wird als hängender Link be-
zeichnet.
Das WebStyles Modell 36
3.4 Generische Netze
Der Verwendung generischer Netze zur Hypertext-Typdefinition ist eine zentrale konzeptio-
nelle Idee des WebStyles-Modells. Ein generisches Netz ist ein Hypertext, der aus einer Men-
ge von generischen Knoten und einer Menge von generischen Links besteht. Diese bestim-
men, welche Knoten und Links in einem gültigen, vom generischen Netz abgeleiteten Hyper-
text vorkommen können, und wie oft.
3.4.1 Generische Knoten
Jeder generische Knoten ist Stellvertreter für einen, mehrere oder keinen Knoten in einem
abgeleiteten Hypertext. Diese Klassifizierung entspricht den anschließend dargestellten obli-
gatorischen Knoten, Sequenzknoten und optionalen Knoten. Die Abbildung verdeutlicht auch
Hypertextfragmente, wie sie von den generischen Knotentypen abgeleitet werden können. Zur
visuellen Unterscheidung der generischen Hypertext-Objekte von den davon abgeleiteten kon-
kreten Knoten und Links werden die generischen Objekte grau dargestellt. Die Raute in einem
Link kennzeichnet ihn als vollständig (Quelle und Ziel sind definiert).
Das WebStyles Modell 37
Generischer Knotentyp Graphische Darstellung Mögliche Ableitungen
Obligatorischer Knoten REQ
Optionaler Knoten OPT
Sequenzknoten SEQ
Abbildung 5: Generische Knotentypen und mögliche Ableitungen
Ein generischer Knoten spezifiziert auch Attribute für alle abgeleiteten Knoten, insbesondere
• Typ und Name
• Vorgabe für den Inhalt (Schablone)
• Regeln für die Navigationsunterstützung im abgeleiteten Hypertext
• Weitere anwendungsspezifische Attribute, die vom WebStyles-Autor festgelegt werden.
Die drei generischen Knotentypen unterscheiden sich durch die jeweils unterschiedliche unte-
re und obere Grenze für die abzuleitenden konkreten Knoten. Es wird jedoch an der für den
Benutzer verständlicheren Bezeichnung von obligatorischem, optionalem und Sequenzknoten
festgehalten.
Das WebStyles Modell 38
Somit ergibt sich für den obligatorischen Knoten als minimale und maximale Anzahl der
Instanzen der Wert eins. Der optionale Knoten, der als konkreter Knoten auftreten kann, hat
als Untergrenze den Wert Null und als Obergrenze den Wert Eins. Beim Sequenzknoten sind
die beiden Werte frei wählbar und entscheiden darüber, ob die Sequenz eventuell ganz ver-
schwindet und wie viele Knoten in der Sequenz maximal vorkommen können.
Die Instantiierung von Sequenzknoten und optionalen Knoten erfordert eine spezielle Behand-
lung. Jeweils ein eingehender und ein ausgehender Link von generischen Sequenzknoten und
optionalen Knoten werden als Sequenzlinks ausgezeichnet (in den Abbildungen durch
schwarze Punkte zwischen Link und Knoten dargestellt). Bei einem möglichen Wegfall des
Knotens im konkreten Hypertext werden die beiden Sequenzlinks durch einen Link ersetzt.
Bei der mehrfachen Instantiierung des Knotens werden Links zu Sequenzen von Links einge-
fügt, so daß jeweils der ausgehende Sequenzlink des vorhergehenden Knotens mit dem einge-
henden Sequenzlink des folgenden Knotens zu einem neuen, gemeinsamen Link zusammen-
geführt wird.
Alle anderen Links, die bei denen solchen Knoten ein- und ausgehen, fallen weg, wenn der
betreffende generische Knoten nicht instantiiert wird. Bei mehrfacher Instantiierung von gene-
rischen Knoten werden die von ihnen ausgehenden Stränge mitdupliziert. Dieses Prinzip wird
in weiterer Folge noch näher erläutert.
Zur Beschreibung hierarchischer bzw. baumförmiger Strukturen sind Aggregatknoten vorge-
sehen, die bei der Ableitung nicht durch einen konkreten Knoten, sondern durch das enthalte-
ne generische Netz ersetzt werden. Zu diesem Zweck wird jeweils ein ein- und ein ausgehen-
der Link des eingebetteten generischen Netzes als Standard-Zugangslink gekennzeichnet, und
mit einem ein- und ausgehenden Link des Aggregatknoten verknüpft. Die Zuordnung der rest-
lichen Links erfolgt über Gleichheit der Namensattribute.
Das WebStyles Modell 39
3.4.2 Generische Links
Analog zu den generischen Knoten stehen generische Links stellvertretend für einen, mehrere
oder keinen Link im abgeleiteten Hypertext. Dies entspricht den Typen des obligatorischen
Links, des sich wiederholenden Links (Fächerlink) und des optionalen Links. Ebenso wie der
generische Knoten legt der generische Link die Attribute für die von ihm abgeleiteten konkre-
ten Links fest, und zwar:
• Typ und Name des abgeleiteten konkreten Links
• Regeln für die Navigationsunterstützung im abgeleiteten Hypertext
• Weitere, anwendungsspezifische Attribute, die vom WebStyles-Autor festgelegt werden
Das WebStyles Modell 40
Die folgende Abbildung veranschaulicht die verschiedenen generischen Linktypen.
Generischer Linktyp Graphische Darstellung Mögliche Ableitungen
Obligatorischer Link
Optionaler Link
Fächerlink
Abbildung 6: Generische Linktypen und mögliche Ableitungen
Auch hier werden die drei generischen Linktypen durch die untere und obere Grenze für die
zu instantiierenden Links definiert.
Das WebStyles Modell 41
Fächerlinks haben zwei wichtige Eigenschaften, die beim obligatorischen bzw. beim optio-
nalen Link fehlen:
• Die Auffächerung der Instanzen erfolgt in der Richtung von der Quelle zum Ziel. Bei einer
mehrfachen Instantiierung haben alle Instanzen den gleichen Knoten als Quelle.
• Durch die mehrfache Instantiierung werden auch die Knoten am Ziel des Fächerlinks wie-
derholt instantiiert. Dieses Verhalten bei der Instantiierung ähnelt jenem des Sequenzkno-
tens. Dies impliziert, daß zusätzliche Links, die am generischen Zielknoten angebracht
sind, bei der Instantiierung auch dupliziert werden.
3.4.3 Stränge
Bei der mehrfachen Instantiierung von Sequenzknoten und Fächerlinks werden bestimmte
Teile des generischen Netzes, welche vom generischen Sequenzknoten bzw. vom Fächerlink
ausgehen, mitdupliziert. Diese mehrfach zu instantiierenden Teilnetze werden als Stränge
bezeichnet. Stränge können auch von optionalen Knoten und Links ausgehen, wo sie bei
Nicht-Instantiierung wegfallen.
Solcherart definierte Stränge erlauben die Konstruktion verschiedener Hypertext-Strukturen
durch generische Netze:
• Sackgassenartige Teilnetze, etwa als Vertiefung der Instanzen eines Sequenzknotens oder
Fächerlinks.
• Links, die von jeder Instanz eines Sequenzknotens zu einem gemeinsamen Ausgangskno-
ten führen.
• Hypertexte, die mehrfach verzweigen und später, jeweils nach mehreren Knoten und Links
in jedem Zweig, wieder an einem oder mehreren gemeinsamen Zielknoten zusammenge-
führt werden.
Das WebStyles Modell 42
Ein spezieller Strang-Algorithmus dient der Ermittlung alle Hypertext-Objekte, die zu dem
Strang gehören, der von einem Sequenzknoten bzw. einem Fächerlink ausgeht. Der Algorith-
mus durchwandert ausgehend von jenen Links, die am Sequenzknoten hängen (mit Ausnahme
der beiden Sequenzlinks), bzw. vom Zielknoten des Fächerlinks, rekursiv alle Teile des gene-
rischen Netzes, die mit dem Sequenzknoten bzw. Fächerlink verbunden sind. Alle so besuch-
ten generischen Hypertext-Objekte sind Teil des Stranges. Abbruchkriterium ist das Erreichen
eines der folgenden Hypertext-Objekte:
• Links, die bei denen das Instantiierungsattribut join mit dem Wert true belegt ist, und die
in Vorwärtsrichtung erreicht werden. Durch diese Join-Links werden Strang-Instanzen
wieder zusammengeführt.
• Fächerlinks, die in Rückwärtsrichtung erreicht werden; auch sie dienen der Zusammenfüh-
rung von Strang-Instanzen.
• Sequenzknoten, die nicht über die Sequenzlinks erreicht werden, werden zu einer Kette
verknüpft, welche die einzelnen Strang-Instanzen miteinander verbindet. Eine derartige
Kette führt gewissermaßen als Querstraße durch die Strang-Instanzen.
Der Strang-Algorithmus markiert in Tiefensuche rekursiv die zum Strang gehörenden Teile
des generischen Netzes. Dabei werden vier Markierungen verwendet:
Markierung Knoten Links Bedeutung
F Fächermarke � Feststellung von Widersprüchen
S Sequenzmarke � Zum Strang gehörig, Sequenz-Instanz ist zu erzeugen
J Zusammenführung � Link führt Strang-Instanzen zusammen
D Duplizierung � � Zum Strang gehörig, Duplikat ist zu erzeugen
Abbildung 7: Markierungen des Strang-Algorithmus
Das WebStyles Modell 43
Der Algorithmus hat die Komplexität O(n), wobei n die Anzahl der Hypertext-Objekte im
generischen Netz bezeichnet. Er terminiert immer, da die Rekursion nur dann aufgerufen
wird, wenn tatsächlich eine Markierung am betreffenden Hypertext-Objekt gesetzt wurde.
Zur Verdeutlichung zeigt die folgende Abbildung die Auswirkung des Instantiierungsattributs
join eines generischen Links, der Teil eines Stranges ist, welcher von einem Sequenzknoten
oder einem Fächerlink ausgeht. Der Wert des Attributs join legt fest, ob mehrere Strang-
Instanzen durch diesen Link wieder zu einem gemeinsamen Zielknoten zusammengeführt
werden, oder nicht.
Generischer Sequenzknoten Mögliche Ableitungen
Ohne Join-Link
SEQ
Mit Join-Link
SEQ
J
Abbildung 8: Mehrfachinstantiierung von Sequenzknoten
Das WebStyles Modell 44
Generischer Fächerlink Mögliche Ableitungen
Ohne Join-Link
Mit Join-Link
J
Abbildung 9: Mehrfachinstantiierung von Fächerlinks
Das Zusammenführen von Strängen über einen Link in umgekehrter Richtung, also vom Ziel
zur Quelle, erfolgt über einen Fächerlink, wie Abbildung 10 zeigt. Der Fächerlink ist also das
Gegenstück zu einem Join-Link.
Das WebStyles Modell 45
Generisches Netz Abgeleitetes Netz
Abbildung 10: Zusammenführung von Strängen über einen Fächerlink
Enthält ein generisches Netz mehrere Sequenzknoten und/oder Fächerlinks, so können sich
die dadurch definierten Stränge überlappen. Dies führt dazu, daß bei der Konstruktion unter-
schiedliche Ergebnisse erzielt werden können, abhängig davon, an welcher Stelle der Hyper-
text-Autor das generische Netz zuerst expandiert.
Mit dem Strang-Algorithmus lassen sich auch noch komplexere Formationen als die eingangs
beschriebenen definieren. Es ist jedoch nicht Sinn dieses Mechanismus, beliebig komplizierte
Konstruktionen zu unterstützen, sondern die Strukturen Vertiefung, Verzweigung und Zu-
sammenführung zu ermöglichen.
Das WebStyles Modell 46
Strang Graphische Darstellung
Generischer Strang
Bseq
A C DJ
Abgeleiteter Strang
Bc1 Cc
Bb1
CaBa1 Ba2
A1 D1
Abbildung 11: Beispiel für eine Strang-Instantiierung
In generischen Netzen können aber auch widersprüchliche Strangdefinitionen enthalten sein.
Die Prüfung auf Widerspruchsfreiheit erfolgt bereits bei der Erstellung des generischen Net-
zes, indem ausgehend von jedem optionalen Knoten, Sequenzknoten, optionalen Link und
Fächerlink der Markierungsalgorithmus aufgerufen wird.
3.4.4 Hypertext-Konstruktion
Unter Ableitung oder Instantiierung eines konkreten Hypertextes versteht man den Vorgang
der Erzeugung eines Hypertextes nach den Vorschriften eines generischen Netzes. Dies ist die
typische Aufgabe des Hypertext-Autors. Dabei sind für die Instantiierung generischer Knoten
Alternativen vorgegeben, über die der Hypertext-Autor entscheidet. Die Alternativen für einen
Knoten können verschiedene Typen von konkreten Knoten, aber auch Aggregat-Knoten sein.
Wenn von einem generischen ein konkretes Hypertext-Objekt abgeleitet wird, wird letzteres
mit einer Reihe von Attributen versehen, die im generischen Hypertext-Objekt definiert sind.
Das WebStyles Modell 47
Die Gruppe dieser Instantiierungsattribute ist eine ausgezeichnete Teilmenge der Attribute des
generischen Hypertext-Objekts. Dazu gehört gegebenenfalls eine Schablone für den Inhalt von
Knoten.
Die Attribute der generischen Hypertext-Objekte lassen sich wie folgt ordnen:
• Instantiierungsattribute, die die Instantiierung der Hypertext-Objekte kontrollieren.
• Navigationsattribute, welche die Navigation im generischen Netz steuern (im Gegensatz
zu den Navigationsregeln für den abgeleiteten Hypertext, welche zu den Instantiierung-
sattributen gehören).
• Konsistenzattribute, die Regeln zur weitergehenden Prüfung der Vollständigkeit des ab-
geleiteten Hypertextes enthalten. Sie werden nach Fertigstellung der Hypertext-
Konstruktion ausgewertet.
Der Ansatz zur Konstruktion von Hypertext-Graphen sollte einfach genug sein, um auch von
Laien verstanden zu werden. Nicht zuletzt deshalb sollten generische Netze aus einigen weni-
gen, dafür etwas größeren Produktionen bestehen, so daß die Hypertext-Autoren einen relativ
großen Teil des zu konstruierenden Hypertextes auf einmal überblicken können. Das Modell
der generischen Netze unterstützt auch intuitive Strukturierungsprinzipien wie Reihung, Ag-
gregation und Auswahl, die so auf die Strukturierung von Hypertexten übertragen werden
können.
Das WebStyles Modell 48
3.5 Navigationsmodell
Die Navigationsunterstützung von WebStyles basiert auf einem einfachen Regelsystem. Ein
Benutzer navigiert in einem Hypertext, wenn er damit ein bestimmtes Ziel verfolgt. Doch
auch ein nicht zielgerichtetes Durchblättern oder Durchstöbern (Browsing) eines Hypertextes,
wird mit Hilfe des WebStyles-Navigationsmodells unterstützt.
Das Navigationssziel kann unterschiedliche Ausprägungen haben:
• Abdecken aller Informationsknoten oder bestimmter Teile davon.
• Auffinden einer bestimmten Information unter vielen.
• Befriedigung eines bestimmten Informationsbedürfnisses (wobei möglicherweise nicht
alle Informationsknoten des Hypertexts konsumiert werden müssen)
Ein Hypertext-Benutzer bewegt sich entlang von Links von Knoten zu Knoten. Dabei befindet
er sich wiederkehrend in verschiedenen Navigationssituation. Unter einer Navigationssituati-
on versteht man einen Zustand, in dem der Benutzer aus der Adjazenz-Linkmenge des Kno-
tens, an dem er sich gerade befindet, einen Link für die Ausübung des nächsten Navigations-
schritts auswählen muß. Ein Benutzer kann sich gleichzeitig in mehreren Navigationssituatio-
nen befinden, wenn das Hypertextsystem zuläßt, daß er mehrere Knoten zur gleichen Zeit ak-
tiviert.
Zu einem Navigationsschritt kommt es, wenn der Benutzer in einer Navigationssituation
einen Link gewählt hat und über diesen den Zielknoten aktiviert. Resultat des Navigations-
schritts ist eine neue Navigationssituation.
Das WebStyles Modell 49
Der durch den Benutzer ausgelöste Navigationsschritt hat zwei mögliche Semantiken:
• Bei der Follow-Semantik wird der Ausgangsknoten der Navigationssituation durch den
Zielknoten des Navigationsschritts ersetzt. Die Verwendung des Ausgangsknotens gilt als
abgeschlossen. Die bisherige Navigationssituation existiert danach nicht mehr.
• Bei der Visit- oder Branch-Semantik bleibt die Aktivierung des Ausgangsknotens erhal-
ten, der neue Knoten wird zusätzlich aktiviert. Es entsteht also eine zusätzliche, neue Na-
vigationssituation. Die Visit-Semantik wird typischerweise bei der Navigation zu Blatt-
knoten eingesetzt, von denen keine weiteren Links ausgehen.
Darüberhinaus kann der Benutzer eine Navigationssituation auch aufgeben, indem er einen
aktivierten Knoten deaktiviert. Navigationsschritte werden von den Benutzern nacheinander
ausgeübt, so daß sich eine geordnete Menge von Links, die der Benutzer zur Navigation ver-
wendet hat, ergibt. Dies führt uns zum Begriff des Navigationspfads, welcher bei der Naviga-
tion des Benutzers entsteht: Der Navigationspfad ist eine geordnete Menge von Links, die ein
Benutzer zur Ausübung von Navigationsschritten benutzt hat. Da sich ein Benutzer in mehre-
ren Navigationssituationen befinden kann, ist durch den Navigationspfad nicht notwendiger-
weise ein Pfad vom Ausgangsknoten der ersten Navigationssituation zum Ausgangsknoten der
letzten Navigationssituation definiert.
Die Navigationsunterstützung des WebStyles-Ansatzes setzt als Entscheidungshilfe an der
Navigationssituation an, also genau dort, wo der Benutzer sich für einen Link für die Ausfüh-
rung des nächsten Navigationsschritts entscheidet. Die Unterstützung erfolgt durch Anwen-
dung von Navigationsregeln, die vom Hypertext-Autor als Teil des Hypertexts spezifiziert
werden. Resultat ist eine Menge von Links, auf die der Benutzer für seinen nächsten Naviga-
tionsschritt zurückgreifen kann.
Das WebStyles Modell 50
Dabei sind zwei Strategien denkbar:
• Strikte Benutzerführung: Die Entscheidung über den nächsten Navigationsschritt wird
durch das Unterstützungssystem übernommen. Dem Benutzer bleibt allenfalls die Wahl
aus einer Menge von empfohlenen Links, die das Unterstützungssystem ermittelt hat.
• Freie, unterstützte Navigation: Dem Benutzer bleibt die Entscheidung über seinen
nächsten Navigationsschritt überlassen, die vom Navigationssystem ermittelten Linkmen-
gen gelten dabei nur als Empfehlungen.
Diese Navigationsunterstützung ist
• dynamisch, wenn sie immer bei Erreichen einer neuen Navigationssituation bzw. bei Ver-
änderung der Voraussetzungen, unter denen sie erfolgt, durchgeführt wird, also zu unter-
schiedlichen Zeitpunkten unterschiedliche Ergebnisse produziert.
• adaptiv, wenn dabei der bisherige Navigationsablauf des individuellen Benutzers mit ein-
bezogen wird.
Jeder Navigationsschritt des Hypertext-Benutzers, insbesondere die Aktivierung von Knoten,
kann eine Änderung des Benutzermodells und damit des Navigations-Kontexts hervorrufen.
Die Navigationsregeln werden jeweils als Attribute der an der Navigationssituation beteiligten
Hypertext-Objekte spezifiziert. Dabei werden gegebenenfalls mehrere Regeln zu einem Attri-
but zusammengefaßt. Die Menge der Regeln in einem Attribut kann aber auch leer sein.
Bei der Klärung der Frage, ob ein Link im Rahmen einer bestimmten Strategie benutzbar sein
soll oder nicht, spielt auch die Richtung eine Rolle, in der er passiert wird. Differierende Na-
vigationsrichtungen drücken unterschiedliche Semantiken aus. Deshalb können zusätzlich zu
den Regeln, die für beide Richtungen gleichermaßen gelten, für jede Richtung jeweils unter-
schiedliche Regeln spezifiziert werden. Bei der Zusammenstellung der aktuellen Regelbasis
Das WebStyles Modell 51
werden also die Vorwärts-Navigationsregeln der ausgehenden Links und die Rückwärts-
Navigationsregeln der eingehenden Links in die Auswertung einbezogen.
Die wichtigsten Aufgaben des im WebStyles-Laufzeitsystem enthaltenen Regelinterpreters
sind:
• Dynamische Zusammenstellung von Anfragen an die Regelbasis unmittelbar vor der Er-
mittlung der für die Navigation möglichen Linkmengen
• Einbeziehung von Objekten und Attributen des Hypertext-Modells bei der Regelauswer-
tung
Der Benutzerkontext spielt in diesem Zusammenhang eine wesentliche Rolle. Er dient dazu,
alle global für einen Benutzer geltenden Informationen abzulegen.
3.6 Prozeduren
Während Regeln die Bedingungen festlegen, unter denen ein Benutzer im Hypertext navigie-
ren kann, definieren Prozeduren Aktionen, die bei der Navigation ausgeführt werden. So kann
etwa die Wissensbasis für die Link-Auswahl, insbesondere das Benutzermodell, aktualisiert
werden.
Navigationsprozeduren werden - wie Navigationsregeln - von WebStyles-Autoren als Be-
standteil generischer Hypertext-Objekte erstellt und bei der Instantiierung auf die konkreten
Hypertext-Objekte übertragen. Hypertext-Autoren haben die Möglichkeit, Prozeduren gege-
benenfalls noch anzupassen. Darüberhinaus sind Teile des WebStyles-Laufzeitsystems durch
Prozeduren realisiert. Da dem WebStyles-Modell ein objektorientiertes Hypertextmodell zu-
grunde liegt, definieren WebStyles-Prozeduren das Verhalten von Hypertext-Objekten. Sie
sind Methoden der Hypertext-Objekte.
Das WebStyles Modell 52
Ein Knoten kann zwei Methoden besitzen, die bei der Navigation aufgerufen werden:
• Die activate()-Methode wird jedes Mal aufgerufen, wenn der Knoten durch Ausführen
eines Navigationsschritts über einen Link aktiviert wird. Die Ausführung erfolgt, bevor
der Knoteninhalt tatsächlich präsentiert wird, das heißt bevor die Anwendung Kontrolle
über den Inhalt erhält.
• Die deactivate()-Methode kommt zur Ausführung, wenn ein Knoten deaktiviert wird,
entweder durch explizite Deaktivierung durch den Benutzer oder durch die implizit ausge-
löste Deaktivierung eines Navigationsschritts mit der Follow-Semantik.
Analog dazu existieren auch Prozeduren für Links:
• Die traverseforward()-Methode wird aufgerufen, wenn ein Link vom Hypertext-Benutzer
zu einem Navigationsschritt in der Richtung von der Quelle zum Ziel betreten wird.
• Die traversebackward()-Methode wird aufgerufen, wenn ein Link vom Hypertext-
Benutzer zu einem Navigationsschritt in umgekehrter Richtung, vom Ziel zur Quelle, ver-
wendet wird.
Ein wichtiges Bestreben des WebStyles-Ansatzes ist es, daß das vorliegende Modell auch auf
Standard-Hypertext-Architekturen abgebildet werden kann. Dem wird unter anderem dadurch
Rechnung getragen, daß die generischen Netze selbst durch Hypertexte dargestellt werden.
Das WebStyles-Modell stützt sich dabei auf die Möglichkeit, Hypertext-Objekte mit einer
beliebigen Anzahl von Attributen auszustatten. Es kommen daher nur solche Hypertextsyste-
me als Basis in Frage, die beliebige Attribute an Knoten und Links zulassen.
Das WebStyles Modell 53
3.7 Zusammenfassung
In diesem Kapitel wurde die formale Definition des WebStyles-Modell beschrieben. Grundle-
gender Bestandteil ist das eingangs erläuterte formale Hypertext-Modell. Zentrale Komponen-
te sind dabei generische Netze, die in der Form spezieller Hypertexte durch die Vorgabe obli-
gatorischer, optionaler und sich wiederholender Knoten und Links Typen von Hypertexten
beschreiben. Bei der Instantiierung der generischen Netze, also der Erzeugung konkreter Hy-
pertexte durch den Autor, werden Instantiierungsattribute der generischen Hypertext-Objekte
als Attribute an die abgeleiteten konkreten Hypertext-Objekte vererbt.
Der zweite Bestandteil des WebStyles-Modells ist die auf einem formalen Navigationsmodell
beruhende Navigationsunterstützung, die den Benutzer durch Link-Auswahlmengen unter-
stützt, welche durch Auswertung von Navigationsregeln ermittelt werden. Die Navigationsre-
geln sind Instantiierungsattribute der Hypertext-Objekte und werden vom WebStyles-Autor
als Attribute der generischen Hypertext-Objekte definiert.
Schließlich kann der WebStyles-Autor Prozeduren als Instantiierungsattribute vorsehen, die
bei der Navigation ausgeführt werden, etwa um das in die Auswertung der Navigationsregeln
einfließende Benutzermodell zu aktualisieren.
Implementierung 54
4. Implementierung
4.1 Wahl von Entwicklungssprache und -umgebung
Die Wahl der Implementierungssprache fiel in diesem Projekt auf Java. Als Vorteile von Java
etwa gegenüber C++ werden oftmals Plattformunabhängigkeit, einfachere Sprachsyntax und
Stabilität genannt. Im Falle des WebStyles-Editors waren diese Kriterien allerdings letztlich
nicht entscheidend. Vielmehr empfahl sich Java vor allem durch seine standardisierten APIs
(Application Programing Interfaces) im Umfeld von Hypertexten. Folgende Standard Java
Bibliotheken fanden Verwendung:
• Java 2D API für die graphische Darstellung von WebStyles-Graphen
• Java Foundation Classes (Swing) für die graphische Benutzeroberfläche und die interak-
tive Erstellung von WebStyles-Graphen
• Java Servlet API für die Referenz-Implementierung der WebStyles-Laufzeitumgebung
• Der HTML-Parser des javax.text.html Packages für die Implementierung des Hyper-
text-Dokumenteditors und die dynamische Modifikation der damit erstellten HTML-
Seiten im Rahmen der WebStyles-Laufzeitumgebung
Ein Schwachpunkt von Java ist das schlechte Laufzeitverhalten, vor allem was Applikationen
mit graphischer Benutzeroberfläche betrifft. Der WebStyles-Editor stellt in dieser Hinsicht
jedoch relativ geringe Anforderungen. Selbst bei Graphen mit hunderten Knoten und Links
(dieser Fall tritt in der Realität kaum auf) ist auf einem heutigen Standard-PC das interaktive
Bearbeiten ohne merkbare Verzögerung möglich.
Die eingesetzte Entwicklungsumgebung war Symantec Visual Cafe 3.0c, da diese IDE (In-
tegrated Development Environment) an der Abteilung für Telekooperation verfügbar war.
Implementierung 55
Visual Cafe enthält einen schnellen und relativ ausgereiften Compiler, die Umgebung ist
leicht zu bedienen und belastet den Entwickler nicht mit unnötigem Overhead. Als Defizite
stellten sich die geringe Stabilität, der mangelhafte GUI (Graphical User Interface)-Editor
und das Fehlen einer integrierten Java Servlet Engine, welche für die Implementierung der
Laufzeitumgebung benötigt wurde, heraus.
4.2 Systemarchitektur
Der WebStyles-Editor besteht aus 138 Klassen, der unkomprimierte Bytecode hat einen Um-
fang von 371kB. Ein graphisches Klassendiagramm inklusive sämtlicher Relationen wäre
unübersichtlich und würde zudem den Rahmen dieser Arbeit sprengen. Aus diesem Grund
beschränkt sich die folgende Darstellung auf die wichtigsten Anwendungsklassen rund um das
WebStyles-Paradigma.
Implementierung 56
model
WebStyles
javax.swing.JComponent
PSView
PSAbstractObject
PSObject
PSGraph
PSComponent
PSNode
PSLink
PSController
PSGraphController
PSComponentController
PSNodeController
PSLinkController
PSNodeView
PSLinkView
PSGraphView
PSComponentView
PSNestedGraphNodeView
PSNestedGraphNode
PSNestedGraphNodeCtrl
model
model
model
model
model
model
model
controller
propertyListener
propertyListener
view
view
view
view
components
componentControllers
links
nodes
Abbildung 12: Klassendiagramm (Ausschnitt)
Implementierung 57
Da der Editor als SDI-Applikation (Single Document Interface) konzipiert wurde, referenziert
die Hauptanwendungsklasse zu jedem Zeitpunkt genau einen PSGraphController, an
dem wiederum ein PSGraphModel und eine PSGraphView hängen. Die PSGraphView
im ContentPane des Fensters dargestellt.
Beim Anlegen (und äquivalent beim Löschen) von Graph-Komponenten wird jeweils ein
Controller, ein Model und eine View instantiiert, und dem Graph-Controller, dem Graph-
Model bzw. der Graph-View hinzugefügt (bzw. entfernt).
Datenpersistenz eines WebStyles-Dokuments kann erreicht werden, indem der PSGraph-
Controller serialisiert wird. Die von dort ausgehende "Referenzwolke" enthält sämtliche
Objekte, die einen Graph definieren.
Diese Systemarchitektur entstand nicht im Zuge eines abgeschlossenen Entwurfsschrittes,
sondern vielmehr iterativ während der ersten Monate der Implementierung. Nachdem die erste
lauffähige Version des Editors lediglich einen Prototyp darstellte, erfüllte diese bei weitem
noch nicht die Anforderungen bezüglich objektorientierter Designqualität. Vor der Umsetzung
der komplexeren Funktionen des WebStyles-Modells wurde der Editor einem eingehenden
Redesign unterzogen, so daß danach eine gute Basis für die weiteren Entwicklungsschritte
vorlag.
Implementierung 58
4.2.1 Java Packages
Die Anwendungskomponenten wurden in folgende Packages untergliedert:
Package Bedeutung
at.ac.uni_linz.tk.webstyles Haupt-Anwendungsklassen wie WebStyles-Graph, Hypertext-Objekte, Applikation
at.ac.uni_linz.tk.webstyles.action Java Swing Action-Klassen (auch: Kommandos) für Menü- und Toolbar-Befehle
at.ac.uni_linz.tk.webstyles.engine Referenzimplementierung der WebStyles-Laufzeitumgebung
at.ac.uni_linz.tk.webstyles.generic API-Schnittstellen für das Einklinken beliebiger Knoteninhalte (auch zur Laufzeit)
at.ac.uni_linz.tk.webstyles.gui Graphische Benutzeroberfläche (Dialoge, Me-nüs, Toolbar, etc.)
at.ac.uni_linz.tk.webstyles.util Utility-Klassen
at.ac.uni_linz.tk.webstyles.xml Basisklassen für den XML-Export von WebSty-les-Graphen
at.ac.uni_linz.tk.webstyles.xml.memory Klassen für den XML-Export einer speziellen Anwendungsdomäne (Generic Game Engine, ebenfalls ein Projekt an der Abteilung für Tele-kooperation)
Abbildung 13: Java-Packages des WebStyles-Editors
Implementierung 59
4.3 Objektorientierte Entwurfsmuster
In objektorientierten Sprachen lassen sich wiederkehrende Muster von Klassen und kommu-
nizierenden Objekten finden, welche spezifische Entwurfsprobleme lösen und objektorientier-
te Architekturen flexibler, eleganter und wiederverwendbar machen. Diese Muster sind kei-
neswegs neu, sondern haben sich großteils über Jahre hinweg in verschiedenen Projekten be-
währt. 25 bewährte Entwurfsmuster wurden erstmals in [GHJV95] eingehend dokumentiert.
Im Zuge der Implementierung des WebStyles-Editors wurde eine Vielzahl dieser und anderer
Entwurfsmuster eingesetzt, zum Teil auch Muster, die der Java-API inhärent sind. Die folgen-
den Ausführungen stellen lediglich einen Auszug der verwendeten Muster dar, und zwar jene,
welche die Gesamtarchitektur des Systems besonders prägen.
4.3.1 Observer
In einem System mit einer großen Menge von interagierenden Objekten ergibt sich häufig das
Problem, daß die Konsistenz zwischen den miteinander in Beziehung stehenden Objekten
aufrechterhalten werden muß, ohne daß die Klassen enger gekoppelt werden als unbedingt
nötig.
So trennen viele Klassenbibliotheken Darstellungsaspekte der Benutzerschnittstelle von den
dahinterliegenden Anwendungsdaten. Klassen, die Daten bzw. Datenrepräsentierung definie-
ren, können somit zusammenarbeiten, oder aber auch unabhängig voneinander verwendet
werden (siehe auch: Model-View-Controller). Über das Observer-Muster kann diese lose
Kopplung etabliert werden.
Implementierung 60
Subject
Attach(Observer)Detach(Observer)Notify()
Observer
Update()
for all o in observers {
o->Update()
}
ConcreteSubject
GetState()SetState()
subjectStatereturn subjectState
ConcreteObserver
Update()
observerState
observerState =
subject->GetState()
subject
Abbildung 14: Das Observer-Entwurfsmuster
Zentrale Komponenten dieses Konzepts sind die Klassen Observable und Observer. Bei ei-
nem Objekt vom Typ Observable kann eine beliebige Anzahl von Observer-Objekten regist-
riert werden. Die Observer werden benachrichtigt, wenn das Observable-Objekt seinen Zu-
stand ändert.
Man erreicht dadurch eine unabhängige Verwendung von Observables und Observern. Das
Observable kennt lediglich eine Liste von Objekten, welche die Observer-Schnittstelle imp-
lementieren, aber keine Details der Implementierung. Benachrichtigungen über Zustandsände-
rungen werden vom Observable an die registrierten Observer verschickt, und es liegt am Ob-
server, eine derartige Nachricht zu ignorieren oder zu bearbeiten.
Das Observer-Konzept wird von Java direkt unterstützt. Im Package java.util existieren
dafür die Klassen Observer und Observable. Die Klasse PSGraphView des WebSty-
les-Editors besitzt einige Observer-Instanzvariablen für Zustandsattribute der Hauptansicht
des bearbeiteten WebStyles-Graphen, z.B. SELECTION_OBSERVABLE, an dem sich Ob-
server registrieren können, die an Selektionsänderungen interessiert sind. Einer dieser Ob-
server ist die Hauptanwendungs-Klasse WebStyles. WebStyles aktualisiert den e-
nabled-Status sämtlicher Action-Instanzen (und somit aller Menü- und Toolbar-Befehle) in
Implementierung 61
Abhängigkeit vom aktuellen Zustand der Anwendung. So können etwa Cut-, Copy- oder De-
lete-Befehle nur dann ausgeführt werden, wenn zumindest ein Objekt des Graphen selektiert
wurde. Eine Wertänderung von SELECTION_OBSERVABLE führt dazu, daß die WebSty-
les-Klasse die aktuelle Selektion von PSGraphView anfordert und Cut-, Copy- oder Dele-
te-Befehl dementsprechend aktiviert oder deaktiviert.
Eine Einschränkung des erläuterten Aktualisierungsprotokolls liegt darin, daß der Observer
nicht wirklich weiß, was sich im Observable-Objekt geändert hat. In obigem Beispiel wird
allein durch die Bezeichnung SELECTION_OBSERVABLE bereits eine Aussage darüber ge-
troffen, daß es sich um die Selektion handelt. Welche Teile des Graphen nunmehr wirklich
selektiert sind, muß aber explizit eruiert werden, welche Teile zuvor selektiert waren, ist nicht
mehr feststellbar (und im gegebenen Fall auch nicht von Interesse).
Das Aktualisierungsprotokoll des Observer-Schemas läßt sich jedoch einfach erweitern. Java
bietet auch dafür Unterstützung. Ein wichtiger Bestandteil der Komponententechnologie Java
Beans sind Properties (Eigenschaften) der Komponenten. Auf Wertänderungen dieser Eigen-
schaften lassen sich Instanzen von Klassen, die das Interface PropertyChangeListener
implementieren, registrieren. Dazu genügt es, eine einzige Methode der Form
public void propertyChange(PropertyChangeEvent evt)
bereitzustellen. Das PropertyChangeEvent gibt nicht nur Auskunft darüber, wo eine Wertmo-
difikation stattgefunden hat, sondern auch, welches Attribut betroffen war, und enthält Infor-
mationen über alten und neuen Wert.
Ein Anwendungsfall dieses Schemas ist eine Änderung des Typs von Hypertext-Objekten in
generischen WebStyles-Graphen. So ist etwa PSNodeView als PropertyChange-
Listener auf die PropertyChangeEvents der Property type von PSNode ange-
meldet. Als Reaktion auf eine Typ-Änderung invalidiert sich die View, was in weiterer Folge
Implementierung 62
zu einer Aktualisierung auf dem Bildschirm führt (obligatorische, optionale und Sequenzkno-
ten unterscheiden sich ja wie erwähnt in ihrer graphischen Darstellung).
Ein potentielles Risiko bei der Anwendung des Observer-Patterns liegt darin, daß bei einer
Aktualisierung des Observables keine Information darüber vorliegt, welche Auswirkungen
dies in Hinblick auf die Laufzeit hat. So können schlecht definierte Abhängigkeiten zu einer
Kaskade von Benachrichtigungen führen. Eine mögliche Umgehung dieses Problems liegt
darin, die Observer-Aufrufe in einen eigenen Thread mit niedriger Priorität auszulagern. Um
Race Conditions (Konkurrenzsituationen aufgrund fehlender Thread-Synchronisation) auszu-
schließen, muß der Thread mit einer Queue ausgestattet werden, in welcher Observer-
Benachrichtigungen in der Reihenfolge ihres Eintreffens abgelegt werden.
Im Rahmen des vorliegenden Projekts hätte diese Vorgehensweise jedoch einen unnötigen
Overhead bedeutet. Durch die Implementierung selbst ist bereits sichergestellt, daß Observer
nur dann benachrichtigt werden, wenn dies wirklich nötig ist, und daß deren Reaktion auf eine
Benachrichtigung in kürzester Zeit abgearbeitet wird (so wird etwa niemals eine View als di-
rekte Reaktion auf eine Wertänderung neu gezeichnet, vielmehr registriert sich die View für
eine Aktualisierung, die durchgeführt wird, sobald der sogenannte Java AWT Event-
DispatchThread in den Leerlauf übergeht, also keine weiteren vom Benutzer ausgelösten
Ereignisse mehr zu behandeln sind).
4.3.2 Singleton
In manchen Situationen ist es wünschenswert, daß es von einer Klasse genau ein Exemplar
gibt. Eine Grundprinzip des Singleton-Musters besteht darin, die Klasse selbst für die Verwal-
tung ihres einzigen Exemplars zuständig zu machen. Intern wird eine Instanz angelegt, auf die
Klienten von außen über eine Exemplaroperation zugreifen können. Indem Befehle zur Er-
zeugung neuer Objekte abgefangen werden, wird sichergestellt, daß kein weiteres Exemplar
erzeugt wird.
Implementierung 63
Diese Vorgehensweise hat mehrere Vorteile. Durch die Kapselung des einzigen Exemplars
der Singleton-Klasse ist eine strikte Zugriffskontrolle gewährleistet, eine Überfrachtung des
Namensraumes mit globalen Variablen zur Speicherung der Singleton-Instanzen wird vermie-
den. Das Konzept ist auf mehrere Exemplare - etwa in Form eines Pooling - erweiterbar.
Auch von einigen Klassen des WebStyles-Editors existiert zur Laufzeit jeweils nur eine In-
stanz. Dies betrifft zum Beispiel die sogenannten Action-Klassen, welche einerseits einge-
setzt werden, um über Implementierung des Interfaces ActionListener auf Mausklicks
auf Buttons oder Menübefehle reagieren zu können, und andererseits, um die Darstellung die-
ser Steuerelemente zu spezifizieren (also welcher Text oder welches Icon angezeigt wird, ob
ein Button ausgegraut erscheint oder nicht, etc.).
Viele Befehle treten jedoch nicht nur in Pulldown-Menüs, sondern auch in einer Toolbar oder
einem Popup-Menü auf. Es ist wünschenswert, nur mit einer Instanz eines Befehls zu arbei-
ten, so daß dieser zum Beispiel nur einmal deaktiviert werden muß, und dennoch überall, wo
er verwendet wird, ausgegraut erscheint. Oft ist es auch notwendig, an mehreren Stellen eben
auf diesen Befehl zuzugreifen, ohne daß eine Referenz darauf gehalten werden muß. Aus die-
sem Grund wurden die Action-Klassen des WebStyles-Editors als Singletons implementiert.
Als Beispiel sei der Sourcecode des Druck-Befehls angeführt.
package at.ac.uni_linz.tk.webstyles.action;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import at.ac.uni_linz.tk.webstyles.*;
public class PrintAction extends AbstractAction {
// Creating a single instance of PrintAction
private static PrintAction action = new PrintAction();
Implementierung 64
// Returning the single instance of PrintAction
public static Action getAction() {
return action;
}
// Private constructor avoids external creation
private PrintAction() {
super("Print", new ImageIcon("images/print.gif"));
setEnabled(false);
}
public void actionPerformed(ActionEvent e) {
PrintJob job =
Toolkit.getDefaultToolkit().getPrintJob(new Frame(),
"WebStyles Graph", null);
if (job != null) {
Graphics graphics = job.getGraphics();
if (graphics != null) {
WebStyles app = WebStyles.getApplication();
app.getGraphView().printAll(graphics);
graphics.dispose();
}
job.end();
}
}
}
Implementierung 65
4.3.3 Model-View-Controller
Das Model-View-Controller Paradigma findet häufig in Frameworks für interaktive Applika-
tionen Verwendung. Es besteht aus drei Grundkomponenten:
• Model: Verwaltung der verarbeiteten Daten.
• View: Anzeige der Daten am Bildschirm.
• Controller: Interpretation von Benutzereingaben.
Control
Update(whatChanged)
HandleMouse(x, y, but)
HandleKey(ch)
View
Update(whatChanged)
subject
Model
Add(observer)Remove(observer)Notify(whatChanged)
model model
for all o in observers {
o->Update(whatChanged)
}
MyControl
Update(whatChanged)HandleMouse(x, y, but)HandleKey(ch)
MyModel
Insert(...)Read(...)...
MyView
Update(whatChanged)Redraw(...)...
Abbildung 15: Das Model-View-Controller Schema [Mössenböck98]
Zu einem Model kann es mehrere Views geben - etwa wenn in einem Texteditor in mehreren
Fenstern Ausschnitte desselben Dokuments angezeigt werden. Ein Hauptzweck des MVC-
Schemas besteht darin, nach einer Änderung des Modells mehrere Views konsistent nachzu-
führen. Zu jeder View gibt es einen Controller, da dieselbe Eingabe in verschiedenen Views
unterschiedliche Auswirkungen haben kann. Der Controller reagiert in der Regel auf externe
Eingaben, indem er das Model verändert. Das Model teilt dies wiederum allen Views und
Controllern mit. Die Views holen sich die aktualisierten Daten aus dem Model und stellen
Implementierung 66
diese dar. In manchen Fällen informiert ein Controller nur die View selbst, etwa wenn der
Inhalt der View gescrollt werden soll. Hier ist keine Model-Änderung nötig. [Mössenböck98]
Dieses Muster basiert auf dem zuvor vorgestellten Observer-Konzept: Controller und Views
melden sich als Beobachter des Models an, und werden über Veränderungen benachrichtigt.
Das MVC-Prinzip wird im Rahmen des WebStyles-Editor intensiv angewendet. Wie dem
Klassendiagramm zu entnehmen ist, existiert für alle Komponenten eines WebStyles-Graphen
eine klare Trennung zwischen Modelldaten und deren Repräsentation. View und Controller
sind als PropertyChangeListener auf verschiedenen Properties ihres Models registriert, und
reagieren bei Model-Änderung entsprechend.
Daß mit einer WebStyles-View mehrere Controller und Models verbunden werden können ist
zwar aus Sicht der Softwarearchitektur sinnvoll, war aber nicht der eigentliche Anlaß für die
Verwendung eines MVC-Schemas, und wird innerhalb des WebStyles-Editors auch nur wenig
genutzt (nicht zuletzt auch deshalb, weil die gegenwärtige Version als SDI-Applikation imp-
lementiert ist und nur eine Ansicht zuläßt). Das System ist aber diesbezüglich so offen ausge-
legt, daß eine Umstellung auf MDI (Multiple Document Interface) nur mit geringem Aufwand
verbunden wäre.
Der Hauptgrund der Trennung in Model, View und Controller im Rahmen dieses Projekts ist
die dadurch entstehende adäquatere Kapselung und Klassenbildung, sowie die Möglichkeit,
Einzelkomponenten einfacher austauschen zu können. So entstand im Zuge der Implementie-
rungsarbeiten die konkrete Teilaufgabe, die View-Komponenten von einem eigenen, proprie-
tären Ansatz zu Swing JComponenten zu portieren. Die klare Loslösung von Model und
View vereinfachte dieses Vorhaben erheblich.
Auch das entstandene Klassendesign entspricht damit der Applikations-Domäne. Hätte man
Model und View in einer Klasse entwickelt, hätte javax.swing.JComponent oder ja-
va.awt.Component als gemeinsame Basisklasse fungieren müssen. Es gibt aber keinen
Implementierung 67
Grund, Implementierungsdetails von Java AWT- oder Swing-Komponenten etwa mit jenen
eines generischen Knotens zu mischen. Die Hypertext-Modelle existieren völlig unabhängig
von deren graphischer Darstellung oder darauf ausgeführten Benutzereingaben, und sind da-
durch projektübergreifend wiederverwendbar.
4.3.4 Memento
Ein Memento dient der Festhaltung des inneren Zustands eines Objekts. Es wird durch einen
Urheber erzeugt, der nach eigenem Gutdünken so viel oder so wenig über seinen eigenen in-
neren Zustand im Memento ablegt, wie im jeweiligen Kontext nötig ist. Gegen den Zugriff
von außen wird das Memento durch eine schmale Schnittstelle geschützt, nur dem Urheber ist
es möglich, auf alle benötigten Daten zurückzugreifen, um sich selbst wieder in seinen vorhe-
rigen Zustand zurückzuversetzen. [GHJV96]
Die klassische Vorgehensweise zur Implementierung eines Undo/Redo-Mechanismus ist die
Verwaltung einer Befehlsgeschichte in Form einer Liste von Befehlsobjekten, welche bei Be-
darf rückgängig gemacht werden können. Bei der Benutzung des WebStyles-Editors fallen
Befehle mit sehr komplexen Ausführungsalgorithmen an, wie etwa das Instantiieren eines
Stranges. Hier werden durch einen einzelnen Befehl eine Vielzahl von Hypertext-
Komponenten hinzugefügt, eventuell auch wieder entfernt und miteinander verknüpft, Views
erzeugt und in der Fensteransicht plaziert. Einen Mechanismus für die schrittweise Rückgän-
gigmachung bereitzustellen hätte einen Aufwand bedeutet, der im Kontext dieser Diplomar-
beit nicht gerechtfertigt gewesen wäre.
Glücklicherweise bietet das Memento hier eine alternative Lösung. Anstelle des Aufzeichnens
von Befehlsfolgen erstellt der WebStyles-Editor Schnappschüsse des aktuellen Dokuments,
und verkettet diese in einer auf maximal zehn Elemente beschränkten Liste. Dies ist deshalb
praktikabel, weil die dafür eingesetzte Java Serialisierung in einen Bytebuffer relativ perfor-
mant vonstatten geht (Laufzeit: ca. 100 bis 200ms), und ein serialisierter WebStyles-Graph
nur etwa 50 bis 100kB belegt. Ein Undo oder Redo führt einfach zur Ersetzung des aktuellen
Implementierung 68
Graphen durch seinen serialisierten Snapshot. Auch beim Hinzufügen zukünftiger Funktiona-
lität genügt somit das Erstellen eines Schnappschusses, um Aktionen rückgängig zu machen.
4.4 Ausgewählte Implementierungsproblemstellungen
4.4.1 Interaktive Bearbeitung des WebStyles-Graphen
Um Benutzeraktionen wie Mausklicks, Mausbewegungen oder Tastatureingaben auf einer
View interpretieren zu können, wird in der Regel eine Controller-Instanz als Observer dieser
Ereignisse registriert. So ist es ein leichtes, bei der Selektion eines Objekts dieses auch optisch
hervorzuheben, oder bei einer Wanderung des Mauscursors über das Element entsprechend zu
reagieren.
Die Sache gestaltet sich schwieriger, wenn zum Beispiel das Ende eines Links durch Ziehen
mit gedrückter Maustaste verschoben, oder aber der Link mit einem Knoten verbunden wer-
den soll. In diesen Fällen ist das Zielobjekt der Benutzereingabe nicht der Link, sondern der
umgebende Container, oder aber die View des angepeilten Knotens. Den Controllern dieser
Elemente müßte bekannt sein, daß eigentlich der Zielpunkt eines Links verschoben wird, um
richtig darauf reagieren zu können - eine unschöne und ungewünschte Verallgemeinerung.
Eine Möglichkeit dieses Problem zu lösen besteht darin, der Haupt-View zunächst einen
transparenten Container hinzuzufügen (im Java Jargon spricht man auch von einem Glass-
Pane), so daß - programmtechnisch betrachtet - alle anderen Komponenten-Views wie Kno-
ten oder Links überdeckt werden. Graphisch wird der Container aber nicht dargestellt. Der
Haupt-Controller empfängt sämtliche Benutzereingaben, die ja nunmehr auf dem transparen-
ten Container entstehen, und weiß diese richtig zu interpretieren, da er über die Haupt-View
die Position und Größe aller Komponenten-Views kennt. Ereignisse, die von den Komponen-
Implementierung 69
ten-Controllern einzelner Knoten oder Links abgehandelt werden können, werden an diese
delegiert.
4.4.2 Vorschau-Ansicht in Dateidialogen
Die Vorab-Anzeige in einem JFileChooser führte zu einer effizienteren Bedienung, da
unnötige Arbeitsschritte entfallen.
Abbildung 16: Dateidialog mit Vorschau-Ansicht
JFileChooser unterstützt das Einpassen eigener Komponenten über die Methode setAc-
cessory(JComponent newAccessory). Hinzugefügt wird zunächst lediglich ein
JScrollPane:
chooser = new JFileChooser();
scroller = new JScrollPane();
scroller.setMaximumSize(new Dimension(200, 200));
scroller.setPreferredSize(new Dimension(200, 200));
chooser.setAccessory(scroller);
Implementierung 70
chooser.addPropertyChangeListener(this);
Eine Änderung der Dateiauswahl führt zur Benachrichtigung von registrierten Property-
ChangeListenern. Handelt es sich um einen gültigen WebStyles-Graph, so wird dieser
geladen und verkleinert dargestellt. WebStyles-Graphen werden in einem kompakten Seriali-
sierungs-Format abgelegt, und können daher auch für eine Voransicht zur Gänze geladen wer-
den. Dieser Code-Ausschnitt zeigt die wichtigsten Details der Implementierung.
public void propertyChange(PropertyChangeEvent evt) {
String prop = evt.getPropertyName();
// a file has been selected, preview needs to be updated
if (prop.equals(JFileChooser.SELECTED_FILE_CHANGED_PROPERTY)) {
updatePreview();
}
}
private void updatePreview() {
// remove old content
scroller.getViewport().removeAll();
if (chooser.getSelectedFile() != null) {
if (!chooser.getSelectedFile().isDirectory()) {
// a file has been selected
try {
// load the graph
PSGraphController ctrl = loadGraphInternal(
chooser.getSelectedFile().getPath());
if (ctrl != null) {
// graph loaded successfully, display it
ctrl.getView().zoom(0.5);
scroller.getViewport().add(ctrl.getView());
ctrl.disconnect();
}
}
Implementierung 71
catch (Exception excpt) {
// error has occured, display it
JTextArea text = new JTextArea(excpt.toString());
text.setLineWrap(true);
scroller.getViewport().add(text);
text.setEnabled(false);
}
}
// force update
scroller.repaint();
}
}
4.4.3 Hypertext-Dokumenteditor
Für die Bestimmung von Knoteninhalten können sowohl externe Referenzen angegeben, als
auch eigene Hypertext-Dokumente erstellt und bearbeitet werden. Diese werden später für die
Laufzeitumgebung im HTML-Format exportiert.
Im Rahmen des Dokumenteditors wird das Swing-Steuerelement JTextPane verwendet,
das attributierte Textdokumente anzeigen und bearbeiten kann. Textdokumente bestehen aus
reinen Textdaten und Attributen, die auf Zeichen- oder Absatzebene definiert werden können.
Sollen HTML-Tags hinzugefügt werden, so werden diese als Zeichen- oder Absatzattribute
auf der aktuellen Textselektion oder Caret-Position (Position der Einfügemarke) des Doku-
ments definiert.
protected JTextPane content = new JTextPane();
protected class FormatAction extends StyledEditorKit.StyledTextAction {
HTML.Tag htmlTag;
public FormatAction(String actionName, HTML.Tag inTag) {
super(actionName);
Implementierung 72
// set the tag connected with this format
htmlTag = inTag;
}
public void actionPerformed(ActionEvent ae) {
// a tag should added or removed
// get current attributes
MutableAttributeSet attrInput =
content.getInputAttributes();
if (attrInput.getAttribute(htmlTag) == null) {
// add tag to attributes
attrInput.addAttribute(htmlTag,
new SimpleAttributeSet());
}
else {
// remove tag from attributes
attrInput.removeAttribute(htmlTag);
}
// update and display content
content.setCharacterAttributes(attrInput, true);
content.setText(content.getText());
}
}
public void actionPerformed(ActionEvent e) {
// [snip]
if (e.getSource() == orderedList) {
// react on user-input: add or remove <ol>-tag
new FormatAction("Ordered List", HTML.Tag.OL).actionPerformed(
new ActionEvent(content, 0, null));
}
// [snip]
}
Implementierung 73
4.4.4 WebStyles-Laufzeitumgebung
Die WebStyles-Laufzeitumgebung ist eine konkrete Umsetzung der regelbasierten Navigati-
onsunterstützung und des Prozeduren-Konzepts wie in Kapitel 3 beschrieben. Die Implemen-
tierung basiert auf Java Servlets. Java Servlets ermöglichen serverseitig die dynamische An-
passung von Web-Inhalten und können in die meisten Web-Server direkt integriert werden.
Die Session Tracking API behebt die Zustandslosigkeit von HTTP und ermöglicht es, die
Navigationssituation und das Benutzer-Modell innerhalb des Session-Kontexts abzulegen.
Da während der Bearbeitung von WebStyles-Graphen im Editor von konkreten Hypertext-
Architekturen abstrahiert wird, werden die Servlets im Zuge eines speziellen Exports gene-
riert. Der Editor erzeugt dabei compilefähigen Java Sourcecode, der vom Entwickler weiter-
gewartet werden kann. Jeder Knoten des WebStyles-Graphen wird zu einem Servlet, das von
der Klasse PSServlet abgeleitet ist. Ein PSServlet ist durch einen WebStyles-Graph,
seine Inhaltsvorlage und durch Navigationsregeln und Prozeduren definiert - all diese Kom-
ponenten werden bereits durch den WebStyles-Editor bereitgestellt. In PSServlet ist so-
wohl die eigentliche Implementierung der WebStyles-Laufzeitumgebung untergebracht, als
auch die im folgenden dokumentierte API-Schnittstelle für alle abgeleiteten Klassen.
public abstract class PSServlet extends HttpServlet {
public PSGraph getGraph(HttpSession session);
public HashSet getVisitedNodes(HttpSession session);
public HashSet getTraversedLinks(HttpSession session);
public boolean hasBeenVisited(HttpSession session,
String nodeName);
public boolean hasBeenTraversed(HttpSession session,
String linkName);
public String getPreviousVisitedNodeName(HttpSession session);
Implementierung 74
public String getLinkName(HttpSession session,
String fromNodeName,
String toNodeName);
protected PSNode getNode(HttpSession session,
String nodeName);
protected PSLink getLink(HttpSession session,
String linkName);
public boolean isLinkEnabled(HttpSession session,
String linkName);
protected boolean isLinkEnabledInternal(HttpSession session,
String linkName);
public Hashtable getProperties(HttpSession session,
String nodeName);
public String getProperty(HttpSession session,
String propertyName);
public String getProperty(HttpSession session,
String nodeName,
String propertyName);
}
Die Default-Implementierung von getParsedContent(HttpSession session) in
PSServlet sorgt dafür, daß über definierte Navigationsregeln Links aus dem HTML-
Quelltext der Inhaltsvorlagen entfernt werden und damit die zur Auswahl stehende Linkmenge
eingeschränkt wird.
Implementierung 75
public String getParsedContent(HttpSession session) {
String content = "";
try {
String template = getTemplate();
// load html template
HTMLEditorKit htmlKit = new HTMLEditorKit();
HTMLDocument doc = new HTMLDocument();
htmlKit.read(new StringReader(template), doc, 0);
// look for all <a>-tags
HTMLDocument.Iterator it = doc.getIterator(HTML.Tag.A);
// iterate over all <a>-tags
while (it.isValid()) {
if (!isLinkEnabled(session, getLinkName(session,
name, it.getAttributes().getAttribute(
HTML.Attribute.HREF).toString()))) {
// the link is disabled - get the attributes
SimpleAttributeSet attr = new SimpleAttributeSet(
doc.getCharacterElement(
it.getStartOffset()).getAttributes());
// remove <a>-tag
attr.removeAttribute(HTML.Tag.A);
doc.setCharacterAttributes(it.getStartOffset(),
it.getEndOffset() - it.getStartOffset() + 1,
attr, true);
}
it.next();
}
// write back the resulting html code
StringWriter writer = new StringWriter();
new HTMLEditorKit().write(writer, doc, 0, doc.getLength() - 1);
content = writer.getBuffer().toString();
}
Implementierung 76
catch (Exception excpt) {
log("Exception in PSServlet.getParsedContent", excpt);
}
return content;
}
Anwendung 77
5. Anwendung
5.1 Graphische Benutzeroberfläche
Die Oberfläche des Editors besteht aus einer Menüleiste, einer andockbaren Symbolleiste,
dem Dokument-Bereich und einer Statuszeile. Zu einem gegebenen Zeitpunkt kann immer nur
ein WebStyles-Graph bearbeitet werden, es sind jedoch mehrere parallele Editor-Sitzungen
möglich.
Abbildung 17: Graphische Benutzeroberfläche des WebStyles-Editors
Anwendung 78
Knoten und Links können beliebig plaziert, verschoben und miteinander verknüpft werden.
Per Klick mit der rechten Maustaste werden kontextabhängige Popup-Menüs geöffnet.
5.1.1 Menü File
Abbildung 18: Das Menü File
Die Befehle des Menüs File setzen sich aus den Standardkommandos zur Neuanlage, zum
Laden, Speichern, Drucken und Beenden, sowie dem Export in den Formaten HTML, Java
Servlet Engine und generischer Content im XML-Format (Extended Markup Language) zu-
sammen. Die zuletzt geöffneten Graphen können auch direkt über History-Einträge aufgerufen
werden.
Anwendung 79
5.1.2 Menü Edit
Abbildung 19: Das Menü Edit
Gemäß allgemein geltender Konventionen enthält das Menü Edit Undo- und Redo-
Funktionen, sowie die Befehle der Zwischenablage.
5.1.3 Menü View
Abbildung 20: Das Menü View
Über das Menü View kann der Benutzer die Ansicht über mehrere Stufen verkleinern oder
vergrößern, und einzelne Graph-Elemente in den Vordergrund oder in den Hintergrund stel-
len.
Anwendung 80
5.1.4 Menü Tools
Abbildung 21: Das Menü Tools
Über die Auswahlgruppe Edit / Node / Link des Menüs Tools wird der aktuelle Editiermodus
festgelegt. Edit dient dem Verschieben und Verbinden von Graph-Elementen. Node und Link
bestimmen, ob Knoten oder Links eingefügt werden sollen. Ist im Node-Modus zudem das
Kontrollkästchen Insert Nested Graph Node angekreuzt, so werden Aggregatknoten einge-
setzt. Der Befehl Expand Nested Graph Node ist nur dann ausführbar, wenn ein Aggregat-
knoten selektiert ist. Die Funktionen Properties, Instantiate bzw. Don’t Instantiate bezie-
hen sich ebenfalls auf das gerade selektierte Element, und sind in Abhängigkeit davon verfüg-
bar.
Anwendung 81
5.1.5 Symbolleiste
Löschen
Einfügen
Neu
Öffnen
Speichern
Ausschneiden
Kopieren
KnotenModus
Eigenschaften
DebugModus
Instantiieren
NichtInstantiieren
StrangAlgor.
LinkModus
EditModus
Abbildung 22: Symbolleiste
Die Symbolleiste enthält - zwecks schnellerem Zugriff - die wichtigsten Kommandos ein wei-
teres Mal. Dazu kommen Befehle zum Ein- und Ausschalten des Debug-Modus (im Debug-
Modus werden Knoten- und Linkmarkierungen, sowie in den Hintergrund getretene generi-
sche Hypertext-Objekte eingeblendet), sowie zur Anwendung des Strang-Algorithmus auf
das gerade selektierte Element.
Anwendung 82
5.1.6 Knoten- und Link-Kontextmenüs
Abbildung 23: Knoten-Kontextmenü
Abbildung 24: Link-Kontextmenü
Das Knoten- bzw. Link-Kontetxtmenü wird bei einem Klick mit der rechten Maustaste auf
einen Knoten oder Link geöffnet. Es enthält die am häufigsten jeweils darauf ausführbaren
Funktionen. Einige Attribute können so auf direkte Weise modifiziert werden.
Anwendung 83
5.1.7 Knoten-Properties
In diesem Dialog werden die Eigenschaften von Knoten verwaltet.
Abbildung 25: Knoten-Properties
Für die Knoten-Instantiierung sind Knotentyp, minimale und maximale Anzahl der Instanzen
und das Verhalten bei der Instantiierung von besonderer Bedeutung. Unter Generic Content
verbirgt sich die Schnittstelle zu generischen Knoteninhalten - hier können sich zur Laufzeit
Inhaltsklassen, die eine bestimmte Schnittstelle bereitstellen, anmelden. Properties sind frei
Anwendung 84
definierbare Name/Wert-Paare, welche zum Beispiel von der WebStyles-Laufzeitumgebung
ausgewertet werden können. Unter Content kann ein externer Bezug definiert, oder aber der
tatsächliche Knoteninhalt bearbeitet werden.
5.1.7.1 Generischer Knoteninhalt
Der WebStyles-Editor sieht eine generische Erweiterungsmöglichkeit für Knoteninhalte vor.
Über die Klasse ContentManager können sich Anwendungskomponenten registrieren, die
eine bestimmte Schnittstelle (ContentTemplate) bereitstellen müssen.
package at.ac.uni_linz.tk.webstyles.generic;
import java.io.*;
public interface ContentTemplate extends Cloneable, Serializable {
public String getName();
public void editProperties();
public Object clone();
}
ContentTemplates sind für ihre Konfiguration, interne Datenhaltung und Serialisierung
(Persistenz) selbst verantwortlich. Der Editor ermöglicht lediglich die Verknüpfung mit
WebStyles-Knoten und den Aufruf über die Knoten-Properties. Er verfügt ansonsten über
keinerlei Kenntnis der Semantik oder der Implementierung generischer Inhalte.
Beispielsweise wird der Editor im Rahmen des Projektes "Generic Game Engine" an der Ab-
teilung für Telekooperation eingesetzt. Er dient dabei der Modellierung von 3D Welten - ein
Raum entspricht einem Knoten, ein Link einer Tür zwischen zwei Räumen. Innerhalb von
Anwendung 85
Räumen können verschiedene Spiele angesiedelt sein. Diese Spiele werden über Knoteninhal-
te definiert. Ein Memory-Spiel etwa läßt sich über Karten-Paare zusammenstellen.
Abbildung 26: Generischer Knoteninhalt
Wird der Graph im XML-Format exportiert, so inkludiert dies auch alle generischen Knoten-
inhalte. Die XML-Präsentation der Inhalte kann entweder auskodiert, oder über eine Konfigu-
rationsdatei festgelegt werden. Die Konfiguration der Beschreibung eines Memory-Spiels
könnte zum Beispiel folgendes Aussehen haben:
<?xml version="1.0"?>
<mapping>
[snip]
<class name="at.ac.uni_linz.tk.webstyles.xml.XMLNode" identity="id">
<map-to xml="Node"/>
<field name="Content"
type="at.ac.uni_linz.tk.webstyles.xml.memory.XMLMemory">
<bind-xml name="Content" node="element"/>
</field>
</class>
[snip]
Anwendung 86
<class name="at.ac.uni_linz.tk.webstyles.xml.memory.XMLMemory">
<map-to xml="XMLMemory"/>
<field name="name">
<bind-xml name="Name" node="element"/>
</field>
<field name="width">
<bind-xml name="Width" node="element"/>
</field>
<field name="height">
<bind-xml name="Height" node="element"/>
</field>
<field name="Pair" get-method ="getPairs"
type="at.ac.uni_linz.tk.webstyles.xml.memory.XMLMemoryPair"
collection="vector">
</field>
</class>
<class name="at.ac.uni_linz.tk.webstyles.xml.memory.XMLMemoryPair">
<map-to xml="XMLMemoryPair"/>
<field name="card1">
</field>
<field name="card2">
</field>
</class>
</mapping>
Das Resultat eines XML-Exports wird in weiterer Folge in andere Anwendungen übernom-
men.
<?xml version="1.0"?>
<Graph>
<Node Id="1">
<Name>Node_1</Name>
<Content>
<Name>Memory</Name>
<Width>2</Width>
<Height>4</Height>
Anwendung 87
<Pair card1="Apple" card2="Apfel"/>
<Pair card1="Pear" card2="Birne"/>
<Pair card1="Potato" card2="Kartoffel"/>
<Pair card1="Lettuce" card2="Salat"/>
</Content>
</Node>
</Graph>
5.1.8 Hypertext-Dokumenteditor
Abbildung 27: Der Hypertext-Dokumenteditor
Der Hypertext-Dokumenteditor ermöglicht die Gestaltung von Texten, welche als Knotenin-
halt zugewiesen werden können. Der Dokumenteditor hat nicht den Anspruch, professionelle
Anwendung 88
Werkzeuge zur Erstellung von Hypertexten zu ersetzen, vielmehr können Hypertext-
Dokumente importiert, und darin einfache Änderungen vorgenommen werden.
5.1.9 Link-Properties
Abbildung 28: Link-Properties
Anwendung 89
Ein Spezifikum der Link-Attribute sind Regeln, die zur Auswertung der Sichtbarkeit herange-
zogen werden. Die hier angegebenen Regeln müssen in dieser Syntax von der Laufzeitumge-
bung interpretiert werden können.
Anwendung 90
5.2 Beispiele für Hypertext-Entwürfe
5.2.1 Konstruktionsbeispiel Firmenpräsentation
In diesem Beispiel ist das Ziel die Erstellung einer Vorlage für ähnlich strukturierte Hypertex-
te zur Präsentation eines Unternehmens. Der WebStyles-Autor beginnt seine Arbeit mit der
Definition einiger generischer Knoten und Links. Ausgehend vom einer Startseite (Welcome)
soll der Benutzer zu einer Inhaltsübersicht (Content) gelangen, und von dort zu einzelnen
Themen verzweigen.
Abbildung 29: Hypertext-Konstruktion Firmenpräsentation (Schritt 1)
Anwendung 91
Die Themengebiete selbst sind vorgegeben, daher ist für jeden Strang ein Knoten zu erstellen
(andernfalls könnte man auch eine Kombination aus Fächerlink und Sequenzknoten verwen-
den). Da jeder Bereich aus mehreren Hypertext-Dokumenten bestehen kann, werden dafür
Sequenzknoten eingesetzt. Jeder Sequenzknoten verfügt über einen Link zurück zum Inhalts-
verzeichnis.
Abbildung 30: Hypertext-Konstruktion Firmenpräsentation (Schritt 2)
Neben der Vorgabe der grundsätzlichen Hypertext-Struktur, sowie der Knoten- und Link-
Typen sollen für die Knoteninhalte Schablonen festgelegt werden. In diesem Fall handelt es
sich vornehmlich um Vorgaben für Layout (Farbe, Zeichensatz, Kopf- und Fußzeilen, etc.),
um ein einheitliches Erscheinungsbild zu gewährleisten. Die Inhaltsvorlagen werden im Hy-
pertext-Dokumenteditor bearbeitet.
Anwendung 92
Abbildung 31: Definition von Inhaltsschablonen
Der generische Hypertext ist somit fertiggestellt, und kann als Basis für die Konstruktion ei-
nes konkreten Hypertexts durch den Hypertext-Autor dienen. In unserem Fall entscheidet sich
dieser für die Instantiierung aller Stränge, wobei die Sequenzknoten verschieden oft abgeleitet
werden.
Anwendung 93
Abbildung 32: Hypertext-Konstruktion Firmenpräsentation (Schritt 3)
5.2.2 Konstruktionsbeispiel Computer Based Training (CBT)
Das zweite Konstruktionsbeispiel ist der Arbeit von Martin Richartz [Richartz95] entnom-
men. Es wurde - neben anderen Tests auf Praxistauglichkeit - zur Verifikation der korrekten
Funktionsweise des Hypertext-Editors und zur Evaluierung der realisierten WebStyles-
Laufzeitumgebung herangezogen. Ausgangspunkt ist bereits ein generischer Hypertext, der
von einem WebStyles-Autor für die Erstellung von hypertextgestützten Kursunterlagen vor-
gegeben wurde.
Anwendung 94
Abbildung 33: Hypertext-Konstruktion CBT (Schritt 1)
Der Hypertext-Autor wählt zunächst den Startknoten Instructional_Goal aus, und instantiiert
diesen. Dadurch werden alle ein- und ausgehenden Links, sofern es sich nicht um Fächerlinks
handelt, mitinstantiiert. Im Anschluß daran selektiert der Autor den Fächerlink
Goal_To_Analysis. Dieser Link markiert den Beginn eines Stranges, der dupliziert wird. Zu-
sammenführungspunkt ist der Sequenzknoten Module, da dieser nicht über einen Sequenzlink
erreicht wurde.
Anwendung 95
Abbildung 34: Hypertext-Konstruktion CBT (Schritt 2)
Nun ist der Fächerlink Entities_To_Topic für eine Instantiierung vorgesehen. Dabei entsteht
ein weiterer Strang.
Anwendung 96
Abbildung 35: Hypertext-Konstruktion CBT (Schritt 3)
Nach einigen weiteren Instantiierungsschritten werden all jene generische Hypertext-Objekte,
die nicht mehr benötigt werden, entfernt (dafür ist die Funktion Don’t Instantiate bestimmt).
Generische Hypertext-Objekte, deren maximale Anzahl von Instanzen erreicht wurde, wan-
dern automatisch in den Hintergrund.
Anwendung 97
Abbildung 36: Hypertext-Konstruktion CBT (Schritt 4)
Der so entstandene Hypertext kann jetzt noch mit Navigationsregeln versehen und mit Inhalt
gefüllt werden, bzw. sind gegebenenfalls aus der generischen Vorlage übernommene Inhalts-
schablonen anzupassen. Der Zugangslink zum Knoten Calendar_Overview soll nur dann
aktiviert sein, wenn zuvor der Knoten Topic_Calendar besucht wurde. Zu diesem Zweck
wird dem Link eine entsprechende Regel zugewiesen.
Anwendung 98
Abbildung 37: Definition von Navigationsregeln
Nun kann der Ausgangsknoten Pre_Test mit Inhalt versehen werden, und der Link eingebun-
den werden.
Anwendung 99
Abbildung 38: Festlegung von Links im Hypertext-Dokumenteditor
Im Zuge des Exports der WebStyles-Laufzeitumgebung wird der Knoten Pre_Test wie folgt
erzeugt:
import at.ac.uni_linz.tk.webstyles.engine.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Pre_Test extends PSServlet {
public Pre_Test() {
super("Pre_Test", "engine.pre");
}
protected boolean isLinkEnabledInternal(
HttpSession session, String linkName) {
Anwendung 100
if (linkName.equals("PreTest_To_CalOverviewTest")) {
return (hasBeenVisited(session, "Topic_Calendar"));
}
return true;
}
}
Besucht ein Hypertext-Benutzer den Knoten Pre_Test, ohne zuvor den Inhalt von To-
pic_Calendar studiert zu haben, so wird der Link auf Calendar_Overview dynamisch aus-
geblendet.
Abbildung 39: Kontextabhängige Sichtweise des Knoteninhalts (1)
Anwendung 101
Sobald Topic_Calendar einmal aufgerufen wurde, ist auch der Link auf Calen-
dar_Overview aktiviert.
Abbildung 40: Kontextabhängige Sichtweise des Knoteninhalts (2)
Resümee und Ausblick 102
6. Resümee und Ausblick
Ziel dieser Arbeit war die praktische Umsetzung des WebStyles-Ansatzes, dessen Intention
die Vereinfachung der Erstellung und Verwendung von Hypertexten ist. Der nunmehr vorlie-
gende Editor unterstützt alle grundlegenden Konzepte des WebStyles-Modells: generische
Netze, regelbasierte Navigation und Prozeduren. Die Laufzeitumgebung wurde rudimentär
implementiert und hat derzeit den Status eines Prototyps. Die bisher gewonnenen Erfahrungen
lassen aber positive Rückschlüsse über die Praxistauglichkeit des gewählten Ansatzes zu.
Bei der Auseinandersetzung mit dem WebStyles-Modell trat klar zutage, daß die darin entwi-
ckelten Formalismen fundierte und ausgereifte Prinzipien darstellen. Auch wenn die Arbeit
von Martin Richartz schon einige Jahre zurückliegt, ist sie auf die aktuellen Probleme gegen-
wärtiger Hypertext-Strukturen anwendbar. Die WebStyles-Konstruktionsmechanismen erlau-
ben einerseits die Erstellung einer Vielzahl von Hypertext-Strukturen, und überzeugen ande-
rerseits durch ihre konzeptionelle Schlichtheit.
Bei der Entwicklung des Editors lag das Hauptaugenmerk dahingehend, daß die Anwendung
der WebStyles-Prinzipien nicht um des Modells willen, sondern zur bestmöglichen Unterstüt-
zung des Hypertext-Autors oder Benutzers erfolgt. Einige Konzepte wurden aus diesem
Grund etwas freier interpretiert. So ist es dem Autor freigestellt, zu jedem Zeitpunkt generi-
sche oder konkrete Hypertext-Objekte hinzuzufügen oder miteinander zu verbinden.
Im Zuge der Implementierungsarbeiten stellte sich als positiv heraus, daß die zugrundeliegen-
den Arbeiten über rein formaltheoretische Darlegungen hinausgehen, etwa durch die in Pseu-
docode gehaltene Beschreibung des Strang-Algorithmus und der exemplarische Darstellung
verschiedener Konstruktions- und Navigationsszenarien. In den wenigen Fällen, in denen die
WebStyles-Formalismen nicht vollständig oder nicht eindeutig waren (etwa bei speziellen,
teilweise widersprüchlichen Hypertext-Konstrukten) wurden pragmatische Annahmen getrof-
fen.
Resümee und Ausblick 103
Bei der Formulierung und späteren Umsetzung neuer Hypertext-Systeme darf ein De-facto-
Standard wie das World Wide Web nicht außer acht gelassen werden. Die Bereitstellung einer
Schnittstelle, die die Verwendung von WebStyles-Hypertexten im WWW ermöglicht, ist eine
Grundvoraussetzung für die Benutzerakzeptanz. Für eine funktionierende WebStyles-
Laufzeitumgebung war ein serverseitiger Ansatz nötig. Die Java Servlet API erwies sich dafür
als bestens geeignet, nicht nur weil der WebStyles-Editor selbst auch in Java implementiert
wurde, sondern weil Java Servlets alle Anforderungen einer WebStyles-Umsetzung erfüllen.
Vor allem in Hinblick auf die Laufzeitumgebung ist das Potential zukünftiger Weiterentwick-
lungen erkennbar. Vom System selbst wird bisher das Ein- und Ausblenden von Hyperlinks
unterstützt, dieser Ansatz ist jedoch auch in Richtung einer kontextabhängigen inhaltlichen
Aufbereitung erweiterbar. Auch die Konstruktionsunterstützung ist noch verbesserungsfähig.
Wünschenswert wäre eine abstraktere Datenhaltung und Bearbeitung von Knoteninhalten
bzw. der darin enthaltenen Anker und Hyperlinks.
Verbesserungsmöglichkeiten bestehen stellenweise auch in bezug auf funktionelle Ausgereift-
heit und Laufzeitverhalten. Die Applikation ist aufgrund der sauberen Strukturierung und Do-
kumentation der Softwarekomponenten wartungsfreundlich ausgelegt, sodaß einer Weiterent-
wicklung nichts im Wege stehen sollte. Die WebStyles-Laufzeitumgebung ist bisher lediglich
rudimentär implementiert. Sie kann zwar relativ komfortabel generiert werden, danach geht
der Konnex zum Graph jedoch verloren, und Runtime- und Graph-Modell laufen bei einer
weiteren Bearbeitung auseinander.
Die Gesamtlaufzeit des Projekts betrug etwa ein Jahr. Aufgrund der guten Praxiseignung des
WebStyles-Modells und nicht zuletzt dank der hervorragenden Unterstützung durch den Be-
treuer konnte das Projekt erfolgreich abgeschlossen werden. Der Editor erlaubt die komfortab-
le Konstruktion generischer und konkreter Hypertexte, die exportierten Servlet-Versionen
belegen die Realisierbarkeit der WebStyles-Laufzeitumgebung. Eine nachhaltige Umsetzung
der aufgezeigten Potentiale im Zuge von Folgeprojekten ist wünschenswert und wird auch
angestrebt.
Quellenverzeichnis 104
Quellenverzeichnis
[Bardini97]: Bardini, T.: "Bridging the Gulfs: From Hypertext to Cyberspace", in:
"Journal of Computer-Mediated Communication", Volume 3, Issue 2,
1997. http://www.ascusc.org/jcmc/vol3/issue2/bardini.html
[Berners89]: Berners-Lee, T.: "Information Management: A Proposal", CERN, Genf
1989
[Bush45]: Bush, V.: "As We May Think", in: "The Atlantic Monthly", Volume
176, No. 1, Pg. 101-108, Boston 1945.
http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm
[Conklin87]: Conklin, J.: "Hypertext: An introduction and survey", in: "IEEE Com-
puter 20, 9'87), Pg. 17-41, Washington 1987
[DeYoung90]: De Young, L.: "Linking Considered Harmful", in: "Proceedings of the
ECHT'90 European Conference on Hypertext, Designing and Reading
Hyperdocuments", Pg. 238-249, Paris 1990
[Eike00]: Eike, U.: "Content Management: Sitemanagement mit Web-Editoren".
http://www.zdnet.de/internet/artikel/wdm/200007/content03_00-ec.html
[Feizabadi96]: Feizabadi, S.: "The World Wide Web: Beyond the Basics", 1996.
http://ei.cs.vt.edu/~wwwbtb/
[Geary00]: Geary, D.: "Graphic Java - Die JFC beherrschen", Verlag Markt und
Technik, München 2000
Quellenverzeichnis 105
[GHJV96]: Gamma, Helm, Johnson, Vlissides: "Entwurfsmuster - Elemente
wiederverwendbarer objektorientierter Software", 1. Auflage, Addison-
Wesley, Bonn 1996
[Halasz88]: Halasz, F.: "Reflections on Notecards: Seven issues for the next genera-
tion of hypermedia systems", in: "Communications of the ACM, Issue 7
(1988)", Pg. 836-852, New York 1988
[HS94]: Halasz, Schwartz.: "The Dexter Hypertext Reference Model", in: "Com-
munications of the ACM, Issue 2 (1994)", Pg. 30-39, New York 1988
[HT98]: Hoppe, Tewissen: "Hypermedia-Systeme", Duisburg 1998.
http://collide.informatik.uni-duisburg.de/Lehre/Workshop/hyp_sys.htm
[MBF+99]: Mäurers, Baufeld, Friedrich, Müller, Wabnitz, Mühle: "Java - Das
Grundlagen Buch", 1. Auflage, Data Becker, Düsseldorf 1999
[MHK98]: Mühlhäuser, Hauber, Kopetzky: "Typing Concepts for the Web as a Ba-
sis for Re-use", in: Vercoustre, A.: "Reuse of Web Information", INRIA
Rocquencourt 1998
[Maurer01]: Maurer, H.: "Multimediale Informationssysteme", Institut für Informati-
onsverarbeitung und computergestützte neue Medien, Technische Uni-
versität Graz, Graz 2001
[Mössenböck98]: Mössenböck, H.: "Objektorientierte Programmierung in Oberon-2", 3.
Auflage, Springer Verlag, Berlin 1998
Quellenverzeichnis 106
[Nelson99]: Nelson, T.: "Xanalogical Structure, Needed Now More than Ever: Paral-
lel Documents, Deep Links to Content, Deep Versioning, and Deep Re-
Use", in: "ACM Computing Survey 31(4)", Cambridge 1999
[Nielsen95]: Nielsen, J.: "Multimedia and Hypertext - The Internet and Beyond",
Academic Press, Cambridge 1995
[Richartz95]: Richartz, M.: "Generik und Dynamik in Hypertexten", Dissertation, Fa-
kultät für Informatik der Universität Karlsruhe, Karlsruhe 1995
[SM88]: Smith, Weiss: "An overview of hypertext", in: "Communications of the
ACM, Issue 7 (1988)", Pg. 887-895, New York 1988
[TRTJ97]: Theng, Rigny, Thimbleby, Jones: "HyperAT: HCI and Web Authoring",
School of Computing Science, Middlesex University, 1997.
http://www.cs.mdx.ac.uk/staffpages/yinleng/hci97.html
[Weinreich97]: Weinreich, H.: "Ergonomie von Hypertext-Systemen und das World
Wide Web", Diplomarbeit am Fachbereich Informatik der Universität
Hamburg, Hamburg 1997
[WS88]: Weiland, Shneiderman: "Interactive graphics in hypertext systems",
Human-Computer Interaction Laboratory, University of Maryland, Col-
lege Park 1988
Quellenverzeichnis 107
[Zschau01]: Zschau, O.: "Website-Management mit Content Management Syste-
men", Karlsruhe 2001.
http://www.webagency.de/infopool/internetwissen/content-
management.htm