Kapitel 7

Ausblick

In diesem Kapitel zähle ich einige Dinge auf, die ich aus verschiedenen Gründen (vor allem die begrenzte Zeit) nicht in IP4W3 implementieren konnte. Ich diskutiere aber auch Fragen, die sich bei der Benutzung vielleicht stellen, und deren mögliche Lösungen. Die einzelnen Abschnitte dieses Kapitels sind voneinander unabhängig und als Sammlung zu verstehen.

7.1 Suchen in mehreren Dokumenten

Eine Funktion, die vielleicht als erste in IP4W3 vermißt wird, ist die Suche in mehreren Dokumenten. Falls es sich bei den fraglichen Dokumenten um Instanzen von verschiedenen Dokumenttypen handelt, gibt es einen einfachen Grund dafür: Die Definition der Suchmuster und auch der Formatierungsrumpf sind untrennbar mit der DTD verbunden. Aus diesem Grund gibt es keine gemeinsamen, durch die Suchmuster definierten Kategorien, in denen die Suche stattfinden kann.

Handelt es sich jedoch um eine Sammlung von gleichartigen Dokumenten, d.h. Instanzen des selben Dokumenttyps, die gegebenenfalls auch in einem inhaltlichen Zusammenhang stehen, so ist der Wunsch nach einer Suchmöglichkeit in mehreren Dokumenten naheliegend.

Für diesen Fall braucht IP4W3 keine besondere Unterstützung anzubieten, da SGML/XML eigene Konstrukte zur Lösung dieses Problems bietet. Auf den ersten Blick ist dies eine typische Anwendung des Subdocument-Features von SGML³⁵. Aufgrund des zuvor gesagten ist es jedoch in IP4W3 nicht notwendig oder sinnvoll, Dokumente unterschiedlicher Typen als Subdocument zu behandeln. Außerdem ist das Subdocument-Feature in XML nicht enthalten³⁶. Das Problem kann viel einfacher durch den Entity-Mechanismus von SGML/XML gelöst werden, indem mehrere Dokumente zu einem zusammengefaßt werden. Zur Erklärung diene folgendes Beispiel.

Es sollen drei Bücher, die Instanzen des selben Dokumenttyps sind, in IP4W3 integriert werden. Die Bücher besitzen die folgenden PIDs37: "-//DEK//DOCUMENT Fundamental Algorithms//DE" "-//DEK//DOCUMENT Seminumerical Algorithms//DE" "-//DEK//DOCUMENT Sorting and Searching//DE" Der PID der zugrunde liegenden DTD sei: "-//Addison-Wesley//DTD cs professional//DE" Das Wurzelelement dieses Dokumenttyps sei buch, die Doctype-Deklaration der drei Instanzen sieht also wie folgt aus38: <!DOCTYPE buch PUBLIC "-//Addison-Wesley//DTD cs professional//DE">

Um diese drei Bücher nun zu einer Instanz zusammenzufassen, ist folgendes zu tun: Es muß eine DTD erstellt werden, die eine Folge von Elementen des Typs buch erlaubt und es muß eine Instanz erstellt werden, die die drei Bücher als Entities lädt.

Beide Fälle sind einfach zu handhaben. Die DTD sieht so aus³⁹:

<!ELEMENT bibliothek - - (buch)+> 
<!ENTITY % buch-dtd PUBLIC "-//Addison-Wesley//DTD cs professional//DE">
%buch-dtd;

Nach dieser Definition besteht eine bibliothek einfach aus einer Folge von Büchern. Die Instanz nimmt nun folgende Form an:

<!DOCTYPE bibliothek [
<!ELEMENT bibliothek - - (buch)+> 
<!ENTITY % buch-dtd PUBLIC "-//Addison-Wesley//DTD cs professional//DE">
%buch-dtd;
]>
<!ENTITY aocp1 PUBLIC "-//DEK//DOCUMENT Fundamental Algorithms//DE">
<!ENTITY aocp2 PUBLIC "-//DEK//DOCUMENT Seminumerical Algorithms//DE">
<!ENTITY aocp3 PUBLIC "-//DEK//DOCUMENT Sorting and Searching//DE">
<bibliothek>
&aocp1;
&aocp2;
&aocp3;
</bibliothek>

