Cool URIs veranderen niet

Waarom worden URI's gewijzigd?

URI's veranderen niet uit zichzelf; mensen veranderen ze. In theorie zijn er geen redenen voor mensen om URI's te wijzigen (of te stoppen met het onderhouden van documenten), maar in de praktijk zijn er miljoenen redenen.

In theorie is de eigenaar van de domeinnaamruimte eigenaar van die ruimte en dus van alle URI's daarin. Behalve bij insolventie is er niets dat de eigenaar verhindert de naam te behouden. Ook is de URI-ruimte onder uw domeinnaam volledig in uw eigen beheer, waardoor u deze zo stabiel kunt maken als u wilt.

De enige echt goede reden voor een document om van het web te verdwijnen, is dat het bedrijf dat het domein bezat failliet is gegaan of de server niet langer kan betalen. Waarom zijn er dan zoveel dode links in de wereld? Deels komt dit door een gebrek aan vooruitziendheid. Hier zijn enkele veelgehoorde redenen:

"We hebben onze website gereorganiseerd om deze te verbeteren." Heeft u echt het gevoel dat de oude URI's niet in stand kunnen worden gehouden? Zo ja, dan heeft u ze erg slecht gekozen. Denk bij uw nieuwe URI's na, zodat u deze ook na de volgende herontwikkeling in de lucht kunt houden.

"We hebben zoveel materiaal dat we het overzicht verliezen over wat verouderd, vertrouwelijk of geldig is, dus dachten we dat we het beste alles maar konden uitzetten." Hier kan ik begrip voor hebben; het W3C heeft een soortgelijke periode gekend waarin we archiefmateriaal zorgvuldig moesten filteren op vertrouwelijkheid voordat we de archieven openbaar maakten. De oplossing is vooruitziendheid: zorg dat u bij elk document de toegestane distributie, de creatiedatum en idealiter de vervaldatum vastlegt. Bewaar deze metadata.

"Nou, we merkten dat we de bestanden moesten verplaatsen..." Dit is een van de zwakste excuses. Veel mensen weten niet dat servers zoals Apache u veel controle geven over de flexibele relatie tussen de URI van een object en waar het bestand dat dit object representeert zich daadwerkelijk in een bestandssysteem bevindt. Beschouw de URI-ruimte als een abstracte, perfect georganiseerde ruimte. Maak vervolgens een koppeling naar de realiteit die u gebruikt om dit te implementeren en configureer uw server dienovereenkomstig.

"John onderhoudt dat bestand niet meer, Jane doet dat nu." Wat deed de URI van John in dat adres? Stond het in zijn persoonlijke map? Ik begrijp het al.

"We gebruikten eerst een CGI-script hiervoor en nu gebruiken we een binair programma." Er bestaat een vreemd idee dat pagina's die door scripts worden gegenereerd, zich in een cgi-bin of cgi-map moeten bevinden. Hiermee stelt u het mechanisme van uw server bloot. Zodra u het mechanisme wijzigt (zelfs als de inhoud hetzelfde blijft), veranderen plotseling al uw URI's.

Voorbeeld: National Science Foundation (NSF)

Neem bijvoorbeeld de National Science Foundation:

  • Hoofdpagina voor documenten: http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Deze pagina is duidelijk niet betrouwbaar voor de lange termijn. "cgi-bin", "oldbrowse" en ".pl" verwijzen allemaal naar hoe men het nu technisch oplost.

  • Indexpagina van een document: http://www.nsf.gov/cgi-bin/getpub?nsf9814

Ook deze is problematisch.

  • Het HTML-document zelf: http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Kijkend naar dit voorbeeld, geeft de header "pubs/1998" een toekomstige archiefdienst een goede aanwijzing dat het classificatieschema uit 1998 wordt gebruikt. Hoewel documentnummers in het jaar 2098 misschien anders zijn, kan ik me voorstellen dat deze URI dan nog steeds geldig is.

De misvatting over URN's

"Ik dacht niet dat URL's persistent moesten zijn - dat waren URN's." Dit is waarschijnlijk een van de ergste neveneffecten van de discussies over URN's. Sommigen lijken te denken dat omdat er onderzoek is naar name-spaces die persistenter zijn, ze zo laks mogelijk kunnen omgaan met dode links omdat "URN's dat wel zullen oplossen". Laat me u uit deze droom helpen.

De meeste URN-schema's zien eruit als een autoriteits-ID gevolgd door een datum en een string naar keuze, of simpelweg een string naar keuze. Dit lijkt sterk op een HTTP URI. Met andere woorden: als u denkt dat uw organisatie in staat is om URN's te maken die standhouden, bewijs dat dan door dit nu al te doen voor uw HTTP URI's. Er is niets aan HTTP dat uw URI's onstabiel maakt; het ligt aan uw organisatie. Maak een database die document-URN's koppelt aan de huidige bestandsnaam en laat de webserver die gebruiken om bestanden op te halen.

