L’article ci-dessous est une traduction qui s’inscrit dans la poursuite d’une volonté de mieux faire connaître quelques membres de la gouvernance des microformats. Vous trouverez ci-dessous un essai sur un billet de Jeremy Keith, un brillant orateur qui avait marqué son public lors de sa présentation à XTech. Ce billet, bien que technique me semble très intéressant pour révéler la volonté explicite de la communauté à calmer la profusion de propositions et/ou d’extensions de formats. Interprétons le aussi comme un appel pour nous inviter à être créatifs sur les remix possibles de quelques briques de construction existantes et stabilisées. Et comme toujours, cette traduction est bien imparfaite et reste ouverte au raffinage sur notre wiki de travail. Seul le lien original fait référence.
“Mashupez” les microformats
Quand j’ai fait ma présentation à XTech un peu prétentieusement titrée —Microformats : The Nanotechnology of the Semantic Web—j’ai poussé la métaphore globale de la nanotech à ses limites. L’une des choses dont j’ai parlé était la glu grise. Je faisais référence au danger qu’il y ait un microformat pour tout. Comme cela a été répété de nombreuses fois, si dans deux ou trois ans il existe des centaines de microformats, alors nous aurons échoué.
Il existe un danger de glu grise provenant d’un autre coin : la tentation de pousser inutilement des microformats existants. C’est arrivé quelques fois sur la liste de discussion des microformats. Je crois que cette tentation peut être combattue en utilisant la même mesure de protection qui protège le Web d’une surinfection de microformats… Le Processus (pousser la
musique dramatique).
La première question est de savoir s’il existe un vrai problème à résoudre. Souvenez-vous que les microformats fonctionnent sur le principe du 80/20, par conséquent si je propose une extension qui ne s’applique pas à environ 80% des cas d’utilisation et qui requiert plus que ces 20% d’efforts supplémentaires, alors le prix à payer est trop élevé.
L’étape suivante dans le processus est de regarder si un format existant résout déjà le problème. De mon point de vue, c’est l’objectif pour lequel l’appel aux extensions potentielles passe par une recherche de microformats sur le net.
Voici un exemple apparu récemment sur la liste de diffusion…
Pourquoi ne pas étendre hCardpour y ajouter un champ “date de décès” ?
Tout d’abord et à cette heure, je ne pense pas que ce soit un cas d’utilisation très commun mais laissons cela de côté un moment et concentrons-nous pour savoir si cela fait sens d’ajouter un nouveau champ à la spec hCard.
hCard est une représentation 1:1 de la vCard en HTML et la vCard n’a pas de champ “died”. Il existe néanmoins un bday pour la date de naissance. Ainsi, il ne semble pas déraisonnable de demander un champ correspondant pour la date de décès. Ici, par exemple, c’est la hCard d’un personnage historique qui encode une date de naissance mais il n’y a pas moyen d’encoder la date de décès :
<p class="vcard">
<span class=”fn”>Robert Hooke</span>
est né le
<abbr title=”1635-07-18″ class=”bday”>
18 juillet 1635
</abbr>
et décédé le
3 mars 1703.
</p>
Tel que cela se présente, ce n’est pas nécessaire. Il existe déjà un format pour encoder les dates de début et de fin. Ce format est hCalendar. Si vous reconsidérez une vie d’une personne comme un évènement, alors vous pouvez encoder sa naissance et sa date de décès :
<p class="vevent">
<span class=”summary”>Robert Hooke</span>
est né le
<abbr title=”1635-07-18″ class=”dtstart”>
18 juillet 1635
</abbr>
et décédé le
<abbr title=”1703-03-03″ class=”dtend”>
3 mars 1703
</abbr>.
</p>
Désormais vous avez encodé avec succès les données d’événements mais vous ne marquez pas explicitement cela comme étant une personne.
Un des principes de design des microformats est qu’ils peuvent être en-capsulés les uns dans les autres. Aussi, il n’y a pas de raison pour laquelle vous ne pouvez pas encoder une personne avec un événement comme ça :
<p class="vcard vevent">
<span class=”fn summary”>Robert Hooke</span>
est né le
<abbr title=”1635-07-18″ class=”dtstart bday”>
18 juillet 1635
</abbr>
et décédé le
<abbr title=”1703-03-03″ class=”dtend”>
3 mars 1703
</abbr>.
</p>
Et voilà ! Vous avez maintenant encodé la date de décès de la personne sans augmenter inutilement hCard.
Le truc est de ne pas rester trop fixé sur l’utilisation d’un format unique. Utilisez le bon outil pour faire le boulot.
Cela ressemble à la situation de développement front-end. Il y a trois technologies distinctes, chacune ayant son propre objectif :
- HTML pour la structure.
- CSS pour la présentation.
- Le Scripting DOM pour le comportement.
Ici aussi existe un danger d’essayer de trop étendre une technologie au delà de son objectif. D’où l’appel aux menus “CSS-only” et au Javascript qui génère le contenu de la page.
En y réfléchissant, l’existence d’un champ bday dans la hCard est une sorte de pseudo-classe :hover dans CSS. Placer des données d’événements à l’intérieur d’un format pour les détails de contacts est similaire à déraper sur une pente en plaçant des contrôles de comportements à l’intérieur de la présentation.
Au fur et à mesure que vous arrêter de vous borner à essayer de tout encoder sur un format unique alors tout un monde de possibilités s’ouvre à vous avec les microformats. Tout simplement en les encastrant les uns dans les autres. Le format hResumé est un amalgame de microformats existants : les “skills” marquées avec rel-tag, les précédents jobs marqués avec hCalendar, et ainsi de suite.
En outre, il y a eu un appel pour un microformat de généalogie. Mais je pense que l’information requise pour un arbre généalogique -au moins dans la situation 80/20- peut être gérée avec une combinaison de microformats existants :
- hCard pour les personnes
- hCalendar pour les durées de vie et
- XFN pour les relations.
J’adore vraiment en venir à des combinaisons inattendues de microformats. Cela revient à augmenter l’information sémantique de façon exponentielle.
En restant avec l’exemple hCard/hCalendar du dessus, supposez que j’ai utilisé l’article Wikipedia de Robert Hooke comme champ url :
<p class="vcard vevent">
<a class=”fn url summary”
href=”http://fr.wikipedia.org/wiki/Robert_Hooke”>
Robert Hooke
</a>
est né le
<abbr title=”1635-07-18″ class=”dtstart bday”>
18 juillet 1635
</abbr>
et mort le
<abbr title=”1703-03-03″ class=”dtend”>
3 mars 1703
</abbr>.
</p>
Du fait de l’espace tag des URLs de Wikipedia, je pourrais taguer le document actuel avec “Robert Hooke” en ajoutant rel-tag :
<p class="vcard vevent">
<a class=”fn url summary” rel=”tag”
href=”http://fr.wikipedia.org/wiki/Robert_Hooke”>
Robert Hooke
</a>
est né le
<abbr title=”1635-07-18″ class=”dtstart bday”>
18 juillet 1635
</abbr>
et mort le
<abbr title=”1703-03-03″ class=”dtend”>
3 mars 1703
</abbr>.
</p>
Et voyant que j’admire vraiment Robert Hooke je peux aussi encoder sa relation à moi sous “muse”
<p class="vcard vevent">
<a class=”fn url summary” rel=”tag muse”
href=”http://fr.wikipedia.org/wiki/Robert_Hooke”>
Robert Hooke
</a>
est né le
<abbr title=”1635-07-18″ class=”dtstart bday”>
18 juillet 1635
</abbr>
et mort le
<abbr title=”1703-03-03″ class=”dtend”>
3 mars 1703
</abbr>.
</p>
hCard, hCalendar, rel-tag et XFN tous ensemble dans une seule phrase. Les microformats sont suffisamment intéressants en eux-mêmes mais ils deviennent très puissants quand vous les mélangez ensemble.
