Diplomarbeit: Generische und dynamische Hypertexte (2001)

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


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


Abbildung 29: Hypertext-Konstruktion Firmenpräsentation (Schritt 1) _________________90


Abbildung 31: Definition von Inhaltsschablonen __________________________________92


Abbildung 33: Hypertext-Konstruktion CBT (Schritt 1)_____________________________94




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


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-


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


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


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.


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


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.


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]


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.


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


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]


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].


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.


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.


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]


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-


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 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.


• 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,


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.


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


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.


• 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-


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-


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.


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.


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.


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,


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.


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.


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).


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.


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.


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


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.


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.


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


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


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.


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.


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.


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.


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.


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.


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


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.


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.


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

Drucken

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.


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


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


Nun ist der Fächerlink Entities_To_Topic für eine Instantiierung vorgesehen. Dabei entsteht

ein weiterer Strang.

Anwendung 96


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


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


[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


[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


[Zschau01]: Zschau, O.: "Website-Management mit Content Management Syste-

men", Karlsruhe 2001.

http://www.webagency.de/infopool/internetwissen/content-

management.htm