Coole URIs ändern sich nicht

Von Sir Tim Berners-Lee, Erfinder von URIs, URLs, HTTP, HTML und dem World Wide Web, dem derzeitigen Leiter des W3C. Geschrieben im Jahr 1998



Welche URI ist cool?

Eine, die sich nicht ändert.

Wie ändern sich URIs?

URIs ändern sich nicht: Menschen ändern sie.



Theoretisch gibt es keinen Grund für Menschen, URIs zu ändern (oder die Pflege von Dokumenten einzustellen), aber in der Praxis gibt es Millionen.



Theoretisch besitzt der nominelle Eigentümer des Domain-Namespace tatsächlich den Domain-Namespace und damit alle darin enthaltenen URIs. Abgesehen von der Insolvenz hindert nichts den Domaininhaber daran, diesen Namen zu behalten. Theoretisch liegt der URI-Bereich unter Ihrem Domain-Namen vollständig unter Ihrer Kontrolle, sodass Sie ihn so stabil gestalten können, wie Sie möchten. Der einzige gute Grund für das Verschwinden eines Dokuments aus dem Internet ist, dass das Unternehmen, dem der Domainname gehörte, sein Geschäft eingestellt hat oder es sich nicht mehr leisten kann, den Server am Laufen zu halten. Warum gibt es dann so viele fehlende Glieder auf der Welt? Dies ist teilweise nur ein Mangel an Voraussicht. Hier sind einige der Gründe, die Sie hören können:



Wir haben die Site nur neu organisiert, um sie besser zu machen.



Haben Sie wirklich das Gefühl, dass die alten URIs nicht mehr funktionieren können? Wenn ja, haben Sie sie sehr schlecht ausgewählt. Ziehen Sie in Betracht, die neuen vom nächsten Redesign fernzuhalten.



Wir haben so viel Material, dass wir nicht verfolgen können, was veraltet, was vertraulich und was noch relevant ist, und deshalb dachten wir, es wäre besser, es einfach auszuschalten.



Ich kann nur mitfühlen. Das W3C hat eine Phase durchlaufen, in der wir Archivmaterial sorgfältig auf Vertraulichkeit prüfen mussten, bevor wir es veröffentlichen konnten. Die Entscheidung muss im Voraus getroffen werden - stellen Sie sicher, dass Sie mit jedem Dokument einen akzeptablen Leserkreis, das Erstellungsdatum und im Idealfall das Ablaufdatum aufzeichnen. Speichern Sie diese Metadaten.



Nun, wir haben festgestellt, dass wir Dateien verschieben müssen ...



Dies ist eine der erbärmlichsten Ausreden. Viele Leute wissen nicht, dass Sie mit Webservern die Beziehung zwischen dem URI eines Objekts und seinem tatsächlichen Speicherort im Dateisystem steuern können. Stellen Sie sich einen URI-Raum als einen abstrakten Raum vor, der perfekt organisiert ist. Ordnen Sie dann die Realität zu, mit der Sie sie tatsächlich implementieren. Dann melden Sie es dem Webserver. Sie können sogar einen Ausschnitt Ihres Servers schreiben, um ihn richtig zu machen.



John verwaltet diese Datei nicht mehr, Jane jetzt.



War Johns Name in der URI? Nein, nur die Datei war in seinem Verzeichnis? Na gut.



Früher haben wir dafür ein CGI-Skript verwendet, jetzt verwenden wir ein Binärprogramm.



Es gibt eine verrückte Idee, dass sich geskriptete Seiten im Bereich "cgibin" oder "cgi" befinden sollten. Dies zeigt den Mechanismus, wie Sie Ihren Webserver starten. Ändern Sie den Mechanismus (behalten Sie sogar den Inhalt bei) und hoppla - alle Ihre URIs ändern sich.



Nehmen wir zum Beispiel die National Science Foundation (NSF): NSF



Online Documents

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl


Die erste Seite, auf der Dokumente angezeigt werden, wird in einigen Jahren eindeutig nicht mehr dieselbe sein. cgi-bin, oldbrowseund pl - all dies gibt Partikel von Informationen darüber heraus, wie wir es jetzt tun. Wenn Sie die Seite verwenden, um nach einem Dokument zu suchen, erhalten Sie zuerst ein ebenso schlechtes Ergebnis:



