Verglichen mit dem OSI-Referenzmodell, das als universelles Beschreibungsmodell für Netzwerk-Protokollstapel oft zum Vergleich herangezogen wird, fallen einige wichtige Unterschiede auf: Als erstes fällt die unterschiedliche Anzahl der Schichten auf. Während das OSI-Modell sieben Schichten aufweist, hat das TCP/IP-Modell nur fünf. Zwar haben beide Modelle je eine Vermittlungs- (beim TCP/IP-Modell heißt sie Internetschicht), eine Transport- und eine Verarbeitungsschicht, doch der Rest der Protokollstapel ist nicht direkt vergleichbar. In einer Gegenüberstellung der beiden Modelle wird der für das Navigations- und Orientierungsproblem im WWW relevante Unterschied[23] hervorgehoben:
"Ein weiterer Unterschied liegt in der verbindungslosen gegenüber der verbindungsorientierten Kommunikation. Das OSI-Modell unterstützt auf der Vermittlungsschicht sowohl die verbindungslose als auch die verbindungsorientierte Kommunikation, auf der Transportschicht jedoch nur die vermittlungsorientierte, weil das dort wichtig war (da der Transportdienst für die Benutzer sichtbar ist). Das TCP/IP-Modell hat in der Vermittlungsschicht nur einen Modus (verbindungslos), unterstützt auf der Transportschicht aber beide Modi, so daß der Benutzer eine Wahl hat. Diese Wahl ist besonders für einfache Anfrage/Antwort-Protokolle wichtig." [Tannenbaum, 1997, S. 56]Festzuhalten ist vor allem, daß die Transportanbieter (das sind die unteren Schichten bis zur Transportschicht) ausdrücklich sowohl eine verbindungslose als auch eine verbindungsorientierte Kommunikation unterstützen, was zu einer einfacheren und effizienteren Implementation der anwendungsorientierten Protokolle in der Verarbeitungsschicht führt. Entsprechend können sich die höheren Protokolle je nach Datenmenge für eine Verbindungsart entscheiden: Für kleine Datenmengen ist eine verbindungslose, während für große Datenmengen eine verbindungsorientierte Kommunikation effizienter.
Andere Unterschiede zwischen den beiden Modellen, wie etwa die Tatsache, daß im TCP/IP-Modell nicht zwischen einer Bitübertragungs- und einer Sicherungsschicht unterschieden wird, oder daß die Netz-Host-Schicht eigentlich keine Schicht, sondern vielmehr eine Schnittstelle zwischen dem darunterliegenden Netz (die Hardware) und den darüberliegenden Sicherungsschichten ist, deuten zwar auf Designschwächen hin, werden aber in den Implementierungen durch die Funktionalität der jeweils höheren Schichten aufgefangen. Daß im TCP/IP-Modell die Sitzungs- und Darstellungsschicht völlig fehlen, wird von Tannenbaum nicht als Nachteil angesehen, weil die Erfahrungen mit dem OSI-Modell bestätigt haben, daß in den meisten Anwendungen diese beiden Schichten nicht gebraucht werden [Tannenbaum, 1997, S. 52].
Die Verarbeitungsschicht umfaßt alle anwendungsorientierten Protokolle, wie Telnet, FTP, SMTP[24], DNS[25] oder HTTP[26]. Im WWW wird das HTTP-Protokoll eingesetzt.
Die Anfragen des Clients sind einfache ASCII-Zeilen und die Antwort des Servers fängt ebenfalls mit ASCII-Zeilen an (der sogenannte Header), gefolgt von den tatsächlich angeforderten Daten, die wiederum ASCII oder binär sein können. Die brauchbare Darstellung des erhaltenen Dokuments obliegt der Client-Software (Browser). Hier wird das Dokument sichtbar gemacht und die enthaltenen Links auf plattformtypische Weise hervorgehoben, z.B. durch Unterstreichen, Fett- oder Kursivdarstellung, durch farbliche Markierung oder eine Kombination mehrerer Methoden.
Eines der Probleme von HTTP liegt in der Benutzung jeweils einer TCP-Verbindung pro Datei. So werden z.B. für die Übertragung einer WWW-Seite mit fünf Bildern sechs TCP-Verbindungen aufgebaut. Dies ist vor allem für den Transfer von kleinen Datenmengen geeignet; dagegen können viele gleichzeitige Anfragen für große Dateien (z.B. ein umfangreiches Dokument mit mehreren großen Bildern) durch viele langanhaltende Prozesse die Leistung des WWW-Servers reduzieren. Ein anderes Problem ist das Beenden einer TCP-Verbindung, das normalerweise vom Server durch ein TIME_WAIT-delay initiiert wird. Bei einem Server mit hohem Datenverkehr kann dies zu einer Ansammlung von TIME_WAITs führen, was die Leistung des Servers beeinträchtigt.
Mit den Vorschlägen zur HTTP-Version 1.1 sollten einige dieser Schwächen behoben werden. Darunter fallen z.B. die Authentifikation (Verbindungsaufbau schneller), persistente TCP-Verbindungen (Nutzdatenübertragung effizienter) und das Verhandeln der zu übermittelnden Inhalte zwischen Client und Server (um sicherzustellen, daß der Client die Daten richtig darstellen kann). Anzumerken wäre noch, daß alle Übersichten und Statistiken zum HTTP-Datentransfer ursprünglich nur verbindungs-, aber nicht sitzungsorientiert sind, da der Server keine Möglichkeit hat, die Anfragen des Clients anders als über die TCP/IP-Nummer zu unterscheiden. Durch Einsatz komplexer Algorithmen versucht man diese Unzulänglichkeit auszugleichen und sitzungsorientierte Daten für Auswertungen[27] bereitzustellen.
Das Performanzproblem von HTTP wird durch die Inkompatibilität zwischen der byteorientierten TCP-Verbindung und dem nachrichtorientierten HTTP-Service bedingt, was unnötig viele Anpassungsschritte nach sich zieht. Als ideale Lösung für dieses Problem schlägt Stevens eine Sitzungs-Zwischenschicht vor, die auf dem TCP-Protokollstapel aufsetzt:
A fundamental problem with HTTP is a mismatch between the byte-oriented TCP stream and the message-oriented HTTP service. An ideal solution is a session-layer protocol on top of TCP that provides a message-oriented interface between an HTTP client and server over a single TCP connection. [Stevens, 1994, S. 175]Man bezeichnet das HTTP-Protokoll als stateless, weil der Server keine Statusinformationen über die Anfragen der Clients speichern kann. In manchen Situationen, wie z.B. das Beibehalten der Sitzungseinstellungen, die kontextsensitive Reaktion des Servers auf Benutzeraktionen und vor allem bei Transaktionen ist es sehr wichtig, daß der Server über Statusinformationen zu früheren Anfragen eines Clients verfügt. Es gibt unterschiedliche Ansätze, um dieses schwerwiegende HTTP-Problem anzugehen. Eine Lösung des Problems würde einerseits den nötigen Datentransfer in vielen Fällen verringern, andererseits für den Benutzer ein deutliches Plus an Sicherheit und Benutzungsfreundlichkeit in der WWW-Orientierung und –Navigation bedeuten. Einige eingesetzte Techniken, mit denen Statusinformationen erhalten werden können, sind HTML-Forms, Netscape cookies oder Dynamic Argument Embedding.
Die einfachste Methode zur Erhaltung von Statusinformationen bieten die HTML-Forms, die Teil des HTML-Sprachumfangs sind. Hier antwortet der Server auf die Anfrage des Clients mit einer dynamisch erstellten HTML-Seite, in die für den Benutzer unsichtbar Variablen eingebettet sind. Diese Variablen werden zusammen mit der nächsten Anfrage des Clients an den Server zurückgeschickt, der sie mit der nächsten Antwort erneut an den Client schickt. Dies funktioniert allerdings nur, solange der Client die Konversation mit dem betroffenen Server aufrechterhält. Sobald der Client aber Daten von einem anderen Server abruft, geht die Statusinformation verloren. Aufgrund dieser Einschränkung ist die Erhaltung der Statusinformation über HTML-Forms für viele Anwendungen nicht geeignet.
Eine andere Methode zur Erhaltung von Statusinformationen sind die sogenannten cookies, die von der Firma Netscape Communications Corp. eingeführt wurden und die nicht die oben genannten Nachteile der HTML-Forms aufweisen. Allerdings setzt der Einsatz von cookies nicht-standardisierte Erweiterungen voraus sowohl beim Client als auch beim Server. Ein Server kann mit der Antwort auf eine Client-Anfrage ein cookie mitschicken. Dabei handelt es sich um eine Datenstruktur, die auf dem Client-Rechner physikalisch gespeichert wird und die außer den statusbeschreibenden Variablen auch eine Liste der URLs enthält, an die die Statusinformationen im Falle einer Konversation gesendet werden dürfen und sollen. Außerdem kann auch durch ausdrückliche Angabe des Datums und der Uhrzeit die Lebensdauer des cookies eingeschränkt werden. Wenn diese Daten fehlen, werden die cookies beim Beenden der aktuellen Arbeitssitzung des Browsers automatisch gelöscht.
Dynamic argument embedding (DAE) ist eine allgemeine Methode, um im WWW-Datenverkehr Statusinformationen zu erhalten und wurde im Thomas J. Watson Research Center der Firma IBM unter der Leitung von Arun Iyengar [Iyengar, 1997] entwickelt. DAE benötigt keine Erweiterungen des HTTP-Protokolls. Beim DAE wird der Status mit dem Begriff Konversation assoziert. Darunter versteht man die Verbindung eines Clients mit einem oder mehreren Servern und den Abruf beliebiger WWW-Seiten über Hyperlinks (also nicht durch direkte URL-Eingabe im Browser) von diesen Servern. Das Prinzip von DAE ist die dynamische Modifizierung der Hyperlinks, um die Statusinformationen einzubetten. Dies wird mittels zweier Programme (die argument embedder) erreicht, die die Statusvariablen an die Hyperlinks anfügen bzw. die vom Client zurückerhaltenen Statusvariablen an den Server übergeben. Die beiden argument embedder rufen sich gegenseitig auf. Die Initialisierung dieses zyklischen Prozesses wird von einem CGI-Skript vorgenommen. Dadurch stellt man sicher, daß die Statusinformationen mit jeder Anfrage von und zum Server geschickt werden.
Um den Datenverkehr zwischen dem Client und dem Server einzuschränken, wäre es möglich, die meisten Statusvariablen in einer Datenbank auf dem Server zu speichern und nur einen Index als Statusträger zwischen Server und Client zu schicken. Alternativ könnte man durch Einsatz einer Sprache wie Java die Statusvariablen in einer Datenbank auf dem Client speichern. Ebenfalls könnte man Java dazu benutzen, um den argument embedder vom Server herunterzuladen und auf dem Client auszuführen, was den Server erheblich entlasten würde. Ein anderer Vorteil wäre, daß beim Einsatz von Java der Client bezüglich der Statusinformation nicht mehr vom Server abhängt und die Möglichkeit hat, auch Konversationen fortzuführen, in denen wegen Leitungs- oder Hardwarefehlern die Verbindung zum Server unterbrochen wurde.
Aus der obigen Vorstellung der HTML-Forms, cookies und DAE wird ersichtlich, daß die statuserhaltenden Mechanismen wichtige Erweiterungen von HTTP sind. Im Vergleich zwischen cookies und DAE schneidet DAE trotz einiger Performanzprobleme etwas besser ab: Es bietet dem Programmierer eine einfache Variablenübergabe und eine höhere Sicherheit, daß die Statusvariablen übergeben werden, weil dafür keine unstandardisierten Erweiterungen erforderlich sind und die Browser die WWW-Seiten mit DAE-Statusinformationen nicht ablehnen können, wie dies bei cookies der Fall ist. Cookies haben sich auch deshalb durchgesetzt, weil sie sehr einfach einzusetzen sind.
Als man Anfang der 90er Jahren eine einfache Seitenbeschreibungssprache für das WWW entwickeln mußte, entschied man sich, diese an das vorhandene SGML anzulehnen. Außerdem wurde die DTD für HTML-Dokumente in SGML geschrieben. Dabei wird hier der Begriff "Seitenbeschreibungssprache" wirklich sehr eingeschränkt benutzt, da HTML entsprechend den damaligen Vorgaben nur einen Bruchteil der Möglichkeiten von SGML bietet.
HTML-Dokumente bestehen immer aus zwei Teilen, dem Inhalt und den Formatierungsanweisungen. Konkret sind dies zum einen der Text des Dokumentes und die anderen Dateien, z.B. Bilder, Videos, Tondateien usw., die vom Browser (evtl. mit Hilfe von Erweiterungen) dargestellt werden, und zum anderen die Befehle, die sogenannten HTML-Tags[28]. Mit den HTML-Tags werden sowohl das Erscheinungsbild als auch die logische Struktur des Dokuments beschrieben. Die Umsetzung in das, was der Benutzer letztendlich auf seinem Bildschirm sieht, erfolgt durch den Browser. Erst hier wird das Dokument entsprechend den Besonderheiten der Zielplattform so formatiert, daß das Erscheinungsbild auf allen Plattformen und Betriebssystemen möglichst gleich aussieht. Wegen der Universalität dieses Konzeptes wurde HTML des öfteren als eine Art Esperanto der IT-Branche gehandelt.
Die HTML-Tags werden in spitze Klammern eingeschlossen und treten –
bis auf wenige Ausnahmen – immer paarweise auf, um den Anfang und das Ende
der Anweisung zu markieren. Man unterscheidet zwei Arten von Tags: Die
eine Kategorie gibt an, welchen Platz innerhalb der Struktur eines Dokumentes
ein Element einnimmt.
Beispiel: Der HTML-Tag <H1>Zeichenfolge</H1> gibt an, daß
es sich bei "Zeichenfolge" um eine Überschrift erster Stufe handelt.
Dadurch wird eine logische Auszeichnung innerhalb des Dokuments vorgenommen.
Gleichzeitig werden die dazugehörenden Formatanweisungen zugewiesen,
die Browser- und Plattform-spezifisch sind. Die zweite Kategorie erlaubt,
den Elementen eines Dokumentes konkrete oder feste Formatierungen wie Schriftart
und –größe zuzuweisen. Beispiel: Der HTML-Tag <B>Zeichenfolge</B>
teilt dem Browser mit, daß "Zeichenfolge" in Fettdruck ("bold") dargestellt
werden soll.
Damit sind die prinzipiellen Möglichkeiten von HTML bereits ausgeschöpft. Zwei Schwächen werden HTML angelastet: Es bietet nicht ausreichend umfangreiche und genaue Formatierungsmöglichkeiten für die Elemente eines Dokumentes, und es unterstützt kaum eine inhaltliche Strukturierung der Dokumente. Allerdings eignet sich HTML vorzüglich für die Präsentation einfach gestalteter Dokumente im WWW, was der Entwurfsvorgabe dieser Auszeichnungssprache entspricht.
Durch die Einführung von Erweiterungen wie style sheets – das sind selbsterstellte Vorlagen für bestimmte Layouts in HTML – konnte die Formatierschwäche teilweise aufhoben werden. Layouter werden aber nach wie vor die Feinheiten des DTP-Designs nicht in HTML umsetzen können.
Schwerwiegender für das in dieser Arbeit untersuchte Gebiet der Orientierung und Navigation im WWW ist das Fehlen geeigneter Mechanismen zur Unterstützung der inhaltlichen Dokumentenstruktur in HTML, was sich u.a. auf die Dokumenten-Suche oder auf die Möglichkeiten, Dokumente inhaltsbezogen zu formatieren, auswirkt. Eine Lösung für die bessere Struktur-Auszeichnung von Dokumenten soll die neue Seitenbeschreibungssprache XML bereitstellen.
Im November 1996 legte das World Wide Web Consortium (W3C) einen ersten Entwurf[29] für die Syntax einer neuen Seitenbeschreibungssprache vor: die eXtensible Markup Language[30] (XML). Aktuell ist die Empfehlung des W3C zu XML 1.0 vom 10.02.1998, die noch nicht endgültig verabschiedet wurde. In XML wurden die wichtigsten Konzepte von SGML implementiert; weggelassen wurden nur solche Konstrukte, die weniger gebräuchlich oder sehr kompliziert sind.
Als wichtigste Neuerung von XML gegenüber HTML gelten die semantischen
Tags, mit denen man Aussagen über den Inhalt von Dokumenten machen
kann.
Beispiel: Der XML-Tag <Fach>Informatik</Fach> sagt etwas über
die Bedeutung der Zeichenfolge "Informatik" aus. Semantische Tags lassen
sich zu komplexen Datenstrukturen verschachteln, ähnlich den Records
in Programmiersprachen. So können auch sehr aussagekräftige Strukturen
gebildet werden wie z.B.:
<Diplomarbeit>
<Titel>Lost in History</Titel>
<Autor>Sigrid Bumann, Sandi Bilinski</Autor>
<Fach>Informatik</Fach>
</Diplomarbeit>
dessen Bedeutung sofort einleuchtet. Außerdem bieten die semantischen Tags die Möglichkeit, Dokumente maschinell auf ihre inhaltliche Struktur zu untersuchen:
Tags dieser Art sind eine ungemein simple Angelegenheit. Sie sind so dermaßen simpel, daß sie auch Maschinen zugemutet werden können. Und darum geht es. [Dünhölter, 1998, S. 2]Die XML-Spezifikation sieht keine Einschränkungen für diese Art von Tags vor, es wird nur deren Syntax festgelegt. Das bedeutet, daß jeder Entwickler von WWW-Seiten solche Tags in seine Dokumente einbauen kann, und auch daß jeder, der diese Tags kennt, sie zur elektronischen Verarbeitung der Dokumente heranziehen kann. Es können und werden dadurch viele XML-Dialekte entstehen, die sich von Firma zu Firma oder von Branche zu Branche unterscheiden werden.
Die Vielfalt der XML-basierten Auszeichnungssprachen wird durch eine andere Eigenschaft von XML ermöglicht: Jedes Dokument kann seine eigene DTD zum Client-Browser mitbringen oder auf eine passende DTD im Internet verweisen. Es reicht also, daß der Browser die DTD mit den neuen Tags einmal einliest, um mit allen Dokumenten, die diese Tags einsetzen, umgehen zu können. Es soll sogar möglich sein, Dokumente ohne vorhandene DTD im Browser darzustellen. Dazu wird die Dokument-Struktur beim Einlesen geparst – wenn das Dokument mindestens "wohlgeformt" ist, also einer Mindestanzahl von Regeln entspricht. XML stellt also sehr einfache Mechanismen zur Verfügung, um die Informationen zu strukturieren.
Die Daten, die mit XML-Dokumenten geliefert werden, stehen von ihrer Strukturiertheit her zwischen den (üblicherweise in hohem Maße strukturierten) Datenbank-Daten einerseits und den unstrukturierten Textdaten andererseits. [Dünhölter, 1998, S. 5]Eine weitere wichtige Eigenschaft von XML ist, daß es in den Dokumenten mit sogenannten Entitäten arbeiten kann. Entitäten sind die Informationseinheiten, aus denen ein Dokument besteht. Dadurch wird eine feinere Gliederung der Dokumente erreicht. Zusätzlich kann im Dokument oder in der DTD zu einer Entität angegeben werden, wo sie sich physikalisch befindet, wobei der Ort auch durch eine URL spezifiziert werden kann. Diese Eigenschaft macht es möglich, in einem Dokument Informationen aus anderen Dokumenten darzustellen, z.B. um zu zitieren. Dadurch ermöglicht das WWW, einige der von Ted Nelson mit seinem Projekt Xanadu verfolgten Ideen umzusetzen.
XML ist nicht darauf ausgerichtet, HTML im WWW zu ersetzen, sondern zu ergänzen: HTML wird eingesetzt, um festzulegen, wie ein Dokument auf dem Bildschirm des Clients dargestellt werden soll. Dies wird auch weiterhin die einfachste Möglickeit sein, Informationen im WWW bereitzustellen. Dagegen werden XML-basierte Auszeichnungssprachen eingesetzt, um Informationen über die inhaltliche Struktur der Dokumente zu liefern, so daß diese elektronisch weiterverarbeitet werden können.
In XML wurde – entsprechend dem SGML-Modell – die Strukturierung vollständig von der Formatierung getrennt. Da XML aber von Anfang an mit style sheets zusammenarbeitet, könnte es langfristig Vorteile auch für Layouter bieten. Es ist denkbar, daß man in den style sheets Angaben für die neuen XML-Tags machen kann, genauso wie man es z.Zt. für die vorhandenen HTML-Tags macht. Außerdem ist die Nachfolgetechnologie zu den style sheets – eine Formatvorlagen-Sprache namens eXtensible Style sheet Language (XSL) – beim W3C bereits in Entwicklung[31] und soll die stark erweiterten Möglichkeiten von XML berücksichtigen.
Die Protokolle TCP und IP sind für das Zustandekommen von sicheren Verbindungen verantwortlich. Dabei unterstützen sie sowohl eine verbindungslose als auch eine verbindungsorientierte Kommunikation. Dies ermöglicht eine effiziente Implementation der Protokolle in der Anwendungsschicht, denn je nach Bedarf kann für kleine Datenmengen die verbindungslose, für große Datenmengen die verbindungsorientierte Kommunikation gewählt werden. Leichte Designschwächen des TCP/IP-Modells im Vergleich zum OSI-Modell können durch die Funktionalität der darüberliegenden Anwendungsschicht aufgefangen werden. TCP/IP besticht durch eine effiziente Umsetzung und seine universale Verfügbarkeit über alle Hard- und Software-Plattformen hinweg.
Das HTTP-Protokoll ist das im WWW eingesetzte Protokoll zum Übertragen von Dokumenten. Es setzt auf dem TCP/IP-Stapel auf. Bei der Übertragung von Daten wird für jede Datei eine TCP-Verbindung angefordert, was den Overhead erhöht. Diese Verbindungsart ist zudem für kleine Datenmengen optimiert; bei WWW-Seiten mit vielen großen Grafiken wird die Leistung des Servers reduziert. Das Problem der Performanz ist in der Inkompatibilität zwischen der byteorientierten TCP-Verbindung und dem nachrichtenorientierten HTTP-Service begründet, was unnötig viele Anpassungsschritte erfordert.
Eine weitere Schwäche von HTTP ist das Fehlen von Mechanismen, mit denen der Status einer Verbindung beibehalten werden kann. Dies ist aber gerade aus Sicht der Benutzbarkeit wichtig: Benutzer könnten unterschiedliche Rechte auf Informationen haben, der Sitzungs-Endstand und die Spracheinstellungen könnten gesichert werden und beim nächsten Aufruf automatisch wiederhergestellt werden. Unverzichtbar sind Statusinformationen aus Sicherheitsgründen für Online-Transaktionen; hier werden sie mühsam nachgebildet. Einige Hersteller versuchen diese Lücke durch zusätzliche Mechanismen wie Netscape cookies oder Dynamic Argument Embedder (IBM) zu schließen.
HTML ist die Seitenbeschreibungssprache des WWW. Bei der Übertragung eines Dokumentes im HTML-Format werden die Inhalte von den Formatieranweisungen getrennt, was zur Universalität des Konzeptes führt. Wegen der beschränkten Layout-Fähigkeiten von HTML müssen Designer mit Einschränkungen in den Gestaltungsmöglichkeiten leben. Als problematischer erweist sich das weitgehende Fehlen von Möglichkeiten zur Beschreibung der inhaltlichen Struktur von Dokumenten. Dies ist teilweise die Ursache für die Schwierigkeiten der Benutzer, gewünschte Informationen im WWW zu finden. Suchmaschinen können zwar Dokumente vollständig nach gesuchten Stichwörtern durchscannen, aber das Ergebnis ist meistens unbefriedigend, denn letztlich muß der Benutzer selbst entscheiden, ob der Kontext, in dem ein Stichwort erscheint, für seinen Bedarf geeignet ist. Unüberschaubar große Suchergebnisse sind leider keine Ausnahmen.
Um die Schwächen von HTML auszugleichen, wurde vom W3C eine neue,
auf SGML basierte Beschreibungssprache XML entworfen. Diese soll nicht
HTML ersetzen, sondern ergänzen. Eine neue Eigenschaft von XML ist
die Einführung der semantischen Tags, mit denen inhaltliche Auszeichnungen
von Dokumenten vorgenommen werden können. Damit wird es erstmals möglich
sein, Dokumente inhaltsbezogen zu strukturieren und zu formatieren, was
zu einer verbesserten Visualisierung und damit auch Benutzbarkeit von Informationen
führen wird. Außerdem enthält XML die nötigen Konzepte,
um die darauf basierenden Sprachen zu erweitern. Dadurch wird es in Zukunft
viele Sprach-Erweiterungen geben, mit denen Dokumente noch genauer beschrieben
werden können.
| Inhaltsverzeichnis | nächstes Kapitel | Literaturverzeichnis |