microformats : les principes

Un facteur-clé de différenciation entre les microformats et d'autres formats sont les principes sur lesquels les microformats ont été recherchés, conçus et développés.

auteur/éditeur

Tantek Çelik

traduction

Christophe Ducamp

résumé des principes-clés

• résoudre un problème spécifique
• démarrer aussi simple que possible
  • résoudre d'abord les problèmes les plus simples
  • faire des améliorations évolutionnaires
• conçu d'abord pour les êtres humains, ensuite pour les machines
  • être présentable et parsable
  • la donnée visible est bien mieux pour les humains que la métadonnée invisible (voir : Principles of visibility and human friendliness).
  • adaptation aux comportements actuels et modèles d'usages, par ex (X)HTML, blogg
  • la facilité de publication est importante
• réutiliser des blocs de constructions provenant de standards massivement adoptés :
  • meaningful (X)HTML sémantique ayant du sens, , à savoir. POSH ou CHIC. Voir Principes de design XHTML sémantique pour plus de détails.
  • microformats existants
    • en tant qu'ensemble, par ex. utiliser hCard pour représenter les personnes
    • en partie, réutiliser des noms de classes sémantiques particuliers, en suivant les principes de nommage des microformats
  • schémas bien établis à partir de RFCs interopérables
• modularité / embarquement
  • design pour être réutilisé et embarqué dans des formats et microformats existants
• permet et encourage le développement décentralisé et distribué de contenus et services
  • encourage explicitement l'"esprit original du Web".

principes en rapport

Principes en rapport que la communauté des microformats réutilisent à partir d'autres paradigmes de design :

• DRY (Don't Repeat Yourself)
• Least Surprise
• Pareto Principle (80/20)

effets des principes

Buts, Objectifs et effets de quelques-uns des principes.

• Intégrité de la Donnée. L'un des objectifs communs que bon nombre des principes aident à réaliser est l'intégrité de la donnée.
  • Donnée visible = donnée plus pertinente. En concevant d'abord pour les humains et en rendant la donnée présentable (de ce fait vue et vérifiée par les humains), la donnée est inéluctablement plus pertinente, non seulement pour démarrer avec (car les erreurs sont facilement/rapidement remarquées par ceux qui voient les pages/sites), mais tout aussi bien au fil du temps en ce sens que les modifications sont remarquées et si la donnée devient obsolète, elle sera remarquée tout aussi bien. Ceci contraste directement aux "side files" et données invisibles que contenaient les tags <meta>.
  • Ne pas vous répéter vous-même (suivant DRY) - signifie qu'il y a de moindres chances pour l'incohérence
  • Intégrité multilangage. Peut-être pas un principe, mais beaucoup de ceux impliqués dans les microformats ont trouvés qu'utiliser UTF-8 de façon cohérente aide à s'assurer que le contenu de texte humain lui-même n'est pas corrompu, tout spécialement au moment d'utiliser des caractères non-ASCII7.

• Baisser les barrières à l'entrée pour les auteurs. L'un des buts des microformats est d'être un peu plus centré auteur dans la conception, plutôt que concentré-parseur, quand on les compare à d'autres efforts sur les formats. Ceci ne veut pas dire que nous essayons de faire que les choses soient complètement libres de tout effort poru les auteurs, parce que clairement nous n'en interrogeons que peu parmi eux, mais cela veut vraiment dire que nous leur en demandons moins que la plupart des autres efforts de standards, qui demandent aux auteurs d'apprendre de nouvaux langages, de créer de nouveaux fichiers, des espaces-noms etc. Par exemple le microformat hCalendar baisse la barrière à l'entrée pour les auteurs en comparaison avec le format iCalendar (RFC 2445) qui oblige l'auteur à apprendre un nouveau langage (.ics), à créer un fichier séparé .ics, etc. Le hCalendar en lui-même peut peut-être être facilité à travers la résolution de quelques problématiques-hCalendar, mais l'objectif plus général est même dans son état actuel, hCalendar baisse immédiatement la barrière à l'entrée pour les auteurs qui veulent publier et partager de l'information d'événement dans un format ouvert en comparaison aux précédents formats de calendrier. Les principes suivants aident à baisser la barrières pour les auteurs :
  • les humains d'abord, les machines en second. Un aspect d'être plus centré-humain en design est de faire qu'il soit plus facile pour les êtres humains en général de publier de l'information en microformats, plutôt que de simplement faire que ce soit plus facile pour les machines (programmes) de parser les microformats. Ceci peut sembler comme un compromis en ce sens qu'il existe beaucoup moins d'être humains qui développent ou écrivent des parseurs que ceux qui publient du contenu, et par conséquent rendre la publication plus facile profite à plus de personnes.
  • Note : pour être clair, le but ici est de baisser les barrières pour les auteurs, plutôt que d'éliminer à tout prix les barrières pour les auteurs. On devrait prendre le point de vue extrême que les auteurs ne devaient rien avoir à faire de différent, et que tout le travail devrait être fait par les parseurs qui devraient être produits aussi intelligents que possible (à travers des techniques telles que la détection d'entité contenu). De telles méthodes tendent à être probabilistes par nature, et à avoir différents degrés de succès et de pertinence, fournissant souvent des résultats "suffisamment bons" pour beaucoup d'applications. Néanmoins la détection de donnée probabiliste n'est pas suffisamment bonne quand l'un des buts est l'"Intégrité de la Donnée" comme cela est déclaré au-dessus. Par conséquent bien que nous reconnaissions l'utilité de la détection d'entité, les microformats ne dépendent pas et ne doivent pas dépendre de méthodes probabilistes telles que la détection d'entité.

• Ré-utilisation de données centrées sur l'utilisateur. En encourageant POSH / CHIC et le marquage additionnel sémantique à travers les microformats, les microformats en eux-mêmes permettent une réutilisation de données centrées sur l'utilisateur. La portabilité, à savoir la portabilité de données et la portabilité de réseau social, est un exemple de ré-utilisation de données centrées sur l'utilisateur.
  • Un peu de tout ça est réalisé implicitement par le fait que nous ne demandons pas aux utilisateurs de le faire. Spécifiquement, nous demandons aux auteurs de : marquer sémantiquement les données, ce qui permet une ré-utilisation générale, et d'éviter explicitement de leur demander de marquer la donnée sémantiquement et avec des verbes pour les ré-utilisations spécifiques.

citations

citations en rapport avec les principes :

simple

"The trick... is to make sure that each limited mechanical part of the Web, each application, is within itself composed of simple parts that will never get too powerful." — Tim Berners-Lee, Weaving The Web

"The beauty of this is its simplicity. If the plan gets too complex something always goes wrong." — John Goodman's character "Walter"

modulaire

"...if I had insisted everyone use HTTP, this would also have been against the principle of minimal constraint... the Web would come as a set of ideas that could be adopted individually in combination with existing or future parts." — Tim Berners-Lee, Weaving The Web

apparentées

Bon nombre des principes ont été / sont basés sur des hypothèses inversées explicitement à partir du développement typique de la technologie-format.

voir aussi

• priorités