Summary

  • Dans « Cool URIs don't change », Tim Berners-Lee décrit les excuses ordinaires des liens brisés et la solution d’exploitation : conserver une URI publique, puis faire correspondre cette URI au fichier ou au programme actuel. La chronologie du W3C situe ce texte en décembre 1998.
  • Un nom d’employé, un dossier cgi-bin, une extension de fichier, une catégorie éditoriale ou un niveau d’accès peut changer. Les inscrire dans une adresse destinée à durer transforme chaque réorganisation en travail imposé aux lecteurs et aux sites qui ont créé des liens.

La vitrine neuve, l’ancienne entrée condamnée

Le cas commence souvent par une bonne intention. Le menu est confus, la documentation a grossi, les responsables changent. On range les pages autrement pour que l’équipe puisse travailler. Puis l’ancienne URL cesse de répondre. Dans son texte de 1998, Berners-Lee conteste le lien de cause à effet que suppose cette dernière étape. Le serveur sait associer une adresse visible à un fichier rangé ailleurs. Il peut continuer à servir le même document après un déménagement interne. La nouvelle organisation n’a pas besoin de devenir la nouvelle adresse de tout le monde.

Cette séparation donne à la maison d’édition deux plans. Le premier est public : les URI reprises dans des articles, enregistrées dans des favoris ou recopiées dans une lettre. Le second est privé : le disque, l’application, l’équipe, les permissions et la façon dont le serveur retrouve la bonne représentation. Une modification du second plan peut rester invisible sur le premier. Elle exige un peu de travail de l’éditeur. Elle évite à un nombre inconnu de lecteurs de refaire leur chemin.

Berners-Lee énumère les prétextes qu’il entendait. Le site a été réorganisé « pour l’améliorer ». Des archives sont devenues difficiles à trier. Les fichiers ont bougé. John a quitté le dossier dont il avait la charge et Jane le reprend. Un script CGI a été remplacé par un programme. Ce sont de vrais changements dans une institution. Ce ne sont pas des raisons techniques obligeant à renommer une ressource publique. Un serveur peut faire la correspondance entre le nom stable et les moyens nouveaux de la fournir.

L’exemple des documents de la National Science Foundation rend la critique matérielle. Berners-Lee relève des adresses exposant cgi-bin, un script Perl et une requête de récupération. Il les oppose à un chemin où figurent une année de publication et un identifiant de document. Le texte compare ces formes en 1998 ; il ne mesure pas leur survie ultérieure. La différence est claire : l’année du document peut rester vraie après une migration, alors que le nom du script vend comme durable une plomberie provisoire.

L’organigramme ne doit pas gouverner l’adresse

Le logiciel n’est qu’un des pièges. Un nom d’auteur dans l’URI devient gênant quand une autre personne maintient le document. Une catégorie devient fausse quand les sujets ou les départements sont redécoupés. Le mot draft vieillit dès que le texte change de statut. Une adresse marquée « membres » peut coincer une page qu’on ouvre plus tard au public. Même le nom d’un serveur spécialisé peut exposer un découpage administratif appelé à disparaître. À chaque fois, une commodité interne se fait passer pour une identité publique.

Berners-Lee proposait de partir des faits qui vieillissent peu. La date de création d’un document reste sa date de création. Une URI datée peut donc ancrer une publication d’archive. Une adresse latest peut convenir à une page dont la fonction est précisément d’indiquer la livraison courante. Ce choix oblige l’éditeur à préciser ce que le nom désigne. Un numéro archivé et « le numéro d’aujourd’hui » ne promettent pas la même stabilité de contenu. Le serveur peut les servir avec les outils qu’il veut, tant que le contrat public reste intelligible.

Le classement par sujet résiste davantage à cette discipline. Les catégories semblent naturelles au moment de concevoir un site. Mais un sujet peut traverser plusieurs dossiers et le vocabulaire de l’organisation évolue. Berners-Lee cite les changements de terminologie au W3C, de « MarkUp » vers « HTML ». Mettre la catégorie dans l’URI revient à faire dépendre chaque ancien lien de la taxonomie du moment. L’auteur recommandait de ne pas confondre l’arbre commode pour les collaborateurs et le nom durable que d’autres institutions vont citer.

Une URN ne paiera pas l’archiviste

Certains espéraient que les Uniform Resource Names résoudraient la persistance, en laissant les URL ordinaires se perdre. Berners-Lee rejetait l’alibi. Une organisation capable d’entretenir un nom permanent peut appliquer la même discipline à une URI HTTP. Dans les deux cas, quelqu’un doit garder le nom, maintenir la correspondance avec le document et financer le service qui répond. Une catégorie d’identifiant plus solennelle ne transforme pas une promesse négligée en infrastructure.

Le texte reconnaissait aussi le travail que cette promesse réclame. Les outils de publication courants ne tenaient pas automatiquement un registre reliant URI, fichiers, versions, traductions et sommes de contrôle. Le W3C lui-même avait des pages peu exemplaires. Berners-Lee demandait des outils grâce auxquels un changement de propriétaire, de niveau d’accès ou d’emplacement ne force pas le changement d’adresse. Voilà la vraie dépense de la permanence : concevoir une publication capable de traverser ses propres réorganisations.

La Recommandation du W3C sur l’architecture du Web, en 2004, a formulé le principe avec plus de gravité. La persistance d’une URI dépend de la politique et de l’engagement de son propriétaire ; le schéma choisi ne garantit rien à lui seul. Une représentation cohérente et, lorsqu’il y a réellement déplacement, une redirection HTTP peuvent aider. Le centre de gravité reste chez l’éditeur qui a émis l’adresse.