Bericht der Arbeitsgruppe für Kryptologie und Codierungstheorie

http://www.nsf.gov/cgi-bin/getpub?nsf9814


für die Indexseite des Dokuments, obwohl das HTML-Dokument selbst viel besser aussieht:



http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm


Hier wird die Überschrift Pubs / 1998 jedem zukünftigen Archivierungsdienst einen guten Hinweis darauf geben, dass das alte Dokumentklassifizierungsschema von 1998 in Kraft ist. Obwohl die Dokumentennummern im Jahr 2098 möglicherweise anders aussehen, kann ich mir vorstellen, dass diese URI weiterhin gültig ist und die NSF oder eine andere Organisation, die das Archiv in irgendeiner Weise verwaltet, nicht beeinträchtigt.



Ich dachte nicht, dass URLs persistent sein sollten - sie waren URNs.



Dies ist wahrscheinlich eine der schlimmsten Nebenwirkungen der URN-Diskussion. Einige Leute denken, dass sie aufgrund der Erforschung eines beständigeren Namespace möglicherweise nachlässig mit baumelnden Links umgehen, weil "URNs alles reparieren". Wenn Sie einer dieser Menschen sind, lassen Sie uns enttäuscht sein.



Die meisten der URN-Schemata, die ich gesehen habe, sehen aus wie eine Berechtigungskennung, gefolgt von dem von Ihnen ausgewählten Datum und der ausgewählten Zeichenfolge oder nur der von Ihnen ausgewählten Zeichenfolge. Dies ist dem HTTP-URI sehr ähnlich. Mit anderen Worten, wenn Sie der Meinung sind, dass Ihre Organisation langlebige URNs erstellen kann, beweisen Sie dies jetzt, indem Sie sie für Ihre HTTP-URIs verwenden. In HTTP selbst gibt es nichts, was Ihre URI instabil macht. Nur Ihre Organisation. Erstellen Sie eine Datenbank, die die URN des Dokuments dem aktuellen Dateinamen zuordnet, und lassen Sie den Webserver sie verwenden, um die Dateien tatsächlich abzurufen.



Wenn Sie an diesem Punkt angelangt sind und nicht über die Zeit, das Geld und die Verbindungen verfügen, um eine Software zu entwickeln, können Sie die folgende Entschuldigung nennen:



Wir wollten, aber wir haben einfach nicht die richtigen Werkzeuge.



Aber Sie können damit sympathisieren. Ich bin vollkommen einverstanden. Sie müssen den Webserver zwingen, den persistenten URI sofort zu verarbeiten und die Datei an den Ort zurückzugeben, an dem sie derzeit in Ihrem aktuellen verrückten Dateisystem gespeichert ist. Sie möchten alle URIs in einer Datei zur Überprüfung behalten und die Datenbank jederzeit auf dem neuesten Stand halten. Sie möchten die Beziehung zwischen verschiedenen Versionen und Übersetzungen desselben Dokuments beibehalten und außerdem ein unabhängiges Prüfsummenprotokoll führen, um sich vor versehentlichen Fehlern in der Datei zu schützen. Und Webserver sind mit diesen Funktionen einfach nicht sofort einsatzbereit. Wenn Sie ein neues Dokument erstellen möchten, fordert Ihr Editor eine URI an.



Sie müssen in der Lage sein, den Besitz, den Dokumentenzugriff, die Sicherheit auf Archivebene usw. im URI-Bereich zu ändern, ohne den URI zu ändern.



Das ist schade. Aber wir werden die Situation beheben. Im W3C verwenden wir die Jigedit-Funktion (einen Jigsaw-Bearbeitungsserver), mit der Versionen verfolgt werden, und experimentieren mit Skripten zur Dokumenterstellung. Wenn Sie Tools, Server und Clients entwickeln, achten Sie auf dieses Problem!



Diese Entschuldigung gilt auch für viele W3C-Seiten, einschließlich dieser: Tun Sie also, was ich sage, nicht was ich tue.



Warum sollte es mich kümmern?



Wenn Sie den URI auf Ihrem Server ändern, können Sie nie vollständig sagen, wer auf den alten URI verweist. Dies können Links von normalen Webseiten sein. Lesezeichen zu Ihrer Seite. Die URI wurde möglicherweise am Rand eines Briefes an einen Freund zerkratzt.