"We zouden het wel willen, maar we hebben simpelweg niet de juiste tools." Hier kan ik me volledig in vinden. Wat u nodig heeft is een webserver die razendsnel een persistente URI opzoekt en het bestand teruggeeft, ongeacht waar uw huidige chaotische bestandssysteem het op dat moment bewaart. U zou de URI in het bestand willen opslaan als controle en de database constant synchroon willen houden met de realiteit. Ook zou u relaties tussen verschillende versies en vertalingen van hetzelfde document willen opslaan, en een onafhankelijk record van de checksum willen bijhouden om corruptie door accidentele fouten te voorkomen. Webservers worden niet standaard geleverd met deze functies.

U moet zaken kunnen wijzigen zoals eigendom, toegang, archiefniveau en beveiligingsniveau van een document in de URI-ruimte zonder de URI zelf te wijzigen. We zijn er nog niet, maar we komen er wel. Bij het W3C gebruiken we Jigedit-functionaliteit (Jigsaw server voor bewerking) die versies bijhoudt, en we experimenteren met scripts voor documentcreatie. Ontwikkelaars van tools, servers en clients: neem dit serieus!

Waarom zou ik me hier druk om maken?

Wanneer u een URI op uw server wijzigt, kunt u nooit volledig weten wie er links naar de oude URI heeft staan. Ze kunnen links hebben geplaatst op reguliere webpagina's, ze kunnen uw pagina hebben gebookmarked, of ze hebben de URI in de kantlijn van een brief aan een vriend gekrabbeld.

Wanneer iemand een link volgt en deze is kapot, verliezen ze over het algemeen het vertrouwen in de eigenaar van de server. Ze raken gefrustreerd, zowel emotioneel als praktisch, omdat ze hun doel niet bereiken. De reputatieschade komt direct terecht bij de beheerder van de server waarvan het document is verdwenen.

Het ontwerpen van URI's

Het is de plicht van een webmaster om URI's toe te wijzen die over 2 jaar, 20 jaar of 200 jaar nog steeds standhouden. Dit vereist nadenken, organisatie en toewijding.

URI's veranderen wanneer er informatie in staat die verandert. Het is cruciaal hoe u ze ontwerpt. Ontwerpen betekent in dit geval vooral: informatie weglaten.

De creatiedatum van het document — de datum waarop de URI wordt uitgegeven — is iets dat niet zal veranderen. Dit is zeer nuttig om verzoeken die een nieuw systeem gebruiken te scheiden van die voor een oud systeem. Het is een goed startpunt voor een URI.

De enige uitzondering is een pagina die bewust een "laatste" pagina is (bijvoorbeeld voor een hele organisatie). http://www.pathfinder.com/money/moneydaily/latest/ is de nieuwste column van "Money daily". De reden dat hier geen datum in staat, is dat de persistentie van deze URI niet langer hoeft te duren dan het magazine zelf. Als u echter naar de specifieke inhoud wilt linken, linkt u naar het archief: http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

Wat u moet weglaten uit een URI

In principe alles! Na de creatiedatum is elke vorm van specifieke informatie in de naam vragen om problemen:

  • Naam van de auteur: Auteurschap kan veranderen bij nieuwe versies; mensen verlaten organisaties.
  • Onderwerp: Dit is verraderlijk. Het lijkt op het moment zelf logisch, maar verandert verrassend snel.
  • Status: Mappen zoals "oud", "concept" of "nieuwste" komen overal voor. Documenten veranderen van status; de nieuwste versie heeft een persistente identifier nodig, ongeacht de huidige status.
  • Toegang: Bij het W3C maken we onderscheid tussen team-, lid- en publieke toegang. Documenten beginnen vaak als teamideeën, worden besproken met leden en gaan dan openbaar. Het is zonde als alle oude links falen zodra een document toegankelijker wordt gemaakt.
  • Bestandsextensies: Dit is zeer gebruikelijk. .cgi of zelfs .html kan veranderen. Mogelijk gebruikt u over 20 jaar geen HTML meer voor die pagina, maar wilt u dat de huidige links nog steeds werken.
  • Softwaremechanismen: Vermijd termen als cgi, exec of andere aanwijzingen over welke software u gebruikt (zoals .pl voor Perl).
  • Schijfnaam: Dit is absoluut onnodig, hoewel ik het weleens heb gezien.

Een beter voorbeeld van onze eigen site is simpelweg: http://www.w3.org/1998/12/01/chairs (een verslag van de notulen van een vergadering van W3C-voorzitters).

Onderwerpen en classificatie naar onderwerp

Dit is een van de moeilijkste zaken om te vermijden. Typisch komen onderwerpen in URI's terecht wanneer u documenten classificeert volgens de indeling van uw werkzaamheden. Die indeling zal echter veranderen. Namen voor vakgebieden veranderen. Bij het W3C wilden we "MarkUp" veranderen naar "Markup" en later naar "HTML" om de werkelijke inhoud te reflecteren.