Soweit stellt die SGML-seitige Behandlung kein Problem dar. Es ist aber noch zu diskutieren, wie sich Suchmusterdefinitionen und DSSSL-Skripte verhalten, die für die Buch-DTD geschrieben wurden und nun zusammen mit der Bibliothek-DTD eingesetzt werden. In beiden Fällen sind Schwierigkeiten ausgeschlossen, die durch die Zusammenfassung der Instanzen in der beschriebenen Weise hervorgerufen werden. Der Grund besteht darin, daß sich sowohl Suchmuster als auch DSSSL-Skripte auf Elemente konzentrieren, die »unten« in der Hierarchie stehen. Im Gegensatz zu Suchmustern kann man in DSSSL zwar gezielt die Wurzel ansprechen, jedoch ist auch dadurch kein neues Problem entstanden. Vielmehr stellen sich hier Fragen, die auch bei einzelnen Instanzen auftreten. Die Diskussion wurde bereits in 5.2.4 geführt.

Abschließend kann man feststellen, daß keine Notwendigkeit besteht, eine besondere Unterstützung für die Behandlung von mehreren Dokumenten in IP4W3 vorzusehen. Die Mittel, die SGML/XML bereitstellen sind sowohl ausreichend als auch einfach genug, um in IP4W3 den Standpunkt einzunehmen, daß man grundsätzlich genau ein Dokument vor sich hat.

7.2 Konformität zu Standards

Die Frage, in wie weit IP4W3 konform zu den verschiedenen Standards ist, ist relativ leicht zu beantworten. Da ich für den Zugriff auf Instanzen und die Interpretation von DSSSL-Stylesheets externe Programme verwende, leitet sich die Konformität direkt aus den Eigenschaften dieser Programme ab.

