Skrywer: Sir Tim Berners-Lee, uitvinder van URI's, URL's, HTTP, HTML en die Wêreldwye Web, en huidige hoof van die W3C. Artikel geskryf in 1998
Watter URI word as "cool" beskou?
Een wat nie verander nie.
Hoe word URI's verander?
URI's verander nie: mense verander dit.
In teorie is daar geen rede vir mense om URI's te verander (of op te hou om dokumente te ondersteun nie), maar in die praktyk is daar miljoene van hulle.
In teorie besit die nominale eienaar van 'n domeinnaamruimte eintlik die domeinnaamruimte en dus al die URI's daarin. Behalwe insolvensie verhinder niks die eienaar van 'n domeinnaam om die naam te behou nie. En in teorie is die URI-spasie onder u domeinnaam geheel en al onder u beheer, sodat u dit so stabiel kan maak as wat u wil. Byna die enigste goeie rede waarom 'n dokument van die internet af verdwyn, is dat die maatskappy wat die domeinnaam besit, uit die bedryf gegaan het of nie meer kan bekostig om die bediener aan die gang te hou nie. Waarom is daar dan so baie vermiste skakels in die wêreld? Sommige hiervan is bloot 'n gebrek aan oordenking. Hier is 'n paar redes wat jy kan hoor:
Ons het net die webwerf herorganiseer om dit beter te maak.
Dink jy regtig die ou URI's kan nie meer werk nie? Indien wel, dan het jy hulle baie swak gekies. Oorweeg dit om die nuwes te hou vir die volgende herontwerp.
Ons het soveel goed dat ons nie kan tred hou met wat verouderd is, wat vertroulik is en wat nog relevant is nie, daarom het ons dit goed gedink om dit net alles af te skakel.
Ek kan net simpatiseer. W3C het 'n tydperk deurgemaak waar ons argiefmateriaal noukeurig moes sif vir vertroulikheid voordat dit openbaar gemaak word. Die besluit moet vooraf deurdink word – maak seker dat jy met elke dokument die aanvaarbare leserstal, skeppingsdatum en, ideaal gesproke, vervaldatum aanteken. Stoor hierdie metadata.
Wel, ons het ontdek dat ons lêers moet skuif ...
Dit is een van die mees patetiese verskonings. Baie mense weet nie dat webbedieners jou toelaat om die verhouding tussen 'n voorwerp se URI en sy werklike ligging in die lêerstelsel te beheer nie. Dink aan die URI-ruimte as 'n abstrakte ruimte, perfek georganiseer. Maak dan 'n kartering na watter werklikheid jy ook al gebruik om dit te besef. Rapporteer dit dan aan die webbediener. U kan selfs u eie bedienerbrokkie skryf om dit reg te kry.
John hou nie meer hierdie lêer in stand nie, Jane doen dit nou.
Was John se naam in die URI? Nee, was die lêer net in sy gids? Wel, oukei.
Ons het voorheen 'n CGI-skrip hiervoor gebruik, maar nou gebruik ons 'n binêre program.
Daar is 'n mal idee dat bladsye wat deur skrifte geskep is in die "cgibin" of "cgi" area geleë moet wees. Dit ontbloot die meganika van hoe jy jou webbediener bestuur. Jy verander die meganisme (selfs terwyl jy inhoud stoor), en oeps - al jou URI's verander.
Neem die Nasionale Wetenskapstigting (NSF) byvoorbeeld:
NSF aanlyn dokumente
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl
Die eerste bladsy om dokumente te begin bekyk, sal duidelik oor 'n paar jaar nie dieselfde bly nie. cgi-bin, oldbrowse и pl - dit alles gee stukkies inligting uit oor hoe-ons-dit-nou-doen. As jy die bladsy gebruik om na 'n dokument te soek, is die eerste resultaat wat jy kry ewe sleg:
Verslag van die Werkgroep oor Kriptologie en Koderingsteorie
http://www.nsf.gov/cgi-bin/getpub?nsf9814
vir die dokument-indeksbladsy, alhoewel die html-dokument self baie beter lyk:
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
Hier sal die kroeë/1998-opskrif aan enige toekomstige argiefdiens 'n goeie leidraad gee dat die ou 1998-dokumentklassifikasieskema in werking is. Alhoewel die dokumentnommers dalk anders lyk in 2098, sou ek my voorstel dat hierdie URI steeds geldig sal wees en nie sal inmeng met NSF of enige ander organisasie wat die argief sal onderhou nie.
Ek het nie gedink URL's hoef aanhoudend te wees nie - daar was URN'e.
Dit is waarskynlik een van die ergste newe-effekte van die URN-debat. Sommige mense dink dat as gevolg van die navorsing na 'n meer permanente naamruimte, hulle dalk onverskillig kan wees oor hangende skakels, want "URN'e sal dit alles regmaak." As jy een van hierdie mense is, laat ek jou dan teleurstel.
Die meeste URN-skemas wat ek gesien het, lyk soos 'n outoriteit-identifiseerder, gevolg deur óf 'n datum en 'n string wat jy kies, óf net 'n string wat jy kies. Dit is baie soortgelyk aan 'n HTTP URI. Met ander woorde, as jy dink jou organisasie sal in staat wees om langlewende URN's te skep, bewys dit dan nou deur dit vir jou HTTP URI's te gebruik. Daar is niks in HTTP self wat jou URI onstabiel maak nie. Slegs jou organisasie. Skep 'n databasis wat die dokument-URN na die huidige lêernaam karteer, en laat die webbediener dit gebruik om die lêers werklik te herwin.
As jy hierdie punt bereik het, as jy nie die tyd, geld en verbindings het om sekere sagteware te ontwikkel nie, dan kan jy die volgende verskoning noem:
Ons wou, maar ons het net nie die regte gereedskap nie.
Maar jy kan hiermee simpatiseer. Ek stem heeltemal saam. Wat u moet doen, is om die webbediener te dwing om die aanhoudende URI onmiddellik te ontleed en die lêer terug te stuur waar dit ook al op u huidige mal lêerstelsel gestoor word. U wil alle URI's in 'n lêer stoor as 'n tjek en die databasis te alle tye op datum hou. U wil die verhouding tussen verskillende weergawes en vertalings van dieselfde dokument behou, en ook 'n onafhanklike kontrolesomrekord hou om te verseker dat die lêer nie deur 'n toevallige fout beskadig word nie. En webbedieners kom eenvoudig nie uit die boks met hierdie kenmerke nie. Wanneer jy 'n nuwe dokument wil skep, vra jou redigeerder jou om 'n URI te spesifiseer.
Jy moet eienaarskap, dokumenttoegang, argiefvlaksekuriteit, ens. in die URI-spasie kan verander sonder om die URI te verander.
Dit is alles te erg. Maar ons sal die situasie regstel. By W3C gebruik ons die Jigedit (Jigsaw editing server) funksionaliteit wat weergawes naspoor, en ons eksperimenteer met dokumentgenerering skrifte. As jy gereedskap, bedieners en kliënte ontwikkel, let op hierdie probleem!
Hierdie verskoning geld ook vir baie W3C-bladsye, insluitend hierdie een: doen dus soos ek sê, nie soos ek doen nie.
Hoekom moet ek omgee?
Wanneer jy die URI op jou bediener verander, kan jy nooit heeltemal sê wie skakels na die ou URI sal hê nie. Dit kan skakels vanaf gewone webblaaie wees. Boekmerk jou bladsy. Die URI is dalk in die kantlyne van 'n brief aan 'n vriend gekrap.
Wanneer iemand 'n skakel volg en dit is gebreek, verloor hulle gewoonlik vertroue in die bedienereienaar. Hy is ook gefrustreerd, beide emosioneel en fisies, deurdat hy nie sy doelwit kan bereik nie.
Baie mense kla heeltyd oor stukkende skakels, en ek hoop die skade is duidelik. Ek hoop dat die reputasieskade aan die onderhouer van die bediener waar die dokument verdwyn het ook duidelik is.
So wat moet ek doen? URI ontwerp
Dit is die verantwoordelikheid van die webmeester om URI's toe te ken wat oor 2 jaar, oor 20 jaar, in 200 jaar gebruik kan word. Dit verg bedagsaamheid, organisasie en vasberadenheid.
URI's verander as enige inligting daarin verander. Hoe jy dit ontwerp is baie belangrik. (Wat, URI-ontwerp? Moet ek die URI ontwerp? Ja, jy moet daaroor dink). Ontwerp beteken basies om enige inligting in die URI uit te laat.
Die datum waarop die dokument geskep is - die datum waarop die URI uitgereik is - is iets wat nooit sal verander nie. Dit is baie nuttig om navrae wat die nuwe stelsel gebruik te skei van dié wat die ou stelsel gebruik. Dit is 'n goeie plek om met 'n URI te begin. As 'n dokument gedateer is, selfs al sal die dokument in die toekoms relevant wees, dan is dit 'n goeie begin.
Die enigste uitsondering is 'n bladsy wat doelbewus die "nuutste" weergawe is, byvoorbeeld vir die hele organisasie of 'n groot deel daarvan.
http://www.pathfinder.com/money/moneydaily/latest/
Dit is die nuutste Money Daily-kolom in Money-tydskrif. Die hoofrede waarom daar nie 'n datum in hierdie URI nodig is nie, is dat daar geen rede is om die URI te stoor wat die logboek sal oorleef nie. Die konsep van Money Daily sal verdwyn wanneer Geld verdwyn. As jy na inhoud wil skakel, moet jy afsonderlik daarna in die argiewe skakel:
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
(Lyk goed. Aanvaar dat "geld" dieselfde ding sal beteken regdeur die lewe van pathfinder.com. Daar is 'n duplikaat "98" en 'n onnodige ".html", maar andersins lyk dit na 'n sterk URI.
Wat om eenkant te laat
Almal! Afgesien van die skeppingsdatum, vra die plaas van enige inligting in die URI op een of ander manier vir moeilikheid.
- Skrywer se naam. Outeurskap kan verander soos nuwe weergawes beskikbaar word. Mense verlaat organisasies en gee dinge aan ander oor.
- Onderwerp. Dit is baie moeilik. Dit lyk aanvanklik altyd goed, maar verander verbasend vinnig. Ek sal hieronder meer hieroor praat.
- status. Gidse soos "oud", "konsep" ensovoorts, om nie eens te praat van "nuutste" en "cool", verskyn in alle lêerstelsels. Dokumente verander status – anders sou dit geen sin wees om konsepte te skep nie. Die nuutste weergawe van 'n dokument benodig 'n aanhoudende identifiseerder, ongeag die status daarvan. Hou die status uit die naam.
- Toegang. By W3C het ons die webwerf in afdelings vir werknemers, lede en die publiek verdeel. Dit klink goed, maar dokumente begin natuurlik as spanidees van personeel, word met lede bespreek en word dan publieke kennis. Dit sal regtig jammer wees as elke keer as 'n dokument oopgemaak word vir wyer bespreking, al die ou skakels daarna verbreek word! Nou gaan ons aan na 'n eenvoudige datumkode.
- Lêeruitbreiding. 'n Baie algemene verskynsel. "cgi", selfs ".html" sal in die toekoms verander. Jy sal dalk oor 20 jaar nie HTML vir hierdie bladsy gebruik nie, maar vandag se skakels daarna behoort steeds te werk. Kanoniese skakels op die W3C-werf gebruik nie die uitbreiding nie ().
- Sagteware meganismes. Soek in die URI vir "cgi", "exec" en ander terme wat skree "kyk watter sagteware ons gebruik." Wil iemand sy hele lewe spandeer om Perl CGI-skrifte te skryf? Geen? Verwyder dan die .pl-uitbreiding. Lees die bedienerhandleiding oor hoe om dit te doen.
- Skyf naam. Komaan! Maar ek het dit gesien.
So die beste voorbeeld van ons webwerf is eenvoudig
http://www.w3.org/1998/12/01/chairs
... verslag doen oor die notule van die W3C-voorsittersvergadering.
Onderwerpe en klassifikasie volgens onderwerp
Ek sal meer in detail oor hierdie gevaar ingaan, aangesien dit een van daardie dinge is wat die moeilikste is om te vermy. Tipies beland onderwerpe in URI's wanneer jy jou dokumente kategoriseer volgens die werk wat hulle doen. Maar hierdie uiteensetting sal mettertyd verander. Die name van die gebiede sal verander. By W3C wou ons MarkUP na Markup en dan na HTML verander om die werklike inhoud van die afdeling te weerspieël. Daarbenewens is daar dikwels 'n plat naamruimte. Oor 100 jaar, is jy seker jy sal niks wil hergebruik nie? In ons kort lewe wou ons al byvoorbeeld "Geskiedenis" en "Stylblaaie" hergebruik.
Dit is 'n aanloklike manier om 'n webwerf te organiseer - en 'n werklik aanloklike manier om enigiets te organiseer, insluitend die hele web. Dit is 'n goeie mediumtermyn-oplossing, maar het ernstige tekortkominge op die lang termyn.
Deel van die rede lê in die filosofie van betekenis. Elke term in 'n taal is 'n potensiële teiken vir groepering, en elke persoon kan 'n ander idee hê van wat dit beteken. Aangesien verhoudings tussen entiteite meer soos 'n web as 'n boom is, kan selfs diegene wat met die web saamstem, 'n ander voorstelling van die boom kies. Dit is my (dikwels herhaalde) algemene waarnemings oor die gevare van hiërargiese klassifikasie as 'n algemene oplossing.
Trouens, wanneer jy 'n onderwerpnaam in 'n URI gebruik, verbind jy jouself tot 'n soort klassifikasie. Miskien sal jy in die toekoms 'n ander opsie verkies. Die URI sal dan vatbaar wees vir oortreding.
Die rede vir die gebruik van 'n vakgebied as deel van 'n URI is dat verantwoordelikheid vir onderafdelings van die URI-ruimte gewoonlik gedelegeer word, en dan benodig jy die naam van die organisatoriese liggaam - departement, groep, of wat ook al - wat verantwoordelik is vir daardie subruimte. Dit is 'n URI wat aan 'n organisasiestruktuur bind. Dit is gewoonlik net veilig as die verdere (linker) URI deur 'n datum beskerm word: 1998/foto's kan vir jou bediener beteken "wat ons in 1998 bedoel het met foto's" eerder as "wat ons in 1998 gedoen het met wat ons nou foto's noem."
Moenie die domeinnaam vergeet nie
Onthou dat dit nie net van toepassing is op die pad in die URI nie, maar ook op die bedienernaam. As jy aparte bedieners vir verskillende dinge het, onthou dat hierdie verdeling onmoontlik sal wees om te verander sonder om baie, baie skakels te vernietig. Sommige klassieke "kyk na die sagteware wat ons vandag gebruik"-foute is domeinname "cgi.pathfinder.com", "secure", "lists.w3.org". Hulle is ontwerp om bedieneradministrasie makliker te maak. Ongeag of 'n domein 'n afdeling in jou maatskappy verteenwoordig, 'n dokumentstatus, 'n toegangsvlak of 'n sekuriteitsvlak, wees baie, baie versigtig voordat jy meer as een domeinnaam vir veelvuldige dokumenttipes gebruik. Onthou dat jy verskeie webbedieners binne een sigbare webbediener kan versteek deur herleiding en instaanbediener te gebruik.
O, en dink ook aan jou domeinnaam. Jy wil nie na jou verwys word as soap.com nadat jy produk lyne verander het en ophou om seep te maak nie (Jammer aan wie soap.com op die oomblik besit).
Gevolgtrekking
Om 'n URI vir 2, 20, 200 of selfs 2000 jaar te bewaar is natuurlik nie so maklik soos dit lyk nie. Oor die hele internet neem webmeesters egter besluite wat hierdie taak in die toekoms vir hulself regtig moeilik maak. Dikwels is dit omdat hulle gereedskap gebruik wie se taak is om die beste webwerf net op die oomblik aan te bied - en niemand het geassesseer wat met die skakels sal gebeur wanneer alles verander nie. Die punt hier is egter dat baie, baie dinge kan verander, en jou URI's kan en moet dieselfde bly. Dit is slegs moontlik as jy dink oor hoe jy dit skep.
Sien ook:
aanvullings
Hoe om lêeruitbreidings te verwyder ...
...van 'n URI in die huidige lêergebaseerde webbediener?
As jy byvoorbeeld Apache gebruik, kan jy dit instel om inhoud te onderhandel. Stoor die lêeruitbreiding (bv. .png) na 'n lêer (bv. mydog.png), maar jy kan daarsonder na 'n webhulpbron skakel. Apache kontroleer dan die gids vir alle lêers met daardie naam en enige uitbreiding, en kan die beste een uit die stel kies (byvoorbeeld GIF en PNG). En dit is nie nodig om verskillende tipes lêers in verskillende dopgehou te plaas nie, in werklikheid sal inhoudpassing nie werk as jy dit doen nie.
- Stel jou bediener op om inhoud te onderhandel
- Skakel altyd na URI's sonder uitbreiding
Skakels met uitbreidings sal steeds werk, maar sal verhoed dat jou bediener die beste formaat wat tans en in die toekoms beskikbaar is, kies.
(In werklikheid, mydog, mydog.png и mydog.gif - geldige webbronne, mydog is 'n universele inhoud tipe hulpbron, en mydog.png и mydog.gif — hulpbronne van 'n spesifieke inhoudtipe).
Natuurlik, as jy jou eie webbediener skryf, is dit 'n goeie idee om 'n databasis te gebruik om aanhoudende identifiseerders aan hul huidige vorm te bind, alhoewel pasop vir onbeperkte databasisgroei.
The Board of Shame - Storie 1: Kanaal 7
Gedurende 1999 het ek skoolsluitings as gevolg van sneeu op bladsy dopgehou http://www.whdh.com/stormforce/closings.shtml. Moenie wag dat die inligting onderaan die TV-skerm verskyn nie! Ek het vanaf my tuisblad daarna geskakel. Die eerste groot sneeustorm van 2000 kom en ek kyk na die bladsy. Daar staan geskryf:,
- Asof.
Niks is tans gesluit nie. Keer asseblief terug in geval van weerwaarskuwings.
Dit kan nie so 'n sterk storm wees nie. Dis snaaks dat die datum ontbreek. Maar as jy na die hoofblad van die webwerf gaan, sal daar 'n groot knoppie "Geslote skole" wees wat na die bladsy lei http://www.whdh.com/stormforce/ met 'n lang lys geslote skole.
Miskien het hulle die stelsel verander om die lys te kry - maar hulle het nie nodig gehad om die URI te verander nie.
Board of Shame - Storie 2: Microsoft Netmeeting
Met die groeiende afhanklikheid van die internet het 'n slim idee gekom dat skakels na die vervaardiger se webwerf in toepassings ingebed kan word. Dit is al baie gebruik en misbruik, maar jy kan nie die URL verander nie. Ek het net nou die dag 'n skakel van die Microsoft Netmeeting 2/iets-kliënt in die Help/Microsoft op die web/Gratis goed-kieslys probeer en 'n 404-fout gekry - geen antwoord van die bediener is gevind nie. Miskien is dit al reggemaak...
© 1998
Historiese nota: In die laat 20ste eeu, toe dit geskryf is, was "cool" 'n bynaam van goedkeuring, veral onder jongmense, wat modieusheid, kwaliteit of toepaslikheid aandui. Inderhaas is die URI-pad dikwels gekies vir "koelte" eerder as bruikbaarheid of duursaamheid. Hierdie pos is 'n poging om die energie agter die soeke na koel te herlei.
Bron: will.com