Implementierung eines Editors zur Erstellung generischer und dynamischer Hypertexte

Transcript

1. 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
2. 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)
3. 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.
4. 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.
5. 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
6. 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
7. 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
8. Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: Die Idee des Memex im Verständnis seiner Zeit________________________10 Abbildung 2: Historische Notizen von Theodor Nelson: Links zwischen Dateien_________13 Abbildung 3: Xanadu: Paralleles Bearbeiten mehrerer Dokumente, graphische Darstellung von Links _________________________________________________________________14 Abbildung 4: Hypertext-Browser, Hypertext-Server und Hypertext-Gateway ____________22 Abbildung 5 : Generische Knotentypen und mögliche Ableitungen____________________37 Abbildung 6: Generische Linktypen und mögliche Ableitungen ______________________40 Abbildung 7: Markierungen des Strang-Algorithmus _______________________________42 Abbildung 8: Mehrfachinstantiierung von Sequenzknoten ___________________________43 Abbildung 9: Mehrfachinstantiierung von Fächerlinks______________________________44 Abbildung 10: Zusammenführung von Strängen über einen Fächerlink_________________45 Abbildung 11: Beispiel für eine Strang-Instantiierung ______________________________46 Abbildung 12: Klassendiagramm (Ausschnitt) ____________________________________56 Abbildung 13: Java-Packages des WebStyles-Editors ______________________________58 Abbildung 14: Das Observer-Entwurfsmuster ____________________________________60 Abbildung 15: Das Model-View-Controller Schema _______________________________65 Abbildung 16: Dateidialog mit Vorschau-Ansicht _________________________________69 Abbildung 17: Graphische Benutzeroberfläche des WebStyles-Editors _________________77 Abbildung 18: Das Menü File _________________________________________________78 Abbildung 19: Das Menü Edit_________________________________________________79 Abbildung 20: Das Menü View________________________________________________79 Abbildung 21: Das Menü Tools _______________________________________________80 Abbildung 22: Symbolleiste __________________________________________________81 Abbildung 23: Knoten-Kontextmenü ___________________________________________82 Abbildung 24: Link-Kontextmenü _____________________________________________82 Abbildung 25: Knoten-Properties ______________________________________________83 Abbildung 26: Generischer Knoteninhalt ________________________________________85 Abbildung 27: Der Hypertext-Dokumenteditor____________________________________87 Abbildung 28: Link-Properties ________________________________________________88
9. Abbildungsverzeichnis Abbildung 29: Hypertext-Konstruktion Firmenpräsentation (Schritt 1) _________________90 Abbildung 30: Hypertext-Konstruktion Firmenpräsentation (Schritt 2) _________________91 Abbildung 31: Definition von Inhaltsschablonen __________________________________92 Abbildung 32: Hypertext-Konstruktion Firmenpräsentation (Schritt 3) _________________93 Abbildung 33: Hypertext-Konstruktion CBT (Schritt 1)_____________________________94 Abbildung 34: Hypertext-Konstruktion CBT (Schritt 2)_____________________________95 Abbildung 35: Hypertext-Konstruktion CBT (Schritt 3)_____________________________96 Abbildung 36: Hypertext-Konstruktion CBT (Schritt 4)_____________________________97 Abbildung 37: Definition von Navigationsregeln __________________________________98 Abbildung 38: Festlegung von Links im Hypertext-Dokumenteditor___________________99 Abbildung 39: Kontextabhängige Sichtweise des Knoteninhalts (1) __________________100 Abbildung 40: Kontextabhängige Sichtweise des Knoteninhalts (2) __________________101
10. 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
11. 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.
12. 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.
13. 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.
14. 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
15. Hypertext - Geschichte und gegenwärtige Systeme 6 durch interaktive Browser betrachtet, und durch Struktureditoren manipuliert werden. [SM88] • Hypertext stellt eine Technik zur Organisation von textuellen Informationen auf eine kom- plexe, nicht-lineare Weise und zur raschen, explorativen Zugänglichmachung von großen Wissensbasen zur Verfügung. [WS88] Konzeptuell kann ein Hypertext als ein gerichteter Graph betrachtet werden, wobei jeder Kno- ten ein Textstück darstellt, und die Kanten des Graphen miteinander in Beziehung stehende Textstücke verbinden. Dem Benutzer wird eine Schnittstelle angeboten, über welche Text betrachtet und Links überquert werden können, wenn neue Interessensbereiche in den Vorder- grund rücken Die Wortschöpfung "Hypertext" geht auf Theodor H. Nelson zurück. Für Nelson war Hyper- text ursprünglich ein für seine Arbeit als Autor gedachtes Werkzeug, das er wie folgt be- schrieb: "[A tool that] allows you to see alternative versions on the same screen on parallel windows and mark side by side what the differences are. Not by scan- ning but by analysis of data structure. Now the system I started designing in the 1960s, allows you, would have allowed you, will allow you to see connec- tions between the contents of different windows, like rubber bands between the middles of the windows" [Bardini97] Geprägt wurde der Begriff auch von der Bedeutung des Worts "hyper" in der Mathematik, wo es oftmals als Synonym für "erweitert" und "verallgemeinert" verwendet wird. Die Abkehr von der traditionellen Linearität war für Nelson eines der wichtigsten Merkmale von Hypertexten - er sprach selbst nannte sie auch eine Form des "Non-Sequential Writings". Nelson sah darin die Automatisierung von in der gedruckten Literatur üblichen Querverwei-
16. Hypertext - Geschichte und gegenwärtige Systeme 7 sen, mit dem Unterschied, daß diese nunmehr zum Hauptstrukturmerkmal von Texten wur- den. In einem Hypertext werden Informationen eines engeren Sinnzusammenhangs zu überschau- bare Einheiten aufgesplittet, die als Knoten bezeichnet werden. Diese Informationseinheiten können durch Links erreicht werden. Links sind gerichtete Verweise zwischen den Knoten, und stellen den strukturellen Teil der Information dar. Ein Link kann zu vertiefenden, übergeordneten oder verwandten Informationen führen. Diese Allgemeinheit ist es auch, die beim praktischen Einsatz des Hypertextkonzepts Probleme ver- ursacht. Als Anker bezeichnet man den Zielpunkt eines Links. Dieser Zielpunkt muß nicht notwendi- gerweise immer ein ganzer Knoten sein, vielmehr kann auch eine Teilmenge des Knotenin- halts als Anker fungieren. 2.2 Historischer Hintergrund 2.2.1 Vorgeschichte Bemühungen, Wissen zu sammeln und in einer für den Menschen geeigneter Form zugänglich zu machen, gibt es schon lange, ebenso wie die Tradition des Einsatzes technischer Hilfsmittel zu diesem Zweck. Die geschichtlichen Wurzeln des Hypertext-Konzepts liegen in einem für die Informatik prä- historischen Zeitalter. Im Mittelalter wurde das stetig wachsende Wissen der Menschheit hauptsächlich in klösterlichen Bibliotheken verwaltet. Während der Renaissance konstruierten Mönche ein Gerät, welches aus einem Räderwerk bestand, auf dem mehrere Bücher befestigt
17. Hypertext - Geschichte und gegenwärtige Systeme 8 wurden. Somit war es möglich, beim Lesen schnell zwischen verschiedenen Werken hin- und herzuspringen. Nicht umsonst bedeutet der Begriff "Enzyklopädie" wörtlich übersetzt "Rad des Lernens". 2.2.2 Pionierarbeiten 2.2.2.1 Vannevar Bush: Memex Vannevar Bush war während des Zweiten Weltkriegs Präsident des Massachusetts Institute for Technology (MIT) in Cambridge und einer der hochrangigsten Militärberater der US- Regierung. Als das Ende des Krieges absehbar war, veröffentlichte er 1945 den visionären Artikel "As We May Think", in dem er die Idee eines "Memex" (Memory Extenders) be- schrieb, das den Menschen bei sich wiederholenden Denkvorgängen unterstützen sollte. Bushs akademisches Hauptinteresse galt dem Gebiet der wissenschaftlichen Kommunikation. Seine Sorge war, daß die stetig wachsende Menge an wissenschaftlicher Literatur nicht mehr richtig genutzt werden könnte. "The real heart of the matter of selection, however, goes deeper than a lag in the adoption of mechanisms by libraries, or a lack of development of devices for their use. Our ineptitude in getting at the record is largely caused by the ar- tificiality of systems of indexing. When data of any sort are placed in storage, they are filed alphabetically or numerically, and information is found (when it is) by tracing it down from subclass to subclass. It can be in only one place, unless duplicates are used; one has to have rules as to which path will locate it, and the rules are cumbersome. Having found one item, moreover, one has to emerge from the system and re-enter on a new path. The human mind does not work that way. It operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accor- dance with some intricate web of trails carried by the cells of the brain. It has
18. Hypertext - Geschichte und gegenwärtige Systeme 9 other characteristics, of course; trails that are not frequently followed are prone to fade, items are not fully permanent, memory is transitory. Yet the speed of action, the intricacy of trails, the detail of mental pictures, is awe- inspiring beyond all else in nature." [Bush45] Bush kritisierte, daß die meisten existierenden Indexmöglichkeiten auf hierarchischen, alpha- betischen oder numerischen Strukturen basierten. Diese Strukturen wären aber nicht auf spezi- fische menschliche Fähigkeiten zugeschnitten, wie etwa jene, Assoziationen zu knüpfen. Nach Bush's Auffassung benötigte man anstelle der traditionellen Lagerungs- und Indizierungsme- thoden der Bibliotheken ein natürlicheres System, welches eher der Funktionsweise des menschlichen Gehirns entsprechen sollte. Das Memex war ein solches fiktives System, um große Mengen von Informationen zu verwalten. Eine der Ideen dahinter bestand in der Nut- zung von „Natural human principles“ für die Ablage und das Wiederfinden von Dokumen- ten. In seinem Manuskript bezeichnete Bush dieses Prinzip als "Selection by association". Das Memex selbst beschrieb Bush wie folgt: "Consider a future device for individual use, which is a sort of mechanized private file and library. It needs a name, and, to coin one at random, 'memex' will do. A memex is a device in which an individual stores all his books, re- cords, and communications, and which is mechanized so that it may be con- sulted with exceeding speed and flexibility. It is an enlarged intimate supple- ment to his memory. It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which he works. On the top are slanting translucent screens, on which material can be projected for convenient read- ing. There is a keyboard, and sets of buttons and levers. Otherwise it looks like an ordinary desk.
19. Hypertext - Geschichte und gegenwärtige Systeme 10 In one end is the stored material. The matter of bulk is well taken care of by improved microfilm. Only a small part of the interior of the memex is devoted to storage, the rest to mechanism. Yet if the user inserted 5000 pages of mate- rial a day it would take him hundreds of years to fill the repository, so he can be profligate and enter material freely." [Bush45] Abbildung 1: Die Idee des Memex im Verständnis seiner Zeit [HT98] Die Idee des Memex basiert auf den damals aktuellen Technologien der Feinmechanik und der Mikrophotographie. Wesentlicher als dieser Umstand ist jedoch, daß das Memex in einem
20. Hypertext - Geschichte und gegenwärtige Systeme 11 direkten Schritt assoziative Verknüpfungen erlaubt, indem aus einem Dokument heraus ohne Verzögerung ein anderes ausgewählt werden kann. Der Benutzer kann diese Verbindungen herstellen, indem er sie mit einem Namen versieht und in ein Codebuch einträgt. Über eine Tastatur wird die Verknüpfung bestätigt und besteht von da an dauerhaft. Wird später eines der beiden verknüpften Dokumente erneut aufgerufen, kann direkt über ei- nen Tastendruck auf das andere zugegriffen werden. Ganze Listen von verketteten Dokumen- ten können in beliebiger Geschwindigkeit durchgesehen werden, und ergeben in ihrer Ge- samtheit wiederum neue Dokument. Das Memex erlaubt auch das Einfügen persönlicher No- tizen, und verfügt damit über alle wesentlichen Eigenschaften, die der heutige Hypertext- Ansatz vorsieht. Einen Versuch, das von Vannevar Bush beschriebene System zur Unterstüt- zung des menschlichen Intellekts zu verwirklichen, hat es jedoch nie gegeben. Es hat aller- dings allein durch seine Konzeption die Entwicklung vieler späterer Hypertextsysteme maß- geblich beeinflußt. 2.2.2.2 Douglas C. Engelbart: NLS/Augment Inspiriert von Vannevar Bushs Artikel begann Douglas C. Engelbart Anfang der fünfziger Jahre eine bis heute andauernde Arbeit an der Vision eines "Conceptual Framework for the Augmentation of Man’s Intellect". Am Stanford Research Institute in Palo Alto, Kalifornien entwickelte er später das System NLS/Augment. Es enthielt bereits eine Vielzahl von Elemen- ten, die heute ganz selbstverständlich auf modernen Arbeitsplatzrechnern eingesetzt werden. Dokumente und Informationen wurden in drei Bereichen, die mit unterschiedlichen Zugriffs- arten versehen waren, abgelegt: einem Bereich für Wegwerfnachrichten, Briefe und Notizen, einem weiteren für gemeinsam benutzte Dokumente, und einem dritten Bereich für eingefro- rene, bibliotheksähnliche Dokumente. Zwischen den Dokumente und über die Grenzen der einzelnen Bereiche hinaus bestanden Querverweise. Jeder Benutzer verfügte über einen per- sönlichen Arbeitsplatz, von dem aus er auf die Dokumente zugreifen und sie parallel mit an- deren Benutzern betrachten konnte.
21. Hypertext - Geschichte und gegenwärtige Systeme 12 Engelbart wird berechtigterweise als geistiger Vater des Personal Computers und von Compu- ter Supported Cooperative Work (CSCW) bezeichnet. Von ihm stammt u.a. die erste Imple- mentierung eines Fenstersystems, er erfand die Maus als Eingabegerät, in seinem System gab es erstmals elektronische Post, Textverarbeitung und die integrierte Darstellung von Grafiken. Vieles was nicht von ihm selbst stammt, wurde von seinen ehemaligen Mitarbeitern später am XEROX Palo Alto Research Center entwickelt [Richartz95]. 2.2.2.3 Theodor Nelson: Xanadu Theodor H. Nelson begann Mitte der sechziger Jahre Beiträge zu seiner Vorstellung eines Hypertexts zu veröffentlichen. Eine wegweisende Arbeit aus dem Jahr 1965 trug den Titel "The Hypertext". Weiters beschäftigte sich Nelson mit der verteilten Speicherung großer Da- tenmengen, und mit durch den verbreiteten Computereinsatz entstehenden Liberalisierungsef- fekten. Nelsons Ansätze zum Thema Hypertext sind die ambitioniertesten der drei Pioniere, und des- halb wohl auch am schwersten umzusetzen. Das von Nelson initiierte Xanadu Projekt steht für ein Netzwerk eines weltumspannenden elektronischen Docuverse (Dokumenten-Universum), in dem alle Dokumente publiziert werden. Ähnlich wie unter NLS/Augment gibt es persönli- che und öffentliche Dokumentenbereiche, ebenso wie persönliche und öffentliche Links. Links sind gerichtet, aber immer von beiden Seiten aus sichtbar und verfolgbar. "A link is simply a connection between parts of text or other material. It is put in by a human. Links are made by individuals as pathways for the reader's ex- ploration; thus they are part of the actual document, part of a writing." [Nel- son99]
22. Hypertext - Geschichte und gegenwärtige Systeme 13 Abbildung 2: Historische Notizen von Theodor Nelson: Links zwischen Dateien [Maurer01] Später entwickelte Nelson Links zu sogenannten Transclusions weiter. Transclusions erlauben es, Dokumente oder Teile von Dokumenten in andere Dokumente einzubetten, ohne sie zu kopieren. Dies vermeidet redundante Speicherung und garantiert, dass die eingebetteten Do- kumente immer auf aktuellem Stand sind. Das Prinzip der Transclusions entspricht in etwa eingebetteten Dokumenten in modernen Textverarbeitungssystemen.
23. Hypertext - Geschichte und gegenwärtige Systeme 14 Abbildung 3: Xanadu: Paralleles Bearbeiten mehrerer Dokumente, graphische Darstellung von Links [Nelson99] Xanadu ist bisher nur in Teilbereichen realisiert. Durch den Siegeszug des World Wide Web gerieten Nelsons Arbeiten etwas in Vergessenheit, dennoch verfolgt er mit unverminderter Vehemenz die Verwirklichung seiner Idee weiter. Einer eventuellen Zusammenführung von Xanadu und World Wide Web steht Nelson kritisch gegenüber: "The World Wide Web was not what we were working toward, it was what we were trying to 'prevent'. The Web displaced our principled model with some- thing far more raw, chaotic and short-sighted. Its one-way breaking links glo- rified and fetishized as 'websites' those very hierarchical directories from
24. Hypertext - Geschichte und gegenwärtige Systeme 15 which we sought to free users, and discarded the ideas of stable publishing, annotation, two-way connection and trackable change." [Nelson99] 2.2.3 Hypertext im Zeitalter des Personal Computers In den siebziger Jahren beschäftigten sich nur sehr wenige Arbeiten mit Hypertext. Erwäh- nenswert sind das auf Andries van Dams zurückgehende Projekt FRESS (File Retrieval and Editing), ein im Lehrbetrieb eingesetztes Hypertextsystem, mit dem Studenten in einer verteil- ten Umgebung Texte am Bildschirm studieren und mit Kommentaren versehen konnten. Die Bedienung war allerdings relativ umständlich und ausschließlich textbasiert. Ein Prototyp von FRESS wurde später an die NASA verkauft, und dort tatsächlich für die Dokumentation der Apollo-Raumfahrtmissionen eingesetzt. ZOG war ein Hypertext-System, in dem erstmals Menüs eingesetzt wurden, um Links mit schneller Antwortzeit zu verfolgen und weitere Dokumente abzurufen. 1980 wurde es an Bord eines amerikanischen Flugzeugträgers auf 28 Workstations installiert, wo es zu Dokumentati- onszwecken, als Wartungshandbuch und als Schnittstelle zu einem Expertensystem für die Einsatzplanung von Flugzeugen verwendet wurde. Das Jahr 1987 bedeutete den Durchbruch von Hypertext in Wissenschaft und Forschung. Jeff Conklin veröffentlichte den Artikel "Hypertext: An Introduction and Survey" [Conklin87]. Er gab darin einen Überblick über alle wesentlichen, bis dahin in der Forschung entstandenen Systeme, und wies auch auf Probleme beim Hypertext-Einsatz hin. Conklin prägte auch den Term des "Getting lost in hyperspace" - so bezeichnete er das Problem der Desorientierung beim Navigieren durch den Hypertext, und identifizierte damit den kognitiven Mehraufwand der entsteht, wenn verschiedene Aufgaben bzw. Wege durch den Hypertext gleichzeitig zu bewältigen sind. [Richartz95]
25. Hypertext - Geschichte und gegenwärtige Systeme 16 Ein weiterer wichtiger Meilenstein war eine erstmals im November 1987 auf Initiative der ACM (Association for Computing Machinery) an der Universität von North Carolina abgehal- tene Konferenz namens "Hypertext ’87". Diese sollte alle wesentlichen Forschungsanstren- gungen in diesem Bereich zusammenführen, und aus den Kleinprojekten einiger Forscher und Utopisten ein weitverbreitetes populäres Thema machen. Praktisch alle namhaften Wissen- schafter dieses Gebiets waren anwesend, die Hälfte aller potentiell interessierten Teilnehmer mußte aus Platzmangel abgewiesen werden. Diese Hypertext-Konferenz findet seither alle zwei Jahre statt. [Nielsen95] 2.2.3.1 HyperCard Das erste wirklich populäre Hypertext-System ist das auf Bill Atkinson zurückgehende Hy- perCard. HyperCard wurde 1987 von Apple für seine Macintosh-Rechner vorgestellt und kos- tenlos mit den Rechnern ausgeliefert. Dies war vermutlich auch der entscheidende Grund für dessen hohe Popularität. Ein simples Benutzerinterface gestattete es, auf relativ einfache Wei- se multimediale Präsentationen zu gestalten. Die Informationen wurden als Stapel von elekt- ronischen Karten organisiert. Das System enthielt eine einfach zu erlernende, nicht allzu kom- plexe Programmiersprache (Hypertalk), die es zu einem universellen System machte. Es man- gelte allerdings an ausgereiften Strukturierungswerkzeugen zur Unterstützung der Hypertext- Autoren, so daß sich HyperCard kaum für komplexe Anwendungen anbot, sondern eher für kleine Informationssysteme, zum Prototyping und Experimentieren [Weinreich97].
26. Hypertext - Geschichte und gegenwärtige Systeme 17 2.2.3.2 NoteCards NoteCards wurde am XEROX Palo Alto Research Center entwickelt, und auf einem Xerox Lisp-System realisiert. Ziel war es, Autoren und Wissenschafter dabei zu unterstützen, zu- nächst unstrukturierte Gedanken und Ideen zu ordnen. NoteCards besteht aus den Komponen- ten NoteCards, Links, Browser und Fileboxes. Eine NoteCard ist das elektronische Pendant einer Karteikarte, und mit ähnlichen Einschrän- kung behaftet: ihr Inhalt wird durch die Größe ihrer Bildschirmdarstellung begrenzt. Quell- und Zielkarten werden über unidirektionale Links miteinander verbunden. Links sind an der Quellkarte durch ein Symbol gekennzeichnet, durch das Anklicken wird die Zielkarte auf den Bildschirm gebracht. Benutzer können Links mit einem Etikett versehen, das den Typ des Links zeigt. Browser bieten eine graphische Darstellung eines NoteCard-Netzes durch Knoten und Kanten an, und können für die Navigation verwendet werden. Die Diagramme werden automatisch durch das System erstellt. Fileboxes sind selbst wiederum NoteCards, die der Organisation von Kartenkollektionen dienen. Auch eine einfache Suchmöglichkeit nach Karteninhalten ist vorgesehen. NoteCards ist voll in die XEROX Lisp Programmierumgebung eingebettet, und verfügt damit über eine umfangreiche Funktionsschnittstelle. Dieser ermöglicht die Erstellung neuer Karten- typen, die Manipulation von Hypertext-Netzen und die Integration anderer Lisp-Programme.
27. Hypertext - Geschichte und gegenwärtige Systeme 18 2.2.3.3 Intermedia Intermedia wurde zwischen 1984 und 1992 an der Brown University entwickelt, und stellt eines der umfassendsten Projekte der frühen Hypertext-Phase der achtziger Jahre dar. Es ori- entiert sich an der damaligen Software-Architektur der Macintosh-Computer, ist objektorien- tiert aufgebaut und trennt strikt zwischen Struktur und Inhalten. Inhalte werden als Dokumente im Dateisystem des zugrundeliegenden Betriebssystems abge- legt. Da Intermedia als Hypermedia-System konzipiert ist, können Texte, Zeichnungen, Bil- dern, Zeitachsen und 3D-Modelle als Knoteninhalte erstellt werden. Die Navigation wird durch eine graphische Darstellung der Hypertext-Netze (sogenannte Web-Views) vereinfacht. Verweisstrukturen befinden sich in eigenen Web-Dokumenten, und werden graphisch visualisiert und manipuliert. Auf diese Weise können persönliche und ge- meinsam genutzte Netze erstellt werden. Eine Erweiterung von Intermedia erlaubte die Ver- wendung von Templates zur Unterstützung der Hypertext-Konstruktion. Templates sind Teil- netze eines Hypertextes, von denen durch Kopieren Instanzen erzeugt werden. Intermedia sieht ein Hypertext-Austauschformat vor, das von den Inhalten des Hypertexts abstrahiert, und ausschließlich auf den Austausch der Verweisstrukturen ausgerichtet ist. Für den Austausch von Dokumenteninhalten wurde auf existierende Standards zurückgegriffen.
28. Hypertext - Geschichte und gegenwärtige Systeme 19 2.2.3.4 Dexter Hypertext-Referenzmodell Das Dexter Hypertext-Referenzmodell ist das Ergebnis mehrerer von der Dexter-Gruppe or- ganisierter Workshops, und stellt eine umfassende Referenzarchitektur für Hypertexte dar. Es basiert auf einer Drei-Schichten-Architektur: • Runtime Layer: Darstellung des Hypertexts, Benutzerinteraktion, Dynamik • Storage Layer: Datenbasis für ein Netz von Knoten und Links • Within-Component Layer: Inhalt bzw. Struktur eines Knotens Auf der Ebene des Storage Layers sind die Knoteninhalte opak. Ihre innere Struktur offenbart sich erst im Within-Component Layer. Als Schnittstelle dieser beiden Schichten dient das sogenannte Anchoring. Es ermöglicht über indirekte Adressierung, daß Verweise innerhalb von Knoten entspringen und Ziele innerhalb von Knoten haben können, ohne daß im Storage Layer Information über die Struktur der Knoteninhalte vorhanden sein muß. Ein zweiter wichtiger Aspekt ist ein Hypertext-Datenmodell. Es benennt atomare Komponen- ten, Links und zusammengesetzte Komponenten als fundamentale Objekte. Das Modell trennt klar zwischen dem Inhalt der Knoten und der Bildung des Hypertext-Netzes aus diesen Kno- ten. Diese Trennung ist Voraussetzung für die Offenheit des Modells. Offenheit bedeutet hier die Möglichkeit, das System um neue Typen von Knoteninhalten zu erweitern. Wie Intermedia macht auch das Dexter-Modell bewußt keine Vorgaben für die Darstellung der Knoteninhalte. [HS94]
29. Hypertext - Geschichte und gegenwärtige Systeme 20 2.2.3.5 Digital LinkWorks Digital LinkWorks ist eine konkrete Umsetzung des Dexter-Referenzmodells. Die Trennung von Struktur und Inhalt wird gewährleistet, indem ein Strukturdienst quasi auf Ebene des Be- triebssystems agiert, und von Applikationen in Anspruch genommen werden kann. Über eine offene Programmier-Schnittstelle können bereits existierende, weitverbreitete Applikationen integriert, und damit der Bedarf an speziellen Editoren für Inhaltsdokumente abgedeckt wer- den. Die Applikation hinterlegt bei LinkWorks die Identität von Dokumenten sowie den An- ker innerhalb des Dokuments als Surrogat, und kann so Dokument und Anker bei Bedarf spä- ter wiederfinden. LinkWorks selbst speichert nur die Links, von denen der Benutzer beliebig viele erzeugen kann. Linkdokumente lassen sich zu einer gemeinsamen Sicht überlagern. Wenn der Benutzer einen Link verfolgt, der zu einem Dokument führt, dessen zugehörige Applikation noch nicht gestartet ist, so startet LinkWorks diese. Über eine Ereignisnachricht erhält die Anwendung den Befehl zur Darstellung des entsprechenden Dokuments, wobei ge- gebenenfalls auf den Zielanker positioniert wird. [Richartz95] 2.2.3.6 World Wide Web Tim Berners-Lee arbeitete 1980 als Consultant am europäischen Teilchenphysik Zentrum CERN in Genf. In seiner täglichen Arbeit frustrierte ihn der Umstand, daß sein Terminkalen- der, sein Telefonbuch und seine Dokumente in unterschiedlichen Datenbasen abgelegt waren, was einen simultanen Zugriff unmöglich machte. Heute erinnert er sich: "I wanted a program that could store random associations between arbitrary pieces of information" [Feizabadi96]. Sein erster Lösungsansatz war ein Programm namens "Enquire", das aber bald wieder in Ver- gessenheit geriet. Berners-Lee verließ in der Zwischenzeit das CERN, arbeitete im Bereich des Networking und lieferte Beiträge zu RPC-Systemen (Remote Procedure Call). 1984 wurden am CERN TCP/IP und das Internet eingeführt. Anfang 1989 kehrte Berners-Lee an das CERN (das mittlerweile über die größte Internet Site in Europa verfügt) zurück. Die dortige Computerkultur war gera-
30. Hypertext - Geschichte und gegenwärtige Systeme 21 de im Umbruch begriffen und wurde nunmehr durch neue verteilte, objektorientierte Soft- wareparadigmen wie jene von NeXT Software, und durch den Einsatz weiterentwickelter UNIX Umgebungen geprägt. Berners-Lee verfaßte einen Artikel unter dem Titel "Information Management: A Proposal". Darin führt er die Nachteile der existierenden hierarchischen Informationssysteme an, und schlägt als Alternative ein verteiltes, hypertext-basiertes System vor: "[...] a single user-interface to many large classes of stored information such as reports, notes, data-bases, computer documentation and on-line systems help [...]" [Berners89] Und weiter: "Let us see what components a hypertext system at CERN must have. The only way in which sufficient flexibility can be incorporated is to separate the infor- mation storage software from the information display software, with a well- defined interface between them. Given the requirement for network access, it is natural to let this clean interface coincide with the physical division between the user and the remote database machine." [Berners89]
31. Hypertext - Geschichte und gegenwärtige Systeme 22 Hypertext Server Dummy hypertext server makes existing database look like hypertext to the browser Generic browser Abbildung 4: Hypertext-Browser, Hypertext-Server und Hypertext-Gateway [Berners89] Berners-Lee's Vorschlag enthält folgende Komponenten: • Ein einfaches Protokoll für den Netzwerk-Zugriff auf für den Menschen lesbare Informa- tionen in verteilten Systemen. • Ein Protokoll für den automatischen Datenaustausch zwischen Informationsanbieter und - konsument. • Anzeigefunktionen für Text und Graphik unter Verwendung der diesbezüglich bereits am CERN existierenden Technologien. • Erstellung und Wartung von Dokumentensammlungen, in welche die Benutzer selbst Do- kumente ablegen können.
32. Hypertext - Geschichte und gegenwärtige Systeme 23 • Verknüpfung von Dokumenten oder Dokumentensammlungen durch vom Benutzer er- stellte Hyperlinks. • Eine Option, welche die Suche von Inhalten nach Schlüsselworten ermöglicht, und über Hyperlinks erreichbar ist. • Den Einsatz von frei verfügbarer Software wo immer möglich, Bereitstellung von Schnitt- stellen zu existierenden, proprietären Systemen. • Die kostenlose Bereitstellung der benötigten Programme. "As it happened many times in the history of science, the most impressive re- sults of the super-large scale scientific efforts were far from the main direc- tions of these efforts. I hope you agree that Web was a side effect of the CERN's scientific agenda. After World War 2, the nuclear centers of [...] developed countries around the world became the places with highest rate of the concen- tration of talented people per square of Labs. Some of the most talented per- sons among the national scientists usually were invited to the international CERN's Laboratories. The specific kind of the CERN's intellectual 'entire cul- ture' was constantly growing from one generation of the scientists and engi- neers to another during about four decades." [Feizabadi96] 1990 wurde der Vorschlag Berners-Lees unter dem Projekttitel "World Wide Web" umge- setzt. Die ersten WWW-Server und ein Browser wurden unter Verwendung von NeXTSTEP implementiert. Der Browser erlaubte neben der Anzeige auch WYSIWYG-Editierung von Hypertexten. Als Kommunikationsprotokoll zwischen Client und Server wurde das Hypertext Transport Protocol (HTTP) eingesetzt, Hyper Text Markup Language (HTML) und Universal Resource Locator (URL) dienten der Erstellung von Web-Dokumenten. Die Software wurde 1991 auf andere Plattformen portiert und schließlich für die Öffentlichkeit freigegeben. Marc Andreesen war zu dieser Zeit am National Center for Supercomputing Applications (NCSA) der University of Illinois beschäftigt. Er leitete eine kleine Gruppe von Diplomanden,
33. Hypertext - Geschichte und gegenwärtige Systeme 24 die im Februar 1993 eine Alpha-Version ihrer Weiterentwicklung des CERN Browsers veröf- fentlichten: "Mosaic for X". Im August desselben Jahres folgten frei erhältliche Versionen von Mosaic für Windows und Apple Macintosh. Zum ersten Mal in der Geschichte des World Wide Web existierte ein Webclient mit einem konsistenten und einfach zu handhabenden "Point-And-Click" Benutzerinterface für die drei häufigsten Betriebssysteme. Im Herbst 1993 machte der WWW Netzwerkverkehr dennoch erst etwa 1% des Gesamtverkehrs auf dem NSF (Nation Science Foundation) Backbone aus. Andreesen plante ursprünglich keine Weiterentwicklung von Mosaic. Anfang 1994 initiierte er dann aber gemeinsam mit Eric Bina und dem Gründer von SGI, Jim Clark, die "Mosaic Communications Corporation", die heute als Netscape bekannt ist. Dem World Wide Web liegt die Idee eines Universum von Dokumenten zugrunde, wobei jedes Dokument über einen Universal Resource Locator eindeutig referenzierbar ist. Dieser Mechanismus baut auf den Namensdiensten des Internet auf. HTML basiert auf den Konzepten von SGML (Standard Generalized Markup Language), ist aber stark vereinfacht. Verschiedene Arten von Klienten, meist graphische Browser wie Inter- net Explorer oder Netscape, lösen URI-Adressen auf und fordern HTML-Dokumente und dar- in eingebundene Objekte von HTTP-Servern an. HTML-Dokumente enthalten eingebettete Links in Form von weiteren URIs, die vom Benutzer angewählt werden können. Dieses Konzept nimmt große Einschränkungen zugunsten eines weltweiten, einfach zu erwei- ternden Dokumenten-Universums in Kauf. So gibt es keinen Mechanismus zur Konsistenzer- haltung. Die Folge sind Links, deren Ziel einfach nicht mehr existiert. Links sind keine eigen- ständigen Objekte, sondern lediglich in Form von Ankern in das Quell-Dokument eingebettet. Die Zurückverfolgung von Links vom Ziel zu Quelle ist demzufolge nicht möglich. Ebenso- wenig können Teilnetze manipuliert oder graphisch dargestellt werden.
34. Hypertext - Geschichte und gegenwärtige Systeme 25 Als einzige Navigationshilfe machen die WWW-Klienten Links auf Dokumente, die bereits einmal gesehen wurden, kenntlich - allerdings unabhängig davon, ob sie zwischenzeitlich ge- ändert wurden. Außerdem wird eine einfache Navigationshistorie mitgeführt. Ein weiteres Problem ist die unbekannte Kommunikationsbandbreite. Der Benutzer kann von einem Link aus oft nicht erkennen, was mit der Selektion des Links ausgelöst wird. Ein Verweis von ei- nem lokalen Dokument kann durchaus das Laden mehrerer Megabyte von Informationen von der anderen Seite des Erdballs auslösen. [Richartz95] 2.2.3.7 Hyper-G / HyperWave Hyper-G / HyperWave wurde in der ersten Hälfte der neunziger Jahre am Institut für Informa- tionsverarbeitung und computergestützte Medien (IICM) der Technischen Universität Graz entwickelt. 1996 wurde Hyper-G in HyperWave umgetauft, und wird seither auch kommer- ziell angeboten. Der Entwurf von Hyper-G verlief weitgehend parallel und unabhängig vom World Wide Web, wobei aber zweifellos einige Konzepte verschiedener Internet-Dienste miteingeflossen sind. Hyper-G ist verteiltes, mehrbenutzerfähiges Client/Server System. Dabei kommt ein eigenes, verbindungsorientiertes Protokoll zum Einsatz. Hyper-G Dokumente werden in Form einer SGML-Variante namens Hyper-G Text Format (HTF) kodiert, und in hierarchischen Kollektionshierarchien (Dokumentensammlungen) ge- speichert. Links werden in einer eigenen Datenbasis abgelegt. Sie sind von beiden Seiten aus sichtbar und traversierbar, können graphisch veranschaulicht und auf Konsistenz geprüft wer- den. Darüber hinaus ist eine Suche über Attribute und Inhalt von Dokumenten vorgesehen. Hyper-G Server ermöglichen den Zugriff auf Dokumente und Links, und stehen untereinander in Verbindung. Jeder Server besitzt ein HTTP-Gateway, so daß auch mit WWW-Browsern auf die Informationen eines Hyper-G Servers zugegriffen werden kann. Dabei gehen aber einige
35. Hypertext - Geschichte und gegenwärtige Systeme 26 Orientierungs- und Navigationshilfen verloren, die in den systemeigenen Clients angeboten werden. Der am weitesten entwickelte Client für HyperWave heißt "Harmony" und ist für verschiede- ne Unix-Plattformen erhältlich. Der Client für Microsoft Windows wird "Amadeus" genannt und bietet im Vergleich zu Harmony etwas eingeschränkte Navigations- und Orientierungshil- fen. Ein Herzstück von Harmony ist der sogenannte Session Manager, der die augenblickliche Position in der Kollektionshierarchie anzeigt. Eine Besonderheit ist die Unterstützung von dreidimensionalen Szenen als Hyper-G Dokumente, in denen der Benutzer navigieren und Dokumente auswählen kann. Harmony wird durch verschiedene Anzeige-Programme ergänzt. Das am häufigsten benutzte ist der Hypertext-Viewer, der auch HTML-Dokumente anzeigen kann. Dazu kommen Postsc- ript-Viewer, MPEG- und Audio-Decoder, usw. Gegenüber dem World Wide Web läßt sich Hyper-G wie folgt abgrenzen [Weinreich97]: • Sitzungen sind verbindungsorientiert. Benutzer können sich anmelden, und verfügen über eine persönliche Konfiguration. • Es werden zu jedem Zeitpunkt Hilfestellungen zur Orientierung und zur Navigation durch das Informationsangebot angeboten. • Inhalte können nur in strukturierter Form und unter Verwendung der Hyper-G Clients in einen Server eingebracht werden. • Alle Dokumente werden in einer objektorientierten Datenbank erfaßt und dabei gleich voll-textindiziert. • Links bestehen als unabhängige Einträge in einer eigenen Datenbank und sind bidirektio- nal.
36. Hypertext - Geschichte und gegenwärtige Systeme 27 • Links sind nicht an einen Objekttyp gebunden, sondern können von allen Dokumenttypen ausgehen, also auch von Tondokumenten, Bildern, Videos und 3D-Szenen. • Das System unterstützt Mehrsprachigkeit. Benutzer können eine bevorzugte Sprache wäh- len. • Es existiert ein hierarchisches Benutzer- und Gruppenkonzept, wodurch ein granuliertes Zugriffsrecht-System ermöglich wird. • Die Netzbelastung durch Verwendung von Caches reduziert. Hyper-G war von den Entwicklern als das Internet-Informationssystem der zweiten Generati- on gedacht. Trotz der zahlreichen Vorteile konnte es sich jedoch nicht durchsetzen - bis heute gibt es weltweit nur einige hundert Server. 2.2.3.8 Aktuelle Technologien und Werkzeuge Heute existiert eine Vielzahl von Authoring-Systemen, welche die Erstellung professioneller WWW-Seiten vereinfachen. Traditionellerweise sind diese Werkzeuge entweder für Power- User gedacht und ermöglichen die komfortable Kodierung und Prüfung von HTML, oder aber es wird eine bequeme WSYIWYG-Benutzerschnittstelle ("What you see is what you get") angeboten, sodaß keinerlei HTML-Kenntnisse erforderlich sind. In letzter Zeit ist zu beobach- ten, daß diese beiden konträren Ansätze wieder vermehrt zusammenwachsen, indem etwa zwischen WSYIWYG- und reiner Code-Ansicht hin- und hergeschaltet werden kann. Die De- signarbeit kann außerdem durch die Verwendung von übergeordneten Layouts, vorgefertigten Komponenten für Navigation oder für Messageboards, und die Integration von externen Da- tenquellen vereinfacht werden. Moderne Webauthoring-Programme benötigen aber auch zahlreiche Funktionen, die über das Erstellen und Modifizieren einzelner Seiten hinausgehen. Selbst für wenig komplexe Hyper- text-Strukturen ist eine effiziente Site-Verwaltung und die werkzeugunterstützte Aktualisie-
37. Hypertext - Geschichte und gegenwärtige Systeme 28 rung von Inhalten und Links ein Muß. Oft wird auch ein automatischer Abgleich mit dem Web-Server angeboten. Zu den meistverwendeten Tools zählen Macromedia Dreamweaver (intuitiver graphischer Designer, Unterstützung vieler Standards, Kompatibilität zu allen wichtigen Web-Browsern, Datenaustausch mit anderen Macromedia Produkten), NetObjects Fusion (integriertes Site- Management, Link-Prüfung, konsistente Visualisierung, automatische Erstellung von Naviga- tions-Leisten) und Microsoft Frontpage (einfache Handhabung, Wizards und Vorlagen, In- tegration mit Microsoft Office). Der Arbeitsaufwand für die Entwicklung, aber vor allem auch die Pflege von WWW-Seiten, ist beim Einsatz klassischer Web-Publishing Werkzeuge dennoch beträchtlich. Die dynami- sche Erstellung von Hypertexten - etwa über eine Datenbankanbindung - war ein erster Ansatz zur Entkopplung von Daten und deren Darstellung. Content Management Systeme beruhen auf einem ähnlichen Prinzip, gehen aber noch darüber hinaus. Sie ermöglichen die Abdeckung des gesamten Entwicklung- und Wartungsprozesses, inklusive Versionierung, Link- Management, Internationalisierung, Einhaltung von Corporate Identity und Abbildung des Publishing-Workflows. Innerhalb von Content Management Systemen werden Vorlagen und Inhalte (Texte, Bilder und andere Bestandteile) separat in einer Datenbank abgelegt. Der Ablauf der Seitenerstellung wird durch ein Rollenkonzept und ein Berechtigungssystem unterstützt, wodurch die ver- schiedenen Mitarbeiter konfliktfrei in Teilbereichen (Layout, Sitestruktur oder an einzelnen Dokumenten) arbeiten können. Weitere wichtige Merkmale sind Importfähigkeiten, die Er- weiterbarkeit mittels Skriptsprachen und Modulen, Personalisierung vom Webinhalten, XML- Fähigkeiten, Content Syndication (der Austausch von Inhalten zwischen Websites) und Re- portingfunktionen. Besonders interessant ist Content-Syndication für Websites, die ihr Angebot mit unterneh- mensrelevanten Informationen aufwerten wollen, beispielsweise mit Branchen-News, Börsen-
38. Hypertext - Geschichte und gegenwärtige Systeme 29 kursen oder aktuellen Nachrichten, oder die bestimmte Inhalte von anderen Sites automatisch beziehen. Grundlage dafür ist das sogenannte Information and Content Exchange Protokoll (ICE). Dieses bidirektionale Protokoll versendet zur Übertragungssteuerung XML-basierte Nachrichten zwischen den beteiligten Systemen. ICE ist formatunabhängig, das heißt, es kön- nen Texte, Bilder oder andere Binärdaten übertragen werden. ICE wird voraussichtlich auch als Standard durch das W3C (WWW Konsortium) ratifiziert. [Eike00] Bekannte Content Management Produkte sind Vignette Storyserver (Highend-Lösung), Gauss VIP (Integration externer Datenbanksysteme, Verwendung von professionellen Web- Editoren) und Network Productivity System (Design-Vorlagen, Datenbankanbindung über Common Gateway Interface, Verwaltung und Bedienung via Web-Browser). [Zschau01] 2.2.3.9 Schlußfolgerungen Während bei den Ansätzen von HyperCard, NoteCards und Intermedia Knoteninhalte in ei- nem bestimmten Format vorliegen müssen, wird in den Konzepten von Dexter und Link- Works von den Datentypen der Knoteninhalten abstrahiert - somit kann jede nur denkbare Applikation angebunden werden. Diese Hypertextsysteme befassen sich vorrangig mit der Repräsentation der Hypertextstruktur, wobei die Bedeutung des Knotens mehr (LinkWorks) oder weniger (Dexter) weit zurücktritt. Auch werden hier Links konsequent als eigenständige Objekte im Hypertextsystem behandelt, so daß ihnen Attribute zugeordnet werden können und sie von beiden Seiten sichtbar sind. Das World Wide Web macht die Problematik der Link-Sichtbarkeit und Aktualität besonders deutlich. In verteilten Systemen wird es mit zunehmender Größe immer schwerer möglich, Links speziell zu verwalten. Im WWW werden Links in Dokumente eingebettet. Daraus resul- tiert ein weiteres Problem: wird ein Knoten gelöscht, können hängende Links entstehen, die auf ein nicht existierendes Ziel zeigen.
39. Hypertext - Geschichte und gegenwärtige Systeme 30 Norman Meyrowitz, der Entwickler von Intermedia, formulierte dies - in Analogie zu Edger Dijkstras Bemerkungen über unstrukturierte Programmiertechnik - so: "Pure hypertext is like spaghetti code with GOTOs". Laura de Young ging noch einen Schritt weiter und wählte für einen Artikel den provokanten Titel "Linking Considered Harmful" [DeYoung90]. Es ist festzustellen, daß viele bestehende Hypertextsysteme vornehmlich für die Entwicklung informeller (unstrukturierte Daten) bzw. semi-formaler Strukturen geeignet sind. Regelmäßig wiederkehrende Strukturmuster müssen oftmals manuell erzeugt werden. Dies ist vor allem bei der Erstellung von umfangreichen Hypertexte problematisch. Zweifellos ist ein strukturier- tes Vorgehen bei der Erstellung von Hypertexten unabdingbar. [Richartz95] "Betrachtet man die im praktischen Einsatz befindlichen sog. Autorensysteme, so fallen hier starke Defizite auf. Die meisten Systeme erlauben zwar das Edi- tieren der monomedialen Medien [...] sie erlauben die Verwendung von Scrip- ting-Sprachen oder Icon-basierte Kontrollfluß-Sprachen. Der Hauptar- beitsaufwand liegt in der Implementierung der Hypermedia-Anwendung, d.h. der Erzeugung und Synchronisation multimedialer Daten, dem Schreiben von Scripte, dem Entwurf von Layouts etc. Der Rückgriff auf bestehende Strukturen wird nicht unterstützt, allenfalls der Rückgriff auf einzelne Elemente früherer Projekte; insofern fängt jedes Projekt mit einem weißen Blatt Papier an." [Ri- chartz95]
40. 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.
41. Das WebStyles Modell 32 3.2 Benutzerrollen Drei Benutzerrollen sind für den Einsatz von WebStyles charakteristisch: Der WebStyles-Autor erstellt Hypertext-Typdefinitionen einschließlich Navigationsregeln und Prozeduren. Er spezifiziert Attribute und Regeln, und zwar überall dort, wo später bei der Erstellung der konkreten Hypertext-Anwendung Vererbung stattfindet. Damit legt er den Grundstein für die Qualität der daraus entstehenden Hypertexte. Der Hypertext-Autor verfaßt Hypertexte auf Basis einer von ihm ausgewählten Hypertext- Typdefinition, die sämtliche Struktur- und Inhaltsvorgaben enthält, durch sukzessives Erwei- tern. Er erzeugt also hauptsächlich Inhalt. In den meisten Szenarien wird diese Rolle von ei- nem Fachexperten eingenommen. Der Hypertext-Benutzer konsumiert den entstandenen Hypertext, indem er durch ihn navi- giert. Im Hintergrund wertet das WebStyles-Laufzeitsystem Navigationsregeln und Prozedu- ren aus, und aktualisiert das Benutzer-Modell. Die Existenz der WebStyles nimmt der Benut- zer jedoch nur durch das dynamische Navigationsverhalten des Hypertexts wahr. 3.3 Hypertext-Komponenten Der WebStyles-Ansatz basiert auf einem formalen Modell, auf dem alle weiteren Elemente aufbauen. Aus diesem Modell ergeben sich auch die Anforderungen an konkrete Hypertext- systeme, auf deren Grundlage das WebStyles-Modell realisiert werden kann. Eine wichtige Eigenschaft von WebStyles ist die Objektorientierung. Hypertext-Objekte re- flektieren immer Zustand und Verhalten. Die Realisierung kann auf einem prototyp- oder ei- nem klassenbasierten Objektmodell beruhen.
42. Das WebStyles Modell 33 3.3.1 Hypertext-Objekt Das Hypertext-Objekt ist das grundlegende Element von Hypertexten. Es stellt den Basistyp für alle in Hypertexten enthaltenen Objekte dar. In einem klassenbasierten Modell ist dies eine abstrakte Klasse, das heißt es können keine Instanzen von Hypertext-Objekten erzeugt, son- dern nur Unterklassen abgeleitet werden. Ein Hypertext besteht aus den vom Hypertext- Objekt abgeleiteten Knoten und Links. Das WebStyles-Modell setzt voraus, daß Hypertext-Objekten eine Menge von Attributen zu- geordnet werden können. Ein Attribut ist ein Name/Wert-Paar. Als Namen werden Bezeichner verwendet, wie sie auch in Programmiersprachen üblich sind, als Werte müssen zumindest Ganzzahlen, Wahrheitswerte, Zeichenketten, Arrays und Referenzen auf Hypertext-Objekte zulässig sein. Hypertext-Objekte entsprechen damit den in objektorientierten Systemen üblichen Dictiona- ries, das heißt der Attributname stellt einen eindeutigen Schlüssel für den zugehörigen Wert dar. Dieser Umstand kommt auch einer Realisierung mit einem prototyp-basierten Objektmo- dell entgegen, da die Attribute als "Slots" der Objekte modelliert werden können. Die von Hypertext-Objekten abgeleiteten Knoten- und Link-Objekte können beliebig viele zusätzliche Attribute besitzen. Durch bestimmte Attribute wird der anwendungsbezogene Typ des Hypertext-Objekts definiert. Somit ergibt sich die Möglichkeit, eine Reihe von Typinfor- mationen anzugeben, welche von der Hypertextanwendung unterschiedlich interpretiert wer- den. 3.3.2 Hypertext-Knoten Ein Knoten ist ein Hypertext-Objekt, das durch ein spezielles Inhaltsattribut ausgezeichnet ist. Da der WebStyles-Ansatz unabhängig von der Art des Inhalts von Knoten anwendbar ist,
43. Das WebStyles Modell 34 ist auch eine nähere Betrachtung des Wertebereichs für den Knoteninhalt nicht relevant. Es ist auch unwesentlich, ob der Knoten selbst die Inhaltsinformation enthält oder nur einen Ver- weis auf eine externe Inhaltsinformation darstellt. Knoten haben außerdem die Eigenschaft, daß ihnen für die Darstellung des Inhalts ein Präsentationsobjekt zugeordnet werden kann. Für die Modellierung der Navigation benötigt man die Definition der Adjazenzmengen eines Knotens. Diese enthalten alle aus- und eingehenden Links eines Knotens, repräsentieren also die lokale Nachbarschaft eines Knotens. 3.3.3 Aggregat-Knoten Eine Sonderstellung nimmt der Aggregat-Knoten ein. Er besitzt als Knoteninhalt einen wei- teren Hypertext. Aggregat-Knoten können auch als Abstraktion oder Generalisierung des ent- haltenen Hypertextes verstanden werden. Ein Aggregat-Knoten ist also ein spezieller Knoten mit einem eingebetteten Hypertext und einer Menge von Zugangslinks des eingebetteten Hy- pertexts, die in weiterer Folge auf ein- und ausgehende Links des Aggregat-Knoten abgebil- det werden. 3.3.4 Hypertext-Link Ein Link ist ein spezielles Hypertext-Objekt, das vereinfacht betrachtet genau einen Quell- knoten mit einem Zielknoten assoziiert. Nach dieser Definition besteht zunächst keine weitere Beziehung zwischen dem Inhalt des Quell- bzw. Zielknotens, das heißt Links sind lediglich am Knoten als Ganzes angebracht. Für die meisten Anwendungen reicht dies nicht aus. Es wird gefordert, daß Links an bestimmten Punkten des Knoteninhalts angebunden werden. Sol- che Teilmengen sind üblicherweise Selektionen innerhalb des Knoteninhalts. Die Adjazenz- Knotenmenge eines Links besteht aus den beiden Knoten, die über den Link verbunden sind.
44. Das WebStyles Modell 35 3.3.5 Hypertext-Anker Die Anbindung von Links an Knoten wird über Anker realisiert. Ein Anker ist ein Anbin- dungspunkt, abgebildet als Surrogat der Selektion innerhalb des Inhalts des Knotens. Dieses Surrogat wird durch die WebStyles-Umgebung nicht interpretiert, sondern nur als transparente Information gehalten. Bei der Aktivierung des Knotens wird das Surrogat unverändert an die Inhaltsdomäne der konkreten Anwendung zurückgegeben, so daß diese den Anbindungspunkt entsprechend identifizieren und darstellen kann. Ein Anker ist im übrigen kein vollwertiges Hypertext-Objekt im oben angeführten Sinne, das heißt er kann keine weiteren Attribute besitzen. Durch die Einbeziehung von Ankern ändert sich die Definition von Links. Links können als spezielle Hypertext-Objekte mit einem Quell- anker und einem Zielanker betrachtet werden, wobei Quellknoten und Zielknoten des Links über die Anker identifiziert werden. Ein Link gilt dann als konsistent, wenn Quell- und Ziel- anker definiert sind. Ein Link, der diese Bedingung nicht erfüllt, wird als hängender Link be- zeichnet.
45. Das WebStyles Modell 36 3.4 Generische Netze Der Verwendung generischer Netze zur Hypertext-Typdefinition ist eine zentrale konzeptio- nelle Idee des WebStyles-Modells. Ein generisches Netz ist ein Hypertext, der aus einer Men- ge von generischen Knoten und einer Menge von generischen Links besteht. Diese bestim- men, welche Knoten und Links in einem gültigen, vom generischen Netz abgeleiteten Hyper- text vorkommen können, und wie oft. 3.4.1 Generische Knoten Jeder generische Knoten ist Stellvertreter für einen, mehrere oder keinen Knoten in einem abgeleiteten Hypertext. Diese Klassifizierung entspricht den anschließend dargestellten obli- gatorischen Knoten, Sequenzknoten und optionalen Knoten. Die Abbildung verdeutlicht auch Hypertextfragmente, wie sie von den generischen Knotentypen abgeleitet werden können. Zur visuellen Unterscheidung der generischen Hypertext-Objekte von den davon abgeleiteten kon- kreten Knoten und Links werden die generischen Objekte grau dargestellt. Die Raute in einem Link kennzeichnet ihn als vollständig (Quelle und Ziel sind definiert).
46. Das WebStyles Modell 37 Generischer Knotentyp Graphische Darstellung Mögliche Ableitungen Obligatorischer Knoten REQ Optionaler Knoten OPT Sequenzknoten SEQ Abbildung 5: Generische Knotentypen und mögliche Ableitungen Ein generischer Knoten spezifiziert auch Attribute für alle abgeleiteten Knoten, insbesondere • Typ und Name • Vorgabe für den Inhalt (Schablone) • Regeln für die Navigationsunterstützung im abgeleiteten Hypertext • Weitere anwendungsspezifische Attribute, die vom WebStyles-Autor festgelegt werden. Die drei generischen Knotentypen unterscheiden sich durch die jeweils unterschiedliche unte- re und obere Grenze für die abzuleitenden konkreten Knoten. Es wird jedoch an der für den Benutzer verständlicheren Bezeichnung von obligatorischem, optionalem und Sequenzknoten festgehalten.
47. Das WebStyles Modell 38 Somit ergibt sich für den obligatorischen Knoten als minimale und maximale Anzahl der Instanzen der Wert eins. Der optionale Knoten, der als konkreter Knoten auftreten kann, hat als Untergrenze den Wert Null und als Obergrenze den Wert Eins. Beim Sequenzknoten sind die beiden Werte frei wählbar und entscheiden darüber, ob die Sequenz eventuell ganz ver- schwindet und wie viele Knoten in der Sequenz maximal vorkommen können. Die Instantiierung von Sequenzknoten und optionalen Knoten erfordert eine spezielle Behand- lung. Jeweils ein eingehender und ein ausgehender Link von generischen Sequenzknoten und optionalen Knoten werden als Sequenzlinks ausgezeichnet (in den Abbildungen durch schwarze Punkte zwischen Link und Knoten dargestellt). Bei einem möglichen Wegfall des Knotens im konkreten Hypertext werden die beiden Sequenzlinks durch einen Link ersetzt. Bei der mehrfachen Instantiierung des Knotens werden Links zu Sequenzen von Links einge- fügt, so daß jeweils der ausgehende Sequenzlink des vorhergehenden Knotens mit dem einge- henden Sequenzlink des folgenden Knotens zu einem neuen, gemeinsamen Link zusammen- geführt wird. Alle anderen Links, die bei denen solchen Knoten ein- und ausgehen, fallen weg, wenn der betreffende generische Knoten nicht instantiiert wird. Bei mehrfacher Instantiierung von gene- rischen Knoten werden die von ihnen ausgehenden Stränge mitdupliziert. Dieses Prinzip wird in weiterer Folge noch näher erläutert. Zur Beschreibung hierarchischer bzw. baumförmiger Strukturen sind Aggregatknoten vorge- sehen, die bei der Ableitung nicht durch einen konkreten Knoten, sondern durch das enthalte- ne generische Netz ersetzt werden. Zu diesem Zweck wird jeweils ein ein- und ein ausgehen- der Link des eingebetteten generischen Netzes als Standard-Zugangslink gekennzeichnet, und mit einem ein- und ausgehenden Link des Aggregatknoten verknüpft. Die Zuordnung der rest- lichen Links erfolgt über Gleichheit der Namensattribute.
48. Das WebStyles Modell 39 3.4.2 Generische Links Analog zu den generischen Knoten stehen generische Links stellvertretend für einen, mehrere oder keinen Link im abgeleiteten Hypertext. Dies entspricht den Typen des obligatorischen Links, des sich wiederholenden Links (Fächerlink) und des optionalen Links. Ebenso wie der generische Knoten legt der generische Link die Attribute für die von ihm abgeleiteten konkre- ten Links fest, und zwar: • Typ und Name des abgeleiteten konkreten Links • Regeln für die Navigationsunterstützung im abgeleiteten Hypertext • Weitere, anwendungsspezifische Attribute, die vom WebStyles-Autor festgelegt werden
49. Das WebStyles Modell 40 Die folgende Abbildung veranschaulicht die verschiedenen generischen Linktypen. Generischer Linktyp Graphische Darstellung Mögliche Ableitungen Obligatorischer Link Optionaler Link Fächerlink Abbildung 6: Generische Linktypen und mögliche Ableitungen Auch hier werden die drei generischen Linktypen durch die untere und obere Grenze für die zu instantiierenden Links definiert.
50. Das WebStyles Modell 41 Fächerlinks haben zwei wichtige Eigenschaften, die beim obligatorischen bzw. beim optio- nalen Link fehlen: • Die Auffächerung der Instanzen erfolgt in der Richtung von der Quelle zum Ziel. Bei einer mehrfachen Instantiierung haben alle Instanzen den gleichen Knoten als Quelle. • Durch die mehrfache Instantiierung werden auch die Knoten am Ziel des Fächerlinks wie- derholt instantiiert. Dieses Verhalten bei der Instantiierung ähnelt jenem des Sequenzkno- tens. Dies impliziert, daß zusätzliche Links, die am generischen Zielknoten angebracht sind, bei der Instantiierung auch dupliziert werden. 3.4.3 Stränge Bei der mehrfachen Instantiierung von Sequenzknoten und Fächerlinks werden bestimmte Teile des generischen Netzes, welche vom generischen Sequenzknoten bzw. vom Fächerlink ausgehen, mitdupliziert. Diese mehrfach zu instantiierenden Teilnetze werden als Stränge bezeichnet. Stränge können auch von optionalen Knoten und Links ausgehen, wo sie bei Nicht-Instantiierung wegfallen. Solcherart definierte Stränge erlauben die Konstruktion verschiedener Hypertext-Strukturen durch generische Netze: • Sackgassenartige Teilnetze, etwa als Vertiefung der Instanzen eines Sequenzknotens oder Fächerlinks. • Links, die von jeder Instanz eines Sequenzknotens zu einem gemeinsamen Ausgangskno- ten führen. • Hypertexte, die mehrfach verzweigen und später, jeweils nach mehreren Knoten und Links in jedem Zweig, wieder an einem oder mehreren gemeinsamen Zielknoten zusammenge- führt werden.
51. Das WebStyles Modell 42 Ein spezieller Strang-Algorithmus dient der Ermittlung alle Hypertext-Objekte, die zu dem Strang gehören, der von einem Sequenzknoten bzw. einem Fächerlink ausgeht. Der Algorith- mus durchwandert ausgehend von jenen Links, die am Sequenzknoten hängen (mit Ausnahme der beiden Sequenzlinks), bzw. vom Zielknoten des Fächerlinks, rekursiv alle Teile des gene- rischen Netzes, die mit dem Sequenzknoten bzw. Fächerlink verbunden sind. Alle so besuch- ten generischen Hypertext-Objekte sind Teil des Stranges. Abbruchkriterium ist das Erreichen eines der folgenden Hypertext-Objekte: • Links, die bei denen das Instantiierungsattribut join mit dem Wert true belegt ist, und die in Vorwärtsrichtung erreicht werden. Durch diese Join-Links werden Strang-Instanzen wieder zusammengeführt. • Fächerlinks, die in Rückwärtsrichtung erreicht werden; auch sie dienen der Zusammenfüh- rung von Strang-Instanzen. • Sequenzknoten, die nicht über die Sequenzlinks erreicht werden, werden zu einer Kette verknüpft, welche die einzelnen Strang-Instanzen miteinander verbindet. Eine derartige Kette führt gewissermaßen als Querstraße durch die Strang-Instanzen. Der Strang-Algorithmus markiert in Tiefensuche rekursiv die zum Strang gehörenden Teile des generischen Netzes. Dabei werden vier Markierungen verwendet: Markierung Knoten Links Bedeutung F Fächermarke Feststellung von Widersprüchen S Sequenzmarke Zum Strang gehörig, Sequenz-Instanz ist zu erzeugen J Zusammenführung Link führt Strang-Instanzen zusammen D Duplizierung Zum Strang gehörig, Duplikat ist zu erzeugen Abbildung 7: Markierungen des Strang-Algorithmus
52. Das WebStyles Modell 43 Der Algorithmus hat die Komplexität O(n), wobei n die Anzahl der Hypertext-Objekte im generischen Netz bezeichnet. Er terminiert immer, da die Rekursion nur dann aufgerufen wird, wenn tatsächlich eine Markierung am betreffenden Hypertext-Objekt gesetzt wurde. Zur Verdeutlichung zeigt die folgende Abbildung die Auswirkung des Instantiierungsattributs join eines generischen Links, der Teil eines Stranges ist, welcher von einem Sequenzknoten oder einem Fächerlink ausgeht. Der Wert des Attributs join legt fest, ob mehrere Strang- Instanzen durch diesen Link wieder zu einem gemeinsamen Zielknoten zusammengeführt werden, oder nicht. Generischer Sequenzknoten Mögliche Ableitungen Ohne Join-Link SEQ Mit Join-Link SEQ J Abbildung 8: Mehrfachinstantiierung von Sequenzknoten
53. Das WebStyles Modell 44 Generischer Fächerlink Mögliche Ableitungen Ohne Join-Link Mit Join-Link J Abbildung 9: Mehrfachinstantiierung von Fächerlinks Das Zusammenführen von Strängen über einen Link in umgekehrter Richtung, also vom Ziel zur Quelle, erfolgt über einen Fächerlink, wie Abbildung 10 zeigt. Der Fächerlink ist also das Gegenstück zu einem Join-Link.
54. Das WebStyles Modell 45 Generisches Netz Abgeleitetes Netz Abbildung 10: Zusammenführung von Strängen über einen Fächerlink Enthält ein generisches Netz mehrere Sequenzknoten und/oder Fächerlinks, so können sich die dadurch definierten Stränge überlappen. Dies führt dazu, daß bei der Konstruktion unter- schiedliche Ergebnisse erzielt werden können, abhängig davon, an welcher Stelle der Hyper- text-Autor das generische Netz zuerst expandiert. Mit dem Strang-Algorithmus lassen sich auch noch komplexere Formationen als die eingangs beschriebenen definieren. Es ist jedoch nicht Sinn dieses Mechanismus, beliebig komplizierte Konstruktionen zu unterstützen, sondern die Strukturen Vertiefung, Verzweigung und Zu- sammenführung zu ermöglichen.
55. Das WebStyles Modell 46 Strang Graphische Darstellung Generischer Strang B seq A C D J Abgeleiteter Strang B c1 C c B b1 C a B a1 B a2 A 1 D 1 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.
56. Das WebStyles Modell 47 Die Gruppe dieser Instantiierungsattribute ist eine ausgezeichnete Teilmenge der Attribute des generischen Hypertext-Objekts. Dazu gehört gegebenenfalls eine Schablone für den Inhalt von Knoten. Die Attribute der generischen Hypertext-Objekte lassen sich wie folgt ordnen: • Instantiierungsattribute, die die Instantiierung der Hypertext-Objekte kontrollieren. • Navigationsattribute, welche die Navigation im generischen Netz steuern (im Gegensatz zu den Navigationsregeln für den abgeleiteten Hypertext, welche zu den Instantiierung- sattributen gehören). • Konsistenzattribute, die Regeln zur weitergehenden Prüfung der Vollständigkeit des ab- geleiteten Hypertextes enthalten. Sie werden nach Fertigstellung der Hypertext- Konstruktion ausgewertet. Der Ansatz zur Konstruktion von Hypertext-Graphen sollte einfach genug sein, um auch von Laien verstanden zu werden. Nicht zuletzt deshalb sollten generische Netze aus einigen weni- gen, dafür etwas größeren Produktionen bestehen, so daß die Hypertext-Autoren einen relativ großen Teil des zu konstruierenden Hypertextes auf einmal überblicken können. Das Modell der generischen Netze unterstützt auch intuitive Strukturierungsprinzipien wie Reihung, Ag- gregation und Auswahl, die so auf die Strukturierung von Hypertexten übertragen werden können.
57. Das WebStyles Modell 48 3.5 Navigationsmodell Die Navigationsunterstützung von WebStyles basiert auf einem einfachen Regelsystem. Ein Benutzer navigiert in einem Hypertext, wenn er damit ein bestimmtes Ziel verfolgt. Doch auch ein nicht zielgerichtetes Durchblättern oder Durchstöbern (Browsing) eines Hypertextes, wird mit Hilfe des WebStyles-Navigationsmodells unterstützt. Das Navigationssziel kann unterschiedliche Ausprägungen haben: • Abdecken aller Informationsknoten oder bestimmter Teile davon. • Auffinden einer bestimmten Information unter vielen. • Befriedigung eines bestimmten Informationsbedürfnisses (wobei möglicherweise nicht alle Informationsknoten des Hypertexts konsumiert werden müssen) Ein Hypertext-Benutzer bewegt sich entlang von Links von Knoten zu Knoten. Dabei befindet er sich wiederkehrend in verschiedenen Navigationssituation. Unter einer Navigationssituati- on versteht man einen Zustand, in dem der Benutzer aus der Adjazenz-Linkmenge des Kno- tens, an dem er sich gerade befindet, einen Link für die Ausübung des nächsten Navigations- schritts auswählen muß. Ein Benutzer kann sich gleichzeitig in mehreren Navigationssituatio- nen befinden, wenn das Hypertextsystem zuläßt, daß er mehrere Knoten zur gleichen Zeit ak- tiviert. Zu einem Navigationsschritt kommt es, wenn der Benutzer in einer Navigationssituation einen Link gewählt hat und über diesen den Zielknoten aktiviert. Resultat des Navigations- schritts ist eine neue Navigationssituation.
58. Das WebStyles Modell 49 Der durch den Benutzer ausgelöste Navigationsschritt hat zwei mögliche Semantiken: • Bei der Follow-Semantik wird der Ausgangsknoten der Navigationssituation durch den Zielknoten des Navigationsschritts ersetzt. Die Verwendung des Ausgangsknotens gilt als abgeschlossen. Die bisherige Navigationssituation existiert danach nicht mehr. • Bei der Visit- oder Branch-Semantik bleibt die Aktivierung des Ausgangsknotens erhal- ten, der neue Knoten wird zusätzlich aktiviert. Es entsteht also eine zusätzliche, neue Na- vigationssituation. Die Visit-Semantik wird typischerweise bei der Navigation zu Blatt- knoten eingesetzt, von denen keine weiteren Links ausgehen. Darüberhinaus kann der Benutzer eine Navigationssituation auch aufgeben, indem er einen aktivierten Knoten deaktiviert. Navigationsschritte werden von den Benutzern nacheinander ausgeübt, so daß sich eine geordnete Menge von Links, die der Benutzer zur Navigation ver- wendet hat, ergibt. Dies führt uns zum Begriff des Navigationspfads, welcher bei der Naviga- tion des Benutzers entsteht: Der Navigationspfad ist eine geordnete Menge von Links, die ein Benutzer zur Ausübung von Navigationsschritten benutzt hat. Da sich ein Benutzer in mehre- ren Navigationssituationen befinden kann, ist durch den Navigationspfad nicht notwendiger- weise ein Pfad vom Ausgangsknoten der ersten Navigationssituation zum Ausgangsknoten der letzten Navigationssituation definiert. Die Navigationsunterstützung des WebStyles-Ansatzes setzt als Entscheidungshilfe an der Navigationssituation an, also genau dort, wo der Benutzer sich für einen Link für die Ausfüh- rung des nächsten Navigationsschritts entscheidet. Die Unterstützung erfolgt durch Anwen- dung von Navigationsregeln, die vom Hypertext-Autor als Teil des Hypertexts spezifiziert werden. Resultat ist eine Menge von Links, auf die der Benutzer für seinen nächsten Naviga- tionsschritt zurückgreifen kann.
59. Das WebStyles Modell 50 Dabei sind zwei Strategien denkbar: • Strikte Benutzerführung: Die Entscheidung über den nächsten Navigationsschritt wird durch das Unterstützungssystem übernommen. Dem Benutzer bleibt allenfalls die Wahl aus einer Menge von empfohlenen Links, die das Unterstützungssystem ermittelt hat. • Freie, unterstützte Navigation: Dem Benutzer bleibt die Entscheidung über seinen nächsten Navigationsschritt überlassen, die vom Navigationssystem ermittelten Linkmen- gen gelten dabei nur als Empfehlungen. Diese Navigationsunterstützung ist • dynamisch, wenn sie immer bei Erreichen einer neuen Navigationssituation bzw. bei Ver- änderung der Voraussetzungen, unter denen sie erfolgt, durchgeführt wird, also zu unter- schiedlichen Zeitpunkten unterschiedliche Ergebnisse produziert. • adaptiv, wenn dabei der bisherige Navigationsablauf des individuellen Benutzers mit ein- bezogen wird. Jeder Navigationsschritt des Hypertext-Benutzers, insbesondere die Aktivierung von Knoten, kann eine Änderung des Benutzermodells und damit des Navigations-Kontexts hervorrufen. Die Navigationsregeln werden jeweils als Attribute der an der Navigationssituation beteiligten Hypertext-Objekte spezifiziert. Dabei werden gegebenenfalls mehrere Regeln zu einem Attri- but zusammengefaßt. Die Menge der Regeln in einem Attribut kann aber auch leer sein. Bei der Klärung der Frage, ob ein Link im Rahmen einer bestimmten Strategie benutzbar sein soll oder nicht, spielt auch die Richtung eine Rolle, in der er passiert wird. Differierende Na- vigationsrichtungen drücken unterschiedliche Semantiken aus. Deshalb können zusätzlich zu den Regeln, die für beide Richtungen gleichermaßen gelten, für jede Richtung jeweils unter- schiedliche Regeln spezifiziert werden. Bei der Zusammenstellung der aktuellen Regelbasis
60. Das WebStyles Modell 51 werden also die Vorwärts-Navigationsregeln der ausgehenden Links und die Rückwärts- Navigationsregeln der eingehenden Links in die Auswertung einbezogen. Die wichtigsten Aufgaben des im WebStyles-Laufzeitsystem enthaltenen Regelinterpreters sind: • Dynamische Zusammenstellung von Anfragen an die Regelbasis unmittelbar vor der Er- mittlung der für die Navigation möglichen Linkmengen • Einbeziehung von Objekten und Attributen des Hypertext-Modells bei der Regelauswer- tung Der Benutzerkontext spielt in diesem Zusammenhang eine wesentliche Rolle. Er dient dazu, alle global für einen Benutzer geltenden Informationen abzulegen. 3.6 Prozeduren Während Regeln die Bedingungen festlegen, unter denen ein Benutzer im Hypertext navigie- ren kann, definieren Prozeduren Aktionen, die bei der Navigation ausgeführt werden. So kann etwa die Wissensbasis für die Link-Auswahl, insbesondere das Benutzermodell, aktualisiert werden. Navigationsprozeduren werden - wie Navigationsregeln - von WebStyles-Autoren als Be- standteil generischer Hypertext-Objekte erstellt und bei der Instantiierung auf die konkreten Hypertext-Objekte übertragen. Hypertext-Autoren haben die Möglichkeit, Prozeduren gege- benenfalls noch anzupassen. Darüberhinaus sind Teile des WebStyles-Laufzeitsystems durch Prozeduren realisiert. Da dem WebStyles-Modell ein objektorientiertes Hypertextmodell zu- grunde liegt, definieren WebStyles-Prozeduren das Verhalten von Hypertext-Objekten. Sie sind Methoden der Hypertext-Objekte.
61. Das WebStyles Modell 52 Ein Knoten kann zwei Methoden besitzen, die bei der Navigation aufgerufen werden: • Die activate()-Methode wird jedes Mal aufgerufen, wenn der Knoten durch Ausführen eines Navigationsschritts über einen Link aktiviert wird. Die Ausführung erfolgt, bevor der Knoteninhalt tatsächlich präsentiert wird, das heißt bevor die Anwendung Kontrolle über den Inhalt erhält. • Die deactivate()-Methode kommt zur Ausführung, wenn ein Knoten deaktiviert wird, entweder durch explizite Deaktivierung durch den Benutzer oder durch die implizit ausge- löste Deaktivierung eines Navigationsschritts mit der Follow-Semantik. Analog dazu existieren auch Prozeduren für Links: • Die traverseforward()-Methode wird aufgerufen, wenn ein Link vom Hypertext-Benutzer zu einem Navigationsschritt in der Richtung von der Quelle zum Ziel betreten wird. • Die traversebackward()-Methode wird aufgerufen, wenn ein Link vom Hypertext- Benutzer zu einem Navigationsschritt in umgekehrter Richtung, vom Ziel zur Quelle, ver- wendet wird. Ein wichtiges Bestreben des WebStyles-Ansatzes ist es, daß das vorliegende Modell auch auf Standard-Hypertext-Architekturen abgebildet werden kann. Dem wird unter anderem dadurch Rechnung getragen, daß die generischen Netze selbst durch Hypertexte dargestellt werden. Das WebStyles-Modell stützt sich dabei auf die Möglichkeit, Hypertext-Objekte mit einer beliebigen Anzahl von Attributen auszustatten. Es kommen daher nur solche Hypertextsyste- me als Basis in Frage, die beliebige Attribute an Knoten und Links zulassen.
62. Das WebStyles Modell 53 3.7 Zusammenfassung In diesem Kapitel wurde die formale Definition des WebStyles-Modell beschrieben. Grundle- gender Bestandteil ist das eingangs erläuterte formale Hypertext-Modell. Zentrale Komponen- te sind dabei generische Netze, die in der Form spezieller Hypertexte durch die Vorgabe obli- gatorischer, optionaler und sich wiederholender Knoten und Links Typen von Hypertexten beschreiben. Bei der Instantiierung der generischen Netze, also der Erzeugung konkreter Hy- pertexte durch den Autor, werden Instantiierungsattribute der generischen Hypertext-Objekte als Attribute an die abgeleiteten konkreten Hypertext-Objekte vererbt. Der zweite Bestandteil des WebStyles-Modells ist die auf einem formalen Navigationsmodell beruhende Navigationsunterstützung, die den Benutzer durch Link-Auswahlmengen unter- stützt, welche durch Auswertung von Navigationsregeln ermittelt werden. Die Navigationsre- geln sind Instantiierungsattribute der Hypertext-Objekte und werden vom WebStyles-Autor als Attribute der generischen Hypertext-Objekte definiert. Schließlich kann der WebStyles-Autor Prozeduren als Instantiierungsattribute vorsehen, die bei der Navigation ausgeführt werden, etwa um das in die Auswertung der Navigationsregeln einfließende Benutzermodell zu aktualisieren.
63. 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.
64. 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.
65. 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)
66. 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.
67. 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
68. 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.
69. Implementierung 60 Subject Attach(Observer) Detach(Observer) Notify() Observer Update() for all o in observers { o->Update() } ConcreteSubject GetState() SetState() subjectState return 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
70. 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
71. 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.
72. 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();
73. 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(); } } }
74. 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
75. 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
76. 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
77. 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-
78. 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);
79. 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(); } }
80. 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);
81. 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] }
82. 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);
83. 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.
84. 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(); }
85. Implementierung 76 catch (Exception excpt) { log("Exception in PSServlet.getParsedContent", excpt); } return content; }
86. 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
87. 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.
88. 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.
89. 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.
90. Anwendung 81 5.1.5 Symbolleiste Löschen Einfügen Neu Öffnen Speichern Drucken Ausschneiden Kopieren Knoten Modus Eigenschaften Debug Modus Instantiieren Nicht Instantiieren Strang Algor. Link Modus Edit Modus 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.
91. 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.
92. 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
93. 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
94. 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]
95. 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>
96. 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
97. 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
98. 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.
99. 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)
100. Anwendung 91 Die Themengebiete selbst sind vorgegeben, daher ist für jeden Strang ein Knoten zu erstellen (andernfalls könnte man auch eine Kombination aus Fächerlink und Sequenzknoten verwen- den). Da jeder Bereich aus mehreren Hypertext-Dokumenten bestehen kann, werden dafür Sequenzknoten eingesetzt. Jeder Sequenzknoten verfügt über einen Link zurück zum Inhalts- verzeichnis. Abbildung 30: Hypertext-Konstruktion Firmenpräsentation (Schritt 2) Neben der Vorgabe der grundsätzlichen Hypertext-Struktur, sowie der Knoten- und Link- Typen sollen für die Knoteninhalte Schablonen festgelegt werden. In diesem Fall handelt es sich vornehmlich um Vorgaben für Layout (Farbe, Zeichensatz, Kopf- und Fußzeilen, etc.), um ein einheitliches Erscheinungsbild zu gewährleisten. Die Inhaltsvorlagen werden im Hy- pertext-Dokumenteditor bearbeitet.
101. 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.
102. Anwendung 93 Abbildung 32: Hypertext-Konstruktion Firmenpräsentation (Schritt 3) 5.2.2 Konstruktionsbeispiel Computer Based Training (CBT) Das zweite Konstruktionsbeispiel ist der Arbeit von Martin Richartz [Richartz95] entnom- men. Es wurde - neben anderen Tests auf Praxistauglichkeit - zur Verifikation der korrekten Funktionsweise des Hypertext-Editors und zur Evaluierung der realisierten WebStyles- Laufzeitumgebung herangezogen. Ausgangspunkt ist bereits ein generischer Hypertext, der von einem WebStyles-Autor für die Erstellung von hypertextgestützten Kursunterlagen vor- gegeben wurde.
103. 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.
104. Anwendung 95 Abbildung 34: Hypertext-Konstruktion CBT (Schritt 2) Nun ist der Fächerlink Entities_To_Topic für eine Instantiierung vorgesehen. Dabei entsteht ein weiterer Strang.
105. Anwendung 96 Abbildung 35: Hypertext-Konstruktion CBT (Schritt 3) Nach einigen weiteren Instantiierungsschritten werden all jene generische Hypertext-Objekte, die nicht mehr benötigt werden, entfernt (dafür ist die Funktion Don’t Instantiate bestimmt). Generische Hypertext-Objekte, deren maximale Anzahl von Instanzen erreicht wurde, wan- dern automatisch in den Hintergrund.
106. Anwendung 97 Abbildung 36: Hypertext-Konstruktion CBT (Schritt 4) Der so entstandene Hypertext kann jetzt noch mit Navigationsregeln versehen und mit Inhalt gefüllt werden, bzw. sind gegebenenfalls aus der generischen Vorlage übernommene Inhalts- schablonen anzupassen. Der Zugangslink zum Knoten Calendar_Overview soll nur dann aktiviert sein, wenn zuvor der Knoten Topic_Calendar besucht wurde. Zu diesem Zweck wird dem Link eine entsprechende Regel zugewiesen.
107. Anwendung 98 Abbildung 37: Definition von Navigationsregeln Nun kann der Ausgangsknoten Pre_Test mit Inhalt versehen werden, und der Link eingebun- den werden.
108. 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) {
109. 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)
110. 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)
111. 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.
112. 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.
113. 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
114. Quellenverzeichnis 105 [GHJV96]: Gamma, Helm, Johnson, Vlissides: "Entwurfsmuster - Elemente wiederverwendbarer objektorientierter Software", 1. Auflage, Addison- Wesley, Bonn 1996 [Halasz88]: Halasz, F.: "Reflections on Notecards: Seven issues for the next genera- tion of hypermedia systems", in: "Communications of the ACM, Issue 7 (1988)", Pg. 836-852, New York 1988 [HS94]: Halasz, Schwartz.: "The Dexter Hypertext Reference Model", in: "Com- munications of the ACM, Issue 2 (1994)", Pg. 30-39, New York 1988 [HT98]: Hoppe, Tewissen: "Hypermedia-Systeme", Duisburg 1998. http://collide.informatik.uni-duisburg.de/Lehre/Workshop/hyp_sys.htm [MBF+99]: Mäurers, Baufeld, Friedrich, Müller, Wabnitz, Mühle: "Java - Das Grundlagen Buch", 1. Auflage, Data Becker, Düsseldorf 1999 [MHK98]: Mühlhäuser, Hauber, Kopetzky: "Typing Concepts for the Web as a Ba- sis for Re-use", in: Vercoustre, A.: "Reuse of Web Information", INRIA Rocquencourt 1998 [Maurer01]: Maurer, H.: "Multimediale Informationssysteme", Institut für Informati- onsverarbeitung und computergestützte neue Medien, Technische Uni- versität Graz, Graz 2001 [Mössenböck98]: Mössenböck, H.: "Objektorientierte Programmierung in Oberon-2", 3. Auflage, Springer Verlag, Berlin 1998
115. Quellenverzeichnis 106 [Nelson99]: Nelson, T.: "Xanalogical Structure, Needed Now More than Ever: Paral- lel Documents, Deep Links to Content, Deep Versioning, and Deep Re- Use", in: "ACM Computing Survey 31(4)", Cambridge 1999 [Nielsen95]: Nielsen, J.: "Multimedia and Hypertext - The Internet and Beyond", Academic Press, Cambridge 1995 [Richartz95]: Richartz, M.: "Generik und Dynamik in Hypertexten", Dissertation, Fa- kultät für Informatik der Universität Karlsruhe, Karlsruhe 1995 [SM88]: Smith, Weiss: "An overview of hypertext", in: "Communications of the ACM, Issue 7 (1988)", Pg. 887-895, New York 1988 [TRTJ97]: Theng, Rigny, Thimbleby, Jones: "HyperAT: HCI and Web Authoring", School of Computing Science, Middlesex University, 1997. http://www.cs.mdx.ac.uk/staffpages/yinleng/hci97.html [Weinreich97]: Weinreich, H.: "Ergonomie von Hypertext-Systemen und das World Wide Web", Diplomarbeit am Fachbereich Informatik der Universität Hamburg, Hamburg 1997 [WS88]: Weiland, Shneiderman: "Interactive graphics in hypertext systems", Human-Computer Interaction Laboratory, University of Maryland, Col- lege Park 1988
116. Quellenverzeichnis 107 [Zschau01]: Zschau, O.: "Website-Management mit Content Management Syste- men", Karlsruhe 2001. http://www.webagency.de/infopool/internetwissen/content- management.htm