principles-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (link on "réutiliser")
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
<h1>microformats : les principes</h1>
{{DISPLAYTITLE:microformats : les principes}}
{{TOC-right}}
 
Un facteur-clé de différenciation entre les [[microformats-fr|microformats]] et d'autres formats sont les principes sur lesquels les microformats ont été recherchés, conçus et développés.
Un facteur-clé de différenciation entre les [[microformats-fr|microformats]] et d'autres formats sont les principes sur lesquels les microformats ont été recherchés, conçus et développés.


Line 9: Line 9:
== résumé des principes-clés ==
== résumé des principes-clés ==
* résoudre un problème spécifique
* résoudre un problème spécifique
* démarrer aussi simple que possible
* [[start-simple-fr|démarrer aussi simple que possible]]
** [[solve simpler problems first-fr|résoudre d'abord les problèmes les plus simples]]
** [[solve simpler problems first-fr|résoudre d'abord les problèmes les plus simples]]
** faire des améliorations évolutionnaires
** faire des améliorations évolutionnaires
* conçu [[humans-first-fr|d'abord pour les êtres humains]], ensuite pour les machines
* conçu [[humans-first-fr|d'abord pour les êtres humains]], ensuite pour les machines
** être présentable ''et'' parsable
** être présentable ''et'' parsable
** la ''donnée visible'' est bien mieux pour les humains que la ''métadonnée invisible''
** la ''donnée visible'' est bien mieux pour les humains que la ''métadonnée invisible'' (voir : [http://tantek.com/log/2005/06.html#d03t2359 Principles of visibility and human friendliness]).
** adaptatption aux comportements actuels et modèles d'usages, par ex (X)HTML, blogg
** adaptation aux comportements actuels et modèles d'usages, par ex (X)HTML, blogg
** [http://tantek.com/log/2003/0813t1158.html#handauthoring la facilité de publication est importante]
** [http://tantek.com/log/2003/0813t1158.html#handauthoring la facilité de publication est importante]
* [[reuse-fr|réutiliser]] des blocs de constructions provenant de standards massivement adoptés :
* [[reuse-fr|réutiliser]] des blocs de constructions provenant de standards massivement adoptés :
** [http://tantek.com/presentations/2005/03/elementsofxhtml meaningful (X)HTML] [http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html sémantique] ayant du sens, , à savoir. [[posh-fr|POSH ou CHIC]]. Voir [[SemanticXHTMLDesignPrinciples-fr|Principes de design XHTML sémantique]] pour plus de détails.  
** [http://tantek.com/presentations/2005/03/elementsofxhtml meaningful (X)HTML] [http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html sémantique] ayant du sens, , à savoir. [[posh-fr|POSH ou CHIC]]. Voir [[SemanticXHTMLDesignPrinciples-fr|Principes de design XHTML sémantique]] pour plus de détails.  
** microformats existants
** microformats existants
*** en tant qu'ensemble, par ex. utiliser [[hcard)fr|hCard]] pour représenter les personnes
*** en tant qu'ensemble, par ex. utiliser [[hcard-fr|hCard]] pour représenter les personnes
*** en partie, réutiliser des noms de classes sémantiques particuliers, en suivant [[naming-principles-fr|les principes de nommage des microformats]]
*** en partie, réutiliser des noms de classes sémantiques particuliers, en suivant [[naming-principles-fr|les principes de nommage des microformats]]
** schémas bien établis à partir de RFCs interopérables
** schémas bien établis à partir de RFCs interopérables
Line 45: Line 45:


<div id="lowering-barriers-fr">
<div id="lowering-barriers-fr">
* '''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 clairment nous interrogeons que peu parmi eux, mais cela veut vraiment dire que nous leur en demandons moins que la plupart des autres efforts de standars, qui demandent aux auteurs d'apprendre de nouvaux langages, de créer de nouveaux fichiers, des [[namespaces-fr|espaces-noms]] etc.  Par exemple le microformat [[hcalendar-fr|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 [[hcalendar-issues-fr|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 :
* '''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 [[namespaces-fr|espaces-noms]] etc.  Par exemple le microformat [[hcalendar-fr|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 [[hcalendar-issues-fr|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'inforamtion 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.
** 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 <em>baisser</em> les barrières pour les auteurs, plutôt que d'<em>éliminer</em> à 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 <em>tout</em> le travail devrait être fait par les parseurs qui devraient être produits aussi intelligents que possible (à travers des techniques telles que  [http://www.google.com/search?hl=en&q=content+%22entity+detection%22 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é.
** Note : pour être clair, le but ici est de <em>baisser</em> les barrières pour les auteurs, plutôt que d'<em>éliminer</em> à 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 <em>tout</em> le travail devrait être fait par les parseurs qui devraient être produits aussi intelligents que possible (à travers des techniques telles que  [http://www.google.com/search?hl=en&q=content+%22entity+detection%22 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é.
</div>
</div>
Line 68: Line 68:
== apparentées==
== apparentées==
Bon nombre des principes ont été / sont basés sur des [http://tantek.com/log/2007/08.html#d31t2354 hypothèses inversées] explicitement à partir du développement typique de la technologie-format.
Bon nombre des principes ont été / sont basés sur des [http://tantek.com/log/2007/08.html#d31t2354 hypothèses inversées] explicitement à partir du développement typique de la technologie-format.
==voir aussi==
*[[priorities-fr|priorités]]

Latest revision as of 16:31, 18 July 2020


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

principes en rapport

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

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