Bovendien is dit vaak een vlakke naamruimte. Weet u zeker dat u over 100 jaar niets wilt hergebruiken? Wij wilden bijvoorbeeld in onze korte bestaan al termen als "History" en "Stylesheets" hergebruiken.

Wanneer u een onderwerpnaam in een URI gebruikt, bindt u zich aan een specifieke classificatie. In de toekomst geeft u misschien de voorkeur aan een andere indeling, waardoor de URI kwetsbaar wordt voor breuken.

Een reden om wel een onderwerpgebied te gebruiken is dat de verantwoordelijkheid voor sub-delen van een URI-ruimte vaak gedelegeerd wordt. Dit koppelt uw URI's echter aan de organisatiestructuur. Dit is doorgaans alleen veilig als het beschermd wordt door een datum verderop in de URI: 1998/pics betekent dan "wat we in 1998 verstonden onder pics", in plaats van "wat we in 1998 deden met wat we nu pics noemen".

Vergeet de domeinnaam niet

Dit geldt niet alleen voor het pad, maar ook voor de servernaam. Als u aparte servers heeft voor verschillende zaken, onthoud dan dat deze verdeling onmogelijk te wijzigen is zonder talloze links te vernietigen. Klassieke voorbeelden van domeinnamen die onnodig de software blootleggen zijn cgi.pathfinder.com, secure of lists.w3.org.

Wees zeer voorzichtig voordat u meer dan één domeinnaam gebruikt voor verschillende typen documenten. Onthoud dat u veel webservers kunt verbergen achter één schijnbare webserver via redirection en proxying.

Denk ook na over de naam van uw domein zelf. Als uw bedrijf niet "zeep" heet, wilt u dan nog steeds worden aangeduid als soap.com wanneer u uw productlijn heeft gewijzigd?

Conclusie

URI's zo ontwerpen dat ze over 2, 20, 200 of zelfs 2000 jaar nog steeds bestaan, is niet zo simpel als het klinkt. Veel webmasters nemen beslissingen die het zichzelf in de toekomst erg moeilijk maken, vaak omdat ze tools gebruiken die alleen gericht zijn op het presenteren van de beste site op dit moment.

De boodschap is: er kan heel veel veranderen, maar uw URI's kunnen en moeten hetzelfde blijven. Dat lukt alleen als u nadenkt over hoe u ze ontwerpt.

***

Voetnoot: Hoe verwijder ik bestandsextensies uit mijn URI's?

Als u bijvoorbeeld Apache gebruikt, kunt u content negotiation instellen. U behoudt de bestandsextensie (zoals .png) op het fysieke bestand (bijv. mydog.png), maar verwijst naar de webresource zonder deze extensie. Apache controleert dan de map op alle bestanden met die naam en een willekeurige extensie, en kan de beste kiezen uit een set (bijv. GIF of PNG).

  1. Stel uw server in voor content negotiation.
  2. Maak verwijzingen altijd naar de URI zonder extensie.

Verwijzingen mét extensie blijven werken, maar maken het onmogelijk voor de server om automatisch de beste huidige of toekomstige formaten te selecteren.

***

Voorbeelden van wat niet moet (Hall of Flame)

Verhaal 1: Channel 7 In 1999 was http://www.whdh.com/stormforce/closings.shtml een pagina over gesloten scholen vanwege sneeuwval. Ik plaatste een link hiernaar op mijn homepagina. Tijdens de eerste grote storm van 2000 controleerde ik de pagina, maar deze zei: "Closings as of . There are currently no closings in effect." De datum ontbrak. Toen ik naar de homepage ging, zag ik een grote knop "school closings" die leidde naar http://www.whdh.com/stormforce/. Ze hadden het systeem gewijzigd, maar er was geen reden om de URI te veranderen.

Verhaal 2: Microsoft Netmeeting Applicaties hebben vaak ingebouwde links naar de website van de fabrikant. Onlangs probeerde ik een link vanuit de Microsoft Netmeeting client onder het menu "Help/Microsoft on the Web/Free stuff" en kreeg ik een Error 404 - not found. Ze hadden waarschijnlijk de URI gewijzigd terwijl deze in de software hardcoded stond.

***

(c)1998 Tim BL

Historische noot: Toen dit geschreven werd aan het einde van de 20e eeuw, was "cool" een term van goedkeuring, vooral onder jongeren, die duidde op trendiness, kwaliteit of passendheid. In de haast om DNS-territorium te claimen werden domeinnamen en URI-paden soms gekozen op basis van schijnbare "coolness" in plaats van bruikbaarheid of levensduur. Deze tekst is een poging om die energie om te buigen naar duurzaamheid.