microformats-fr: Difference between revisions
m (→les principes des microformats: typo) |
|||
Line 57: | Line 57: | ||
Voir la [[Main_Page-fr|page principale]] pour une liste actuelle des spécifications de microformats, brouillons et discussions. | Voir la [[Main_Page-fr|page principale]] pour une liste actuelle des spécifications de microformats, brouillons et discussions. | ||
== | == Plus d'idées sur la façon dont les microformats sont différents == | ||
Il existe beaucoup de formats existants qui sont ''presque'' totalement inutiles/ignorés. | Il existe beaucoup de formats existants qui sont ''presque'' totalement inutiles/ignorés. | ||
Ils ne sont néanmoins pas ''complètement'' inutiles. Ils sont utiles en ce sens qu'ils illustrent ce qu'au moins quelqu'un a pensé qu'ils pourraient être utiles, ce qui malheureusement relève d'un inventeur seul travaillant à priori sans quelque expertise dans un domaine. | Ils ne sont néanmoins pas ''complètement'' inutiles. Ils sont utiles en ce sens qu'ils illustrent ce qu'au moins quelqu'un a pensé à quoi qu'ils pourraient être utiles, ce qui malheureusement relève d'un inventeur seul travaillant à priori sans quelque expertise dans un domaine. | ||
Ou il y a l'autre extrême. Beaucoup d'inventeurs en entreprise travaillant avec beaucoup d'expérience, sur-designant un format pour ce qui ''pourrait'' être demandé un jour. Dans les mauvais cas particuliers, les vendeurs de sociétés sont de connivence pour empêcher l'ouverture et/ou l'adoption par la communauté open source. Les standards média [http://dannyayers.com/archives/2005/09/24/qotd-23/ souffrent souvent de cette forme de positionnement délibérément "stratégique"]. | Ou il y a l'autre extrême. Beaucoup d'inventeurs en entreprise travaillant avec beaucoup d'expérience, sur-designant un format pour ce qui ''pourrait'' être demandé un jour. Dans les mauvais cas particuliers, les vendeurs de sociétés sont de connivence pour empêcher l'ouverture et/ou l'adoption par la communauté open source. Les standards média [http://dannyayers.com/archives/2005/09/24/qotd-23/ souffrent souvent de cette forme de positionnement délibérément "stratégique"]. | ||
Line 68: | Line 68: | ||
* Nous ne sommes pas des inventeurs isolés ; nous sommes une [http://microformats.org/discuss/ communauté]. | * Nous ne sommes pas des inventeurs isolés ; nous sommes une [http://microformats.org/discuss/ communauté]. | ||
* Nous ne travaillons pas [http:// | * Nous ne travaillons pas [http://fr.wikipedia.org/wiki/A_priori a-priori] ; nous exigeons de la documentation provenant d'exemples existants, des essais précédents sur les formats. Voir le [[process-fr|processus]]. | ||
* Quand | * Quand nous manquons d'une expertise dans un domaine, nous cherchons les experts du domaine pour la fournir, et nous nous immergeons nous-mêmes dans les exemples et l'art initial du domaine (voir point précédent) | ||
* Nous faisons | * Nous faisons notre travail dans l'[[Main_Page-fr|ouverture]] avec les [http://microformats.org/discuss/ forums de discussion ouverts]. | ||
* Nous sommes un mélange diversifié d'indépendants, d'entreprises, d'amateurs et d'enthousiastes. | * Nous sommes un mélange diversifié d'indépendants, d'entreprises, d'amateurs et d'enthousiastes. | ||
* Nous ne faisons pas d'over-design. | * Nous ne faisons pas d'over-design. Nous faisons de l'under-design, délibérément et puis n'ajoutons seulement des choses que quand elles sont absolument nécessaires. | ||
* Nous adoptons une politique de licence/copyright très libérale (CC,GMPG,IETF,W3C) et des positions de brevets (RF,IETF,W3C). | * Nous adoptons une politique de licence/copyright très libérale (CC,GMPG,IETF,W3C) et des positions de brevets (RF,IETF,W3C). | ||
* Nous nous auto-critiquons impitoyablement sur nos [ | * Nous nous auto-critiquons impitoyablement sur nos [[microformats-fr#les_principes_des_microformats principes]] afin de punir au-dessus. | ||
Quelques | Quelques personnes se demandent quel est l'objectif des standards (voulus) | ||
Pouquoi avez-vous besoin d'un but ? Plus souvent que non, la concentration | Pouquoi avez-vous besoin d'un but ? Plus souvent que non, la concentration prématurée sur le but tend à altérer les formats de données envers une application particulière qui peut ne pas du tout être pertinente. Par conséquent, plutôt que de se concentrer sur un but à priori, nous nous concentrons sur la modélisation du comportement existant, en sachant qu'une structure additionnelle parviendra à beaucoup d'usages intéressants, que nous ne pourrions pas prévoir à priori pour la plupart d'entre eux. | ||
Ceci est évidemment une approche très différente des efforts fournis sur les formats traditionnels de données. | Ceci est évidemment une approche très différente des efforts fournis sur les formats traditionnels de données. |
Revision as of 06:14, 3 August 2006
microformats
Que sont les microformats ?
les microformats sont
- un moyen de penser aux données
- des conventions de design pour les formats
- adaptées aux comportemnents actuels et aux formes d'usages ("Daller les chemins des vaches." - Adam Rifkin)
- hautement corrélés avec le XHTML sémantique, comme le real world semantics, AKA lowercase semantic web, comme le lossless XHTML
- décrits par la présentation de Tantek au SXSW : The Elements of Meaningful XHTML
- un ensemble de standards de formats de données ouverts et simples que beaucoup (y compris Technorati) sont actuellement en train de développer activement et d'implémenter pour un blogging plus/mieux structuré et la publication de micro-contenus web en général.
- ""Une révolution évolutionnaire"" - Ryan King
- tout ce qui est au-dessus.
ce que ne sont pas les microformats
- un nouveau langage
- infiniment extensibles et ouverts sans fins
- une approche complètement nouvelle qui jette ce qui fonctionne aujourd'hui
- une panacée pour toutes les taxonomies, ontologies et autres abstractions de la sorte
- en train de définir le monde entier, ou même simplement en train de faire bouillir l'océan
- rien de tout ce qui est au-dessus
les principes des microformats
- 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
- Design d'abord conçu pour les humains, ensuite pour les machines.
- Etre présentable et parsable
- les données visibles sont bien mieux pour les humains que les métadonnées invisibles
- s'adapter aux comportements actuels et aux modèles d'usages, par ex. (X)HTML, blog.
- la facilité d'écriture est importante
- réutilisation de briques de constructions provenant de standards largement adoptés.
- sémantique, (X)HTML ayant du sens. Voir Principes de Design XHTML sémantique pour plus de détails.
- microformats existants
- schémas bien établis venant des RFCs interopérables
- modularité / incorporabilité
- design pour être réutilisé et embarqué dans des formats et microformats existants
- permettre et encourager le développement décentralisé et distribué, les contenus, les services.
- encourager explicitement l'"esprit du Web" original.
- Principes en rapport que nous réutilisons d'autres paradigmes de design
- DRY (Don't Repeat Yourself)
- Least Surprise
- Pareto Principle (80/20)
- Intégrité des Données. L'un des objectifs communs que beaucoup des principes aident à parvenir est l'intégrité des données.
- Données visibles = données plus pertinentes. En concevant d'abord pour les humains et en rendant les données présentables (de ce fait visualisées et vérifiées par des humains, les données sont inévitablement plus pertinentes non seulement pour démarrer avec (parce que les erreurs sont rapidement/facilement remarquées par ceux qui visualisent les pages/les sites) mais au fil du temps, en ce sens que les modifications sont remarquées, et si les données deviennent démodées ou obsolètes, ceci sera plus probablement remarqué. Ceci est en contraste direct avec les "side files" et les données invisibles qui étaient contenues dans les
<meta>
tags. - Ne pas vous répéter vous-même (en anglais DRY) - veut dire qu'il y moins de chances pour l'incohérence.
- Intégrité multi-langages. Peut-être pas un principe, mais beaucoup de ceux impliqués par les microformats ont trouvé qu'utiliser de façon cohérente UTF-8 aide à s'assurer que le contenu de texte humain lui-même n'est pas corrompu, tout spécialement quand on utilise des caractères non-ASCII7.
- Données visibles = données plus pertinentes. En concevant d'abord pour les humains et en rendant les données présentables (de ce fait visualisées et vérifiées par des humains, les données sont inévitablement plus pertinentes non seulement pour démarrer avec (parce que les erreurs sont rapidement/facilement remarquées par ceux qui visualisent les pages/les sites) mais au fil du temps, en ce sens que les modifications sont remarquées, et si les données deviennent démodées ou obsolètes, ceci sera plus probablement remarqué. Ceci est en contraste direct avec les "side files" et les données invisibles qui étaient contenues dans les
microformats actuels
Voir la page principale pour une liste actuelle des spécifications de microformats, brouillons et discussions.
Plus d'idées sur la façon dont les microformats sont différents
Il existe beaucoup de formats existants qui sont presque totalement inutiles/ignorés.
Ils ne sont néanmoins pas complètement inutiles. Ils sont utiles en ce sens qu'ils illustrent ce qu'au moins quelqu'un a pensé à quoi qu'ils pourraient être utiles, ce qui malheureusement relève d'un inventeur seul travaillant à priori sans quelque expertise dans un domaine.
Ou il y a l'autre extrême. Beaucoup d'inventeurs en entreprise travaillant avec beaucoup d'expérience, sur-designant un format pour ce qui pourrait être demandé un jour. Dans les mauvais cas particuliers, les vendeurs de sociétés sont de connivence pour empêcher l'ouverture et/ou l'adoption par la communauté open source. Les standards média souffrent souvent de cette forme de positionnement délibérément "stratégique".
Nous cherchons à combattre tous ces problèmes avec l'approche microformat.
- Nous ne sommes pas des inventeurs isolés ; nous sommes une communauté.
- Nous ne travaillons pas a-priori ; nous exigeons de la documentation provenant d'exemples existants, des essais précédents sur les formats. Voir le processus.
- Quand nous manquons d'une expertise dans un domaine, nous cherchons les experts du domaine pour la fournir, et nous nous immergeons nous-mêmes dans les exemples et l'art initial du domaine (voir point précédent)
- Nous faisons notre travail dans l'ouverture avec les forums de discussion ouverts.
- Nous sommes un mélange diversifié d'indépendants, d'entreprises, d'amateurs et d'enthousiastes.
- Nous ne faisons pas d'over-design. Nous faisons de l'under-design, délibérément et puis n'ajoutons seulement des choses que quand elles sont absolument nécessaires.
- Nous adoptons une politique de licence/copyright très libérale (CC,GMPG,IETF,W3C) et des positions de brevets (RF,IETF,W3C).
- Nous nous auto-critiquons impitoyablement sur nos microformats-fr#les_principes_des_microformats principes afin de punir au-dessus.
Quelques personnes se demandent quel est l'objectif des standards (voulus)
Pouquoi avez-vous besoin d'un but ? Plus souvent que non, la concentration prématurée sur le but tend à altérer les formats de données envers une application particulière qui peut ne pas du tout être pertinente. Par conséquent, plutôt que de se concentrer sur un but à priori, nous nous concentrons sur la modélisation du comportement existant, en sachant qu'une structure additionnelle parviendra à beaucoup d'usages intéressants, que nous ne pourrions pas prévoir à priori pour la plupart d'entre eux.
Ceci est évidemment une approche très différente des efforts fournis sur les formats traditionnels de données.