* Nils Ketelsen:
>> > Ich halte einen Link (wie auch einen Literaturverweis) weiterhin
>> > nur fuer einen Hinweis auf die bereits existierende
>> > Zugaenglichkeit.
>> Auch wenn das Dokument erst erzeugt wird, basierend auf den Daten im
>> URL?
>
> Ja. Auch dann ist der gleiche Inhalt zugaenglich, wenn man (zum Beispiel)
> den URL am Telefon vorgelesen bekommt und von Hand in den Browser eingibt.
Ich meinte, da� der URL allein die wesentliche Quelle f�r die
Erstellung der Seiten ist. Technisch ist das ja kein Problem, auch
wenn ich solche URLs wegen der L�nge lieber nicht am Telefon vorlesen
w�rde.
> Zugaengig macht den Inhalt, wer ihn auf den Webserver verbringt. Ob
> er aus einer statischen Datei besteht oder aus einem cgi erzeugt
> wird macht nun wirklich keinen Unterschied.
Was ist mit Angeboten, die vom Betreiber pa�wort gesch�tzt wurden?
Wenn ich eine URL weitergebe, in der eine Session-ID enthalten ist,
bekomme ich bei Deiner Auffassung erhebliche Bauchschmerzen.
> Ich glaube es ist ganz gut moeglich. Zumindest, solange man nicht
> mit Gewalt obskure Sonderfaelle kontruiert.
Obskure Sonderf�lle? Mir fallen eine ganze Reihe von unterschiedlichen
Funktionen ein, die Links inzwischen wahrnehmen.
Die klassische Aufgabe eines Links in einem Hypertext-Dokument besteht
darin, dem Leser eine direkte Zugriffsm�glichkeit auf das verlinkte
Dokument zu geben. Indirekt ist damit also durchaus eine Aufforderung
zum Lesen des Dokumentes gegeben.
Manchmal werden Links verwendet, um eine bestimmte Resource zu
benennen, ohne da� damit eine Aufforderung verbunden ist, sich die
Inhalte dort anzueignen. Beispiele daf�r sind Fehlerbeschreibungen
("ich kann nicht mehr auf http://www.google.de/ zugreifen,
http://www.google.com/ funktioniert aber"), Sperrverf�gungen oder
Zugriffstatistiken von Webservern.
Ein Link kann auch in einem klassischen Literaturverweis auftauchen,
um die Belegstelle f�r ein Zitat zu liefern. Dies ist sicherlich keine
Aufforderung an den Leser, das Zitat an der angegebenen Stelle
nachzulesen (und wird auch regelm��ig nicht so verstanden), sondern
geh�rt einfach zum seri�sen wissenschaftlichen Arbeiten dazu: Quellen
sind zu referenzieren. Klassische URLs werden daf�r i.a. als
unzureichend betrachtet und ggf. durch zus�tzliche Beschreibungen wie
das Datum des letzten Zugriffs erg�nzt.
Links innerhalb einer Web-Anwendung sind zum Teil automatisch erzeugt.
Sie halten quasi die Web-Anwendung zusammen und erm�glichen dem
Nutzer, in ihr zu navigieren. Diese Links sind meist nicht �ffentlich,
d.h. sie haben geheime Bestandteile, die z.B. den Nutzer gegen�ber dem
Server authentifizieren.
Manche Links hat gar nicht der Autor gesetzt, sondern sie wurde von
der Anzeige-Software automatisch erzeugt. Viele Mail-Clients machen
dies. (Ich werde nachher noch das SmartTags-Beispiel ausf�hren.)
Einige Links sind ungebrenzt g�ltig (weil sie auf eine Seite
verweisen, die nachhaltig angeboten wird), manche nur kurze Zeit (weil
sie z.B. eine Session-ID enthalten), manche nur f�r ein paar Tage
(weil sie danach in ein Archiv wandern, auf das nur gegen Bezahlung
zugegriffen werden kann).
In immer mehr F�llen sind Links gar nicht f�r die Verwendung durch
Menschen und Browser ausgelegt, sondern werden intern von Web Services
o.�. verwendet.
Daneben gibt es noch den Nicht-Link: Ein Medium nahe der Spitze der
Ver�ffentlichungspyramide berichtet �ber eine Website ziemlich weit
unten und setzt keinen Link (und nennt auch nicht den vollst�ndigen
Domainnamen), obwohl keinerlei rechtlichen oder sonstigen Probleme
durch den Link zu erwarten w�ren.
Diese paar Beispiele sind sicherlich nicht ersch�pfend, aber sie
zeigen hoffentlich trotzdem, da� es eine Vielzahl unterschiedlicher
Links gibt. Eine Argumentation vom technischen Wesen des Links her ist
daher fast immer unlauter, weil sie diese Komplexit�t zu verschleiern
droht.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
