Summary

  • Le W3C a publié XLink 1.0 comme Recommendation le 27 juin 2001. Un lien simple reprenait le trajet sortant familier; un lien étendu pouvait réunir plusieurs ressources, avec des arcs pour indiquer les parcours.
  • Un lien étendu pouvait être conservé hors des ressources qu'il reliait. Le fichier rassemblant des liens entrants ou entre ressources distantes s'appelait linkbase. Le logiciel devait découvrir ce fichier avant de proposer ces chemins au lecteur.

Le lien hypertexte classique a la politesse de se présenter sur place. On voit une expression cliquable dans la page, on la suit, on arrive ailleurs. Imaginez maintenant une édition de documents XML dont les textes sont déjà publiés et intouchables. Une équipe veut rapprocher trois ressources, ajouter des renvois, peut-être dessiner plusieurs directions de lecture. Elle n'a pas envie de demander à chaque propriétaire d'ouvrir son fichier. Il lui faudrait un tableau de correspondances installé à côté des textes. Mais qui dira au lecteur où se trouve ce tableau?

La Recommendation XLink 1.0 du 27 juin 2001 traitait les liens comme des structures XML. Un lien simple ressemblait au trajet connu des pages HTML: un point de départ local et une destination désignée par URI. Un lien étendu pouvait réunir davantage de participants. Ses éléments locator identifiaient des ressources par référence; des éléments de ressource représentaient des participants locaux; des éléments arc précisaient quels parcours le logiciel pouvait suivre. Le lien avait obtenu un petit standard téléphonique.

Ce standard réglait aussi la direction du mouvement. Un arc sortant partait d'une ressource locale vers une ressource distante. Un arc entrant arrivait sur une ressource locale depuis un départ distant. Un arc dit third-party allait d'une ressource distante à une autre. La distance, ici, était une affaire de désignation: une ressource identifiée par URI comptait comme distante même si ses octets se trouvaient dans le même document XML. Le W3C classait le lien d'après la manière dont le document nommait ses participants.

Grâce à cette géométrie, un éditeur pouvait décrire un rapport entre des ressources dont il ne possédait pas les fichiers. Le communiqué du W3C publié le même jour insistait sur les liens entre plusieurs ressources et sur les collections de liens conservées à part. Une note ou une association supplémentaire pouvait ainsi entourer un document sans qu'on réécrive celui-ci. Les pages restaient fermées; les fiches de liaison prenaient place sur une autre table.

L'indépendance des liens créait immédiatement une corvée de découverte. Un lien sortant situé dans son point de départ se rencontre en lisant ce point de départ. Un lien entrant, ou reliant deux ressources distantes, peut être rangé ailleurs. XLink appelait linkbases les documents qui rassemblent ces liens. Il disait expressément que leur découverte demandait davantage de travail: l'application devait retrouver à la fois la ressource de départ et le lien qui la concernait. Une page scellée n'a aucun moyen de deviner seule la présence d'un dossier extérieur.

Pour aider, la spécification définissait une valeur particulière de arcrole: http://www.w3.org/1999/xlink/properties/linkbase. Un arc portant ce rôle invitait l'application à charger un document XML servant de base de liens et à en extraire les liens étendus. Ce chargement préparait de futurs parcours; il n'affichait pas la base comme une page de destination. La valeur de présentation show n'avait donc pas d'effet pour cet arc, tandis que actuate indiquait à quel moment lancer la recherche. Les bases pouvaient même se renvoyer les unes aux autres. Le classeur pouvait contenir l'adresse d'un autre classeur; le bureau de liaison ne manquait pas de formulaires.

Le partage des responsabilités se lisait désormais dans l'architecture. Le propriétaire publiait la ressource. Un autre auteur pouvait publier les connexions, leurs rôles et leurs directions. L'application devait réunir les deux. XLink donnait une syntaxe à la relation et un moyen d'indiquer où charger une base de liens; l'itinéraire proposé au lecteur dépendait du travail concret de découverte et de traitement du logiciel.