Microformats Wiki - User contributions [en]

hresume-examples-in-wild

2008-09-15T13:24:30Z

SebastienSauteur: changed my drupal basedir

<h1>hResume examples in the wild</h1>

This page is '''informative'''.

The following sites have published '''hResumes''', and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing, etc.

__TOC__

== New Examples ==
If you have an hResume on your own page, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hresume|hResume]] markup. Examples added without a URL to a page with hResume markup may be removed.

* [http://l2fprod.com/ Frederic Lavigne] has marked up his [http://l2fprod.com/cv/cv.php résumé] with hResume
* [http://matthewlevine.com/ Matthew Levine] has marked up his [http://matthewlevine.com/resume résumé] with hResume
* [http://www.jdclark.org/ Jordan Clark] has marked up his [http://www.jdclark.org/cv CV / résumé] with hResume
* [[User:SebastienSauteur|Sebastien Sauteur]] has marked up his [http://valeurdusage.net/drupal/cv C.V.] with hResume
* [[User:MarkNg|Mark Ng]] has marked up his [http://www.markng.co.uk/cv CV] with hResume.
* [[User:SidRoberts|Sid Roberts]] has marked up his [http://www.sidroberts.co.uk/cv/ CV] with hResume.
* [http://bergantinedesign.us/about/resume Joseph Bergantine] has marked up his resume with hResume
* [[User:NathanChase|Nathan Chase]] has marked up [http://www.nathanchase.com/resume.html his resume] with hResume.
* [[User:WikiObert|Alberto Ramacciotti]] has marked up an italian and an english version of his h[http://obertfsp.com/cv.html Resume].
* [[User:JaredEssig|Jared Essig]] has styled and marked up his h[http://prochor.us/resume Resume].
* [[User:Dreamisle|David Millar]] has *hopefully successfully* marked up [http://thegriddle.net/pages/resume his Resume] with hResume.
* [[User:Bczerniak|Brad Czerniak]] has created [http://brad.hawidu.com his Resume] with hResume.
* [[User:BenDodson|Ben Dodson]] has marked up [http://bendodson.com/cv/ his CV] with hResume.
* [[User:Twoplayer|Stephen Kelly]] has marked up his [http://www.twoplayer.net/stephen-kelly/cv.php CV] with hResume.
* [[User:MattWilliams|Matt Williams]] has marked up his [http://mattwilliamsnyc.com/resume/ resume] with hResume.
* [[User:Niall Kennedy|Niall Kennedy]] has marked up his [http://www.niallkennedy.com/about/resume.html résumé] with hResume.
* [[User:ManasTungare|Manas Tungare]] has marked up his [http://manas.tungare.name/resume/ Résumé] with hResume.
* [[User:Eferraiuolo|Eric Ferraiuolo]] has marked up his [http://eric.ferraiuolo.name/resume/ Resume] with hReesume
* [[User:ChristopheDucamp|Christophe Ducamp]] has marked up his [http://www.elanceur.org/CV_ChristopheDucampFr.html C.V.] with hResume
* [[User:RichardDavies|Richard Davies]] has marked up his [http://www.richarddavies.us/resume/ resume] as an hResume.
* [[User:JeffMcNeill|jeffmcneill]] has marked up [http://jeffmcneill.com/microformats/hresume-jeffmcneill.html his resume] with hResume
* Actor [[User:DavidSwain|David Swain]] has marked up his [http://davidswain.co.uk/cv cv] as an hResume.
* [[User:CiaranMc|Ciaran McNulty]] has marked up his [http://ciaranmcnulty.com/cv/html CV] as an hResume.
* [[User:RobCrowther|Rob Crowther]] has marked up his [http://www.dotrob.com/cv.html resume] as an hResume.
* [[User:Ajaswa|Andrew Jaswa]] has marked up his [http://www.gotkicked.net/hresume resume] as an hResume.
* [[User:ScottWallick|Scott Allan Wallick]] has [http://scottwallick.com/about/resume/ his resume] as an hResume.
* Ed Lau has [http://www.edlabs.net/ his resume] marked up with hResume.
* [[User:AndySmith|Andy Smith]] has marked up [http://ymkm.com/AndySmith.html his CV] with hResume.
* [[User:BruceDailey|Bruce Dailey]] has marked up his [http://www.jciti.com/cv/cv.php resume] as an hResume.
* [[User:JesseNewland|Jesse Newland]] has marked up his [http://resume.jnewland.com resume] as an hResume.
* [[User:Harriyott|Simon Harriyott]] has his [http://harriyott.com/cv.aspx curriculum vitae] as an hResume.
* [[User:BradT|Brad Touesnard]] has scraped together [http://brad.touesnard.com/documents/resume/ his resume] with the [http://brad.touesnard.com/projects/wordpress/linkedin-hresume/ LinkedIn hResume for Wordpress] plugin.
* [[User:ChadL|Chad Lindstrom]] has extended his [http://chadlindstrom.ca/resume/ resume] with hResume.
* Dawn Waswick has marked up [http://www.miniminx.com/portfolio/resume.cfm her CV] with hResume.
* [[User:Rolandinsh|Rolands Umbrovskis]] has [http://www.rolandinsh.lv/?ro=hResume marked up his CV] with hResume.
* [http://linkedin.com/ LinkedIn] has ~9 million Public Profiles marked up in hResume, e.g. [http://www.linkedin.com/in/steveganz Steve Ganz's Public Profile].
* [http://steinhardt.nyu.edu/ NYU Steinhardt] has [http://steinhardt.nyu.edu/faculty_bios/list/Faculty 240+ faculty bios marked up], e.g. [http://steinhardt.nyu.edu/faculty_bios/view/Susan_Murray]. ([[User:WizardIsHungry|Jon Williams]])
* [[User:ClintAndrewHall|Clint Hall]] has marked up his [http://www.clintandrewhall.com/resume.html resume] as an hResume.
* [[User:Csarven|Sarven Capadisli]] has marked up his [http://www.csarven.ca/cv Curriculum Vitae] as an hResume.
* [[User:Jax|Xavier Roy]] has marked his [http://xavierroy.com/resume/ resume] with hResume
* [[User:SanchTheFat|Robert O'Rourke]] has marked up his [http://robert.o-rourke.org/ CV] with hResume.
* [[User:Keri Henare|Keri Henare]] has marked up [http://www.kerihenare.com/cv/ his Curriculum Vitae] using hResume.
* [[User:Kwilson|Kenn Wilson]] has marked up [http://www.six23.net/resume/kenn-wilson.html his resume] using hResume, following [[User:Ralph Brandi|Ralph Brandi]]'s method of using object.include.
* [[User:Ralph Brandi|Ralph Brandi]] has [http://www.brandi.org/ralph/resume/ marked up his resume] with hResume, additionally using the object.include method to associate one description with three hCalendar experiences.
* [[User:Pat Ramsey|Pat Ramsey]] has his [http://www.patramsey.net/resume.html resume] marked up as an hResume.
* [[User:Wim Le Page|Wim Le Page]] has also marked up [http://adrem.ua.ac.be/~wlepage/curriculum-vitae/ his curriculum vitae] as an hResume.
* [[user:Jonathan Arkell|Jonathan Arkell]] has posted an [http://portfolio.jonnay.net/cv/ hResume] on his portfolio website.
* [http://steve.ganz.name/hresume/ Steve Ganz - hResume 0.1]
* [[User:Dave Cardwell|Dave Cardwell]] has marked up [http://davecardwell.co.uk/cv/ his curriculum vitae] as an hResume.
* [[User:EdwardOConnor|Edward O'Connor]]'s [http://edward.oconnor.cx/resume/ resume] is in hResume, and has some experimental JavaScript in it to extract a skill summary from the resume.
* [[User:Lindsey Simon|Lindsey Simon]] has his [http://www.commoner.com/~lsimon/lindsey_simon_resume.html resume] marked up as an hResume - with lots of thanks to Pat Ramsey.
* [[User:Ben Ward|Ben Ward]] has published [http://ben-ward.co.uk/cv his CV] with hResume.
* [http://www.kelleychambers.com Kelley Chambers] has published her [http://www.kelleychambers.com/resume resume] via [http://www.ssdesigninteractive.com/ssdesign/?p=96 Sajid Saiyed's Microformat hResume Plugin for Wordpress].
* [[User:Fishy5|Brennan Falkner]] used hResume to markup his [http://my.usf.edu/bbcswebdav/users/bfalker/resume.html resume].
* [http://www.zachary.com/creemer/resume.html David Creemer's resume] uses hResume, with thanks to Pat Ramsey for the CSS.
* [[User:ChristophBurgdorfer|Christoph Burgdorfer]] has integrated his hResume into a [http://emcons.net/index.php mashup].

== Examples with some problems ==

If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hresume|hResume spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hresume-faq|hResume FAQ]], or raise any queries on [[hresume-issues|hResume Issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you. 

* Inga Scholes had <nowiki>http://inga-art.co.uk/cv</nowiki> her CV marked up with hResume.
** '''invalid''' - hResume version missing as of 2007-10-28.
* [[User:RudyDesjardins|Rudy Desjardins]] has marked up his [http://rudy.theendless.org/resume/index.html resume] as an hResume.
** '''Invalid''' : hCard seems invalid
* [[User:MattBosworth|Matt Bosworth]] has marked up his chronological [http://www.codetastic.com/resume-chrono.html resume] and his functional [http://www.codetastic.com/resume-functional.html resume] with hResume.
** '''Invalid''' -- hCalendar's summaries to be specified
* [[User:AndrewPendrick|Andrew Pendrick]] has marked up his [http://www.andrewpendrick.co.uk/cv.html resume] as an hResume.
**'''Invalid''' - hCalendars's summaries to be specified (per Operator).[[User:ChristopheDucamp|xtof]]
* [[User:WebOrganics|Martin McEvoy]] has cobbled together his [http://weborganics.co.uk/hResume/ resume] as a hResume.
**'''Invalid''' - Three hCalendars have empty summary; several tags are invalid (per Operator). [[User:AndyMabbett|Andy Mabbett]] 22:48, 1 Sep 2007 (PDT)
* [[User:DmytroShteflyuk|Dmytro Shteflyuk]] has marked up [http://kpumuk.info/curriculum-vitae/ his resume] as an hResume.
** Invalid; job titles contain hCards without a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:27, 1 May 2007 (PDT)
* [[user:Izo|Mathieu Drouet]] has posted an [http://izo.aucuneid.com/hresume.html hResume].
** ''Incorrect root class name hResume? -- [[DavidJanes]]''
* [[User:Stauciuc|Sergiu Sebastian Tauciuc]] has his [http://www.sergiutauciuc.ro/en/cv.html curriculum vitae] as an hResume.
** '''Invalid''' - no contact vCard specified. [[User:AndyMabbett|Andy Mabbett]] 04:05, 10 Mar 2007 (PST)

== Reviewed Examples ==

If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

== Related Pages ==
{{hresume-related-pages}}

hresume-examples-in-wild

2008-06-14T13:36:29Z

SebastienSauteur: added hresume

<h1>hResume examples in the wild</h1>

This page is '''informative'''.

The following sites have published '''hResumes''', and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing, etc.

__TOC__

== New Examples ==
If you have an hResume on your own page, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hresume|hResume]] markup. Examples added without a URL to a page with hResume markup may be removed.

* [[User:SebastienSauteur|Sebastien Sauteur]] has marked up his [http://valeurdusage.net/drupal62/cv C.V.] with hResume
* [[User:MarkNg|Mark Ng]] has marked up his [http://www.markng.co.uk/cv CV] with hResume.
* [[User:SidRoberts|Sid Roberts]] has marked up his [http://www.sidroberts.co.uk/cv/ CV] with hResume.
* [http://bergantinedesign.us/about/resume Joseph Bergantine] has marked up his resume with hResume
* [[User:NathanChase|Nathan Chase]] has marked up [http://www.nathanchase.com/resume.html his resume] with hResume.
* [[User:WikiObert|Alberto Ramacciotti]] has marked up an italian and an english version of his h[http://obertfsp.com/cv.html Resume].
* [[User:JaredEssig|Jared Essig]] has styled and marked up his h[http://prochor.us/resume Resume].
* [[User:Dreamisle|David Millar]] has *hopefully successfully* marked up [http://thegriddle.net/pages/resume his Resume] with hResume.
* [[User:Bczerniak|Brad Czerniak]] has created [http://brad.hawidu.com his Resume] with hResume.
* [[User:BenDodson|Ben Dodson]] has marked up [http://bendodson.com/cv/ his CV] with hResume.
* [[User:Twoplayer|Stephen Kelly]] has marked up his [http://www.twoplayer.net/stephen-kelly/cv.php CV] with hResume.
* [[User:MattWilliams|Matt Williams]] has marked up his [http://mattwilliamsnyc.com/resume/ resume] with hResume.
* [[User:Niall Kennedy|Niall Kennedy]] has marked up his [http://www.niallkennedy.com/about/resume.html résumé] with hResume.
* [[User:ManasTungare|Manas Tungare]] has marked up his [http://manas.tungare.name/resume/ Résumé] with hResume.
* [[User:Eferraiuolo|Eric Ferraiuolo]] has marked up his [http://eric.ferraiuolo.name/resume/ Resume] with hReesume
* [[User:ChristopheDucamp|Christophe Ducamp]] has marked up his [http://www.elanceur.org/CV_ChristopheDucampFr.html C.V.] with hResume
* [[User:RichardDavies|Richard Davies]] has marked up his [http://www.richarddavies.us/resume/ resume] as an hResume.
* [[User:JeffMcNeill|jeffmcneill]] has marked up [http://jeffmcneill.com/microformats/hresume-jeffmcneill.html his resume] with hResume
* Actor [[User:DavidSwain|David Swain]] has marked up his [http://davidswain.co.uk/cv cv] as an hResume.
* [[User:CiaranMc|Ciaran McNulty]] has marked up his [http://ciaranmcnulty.com/cv/html CV] as an hResume.
* [[User:RobCrowther|Rob Crowther]] has marked up his [http://www.dotrob.com/cv.html resume] as an hResume.
* [[User:Ajaswa|Andrew Jaswa]] has marked up his [http://www.gotkicked.net/hresume resume] as an hResume.
* [[User:ScottWallick|Scott Allan Wallick]] has [http://scottwallick.com/about/resume/ his resume] as an hResume.
* Ed Lau has [http://www.edlabs.net/ his resume] marked up with hResume.
* [[User:AndySmith|Andy Smith]] has marked up [http://ymkm.com/AndySmith.html his CV] with hResume.
* [[User:BruceDailey|Bruce Dailey]] has marked up his [http://www.jciti.com/cv/cv.php resume] as an hResume.
* [[User:JesseNewland|Jesse Newland]] has marked up his [http://resume.jnewland.com resume] as an hResume.
* [[User:Harriyott|Simon Harriyott]] has his [http://harriyott.com/cv.aspx curriculum vitae] as an hResume.
* [[User:BradT|Brad Touesnard]] has scraped together [http://brad.touesnard.com/documents/resume/ his resume] with the [http://brad.touesnard.com/projects/wordpress/linkedin-hresume/ LinkedIn hResume for Wordpress] plugin.
* [[User:ChadL|Chad Lindstrom]] has extended his [http://chadlindstrom.ca/resume/ resume] with hResume.
* Dawn Waswick has marked up [http://www.miniminx.com/portfolio/resume.cfm her CV] with hResume.
* [[User:Rolandinsh|Rolands Umbrovskis]] has [http://www.rolandinsh.lv/?ro=hResume marked up his CV] with hResume.
* [http://linkedin.com/ LinkedIn] has ~9 million Public Profiles marked up in hResume, e.g. [http://www.linkedin.com/in/steveganz Steve Ganz's Public Profile].
* [http://steinhardt.nyu.edu/ NYU Steinhardt] has [http://steinhardt.nyu.edu/faculty_bios/list/Faculty 240+ faculty bios marked up], e.g. [http://steinhardt.nyu.edu/faculty_bios/view/Susan_Murray]. ([[User:WizardIsHungry|Jon Williams]])
* [[User:ClintAndrewHall|Clint Hall]] has marked up his [http://www.clintandrewhall.com/resume.html resume] as an hResume.
* [[User:Csarven|Sarven Capadisli]] has marked up his [http://www.csarven.ca/cv Curriculum Vitae] as an hResume.
* [[User:Jax|Xavier Roy]] has marked his [http://xavierroy.com/resume/ resume] with hResume
* [[User:SanchTheFat|Robert O'Rourke]] has marked up his [http://robert.o-rourke.org/ CV] with hResume.
* [[User:Keri Henare|Keri Henare]] has marked up [http://www.kerihenare.com/cv/ his Curriculum Vitae] using hResume.
* [[User:Kwilson|Kenn Wilson]] has marked up [http://www.six23.net/resume/kenn-wilson.html his resume] using hResume, following [[User:Ralph Brandi|Ralph Brandi]]'s method of using object.include.
* [[User:Ralph Brandi|Ralph Brandi]] has [http://www.brandi.org/ralph/resume/ marked up his resume] with hResume, additionally using the object.include method to associate one description with three hCalendar experiences.
* [[User:Pat Ramsey|Pat Ramsey]] has his [http://www.patramsey.net/resume.html resume] marked up as an hResume.
* [[User:Wim Le Page|Wim Le Page]] has also marked up [http://adrem.ua.ac.be/~wlepage/curriculum-vitae/ his curriculum vitae] as an hResume.
* [[user:Jonathan Arkell|Jonathan Arkell]] has posted an [http://portfolio.jonnay.net/cv/ hResume] on his portfolio website.
* [http://steve.ganz.name/hresume/ Steve Ganz - hResume 0.1]
* [[User:Dave Cardwell|Dave Cardwell]] has marked up [http://davecardwell.co.uk/cv/ his curriculum vitae] as an hResume.
* [[User:EdwardOConnor|Edward O'Connor]]'s [http://edward.oconnor.cx/resume/ resume] is in hResume, and has some experimental JavaScript in it to extract a skill summary from the resume.
* [[User:Lindsey Simon|Lindsey Simon]] has his [http://www.commoner.com/~lsimon/lindsey_simon_resume.html resume] marked up as an hResume - with lots of thanks to Pat Ramsey.
* [[User:Ben Ward|Ben Ward]] has published [http://ben-ward.co.uk/cv his CV] with hResume.
* [http://www.kelleychambers.com Kelley Chambers] has published her [http://www.kelleychambers.com/resume resume] via [http://www.ssdesigninteractive.com/ssdesign/?p=96 Sajid Saiyed's Microformat hResume Plugin for Wordpress].
* [[User:Fishy5|Brennan Falkner]] used hResume to markup his [http://my.usf.edu/bbcswebdav/users/bfalker/resume.html resume].
* [http://www.zachary.com/creemer/resume.html David Creemer's resume] uses hResume, with thanks to Pat Ramsey for the CSS.
* [[User:ChristophBurgdorfer|Christoph Burgdorfer]] has integrated his hResume into a [http://emcons.net/index.php mashup].

== Examples with some problems ==

If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hresume|hResume spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hresume-faq|hResume FAQ]], or raise any queries on [[hresume-issues|hResume Issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you. 

* Inga Scholes had <nowiki>http://inga-art.co.uk/cv</nowiki> her CV marked up with hResume.
** '''invalid''' - hResume version missing as of 2007-10-28.
* [[User:RudyDesjardins|Rudy Desjardins]] has marked up his [http://rudy.theendless.org/resume/index.html resume] as an hResume.
** '''Invalid''' : hCard seems invalid
* [[User:MattBosworth|Matt Bosworth]] has marked up his chronological [http://www.codetastic.com/resume-chrono.html resume] and his functional [http://www.codetastic.com/resume-functional.html resume] with hResume.
** '''Invalid''' -- hCalendar's summaries to be specified
* [[User:AndrewPendrick|Andrew Pendrick]] has marked up his [http://www.andrewpendrick.co.uk/cv.html resume] as an hResume.
**'''Invalid''' - hCalendars's summaries to be specified (per Operator).[[User:ChristopheDucamp|xtof]]
* [[User:WebOrganics|Martin McEvoy]] has cobbled together his [http://weborganics.co.uk/hResume/ resume] as a hResume.
**'''Invalid''' - Three hCalendars have empty summary; several tags are invalid (per Operator). [[User:AndyMabbett|Andy Mabbett]] 22:48, 1 Sep 2007 (PDT)
* [[User:DmytroShteflyuk|Dmytro Shteflyuk]] has marked up [http://kpumuk.info/curriculum-vitae/ his resume] as an hResume.
** Invalid; job titles contain hCards without a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:27, 1 May 2007 (PDT)
* [[user:Izo|Mathieu Drouet]] has posted an [http://izo.aucuneid.com/hresume.html hResume].
** ''Incorrect root class name hResume? -- [[DavidJanes]]''
* [[User:Stauciuc|Sergiu Sebastian Tauciuc]] has his [http://www.sergiutauciuc.ro/en/cv.html curriculum vitae] as an hResume.
** '''Invalid''' - no contact vCard specified. [[User:AndyMabbett|Andy Mabbett]] 04:05, 10 Mar 2007 (PST)

== Reviewed Examples ==

If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

== Related Pages ==
{{hresume-related-pages}}

User:SebastienSauteur

2008-06-14T13:33:21Z

SebastienSauteur: change my url

bonjour/hi,

* ClaimId : http://valeurdusage.net
* French speaking and non programmer, I discovered MicroFormats thanks to ChristopheDucamp, who spotted them to me during the BarCamp session in Paris.
* I'll try to help for the translation into french of some of the pages here.
----
[http://microformats.org/wiki?title=User_talk:SebastienSauteur&action=edit Laisser un message ? / Leave a message ?]

User:SebastienSauteur

2007-06-05T10:08:28Z

SebastienSauteur:

User:SebastienSauteur

2007-06-05T10:07:52Z

SebastienSauteur: màj

bonjour/hi,

* ClaimId : http://claimid.com/sebastiensauteur
* French speaking and non programmer, I discovered MicroFormats thanks to ChristopheDucamp, who spotted them to me during the BarCamp session in Paris.
* I'll try to help for the translation into french of some of the pages here.

Also, i have in mind a (possible?) kind of microformat usage. We're gonna have presidential elections in France next year. Candidates are soon going to unveil their programms.. how to "link" ? Would it be possible to use microformats, in such a way to articulate some kind of "hVotes" with some kind of "hPoliticalPrograms". Adding microstructuration to candidate programms (may be onto a dedicated wiki), and invite people to express their mind using "hVotes" against those proposals.

Then aggregate decentralized votes, and aggregate and compare "sort of centralized" programms. At this time, i don't know if and how it's possible to do it. It would be obviously, a sort of experience. I'm going to help translate first the "process" page, may be i'll see clearer after...

----
[http://microformats.org/wiki?title=User_talk:SebastienSauteur&action=edit Laisser un message ? / Leave a message ?]

introduction-fr

2006-06-27T15:36:15Z

SebastienSauteur: à relire.

__NOTOC__

<h1> Introduction aux Microformats </h1>

Related: [[press-fr|presse]], [[presentations-fr|présentations]], [[podcasts-fr|podcasts]], [[suggested-reading-fr|lectures suggérées]], [[testimonials-fr|testimoniaux]]

__TOC__

== Que sont les Microformats ? ==

Les microformats sont les "dictionnaires" du contenu sémantique XHTML. Ils ont pour objet de codifier le contenu HTML riche-en-information couramment utilisé, de telle façon à ce que le contenu sémantique puisse être extrait par une machine. En bref, ils sont la manière la plus simple d'architecturer des données (ou formats de données) destinés à être réutilisés sur le Web.

== Pourquoi les Microformats ==

Pourquoi en sommes-nous venus aux microformats?

En bref, les microformats sont la convergence d'un certain nombre de tendances :
# une étape à venir logique dans l'évolution du "web design" et l'architecturage de l'information.
# une façon pour les éditeurs autonomes de publier eux-mêmes une information plus riche, sans devoir s'en remettre à des services centralisés.
# la reconnaissance du fait que les efforts "traditionnels" en matière de métadonnées ont soit échoué, soit pris tellement de temps pour engranger une quelconque adoption, qu'une nouvelle approche était nécessaire
# une façon d'utiliser le (X)HTML pour les données (data).

=== Evolution du Web Design ===

Au commencement (1990), il y avait le [http://www.w3.org/MarkUp/ HTML], et il convenait bien. Il était simple, minimal, et utilisé pour baliser semantiquement les données visible de l'utilisateur (texte) et les partager sur le World Wide Web.

Ensuite vint la [http://en.wikipedia.org/wiki/Browser_wars guerre des navigateurs] (1994-1999) qui vit les éditeurs dominants de navigateurs ''took their turns'' en introduisant des étiquettes "innovantes" pour la presentation, donnant aux auteurs/designers typiques du web ce qu'ils voulaient : un semblant de controle sur la presentation de leurs pages web. Le résulat : [http://www.w3.org/TR/REC-html32 HTML 3.2] "standardisa" ces innovations "defacto" en terme de présentation.

L'introduction de [http://www.w3.org/TR/REC-CSS1 CSS1] (1996) et le semantiquement plus riche [http://www.w3.org/TR/REC-html40/ HTML4] (1998) apportèrent une lueur d'espoir, mais ce n'est que des années plus tard (2000-2001), avec l'introduction d'implémentations pleinement conformes (ou presque) à CSS1/HTML4 (IE5/Mac, IE6/Windows, Netscape 6) que l'usage par les "web designers" de CSS dans leurs pages web, devint possible en pratique. Les leaders au sein des communautés commencèrent à furieusement adopter et promouvoir CSS (même s'il fallait en passer par [http://www.tantek.com/log/2004/07.html#ie5macbandpass un] [http://tantek.com/CSS/Examples/boxmodelhack.html "hack"] [http://www.tantek.com/CSS/Examples/midpass.html ou] [http://tantek.com/CSS/Examples/highpass.html deux]) et l'efficacité et l'amélioration de la productivité que leur apportait la séparation de la présentation et du balisage, resta néanmoins le fait d'une petite minorité agissante.

L'introduction de la version "redesignée" 100% CSS de "Wired News", et le superbe [http://csszengarden.com/ CSS Zen Garden] (2002-2003) marquèrent le "tipping point" du CSS. Avec la présentation claire et évidente de la beauté visuelle et de la pleine créativité, il apparut soudain comme une évidence aux designers du monde entier, ils réalisèrent que c'était là le futur du "web design". Les balisages à des fins de présentation par <code><FONT></code>, <code><TABLE></code>, et <code>spacer.gif</code> furent laissé de côté par tous les web designers qui se respectaient, et qui découvrirent la flexibilité presque infinie des <code><div></code>, <code><span></code>, et de l'attribut 'class'. Quelques uns dans la communauté commencèrent même à adopter quelques uns des éléments les plus sémantiques du HTML: <code><p></code>, <code><h1></code>...<code><h6></code>, <code><ol></code>, <code><ul></code>, <code><li></code>, <code><em></code>, <code><strong></code>. Les leaders au sein de la communauté s'exercèrent aux limites sémantiques du HTML4 strict (experimenté avec XHTML) et documentèrent [http://www.simplebits.com/publications/solutions/ les "best practices"].

Alors que la communauté se mit à suivre rapidement les traces qu'ils avaient marquées, les leaders commencèrent à se heurter aux limites du (X)HTML semantique. D'autres ''subcultures'' essayaient de réécrire le monde dans leur(s) propre(s) language(s) (<abbr title="Resource Description Framework">[http://www.w3.org/RDF/ RDF]</abbr>, [[plain-xml|"plain" XML]], <abbr title="Scalable Vector Graphics">[http://www.w3.org/TR/SVG/ SVG]</abbr>), sans toutefois avoir beaucoup d'impact sur le World Wide Web, qui exigeait des données présentables aux humains, compatibles avec les navigateurs que les gens utilisaient déjà. [http://en.wikipedia.org/wiki/Social_software Le "Social Software"] et les [http://en.wikipedia.org/wiki/Blogs Blogs], écrits par cette nouvelle génération de "web designers" et de programmeurs, commencèrent à décoller.

Des "patterns" naturels émergèrent de la façon dont les gens utilisaient les systèmes de blogs, en mettant des choses sous forme de listes, par exemple des listes d'autres bloggueurs (connues sous le nom de "blogrolls"), et les annotant avec des informations representant les types de rapports, tels que "ai rencontré", "amis", "famille", etc. Le premier microformat, <abbr title="XHTML Friends Network">[http://gmpg.org/xfn/ XFN]</abbr>, fut conçu de façon à correspondre à ces comportements, et [http://tantek.com/log/2003/12.html#L20031215t0830 introduit dans la communauté des bloggueurs] (2003-2004), qui l'adopta en quelques semaines. Le [http://gmpg.org GMPG] fut formé en tant que "home" pour XFN, et documenta quelques [http://gmpg.org/principles principes de design] clés, plus tard adoptés pour les microformats. La notion clé, que le (X)HTML semantique pouvait être étendu, avait été introduite et acceptée par la communauté.

En comprenant, en utilisant, et en combinant les briques du (X)HTML semantique, ainsi qu'en statuant que le (X)HTML semantique pourrait être étendue de façon valide ''via'' de nouvelle valeur "rel", "meta name", and "class values", définie dans des profiles (X)HTML dans le [http://gmpg.org/xmdp format XMDP], la communauté commença à concevoir et développper de nombreux microformats supplémentaires (2004-2005). Des "patterns" supplémentaires émergèrent de la communauté des bloggueurs, et chaque aggrégat de comportement humain entraîna la conception de microformats simples et adaptatif pour répondre à ses besoins. Les contrats de licenses Creative Commons devinrent populaires et [[rel-license]] fut proposé. "Outlines" et listes : [[xoxo|XOXO]]. Contact info: [[hcard|hCard]]. Calendriers et évènements [[hcalendar|hCalendar]].

En faisant usage de ces toutes nouvelles briques, les communautés oeuvrant dans le "web design" et l'architecture informationnelle n'étaient plus dès lors limitées par la sémantique prédéfinie du HTML4 (elles n'avaient plus non plus à faire de compromis entre présentation "humaine" et facilité d'édition, ce dont d'autres tentatives manquaient fortement). 2005 pourrait bien être l'année où les microformats devinrent l'"étape suivante" de l'évolution du web.

=== L'Attrait de la Simplicité ===

* Les microformats sont un effort simple qui a séduit de nombreuses personnes frustrées par des efforts complexes par le passé. On peut voir là un parallèle avec REST dans le monde des "web services", par exemple voyez cette [http://www.windley.com/archives/2005/07/microformats.shtml comparaison des microformats et de REST]. Regardez le [http://rest.blueoxen.net REST wiki] pour plus d'information à propos de REST. [http://patricklogan.blogspot.com/2006/01/microformat-microprotocol.html Microformats et microprotocoles] en rapport.
* Voir aussi : [http://www.justinleavesley.com/journal/2005/7/28/web-services-and-the-innovators-dilemma.html Web Services et le Dilemnme des Innovateurs] par Justin Leavesley

== Pages en rapport ==
* Recent [[press]] interviews and articles are also a good introduction.
* See microformat [[presentations]] for more background and introductory material on [[microformats]].
* Listen to [[podcasts]] about microformats.
* More [[suggested-reading|suggested reading]]
* [[implement|So you wanna implement microformats?]]

== Articles ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon
* [http://www.gr0w.com/articles/design/an_extra_side_to_web_standards_based_design/ An Extra SIDE to Web Standards Based Design] - How Semantic Information Design Ethics (SIDE) and a few readily available techniques can help heal the Web, by Jon Tan. See also his [http://www.csszengarden.com/?cssfile=/193/193.css&page=0 CSS Zen Garden "Leggo my ego" entry].
* [http://thedredge.org/ Andrew D. Hume] has written a blog post [http://thedredge.org/2005/07/introducing-microformats/ introducing microformats] and another one on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats].
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect Seearch Engine Optimization]
* [http://blogbusinesssummit.com/2006/04/microformats_in.htm Blog Business Summit: Microformats in Plain English: the Promise of Simple Business to Business Data Exchange] by Steve Broback

== Références diverses ==

These are various intro-related links/articles which I haven't figured out yet how to incorporate. You may find them of interest. - [http://tantek.com/log/ Tantek]

* [http://www.betaversion.org/~stefano/linotype/news/93/ Data First vs. Structure First]
** [http://tantek.com/log/ Tantek] says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem.
*** Zeroeth, define the real-world problem. If you can't do this, then stop.
*** First, look at real-world usage (data).
*** Second, what previous standards are people actually using today? If there is more than one, then lean towards those with the better adoption.
***And only after those first two do we bother to pay attention to theoretical standards, those that have been invented (whether by individuals, committees), but haven't seen much if any actual adoption.
* [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 2000-03-21 Dan Connolly on human-consumable information]: ('''strong emphasis''' added)
** I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to '''manage the information in human-consumable form (XHTML) annotated with just enough info to extract''' the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. '''We all know that we have to produce a human-readable version of the thing... why not use that as the primary source?'''

introduction-fr

2006-06-27T12:57:15Z

SebastienSauteur: to be continued...

__NOTOC__

<h1> Introduction aux Microformats </h1>

Related: [[press]], [[presentations]], [[podcasts]], [[suggested-reading]], [[testimonials]]

__TOC__

== Que sont les Microformats? ==

Les microformats sont les "dictionnaires" du contenu sémantique XHTML. Ils ont pour objet de codifier le contenu HTML riche-en-information couramment utilisé, de telle façon à ce que le contenu sémantique puisse être extrait par une machine. En bref, ils sont la manière la plus simple d'architecturer des données (ou formats de données) destinés à être réutilisés sur le Web.

== Pourquoi les Microformats ==

Pourquoi en sommes-nous venus aux microformats?

En bref, les microformats sont la convergence d'un certain nombre de tendances :
# une étape à venir logique dans l'évolution du "web design" et l'architecturage de l'information.
# une façon pour les éditeurs autonomes de publier eux-mêmes une information plus riche, sans devoir s'en remettre à des services centralisés.
# la reconnaissance du fait que les efforts "traditionnels" en matière de métadonnées ont soit échoué, soit pris tellement de temps pour engranger une quelconque adoption, qu'une nouvelle approche était nécessaire
# une façon d'utiliser le (X)HTML pour les données (data).

=== Evolution du Web Design ===

Au commencement (1990), il y avait le [http://www.w3.org/MarkUp/ HTML], et il convenait bien. Il était simple, minimal, et utilisé pour baliser semantiquement les données visible de l'utilisateur (texte) et les partager sur le World Wide Web.

Ensuite vint la [http://en.wikipedia.org/wiki/Browser_wars guerre des navigateurs] (1994-1999) qui vit les éditeurs dominants de navigateurs ''took their turns'' en introduisant des étiquettes "innovantes" pour la presentation, donnant aux auteurs/designers typiques du web ce qu'ils voulaient : un semblant de controle sur la presentation de leurs pages web. Le résulat : [http://www.w3.org/TR/REC-html32 HTML 3.2] "standardisa" ces innovations "defacto" en terme de présentation.

L'introduction de [http://www.w3.org/TR/REC-CSS1 CSS1] (1996) et le semantiquement plus riche [http://www.w3.org/TR/REC-html40/ HTML4] (1998) apportèrent une lueur d'espoir, mais ce n'est que des années plus tard (2000-2001), avec l'introduction d'implémentations pleinement conformes (ou presque) à CSS1/HTML4 (IE5/Mac, IE6/Windows, Netscape 6) que l'usage par les "web designers" de CSS dans leurs pages web, devint possible en pratique. Les leaders au sein des communautés commencèrent à furieusement adopter et promouvoir CSS (même s'il fallait en passer par [http://www.tantek.com/log/2004/07.html#ie5macbandpass un] [http://tantek.com/CSS/Examples/boxmodelhack.html "hack"] [http://www.tantek.com/CSS/Examples/midpass.html ou] [http://tantek.com/CSS/Examples/highpass.html deux]) et l'efficacité et l'amélioration de la productivité que leur apportait la séparation de la présentation et du balisage, resta néanmoins le fait d'une petite minorité agissante.

L'introduction de la version "redesignée" 100% CSS de "Wired News", et le superbe [http://csszengarden.com/ CSS Zen Garden] (2002-2003) marquèrent le "tipping point" du CSS. Avec la présentation claire et évidente de la beauté visuelle et de la pleine créativité, il apparut soudain comme une évidence aux designers du monde entier, ils réalisèrent que c'était là le futur du "web design". Les balisages à des fins de présentation par <code><FONT></code>, <code><TABLE></code>, et <code>spacer.gif</code> furent laissé de côté par tous les web designers qui se respectaient, et qui découvrirent la flexibilité presque infinie des <code><div></code>, <code><span></code>, et de l'attribut 'class'. Quelques uns dans la communauté commencèrent même à adopter quelques uns des éléments les plus sémantiques du HTML: <code><p></code>, <code><h1></code>...<code><h6></code>, <code><ol></code>, <code><ul></code>, <code><li></code>, <code><em></code>, <code><strong></code>. Les leaders au sein de la communauté s'exercèrent aux limites sémantiques du HTML4 strict (experimenté avec XHTML) et documentèrent [http://www.simplebits.com/publications/solutions/ les "best practices"].

As the community followed rapidly in the footpaths they had worn, the leaders began to run into the limits of semantic (X)HTML. Other subcultures were attempting to rewrite the world in their own language(s) (<abbr title="Resource Description Framework">[http://www.w3.org/RDF/ RDF]</abbr>, [[plain-xml|"plain" XML]], <abbr title="Scalable Vector Graphics">[http://www.w3.org/TR/SVG/ SVG]</abbr>), yet not having much of an impact on the World Wide Web, which required human presentable data, compatible with the browsers people already used. [http://en.wikipedia.org/wiki/Social_software Social Software] and [http://en.wikipedia.org/wiki/Blogs Blogs], written by this new generation of web designers and programmers, began to take off.

Natural patterns emerged from the way people used blogging systems, putting things into lists, for example lists of other bloggers (known as blogrolls), and annotating them with information representing relationships such has having met, friends, family, etc. The first microformat, <abbr title="XHTML Friends Network">[http://gmpg.org/xfn/ XFN]</abbr>, was designed to match these behaviors, and [http://tantek.com/log/2003/12.html#L20031215t0830 introduced to the blogging community] (2003-2004), who adopted it within weeks. The [http://gmpg.org GMPG] was formed as a home for XFN, and documented a few key [http://gmpg.org/principles design principles] later adopted for microformats. The key notion, that semantic (X)HTML could be extended, had been introduced and accepted by the community.

By understanding, using, and combining semantic (X)HTML building blocks, as well as determining that semantic (X)HTML could be validly extended via new rel, meta name, and class values, defined in (X)HTML profiles in the [http://gmpg.org/xmdp XMDP format], the community began to design and develop many more microformats (2004-2005). More patterns emerged from the blogging community, and each aggregate human behavior drove the design of simple, adaptive microformats to meet its needs. Creative Commons licensing became popular and [[rel-license]] was proposed. Outlines and lists: [[xoxo|XOXO]]. Contact info: [[hcard|hCard]]. Calendars and events [[hcalendar|hCalendar]].

Using these new found building blocks, the web design and information architecture communities were no longer limited by the predefined semantics of HTML4 (nor did they have to compromise human presentation and ease of authoring which other attempts sorely lacked). 2005 may well be the year that microformats became the next step in the evolution of the web.

=== L'Attrait de la Simplicité ===

* Microformats are a simple effort which has appealed to many frustrated with previous complex efforts. One parallel that can be drawn is to REST in the web services world, i.e. see this [http://www.windley.com/archives/2005/07/microformats.shtml comparison of microformats and REST]. See the [http://rest.blueoxen.net REST wiki] for more about REST. Related [http://patricklogan.blogspot.com/2006/01/microformat-microprotocol.html microformats and microprotocols].
* See also: [http://www.justinleavesley.com/journal/2005/7/28/web-services-and-the-innovators-dilemma.html Web Services and the Innovators Dilemma] by Justin Leavesley

== Pages en rapport ==
* Recent [[press]] interviews and articles are also a good introduction.
* See microformat [[presentations]] for more background and introductory material on [[microformats]].
* Listen to [[podcasts]] about microformats.
* More [[suggested-reading|suggested reading]]
* [[implement|So you wanna implement microformats?]]

== Articles ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon
* [http://www.gr0w.com/articles/design/an_extra_side_to_web_standards_based_design/ An Extra SIDE to Web Standards Based Design] - How Semantic Information Design Ethics (SIDE) and a few readily available techniques can help heal the Web, by Jon Tan. See also his [http://www.csszengarden.com/?cssfile=/193/193.css&page=0 CSS Zen Garden "Leggo my ego" entry].
* [http://thedredge.org/ Andrew D. Hume] has written a blog post [http://thedredge.org/2005/07/introducing-microformats/ introducing microformats] and another one on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats].
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect Seearch Engine Optimization]
* [http://blogbusinesssummit.com/2006/04/microformats_in.htm Blog Business Summit: Microformats in Plain English: the Promise of Simple Business to Business Data Exchange] by Steve Broback

== Références diverses ==

These are various intro-related links/articles which I haven't figured out yet how to incorporate. You may find them of interest. - [http://tantek.com/log/ Tantek]

* [http://www.betaversion.org/~stefano/linotype/news/93/ Data First vs. Structure First]
** [http://tantek.com/log/ Tantek] says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem.
*** Zeroeth, define the real-world problem. If you can't do this, then stop.
*** First, look at real-world usage (data).
*** Second, what previous standards are people actually using today? If there is more than one, then lean towards those with the better adoption.
***And only after those first two do we bother to pay attention to theoretical standards, those that have been invented (whether by individuals, committees), but haven't seen much if any actual adoption.
* [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 2000-03-21 Dan Connolly on human-consumable information]: ('''strong emphasis''' added)
** I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to '''manage the information in human-consumable form (XHTML) annotated with just enough info to extract''' the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. '''We all know that we have to produce a human-readable version of the thing... why not use that as the primary source?'''

to-do-fr

2006-06-27T12:18:25Z

SebastienSauteur: /* Page Accueil francophone : */

Cette page est destinée à poster :
* les choses à faire en rapport avec les micro-formats
* l'organisation des pages en français sur ce wiki
* les pages d'ensemencement pour fonder une micro-communauté francophone des microformats.

Si vous voulez utiliser cette page pour vos items à faire en rapport avec les microformats, créez une section et placez votre nom dessus. La raison pour laquelle nous gardons tout sur la même page est de pouvoir faire qu'il soit plus facile de dire quand les gens travaillent sur des choses similaires, et faire qu'il soit plus évident quand les personnes aideront sur les tâches d'autres personnes.

En théorie, ceci ne pourra pas s'agrandir indéfiniment, mais voyons d'abord comment mettre ça en pratique. Pour des choses plus sérieuses et si vous êtes programmeur et comprenez l'anglais rejoignez directement la page de référence [[to-do]]. - [[Christophe Ducamp]]

== Traductions spécifications ==

Elles ont démarré et sont encore à l'état de brouillon. Si vous rajoutez une traduction en français, merci de la recenser sur cette page afin de la passer sur un processus de révision à définir par la future micro-communauté francophone des microformats.

=== hCalendar (traductions) ===

* [[hcalendar-fr]] -- événements
** [[hcalendar-faq-fr]] -- faq hcalendar
** [[icalendar-implementations-fr]] -- implémentations icalendar
** [[hcalendar-examples-fr]]
** [[hcalendar-brainstorming-fr]]
** [[hcalendar-example1-steps-fr]]
** [[hcalendar-issues-fr]] -- les problématiques
** [[hcalendar-tests-fr]]

=== hCard (traductions spéc. et pages apparentées) ===
* [[hcard-fr]] -- carte de visite
** [[hcard-authoring-fr]] -- comment publier une hCard ?
** [[hcard-examples-fr]] -- traduction amorcée avec tentatives de localiser le format avec des données francophones. Une page à vérifier très sérieusement sujette à erreurs.
** [[hcard-example1-steps-fr]]

Traductions prévues :
* [[hcard-profile-fr]]
* [[hcard-parsing-fr]]

=== rel-license ===
* [[rel-license-fr]] -- licences

traduire [[rellicense-issues]] sur [[rellicense-issues-fr]]

=== rel-nofollow ===
* [[rel-nofollow-fr]] -- parce que tous les liens sur une page ne sont pas égaux. mesure antispam, etc.

=== rel-tag ===
* [[rel-tag-fr]] -- tag, tag...
** [[rel-tag-feedback-fr]]
** [[rel-tag-issues-fr]]
** [[rel-tag-faq-fr]]

=== hResume ===
* [[hresume-fr]] -- curriculum vitae
** [[resume-formats-fr]]

=== hReview (critique) ===
* [[hreview-fr]] -- cette spécification est à relire. Il faut aussi localiser en français l'échantillon de critique
** [[hreview-faq-fr]]
** [[review-formats-fr]]
** [[review-examples-fr]]

=== hAtom ===

* [[hatom-fr]]

=== XOXO ===
* [[xoxo-fr]] -- outliner (comment traduire ? idéateur ?)

=== xfn ===
* [[xfn-implementations-fr]] --

=== vote-links ===
** [[vote-links-fr]] -- vote... à tester pour les présidentielles en France ?

== Organisation Communauté Francophone ==

La micro-communauté francophone des microformats aura sans doute besoin de quelques pages pour s'organiser. Ci-après quelques contenus qui pourront aider à structurer notre processus de communication pour mieux faire connaître et adopter les microformats en francophonie.

=== Site officiel ? ===

Pour le moment il n'existe pas de pages en français sur le site http://www.microformats.org. Les pages pourraient être traduites et déposées provisoirement sur ce wiki avant de dealer une branche comme un microformats.org/fr.

=== Page Accueil francophone : ===

* [[Main_Page-fr]] à travailler sérieusement et synchroniser avec [[Main_Page]]
** traduire notamment l'[[introduction]] sur [[introduction-fr]] ''-- en cours''

=== Gabarits : ===
* [[Template:semantic-xhtml-design-principles-fr]] -- les principes de design du xhtml sémantique
* [[Template:MicroFormatCopyrightStatement2004-fr]] -- déclaration copyright
* [[Template:MicroformatCopyrightStatement2005-fr]]
* [[Template:MicroFormatPatentStatement-fr]] -- brevets

=== Processus, Communication et jeu dans la communauté ===
* [[process-fr]] -- le processus de travail pour construire un microformat
* [[how-to-play-fr]] -- comment jouer en français sur ce wiki
* [[irc-fr]] -- le canal irc des microformats

[[to-do-fr]] : A créer : un annuaire des contributeurs francophones ?

=== Documentation générale et base de connaissance : ===
* [[faq-fr]] -- les questions souvent posées
* [[press-fr]] -- articles publiés dans la presse. Mériteraient d'être traduits en français ?
** [[press-faq-fr]] -- les questions souvent posées par les journalistes
* [[books-fr]] -- les livres parus sur les microformats (à cette heure ils sont tous en anglais et n'ont pas été traduits)
* [[presentations-fr]] -- les "points puissants"
* [[podcasts-fr]] -- du son
* [[screencasts-fr]] -- vidéo

=== Pédagogie ===
* [[demo-fr]] -- démonstration pour présenter les microformats

=== Rencontres : ===
* [[events-fr]] -- à construire en francophonie

=== Décor et stylisme :===
* [[buttons-fr]] -- de jolis boutons à disposition

=== Interface utilisateur : ===
* [[user-interface-fr]] -- tout reste à inventer pour que les microformats soient adoptés massivement par les utilisateurs non connaisseurs.

=== Terrain de jeu : ===
* [[zen-garden-fr]] -- un projet de répliquer le zen-garden css pour l'usage des microformats

to-do-fr

2006-06-27T12:18:01Z

SebastienSauteur: @Christophe : peut-être indiquer un statut pour page (itératif: encours, àrelire,àpaufiner, etc.) car rss dense...

Cette page est destinée à poster :
* les choses à faire en rapport avec les micro-formats
* l'organisation des pages en français sur ce wiki
* les pages d'ensemencement pour fonder une micro-communauté francophone des microformats.

Si vous voulez utiliser cette page pour vos items à faire en rapport avec les microformats, créez une section et placez votre nom dessus. La raison pour laquelle nous gardons tout sur la même page est de pouvoir faire qu'il soit plus facile de dire quand les gens travaillent sur des choses similaires, et faire qu'il soit plus évident quand les personnes aideront sur les tâches d'autres personnes.

En théorie, ceci ne pourra pas s'agrandir indéfiniment, mais voyons d'abord comment mettre ça en pratique. Pour des choses plus sérieuses et si vous êtes programmeur et comprenez l'anglais rejoignez directement la page de référence [[to-do]]. - [[Christophe Ducamp]]

== Traductions spécifications ==

Elles ont démarré et sont encore à l'état de brouillon. Si vous rajoutez une traduction en français, merci de la recenser sur cette page afin de la passer sur un processus de révision à définir par la future micro-communauté francophone des microformats.

=== hCalendar (traductions) ===

* [[hcalendar-fr]] -- événements
** [[hcalendar-faq-fr]] -- faq hcalendar
** [[icalendar-implementations-fr]] -- implémentations icalendar
** [[hcalendar-examples-fr]]
** [[hcalendar-brainstorming-fr]]
** [[hcalendar-example1-steps-fr]]
** [[hcalendar-issues-fr]] -- les problématiques
** [[hcalendar-tests-fr]]

=== hCard (traductions spéc. et pages apparentées) ===
* [[hcard-fr]] -- carte de visite
** [[hcard-authoring-fr]] -- comment publier une hCard ?
** [[hcard-examples-fr]] -- traduction amorcée avec tentatives de localiser le format avec des données francophones. Une page à vérifier très sérieusement sujette à erreurs.
** [[hcard-example1-steps-fr]]

Traductions prévues :
* [[hcard-profile-fr]]
* [[hcard-parsing-fr]]

=== rel-license ===
* [[rel-license-fr]] -- licences

traduire [[rellicense-issues]] sur [[rellicense-issues-fr]]

=== rel-nofollow ===
* [[rel-nofollow-fr]] -- parce que tous les liens sur une page ne sont pas égaux. mesure antispam, etc.

=== rel-tag ===
* [[rel-tag-fr]] -- tag, tag...
** [[rel-tag-feedback-fr]]
** [[rel-tag-issues-fr]]
** [[rel-tag-faq-fr]]

=== hResume ===
* [[hresume-fr]] -- curriculum vitae
** [[resume-formats-fr]]

=== hReview (critique) ===
* [[hreview-fr]] -- cette spécification est à relire. Il faut aussi localiser en français l'échantillon de critique
** [[hreview-faq-fr]]
** [[review-formats-fr]]
** [[review-examples-fr]]

=== hAtom ===

* [[hatom-fr]]

=== XOXO ===
* [[xoxo-fr]] -- outliner (comment traduire ? idéateur ?)

=== xfn ===
* [[xfn-implementations-fr]] --

=== vote-links ===
** [[vote-links-fr]] -- vote... à tester pour les présidentielles en France ?

== Organisation Communauté Francophone ==

La micro-communauté francophone des microformats aura sans doute besoin de quelques pages pour s'organiser. Ci-après quelques contenus qui pourront aider à structurer notre processus de communication pour mieux faire connaître et adopter les microformats en francophonie.

=== Site officiel ? ===

Pour le moment il n'existe pas de pages en français sur le site http://www.microformats.org. Les pages pourraient être traduites et déposées provisoirement sur ce wiki avant de dealer une branche comme un microformats.org/fr.

=== Page Accueil francophone : ===

* [[Main_Page-fr]] à travailler sérieusement et synchroniser avec [[Main_Page]]
** traduire notamment l'[[introduction]] sur [[introduction-fr]] ''en cours''

=== Gabarits : ===
* [[Template:semantic-xhtml-design-principles-fr]] -- les principes de design du xhtml sémantique
* [[Template:MicroFormatCopyrightStatement2004-fr]] -- déclaration copyright
* [[Template:MicroformatCopyrightStatement2005-fr]]
* [[Template:MicroFormatPatentStatement-fr]] -- brevets

=== Processus, Communication et jeu dans la communauté ===
* [[process-fr]] -- le processus de travail pour construire un microformat
* [[how-to-play-fr]] -- comment jouer en français sur ce wiki
* [[irc-fr]] -- le canal irc des microformats

[[to-do-fr]] : A créer : un annuaire des contributeurs francophones ?

=== Documentation générale et base de connaissance : ===
* [[faq-fr]] -- les questions souvent posées
* [[press-fr]] -- articles publiés dans la presse. Mériteraient d'être traduits en français ?
** [[press-faq-fr]] -- les questions souvent posées par les journalistes
* [[books-fr]] -- les livres parus sur les microformats (à cette heure ils sont tous en anglais et n'ont pas été traduits)
* [[presentations-fr]] -- les "points puissants"
* [[podcasts-fr]] -- du son
* [[screencasts-fr]] -- vidéo

=== Pédagogie ===
* [[demo-fr]] -- démonstration pour présenter les microformats

=== Rencontres : ===
* [[events-fr]] -- à construire en francophonie

=== Décor et stylisme :===
* [[buttons-fr]] -- de jolis boutons à disposition

=== Interface utilisateur : ===
* [[user-interface-fr]] -- tout reste à inventer pour que les microformats soient adoptés massivement par les utilisateurs non connaisseurs.

=== Terrain de jeu : ===
* [[zen-garden-fr]] -- un projet de répliquer le zen-garden css pour l'usage des microformats

introduction-fr

2006-06-27T10:20:05Z

SebastienSauteur: /* Pourquoi les Microformats */

__NOTOC__

<h1> Introduction aux Microformats </h1>

Related: [[press]], [[presentations]], [[podcasts]], [[suggested-reading]], [[testimonials]]

__TOC__

== Que sont les Microformats? ==

Les microformats sont les "dictionnaires" du contenu sémantique XHTML. Ils ont pour objet de codifier le contenu HTML riche-en-information couramment utilisé, de telle façon à ce que le contenu sémantique puisse être extrait par une machine. En bref, ils sont la manière la plus simple d'architecturer des données (ou formats de données) destinés à être réutilisés sur le Web.

== Pourquoi les Microformats ==

Pourquoi en sommes-nous venus aux microformats?

En bref, les microformats sont la convergence d'un certain nombre de tendances :
# une étape à venir logique dans l'évolution du "web design" et l'architecturage de l'information.
# une façon pour les éditeurs autonomes de publier eux-mêmes une information plus riche, sans devoir s'en remettre à des services centralisés.
# la reconnaissance du fait que les efforts "traditionnels" en matière de métadonnées ont soit échoué, soit pris tellement de temps pour engranger une quelconque adoption, qu'une nouvelle approche était nécessaire
# une façon d'utiliser le (X)HTML pour les données (data).

=== Evolution du Web Design ===

Au commencement (1990), il y avait le [http://www.w3.org/MarkUp/ HTML], et il convenait bien. Il était simple, minimal, et utilisé pour baliser semantiquement les données visible de l'utilisateur (texte) et les partager sur le World Wide Web.

Ensuite vint la [http://en.wikipedia.org/wiki/Browser_wars guerre des navigateurs] (1994-1999) qui vit les éditeurs dominants de navigateurs ''took their turns'' en introduisant des étiquettes "innovantes" pour la presentation, donnant aux auteurs/designers typiques du web ce qu'ils voulaient : un semblant de controle sur la presentation de leurs pages web. Le résulat : [http://www.w3.org/TR/REC-html32 HTML 3.2] "standardized" these defacto presentational innovations.

The introduction of [http://www.w3.org/TR/REC-CSS1 CSS1] (1996) and the semantically richer [http://www.w3.org/TR/REC-html40/ HTML4] (1998) brought a glimmer of hope, but it wasn't until years later (2000-2001), with the introduction of fully compliant (or almost) implementations of CSS1/HTML4 (IE5/Mac, IE6/Windows, Netscape 6) that it became practical for web designers to depend on CSS in their web pages. Leaders in the community began to furiously adopt and promote CSS (even if it took [http://www.tantek.com/log/2004/07.html#ie5macbandpass a] [http://tantek.com/CSS/Examples/boxmodelhack.html hack] [http://www.tantek.com/CSS/Examples/midpass.html or] [http://tantek.com/CSS/Examples/highpass.html two]) and the efficiencies and enhanced productivity that separating presentation from markup brought them, yet remained a small vocal minority.

The introduction of the Wired News redesign in 100% CSS, and the beautiful [http://csszengarden.com/ CSS Zen Garden] (2002-2003) was CSS's tipping point. With the clear and obvious presentation of visual beauty and broad creativity, designers world-wide "got it" and realized that this was the future of web design. The presentational markup of <code><FONT></code>, <code><TABLE></code>, and <code>spacer.gif</code> were tossed aside by any and all self-respecting web designers, who discovered the near infinite flexibility of <code><div></code>, <code><span></code>, and the 'class' attribute. A few in the community even began adopting some of the more semantic elements in HTML: <code><p></code>, <code><h1></code>...<code><h6></code>, <code><ol></code>, <code><ul></code>, <code><li></code>, <code><em></code>, <code><strong></code>. Leaders in the community exercised the semantic limits of strict HTML4 (experimented with XHTML) and documented [http://www.simplebits.com/publications/solutions/ best practices].

As the community followed rapidly in the footpaths they had worn, the leaders began to run into the limits of semantic (X)HTML. Other subcultures were attempting to rewrite the world in their own language(s) (<abbr title="Resource Description Framework">[http://www.w3.org/RDF/ RDF]</abbr>, [[plain-xml|"plain" XML]], <abbr title="Scalable Vector Graphics">[http://www.w3.org/TR/SVG/ SVG]</abbr>), yet not having much of an impact on the World Wide Web, which required human presentable data, compatible with the browsers people already used. [http://en.wikipedia.org/wiki/Social_software Social Software] and [http://en.wikipedia.org/wiki/Blogs Blogs], written by this new generation of web designers and programmers, began to take off.

Natural patterns emerged from the way people used blogging systems, putting things into lists, for example lists of other bloggers (known as blogrolls), and annotating them with information representing relationships such has having met, friends, family, etc. The first microformat, <abbr title="XHTML Friends Network">[http://gmpg.org/xfn/ XFN]</abbr>, was designed to match these behaviors, and [http://tantek.com/log/2003/12.html#L20031215t0830 introduced to the blogging community] (2003-2004), who adopted it within weeks. The [http://gmpg.org GMPG] was formed as a home for XFN, and documented a few key [http://gmpg.org/principles design principles] later adopted for microformats. The key notion, that semantic (X)HTML could be extended, had been introduced and accepted by the community.

By understanding, using, and combining semantic (X)HTML building blocks, as well as determining that semantic (X)HTML could be validly extended via new rel, meta name, and class values, defined in (X)HTML profiles in the [http://gmpg.org/xmdp XMDP format], the community began to design and develop many more microformats (2004-2005). More patterns emerged from the blogging community, and each aggregate human behavior drove the design of simple, adaptive microformats to meet its needs. Creative Commons licensing became popular and [[rel-license]] was proposed. Outlines and lists: [[xoxo|XOXO]]. Contact info: [[hcard|hCard]]. Calendars and events [[hcalendar|hCalendar]].

Using these new found building blocks, the web design and information architecture communities were no longer limited by the predefined semantics of HTML4 (nor did they have to compromise human presentation and ease of authoring which other attempts sorely lacked). 2005 may well be the year that microformats became the next step in the evolution of the web.

=== L'Attrait de la Simplicité ===

* Microformats are a simple effort which has appealed to many frustrated with previous complex efforts. One parallel that can be drawn is to REST in the web services world, i.e. see this [http://www.windley.com/archives/2005/07/microformats.shtml comparison of microformats and REST]. See the [http://rest.blueoxen.net REST wiki] for more about REST. Related [http://patricklogan.blogspot.com/2006/01/microformat-microprotocol.html microformats and microprotocols].
* See also: [http://www.justinleavesley.com/journal/2005/7/28/web-services-and-the-innovators-dilemma.html Web Services and the Innovators Dilemma] by Justin Leavesley

== Pages en rapport ==
* Recent [[press]] interviews and articles are also a good introduction.
* See microformat [[presentations]] for more background and introductory material on [[microformats]].
* Listen to [[podcasts]] about microformats.
* More [[suggested-reading|suggested reading]]
* [[implement|So you wanna implement microformats?]]

== Articles ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon
* [http://www.gr0w.com/articles/design/an_extra_side_to_web_standards_based_design/ An Extra SIDE to Web Standards Based Design] - How Semantic Information Design Ethics (SIDE) and a few readily available techniques can help heal the Web, by Jon Tan. See also his [http://www.csszengarden.com/?cssfile=/193/193.css&page=0 CSS Zen Garden "Leggo my ego" entry].
* [http://thedredge.org/ Andrew D. Hume] has written a blog post [http://thedredge.org/2005/07/introducing-microformats/ introducing microformats] and another one on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats].
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect Seearch Engine Optimization]
* [http://blogbusinesssummit.com/2006/04/microformats_in.htm Blog Business Summit: Microformats in Plain English: the Promise of Simple Business to Business Data Exchange] by Steve Broback

== Références diverses ==

These are various intro-related links/articles which I haven't figured out yet how to incorporate. You may find them of interest. - [http://tantek.com/log/ Tantek]

* [http://www.betaversion.org/~stefano/linotype/news/93/ Data First vs. Structure First]
** [http://tantek.com/log/ Tantek] says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem.
*** Zeroeth, define the real-world problem. If you can't do this, then stop.
*** First, look at real-world usage (data).
*** Second, what previous standards are people actually using today? If there is more than one, then lean towards those with the better adoption.
***And only after those first two do we bother to pay attention to theoretical standards, those that have been invented (whether by individuals, committees), but haven't seen much if any actual adoption.
* [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 2000-03-21 Dan Connolly on human-consumable information]: ('''strong emphasis''' added)
** I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to '''manage the information in human-consumable form (XHTML) annotated with just enough info to extract''' the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. '''We all know that we have to produce a human-readable version of the thing... why not use that as the primary source?'''

introduction-fr

2006-06-27T10:17:52Z

SebastienSauteur: a suivre..

__NOTOC__

<h1> Introduction aux Microformats </h1>

Related: [[press]], [[presentations]], [[podcasts]], [[suggested-reading]], [[testimonials]]

__TOC__

== Que sont les Microformats? ==

Les microformats sont les "dictionnaires" du contenu sémantique XHTML. Ils ont pour objet de codifier le contenu HTML riche-en-information couramment utilisé, de telle façon à ce que le contenu sémantique puisse être extrait par une machine. En bref, ils sont la manière la plus simple d'architecturer des données (ou formats de données) destinés à être réutilisés sur le Web.

== Pourquoi les Microformats ==

Pourquoi en sommes-nous venus aux microformats?

En bref, les microformats sont la convergence d'un certain nombre de tendances :
# une étape à venir logique dans l'évolution du "web design" et l'architecture de l'information.
# une façon pour les éditeurs autonomes de publier eux-mêmes une information plus riche, sans devoir s'en remettre à des services centralisés.
# la reconnaissance du fait que les efforts "traditionnels" en matière de métadonnées ont soit échoué, soit pris tellement de temps pour ''garner'' une quelconque adoption, qu'une nouvelle approche était nécessaire
# une façon d'utiliser le (X)HTML pour les données (data).

=== Evolution du Web Design ===

Au commencement (1990), il y avait le [http://www.w3.org/MarkUp/ HTML], et il convenait bien. Il était simple, minimal, et utilisé pour baliser semantiquement les données visible de l'utilisateur (texte) et les partager sur le World Wide Web.

Ensuite vint la [http://en.wikipedia.org/wiki/Browser_wars guerre des navigateurs] (1994-1999) qui vit les éditeurs dominants de navigateurs ''took their turns'' en introduisant des étiquettes "innovantes" pour la presentation, donnant aux auteurs/designers typiques du web ce qu'ils voulaient : un semblant de controle sur la presentation de leurs pages web. Le résulat : [http://www.w3.org/TR/REC-html32 HTML 3.2] "standardized" these defacto presentational innovations.

The introduction of [http://www.w3.org/TR/REC-CSS1 CSS1] (1996) and the semantically richer [http://www.w3.org/TR/REC-html40/ HTML4] (1998) brought a glimmer of hope, but it wasn't until years later (2000-2001), with the introduction of fully compliant (or almost) implementations of CSS1/HTML4 (IE5/Mac, IE6/Windows, Netscape 6) that it became practical for web designers to depend on CSS in their web pages. Leaders in the community began to furiously adopt and promote CSS (even if it took [http://www.tantek.com/log/2004/07.html#ie5macbandpass a] [http://tantek.com/CSS/Examples/boxmodelhack.html hack] [http://www.tantek.com/CSS/Examples/midpass.html or] [http://tantek.com/CSS/Examples/highpass.html two]) and the efficiencies and enhanced productivity that separating presentation from markup brought them, yet remained a small vocal minority.

The introduction of the Wired News redesign in 100% CSS, and the beautiful [http://csszengarden.com/ CSS Zen Garden] (2002-2003) was CSS's tipping point. With the clear and obvious presentation of visual beauty and broad creativity, designers world-wide "got it" and realized that this was the future of web design. The presentational markup of <code><FONT></code>, <code><TABLE></code>, and <code>spacer.gif</code> were tossed aside by any and all self-respecting web designers, who discovered the near infinite flexibility of <code><div></code>, <code><span></code>, and the 'class' attribute. A few in the community even began adopting some of the more semantic elements in HTML: <code><p></code>, <code><h1></code>...<code><h6></code>, <code><ol></code>, <code><ul></code>, <code><li></code>, <code><em></code>, <code><strong></code>. Leaders in the community exercised the semantic limits of strict HTML4 (experimented with XHTML) and documented [http://www.simplebits.com/publications/solutions/ best practices].

As the community followed rapidly in the footpaths they had worn, the leaders began to run into the limits of semantic (X)HTML. Other subcultures were attempting to rewrite the world in their own language(s) (<abbr title="Resource Description Framework">[http://www.w3.org/RDF/ RDF]</abbr>, [[plain-xml|"plain" XML]], <abbr title="Scalable Vector Graphics">[http://www.w3.org/TR/SVG/ SVG]</abbr>), yet not having much of an impact on the World Wide Web, which required human presentable data, compatible with the browsers people already used. [http://en.wikipedia.org/wiki/Social_software Social Software] and [http://en.wikipedia.org/wiki/Blogs Blogs], written by this new generation of web designers and programmers, began to take off.

Natural patterns emerged from the way people used blogging systems, putting things into lists, for example lists of other bloggers (known as blogrolls), and annotating them with information representing relationships such has having met, friends, family, etc. The first microformat, <abbr title="XHTML Friends Network">[http://gmpg.org/xfn/ XFN]</abbr>, was designed to match these behaviors, and [http://tantek.com/log/2003/12.html#L20031215t0830 introduced to the blogging community] (2003-2004), who adopted it within weeks. The [http://gmpg.org GMPG] was formed as a home for XFN, and documented a few key [http://gmpg.org/principles design principles] later adopted for microformats. The key notion, that semantic (X)HTML could be extended, had been introduced and accepted by the community.

By understanding, using, and combining semantic (X)HTML building blocks, as well as determining that semantic (X)HTML could be validly extended via new rel, meta name, and class values, defined in (X)HTML profiles in the [http://gmpg.org/xmdp XMDP format], the community began to design and develop many more microformats (2004-2005). More patterns emerged from the blogging community, and each aggregate human behavior drove the design of simple, adaptive microformats to meet its needs. Creative Commons licensing became popular and [[rel-license]] was proposed. Outlines and lists: [[xoxo|XOXO]]. Contact info: [[hcard|hCard]]. Calendars and events [[hcalendar|hCalendar]].

Using these new found building blocks, the web design and information architecture communities were no longer limited by the predefined semantics of HTML4 (nor did they have to compromise human presentation and ease of authoring which other attempts sorely lacked). 2005 may well be the year that microformats became the next step in the evolution of the web.

=== L'Attrait de la Simplicité ===

* Microformats are a simple effort which has appealed to many frustrated with previous complex efforts. One parallel that can be drawn is to REST in the web services world, i.e. see this [http://www.windley.com/archives/2005/07/microformats.shtml comparison of microformats and REST]. See the [http://rest.blueoxen.net REST wiki] for more about REST. Related [http://patricklogan.blogspot.com/2006/01/microformat-microprotocol.html microformats and microprotocols].
* See also: [http://www.justinleavesley.com/journal/2005/7/28/web-services-and-the-innovators-dilemma.html Web Services and the Innovators Dilemma] by Justin Leavesley

== Pages en rapport ==
* Recent [[press]] interviews and articles are also a good introduction.
* See microformat [[presentations]] for more background and introductory material on [[microformats]].
* Listen to [[podcasts]] about microformats.
* More [[suggested-reading|suggested reading]]
* [[implement|So you wanna implement microformats?]]

== Articles ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon
* [http://www.gr0w.com/articles/design/an_extra_side_to_web_standards_based_design/ An Extra SIDE to Web Standards Based Design] - How Semantic Information Design Ethics (SIDE) and a few readily available techniques can help heal the Web, by Jon Tan. See also his [http://www.csszengarden.com/?cssfile=/193/193.css&page=0 CSS Zen Garden "Leggo my ego" entry].
* [http://thedredge.org/ Andrew D. Hume] has written a blog post [http://thedredge.org/2005/07/introducing-microformats/ introducing microformats] and another one on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats].
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect Seearch Engine Optimization]
* [http://blogbusinesssummit.com/2006/04/microformats_in.htm Blog Business Summit: Microformats in Plain English: the Promise of Simple Business to Business Data Exchange] by Steve Broback

== Références diverses ==

These are various intro-related links/articles which I haven't figured out yet how to incorporate. You may find them of interest. - [http://tantek.com/log/ Tantek]

* [http://www.betaversion.org/~stefano/linotype/news/93/ Data First vs. Structure First]
** [http://tantek.com/log/ Tantek] says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem.
*** Zeroeth, define the real-world problem. If you can't do this, then stop.
*** First, look at real-world usage (data).
*** Second, what previous standards are people actually using today? If there is more than one, then lean towards those with the better adoption.
***And only after those first two do we bother to pay attention to theoretical standards, those that have been invented (whether by individuals, committees), but haven't seen much if any actual adoption.
* [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 2000-03-21 Dan Connolly on human-consumable information]: ('''strong emphasis''' added)
** I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to '''manage the information in human-consumable form (XHTML) annotated with just enough info to extract''' the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. '''We all know that we have to produce a human-readable version of the thing... why not use that as the primary source?'''

introduction-fr

2006-06-27T09:57:44Z

SebastienSauteur: amorce traduction introduction-fr

__NOTOC__

<h1> Introduction aux Microformats </h1>

Related: [[press]], [[presentations]], [[podcasts]], [[suggested-reading]], [[testimonials]]

__TOC__

== Que sont les Microformats? ==

Microformats are the "dictionaries" of XHTML semantic content. They are for codifying commonly used information-rich HTML content in such a way that semantic meaning can be machine extracted. In short, they are the easiest-possible way to design data (or data formats) intended for reuse on the Web.

== Pourquoi les Microformats ==

Why did we come up with microformats?

In short, microformats are the convergence of a number of trends:
# a logical next step in the evolution of web design and information architecture
# a way for self-publishers to publish richer information themselves, without having to rely upon centralized services
# an acknowledgment that "traditional" metadata efforts have either failed or taken so long to garner any adoption, that a new approach was necessary
# a way to use (X)HTML for data.

=== Evolution du Web Design ===

In the beginning (1990), there was [http://www.w3.org/MarkUp/ HTML] and it was good. It was simple, minimal, and used to semantically markup user visible data (text) and share it on the World Wide Web.

Then came the [http://en.wikipedia.org/wiki/Browser_wars browser wars] (1994-1999) where dominant browser manufacturers took their turns introducing "innovative" presentational tags, giving the typical web author/designer what they wanted: a semblance of control over the presentation of their webpages. The result: [http://www.w3.org/TR/REC-html32 HTML 3.2] "standardized" these defacto presentational innovations.

The introduction of [http://www.w3.org/TR/REC-CSS1 CSS1] (1996) and the semantically richer [http://www.w3.org/TR/REC-html40/ HTML4] (1998) brought a glimmer of hope, but it wasn't until years later (2000-2001), with the introduction of fully compliant (or almost) implementations of CSS1/HTML4 (IE5/Mac, IE6/Windows, Netscape 6) that it became practical for web designers to depend on CSS in their web pages. Leaders in the community began to furiously adopt and promote CSS (even if it took [http://www.tantek.com/log/2004/07.html#ie5macbandpass a] [http://tantek.com/CSS/Examples/boxmodelhack.html hack] [http://www.tantek.com/CSS/Examples/midpass.html or] [http://tantek.com/CSS/Examples/highpass.html two]) and the efficiencies and enhanced productivity that separating presentation from markup brought them, yet remained a small vocal minority.

The introduction of the Wired News redesign in 100% CSS, and the beautiful [http://csszengarden.com/ CSS Zen Garden] (2002-2003) was CSS's tipping point. With the clear and obvious presentation of visual beauty and broad creativity, designers world-wide "got it" and realized that this was the future of web design. The presentational markup of <code><FONT></code>, <code><TABLE></code>, and <code>spacer.gif</code> were tossed aside by any and all self-respecting web designers, who discovered the near infinite flexibility of <code><div></code>, <code><span></code>, and the 'class' attribute. A few in the community even began adopting some of the more semantic elements in HTML: <code><p></code>, <code><h1></code>...<code><h6></code>, <code><ol></code>, <code><ul></code>, <code><li></code>, <code><em></code>, <code><strong></code>. Leaders in the community exercised the semantic limits of strict HTML4 (experimented with XHTML) and documented [http://www.simplebits.com/publications/solutions/ best practices].

As the community followed rapidly in the footpaths they had worn, the leaders began to run into the limits of semantic (X)HTML. Other subcultures were attempting to rewrite the world in their own language(s) (<abbr title="Resource Description Framework">[http://www.w3.org/RDF/ RDF]</abbr>, [[plain-xml|"plain" XML]], <abbr title="Scalable Vector Graphics">[http://www.w3.org/TR/SVG/ SVG]</abbr>), yet not having much of an impact on the World Wide Web, which required human presentable data, compatible with the browsers people already used. [http://en.wikipedia.org/wiki/Social_software Social Software] and [http://en.wikipedia.org/wiki/Blogs Blogs], written by this new generation of web designers and programmers, began to take off.

Natural patterns emerged from the way people used blogging systems, putting things into lists, for example lists of other bloggers (known as blogrolls), and annotating them with information representing relationships such has having met, friends, family, etc. The first microformat, <abbr title="XHTML Friends Network">[http://gmpg.org/xfn/ XFN]</abbr>, was designed to match these behaviors, and [http://tantek.com/log/2003/12.html#L20031215t0830 introduced to the blogging community] (2003-2004), who adopted it within weeks. The [http://gmpg.org GMPG] was formed as a home for XFN, and documented a few key [http://gmpg.org/principles design principles] later adopted for microformats. The key notion, that semantic (X)HTML could be extended, had been introduced and accepted by the community.

By understanding, using, and combining semantic (X)HTML building blocks, as well as determining that semantic (X)HTML could be validly extended via new rel, meta name, and class values, defined in (X)HTML profiles in the [http://gmpg.org/xmdp XMDP format], the community began to design and develop many more microformats (2004-2005). More patterns emerged from the blogging community, and each aggregate human behavior drove the design of simple, adaptive microformats to meet its needs. Creative Commons licensing became popular and [[rel-license]] was proposed. Outlines and lists: [[xoxo|XOXO]]. Contact info: [[hcard|hCard]]. Calendars and events [[hcalendar|hCalendar]].

Using these new found building blocks, the web design and information architecture communities were no longer limited by the predefined semantics of HTML4 (nor did they have to compromise human presentation and ease of authoring which other attempts sorely lacked). 2005 may well be the year that microformats became the next step in the evolution of the web.

=== L'Attrait de la Simplicité ===

* Microformats are a simple effort which has appealed to many frustrated with previous complex efforts. One parallel that can be drawn is to REST in the web services world, i.e. see this [http://www.windley.com/archives/2005/07/microformats.shtml comparison of microformats and REST]. See the [http://rest.blueoxen.net REST wiki] for more about REST. Related [http://patricklogan.blogspot.com/2006/01/microformat-microprotocol.html microformats and microprotocols].
* See also: [http://www.justinleavesley.com/journal/2005/7/28/web-services-and-the-innovators-dilemma.html Web Services and the Innovators Dilemma] by Justin Leavesley

== Pages en rapport ==
* Recent [[press]] interviews and articles are also a good introduction.
* See microformat [[presentations]] for more background and introductory material on [[microformats]].
* Listen to [[podcasts]] about microformats.
* More [[suggested-reading|suggested reading]]
* [[implement|So you wanna implement microformats?]]

== Articles ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon
* [http://www.gr0w.com/articles/design/an_extra_side_to_web_standards_based_design/ An Extra SIDE to Web Standards Based Design] - How Semantic Information Design Ethics (SIDE) and a few readily available techniques can help heal the Web, by Jon Tan. See also his [http://www.csszengarden.com/?cssfile=/193/193.css&page=0 CSS Zen Garden "Leggo my ego" entry].
* [http://thedredge.org/ Andrew D. Hume] has written a blog post [http://thedredge.org/2005/07/introducing-microformats/ introducing microformats] and another one on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats].
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect Seearch Engine Optimization]
* [http://blogbusinesssummit.com/2006/04/microformats_in.htm Blog Business Summit: Microformats in Plain English: the Promise of Simple Business to Business Data Exchange] by Steve Broback

== Références diverses ==

These are various intro-related links/articles which I haven't figured out yet how to incorporate. You may find them of interest. - [http://tantek.com/log/ Tantek]

* [http://www.betaversion.org/~stefano/linotype/news/93/ Data First vs. Structure First]
** [http://tantek.com/log/ Tantek] says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem.
*** Zeroeth, define the real-world problem. If you can't do this, then stop.
*** First, look at real-world usage (data).
*** Second, what previous standards are people actually using today? If there is more than one, then lean towards those with the better adoption.
***And only after those first two do we bother to pay attention to theoretical standards, those that have been invented (whether by individuals, committees), but haven't seen much if any actual adoption.
* [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 2000-03-21 Dan Connolly on human-consumable information]: ('''strong emphasis''' added)
** I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to '''manage the information in human-consumable form (XHTML) annotated with just enough info to extract''' the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. '''We all know that we have to produce a human-readable version of the thing... why not use that as the primary source?'''

User talk:SebastienSauteur

2006-06-21T09:55:14Z

SebastienSauteur: @Christophe : tout prêt pour.

Content de te voir ici Sébastien. Et merci de ton aide. Je crois que nous allons avoir beaucoup de travaux ici et ailleurs. Hâte de pouvoir tester les [[VoteLinks]]. Dès que j'ai de la connexion moins chère qu'à la campagne, je compte attaquer la traductioin de la spec en [[VoteLinks-fr]]. Plein d'articles pas encore publiés, notamment les points puisssants qui traînent. Que dirais-tu d'amorcer la mini-communauté microformats-fr ? A plus tard. -- [[User:ChristopheDucamp|Christophe Ducamp]] | <small>[[User talk:ChristopheDucamp|talk]]</small> 15:45, 20 Jun 2006 (PDT)

''Salut Christophe. Avec plaisir pour continuer à avancer sur le sujet, et participer à sa dynamique francophone - ces microformats me semblent aussi porter en germe plein de réponses... La page [[to-do-fr|to-do-fr]] pourra nous permettre dans un premier temps d'avancer petit à petit ? Vraisemblablement j'aurai un mode de connexion en pointillé pendant l'été... mais je suis de toutes les façons ;-) ----[[User:SebastienSauteur|SebastienSauteur]] 02:55, 21 Jun 2006 (PDT)''

process-fr

2006-06-20T10:47:50Z

SebastienSauteur: /* Passer d'une Etape à un autre Etape */

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvons d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ensuite seulement élaborer des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous pensez toujours que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un bloc-notes général. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous avez besoin d'écrire un long document, vous essayez probablement de résoudre un trop gros problème - voir le paragraphe précédent.

==Documentez les Comportements Existants==
Documentez les comportements humains existants. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Il faut que vos [[exemples-fr|exemples]] soient une collection de pages et de sites réels, qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, il vous faut extraire des exemples de balisages et les schémas impliqués là-dedans, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques existantes concernant les critiques/compte-rendus (reviews) qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas impliqués dedans.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui se soit déjà frotté au même problème que celui qui vous occupe. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec d'autres qui ont rencontré le même problème. Nous ne voulons pas construire des murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation d'éléments XHTML, et sur la construction de combinaisons d'éléments XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Tout d'abord, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe des standards bien établis, implémentés de façon interopérable, vers lesquels se tourner et qui solutionnent ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé de nombreuses années dans des comités de standardisation, à défendre et à développer les schémas. Il est préférable de s'appuyer sur le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats doivent être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas CSS, ou dont cette fonctionnalité a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables avec CSS ?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedbacks'' de la part d'autres personnes intéressées par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et pourra entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des tentatives fructueuses pour développer des microformats : plusieurs sortes de pages wikis spécifiques sont créees dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème posé (*) ait été déterminé (principe n°1), envisagez de créer et de remplir les pages suivantes à son sujet. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples existants sur le web du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qu'impliquent ces exemples de contenu. Cette action vous aidera à respecter le principe n°3, conception pour les humains d'abord, et pour les machines ensuite... adaptez aux comportement courants et aux "patterns" d'usage.
# *-formats. Trouvez des formats et des standards de données existants interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser des briques de standards largement adoptés".
# *-brainstorming. Utiliser les exemples actuels du web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de certains cas d'usages, ou peut-être des cas d'usages entiers, qui sont plus des cas limites, qu'ils ne sont représentatifs de comportements plus large, de niveau aggregation/macro. Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité). Utiliser ces formats et schémas de données existants comme une [[existing-classes|source de noms]] pour les champs (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'autres formats (également le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champs, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encouragent la distribution décentralisée des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il semble qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous la forme d'une specification "draft" sur une page séparée du wiki.
# **-faq. Il y aura probablement des questions récurrentes à propos du nouveau microformat, qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Il se peut également qu'il y en ait qui soulèvent des problématiques à propos du microformat, qui ne puissent pas être traitées immédiatemment. Un document dédié aidera en servant à enregistrer ces problématiques, en consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifications, cette liste méritant sa propre page.

=== Passer d'une Etape à un autre Etape ===

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis dans les sections "Discussions exploratoires", "Drafts", et "Spécifications". Comment les microformats passent-ils d'une étape à une autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

==== Discussions Exploratoires ====

Vous avez besoin d'un problème, et il vous faut essayer de l'énoncer. Faites le sur ce wiki en utilisant comme guide les items situés sous "Discussion Exploratoire". Envoyez ensuite une note à la liste microformats-discuss, pour attirer l'attention d'autres personnes qui s'intéressent aux microformats. Ceci est un probablement un bon moyen pour amener ici des personnes extérieures à la communauté actuelles des microformats, et qui peuvent être confronté à la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problème, questionner le besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback pourra être que vous décidiez d'abandonner votre idée de microformat, ou de la modifier substanciellement. Une chose que vous êtes certain de vouloir faire à ce stade, est d'éviter de [[reinvented-wheels|réinventer la roue]]. Il y a t'il des microformats élémentaires que vous pouvez réutiliser comme des "briques" ? En procédant ainsi, vous vous économiserez des efforts, et cela vous aidera dans l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

Ceci étant ne soyez pas intimidé pour aller de l'avant, juste parce que certaines personnes ont des objections. Si vous arrivez à trouver un groupe de personnes que vous respectez, qui sentent que votre idée a du mérite et, c'est peut être le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

==== Brouillons (Drafts) ====

Ici, vous devez écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vous devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer du feedback depuis des sources pertinentes extérieures à la communauté. Les "drafts" devront comporter au minimum ce qui suit :

* Une déclaration concernant le fait que vous ne déposerez pas de brevet, et que vous adoptez un copyright approprié, tel qu'illustré par les drafts actuels.
* Une déclaration XMDP déclarant les valeurs d'attributs. Vous pouvez préférer la placer sur une page à part du wiki, et faire un lien vers elle. Dans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Garder un oeil sur la façon dont le microformat améliore réellement les choses. Si ce n'est pas le cas, c'est peut être une indication que vous devriez l'abandonner, ou lui apporter de grands changements.
* Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" (issues) pour permettre aux gens de vous remonter leur 'feedback' avec des objections détaillées.

==== Spécifications ====

Vous aurez en général besoin d'au moins une itération pour passer l'étape du "draft". Une fois que les choses deviennent des spécifications, cela suppose qu'elles soient stables, de façon à ce que les développeurs puissent s'en emparer et écrire pour elles. Ceci implique aussi qu'il y ait au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objections majeures. Si aucune réponse ne vient, déplacez le microformat dans la zone "spécifications". Ce mouvement réveillera les éventuels éditeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoient au stade "draft". Si vous avez suivi le process, il est temps désormais de fixer les choses. A ce stade, toutes les problématiques restantes devraient être faciles à résoudre.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-20T10:11:46Z

SebastienSauteur: /* Itération */

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvons d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ensuite seulement élaborer des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous pensez toujours que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un bloc-notes général. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous avez besoin d'écrire un long document, vous essayez probablement de résoudre un trop gros problème - voir le paragraphe précédent.

==Documentez les Comportements Existants==
Documentez les comportements humains existants. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Il faut que vos [[exemples-fr|exemples]] soient une collection de pages et de sites réels, qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, il vous faut extraire des exemples de balisages et les schémas impliqués là-dedans, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques existantes concernant les critiques/compte-rendus (reviews) qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas impliqués dedans.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui se soit déjà frotté au même problème que celui qui vous occupe. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec d'autres qui ont rencontré le même problème. Nous ne voulons pas construire des murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation d'éléments XHTML, et sur la construction de combinaisons d'éléments XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Tout d'abord, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe des standards bien établis, implémentés de façon interopérable, vers lesquels se tourner et qui solutionnent ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé de nombreuses années dans des comités de standardisation, à défendre et à développer les schémas. Il est préférable de s'appuyer sur le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats doivent être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas CSS, ou dont cette fonctionnalité a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables avec CSS ?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedbacks'' de la part d'autres personnes intéressées par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et pourra entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des tentatives fructueuses pour développer des microformats : plusieurs sortes de pages wikis spécifiques sont créees dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème posé (*) ait été déterminé (principe n°1), envisagez de créer et de remplir les pages suivantes à son sujet. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples existants sur le web du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qu'impliquent ces exemples de contenu. Cette action vous aidera à respecter le principe n°3, conception pour les humains d'abord, et pour les machines ensuite... adaptez aux comportement courants et aux "patterns" d'usage.
# *-formats. Trouvez des formats et des standards de données existants interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser des briques de standards largement adoptés".
# *-brainstorming. Utiliser les exemples actuels du web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de certains cas d'usages, ou peut-être des cas d'usages entiers, qui sont plus des cas limites, qu'ils ne sont représentatifs de comportements plus large, de niveau aggregation/macro. Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité). Utiliser ces formats et schémas de données existants comme une [[existing-classes|source de noms]] pour les champs (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'autres formats (également le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champs, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encouragent la distribution décentralisée des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il semble qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous la forme d'une specification "draft" sur une page séparée du wiki.
# **-faq. Il y aura probablement des questions récurrentes à propos du nouveau microformat, qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Il se peut également qu'il y en ait qui soulèvent des problématiques à propos du microformat, qui ne puissent pas être traitées immédiatemment. Un document dédié aidera en servant à enregistrer ces problématiques, en consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifications, cette liste méritant sa propre page.

=== Passer d'une Etape à un autre Etape ===

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis en "Discussions exploratoires", Drafts, et Spécifications. Comment les microformats évoluent-ils d'une étape à una autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

==== Discussions Exploratoires ====

Vous devez avoir un problème, et vous devez essayer de l'énoncer. Vous devriez le faire sur ce wiki en utilisant comme un guide, les items qui se trouvent actuellement sous la "discussion exploratoire". Ensuite, envoyez une note à la liste microformats-discuss pour capter l'attention d'autres personnes qui s'intéressent également aux microformats. C'est un moyen d'éventuellement amener ici des personnes qui sont extérieures à cette communauté sur les microformats, et qui pourraient rencontrer la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problem, du besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback, peut être que vous décidiez d'abandonner votre idée de microformat ou de la modifier substanciellement. Une chose que vous êtes certain de désirer à ce stade, c'est d'éviter de [[reinvented-wheels|reinventing the wheel]]. Il y a t'il des microformats élémentaires que vous pouvez réutiliser en tant que briques ? Si vous le faites, vous économiserez vos efforts et cela vous aidera pour l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

Ceci étant, ne soyez pas intimidé pour aller de l'avant juste parce que certaiens personnes ont des objections. Si vous pouvez trouver un groupe de personnes que vous respectez, et qui sentent que votre idée a du mérite et, et c'est peut être le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

==== Brouillons ====

Ici, il vous faut écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vosu devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer du feedback depuis des sources pertinentes qui soient à l'extérieur de la communauté. Les "drafts" devront comporter au minimum ce qui suit :

* Une déclaration conernant le fait que vous ne déposerez pas de brevet et que vous adopter un copyright approprié tel qu'illustré par les drafts actuels.
* Une déclaration XMDP déclarant les "attribute values". Vous pouvez souhaiter la placer sur une page wiki séparée ; faites alors un lien vers elle.. Dans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Garder un oeil sur la valeur ajoutée du microformat en usage. S'il n'y en a pas, c'est peut être une indication que vous devriez l'abandonner ou lui apporter de grand changement.
* Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous donner leur "feedback" avec des objections détaillées.

==== Spécifications ====

Vous aurez généralement besoin d'au moins une itération pour dépasser l'étape du brouillon. Quand quelquechose devient une spécification, elle doit être stable de façon à ce que les développeurs puissent s'en emparer et écrire dessus. Ceci implique à son tour qu'il y a au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objectiosn majeures. Si rien ne vient, déplacer le microformat dans la zone des spécifications. The déplacement réveillera les editeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoie au stade "brouillon". Si vous avez suivi le process, il est temps désormais de fixer votre travail. A ce stade, toutes les problématiques restantes devraient être facile à résoudre.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-20T09:53:47Z

SebastienSauteur: /* Proposez un Microformat */

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvons d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ensuite seulement élaborer des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous pensez toujours que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un bloc-notes général. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous avez besoin d'écrire un long document, vous essayez probablement de résoudre un trop gros problème - voir le paragraphe précédent.

==Documentez les Comportements Existants==
Documentez les comportements humains existants. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Il faut que vos [[exemples-fr|exemples]] soient une collection de pages et de sites réels, qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, il vous faut extraire des exemples de balisages et les schémas impliqués là-dedans, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques existantes concernant les critiques/compte-rendus (reviews) qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas impliqués dedans.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui se soit déjà frotté au même problème que celui qui vous occupe. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec d'autres qui ont rencontré le même problème. Nous ne voulons pas construire des murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation d'éléments XHTML, et sur la construction de combinaisons d'éléments XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Tout d'abord, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe des standards bien établis, implémentés de façon interopérable, vers lesquels se tourner et qui solutionnent ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé de nombreuses années dans des comités de standardisation, à défendre et à développer les schémas. Il est préférable de s'appuyer sur le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats doivent être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas CSS, ou dont cette fonctionnalité a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables avec CSS ?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des efforts fructueux dans le développement des microformats, de plusieurs sortes de pages wikis spécifiques qui se créent dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), envisager de créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
# *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser les briques des standard largement adoptés".
# *-brainstorming. Utiliser les exemples courants existants sur le web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de quelques cas d'usages, ou peut-être des cas d'usages entiers qui sont plus des cas limites qu'ils ne sont représentatifs de comportements plus large (aggregation/macro). Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité. Utiliser ces formats et schémas de données existants comme des [[existing-classes|source of names]] pour les champs considérés (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'aurtes formats (aussi le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champ, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encourage la distribution décentralisées des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il apparaît qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous forme de specification "draft" en tant que page séparée du wiki.
# **-faq. Il y aura probablement des questions couramment posées à propos du nouveau microformat et qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Ils se peut qu'il y en ait qui soulevent également des problématiques à propos du microformat, qui ne soient pas immédiatemment traitables. Un document dédié aidera et servira à enregistrer ces problématiques, consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifiactions, c'est pourquoi cette liste mérite sa propre page.

=== Avancer d'Etape en Etape===

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis en "Discussions exploratoires", Drafts, et Spécifications. Comment les microformats évoluent-ils d'une étape à una autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

==== Discussions Exploratoires ====

Vous devez avoir un problème, et vous devez essayer de l'énoncer. Vous devriez le faire sur ce wiki en utilisant comme un guide, les items qui se trouvent actuellement sous la "discussion exploratoire". Ensuite, envoyez une note à la liste microformats-discuss pour capter l'attention d'autres personnes qui s'intéressent également aux microformats. C'est un moyen d'éventuellement amener ici des personnes qui sont extérieures à cette communauté sur les microformats, et qui pourraient rencontrer la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problem, du besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback, peut être que vous décidiez d'abandonner votre idée de microformat ou de la modifier substanciellement. Une chose que vous êtes certain de désirer à ce stade, c'est d'éviter de [[reinvented-wheels|reinventing the wheel]]. Il y a t'il des microformats élémentaires que vous pouvez réutiliser en tant que briques ? Si vous le faites, vous économiserez vos efforts et cela vous aidera pour l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

Ceci étant, ne soyez pas intimidé pour aller de l'avant juste parce que certaiens personnes ont des objections. Si vous pouvez trouver un groupe de personnes que vous respectez, et qui sentent que votre idée a du mérite et, et c'est peut être le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

==== Brouillons ====

Ici, il vous faut écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vosu devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer du feedback depuis des sources pertinentes qui soient à l'extérieur de la communauté. Les "drafts" devront comporter au minimum ce qui suit :

* Une déclaration conernant le fait que vous ne déposerez pas de brevet et que vous adopter un copyright approprié tel qu'illustré par les drafts actuels.
* Une déclaration XMDP déclarant les "attribute values". Vous pouvez souhaiter la placer sur une page wiki séparée ; faites alors un lien vers elle.. Dans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Garder un oeil sur la valeur ajoutée du microformat en usage. S'il n'y en a pas, c'est peut être une indication que vous devriez l'abandonner ou lui apporter de grand changement.
* Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous donner leur "feedback" avec des objections détaillées.

==== Spécifications ====

Vous aurez généralement besoin d'au moins une itération pour dépasser l'étape du brouillon. Quand quelquechose devient une spécification, elle doit être stable de façon à ce que les développeurs puissent s'en emparer et écrire dessus. Ceci implique à son tour qu'il y a au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objectiosn majeures. Si rien ne vient, déplacer le microformat dans la zone des spécifications. The déplacement réveillera les editeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoie au stade "brouillon". Si vous avez suivi le process, il est temps désormais de fixer votre travail. A ce stade, toutes les problématiques restantes devraient être facile à résoudre.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-20T09:41:29Z

SebastienSauteur: /* Pourquoi ? */

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvons d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ensuite seulement élaborer des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous pensez toujours que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un bloc-notes général. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous avez besoin d'écrire un long document, vous essayez probablement de résoudre un trop gros problème - voir le paragraphe précédent.

==Documentez les Comportements Existants==
Documentez les comportements humains existants. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Il faut que vos [[exemples-fr|exemples]] soient une collection de pages et de sites réels, qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, il vous faut extraire des exemples de balisages et les schémas impliqués là-dedans, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques existantes concernant les critiques/compte-rendus (reviews) qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas impliqués dedans.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui se soit déjà frotté au même problème que celui qui vous occupe. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec d'autres qui ont rencontré le même problème. Nous ne voulons pas construire des murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des efforts fructueux dans le développement des microformats, de plusieurs sortes de pages wikis spécifiques qui se créent dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), envisager de créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
# *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser les briques des standard largement adoptés".
# *-brainstorming. Utiliser les exemples courants existants sur le web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de quelques cas d'usages, ou peut-être des cas d'usages entiers qui sont plus des cas limites qu'ils ne sont représentatifs de comportements plus large (aggregation/macro). Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité. Utiliser ces formats et schémas de données existants comme des [[existing-classes|source of names]] pour les champs considérés (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'aurtes formats (aussi le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champ, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encourage la distribution décentralisées des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il apparaît qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous forme de specification "draft" en tant que page séparée du wiki.
# **-faq. Il y aura probablement des questions couramment posées à propos du nouveau microformat et qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Ils se peut qu'il y en ait qui soulevent également des problématiques à propos du microformat, qui ne soient pas immédiatemment traitables. Un document dédié aidera et servira à enregistrer ces problématiques, consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifiactions, c'est pourquoi cette liste mérite sa propre page.

=== Avancer d'Etape en Etape===

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis en "Discussions exploratoires", Drafts, et Spécifications. Comment les microformats évoluent-ils d'une étape à una autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

==== Discussions Exploratoires ====

Vous devez avoir un problème, et vous devez essayer de l'énoncer. Vous devriez le faire sur ce wiki en utilisant comme un guide, les items qui se trouvent actuellement sous la "discussion exploratoire". Ensuite, envoyez une note à la liste microformats-discuss pour capter l'attention d'autres personnes qui s'intéressent également aux microformats. C'est un moyen d'éventuellement amener ici des personnes qui sont extérieures à cette communauté sur les microformats, et qui pourraient rencontrer la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problem, du besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback, peut être que vous décidiez d'abandonner votre idée de microformat ou de la modifier substanciellement. Une chose que vous êtes certain de désirer à ce stade, c'est d'éviter de [[reinvented-wheels|reinventing the wheel]]. Il y a t'il des microformats élémentaires que vous pouvez réutiliser en tant que briques ? Si vous le faites, vous économiserez vos efforts et cela vous aidera pour l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

Ceci étant, ne soyez pas intimidé pour aller de l'avant juste parce que certaiens personnes ont des objections. Si vous pouvez trouver un groupe de personnes que vous respectez, et qui sentent que votre idée a du mérite et, et c'est peut être le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

==== Brouillons ====

Ici, il vous faut écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vosu devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer du feedback depuis des sources pertinentes qui soient à l'extérieur de la communauté. Les "drafts" devront comporter au minimum ce qui suit :

* Une déclaration conernant le fait que vous ne déposerez pas de brevet et que vous adopter un copyright approprié tel qu'illustré par les drafts actuels.
* Une déclaration XMDP déclarant les "attribute values". Vous pouvez souhaiter la placer sur une page wiki séparée ; faites alors un lien vers elle.. Dans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Garder un oeil sur la valeur ajoutée du microformat en usage. S'il n'y en a pas, c'est peut être une indication que vous devriez l'abandonner ou lui apporter de grand changement.
* Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous donner leur "feedback" avec des objections détaillées.

==== Spécifications ====

Vous aurez généralement besoin d'au moins une itération pour dépasser l'étape du brouillon. Quand quelquechose devient une spécification, elle doit être stable de façon à ce que les développeurs puissent s'en emparer et écrire dessus. Ceci implique à son tour qu'il y a au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objectiosn majeures. Si rien ne vient, déplacer le microformat dans la zone des spécifications. The déplacement réveillera les editeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoie au stade "brouillon". Si vous avez suivi le process, il est temps désormais de fixer votre travail. A ce stade, toutes les problématiques restantes devraient être facile à résoudre.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-20T09:40:33Z

SebastienSauteur: /* Documentez les Comportements Actuels */

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvons d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ensuite seulement élaborer des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un bloc-notes général. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous avez besoin d'écrire un long document, vous essayez probablement de résoudre un trop gros problème - voir le paragraphe précédent.

==Documentez les Comportements Existants==
Documentez les comportements humains existants. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Il faut que vos [[exemples-fr|exemples]] soient une collection de pages et de sites réels, qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, il vous faut extraire des exemples de balisages et les schémas impliqués là-dedans, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques existantes concernant les critiques/compte-rendus (reviews) qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas impliqués dedans.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui se soit déjà frotté au même problème que celui qui vous occupe. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec d'autres qui ont rencontré le même problème. Nous ne voulons pas construire des murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des efforts fructueux dans le développement des microformats, de plusieurs sortes de pages wikis spécifiques qui se créent dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), envisager de créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
# *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser les briques des standard largement adoptés".
# *-brainstorming. Utiliser les exemples courants existants sur le web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de quelques cas d'usages, ou peut-être des cas d'usages entiers qui sont plus des cas limites qu'ils ne sont représentatifs de comportements plus large (aggregation/macro). Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité. Utiliser ces formats et schémas de données existants comme des [[existing-classes|source of names]] pour les champs considérés (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'aurtes formats (aussi le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champ, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encourage la distribution décentralisées des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il apparaît qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous forme de specification "draft" en tant que page séparée du wiki.
# **-faq. Il y aura probablement des questions couramment posées à propos du nouveau microformat et qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Ils se peut qu'il y en ait qui soulevent également des problématiques à propos du microformat, qui ne soient pas immédiatemment traitables. Un document dédié aidera et servira à enregistrer ces problématiques, consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifiactions, c'est pourquoi cette liste mérite sa propre page.

=== Avancer d'Etape en Etape===

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis en "Discussions exploratoires", Drafts, et Spécifications. Comment les microformats évoluent-ils d'une étape à una autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

==== Discussions Exploratoires ====

Vous devez avoir un problème, et vous devez essayer de l'énoncer. Vous devriez le faire sur ce wiki en utilisant comme un guide, les items qui se trouvent actuellement sous la "discussion exploratoire". Ensuite, envoyez une note à la liste microformats-discuss pour capter l'attention d'autres personnes qui s'intéressent également aux microformats. C'est un moyen d'éventuellement amener ici des personnes qui sont extérieures à cette communauté sur les microformats, et qui pourraient rencontrer la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problem, du besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback, peut être que vous décidiez d'abandonner votre idée de microformat ou de la modifier substanciellement. Une chose que vous êtes certain de désirer à ce stade, c'est d'éviter de [[reinvented-wheels|reinventing the wheel]]. Il y a t'il des microformats élémentaires que vous pouvez réutiliser en tant que briques ? Si vous le faites, vous économiserez vos efforts et cela vous aidera pour l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

Ceci étant, ne soyez pas intimidé pour aller de l'avant juste parce que certaiens personnes ont des objections. Si vous pouvez trouver un groupe de personnes que vous respectez, et qui sentent que votre idée a du mérite et, et c'est peut être le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

==== Brouillons ====

Ici, il vous faut écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vosu devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer du feedback depuis des sources pertinentes qui soient à l'extérieur de la communauté. Les "drafts" devront comporter au minimum ce qui suit :

* Une déclaration conernant le fait que vous ne déposerez pas de brevet et que vous adopter un copyright approprié tel qu'illustré par les drafts actuels.
* Une déclaration XMDP déclarant les "attribute values". Vous pouvez souhaiter la placer sur une page wiki séparée ; faites alors un lien vers elle.. Dans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Garder un oeil sur la valeur ajoutée du microformat en usage. S'il n'y en a pas, c'est peut être une indication que vous devriez l'abandonner ou lui apporter de grand changement.
* Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous donner leur "feedback" avec des objections détaillées.

==== Spécifications ====

Vous aurez généralement besoin d'au moins une itération pour dépasser l'étape du brouillon. Quand quelquechose devient une spécification, elle doit être stable de façon à ce que les développeurs puissent s'en emparer et écrire dessus. Ceci implique à son tour qu'il y a au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objectiosn majeures. Si rien ne vient, déplacer le microformat dans la zone des spécifications. The déplacement réveillera les editeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoie au stade "brouillon". Si vous avez suivi le process, il est temps désormais de fixer votre travail. A ce stade, toutes les problématiques restantes devraient être facile à résoudre.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-20T09:33:56Z

SebastienSauteur: /* Pourquoi ? */

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvons d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ensuite seulement élaborer des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un bloc-notes général. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous avez besoin d'écrire un long document, vous essayez probablement de résoudre un trop gros problème - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des
opérateurs. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balisages et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui ait rencontré le même problème que celui sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des efforts fructueux dans le développement des microformats, de plusieurs sortes de pages wikis spécifiques qui se créent dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), envisager de créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
# *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser les briques des standard largement adoptés".
# *-brainstorming. Utiliser les exemples courants existants sur le web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de quelques cas d'usages, ou peut-être des cas d'usages entiers qui sont plus des cas limites qu'ils ne sont représentatifs de comportements plus large (aggregation/macro). Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité. Utiliser ces formats et schémas de données existants comme des [[existing-classes|source of names]] pour les champs considérés (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'aurtes formats (aussi le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champ, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encourage la distribution décentralisées des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il apparaît qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous forme de specification "draft" en tant que page séparée du wiki.
# **-faq. Il y aura probablement des questions couramment posées à propos du nouveau microformat et qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Ils se peut qu'il y en ait qui soulevent également des problématiques à propos du microformat, qui ne soient pas immédiatemment traitables. Un document dédié aidera et servira à enregistrer ces problématiques, consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifiactions, c'est pourquoi cette liste mérite sa propre page.

=== Avancer d'Etape en Etape===

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis en "Discussions exploratoires", Drafts, et Spécifications. Comment les microformats évoluent-ils d'une étape à una autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

==== Discussions Exploratoires ====

Vous devez avoir un problème, et vous devez essayer de l'énoncer. Vous devriez le faire sur ce wiki en utilisant comme un guide, les items qui se trouvent actuellement sous la "discussion exploratoire". Ensuite, envoyez une note à la liste microformats-discuss pour capter l'attention d'autres personnes qui s'intéressent également aux microformats. C'est un moyen d'éventuellement amener ici des personnes qui sont extérieures à cette communauté sur les microformats, et qui pourraient rencontrer la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problem, du besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback, peut être que vous décidiez d'abandonner votre idée de microformat ou de la modifier substanciellement. Une chose que vous êtes certain de désirer à ce stade, c'est d'éviter de [[reinvented-wheels|reinventing the wheel]]. Il y a t'il des microformats élémentaires que vous pouvez réutiliser en tant que briques ? Si vous le faites, vous économiserez vos efforts et cela vous aidera pour l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

Ceci étant, ne soyez pas intimidé pour aller de l'avant juste parce que certaiens personnes ont des objections. Si vous pouvez trouver un groupe de personnes que vous respectez, et qui sentent que votre idée a du mérite et, et c'est peut être le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

==== Brouillons ====

Ici, il vous faut écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vosu devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer du feedback depuis des sources pertinentes qui soient à l'extérieur de la communauté. Les "drafts" devront comporter au minimum ce qui suit :

* Une déclaration conernant le fait que vous ne déposerez pas de brevet et que vous adopter un copyright approprié tel qu'illustré par les drafts actuels.
* Une déclaration XMDP déclarant les "attribute values". Vous pouvez souhaiter la placer sur une page wiki séparée ; faites alors un lien vers elle.. Dans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Garder un oeil sur la valeur ajoutée du microformat en usage. S'il n'y en a pas, c'est peut être une indication que vous devriez l'abandonner ou lui apporter de grand changement.
* Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous donner leur "feedback" avec des objections détaillées.

==== Spécifications ====

Vous aurez généralement besoin d'au moins une itération pour dépasser l'étape du brouillon. Quand quelquechose devient une spécification, elle doit être stable de façon à ce que les développeurs puissent s'en emparer et écrire dessus. Ceci implique à son tour qu'il y a au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objectiosn majeures. Si rien ne vient, déplacer le microformat dans la zone des spécifications. The déplacement réveillera les editeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoie au stade "brouillon". Si vous avez suivi le process, il est temps désormais de fixer votre travail. A ce stade, toutes les problématiques restantes devraient être facile à résoudre.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-19T13:07:13Z

SebastienSauteur: à relire.....

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des
opérateurs. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balisages et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui ait rencontré le même problème que celui sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des efforts fructueux dans le développement des microformats, de plusieurs sortes de pages wikis spécifiques qui se créent dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), envisager de créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
# *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser les briques des standard largement adoptés".
# *-brainstorming. Utiliser les exemples courants existants sur le web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de quelques cas d'usages, ou peut-être des cas d'usages entiers qui sont plus des cas limites qu'ils ne sont représentatifs de comportements plus large (aggregation/macro). Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité. Utiliser ces formats et schémas de données existants comme des [[existing-classes|source of names]] pour les champs considérés (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'aurtes formats (aussi le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champ, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encourage la distribution décentralisées des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il apparaît qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous forme de specification "draft" en tant que page séparée du wiki.
# **-faq. Il y aura probablement des questions couramment posées à propos du nouveau microformat et qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Ils se peut qu'il y en ait qui soulevent également des problématiques à propos du microformat, qui ne soient pas immédiatemment traitables. Un document dédié aidera et servira à enregistrer ces problématiques, consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifiactions, c'est pourquoi cette liste mérite sa propre page.

=== Avancer d'Etape en Etape===

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis en "Discussions exploratoires", Drafts, et Spécifications. Comment les microformats évoluent-ils d'une étape à una autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

==== Discussions Exploratoires ====

Vous devez avoir un problème, et vous devez essayer de l'énoncer. Vous devriez le faire sur ce wiki en utilisant comme un guide, les items qui se trouvent actuellement sous la "discussion exploratoire". Ensuite, envoyez une note à la liste microformats-discuss pour capter l'attention d'autres personnes qui s'intéressent également aux microformats. C'est un moyen d'éventuellement amener ici des personnes qui sont extérieures à cette communauté sur les microformats, et qui pourraient rencontrer la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problem, du besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback, peut être que vous décidiez d'abandonner votre idée de microformat ou de la modifier substanciellement. Une chose que vous êtes certain de désirer à ce stade, c'est d'éviter de [[reinvented-wheels|reinventing the wheel]]. Il y a t'il des microformats élémentaires que vous pouvez réutiliser en tant que briques ? Si vous le faites, vous économiserez vos efforts et cela vous aidera pour l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

Ceci étant, ne soyez pas intimidé pour aller de l'avant juste parce que certaiens personnes ont des objections. Si vous pouvez trouver un groupe de personnes que vous respectez, et qui sentent que votre idée a du mérite et, et c'est peut être le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

==== Brouillons ====

Ici, il vous faut écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vosu devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer du feedback depuis des sources pertinentes qui soient à l'extérieur de la communauté. Les "drafts" devront comporter au minimum ce qui suit :

* Une déclaration conernant le fait que vous ne déposerez pas de brevet et que vous adopter un copyright approprié tel qu'illustré par les drafts actuels.
* Une déclaration XMDP déclarant les "attribute values". Vous pouvez souhaiter la placer sur une page wiki séparée ; faites alors un lien vers elle.. Dans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Garder un oeil sur la valeur ajoutée du microformat en usage. S'il n'y en a pas, c'est peut être une indication que vous devriez l'abandonner ou lui apporter de grand changement.
* Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous donner leur "feedback" avec des objections détaillées.

==== Spécifications ====

Vous aurez généralement besoin d'au moins une itération pour dépasser l'étape du brouillon. Quand quelquechose devient une spécification, elle doit être stable de façon à ce que les développeurs puissent s'en emparer et écrire dessus. Ceci implique à son tour qu'il y a au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objectiosn majeures. Si rien ne vient, déplacer le microformat dans la zone des spécifications. The déplacement réveillera les editeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoie au stade "brouillon". Si vous avez suivi le process, il est temps désormais de fixer votre travail. A ce stade, toutes les problématiques restantes devraient être facile à résoudre.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-19T12:24:58Z

SebastienSauteur: /* Pages à considérer pour la création */ traduction à relire

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des
opérateurs. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balisages et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui ait rencontré le même problème que celui sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des efforts fructueux dans le développement des microformats, de plusieurs sortes de pages wikis spécifiques qui se créent dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), envisager de créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
# *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser les briques des standard largement adoptés".
# *-brainstorming. Utiliser les exemples courants existants sur le web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ''ommettre'' quelques éléments de quelques cas d'usages, ou peut-être des cas d'usages entiers qui sont plus des cas limites qu'ils ne sont représentatifs de comportements plus large (aggregation/macro). Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité. Utiliser ces formats et schémas de données existants comme des [[existing-classes|source of names]] pour les champs considérés (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'aurtes formats (aussi le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champ, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encourage la distribution décentralisées des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
# **. Quand il apparaît qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous forme de specification "draft" en tant que page séparée du wiki.
# **-faq. Il y aura probablement des questions couramment posées à propos du nouveau microformat et qui pourront/devront être répondues sur une page FAQ.
# **-problématiques. Ils se peut qu'il y en ait qui soulevent également des problématiques à propos du microformat, qui ne soient pas immédiatemment traitables. Un document dédié aidera et servira à enregistrer ces problématiques, consignant qui les a soulevées, et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
# **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifiactions, c'est pourquoi cette liste mérite sa propre page.

=== Avancer d'Etape en Etape===

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". How do microformats move from one stage to the other? To help answer this question, it's probably useful to write up a set of desiderata for each stage.

==== Discussions Exploratoires ====

You need a problem, and you need to attempt to state it. You should do it on this wiki using current items under exploratory discussion as a guide. Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats. This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

==== Brouillons ====

Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. [[hcard-profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* A list of implementations (if any).
* An issues section for people to feed back to you with detailed objections.

==== Spécifications ====

You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.

Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections. If none are forthcoming, move the microformat to the specifications area. This move will wake up any sleeping editors, and they may raise an objection and move you back to draft. If you have followed the process, now is the time to pin them down. At this juncture, any remaining issues should be easy to resolve.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

User:SebastienSauteur

2006-06-19T11:58:34Z

SebastienSauteur: presentation

bonjour/hi,

* hcard : http://valeurdusage.net/cv
* French speaking and non programmer, I discovered MicroFormats thanks to ChristopheDucamp, who spotted them to me during the BarCamp session in Paris.
* I'll try to help for the translation into french of some of the pages here.

Also, i have in mind a (possible?) kind of microformat usage. We're gonna have presidential elections in France next year. Candidates are soon going to unveil their programms.. how to "link" ? Would it be possible to use microformats, in such a way to articulate some kind of "hVotes" with some kind of "hPoliticalPrograms". Adding microstructuration to candidate programms (may be onto a dedicated wiki), and invite people to express their mind using "hVotes" against those proposals.

Then aggregate decentralized votes, and aggregate and compare "sort of centralized" programms. At this time, i don't know if and how it's possible to do it. It would be obviously, a sort of experience. I'm going to help translate first the "process" page, may be i'll see clearer after...

----
[http://microformats.org/wiki?title=User_talk:SebastienSauteur&action=edit Laisser un message ? / Leave a message ?]

process-fr

2006-06-19T10:36:09Z

SebastienSauteur: /* Itérer */ à suivre...

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des
opérateurs. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balisages et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui ait rencontré le même problème que celui sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du ''feedback'', et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

Un "pattern" a émergé des efforts fructueux dans le développement des microformats de plusieurs sortes de pages spécifiques créées sur des wikis, dans un prdre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), voir à créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

# *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
# *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés de résoudre le problème. Documentez leurs schémas explicites. Ceci est un prérequis nécessaire pour continuer en respectant le principe n°4, "reutiliser les briques des standard largement adoptés".
# *-brainstorming. Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data. Yes, this means you will explicitly ''omit'' some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors. See which existing microformats can be reused as building blocks (principle 5, modularity). Use those existing data formats and schemas as a [[existing-classes|source of names]] for the fields (principle 4). Consider how would you embed this microformat in other formats (also principle 5, embeddability). With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat. Make sure the straw proposals encourage the decentralized distribution of data (principle 6). At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
# **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
# **-faq. There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
# **-issues. Folks may also raise issues about the microformat which aren't immediately addressable. An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
# **-implementations. Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.

=== Avancer d'Etape en Etape===

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". How do microformats move from one stage to the other? To help answer this question, it's probably useful to write up a set of desiderata for each stage.

==== Discussions Exploratoires ====

You need a problem, and you need to attempt to state it. You should do it on this wiki using current items under exploratory discussion as a guide. Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats. This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

==== Brouillons ====

Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. [[hcard-profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* A list of implementations (if any).
* An issues section for people to feed back to you with detailed objections.

==== Spécifications ====

You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.

Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections. If none are forthcoming, move the microformat to the specifications area. This move will wake up any sleeping editors, and they may raise an objection and move you back to draft. If you have followed the process, now is the time to pin them down. At this juncture, any remaining issues should be easy to resolve.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-19T10:20:01Z

SebastienSauteur: min

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des
opérateurs. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balisages et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allés faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui ait rencontré le même problème que celui sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itérer ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en des discussions et du feedback, et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

A pattern has emerged from successful microformat development efforts of several specific kinds of wiki pages being created, in a particular order (though not always).

After a specific problem area (*) has been determined (principle 1), consider creating and filling out the following pages for it. If you're unable to come up with material for the pages, then you should probably reconsider whether or not the problem is worth (or ready for) solving.

# *-examples. Find examples on today's web of the the type of content you think needs a microformat. Document them with URLs. Document the implicit schemas that the content examples imply. This is the action that helps follow principle 3, design for humans first, machines second ... adapt to current behaviors and usage patterns.
# *-formats. Find widely adopted interoperable current data formats and standards that attempt to or have attempted to solve the problem previously. Document their explicit schemas. This is necessary prerequisite for following through with principle 4, "reuse building blocks from widely adopted standards".
# *-brainstorming. Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data. Yes, this means you will explicitly ''omit'' some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors. See which existing microformats can be reused as building blocks (principle 5, modularity). Use those existing data formats and schemas as a [[existing-classes|source of names]] for the fields (principle 4). Consider how would you embed this microformat in other formats (also principle 5, embeddability). With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat. Make sure the straw proposals encourage the decentralized distribution of data (principle 6). At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
# **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
# **-faq. There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
# **-issues. Folks may also raise issues about the microformat which aren't immediately addressable. An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
# **-implementations. Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.

=== Avancer d'Etape en Etape===

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". How do microformats move from one stage to the other? To help answer this question, it's probably useful to write up a set of desiderata for each stage.

==== Discussions Exploratoires ====

You need a problem, and you need to attempt to state it. You should do it on this wiki using current items under exploratory discussion as a guide. Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats. This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

==== Brouillons ====

Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. [[hcard-profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* A list of implementations (if any).
* An issues section for people to feed back to you with detailed objections.

==== Spécifications ====

You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.

Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections. If none are forthcoming, move the microformat to the specifications area. This move will wake up any sleeping editors, and they may raise an objection and move you back to draft. If you have followed the process, now is the time to pin them down. At this juncture, any remaining issues should be easy to resolve.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-19T10:17:10Z

SebastienSauteur: /* Itération */ traduction à continuer/relire

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des opérateurs (concernant l'usage des données). Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balises et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il est impossible que vous le fassiez par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allé faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui a rencontré le même problème sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itérer ==
Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de ''feedback'' de la part de ceux qui sont intéressés par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :
<pre>
DIAGRAM:
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V ^___________________V ^______________V
</pre>

Notez que chaque étape implique une processus itératif. Cette itération consiste en des discussions et du feedback, et peut entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs, et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

=== Pages à considérer pour la création ===

A pattern has emerged from successful microformat development efforts of several specific kinds of wiki pages being created, in a particular order (though not always).

After a specific problem area (*) has been determined (principle 1), consider creating and filling out the following pages for it. If you're unable to come up with material for the pages, then you should probably reconsider whether or not the problem is worth (or ready for) solving.

# *-examples. Find examples on today's web of the the type of content you think needs a microformat. Document them with URLs. Document the implicit schemas that the content examples imply. This is the action that helps follow principle 3, design for humans first, machines second ... adapt to current behaviors and usage patterns.
# *-formats. Find widely adopted interoperable current data formats and standards that attempt to or have attempted to solve the problem previously. Document their explicit schemas. This is necessary prerequisite for following through with principle 4, "reuse building blocks from widely adopted standards".
# *-brainstorming. Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data. Yes, this means you will explicitly ''omit'' some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors. See which existing microformats can be reused as building blocks (principle 5, modularity). Use those existing data formats and schemas as a [[existing-classes|source of names]] for the fields (principle 4). Consider how would you embed this microformat in other formats (also principle 5, embeddability). With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat. Make sure the straw proposals encourage the decentralized distribution of data (principle 6). At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
# **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
# **-faq. There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
# **-issues. Folks may also raise issues about the microformat which aren't immediately addressable. An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
# **-implementations. Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.

=== Avancer d'Etape en Etape===

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". How do microformats move from one stage to the other? To help answer this question, it's probably useful to write up a set of desiderata for each stage.

==== Discussions Exploratoires ====

You need a problem, and you need to attempt to state it. You should do it on this wiki using current items under exploratory discussion as a guide. Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats. This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

==== Brouillons ====

Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. [[hcard-profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* A list of implementations (if any).
* An issues section for people to feed back to you with detailed objections.

==== Spécifications ====

You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.

Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections. If none are forthcoming, move the microformat to the specifications area. This move will wake up any sleeping editors, and they may raise an objection and move you back to draft. If you have followed the process, now is the time to pin them down. At this juncture, any remaining issues should be easy to resolve.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-19T10:07:57Z

SebastienSauteur: /* Proposez un Microformat */ relecture + traduction à relire

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des opérateurs (concernant l'usage des données). Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balises et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il est impossible que vous le fassiez par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allé faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui a rencontré le même problème sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par CSS?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : ''les humains d'abord, les machines ensuite''.

== Itération ==
After proposing a microformat, you'll likely get a lot of feedback from others interested in microformats. The proposal needs to be iterated and adapted. Microformat development should be collaborative and community-based.

Here's an ASCII-art flow diagram:
<pre>
DIAGRAM:
problem statement---->research/discussion---->proposal/draft---->standard
^________________V ^___________________V ^______________V
</pre>

Note that each stage involves iteration. That iteration consists of discussion and feedback and may result in major changes. Do not be afraid to make major changes and please don't get too attached to any particular solutions.

=== Pages à considérer pour la création ===

A pattern has emerged from successful microformat development efforts of several specific kinds of wiki pages being created, in a particular order (though not always).

After a specific problem area (*) has been determined (principle 1), consider creating and filling out the following pages for it. If you're unable to come up with material for the pages, then you should probably reconsider whether or not the problem is worth (or ready for) solving.

# *-examples. Find examples on today's web of the the type of content you think needs a microformat. Document them with URLs. Document the implicit schemas that the content examples imply. This is the action that helps follow principle 3, design for humans first, machines second ... adapt to current behaviors and usage patterns.
# *-formats. Find widely adopted interoperable current data formats and standards that attempt to or have attempted to solve the problem previously. Document their explicit schemas. This is necessary prerequisite for following through with principle 4, "reuse building blocks from widely adopted standards".
# *-brainstorming. Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data. Yes, this means you will explicitly ''omit'' some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors. See which existing microformats can be reused as building blocks (principle 5, modularity). Use those existing data formats and schemas as a [[existing-classes|source of names]] for the fields (principle 4). Consider how would you embed this microformat in other formats (also principle 5, embeddability). With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat. Make sure the straw proposals encourage the decentralized distribution of data (principle 6). At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
# **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
# **-faq. There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
# **-issues. Folks may also raise issues about the microformat which aren't immediately addressable. An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
# **-implementations. Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.

=== Avancer d'Etape en Etape===

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". How do microformats move from one stage to the other? To help answer this question, it's probably useful to write up a set of desiderata for each stage.

==== Discussions Exploratoires ====

You need a problem, and you need to attempt to state it. You should do it on this wiki using current items under exploratory discussion as a guide. Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats. This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

==== Brouillons ====

Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. [[hcard-profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* A list of implementations (if any).
* An issues section for people to feed back to you with detailed objections.

==== Spécifications ====

You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.

Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections. If none are forthcoming, move the microformat to the specifications area. This move will wake up any sleeping editors, and they may raise an objection and move you back to draft. If you have followed the process, now is the time to pin them down. At this juncture, any remaining issues should be easy to resolve.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-19T09:47:14Z

SebastienSauteur: /* Documentez le Comportement Actuel */ relecture à relire

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez les Comportements Actuels==
Documentez les comportements actuels des opérateurs (concernant l'usage des données). Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balises et les schémas sous-jacents, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il est impossible que vous le fassiez par vous-même (peu importe combien vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allé faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui a rencontré le même problème sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il un composé d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponse aux deux questions du dessus sont 'non', nous pouvons parler d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des composés XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

D'abord vous devriez observer les [[microformats#the_microformats_principles|les principes des microformats]].

After you understand the principes, ask yourself: "are there any well established, interoperably implemented standards we can look at which address this problem?" For example, hCard and hCalendar were built on top of the IETF standards for vCard and iCal, respectively, both of which are widely interoperably implemented. The developers of those standards had already spent many years in standards committees arguing about and developing the schemas. Better to leverage all the hard work that others have done before you, than to go off as a solo cowboy inventor, and waste time repeating all their mistakes. It's also much easier to start from a well established schema, and map into into XHTML than to develop a new schema.

Remember, microformats should be designed for humans first and machines second. Here are few questions that may help you decide if you really need a microformat for the problem you are trying to solve:

# If I looked at this microformat in a browser that didn't support CSS or had CSS turned off, would it still be human-readable?
# Are this format's elements stylable with CSS?

If the proposed format doesn't pass these two things, it's not likely to gain much acceptance. Remember: ''humans first, machines second''.

== Itération ==
After proposing a microformat, you'll likely get a lot of feedback from others interested in microformats. The proposal needs to be iterated and adapted. Microformat development should be collaborative and community-based.

Here's an ASCII-art flow diagram:
<pre>
DIAGRAM:
problem statement---->research/discussion---->proposal/draft---->standard
^________________V ^___________________V ^______________V
</pre>

Note that each stage involves iteration. That iteration consists of discussion and feedback and may result in major changes. Do not be afraid to make major changes and please don't get too attached to any particular solutions.

=== Pages à considérer pour la création ===

A pattern has emerged from successful microformat development efforts of several specific kinds of wiki pages being created, in a particular order (though not always).

After a specific problem area (*) has been determined (principle 1), consider creating and filling out the following pages for it. If you're unable to come up with material for the pages, then you should probably reconsider whether or not the problem is worth (or ready for) solving.

# *-examples. Find examples on today's web of the the type of content you think needs a microformat. Document them with URLs. Document the implicit schemas that the content examples imply. This is the action that helps follow principle 3, design for humans first, machines second ... adapt to current behaviors and usage patterns.
# *-formats. Find widely adopted interoperable current data formats and standards that attempt to or have attempted to solve the problem previously. Document their explicit schemas. This is necessary prerequisite for following through with principle 4, "reuse building blocks from widely adopted standards".
# *-brainstorming. Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data. Yes, this means you will explicitly ''omit'' some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors. See which existing microformats can be reused as building blocks (principle 5, modularity). Use those existing data formats and schemas as a [[existing-classes|source of names]] for the fields (principle 4). Consider how would you embed this microformat in other formats (also principle 5, embeddability). With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat. Make sure the straw proposals encourage the decentralized distribution of data (principle 6). At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
# **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
# **-faq. There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
# **-issues. Folks may also raise issues about the microformat which aren't immediately addressable. An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
# **-implementations. Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.

=== Avancer d'Etape en Etape===

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". How do microformats move from one stage to the other? To help answer this question, it's probably useful to write up a set of desiderata for each stage.

==== Discussions Exploratoires ====

You need a problem, and you need to attempt to state it. You should do it on this wiki using current items under exploratory discussion as a guide. Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats. This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

==== Brouillons ====

Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. [[hcard-profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* A list of implementations (if any).
* An issues section for people to feed back to you with detailed objections.

==== Spécifications ====

You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.

Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections. If none are forthcoming, move the microformat to the specifications area. This move will wake up any sleeping editors, and they may raise an objection and move you back to draft. If you have followed the process, now is the time to pin them down. At this juncture, any remaining issues should be easy to resolve.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.

process-fr

2006-06-19T09:28:16Z

SebastienSauteur: [min] /* Pourquoi ? */

''Cette page a démarré sur [[process]]''

=Ainsi vous voulez développer un nouveau microformat ?=

__TOC__

==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion '''AVANT''' de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un carnet de brouillon global. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.

==Documentez le Comportement Actuel==
Documentez le comportement humain actuel. Souvenez vous, nous [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons les chemins des vaches]- avant de faire ça, vous devez ''trouver'' les chemins des vaches. Vos [[exemples-fr|exemples]] devraient être une collection de vrais sites du monde et des pages qui sont en train de publier le type de données que vous souhaiter structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de syntaxes et les schémas impliqués dedans, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il n'y a pas moyen que vous puissiez le faire par vous-même (peu importe qui vous êtes). La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont sortis, ont documenté les pratiques actuelles autour des critiques sur les sites web et ont fourni quelques analyses et des schémas tacites.

Il est tout à fait possible durant cette étape que vous puissiez trouver quelqu'un d'autre qui a traité le problème que vous chercher à résoudre. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec les autres qui ont rencontré le même problème. Nous ne voulons pas construire de murs entre les communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

==Proposez un Microformat==
En fait, '''NE LE FAITES PAS !!!'''

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
# Y'a t'il un composé d'éléments XHTML qui fonctionnerait ?
# Ok, si les réponse aux deux questions du dessus sont 'non', nous pouvons parler d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation des éléments XHTML et construire des composés XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].

D'abord vous devriez observer les [[microformats#the_microformats_principles|les principes des microformats]].

After you understand the principes, ask yourself: "are there any well established, interoperably implemented standards we can look at which address this problem?" For example, hCard and hCalendar were built on top of the IETF standards for vCard and iCal, respectively, both of which are widely interoperably implemented. The developers of those standards had already spent many years in standards committees arguing about and developing the schemas. Better to leverage all the hard work that others have done before you, than to go off as a solo cowboy inventor, and waste time repeating all their mistakes. It's also much easier to start from a well established schema, and map into into XHTML than to develop a new schema.

Remember, microformats should be designed for humans first and machines second. Here are few questions that may help you decide if you really need a microformat for the problem you are trying to solve:

# If I looked at this microformat in a browser that didn't support CSS or had CSS turned off, would it still be human-readable?
# Are this format's elements stylable with CSS?

If the proposed format doesn't pass these two things, it's not likely to gain much acceptance. Remember: ''humans first, machines second''.

== Itération ==
After proposing a microformat, you'll likely get a lot of feedback from others interested in microformats. The proposal needs to be iterated and adapted. Microformat development should be collaborative and community-based.

Here's an ASCII-art flow diagram:
<pre>
DIAGRAM:
problem statement---->research/discussion---->proposal/draft---->standard
^________________V ^___________________V ^______________V
</pre>

Note that each stage involves iteration. That iteration consists of discussion and feedback and may result in major changes. Do not be afraid to make major changes and please don't get too attached to any particular solutions.

=== Pages à considérer pour la création ===

A pattern has emerged from successful microformat development efforts of several specific kinds of wiki pages being created, in a particular order (though not always).

After a specific problem area (*) has been determined (principle 1), consider creating and filling out the following pages for it. If you're unable to come up with material for the pages, then you should probably reconsider whether or not the problem is worth (or ready for) solving.

# *-examples. Find examples on today's web of the the type of content you think needs a microformat. Document them with URLs. Document the implicit schemas that the content examples imply. This is the action that helps follow principle 3, design for humans first, machines second ... adapt to current behaviors and usage patterns.
# *-formats. Find widely adopted interoperable current data formats and standards that attempt to or have attempted to solve the problem previously. Document their explicit schemas. This is necessary prerequisite for following through with principle 4, "reuse building blocks from widely adopted standards".
# *-brainstorming. Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data. Yes, this means you will explicitly ''omit'' some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors. See which existing microformats can be reused as building blocks (principle 5, modularity). Use those existing data formats and schemas as a [[existing-classes|source of names]] for the fields (principle 4). Consider how would you embed this microformat in other formats (also principle 5, embeddability). With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat. Make sure the straw proposals encourage the decentralized distribution of data (principle 6). At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
# **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
# **-faq. There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
# **-issues. Folks may also raise issues about the microformat which aren't immediately addressable. An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
# **-implementations. Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.

=== Avancer d'Etape en Etape===

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". How do microformats move from one stage to the other? To help answer this question, it's probably useful to write up a set of desiderata for each stage.

==== Discussions Exploratoires ====

You need a problem, and you need to attempt to state it. You should do it on this wiki using current items under exploratory discussion as a guide. Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats. This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

==== Brouillons ====

Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. [[hcard-profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* A list of implementations (if any).
* An issues section for people to feed back to you with detailed objections.

==== Spécifications ====

You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.

Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections. If none are forthcoming, move the microformat to the specifications area. This move will wake up any sleeping editors, and they may raise an objection and move you back to draft. If you have followed the process, now is the time to pin them down. At this juncture, any remaining issues should be easy to resolve.

== Autres Documents ==

=== Patterns ===

What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?

How do those get created?

The short explanation is this:

The patterns are not formats at all. They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats. The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.