Wenn jemand auf einen Link klickt und dieser beschädigt ist, verliert er normalerweise das Vertrauen in den Serverbesitzer. Er ist auch enttäuscht - sowohl emotional als auch realistisch von der Unfähigkeit, sein Ziel zu erreichen.



Viele Leute beschweren sich ständig über defekte Links, und ich hoffe, der Schaden ist offensichtlich. Ich hoffe, dass der Reputationsschaden für den Betreuer des Servers, auf dem das Dokument verschwunden ist, ebenfalls offensichtlich ist.



Also was soll ich tun? URI-Design



Es liegt in der Verantwortung des Webmasters, URIs zuzuweisen, die in 2 Jahren, in 20 Jahren, in 200 Jahren verwendet werden können. Dies erfordert Nachdenklichkeit, Organisation und Engagement.



URIs ändern sich, wenn sich einige Informationen in ihnen ändern. Wie Sie sie entwerfen, ist sehr wichtig. (Was, URI-Design? Ich muss eine URI entwerfen? Ja, Sie sollten darüber nachdenken). Design bedeutet im Grunde, keine Informationen in der URI zu haben.



Das Datum, an dem das Dokument erstellt wurde - das Datum, an dem der URI ausgestellt wurde - etwas, das sich nie ändern wird. Dies ist sehr nützlich, um Anforderungen, die das neue System verwenden, von Anforderungen zu trennen, die das alte System verwenden. Es ist ein guter Ausgangspunkt für eine URI. Wenn das Dokument datiert ist, auch wenn das Dokument in Zukunft relevant ist, ist dies ein guter Anfang.



Die einzige Ausnahme ist eine Seite, die absichtlich die "neueste" Version ist, beispielsweise für die gesamte Organisation oder einen großen Teil davon.



http://www.pathfinder.com/money/moneydaily/latest/


Dies ist die letzte Spalte von Money Daily im Money Magazine. Der Hauptgrund, warum dieser URI kein Datum benötigt, ist, dass es keinen Grund gibt, einen URI zu speichern, der das Protokoll überlebt. Das Konzept von Money Daily verschwindet, wenn Money verschwindet. Wenn Sie auf Inhalte verlinken möchten, sollten Sie diese im Archiv separat verlinken:



http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html