Soweit es das Parsing von SGML/XML betrifft, ist in IP4W3 durch die Benutzung der Programme nsgmls und jade die bestmögliche Einhaltung der entsprechenden Standards gewährleistet (dies sind [ISO86] und [W3C98D]). Eine eigene System-Deklaration für IP4W3 ist nicht nötig; implizit verwendet das System die entsprechende Deklaration des Parsers (http://www.jclark.com/sp/sysdecl.htm).

Bei der Behandlung von Suchmustern ist darauf zu achten, daß das Programm Cost case-insensitive arbeitet. Dieses Verhalten entspricht der Reference Concrete Syntax von SGML. XML ist jedoch case-sensitive. Der Autor von Cost, Joe English, arbeitet zur Zeit an einer Aktualisierung, die XML-konform sein wird. Sofern er dabei keine Änderungen am Verhalten seines Programms einbaut, sollten meine Programme unmittelbar lauffähig sein.

Als DSSSL-Maschine verwende ich Jade. Der Programmierer James Clark ist auch der Verfasser der DSSSL-Spezifikation [ISO96B], so daß man auch hier von Einhaltung des Standards ausgehen kann. Allerdings ist Jade keine vollständige Implementierung. Ausführlich ist dies in der Dokumentation nachzulesen [CLAR98B]. Insbesondere fehlt die Transformationssprache. Clark hat als Ersatz einige neue Flow Objects definiert, von denen ich bei der Transformation in HTML Gebrauch mache.

Bei der Web-Übertragung ist der Server für die Einhaltung des Protokolls (HTTP) verantwortlich. Der von IP4W3 ausgegebene HTTP-Kopf (Content-type) ist HTTP-1.0-konform und meine Skripte halten sich an die CGI-Konvention. Sie sind daher mit jedem Web-Server lauffähig, der CGI beherrscht.

7.3 Persistenz von URLs

Die Persistenz von URLs ist von Bedeutung, wenn man eine Verknüpfung (Link) zu einer Seite herstellen möchte, die von IP4W3 generiert wurde. Auf die grundsätzliche Problematik der Namen und Adressen möchte ich hier nicht eingehen. Dazu empfehle ich den Aufsatz »The Myth of Names and Addresses« von Tim Berners-Lee [BERN96A].

IP4W3 führt keine mutwillige Änderung von URLs durch. Das heißt, wenn das System keine Veränderung von außen erfährt, sind die von IP4W3 erzeugten URLs auch in Zukunft gültig. Zwei Probleme gibt es aber:

• Die von IP4W3 erzeugte Seite ist üblicherweise in einen Frame eingebettet. Setzt man einen Link auf den oberen Frame, der die gewünschte Seite enthält, so fehlt der untere Frame mit der Steuerung. Das Problem besteht darin, daß der Schalter »Ausschnitt merken« nur funktioniert, wenn der untere Frame existiert. Das Problem wird abgeschwächt, wenn der URL benutzt wird, den man erhält, wenn man in der Steuerung den Link »Gemerkte Ausschnitte zeigen« benutzt. In diesem Fall sind in dem generierten Dokument keine Formularfelder mehr enthalten.
• Das zweite Problem tritt auf, wenn am Ausgangsdokument Änderungen gemacht werden. Sobald sich dadurch die Numerierung der Elemente verändert, sind URLs, die sich auf den ehemaligen Zustand beziehen, ungültig, weil in ihnen veraltete Elementnummern enthalten sind.

7.4 Erweiterungen und Änderungen

7.4.1 Wertebereiche in Formularen

Als zulässige Wertebereiche in Textfeldern von Formularen habe ich beliebig, buchstaben und posinteger zugelassen. Ich verstehe diese Bereiche nur als exemplarische Implementation, da sich in der späteren Anwendung herausstellen muß, welche Wertebereiche tatsächlich benötigt werden. Aus diesem Grund habe ich auf eine einfache Erweiterbarkeit geachtet. Sollte also Bedarf für weitere Wertebereiche bestehen, so sind folgende Änderungen durchzuführen.

Änderung der Suchmuster-DTD

In der Suchmuster-DTD sind die Wertebereiche als zulässige Attributwerte aufgezählt ⁴⁰. Die Erweiterung ist problemlos möglich, alle älteren Instanzen bleiben auch bezüglich der veränderten DTD gültig. Es ist nicht notwendig, den Public Identifier (PID) der DTD zu ändern. Bei einer Entfernung eines Wertebereichs werden natürlich alle Suchmuster-Instanzen ungültig, die diesen Bereich benutzen. In diesem Fall sollte eine neue DTD mit einem neuen PID erzeugt werden.

Erweiterung der JavaScript-Bibliothek

Die Überprüfung der Wertebereiche wird von der Funktion pruefe_wert() durchgeführt. Bei der Einführung neuer Wertebereiche muß die Funktion angepaßt werden. Sie erhält den Namen des Wertebereichs als Zeichenkette in Großbuchstaben beim Aufruf übergeben.

7.4.2 Druckausgabe mit DSSSL

Um eine Druckausgabe mit IP4W3 zu realisieren, muß zu jedem Dokument ein passender DSSSL-Rahmen vorhanden sein. Dies ist eine Anforderung an den Administrator, nicht an das System. IP4W3 muß dem Benutzer erlauben, ein anderes Ausgabeformat als HTML, z.B. RTF, PostScript usw., zu wählen. Hierfür bietet es sich an, ein Formularelement zur Auswahl vom DSSSL-Rahmen ausgeben zu lassen (format.dsssl). Das ausgewählte Format muß vom CGI-Skript (preview.pl) erkannt und beim Zusammensetzen des Rahmens und des Rumpfes berücksichtigt werden.

7.5 IP4W3 und Hypertext

Wie in der Einleitung beschrieben, habe ich den Hypertextansatz in IP4W3 zurückgestellt, um stattdessen ein Dokument aus Ausschnitten zusammenzusetzen. Ich möchte nun nicht den grundsätzlichen Ansatz in Frage stellen. Die Überschrift dieses Abschnitts erweckt vielleicht den Eindruck einer Grundsatzdiskussion über das Konzept des Hypertextes. Zweifellos sind die Ideen in der Tradition von Bush [BUSH45], Engelbart (z.B. [ENGE62]) und Nelson (Xanadu-Projekt) noch längst nicht angemessen realisiert, jedoch ist hier nicht der Platz, sie zu diskutieren. Vielmehr möchte ich an dieser Stelle auf einige offene Fragen hinweisen, die sich in Verbindung von IP4W3 mit der (bescheideneren) Form des Hypertextes stellen, die heute im World Wide Web Realität ist oder in Kürze sein wird.

Wie sind externe Links zu handhaben?

Bei meiner Arbeit konnte ich die Handhabung von externen Links ignorieren, da IP4W3 keine solchen Verknüpfungen herstellt. Der Autor eines DSSSL-Rahmens ist dazu aber durchaus in der Lage. Ein naheliegender Ansatz wäre, einen HTML-Link mit dem Attribut target="_top" auszustatten, um aus dem Frameset von IP4W3 auszubrechen.

Wie sind interne Links zu handhaben?

Dokumentinterne Links gehen in HTML davon aus, daß das Dokument nur eine statische HTML-Seite umfasst. Da IP4W3-Seiten aber dynamisch, als Ergebnis einer Suche, generiert, sind interne Links in der bekannten Form nicht möglich.

Welche Möglichkeiten werden die neuen XLinks für IP4W3 bieten?

Momentan arbeitet das W3C an einem gegenüber HTML stark erweiterten Link-Konzept. Es ist zu prüfen, ob die zukünftigen Möglichkeiten Nutzen für IP4W3 bieten.

7.6 Lernen aus Benutzerverhalten

IP4W3 wurde mit der Idee entworfen, daß das System im Rahmen einer weiteren Diplomarbeit ergänzt wird, um aus dem Verhalten des/der Benutzer zu lernen. Bei der dadurch zu erzielenden Verbesserung kann es sich zum Beispiel darum handeln, welche Treffer zu einer Suchanfrage in welcher Reihenfolge zurückgeliefert werden. Treffer, die in der Vergangenheit als »richtige« Treffer angesehen wurden, könnten bei einer neuen Suchanfrage als erste in der Trefferliste erscheinen. Eine weitere Verbesserung betrifft die Ermittlung der Atome. Es ist nicht ausgeschlossen, daß die auf Grundlage der DTD definierten Atome nicht bei allen Instanzen der DTD für optimale Ergebnisse sorgen. Der Benutzer wird dies dadurch kompensieren, daß er die gelieferten Atome verwirft oder den Ausschnitt vergrößert. Dieses Verhalten kann benutzt werden, um bei der nächsten Suche »bessere« Atome zurückzuliefern. Letzlich kann man die genannten Ansätze auf jeden Benutzer individuell anwenden oder man kann die Menge aller Benutzer gemeinsam behandeln. Dahinter stünde die Annahme, daß zwei verschiedene Benutzer die gleichen Wünsche bezüglich der Trefferliste und der Atome haben.

Ich möchte hier zwei Punkte besprechen, die zur technischen Umsetzung nötig sind:

Logging des Benutzerverhaltens

Da Web-Transaktionen zustandslos sind, muß man selbst dafür sorgen, nacheinander eintreffende Anfragen an den Webserver eindeutig einem Benutzer zuzuordnen. Zu diesem Zweck bietet es sich an, jedem Benutzer eine eindeutige ID zu geben. Es stehen zwei Möglichkeiten zur Verfügung: Kodierung der ID in versteckte Formularfelder (etwa <input type="hidden" value="xyz" name="UID">). Dazu müßte jedes Formular dynamisch generiert werden. Die betroffenen Komponenten von IP4W3 sind search.pl, preview.pl und format.dsssl. Die Alternative besteht in der Verwendung von Cookies. Dazu wird dem Benutzer beim Einstieg in das System eine ID als Cookie gegeben, die der Browser speichert und bei Zugriff auf vordefinierte Adressen wieder an den Server schickt. Der erste Cookie sollte dann von search.pl vergeben werden.

Was ist ein Endergebnis?

Wenn man versucht, eine Beziehung zwischen der ursprünglichen Anfrage und dem Endergebnis herzustellen, stellt sich die Frage, was ein Endergebnis ist beziehungsweise wie man es erkennt? Abstrakt kann man sagen: Das Endergebnis ist das Dokument, das der Benutzer als angemessene Antwort auf seine Suchanfrage ansieht. Da man nicht erkennen kann, ob der Benutzer das System irgendwann frustriert und erfolglos verlassen hat, ist es nicht unbedingt sicher, daß die letzte betrachtete Seite die gewünschte war. Es bietet sich jedoch an, die Dokumentausschnitte, die sich der Benutzer gemerkt hat, als gutes Ergebnis anzusehen. IP4W3 bekommt diese Information, wenn der Benutzer auf »gemerkte Ausschnitte zeigen« klickt. Dann nämlich wird das Skript preview.pl mit dem CGI-Parameter keinesteuerung=true aufgerufen (was dafür sorgt, daß die unschönen Formularelemente verschwinden). Da es nicht ausgeschlossen ist, daß ein Benutzer diesen Link mehrfach anklickt, sollte der letzte Zugriff gewertet werden.

7.7 Trennung von Suchmustern und Atomen

Konzeptionell unterscheide ich zwischen Suchmustern und Atomen. In der Implementierung werden Atome jedoch direkt aus Suchmustern abgeleitet. Die Praxis muß zeigen, ob ein komplexerer Atombegriff notwendig ist und ob dieser dann von den Suchmustern abweicht, oder ob diese mitwachsen.

Ein Beispiel für die Differenzierung beider Begriffe sei genannt: Es soll in einer Sammlung von Briefen die Suche nach dem Namen des Adressaten möglich sein. Das Resultat einer Suche soll aber weder der Name noch die Adresse des Empfängers sein, sondern der Brieftext, der an ihn geschickt wurde. Die Struktur eines Briefes sehe so aus:

<brief>
 <absender>...</absender>
 <adressat>...</adressat>
 <text>...</text>
</brief>

Das Suchmuster zu definieren, ist problemlos möglich. Jedoch ist das gewünschte zugehörige Atom (text) kein Nachfahre und auch kein Vorfahre des Suchmusters, so daß es in der Suchmuster-Definition gar nicht vorkommt.

Ob dieses Szenario realistisch ist und ob es wirklich ein Problem darstellt, ist sicher diskussionswürdig. Eine naheliegende Lösung für das Beispiel wäre es sicher, den gesamten Brief als Ergebnis zurückzuliefern. Es ist nicht ganz unwahrscheinlich, daß der Benutzer von einem Suchergebnis verwirrt wäre, in dem der Suchbegriff gar nicht vorkommt. Die Verknüpfung beider Konzepte über den Suchvorgang in IP4W3 spricht nach meiner Auffassung gegen eine Trennung von Suchmustern und Atomen. Die Situation könnte sich ändern, sobald Web-Browser die neuen, erweiterten Hyperlinks XLink und XPointer unterstützen. Mit XPointern lassen sich Dokumentstellen ähnlich adressieren, wie es momentan implizit durch Atome in IP4W3 geschieht. Mit einer Unterstützung durch die Browser könnte der Suchvorgang von IP4W3 in Zukunft Hyperlinks (verschiedene Ausprägungen von XLinks) als Ergebnis liefern, wobei die Atome als XPointer realisiert wären. Diese Idee bietet einen Ansatz, IP4W3 mit einem Hypertextkonzept zu verbinden.

Als konkreten Einstieg möchte ich mit der folgenden Tabelle noch zeigen, wie IP4W3-Atome (als Suchmuster ausgedrückt) in XPointer umgewandelt werden können. Die Abbildung ist nicht vollständig, da ich mich auf die Struktur beschränkt habe. Daher habe ich nur Elemente ohne ihre Attribute betrachtet. Elemente lassen sich mit einem Tiefendurchlauf mit CoST transformieren. Jedesmal, wenn ein Element abgearbeitet ist, d.h. bei Erreichen des End-Tags, findet eine Ausgabe gemäß der Tabelle 4 statt.

Alle Elementtypen der Suchmuster-DTD, die nicht in der Tabelle aufgeführt sind, können bei der Umwandlung ignoriert werden (abgesehen von attribute, wie oben erwähnt), da sie keinerlei Bedeutung für das Atom haben.