A jó URI-k nem változnak
Mi jellemzi a jó URI-t?
A jó URI nem változik.
Melyek az URI változásának fajtái?
Az URI-k nem változnak: mi változtatjuk meg őket.
Elméletileg semmi okunk rá, hogy megváltoztassuk az URI-ket (vagy beszüntessük a dokumentumok karbantartását), a gyakorlatban viszont annál több.
Elméletben a domain-név tulajdonosa birtokolja a domain nevet és így minden benne levő URI-t is. A fizetésképtelenséget leszámítva semmi sem gátolhatja meg a domain-név tulajdonosát a név megtartásától. Elméletileg a domain-nevünk alatti URI hely teljes mértékben a mi irányításunk alatt áll, így olyan tartóssá tehető, amilyenné csak szeretnénk. Talán az egyetlen igazán jó indok arra, hogy egy dokumentum eltűnik a webről, az az, hogy a domain nevet birtokló vállalat befejezte tevékenységét, esetleg anyagilag nem engedheti meg magának a szerver tovább működtetését. Akkor miért van olyan sok holt link a világon? Sokszor egyszerűen csak az előrelátás hiányából. Néhány ok, amire hivatkozni szoktak:
Valóban úgy érezzük, hogy a régi URI-k nem maradhatnak? Ha így van, nagyon rosszul választottuk meg őket. Gondoljuk át az újakat, hogy meg tudjuk őrizni őket a következő átszervezés után is.
Ez az, amivel egyet tudok érteni - a W3C is megélt egy ilyen periódust, amikor óvatosan át kellett rostálni az archív anyagokat bizalmasság szempontjából, mielőtt azok nyilvánosságra kerültek volna. A megoldást az előrelátás jelenti - minden dokumentumhoz bizotsítani kell az elfogadás, a létrehozás és optimális esetben még az érvényesség dátumát is. Őrizzük meg ezt a metaadatot.
Ez az egyik leggyengébb kifogás. Rengetegen nem tudják, hogy a szerverek (mint például az Apache) számos vezérlési lehetőséget kínálnak egy objektum URI-je és a neki megfelelő fájl fájlrendszerbeli helye közötti kapcsolat rugalmassá tételére. Az URI-re mint absztrakt, tökéletesen rendezett helyre tekintsünk. Készítsünk leképezést a ténylegesen alkalmazott implementációra. Ezután kell megadni a szervernek.
Többé már nem John tartja karban ezt a fájlt, hanem Jane.
Mi is volt ez az URI John nevével? Az ő könyvtárában volt? Vagy úgy.
Helytelen feltételezés, hogy a szkriptekkel létrehozott oldalak biztosan a "cgibin" vagy "cgi" könyvtárban vannak. Ez a szerver működési mechanizmusától függ. Ha megváltoztatjuk a működést (a tartalmat pedig változatlanul hagyjuk) - hoppá, az összes URI megváltozik!
Vegyük például a Nemzeti Tudományos Alapítványt (The National Science Foundation):
NSF Online Documents (NFS Online Dokumentumok)
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl
a dokumentumok kereséséhez használandó főoldal egyértelműen nem olyan oldal, mely pár év múlva is biztosan itt lesz. A "cgi-bin", "oldbrowse" vagy ".pl" mind a jelenleg alkalmazott technológiára utal. Ezzel ellentétben az oldalt dokumentum keresésére használva egy hasonlóan rossz eredményt kapunk
Report of Working Group on Cryptology and Coding Theory (=Kriptográfia és kódoláselmélet Munkacsoport jelentése) címmel
http://www.nsf.gov/cgi-bin/getpub?nsf9814
a dokumentum indexoldalaként, maga a HTML dokumentum ezzel szemben lényegesen jobb:
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
Utóbbit vizsgálva a "pubs/1998" elősegíti a jövőbeli archíválást a régi, 1998-as dokumentumok osztályozásával. Bár 2098-ban a dokumentumok száma ettől különbözhet majd, elképzelhető, hogy ez az URI még akkor is él majd és az NSF-nek vagy bárkinek, aki gondozni fogja az archívumot, nem fogja zavarba ejteni.
This is the probably one of the worst side-effects of the URN discussions. Some seem to think that because there is research about namespaces which will be more persistent, that they can be as lax about dangling links as they like as "URNs will fix all that". If you are one of these folks, then allow me to disillusion you. Alighanem ez az egyik legrosszabb mellékhatása az URN vitáknak. Néhányan úgy gondolják, hogy mivel kutatások folynak a jelenleginél jóval állandóbb névhelyekkel, a holt linkeket félvállról lehet venni,mert "az URN-ek ezt lekezelik". Ha ezek közé tartozik, engedje meg, hogy kiábrándítsam Önt.
A legtöbb URN séma, melyet eddig láttam, szerzői azonosítóhoz hasonlított, melyet vagy egy általunk választott dátum és string vagy csak string követ. Ez nagyon hasonlít egy HTTP-s URI-re. Másképp fogalmazva, ha úgy gondoljuk, hogy a szervezetünk alkalmas lesz fennmaradó URN-ek létrehozására, készítsük el őket most és használjuk őket HTTP URI-nkhez. A HTTP kapcsán nincs semmi, ami URI-jeinket labilissá tehetné, ha saját szervezetről van szó. Készíteni kell egy adatbázist, ami a dokumentum URN-t az aktuális fájlnévhez társítja és hagyjuk, hogy a webszerver használja ezt a fájlok visszakereséséhez.
Ha a fentiek megértettük, akkor – hacsak nincs időnk, pénzünk és kapcsolataink szoftverfejlesztéshez – jöhet a következő kifogás:
Ezt a véleményt el tudom fogadni, sőt teljesen egyetértek vele. A webszerveren keresni kell egy állandó URI-t és lehívni a fájlt, bárhol is van az tárolva a jelenlegi fájlrendszerben. Felmerülhet az igény, hogy az URI a fájlban legyen tárolva ellenőrzési célokra, az adatbázis pedig folyamatosan aktualizált legyen. Egy dokumentum különféle verziói és fordításai közötti kapcsolatokat is tárolni kell. A véletlen hibák fájlhibáinak védelméül szolgálhat egy független rekordként tárolt ellenőrző összeg. A kiszolgálók alapból nem kínálnak ilyen lehetségeket. Egy új dokumentum létrehozásakor a szerkesztő kéri az URI-t, nemhogy kínálná.
Dokumentumok tulajdonosát, hozzáférési jellemzőit, az archíválás biztonsági szintjét stb. URI változás nélkül kell tudni megváltoztatni.
Egyáltalán nem jó, de ide jutunk. Too bad. But we'll get there. At W3C we use Jigedit functionality (Jigsaw server used for editing) which does track versions, and we are experimenting with document creation scripts. If you make tools, servers and clients, take note! Ez is rossz. De ide jutottunk. A W3C-nél a Jigedit funkcionalitást használjuk (a Jigsaw szervert használjuk szerkesztéshez) a dokumentum-változatok követésére, és dokumentum-készítő scriptekkel is kísérletezünk. Ha szoftvereszközöket, kiszolgálókat vagy klienseket fejleszt, értesítsen minket!
A fentiek számos W3C oldalra állnak, beleértve jelen oldalt is: tegyünk úgy, ahogy mondom, nem ahogy cselekszem.
Ha megváltoztatunk egy URI-t a szerverünkön, teljes bizonyossággal sohasem lehet tudni, kiknek vannak hivatkozásai a régi URI-re. Lehetnek hivatkozások külső weblapokról is. Könyvjelzőt helyezhettek oldalunkra. Az URI-t elküldhették egy barátnak levélben.
Ha valaki követ egy hivatkozást és az nem működik, általában megrendül a bizalom a szerver tulajdonosában. Érzelmileg és gyakorlati szempontból is zavaró lehet, hiszen a nem működő hivatkozás gátolja a látogatót célja elérésében.
Elegendően panaszkodnak folyamatosan ahhoz, hogy a kár egyértelmű legyen. Az is nyilvánvaló, milyen fényt vet egy nem működő hivatkozás az eltűnt dokumentum szerverének üzemeltetőjére.
A rendszergazdák kötelessége olyan URI-ket kiosztani, melyek 2, 20 vagy 200 év múlva is meglesznek. Ehhez átgondolásra, szervezésre és elkötelezettségre van szükség.
Az URI-k akkor változnak meg, ha van bennük olyan információ, mely változik. Az URI-k tervezésének módja ezért kritikus. (Micsoda, URI-t tervezni? Az URI-ket tervezni kell? Igen, gondoljuk csak meg!) A tervezés legtöbbször információ-kihagyást jelenti.
Egy dokumentum létrehozási ideje - az a dátum, amikor az URI kiosztásra kerül - egy olyan dolog, ami nem változik. Nagyon hasznos a régi és új rendszert használó kérések elkülönítése. Ez egyike azoknak a dolgoknak, mellyel egy jó URI kezdődhet. Ha egy dokumentum nemzedékek érdekeltsége és bármilyen formában dátummal van vagy lesz ellátva, akkor a dátum egy jó kezdőpont.
Az egyetlen kivétel az olyan oldal, mely egy egész szervezet (vagy annak nagy alrészének) "legfrissebb" weblapja.
http://www.pathfinder.com/money/moneydaily/latest/
a legutolsó "Money daily" (= napi pénz - a ford.) cikk a "Money" (Pénz - a ford.) magazinban. A fő ok, amiért nincs szükség ebben az URI-ben dátumra, az az, hogy nincs okunk tovább állandósítani az URI-t, mint ameddig a magazin létezik. A "today's Money" (mai pénz - a ford.) fogalma megszűnik, amikor a Money magazin adott száma megjelenik. Ha a tartalomra szeretnénk hivatkozni, oda kell linkelni, ahol feltűnik az archívumokban, vagyis:
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
(Jól néz ki, feltéve, hogy a "pénz" mindig ugyanazt jelenti a pathfinder.com fennállása során. A "98" és egy ".html" miatt ugyan duplikálás van, ami nem lenne szükséges, de egyébként ez például egy erős URI-nek néz ki.)
Mindent! A létrehozás dátuma után bármely más információ valamilyen módon problémákhoz vezet:
A fentiek alapján egy jobb példa oldalunkra egyszerűen a
http://www.w3.org/1998/12/01/chairs
mely a W3C elnöki ülésének perceiről szóló beszámoló.
Ezt a veszélyt részletesebben tárgyalom, mert azok közé tartozik, amit nehezebb elkerülni. A témák általában akkor szerepelnek URI-kben, ha végzett munkáink szerint csoportosítjuk dokumentumainkat. Ez a csoportosítás viszont változni fog. A témakörök is változni fognak. A W3C-nél például a "MarkUp"-ot (= jelölés) először "Markup"-ra szerettük volna cserélni, majd "HTML"-re, hogy utalhassunk a tartalomra. Ügyelni kell továbbá arra is, hogy ez nem egy hosszú távlatú elnevezés. Biztos benne, hogy 100 év elteltével nem szeretne újra felhasználni semmit? Rövid fennállásunk során mi például újra szerettük volna használni a "History" és a "Stylesheets" (= stíluslapok - a ford.) elnevezéseket.
Ez egy csábító mód webszájtok szervezésére, sőt valójában bármilyen szervezésre, beleértve az egész webet is. Ez egy nagyszerű közepes életidejű megoldás, de komoly hátrányai vannak hosszú távon.
A helyzet részbeni oka a jelentéstartalom. Minden kifejezés lehet csoportosítási téma, ráadásul mindenkinek eltérő lehet a fogalma annak jelentéséről. Mivel a témák közötti kapcsolatok inkább hálószerűek, mintsem faszerűek, még azok, akik megegyeznek egy hálóban, azok is választhatnak fastruktúrát is. Ezek a hierarchikus osztályozás általános megoldásként való használatának veszélyeiről gyakran ismételt általános megjegyzéseim.
Valójában egy témanév URI-ben való használatával bizonyos osztályozásokhoz kötjük magunkat. Előfordulhat, hogy a jövőben egy másikat részesítenénk előnyben. Ekkor fennáll annak a veszélye, hogy az URI nem fog működni többé.
A reason for using a topic area as part of the URI is that responsibility for sub-parts of a URI space is typically delegated, and then you need a name for the organizational body - the subdivision or group or whatever - which has responsibility for that sub-space. This is binding your URIs to the organizational structure. It is typically safe only when protected by a date further up the URI (to the left of it): 1998/pics can be taken to mean for your server "what we meant in 1998 by pics", rather than "what in 1998 we did with what we now refer to as pics." Egy témakör URI részeként történő felhasználásának oka, hogy egy URI részeit általában kiosztják különféle megbízottak között és ekkor szükség van a szervezet - alrészleg, csoport vagy valami hasonló - nevére, mely felelős ezért az URI-részért. Ez URI-jeinket a szervezeti struktúrába szorítja. A módszer általában csak akkor biztonságos, ha egy dátummal van védve. Ha az URI vége 1998/kepek, szerverünknek ez azt jelenti, hogy "amit nekünk 1998-ban a kepek jelentettek", ahelyett, hogy azt jelentené: "amit 1998-ban tettünk azokkal, amire jelenleg kepek-ként hivatkozunk".
Ne felejtsük, hogy ez nemcsak az URI "elérési út" részére, hanem a szervernév részére is vonatkozik. Ha néhány kollégának különálló szervert biztosítunk, tartsuk szem előtt, hogy ez a részleg nem lesz módosítható számos hivatkozás tönkretétele nélkül. Néhány tipikus "nézzék, milyen szoftvereket használunk ma" típusú tartománynév például a "vgi.pathfinder.com", a "secure" vagy a "lists.w3.org". Ezek a kiszolgáló adminisztrációjának megkönnyítésére készülnek. Akár vállalat-részleget, dokumentum-állapotot, hozzáférési szintet vagy biztonsági szintet reprezentál, legyünk nagyon-nagyon óvatosak, mielőtt egynél több dokumentumtípushoz egynél több domainnevet használnánk. Ne felejtsük, hogy egyetlen webszerverben több kiszolgáló is elrejthető átirányítással és proxy használatával.
Ja és gondoljunk a domain nevünkre! Ha nevünk nem "soap" [szappan -a ford.], akkor is "soap.com"-ként szeretnénk hivatkozni rá, ha idővel más termék forgalmazására térünk át? (Elnézést kérek a soap.com jelenlegi tulajdonosától, bárki is legyen.)
Úgy megőrizni az URI-ket, hogy azok 2, 20, 200 vagy akár 2000 év múltán is megmaradjanak, korántsem egyszerű. A világhálón a rendszergazdák folyamatosan hoznak olyan döntéseket, melyek saját dolgukat a jövőben nagyon megnehezítik majd. Ennek gyakran az az oka, hogy a jelenleg legjobbnak tűnő kiosztáokat használják, de senki sem gondolja végig, hogy különféle változások esetén mi történne a hivatkozásokkal. A dokumentum üzenete tehát az, hogy számos dolog változhat, de URI-jeink ugyanazok maradhatnak és azoknak is kell maradniuk. Ez azonban csak úgy lehetséges, ha átgondoljuk, hogyan tervezzük meg őket.
Lásd még:
...az URI-nkről egy gyakorlatilag fájl-alapú webszerveren?
Ha például Apache kiszolgálót használunk, akkor be lehet állítani, hogy tartalmi elrendezéseket használjon. Meghagyjuk a fájlkiterjesztést (például .png) a fájlon (például kutyam.png), de a webes forrásra enélkül hivatkozunk. Az Apache ilyenkor ellenőrzi a könyvtár minden fájlját ezzel a névvel és bármilyen kiterjesztéssel, és ki tudja választani a legjobbat (pl. GIF és PNG). (Nem kell a különböző típusú fájlokat különböző könyvtárakba rendezni, sőt akkor a tartalmi rendszerezés nem is működne.)
A kiterjesztést tartalmazó hivatkozások továbbra is működnek, csak azok nem teszik lehetővé, hogy a kiszolgálónk a jelenleg, illetve a jövőben elérhető legjobb formátumokat használja.
(Tulajdonképpen mind a kutyam, mind a kutyam.png és a kutyam.gif érvényes webes erőforrások, csak a kutyam tartalomtípus generikus, a kutyam.png és a kutyam.gif pedig tartalomtípus-specifikus.)
1999-ben találtam a http://www.whdh.com/stormforce/closings.shtml oldalt, mely a havazások miatti iskolabezárásokról szólt. Ezekről máskülönben csak a TV alján futó hírekből lehetett volna értesülni. Szóval belinkeltem a honlapomra. Aztán jött az első nagy vihar 2000-ben, s akkor ellenőriztem az oldalt. A következőt találtam:
"Bezárások ...
Jelenleg nincsenek bezárások. Kérjük, látogasson vissza később, ha azt az időjárás indokolttá teszi!"
Nem lehetett olyan nagy a vihar. Az a poénos, hogy a dátum hiányzik. Ha azonban visszatértem a weblap nyitóoldalára, egy nagy "iskolabezárások" feliratú gombot találtam, mely a http://www.whdh.com/stormforce/ oldalra hivatkozott, ami számos bezárt iskola listáját tartalmazta.
Meglehet, hogy megváltoztatták a rendszert, ami a bezárásokat átvette a végleges listáról, de az URI megváltoztatására nem volt szükségük.
A növekvő webes függőség egyik velejárója, hogy az alkalmazásoknak lehetnek beépített, a gyártó honlapjára mutató hivatkozásai. Ezt egyesek túlzásba viszik, de az URL-t meg kell őrizni. Egyszer kipróbáltam egy hivatkozást a Microsoft Netmeeting 2-ről / ügyfélként próbálkoztam a "Help/Microsoft on the Web/Free stuff" [=Segítség/Microsoft a weben/Ingyenes] menüpont alatt és egy Error 404 - not found [=404-es hiba - nem található] feleletet kaptam a szerverről. Mostanra már bizonyára elhárították a hibát...
©1998 Tim BLTörténeti megjegyzés: a 20. század végén, amikor ez a dokumentum készült, a címben szereplő "jó" kifejezés a fiatalok körében használatos díszítő jelző az új irányzatok befogadására, minőségére vagy megfelelőségére. A tartománynév és URI elérési út kiválasztását magában foglaló DNS tartományunk sietős kitűzése néha egyértelműen nem a hasznosság vagy hosszú élettartam jegyzében zajlik. Ez a megjegyzés egy kísérlet arra, hogy az ilyen kapkodások mögött meghúzódó energiákat a megfelelő irányba terelje.