(Sieht gut aus. Angenommen, "Geld" bedeutet dasselbe für das Leben von pathfinder.com. Es gibt doppelte "98" und unnötige ".html", sieht aber ansonsten wie eine starke URI aus.



Was beiseite lassen



Alle! Abgesehen vom Erstellungsdatum ist das Einfügen von Informationen in eine URI auf die eine oder andere Weise ein Problem, das um Probleme bittet.



  • Name des Autors . Die Schuld kann sich mit neuen Versionen ändern. Menschen verlassen Organisationen und geben Dinge an andere weiter.

  • Betreff . Das ist sehr schwer. Er sieht auf den ersten Blick immer gut aus, ändert sich aber überraschend schnell. Ich werde darauf weiter unten näher eingehen.

  • Status . Verzeichnisse wie "alt", "Entwurf" usw., ganz zu schweigen von "aktuell" und "cool", werden auf allen Dateisystemen angezeigt. Dokumente ändern den Status - andernfalls wäre es sinnlos, Entwürfe zu erstellen. Die neueste Version eines Dokuments benötigt unabhängig von seinem Status eine dauerhafte Kennung. Halten Sie den Status außerhalb des Namens.

  • . W3C , . , , , , , . , , , - , ! .

  • . . "cgi", ".html" . , 20 HTML , . W3C ( ).

  • Softwaremechanismen . Suchen Sie in der URI nach "cgi", "exec" und anderen Begriffen, die schreien: "Sehen Sie sich an, welche Software wir verwenden." Möchte jemand sein ganzes Leben Perl CGI-Skripten widmen? Nein? Entfernen Sie dann die Erweiterung .pl. Lesen Sie dazu das Serverhandbuch.

  • Datenträgername. Nun ja! Aber das habe ich gesehen.


Das beste Beispiel auf unserer Website ist also einfach



http://www.w3.org/1998/12/01/chairs


… Ein Bericht über das Protokoll der Sitzung der W3C-Vorsitzenden.



Themen und Klassifizierung nach Themen



Ich werde näher auf diese Gefahr eingehen, da sie eines der am schwersten zu vermeidenden Dinge ist. In der Regel landen Themen in URIs, wenn Sie Ihre Dokumente nach laufenden Arbeiten kategorisieren. Diese Aufteilung wird sich jedoch im Laufe der Zeit ändern. Die Bereichsnamen ändern sich. Im W3C wollten wir MarkUP in Markup und dann in HTML ändern, um den tatsächlichen Inhalt des Abschnitts widerzuspiegeln. Außerdem ist der Namespace häufig flach. Sind Sie sicher, dass Sie nach 100 Jahren nichts mehr wiederverwenden möchten? In unserem kurzen Leben wollten wir zum Beispiel bereits "History" und "Style Sheets" wiederverwenden.



Es ist eine verlockende Art, eine Website zu organisieren - und eine wirklich verlockende Art, alles zu organisieren, einschließlich des gesamten Web. Dies ist eine ausgezeichnete mittelfristige Lösung, die jedoch langfristig schwerwiegende Nachteile aufweist.



Ein Teil des Grundes liegt in der Philosophie der Bedeutung. Jeder Begriff in der Sprache ist ein potenzielles Clustering-Objekt, und jede Person hat möglicherweise eine andere Vorstellung davon, was es bedeutet. Da die Beziehung zwischen Subjekten eher einem Spinnennetz als einem Baum ähnelt, können auch diejenigen, die mit dem Spinnennetz einverstanden sind, eine andere Darstellung des Baums wählen. Dies sind meine (oft wiederholten) allgemeinen Bemerkungen zu den Gefahren der hierarchischen Klassifizierung als allgemeine Lösung.



Wenn Sie einen Themennamen in einer URI verwenden, binden Sie sich tatsächlich an eine Klassifizierung. Sie können in Zukunft eine andere Option wählen. Dann wird die URI kompromittiert.



Der Grund für die Verwendung eines Themenbereichs als Teil einer URI besteht darin, dass die Verantwortung für Unterabschnitte eines URI-Bereichs normalerweise delegiert wird. Anschließend benötigen Sie den Namen des Organisationsorgans - einer Einheit, Gruppe oder was auch immer -, das für diesen Unterbereich verantwortlich ist. Dies ist die Bindung der URI an die Organisationsstruktur. Es ist normalerweise nur dann sicher, wenn der URI weiter unten (links) durch ein Datum geschützt ist: 1998 / pics könnte für Ihren Server bedeuten, "was wir 1998 mit pics gemeint haben" und nicht "was wir damit gemacht haben" was wir jetzt Bilder nennen. "



Vergessen Sie nicht Ihren Domainnamen



Beachten Sie, dass dies nicht nur für den Pfad in der URI gilt, sondern auch für den Servernamen. Wenn Sie separate Server für verschiedene Dinge haben, denken Sie daran, dass diese Trennung nicht geändert werden kann, ohne viele, viele Links zu zerstören. Einige klassische Fehler wie "Sehen Sie sich an, welche Software wir heute verwenden" sind die Domainnamen "cgi.pathfinder.com", "Secure", "Lists.w3.org". Sie sollen die Serververwaltung erleichtern. Unabhängig davon, ob die Domäne eine bestimmte Abteilung in Ihrem Unternehmen, den Dokumentstatus, die Zugriffsebene oder die Sicherheitsstufe darstellt, sollten Sie sehr, sehr vorsichtig sein, bevor Sie mehr als einen Domänennamen für mehrere Dokumenttypen verwenden. Denken Sie daran, dass Sie viele Webserver in einem sichtbaren Webserver verstecken können.mit Umleitung und Proxy.



Ja, und denken Sie auch an Ihren Domainnamen. Sie möchten nicht als soap.com bezeichnet werden, nachdem Sie Ihre Produktlinie geändert und die Herstellung von Seife eingestellt haben (Entschuldigung an alle, die im Moment soap.com besitzen).



Fazit



Das Speichern eines URI für 2, 20, 200 oder sogar 2000 Jahre ist offensichtlich nicht so einfach, wie es sich anhört. Überall im Internet treffen Webmaster jedoch Entscheidungen, die es sich in Zukunft wirklich schwer machen werden. Dies liegt häufig daran, dass sie Tools verwenden, deren Aufgabe es ist, nur im Moment die beste Website zu präsentieren - und niemand hat geschätzt, was mit den Links passieren wird, wenn sich alles ändert. Der Punkt hier ist jedoch, dass sich viel, viel ändern kann und Ihre URIs gleich bleiben können und sollten. Dies ist nur möglich, wenn Sie darüber nachdenken, wie Sie sie erstellen.



Siehe auch:



Ergänzungen



So entfernen Sie Dateierweiterungen ...



... von einem URI im aktuellen dateibasierten Webserver?



Wenn Sie beispielsweise Apache verwenden, können Sie es so konfigurieren, dass Inhalte ausgehandelt werden. Sie speichern die Dateierweiterung (z. B. .png) in einer Datei (z. B. mydog.png ), können jedoch ohne diese eine Verknüpfung zu einer Webressource herstellen. Apache überprüft dann das Verzeichnis auf alle Dateien mit diesem Namen und einer beliebigen Erweiterung und kann die beste aus dem Satz auswählen (z. B. GIF und PNG). Und Sie müssen nicht verschiedene Dateitypen in verschiedenen Verzeichnissen ablegen. In der Tat funktioniert die Inhaltsverhandlung nicht, wenn Sie dies tun.



  • Konfigurieren Sie Ihren Server für die Aushandlung von Inhalten

  • Verweisen Sie immer auf URIs ohne Erweiterung


Erweiterungslinks funktionieren weiterhin, verhindern jedoch, dass Ihr Server das derzeit und in Zukunft beste Format auswählt.



(In der Tat mydog, mydog.pngund mydog.gif- Codes und Web - Ressourcen mydog- ein universeller Ressource Inhaltstyp, mydog.pngund mydog.gif- die Ressourcen eines bestimmten Typ Inhalt).



Wenn Sie Ihren eigenen Webserver schreiben, ist es natürlich eine gute Idee, eine Datenbank zu verwenden, um persistente IDs an ihre aktuelle Form zu binden. Achten Sie jedoch auf unbegrenztes Datenbankwachstum.



Shame Board - Geschichte 1: Kanal 7



1999 habe ich auf einer Seite Schulschließungen aufgrund von Schnee verfolgt http://www.whdh.com/stormforce/closings.shtml. Warten Sie nicht, bis die Informationen am unteren Rand des Fernsehbildschirms angezeigt werden! Ich habe von meiner Homepage aus darauf verlinkt. Der erste große Schneesturm des Jahres 2000 kommt und ich überprüfe die Seite. Es heißt:



- Ab.

Derzeit ist nichts geschlossen. Bitte kommen Sie bei Wetterwarnungen zurück.




Es kann nicht der gleiche starke Sturm sein. Es ist lustig, dass das Datum fehlt. Wenn Sie jedoch zur Hauptseite der Website gehen, wird eine große Schaltfläche "Geschlossene Schulen" angezeigt, die zu einer Seite http://www.whdh.com/stormforce/mit einer langen Liste geschlossener Schulen führt.



Möglicherweise haben sie das Listingsystem geändert, aber sie mussten den URI nicht ändern.



Shame Board - Geschichte 2: Microsoft Netmeeting



Mit der zunehmenden Abhängigkeit vom Internet kam die clevere Idee zu Anwendungen, mit denen Sie Links zur Website des Herstellers einbetten können. Dies wurde viel benutzt und missbraucht, aber - Sie können die URL nicht ändern. Erst neulich habe ich einen Link vom Microsoft Netmeeting 2 / etwas-Client in der Hilfe / Microsoft im Menü Web / Free Stuff ausprobiert und einen 404-Fehler erhalten - keine Antwort vom Server gefunden. Vielleicht schon behoben ...



© 1998 Tim BL



Historischer Hinweis: Am Ende des 20. Jahrhunderts, als dies geschrieben wurde, war „cool“ ein Beiname der Anerkennung, insbesondere unter jungen Menschen, der auf Mode, Qualität oder Angemessenheit hinweist. In Eile wurde der URI-Pfad oft aus "cool" über Nützlichkeit oder Langlebigkeit gewählt. Dieser Beitrag ist ein Versuch, die Energie hinter der Suche nach Coolness umzuleiten.



Siehe auch:






All Articles