RFC 6906: The 'profile' Link Relation Type
Date de publication du RFC : Mars 2013
Auteur(s) du RFC : E. Wilde (EMC Corporation)
Pour information
Première rédaction de cet article le 21 mars 2013
Les liens sont à la base du
Web, tout le monde le sait, mais on sait moins
que les liens sont typés, marqués avec un type qui indique leur
sémantique. Ainsi, le type profile, décrit dans
ce RFC, indique que le lien pointe vers un
profil, une spécification du format utilisé qui restreint les
possibilités d'un format donné.
Ce concept de profil est très fréquent en informatique (mais pas vraiment défini de manière rigoureuse). Lorsqu'on veut réutiliser un format mais qu'on n'a besoin que d'une petite partie de ses possibilités, on définit un profil qui consiste en gros à dire « dans tel format, n'utiliser que ci et ça ». Un profil peut être un peu plus compliqué qu'une simple restriction, par exemple il peut spécifier quelques extensions obligatoires. Le point important est qu'un programme qui sait traiter le format doit savoir traiter un fichier utilisant un profil de ce format. Ainsi, un podcast est un flux de syndication (et doit donc pouvoir être traité par tout programme gérant ces flux) mais avec des éléments spécifiques, qui peuvent être compris par un lecteur de podcasts, comme Apple iTunes.
Le format lui-même est indiqué par d'autres méthodes. Par
exemple, en HTTP, le format peut être indiqué
par le type de media (ou type MIME), comme
text/html. On peut aussi indiquer le format dans
le document lui-même : en HTML, on va utiliser la déclaration
DOCTYPE pour cela. Et pour indiquer
le profil ? Eh bien on va se servir d'un lien. (HTML 4 avait un attribut
profile dans l'élément
<head> mais il n'est pas sûr que HTML 5 le
garde et, de toute façon, la solution de ce RFC est plus
générale.)
Ces liens suivent le cadre général normalisé dans le RFC 8288. Ce cadre comprend notamment un registre
des types de liens (dans lequel se trouve désormais
profile), et plusieurs syntaxes pour mettre les
liens dans le document (cas du <link> de HTML)
ou dans le protocole d'accès (cas de l'en-tête
Link: de HTTP).
La distinction entre profils et formats est parfois subtile. Ainsi, XHTML n'est pas considéré comme un profil de XML parce que, pour les usages de XHTML, afficher du XML brut, sans les traitements spécifiques de XHTML, n'aurait guère d'intérêt. En revanche, hCard est bien un profil de XHTML, car, si un logiciel ne comprend pas hCard, le traiter et l'afficher comme du bête XHTML est utile.
Les profils sont identifiés par un URI
(comme les espaces de noms de
XML). Ces URI ne sont pas forcément
déréférençables (on ne peut pas toujours les donner à un
navigateur Web), ce sont juste des
identificateurs et le logiciel doit donc les traiter comme tels, pas
les présenter systématiquement comme des liens cliquables. Le RFC conseille
juste (ce n'est pas une obligation) de les rendre déréférençables, et
de mettre une jolie documentation du profil au bout de l'URI. Ainsi,
si je crée un profil de HTML nommé
http://www.example.org/profiles/myprofile, il est
recommandé (juste recommandé) qu'une page Web décrivant myprofile se
trouve effectivement à cette adresse.
Une curiosité : un document peut correspondre à plusieurs profils
et le lien de type profile peut donc pointer vers
une liste.
La section 5 du RFC donne quelques exemples concrets.
D'abord, hCard, déjà cité. Il permet de mettre
des vCard (RFC 6350) dans HTML. Son
URI est http://microformats.org/profile/hcard<link rel="profile" href="http://microformats.org/profile/hcard" />
et on trouve plein d'exemples dans la documentation
Autre exemple, Dublin Core, identifié par le
profil
http://dublincore.org/documents/2008/08/04/dc-html/
qui permet de mettre des métadonnées Dublin Core dans une page en
HTML. (Je n'en ai pas mis dans ce blog mais mes flux de
syndication, en XML, continnent du
Dublin Core.) Un exemple simple, les éléments Dublin Core ayant un nom commençant par DC :
<html> <head> <title>Expressing Dublin Core in HTML/XHTML meta and link elements</title> <link rel="profile" href="http://dublincore.org/documents/2008/08/04/dc-html/"/> <meta name="DC.title" lang="en" content="Expressing Dublin Core in HTML/XHTML meta and link elements" /> <meta name="DC.creator" content="Andy Powell, UKOLN, University of Bath" /> <meta name="DCTERMS.issued" scheme="DCTERMS.W3CDTF" content="2003-11-01" /> <meta name="DCTERMS.abstract" content="This document describes how qualified Dublin Core metadata can be encoded in HTML/XHTML <meta> elements" /> <meta name="DC.format" scheme="DCTERMS.IMT" content="text/html" /> </head>
Dernier exemple, déjà cité, les podcasts. Il n'y a pas
d'identificateur officiel (on pourrait utiliser l'URI http://www.apple.com/itunes/podcasts/specs.html).
Il existe désormais un registre de ces profils, créé par le RFC 7284.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)
