Summary

  • El W3C publicó XLink 1.0 como recomendación el 27 de junio de 2001. Además del enlace simple, definió enlaces extendidos con varios recursos y arcos que indicaban los recorridos posibles.
  • Esos enlaces podían guardarse fuera de los documentos enlazados. Las colecciones de enlaces entrantes o entre recursos remotos se llamaban linkbases; un programa tenía que descubrirlas para ofrecer sus rutas.

En la web habitual, el enlace tiene buenos modales: se presenta en la página antes de llevarnos a otra. El texto subrayado actúa como un cartel en la puerta. Ahora imaginemos tres documentos XML publicados por instituciones distintas. Un editor quiere establecer relaciones entre ellos, añadir notas y elegir qué camino conduce a cuál. Ninguno de los tres propietarios le ha dado permiso para reescribir sus archivos. La solución es guardar el plano de conexiones en otro sitio. El nuevo problema consiste en avisar al lector de que existe ese sitio.

La recomendación XLink 1.0 del W3C, fechada el 27 de junio de 2001, dio al XML un vocabulario de enlaces mediante atributos. El enlace simple resolvía el caso cercano al ancla de HTML: un recurso inicial local y otro identificado a distancia. El enlace extendido admitía más participantes. Los elementos locator señalaban recursos mediante referencias URI; los elementos de recurso local aportaban participantes incluidos junto al enlace; los arc describían los trayectos entre ellos. Aquello ya se parecía menos a una flecha y más a una centralita.

En la centralita, la dirección importaba. Un arco saliente iba de lo local a lo remoto. Uno entrante llegaba a lo local desde un punto remoto. Un arco de tercero conectaba dos recursos remotos. XLink consideraba remoto al recurso identificado por URI incluso si sus bytes estaban dentro del mismo documento XML. La etiqueta describía cómo se nombraba el recurso dentro del enlace, no los kilómetros entre los servidores.

Ese reparto permitía una maniobra editorial valiosa. Se podían describir conexiones alrededor de un documento sin tocar su texto. El anuncio original del W3C destacó los enlaces que reunían varios recursos y las colecciones almacenadas aparte de los recursos relacionados. También señaló el uso de información suplementaria asociada a un recurso que permanecía intacto. Los documentos seguían bajo llave; la mesa de conexiones estaba en otra habitación.

En ese punto aparecía la factura. Un enlace saliente que nace en la propia página se encuentra al leerla. Un enlace entrante puede hallarse en un archivo separado, lo mismo que uno que enlaza dos recursos ajenos. XLink llamó linkbases a los documentos que reúnen estas relaciones y advirtió que descubrirlas exige más trabajo. Para atravesar el enlace, la aplicación debe encontrar tanto el recurso inicial como la estructura de enlace. El documento visitado no puede enseñar automáticamente un camino que está guardado en una oficina cuya existencia desconoce.

La especificación ofreció una dirección para esa oficina. Un arco con el valor especial de arcrole http://www.w3.org/1999/xlink/properties/linkbase llevaba a la aplicación a cargar una base de enlaces XML y extraer de ella enlaces extendidos. Cargar la base era preparar rutas futuras, no mostrarle su archivo al usuario como página final. Por eso el valor show, que habla de presentación, se ignoraba en ese caso; actuate decidía cuándo se hacía la carga. Una base podía conducir a otra. La centralita había descubierto el placer administrativo de abrir sucursales.

En XLink, el autor de un documento controlaba su recurso; otro podía publicar la descripción de conexiones externas. El programa lector se encargaba de juntarlos. La norma daba forma a los enlaces y un modo de encontrar la base, mientras que la experiencia visible dependía de que la aplicación hiciera efectivamente esa búsqueda. Separar el enlace de la página ampliaba quién podía escribir el recorrido y convertía el descubrimiento en parte de su coste.