Microformats Wiki - User contributions [en]

rel-payment-fr

2016-03-12T07:46:16Z

ChristopheDucanp: /* Métadonnée Visible */

<entry-title>rel-payment</entry-title>

{{DraftSpecification-fr}}

== Auteurs ==
* [http://solitude.dk Andreas Haugstrup Pedersen]
* [http://joshkinberg.com Joshua Kinberg]
* [http://momentshowing.net Jay Dedman]
* [http://poorbuthappy.com/ease Peter Van Dijk]

(traduction [[User:ChristopheDucamp|Christophe Ducamp]])

== Abstract ==
RelPayment est un microformat pour faire que les échanges de soutien soient possibles (qu'ils soient financiers ou autre). En ajoutant rel="payment" à un hyperlien, une page indique que la destination de cet hyperlien fournit un moyen d'afficher ou de donner un soutien financier à la page en cours. Par exemple, pour offrir un soutien financier au propriétaire de la page en cours.

Un des objectifs de ce microformat est de donner aux agrégateurs de contenus tels que les lecteurs RSS un moyen d'extraire ces liens de soutien et de leur conférer une attention spéciale (comme afficher un bouton standard à côté du contenu).

== RelPayment ==
RelPayment est pensé comme un moyen général de faciliter les dons, et de ce fait cette spécification ne fait aucune hypothèse sur le type de soutien.

Une page peut contenir n'importe quel nombre d'hyperliens marqués avec rel="payment". Ceci permet aux auteurs de donner aux lecteurs plus d'un moyen possible d'afficher le support pour la donation (un lien DropCash, un lien PayPal, un lien pour donner des Twollars, un lien vers une page avec une adresse postale pour envoyer un chèque et ainsi de suite.) Cela permet aussi aux auteurs d'ajouter des liens de paiement qui ne sont seulement en rapport qu'avec une certaine section de page. Par exemple un site web de critique de livre peut avoir plusieurs critiques de livres sur une page avec chaque critique ayant son propre lien Amazon Affilié balisé avec rel="payment". Les agrégateurs devraient implémenter le support pour plusieurs hyperliens de paiement.

Les auteurs devraient utiliser l'attribut "title" pour fournir une description lisible par un humain du type de support pointé par l'hyperlien. Les agrégateurs peuvent utiliser les contenus de l'attribut "title" pour fournir une information supplémentaire au lien de soutien vers leurs utilisateurs. Par exemple <a href="[url]" rel="payment" title="Remerciez moi en Twollars">.

Si l'hyperlien contient une image (par ex. <a href="[url] rel="payment"><img src="[url]" alt="Badge de Soutien" /></a>) les agrégateurs peuvent afficher cette image au lieu du lien standard de l'agrégateur.

== Métadonnée Visible ==
Les liens balisés avec rel="payment" sont sensés être visibles sur la page, et ce parce que l'élément <a> est encouragé sur l'élément <link>. Ceci donne aux lecteurs l'accès le plus facile pour afficher le soutien et cela décourage la fraude de lien. Les auteurs ne devraient pas utiliser des hyperliens vides tels que <a href="[url]" rel="payment" /> et les parseurs peuvent ignorer les liens vides.
Pour sécuriser efficacement les liquidités un [http://www.infosafe.fr/Coffre/CoffresMT/Coffre-fort-ABC.htm coffre fort classe 1E] est souvent requise

== Profil XMDP ==
<source lang=html4strict>
<dl class="profile">
<dt id="rel">rel</dt>
<dd>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value.
<dl>
<dt id="payment">payment</dt>
<dd>Indique que la ressource référencée fournit un moyen de montrer un support pour la page liée.</dd>
</dl>
</dd>
</dl>
</source>
== Application pour ajout de l'enregistrement Atom des relations de liens ==
Ce qui suit est une application pour une valeur de relation de lien, comme spécifiée dans le Format de Syndication Atom. [https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&filename=draft-ietf-atompub-format]

merci -

Joshua Kinberg, jkinberg AT gmail DOT com

Robert Sayre, sayrer AT gmail DOT com

=== Enregistrement ===
http://www.iana.org/assignments/link-relations

=== Valeur d'Attribut ===
"payment"

=== Description ===
rel="payment" indique un URI où le paiement est accepté. Ceci est sensé vouloir dire un moyen général pour faciliter les actes de paiement et de ce fait, cette spécification ne fait aucune hypothèse sur le type de paiement ou protocole de transaction. Les exemples pevuent inclure une page WWW où les donations sont acceptées et les services disponibles pour l'achat. rel="payment" n'est pas conçu pour initier une transaction automatique.

Un élément lien avec un attribut rel="payment" peut exister au niveau fil/canal et/ou au niveau entrée/item. Par exemple un lien rel="payment" au niveau fil/canal peut pointer vers "un petit pot à pourboires", alors qu'une entrée/item contenant une critique de livre peut inclure un lien rel="payment" qui pointe vers l'endroit où le livre peut être acheté chez un détaillant en ligne.

=== Caractéristiques d'Affichage ===
Le logiciel utilisateur final pourrait supporter rel="payment" en affichant un "bouton-paiement" avec le contenu. Alternativement, les agrégateurs de contenus peuvent afficher un hyperlien de paiement contenant le texte spécifié dans un attribut title correspondant dans l'élément <link>, par exemple :

<source lang=html4strict>
<link rel="payment"
href="http://exemple.com/tontine"
title="dites moi merci en twollars" />
</source>
Peut afficher soit un bouton paiement ou un hyperlien contenant le texte, "dites moi merci en twollars".

=== Considérations de Sécurité ===
L'élément lien est sujet au bricolage et à l'observation, comme l'est le lien ressource. Pour cette raison, les implémentations devraient clairement signaler le niveau de confiance et d'intimité qu'un lien ressource fournit. Si présentes, les signatures digitales fournissent de l'authentification, l'intégrité du message et la non-répudiations avec la preuve d'origine. Le cryptage fournit la confidentialité des données. Les implémentations devraient aussi considérer le niveau de confidentialité et l'intégrité du message fourni par le transport utilisé pour toucher la ressource de paiement.

== Art Inital ==
=== Proposition d'Anil Dash, 2002 ===
* http://www.dashes.com/anil/2002/12/10/payment_link_ta

La proposition d'Anil Dash en 2002 est d'utiliser l'élément <link> XHTML pour définir les URLs de paiement :

<blockquote>
LIEN tags de paiement
 
Il y a déjà beaucoup de valeurs possibles définies (si ce n'est pas tout à fait standardisées) pour l'élément LIEN dans le XHTML. Nous les utilisons pour l'Auto-Découverte RSS et bien sûr, déjà pour les feuilles de style. Mais que penser de quelque chose comme :
 
<link rel="appendix" type="text/html" title="payment" href="URL de liste de cadeaux ou la page Paypal" />
 
Un moyen standardisé de lier vers la page où vous payez pour votre soutien d'un site. En appelant la page paiment un "Apppendix" du site que vous visitez est un peu de la manipulation de choses. Peut-être existe-t'il un moyen plus élégant ?
</blockquote>

Bien que cela soit similaire au rel="payment" comme nous le proposons, ce n'est pas aussi flexible parce que cela ne peut être utilisé que pour définir un lieu de paiement unique pour une page entière (probablement une assiette à pourboires ou une page wishlist). Peut-être que rel="payment" pourrait être utilisé dans l'élément link tout comme dans les tags standards d'ancres ?

===Open Financial Exchange===
* http://en.wikipedia.org/wiki/OFX aussi connu sous OFX

==exemples dans la jungle ==
=== Amazon Associates ===
'''Produit avec image'''

Voici le code généré par Amazon pour une citation d'un produit unique avec photo. Tout est généré automatiquement. La forme peut être remplacé par un autre lien régulier html.

<source lang=html4strict>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<body>
<table cellSpacing=0 cellPadding=1 width=120 height=240 bgColor=#000000 border=0>
<tr>
<td>
<table cellSpacing=0 cellPadding=0 width=118 height=238 align=center bgColor=#ffffff border=0>
<tr>
<td>
<table width=100% height=238 border=0 cellSpacing=0 cellPadding=0>
<tr align=center>
<td>
<a href=http://www.amazon.com/exec/obidos/ASIN/B00022AH6I/solitudedk-20?creative=327641&camp=14573&link_code=as1 target=_blank><img src=http://rcm-images.amazon.com/images/P/B00022AH6I.01._SCTZZZZZZZ_.jpg vspace=3 border=0></a>
</td>
</tr>
<tr>
<td vAlign=center height=15%><center>
<a href=http://www.amazon.com/exec/obidos/ASIN/B00022AH6I/solitudedk-20?creative=327641&camp=14573&link_code=as1 target=_blank>Kodak EasyShare DX7440 4MP Digital C...</a>
</td>
</tr>
<tr height=15%>
<td>
<center>
Kodak Digital 
</center>
</td>
</tr>
<tr>
<td height=15%>
<center><a href="http://www.amazon.com/exec/obidos/redirect?tag=solitudedk-20&camp=14573&creative=327641&link_code=am1&path=tg/stores/offering/list/-/B00022AH6I/all/ASIN/B00022AH6I&camp=14573&creative=327641" target=_blank>Best Price $157.70</a></center>
</td>
</tr>
<tr height=15%>
<td>
<center>or Buy New </center>
</td>
</tr>
<tr>
<td height=15%><center>
<table>
<form method="GET" action="http://www.amazon.com/gp/aws/cart/add.html" target="_blank">
<tr>
<td>
<input type="hidden" name="SubscriptionId" value="D68HUNXKLHS4J" />
<input type="hidden" name="AssociateTag" value="solitudedk-20" />
<input type="hidden" name="ASIN.1" value="B00022AH6I" />
<input type="hidden" name="Quantity.1" value="1" />
<input type="hidden" name="linkCode" value="as1" />
<input type="image" name="submit.add" value="Buy from Amazon.com" border="0" alt="Buy from Amazon.com" src="http://rcm-images.amazon.com/images/G/01/buttons/buy-from-tan.gif" />
</center>
</td>
</tr>
</form>
</table>
</center></td>
</tr>
<tr>
<td height=5% align=absbottom>
<center><a href=http://rcm.amazon.com/e/cm/privacy-policy.html?o=1 target=_blank>
Privacy Information</a></center>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
</source>

'''Liens texte'''

Ceci est le code pour un lien texte vers une catégorie de produit. Le lien texte visible est choisi par l'utilisateur.
<source lang=html4strict>
<a href="http://www.amazon.com/exec/obidos/redirect?link_code=ur2&camp=1789&
tag=solitudedk-20&creative=9325&path=tg/browse/-/1">
Get Photography Books at Amazon
</a>
<img src="http://www.assoc-amazon.com/e/ir?t=solitudedk-20&l=ur2&o=1"
width="1" height="1" border="0" alt="" style="border:none !important;
margin:0px !important;" />
</source>

'''Bannières'''

Ce qui suit est le code généré par Amazon pour les bannières génériques. Notez l'utilisation d'imagemap pour créer un "privacy policy link".

<source lang=html4strict>
<html>
<body topmargin=0 leftmargin=0 marginheight=0 marginwidth=0>
<table width=468 height=60 border=0 cellspacing=0 cellpadding=0>
<tr valign=middle align=center>
<td>
<MAP NAME='boxmap'><AREA SHAPE='RECT' COORDS='379, 50, 469, 61'
HREF=http://rcm.amazon.com/e/cm/privacy-policy.html?o=1 target=_top>
<AREA COORDS='0,0,10000,10000' HREF=http://www.amazon.com/exec/obidos/redirect?
tag=solitudedk-20&creative=333489&camp=15553&link_code=ez&path=
/tg/browse/-/171280 target=_top>
</MAP>
<img src=http://rcm-images.amazon.com/images/G/01/
associates/2005/served-banners/us_banner_imag_468x60.gif
width='468' height='60' border='0' usemap='#boxmap'>
</td>
</tr>
</table>
</body>
</html>
</source>

'''Boîtes de Recherche'''

Amazon offre des boîtes de recherche :

<source lang=html4strict>
<form action="http://www.amazon.com/exec/obidos/external-search">
<table class="normal" border="0" cellpadding="0" cellspacing="0">
<tr>
<td style="background-color:#fff;">
<table border="0" cellpadding="0" cellspacing="0" align="top"
height="90" width="120" style="border: 1px solid #000000 !important;">
<tr>
<td style="background-color:#fff;" height="20" valign="bottom" align="center">
Search Now:
</td>
<td style="background-color:#fff;"> </td>
</tr>
<tr>
<td style="background-color:#fff;" align="center" height="30" valign="top">
<input type="text" name="keyword" size="10" value="" />
</td>
<td style="background-color:#fff;" height="20" valign="top" align="left">

<input type="hidden" name="mode" value="blended" />
<input type="hidden" name="tag" value="solitudedk-20" />
<input type="image" border="0" value="Go" name="Submit"
src="http://g-images.amazon.com/images/G/01/associates/build-links/
ap-search-go-btn.gif" alt="[ Go ]" align="absmiddle" />
</td>
</tr>
<tr>
<td colspan="2" style="background-color:#000;" height="40">
<a href="http://www.amazon.com/exec/obidos/redirect-home/solitudedk-20">
<img src="http://g-images.amazon.com/images/G/01/associates/build-links/
searchbox-logo-126x32.gif" height="36" border="0" width="126"
alt="Amazon Logo" /></a></td>
</tr>
</table>
</td>
</tr>
</table>
</form>
</source>

<dl><dt>Commentaires pour l'auteur de l'article : </dt>
<dd>Ceci est un mauvais exemple pour la sémantique, les microformats, le w3c et rel="payment"
<ul><li>Cela utilise des table/td/tr pour le layout</li>
<li>des attributs sans marqueurs de citation (bgColor=120)</li>
<li>lettres capitales dans la syntaxe</li>
<li>des marqueurs dépréciés</li>
<li>l'exemple n'a pas d'attribut rel="payment"</li></dd>
<dl>

=== Exemples Pratiques de rel="payment" ===
* http://www.joshkinberg.com/blog/archives/2005/07/channel_102_int.php

L'entrée de blog contenant l'interview vidéo avec les fondateurs d'un groupe de théâtre. Le lien rel="payment" pointe vers la page d'appel de fonds de la troupe de théâtre où le lecteur est encouragé à donner via Paypal.

* http://www.joshkinberg.com/blog/archives/2005/08/e_e_meet_bullwi.php

L'entrée de blog contenant la vidéo personnelle qui utilise la musique d'un artiste enregistré populaire. Le lien rel="payment" encourage le lecteur à acheter le CD de l'artiste chez Amazon (pourrait avoir utilisé le lien affilié Amazon comme noté au-dessus).

* http://www.joshkinberg.com/blog/archives/2005/08/vlogs_on_npr_sc.php

L'entrée de blog contenant un segment audio provenant d'une interview sur NPR. Le lien rel="payment" encourage le lecteur à supporter NPR en achetant quelque chose sur la boutique en ligne NPR.

* http://tipit.to

Tipit.to est un intermédiaire d'appréciation qui permet aux personnes de placer un petit pot à pourboires sur leurs sites web. Un petit pot à pourboire est une page sur Tipit.to où les visiteurs peuvent donner de l'argent. Le code liant vers le petit pot à pourboire contient rel="payment".

== Outils qui supportent actuellement RelPayment ==

* http://GetFireAnt.com

FireAnt est un agrégateur vidéo RSS et un lecteur de média. Abonnez-vous à n'importe quel canal RSS et téléchargez automatiquement du contenu média frais à regarder et écouter.

* http://blip.tv

blip.tv vous laisse partager et regarder gratuitement la vidéo. Nous hébergerons votre vidéo, la rendrons disponible pour vos amis, votre famille et les lecteurs de blogs, et nous vous aiderons à trouver les vidéos que d'autres ont partagées.

* http://MeFeedia.com

Mefeedia est un agrégateur vidéo, comme Bloglines pour la vidéo. Vous pouvez vous abonner à des canaux et regarder des milliers de vidéos. Ce site ne contient pas ce qui est films, séries ou vidéos produits par des grosses société, mais bien par des milliers de personnes qui créent de la vidéo et la mettent en ligne. Les films produits par de vraies personnes.

* http://rssbazaar.com

* http://49media.com

== Voir aussi ==
* [[rel-faq-fr|rel-faq]]
* [[currency-fr|currency]]

[[Category:Draft Specifications]]
[[Category:rel-payment]]

rel-author-fr

2015-12-06T10:50:44Z

ChristopheDucanp:

''Cette page a démarré sur [[rel-author]]''

<entry-title>rel author</entry-title>
[[User:Tantek|Tantek Çelik]] (Editor) 
(Traduction [[User:ChristopheDucamp|ChristopheDucamp]])

<dfn style="font-style:normal;font-weight:bold">rel-author</dfn> est pour lierr à partir d'un article ou un post (par ex. marqué avec [[hatofr|hAtom]]) vers une page ou un site représentant son auteur. rel-author est l'un des nombreux standard [[microformats-fr|microformat]] ouvert adapté pour embarquer de la data dans le HTML/HTML5, et Atom/RSS/XHTML ou autre XML.

== Résumé ==
rel="author" est pour associer un article ou un post vers une page ou un site représentant son auteur, typiquement pour lui donner du crédit pour son travail (ou des portions celui-ci, comme des livres, articles, billets de blog, etc.)

Par ex. une page ou un billet écrit par "Erin Smith" pourrait contenir un lien comme :
<source lang=html4strict>
<a href="http://erin.exemple.com/" rel="author">Erin Smith</a>
</source>

L'attribut <code>rel="author"</code> indique que la destination du lien représente l'auteur de la page en cours (ou du post).

== Implémentations ==
Cette section est '''informative'''.

=== Google ===
Un ensemble intéressant d'implémentation d'exemples rel="author" est fourni par Google dans une vidéo postée sur Youtube :
* La vidéo [http://www.youtube.com/watch?v=FgFb6Y-UJUI Authorship markup] et la procédure d'implémentation associée pour la sécurité des sauvegardes, un coffre-fort ignifuge http://infosafe.fr

== extensions ==
=== paramètre de requête alternative ===
Google a proposé un mécanisme alternatif pour sépcifier rel=author sur les sites/CMSs qui ne permettent pas aux auteurs de spécifier l'attribut rel, en utilisant un paramètre de requête ajouté à l'URL au lieu de l'exemple ci-dessus avec le paramètre de requête :

<source lang=html4strict>
<a href="http://erin.exemple.com/?rel=author">Erin Smith</a>
</source>

Cette technique est expliquée dans la vidéo qui suit :
* [http://www.youtube.com/watch?v=gG3Oh7Ues8A Authorship markup using URL parameters video] et la [http://www.google.com/support/webmasters/bin/answer.py?answer=1408986 nouvelle procédure d'implémentation] avec l'aide du Profil Google (et nous l'espérons, ce type d'implémentation peut être utilisé sur toute page personnelle de BIO de l'auteur respectif).

==== problèmes param requête ====
<div class="discussion">
* While I understand the motivation here, this is not a good idea. There will definitely be someone who has ?rel= as an actual query param meaning something in their app, and this will just break things. [[User:Singpolyma|Singpolyma]] 17:56, 12 August 2011 (UTC)
* ...
</div>

== articles ==
Articles et posts de blogs concernant rel=author :
* 2013-08-20 http://moz.com/blog/google-plus-correlations

== voir aussi ==
* [[rel-author-issues]]
* [[hatom-fr|hAtom]]
* [[hnews-fr|hNews]]
* [[rel-faq-fr|rel-faq]]
* [[rel-me-fr|rel-me]]
* [[existing-rel-values]] (à synchroniser/traduire avec les [[existing-rel-values-fr|valeurs-rel-existantes]])

[[Category:Draft Specifications]]

rel-author-fr

2015-11-07T10:01:16Z

ChristopheDucanp:

''Cette page a démarré sur [[rel-author]]''

<entry-title>rel author</entry-title>
[[User:Tantek|Tantek Çelik]] (Editor) 
(Traduction [[User:ChristopheDucamp|ChristopheDucamp]])

<dfn style="font-style:normal;font-weight:bold">rel-author</dfn> est pour lierr à partir d'un article ou un post (par ex. marqué avec [[hatofr|hAtom]]) vers une page ou un site représentant son auteur. rel-author est l'un des nombreux standard [[microformats-fr|microformat]] ouvert adapté pour embarquer de la data dans le HTML/HTML5, et Atom/RSS/XHTML ou autre XML.

== Résumé ==
rel="author" est pour associer un article ou un post vers une page ou un site représentant son auteur, typiquement pour lui donner du crédit pour son travail (ou des portions celui-ci, comme des livres, articles, billets de blog, etc.)

Par ex. une page ou un billet écrit par "Erin Smith" pourrait contenir un lien comme :
<source lang=html4strict>
<a href="http://erin.exemple.com/" rel="author">Erin Smith</a>
</source>

L'attribut <code>rel="author"</code> indique que la destination du lien représente l'auteur de la page en cours (ou du post).

== Implémentations ==
Cette section est '''informative'''.

=== Google ===
Un ensemble intéressant d'implémentation d'exemples rel="author" est fourni par Google dans une vidéo postée sur Youtube :
* La vidéo [http://www.youtube.com/watch?v=FgFb6Y-UJUI Authorship markup] et la [http://www.google.com/support/webmasters/bin/answer.py?answer=1229920 procédure d'implémentation] associée pour la sécurité des sauvegardes, un coffre-fort ignifuge http://infosafe.fr

== extensions ==
=== paramètre de requête alternative ===
Google a proposé un mécanisme alternatif pour sépcifier rel=author sur les sites/CMSs qui ne permettent pas aux auteurs de spécifier l'attribut rel, en utilisant un paramètre de requête ajouté à l'URL au lieu de l'exemple ci-dessus avec le paramètre de requête :

<source lang=html4strict>
<a href="http://erin.exemple.com/?rel=author">Erin Smith</a>
</source>

Cette technique est expliquée dans la vidéo qui suit :
* [http://www.youtube.com/watch?v=gG3Oh7Ues8A Authorship markup using URL parameters video] et la [http://www.google.com/support/webmasters/bin/answer.py?answer=1408986 nouvelle procédure d'implémentation] avec l'aide du Profil Google (et nous l'espérons, ce type d'implémentation peut être utilisé sur toute page personnelle de BIO de l'auteur respectif).

==== problèmes param requête ====
<div class="discussion">
* While I understand the motivation here, this is not a good idea. There will definitely be someone who has ?rel= as an actual query param meaning something in their app, and this will just break things. [[User:Singpolyma|Singpolyma]] 17:56, 12 August 2011 (UTC)
* ...
</div>

== articles ==
Articles et posts de blogs concernant rel=author :
* 2013-08-20 http://moz.com/blog/google-plus-correlations

== voir aussi ==
* [[rel-author-issues]]
* [[hatom-fr|hAtom]]
* [[hnews-fr|hNews]]
* [[rel-faq-fr|rel-faq]]
* [[rel-me-fr|rel-me]]
* [[existing-rel-values]] (à synchroniser/traduire avec les [[existing-rel-values-fr|valeurs-rel-existantes]])

[[Category:Draft Specifications]]

process-fr

2015-11-07T09:58:37Z

ChristopheDucanp:

Si c'est votre première visite, regardez SVP la page d'[[introduction-fr|introduction]].

<entry-title>Le processus microformats</entry-title>

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

'''Ou juste un nouveau vocabulaire ?'''

'''Ou créer un nouveau standard fondé sur une recherche empirique et des méthodes scientifiques ?'''

Ce document vous aidera comme guide pour les étapes à franchir pour parvenir à ces fins.

Le processus microformats a été cité comme inspiration pour d'autres groupes de standards et d'efforts tels que WHATWG et ActivityStreams.

;Editeur
:[[User:Tantek|Tantek Çelik]]

;Traduction française
:[[User:ChristopheDucamp|Christophe Ducamp]]

{{TOC-right}}

== tout d'abord ayez quelque expérience ==
Avant même d'imaginer continuer à réfléchir sur un nouveau microformat,
# Faites que votre site soit [[posh-fr|CHIC/POSH]].
# Ajoutez des microformats existants à vos sites comme une [[hcard-fr|hCard]] pour votre information de contact, etc., [[hcalendar-fr|hCalendar]] pour vos événements, [[hatom-fr|hAtom]] pour vos contenus épisodiques (par ex. les blogs). Voir [[get-started-fr|comment démarrer]] pour des exemples plus spécifiques d'ajout de microformats à vos sites.

Ceci aidera à vous familiariser à la façon dont fonctionnent actuellement [[posh-fr|CHIC/POSH]] et [[microformats-fr|microformats]]. Une telle expérience du "vrai monde" vous aidera énormément avec le développement d'un nouveau microformat. Pour en savoir plus à ce sujet, voir [[why-using-existing-microformats-matters-fr|pourquoi-il-est-important-d-utiliser-des-microformats-existants]].

Puis demandez-vous :

==Pourquoi ?==
Il doit y avoir un problème à résoudre (c'est à dire un cas d'utilisation dans le vrai monde). 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.

Peut-être que quelqu'un d'autre suit (ou a suivi) un problème similaire.

Regardez la page [[exploratory-discussion-fr|discussion exploratoire]] et cherchez partout sur le web. Les chances sont que quelqu'un d'autre ailleurs ait rencontré le même problème que vous. Il y a vraiment très peu de nouveaux problèmes complexes.

Si vous croyez encore que vous avez un problème nouveau et non résolu, postez quelque chose sur le canal [[irc-fr|irc]], et si personne n'est là, alors sur la liste de diffusion [http://microformats.org/mailman/listinfo/microformats-new/ microformats-new]. Il est mieux d'impliquer la communauté dans la discussion. Démarrez la discussion '''avant''' de créer de nouvelles pages sur le wiki.

Nous n'utilisons pas le wiki comme un "bloc-notes" général. Si vous ne parvenez 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 concernant 'y'a-t'il un problème plus simple ici ?' et simplifiez jusqu'à ce que vous décriviez votre problème et cas d'usage dans le vrai monde dans un paragraphe court.

==Documentez les Comportements Existants==
Documentez les comportements humains existants. [[why-examples-fr|Exemple du pourquoi d'abord ?]]

[[why-examples-fr|Pourquoi d'abord des exemples ?]] Lisez cela. C'est important et c'est le noyau de ce qui rend les efforts microformats différents de tous les autres/nombreux/précédents efforts de développement.

Nous sommes en train de [http://www.elanceur.org/microformats/traductions/paverlechemindesvaches.html paver les "chemins des vaches"]- avant que vous n'ayez à avoir à "trouver" les chemins des vaches.

Par "chemin des vaches" ici, nous entendons des "exemples de publication du vrai monde". Vos [[examples-fr|exemples]] devraient être un ensemble de sites et pages du vrai monde qui publient le type de donnée que vous souhaitez structurer avec un microformat. A partir de ces pages et ces sites, vous devriez extraire des exemples de marquage et tout spécialement les schémas implicites contenus, et en fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur le wiki microformats parce qu'il est peu probable que vous puissiez la faire vous-même tout seul (peu importe combien vous êtes) et faire que les autres puissent vérifier votre travail aidera à améliorer sa qualité.

La page [[reviews-formats-fr|formats de critiques]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview-fr|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 implicites.

Note : ces exemples concernent le "contenu" (et les schémas "implicites" imbriqués) pas les formats, les noms de classes, les standards pré-existants, etc. Cela vient après.

Etudiez les exemples et déterminez le schéma "implicite" (pas explicite) de donnée qui est en train d'être publié (les propriétés conceptuelles concernant la donnée - pas les noms de classes litérales). Triez ceux-ci par fréquence et déterminez ceux qui apparaissent dans à peu près 80% des cas (selon la règle 80/20, le [[principle-fr|principe]] de Pareto).

Si vous ne pouvez trouver d'exemples du vrai monde pour le type de donnée que vous voulez représenter en utilisant un microformat, alors arrêtez-vous. Il n'a pas besoin d'un microformat.

==Documentez les Efforts Précédents ==
Une fois documentés les exemples de publication du vrai monde des types de données que vous voulez représenter, la prochaine étape est chercher les efforts en développant des formats pour ces types de données.

Il y presque toujours des efforts précédents sur les formats pour n'importe quel type de donnée que vous voulez représenter en utilisant des microformats.

Apprendre à partir des efforts précédents des formats est important, parce que cela aide à :
* minimiser la répétition des erreurs des autres
* explorer pourquoi un précédent format a réussi (ou non)
* fournir une source de vocabulaire pour exprimer un nouvau microformat.

Tout particulièrement, demandez-vous : "existe-t'il des standards établis, interopérables et implémentés que nous pouvons regarder et qui adressent ce problème ?"

Par exemple, hCard et hCalendar ont été construits sur le haut des standards IETF standards pour vCard et iCal, respectivement, les deux étant largement implémentés, et dominants dans leur espace (il n'existait pas de formats concurrents ailleurs avec de tels niveaux d'adoption).

Les développeurs de ces standards ont déjà passé beaucoup d'années dans les comités de standards à discuter, défendre et développer leurs schémas. Mieux de tirer profit de tout le travail que d'autres ont produit avant vous, plutôt que de partir seul comme un cowboy solitaire inventeur et perdre votre temps à répéter toutes leurs erreurs. Il est aussi bien plus facile de démarrer à partir d'un schéma bien établi, et de le cartographier dans un HTML sémantique plutôt que développer un nouveau schéma.

Il est tout à fait possible durant cette étape que vous puissiez trouver quelqu'un d'autre qui se soit confronté au(x) problème(s) que vous résolvez. Peut-être même déjà résolu. Faites de votre mieux pour ouvrir le dialogue avec d'autres qui ont fait face au(x) même(s) problème(s). Nous ne voulons pas construire de murs entre communautés concurrentes - nous voulons des personnes qui travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

Si vous ne pouvez pas trouver d'efforts précédents sur les formats pour les données que vous voulez microformater, demandez sur l'[[irc-fr|IRC]] et sur les [[mailing-lists-fr|listes de discussion]].

==Propositions Brainstorming ==
A ce stade, vous avez recherché des exemples précédents et des formats précédents et vous êtes prêts à écrire les brainstorms pour un nouveau microformat.

En fait, ne le faites pas !!!'''

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

# Y'a t'il un élément standard en HTML qui fonctionnerait ?
# Y'a t'il une combinaison d'élémentsXHTML qui fonctionnerait ?

Si oui, documentez-cela sur la page de brainstorming et arrêtez-vous. Il n'y a pas besoin de microformat.

Ne réinventons pas ce que vous pouvez déjà faire avec HTML.

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://www.elanceur.org/microformats/slides/XHTML-ayant-du-sens.html Les Eléments XHTML ayant du sens].

Autrement, si vous pouvez répondre clairement et franchement "non" aux deux questions du dessus, nous pouvons parler d'un microformat.

Avant que vous ne démarriez votre acte de création, familiarisez-vous avec [[http://microformats.org/wiki/principles-fr|les principes des microformats]].

Il y a fondamentalement deux étapes avant d'écrire une proposition de brainstorming :

# Revenir sur cette liste d'exemples de publication du vrai monde que vous avez cherchés, et assemblez le 80/20 du schéma implicite conceptuel extrait des exemples.
# Donnez à chacun de ces concepts un nom de propriété, en le réutilisant à partir de et dans l'ordre :
## de microformats existants
## de précédents formats
## mots et phrases simples mais spécifiques, en anglais et lisibles par les humains

Bravo, vous avez écrit une proposition de brainstorming avec une liste de nom de classes pour un microformat possible.

Vous pouvez remarquer que vous avez complètement passé le "nommage" du nouveau microformat potentiel en lui-même. Ce n'est pas un accident, c'est délibéré. Nommer est tentant, et un bon nommage est difficile. Par conséquent le nommage est discuté plus tard.

La clé est que le schéma explicite du microformat (quelles propriétés et par conséquent les noms de classes dedans) est "plus important" que le nom.

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

# Si je regardais ce microformat dans un navigateur qui ne supportait pas CSS ou avait CSS désactivé, serait-il encore lisible par un humain ?
# Est-ce que ces élémnets de format sont stylisables avec CSS ?

Si le microformat proposé ne passe pas ces deux choses, il est peu probable qu'il soit accepté. Souvenez-vous : "les humains d'abord, les machines ensuite".

== Itération ==

Maintenant que vous avez une simple proposition de brainstorming, que faites-vous ?

Itérez. Itérez. Itérez.

Dans le processus de développement d'un microformat, vous recueillerez probablement un grand-nombre de réactions de la part d'autres personnes intéressées par les microformats. L'effort devra être "itéré" et adapté. Le développement d'un microformat devrait être ouvert, et de préférence collaboratif et fondé sur une communauté.

Voici un diagramme de flux en ASCII-art :
<pre>
DIAGRAMME :
énoncé du problème---->recherche/discussion---->proposition/"draft"---->spécification
^________________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.

== Considérations de Nommage==
'''NE DEMARREZ PAS'' même par libeller votre effort "hXYZ". C'est une erreur '''vraiment''' courante.

Démarrez toujours par le champ général du problème.

Par conséquent, nommez le champ du problème (*- page en dessous) de façon générique et évitez spécifiquement de démarrer par le nom de code / nom de marque comme hNouveauFormatCool.

Bon : '''[[product-examples]]'''. Mauvais: '''hProduct-examples'''.

Après avoir itéré votre recherche votre recherche et brainstorming, vous avez probablement gagné suffisamment de compréhension de l'espace-problème que vous résolvez pour commercer à envisager les considérations de nommage.

== Pages à créer ==
Un modèle a émergé à partir des efforts réussis de développement de microformats de plusieurs tpes spécifiques de pages wiki ayant été créées, dans un ordre particulier (néanmoins pas toujours).

Par exemple est t'il possible de faire installer une [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoire forte blindée] qui soit également ignifuge

Après que le champ spécifique du problème ('''*''') ait été déterminé (principe 1), considérez de créer et de remplir les pages suivantes, et ajoutez la première à [[exploratory-discussions-fr|discussions-exploratoires]]. Si vous êtes incapable d'en venir à quelque contenu pour les pages, vous devriez considérer de nouveau si oui ou non le problème vaut la peine (ou prêt) d'être résolu.

# '''*-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 implicitement sous-tendus par 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 comportements courants et aux "patterns" d'usage. Commencez par cloner la page d'[[examples-fr|exemples]] et remplissez là.
# '''*-formats''' Trouvez des formats et des standards de données existants interopérables, largement adoptés, qui ont déjà tenté 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, "réutiliser des blocs de construction provenant de standards largement adoptées".

# '''*-brainstorming.''' Utilisez 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) afin de représenter leurs données. Oui, cela signifie que vous allez explicitement ''omettre'' quelques éléments de quelques cas d'utilisation, ou peut-être des cas d'utilisation complets, qui sont plus des cas limites que représentatifs de comportements plus larges, de niveau agrégation/macro. Regardez quels sont les microformats existants pouvant être réutilisés comme blocs de construction (principe n°5, modularité). Utilisez ces formats et schémas de données existants comme une [[existing-classes-fr|source de noms]] pour les champs (principe n°4). Etudiez comment vous embarqueriez ce microformat dans d'autres formats (aussi le principe n°5, "encapsulage"). Voir la page [[brainstorming-fr|brainstorming]] pour un peu plus d'information.
 Avec un schéma 80/20, et une source de noms de champs, écrivez une ou plusieurs propositions de "paille" pour un microformat dans la page *-brainstorming. Assurez-vous que les propositions de "paille" encouragent la distribution décentralisée des données (principe n°6). Repoussez le choix d'un nom de classe racine, car il chevauche souvent le nommage du microformat lui-même. Gardez toujours à portée de main [[naming-principles-fr|les principes de nommage des microformats]] au moment de choisir des noms.
Le Brainstorming sur la substance du microformat (ses propriétés et valeurs) devrait précéder le nommage du microformat lui-même. Par conséquent après que les propositions aient été écrites et discutées pour le schéma, créez une section de nommage pour le microformat lui-même et le nom de classe racine, où différents noms peuvent être envisagés.
# '''**''' Quand il semble qu'il y ait un certain niveau de consensus autour d'une des propositions de "paille" pour un microformat avec un nom spécifique('''**'''), écrivez-la sous la forme d'une spécification "brouillon" sur une page séparée du wiki et puis commencez à créer les pages suivantes pour la suivre.
# '''**-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é aux problématiques 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.
# '''**-exemples''' En fait, il peut y avoir bien trop d'exemples du vrai monde d'un microformat pour le documenter dans une section informative en fin de spécification, de ce fait la liste mérite sa propre page.
# '''**-implémentations''' En fait, 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.
# '''**-brainstorming''' En fait, il y aura des propositions/suggestions/clarifications non triviales pour les modifications dans les microformats faisant partie de l'itération. Créer une page spécifique au format [[brainstorming]] pour de telles suggestions

=== Passer d'une Etape à une 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", "Brouillons" et "Spécifications".

Comment les microformats passent-ils d'une étape à une autre ?

==== 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-new, 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é actuelle des microformats et qui peuvent être confrontées à la même problématique.

Les réactions 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. Toute réaction constructive est saine.

La conséquence de cette réaction pourra être que vous décidiez d'abandonner votre idée de microformat, ou de la modifier substantiellement. Une chose que vous êtes certain de vouloir faire à ce stade, est d'éviter de [[reinvented-wheels-fr|réinventer la roue]].

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 "implémenteurs" auront moins de travail à fournir.

==== 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-new" pour prévenir les gens qu'il y a du nouveau. Continuez à essayer de faire rentrer des réactions à partir de 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é (de préférence le DOMAINE PUBLIC) comme 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-fr|hcard profile]].
* Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Gardez 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.
* Usage de termes [[rfc-2119-fr|rfc-2119]].
* 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". Ceci devrait être relativement aisé si vous avez suivi le processus à ce stade avec la recherche appropriée.
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous remonter leurs 'réactions' 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 "brouillon". 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, envoyez une note sur la liste microformats-new et encouragez la discussion et les objections majeures. Si aucune réponse ne vient, suggérez de migrer le microformat vers la zone "spécifications". S'il y a un support suffisamment explicite de la part de la communauté à faire ainsi, alors allez-y. (Si non, laissez-le alors sous un draft. L'absence de réactions n'est pas une approbation).. Cette migration peut réveiller les éditeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoient au stade "brouillon". Si vous avez suivi le processus, 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 ===
Qu'en est il des autes types de pages sur le wiki, comme les "patterns" (par ex. [[include-pattern-fr|include-pattern]]) ?

Comment ceux-ci sont-ils créés ?

L'explication courte est celle-ci :

Les patterns ne sont pas du tout des formats. Ils ne se tiennent pas de manière autonome. Ce sont simplement de la documentation de morceaux d'autres formats qui sont attendus pour (ou sont) être réutilisés par d'autres formats.

Les exemples dans le vrai monde pour includes en particulier ont été documentés dans le contexte des [[resume-examples-fr|exemples de CV]], [[resume-formats-fr|formats de CV]] et [[resume-brainstorming-fr]] (comme noté tout en haut du [[include-pattern-fr|document]]). Plus tard, les exemples du vrai monde pour des critiques ont été trouvés pour avoir besoin tout aussi bien du "include-pattern".

Quand des exemples du vrai monde pour des microformats "multiples" requièrent la solution d'un problème similaire, alors cela vaut la peine de créer un "pattern" qui résout le problème sur l'ensemble des microformats.

== En rapport ==
* [[process-faq-fr|processus-faq]]
* [[process-issues-fr|processus-problématiques]]
* [[process-brainstorming-fr|processus-brainstorming]]

value-class-pattern-fr

2015-11-07T09:47:07Z

ChristopheDucanp:

<entry-title>Modèle de Classe Value</entry-title>

Le modèle de classe "value" provient de l'[[hcard-fr#Extraction_de_Valeur|extraction de valeur]] dans la hCard.

''Les auteurs pensent que le modèle-de-classe-value est désormais complet et prêt à l'emploi pour le balisage.
Les implémenteurs sont encouragés à mettre leurs sites à jour et fournir un [[value-class-pattern-feedback|feedback]].
'''Remarque''', le comportement précis du parsage pourrait être modifié en réponse aux feedbacks des implémenteurs, mais les méthodes sont stables.
Vous devriez suivre cette page pour les mises à jour.''

Voir aussi, l'[http://microformats.org/blog/2009/05/12/value-class-pattern/ annonce sur le blog] (à traduire).

__TOC__
; Editeurs
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Çelik]]
; URL raccourcie
: <kbd>http://tr.im/ClasseValue</kbd>

; Traduction en cours :
: [[User:ChristopheDucamp|Christophe Ducamp]]

Parfois, seule une partie d'un élément de contenu doit être utilisée comme la valeur d'une propriété d'un microformat.
Ceci peut arriver quand une propriété a des sous-propriétés optionnelles, telles que <code>tel: type</code> et <code>tel: value</code> dans la [[hcard-fr|hCard]].
D'autres fois, la structure la plus appropriée pour une propriété peut inclure d'autre contenu.

A ces fins, le nom spécial de classe <code>value</code> est utilisé pour marquer l'extraction pertinente de la donnée provenant d'un élément de contenu plus grand.

==Exemples Simples==

Voici le marquage pour un numéro de téléphone de domicile :

fragment vCard :

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

fragment hCard :

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

Dans ce cas, la <code>value</code> de <code>tel</code> est <code>+1.415.555.1212</code>, et non pas <code>Home: +1.415.555.1212</code>.

Parfois, la valeur pour une propriété microformats doit être découpée en plusieurs morceaux dans le contenu de l'élément représentant cette propriété.
Plusieurs éléments avec un nom de classe "value" (les éléments value) peuvent être utilisés pour extraire et concaténer ces morceaux en une valeur unique pour les propriétés microformats qui attendent des chaînes simples ou des valeurs tel.

Un autre exemple, cette fois-ci utilisant un numéro de téléphone localisée (France) :

<source lang=html4strict>

Home:
+33 (0) 1 42 31 23 23

</source>

Dans ce cas, la ''data'' valide pour le numéro de téléphone est <samp>+33142312323</samp>, mais la façon dont le numéro de téléphone est présenté en France inclura le <samp>(0)</samp>, pour un appel local.
Ce qui veut dire, qu'à partir de n'importe où dans le monde vous pouvez composer <kbd>+441423123123</kbd>, ou à partir de la France vous pouvez composer <kbd>0142312323</kbd>.
La publication locale communément utilisée interfère avec la donnée, parce que composer <kbd>'''+330'''142312323</kbd> est un numéro invalide.

Dans le marquage, deux classes <code>value</code> ciblent la partie de la chaîne du numéro de téléphone qui produit un numéro international valide, tout en permettant une présentation conventionnelle.

Un autre exemple, ajouter un nom de lieu à des coordonnées [[geo-fr|geo]] :

<source lang=html4strict>
Je flâne dans Montmartre rue Junot

48° 53' 16.3206", 2° 20' 5.9712"
(48.887867;2.3349922)


</source>

Alors que la chaîne complète est un point geo, c'est seulement les coordonnées encodées en décimales qui doivent être consommées par un analyseur de microformats,
ainsi la classe <code>value</code> l'isole de la forme en degrés, que l'auteur a inclus pour plus de complétude.

==Analyse Fondamentale==
# L'exemple de classe value ne s'applique uniquement qu'aux propriétés qui sont de simples chaînes, des valeurs énumérées, des numéros de téléphone et des dates-heures. L'exemple de classe value n'affecte pas l'analyse des propriétés de type email, URL, URI, UID.
# Là où un élément avec un tel nom de propriété de classe microformat a un descendant avec un nom de classe <code>value</code> (un élément "value"), les parseurs devraient utiliser la portion suivante de cet élément :
## si l'élément value est un élément <code>img</code> ou un élément <code>area</code>, utiliser alors la valeur d'attribut du <code>alt</code> de l'élément.
## si l'élément value est un élément <code>abbr</code>, utiliser alors la valeur d'attribut du <code>title</code> de l'élément.
## pour tout autre élément, utiliser son texte à l'intérieur.
# Là où il y a plusieurs descendants d'une propriété avec un nom de classe de <code>value</code> (plusieurs éléments value)
## si la propriété microformats attend une chaîne simple, une valeur énumérée ou un numéro de téléphone, alors les valeurs extraites des éléments value devraient être concaténées ''sans'' insérer de caractères supplémentaires ou d'espace-blanc.
## si la propriété microformats attend une valeur datetime, voir la section [[#Analyse_Date_et-heure|Analyse Date et heure]].
# Les descendants avec la classe <code>value</code> ne doivent pas être analysées plus profondément qu'à un niveau. Ce qui veut dire, là où il y a un élément <code>foo</code> avec la classe <code>value</code>
qui a un descendant <code>bar</code> avec la classe <code>value</code>, le contenu de <code>foo</code> est pris comme la <code>value</code>.
L'imbrication d'éléments supplémentaires avec la classe <code>value</code> ne peut pas être utilisé pour isoler plus en profondeur une value de propriété.

par ex.

<source lang=html4strict>


Puppies Rule!
But kittens are better!


</source>

Dans cet exemple, <code>description</code> a un enfant ‘<code>value</code>’, et cet enfant a une ‘<code>value</code>’ ''petitenfant''.
Néanmoins, l'analyse des classes <code>value</code> s'arrête au premier niveau, ainsi la data pour <code>description</code> est :
<samp><code>Puppies Rule!But kittens are better!</code></samp>, pas simplement <samp>Puppies Rule!</samp>.

== Valeurs Date et heure ==
Quelques propriétés microformats attendent une valeur datetime ISO8601, par ex. [[hcalendar-fr|hCalendar]] <code>dtstart</code> et <code>dtend</code> ou [[hatom-fr|hAtom]] <code>published</code>.

Les auteurs peuvent utiliser le modèle de classe value pour spécifier séparément la date et l'heure, qui sont alors combinés pour spécifier une valeur unique datetime.

Exemple : cette propriété hCalendar 'dtstart' avec des éléments 'value' :

<source lang=html4strict>
La rencontre "afterwork" aura lieu

<abbr class="value" title="2009-05-19">ce Mardi</abbr>
à 19:30


</source>

Produit la valeur 'dtstart' suivante :

et les convertisseurs iCalendar produisent le DTSTART suivant :

<source lang=text>
DTSTART:20090519T193000
</source>

L'absence d'une "timezone" indique une "datetime" "flottante", qui est une date-heure indépendante de tout fuseau horaire particulier. Des exemples de datetimes flottantes pourraient être une alarme de réveil que vous paramétrez pour sonner à 8h00, ou un jour de travail ordinaire comme 9h00-17h00.

=== Analyse Date et heure===
Pour toutes les propriétés date et heure (comme définies dans leurs spécifications respectives microformats), les règles suivantes s'appliquent en plus de celles (et dans certains cas les remplacent) des règles de modèles de parsage de classe value vues au-dessus.

Quand un élément "value" est trouvé, parsez une valeur à partir de l'élément comme suit :
* si l'élément est un élément <code>img</code> ou un élément <code>area</code>, utiliser alors la valeur d'attribut <code>alt</code> de l'élément.
* si l'élément est un élément <code>abbr</code>, utiliser alors la valeur d'attribut <code>title</code> de l'élément.
* pour tout autre élément, utiliser son texte à l'intérieur.
* si la valeur a à la fois une date spécifiée ISO8601 et une heure spécifique, utilisez ceux-ci et arrêtez de chercher des éléments "value".
* si la valeur a *seulement* une date spécifique, spécifiquement, correspondant aux modèles de dates suivants ISO8601 (c.a.d. tels que documentés dans le [http://en.wikipedia.org/wiki/ISO_8601 résumé Wikipedia de ISO8601])
** AAAA-MM-JJ
** AAAA-JJJ
** alors utiliser cela comme la valeur de date. Pour les besoins du modèle de classe value, les tirets "-" séparant les années, mois, jour et/ou jour ordinal sont requis.
** ignorer tous les éléments complémentaires "value" qui spécifient la date.
* si la valeur a *seulement* une heure spécifique (avec ou sans fuseau horaire), parsez la pour une valeur time qui puisse correspondre à tout ce qui suit :
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH sont les "heures" en 24 heures dans le temps, de 00 à 24, avec un 0 optionnel placé devant pour les valeurs inférieures à 10.
** MM sont les minutes de 00 à 59
** SS sont les secondes optionnelles de 00 à 59 (60 pour une seconde). Si omis, inférez 00 secondes.
** XX est le décalage horaire du fuseau, de 00 à 12, avec un 0 en tête optionnel pour les valeurs inférieures à 10
** YY est le décalage en minutes du fuseau horaire, de 00 à 59, même si en pratique ne sont utilisés que des décalages de 00, 15, 30, 45 minutes dans les fuseaux horaires globaux.
** Z est le 'Z' littéral pour indiquer GMT.
** Pour les besoins du modèle de classe value, les deux points ":" séparant heure, minutes et secondes sont requis.
** Néanmoins les deux points ":" séparant les heures et minutes de tout décalage horaire sont "optionnels" et non recommandés afin de faire en sorte qu'une indication de fuseau horaire ne soit pas confondue avec un horaire.
** Un suffixe non sensible à la casse { }"am"|{ }"a.m." pour traiter une valeur HH value de 12 comme 00, ou un suffixe non sensible à la casse { }"pm"|{ }"p.m."pour ajouter 12 à une valeur HH inférieure à 12 - selon [http://en.wikipedia.org/wiki/12-hour_clock l'article de Wikipedia sur l'horloge de 12 heures]. Note : [[X2V]] a implémenté cela.
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** où "am" et "pm" veulent dire "am ou a.m." et "pm or p.m."
*** quand MM est omis, inférer 00 minutes.
** ignorez tous les autres éléments "value" qui spécifient l'heure.
* si la valeur a *seulement* une date-heure spécifique, ou une valeur de zone horaire qui corresponde à n'importe quelle valeur suivante :
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX est le décalage en heures du fuseau horaire, de 00 à 12 avec un 0 optionnel en avant pour les valeurs inférieures à 10.
** YY est le décalage en minutes de la zone horaire, de 00 à 59, bien qu'en pratique seuls les décalages de 00, 15, 30, 45 minutes soient utilisés dans les zones horaires globales.
** Z est le 'Z' littéral pour indiquer GMT.
** ignorez tous les autres éléments "value" qui spécifient la timezone.

Si en parsant les éléments "value", au moins une date spécifique est trouvée, alors la "value" est par dessus-tout valide, et le parseur assemble la valeur datetime en concaténant la date spécifique, "T" et l'horaire spécifique (si l'heure a été spécifiée, avec 00 secondes implicite si aucune seconde n'est fournie), et une timezone spécifique (si la timezone et l'horaire spécifique ont été spécifiés).
* AAAA-MM-JJ - aucun horaire spécifié
* AAAA-MM-JJTHH:MM:SS - heure spécifiée mais pas de timezone. C'est une heure flottante.
* AAAA-MM-JJTHH:MM:SS-XXYY ou
* AAAA-MM-JJTHH:MM:SSZ ou
* AAAA-MM-JJTHH:MM:SS+XXYY - à la fois l'heure et la timezone ont été spécifiées

=== détails spécifiques des formats ===
Ce qui suit sont des détails spécifiques de format et des optimisations qui font usage du modèle-classe-value.

;URL raccourci pour cette section 
:http://tr.im/vcpfso (à localiser)

==== hCalendar date dtend implicite ====
Généralement, les événements qui démarrent et finissent le même jour n'affichent seulement la date de l'événement qu'une fois (cela fait sens selon le [[principles-fr|principe]]) DRY (exemples du vrai monde : [http://upcoming.yahoo.com/event/3010807/ Upcoming], ... plus d'exemples avec des URLs aiderait pour être minutieux).

Par conséquent ce serait pratique si nous pouvions sous-tendre une date dtend d'événement [[hcalendar-fr|hCalendar]] à partir de sa date "dtstart" si et seulement si l'horaire (et en option la timezone) était spécifiée pour son "dtend", par ex. :

<source lang=html4strict>

La soirée aura lieu le

2009-06-26, à partir de
19:00 jusqu'à
22:00.

</source>

Pour simplifier cela aux auteurs, les processeurs hCalendar pourraient traiter la spécification juste avec l'heure selon les règles de valeur du modèle de classe value, et de ce fait éliminer le besoin d'un span "value" dans le span "dtend" :

<source lang=html4strict>

La soirée aura lieu le

2009-06-26, à partir de
19:00 jusqu'à
22:00.

</source>

Le convertisseurs hCalendar vers iCalendar devraient produire le fragment iCalendard suivant (en tant que partie d'un fichier .ics) provenant de l'un ou l'autre des deux exemples au-dessus :

<source lang=text>
BEGIN:VEVENT
SUMMARY:party
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

Note : [[X2V-fr|X2V]] a implémenté la date dtend implicite à partir de dtstart.

Exemples "dans jungle":
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop (exemple du vrai monde, mais sur ce wiki).

==== générateurs iCalendar ====
les implémentations microformats qui consomment [[hcalendar-fr|hCalendar]] et génèrent iCalendar doivent en outre :
# retirer tous les tirets "-" de séparation dans la date.
# retirer tous séparateurs deux points ":" dans l'horaire.
# ajouter un jour complet à toutes les valeurs de propriété <code>dtend</code> hCalendar (manquant d'un horaire spécifié) (inclusion date) afin de générer une valeur de propriété<code>DTEND</code> iCalendar (date excluse) avec le même sens, selon la résolution de la [[dtend-issue-fr|problématique-dtend]].
# exécuter une formule mathématique +/- datetime sur toute valeur timezone , et produire une valeur effective UTC finissant par "Z".

==== hAtom date updated implicite ====
De la même façon, dans les billets de blog qui indiquent à la fois quand ils sont "publiés" et "mis à jour", la date n'est généralement affichée qu'une fois, généralement "publiée" (les exemples du vrai monde aideraient pour plus de minutie).

Par conséquent, ce serait pratique si nous pouvions sous-tendre une date d'entrée "updated" [[hatom-fr|hAtom]] à partir de sa date "published" si et seulement si l'horaire (et en option la timezone) était spécifiée pour son "updated", par ex. pour un billet de blog qui est mis à jour le même jour :

<source lang=html4strict>

exemple de petit billet de blog
publié le 
2009-08-01 à 12:06
et mis à jour à 12:10.

</source>

Pour simplifier cela aux auteurs, les processeurs hAtom pourraient traiter la spécification horaire selon les règles de valeurs des date et time du modèle de classe value, et par conséquent éliminer le besoin d'un span "value" dans le span "updated"

<source lang=html4strict>

exemple de petit billet de blog
publié le 
2009-08-01 à 12:06
et mis à jour à 12:10.

</source>

==== générateurs Atom ====
les implémentations microformats qui consomment [[hatom-fr|hAtom]] et génèrent Atom DOIVENT en outre :
* normaliser toutes les valeurs date et datetime à la [[RFC3339-fr|RFC3339]].

=== dérivation et tests ===
Cette section est informative.

La gestion des valeurs date et heure dans le modèle de classe value a été intialement [[value-excerption-pattern-brainstorming#date_and_time_separation|brainstormée sur la page the value-excerption-pattern-brainstorming]] et dérivée de cette analyse et des feedbacks. Pour les curieux, les détails historiques peuvent être trouvés ici, avec quelques idées supplémentaires pour extension.

Voir [[value-class-date-time-tests]] pour les tests de cas.

==Parsage de valeur à partir d'un attribut <code>title</code> ==
Le nom de classe <code>value-title</code> permet au diffuseur d'indiquer la valeur de donnée pour une propriété parente contenue dans l'attribut <code>title</code> d'un élément, plutôt que dans le texte à l'intérieur.

Ceci peut être utilisé pour fournir un synonyme dans le contenu, ou utilisé pour publier tranquillement des formes alternatives d'inforamtion pour un parsage microformats, sans affecter la consommation de contenu. Poua la sécurisation des archives papier, l'utilisation d'un coffre-fort ignifuge data pour les sauvegardes voir http://www.infosafe.fr ou d'une armoire fortes ignifuges pour les registres est requise par les normes ISO.

Par exemple, vous pouvez utiliser une localisation avec des dates :

<source lang=html4strict>
C'était

l'année dernière

que je commençais à réaliser que mon addiction à la crème de marron coûterait si cher à ce pays.

</source>

Les règles de parsage pour <code>value-title</code> sont les mêmes que pour <code>value</code> above, avec le changement suivant :

* Là où une propriété microformats a un élément enfant avec le nom de classe <code>value-title</code>, le contenu de l'attribut <code>title</code> de cet élément doit être parsé, plutôt que la portion de l'élément qui devrait être parsée pour un nom de classe de <code>value</code>.

===Utilisation de <code>value-title</code> pour publier des données-machines===

L'usage initial de <code>value-title</code> est utilisé pour publier des formes alternatives, parsables de valeurs de propriétés dans un contexte visible sans l'utilisation de l'élément <code>abbr</code> dont la sémantique supporte déjà l'interprétation de l'attribut "title' comme une forme plus étendue, plus précise du contenu.

L'expérience a montré qu'il y a des cas dans les microformats où un certain nombre d'auteurs veulent inclure une valeur précise et parsable pour une propriété mais ne veulent pas qu'elle soit visible sur leurs pages, même sous forme d'info-bulle.

Par exemple, les datetimes complètes [[ISO8601-fr|ISO8601]] peuvent prêter à confusion pour les lecteurs de la page (comme une infobulle ou au moment d'être lues à voix haute par un lecteur-écran), et les valeurs énumérées telles que la sous-propriété <code>type</code> de la propriété <code>tel</code> de hCard utilise des termes US-anglais, qui ne font pas partie des pages dans toute autre langue.

Parce que ces deux scénarios se sont avérés être des obstacles pour un certain nombre de diffuseurs, dans ces cas, et ces cas seulement, il existe une extension approfondie de l'extraction de value. Cette extension permet aussi la forme parsable de la propriété à publier 'en silence' immédiatement adjacente au contenu respectif visible en local.

Voici un exemple, avec l'usage obligatoire d'un premier élément enfant avec le nom de classe <code>value-title</code>:

<source lang=html4strict>


 
mobile

+33 7773 000 000

</source>

La valeur <samp>cell</samp> est parsée pour la sous-propriété 'type', mais <samp>mobile</samp> est présenté à l'utilisateur.

Dans le cas de dates :

<source lang=html4strict>

 
14 mars 2009, vers quatre heures et demi

</source>

Un parseur microformats lira le format datehoraire ISO8601 <samp>2009-03-14T16:28-0600</samp>, mais les utilisateurs ne verront que <samp>14 mars 2009, vers quatre heures et demi</samp>. Les tests ont montré que le date-heure ISO8601 du dessus n'est exposé en aucun cas à l'utilisateur.

==Parser une valeur provenant d'un attribut <code>title</code> ==
Le nom de classe <code>value-title</code> permet à l'auteur d'indiquer la donnée value pour une propriété parent contenue dans l'attribut <code>title</code> d'un élément, plutôt que dans le texte à l'intérieur.

Ceci peut s'utiliser pour fournir un synonyme dans le contenu, ou utilisé pour publier tranquillement des formes alternatives d'information pour le parsage de microformats, sans impacter sur la consommation du contenu.

Par exemple, vous pouvez utiliser des localisations ponctuelles avec des dates :
<source lang=html4strict>
Ce fût

l'année dernière

que je pris conscience que mon addiction au tabac pourrait coûter très cher à la Sécurité Sociale.

</source>

Les règles de parsage pour <code>value-title</code> sont les mêmes que celles pour <code>value</code> au-dessus, avec le changement qui suit :

* Là où une propriété microformats a un élément enfant avec le nom de classe de <code>value-title</code>, le contenu de l'attribut <code>title</code> de cet élément doit être parsé, plutôt que la portion de l'élément qui devrait être parsé pour un nom de classe de <code>value</code>.

===Utiliser <code>value-title</code> pour publier des données-machines===

L'usage initial de <code>value-title</code> est utilisé pour publier des formes alternatives, parsables des valeurs de propriétés dans un contexte visible sans l'utilisation de l'élément <code>abbr</code> dont la sémantique supporte déjà l'interprétation de l'attribut 'title' comme une forme plus étendue, plus précise du contenu.

L'expérience a montré qu'il existe quelques cas dans les microformats où un certain nombre d'auteurs veulent inclure une valeur précise et parsable pour une propriété mais ne veulent pas qu'elle soit visible dans leurs pages, ni même sous forme de petite bulle.

Par exemple le datetimes complet [[ISO-8601-fr|ISO-8601]] peut être confus pour les lecteurs de la page (que ce soit sous forme de bulle ou quand c'est lu par un lecteur écran), et les valeurs énumérées telles que la sous-propriété <code>type</code> de la propriété <code>tel</code> de la hCard utilise des termes US-English, qui ne font pas partie de pages dans toute autre langue.

Le fait que ces scénarios se sont avérés être des obstacles pour un bon nombre d'auteurs, pour ces cas, et ceux-ci seulement, il existe une extension approfondie de l'extraction de valeur. Cette extension permet une forme parsable de la propriété pour être publiée 'en silence' et immédiatement adjacente avec le contenu visible local y afférent.

Voici un exemple, avec l'usage requis d'un premier élément enfant avec le nom de classe <code>value-title</code> :

<source lang=html4strict>


 
mobile

+33 647 730 000

</source>

La valeur <samp>cell</samp> est parsée pour la sous-propriété 'type', mais <samp>mobile</samp> est présenté à l'utilisateur.

Dans le cas de dates :

<source lang=html4strict>

 
le 12 juin 2009, aux alentours de 9h30

</source>

Un analyseur de microformats lira le format datetime ISO8601 <samp>2009-06-12T09:28-0600</samp>, mais les utilisateurs ne verront que <samp>le 12 juin 2009, aux alentours de 9h30</samp>.
Le test a montré que la datetime ISO8601 au-dessus n'est pas du tout présentée à quelque utilisateur.

===Parsage donnée-machine <code>value-title</code>===

Les navigateurs échouent sur le <code>value-title</code> réduit à une largeur de span égale à <code>0</code>, en ne fournissant en fait aucun rendu visuel, tout en conservant l'élément dans le DOM. Sans dimensions physiques, il n'y a pas d'état 'hover', ainsi aucune infobulle n'est révélée. En outre, l'élément vide n'est pas passé aux couches de technologie assistives telles que VoiceOver. Les lecteurs écrans ne lisent pas les contenus de l'attribut title d'un élément vide <code>span</code>.

Nous avons mené des [[value-excerption-value-title-test|tests approfondis]] de ces comportements de parsage pour assurer l'accessibilité.

''Note : Bien que l'élément <code>value-title</code> soit plus élégant à écrire sans texte à l'intérieur avec espace blanc (ou comme un élément <code><foo /></code> auto-fermé en XHTML), les outils actuels tels que les éditeurs WYSIWYG et HTML-Tidy se débarasseront par erreur de tels éléments, aboutissant à une donné parsable se faisant rejeter par quelques outils. Aussi, <code> </code>, comprenant un caractère unique espace-blanc entre la balise d'ouverture et de fermeture, est à cette heure le modèle requis pour les auteurs.''

Parser cette extension finale <code>value-title</code> impose quelques restrictions plus strictes sur l'usage. Ces restrictions existent pour réduire l'impact des violations de <abbr title="Don't Repeat Yourself">DRY</abbr>, pour réduire l'opportunité des sites à absorber les données, et pour encourager la bonne pratique de maintenir convenabelement ces deux formes de données.

Là où un élément avec la classe <code>value-title</code> doit être parsé comme donnée pour une propriété, et que cet élément ne contienne aussi aucun contenu sans-espace-blanc (ici considéré en référence comme 'vide'), les règles suivantes s'appliquent :

* L'élément ‘vide’ value-title doit être le '''premier enfant sans espace-blanc''' de l'élément propriété. Ce qui veut dire qu'il devrait suivre imméidatement après la propriété déclarée, avant la forme lisibile-par-les-humains, et sans aucune autre imbrication supplémentaire.
* L'élément 'vide' value-title ne peut seulement être utilisé que pour des propriétés spécifiques. Les spécifications des microformats doivent explicitement déclarer quelles propriétés peuvent être utilisées avec cette extension du modèle-classe-value.
* Là où un élément 'vide' value-title doit être utilisé comme propriété unique de value, il doit être le ''seul'' comme contenu <code>value</code>. Ce qui veut dire, la première instance d'un élément conforme <code>value-title</code> surpasse toutes les autres <code>value</code> et <code>value-title</code> soeurs et/ou cousines.
* Les outils écrits pour passer les Tests de Conformité et/ou Validation de Microformats ''devraient'' essayer de comparer les formes données-machines et visible-par-les humains des données de propriété, et conseiller les auteurs si les formes ne concordent pas.

=== Utilisation limitée de value-title ===
Du fait que le modèle value-title cache quelque quantité de donnée qui tend à être un duplicata spécifique-machine de donnée fournie dans le contenu lisibile par les humains, il y a deux [[principles-fr|principes]] microformats qui doivent être compromis : '''visibilité''' et '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Par conséquent, l'applicabilité de ce modèle est délibérément restreinte aux propriétés qui ont démontré à travers l'expérience un besoin de ce modèle, sans aucune autre alternative meilleure connnue.

En général, les auteurs devraient :

# Tout d'abord, essayer de spécifier directement les valeurs de propriété microformats dans la ligne (le plus visible, pas de duplication),
# Puis considérer d'utiliser le modèle de classe value
## Comprenant plusieurs éléments de 'value' pour les propriétés date et time
# et puis seulement si ces méthodes sont insuffisantes, considérer le modèle value-title.

Ce document post-date toutes les autres spécifications microformats, parce qu'elles peuvent ne pas indiquer à cette heure quelles propriétés permettent l'usage de ce modèle. Dans l'intervalle, '''seuls''' les types de propriétés suivantes devraient autoriser le modèle value-title.

* valeurs date, datetime, timezone et duration ISO8601
* Valeurs énumérées (tlles que les sous-propriétés 'type' tel/email/adr de la hCard)
* Les coordonnées (comme les propriétés 'latitude' et 'longitude' de [[geo-fr|geo]])
* Les propriétés des numéros de téléphone (par ex. la propriété 'tel' de la hCard)

La page [[machine-data]] a de la documentation sur quelques-unes des propriétés de quelques spécifications pour lesquelles l'expérience a montré le besoin de solution comme le modèle value-title.

Il existe quelques exemples simples de références et tests pour ce modèle sur [[value-class-pattern-tests]].

Pour un futur usage, les ''auteurs de spécification'' peuvent hériter de l'usage de <code>value-title</code> par l'utilisation des formats de date et heures ISO8601, ou réutilisation d'autres microformats, mais les spécifications devraient éviter d'introduire de nouvelles structures de données qui dépendent ou encouragent ce modèle. Les nouvelles spécifications sont elles-mêmes attendues pour adhérer aux principes fondateurs de donnée visible et <abbr>DRY</abbr>.

== Cas de Test ==
Voir [[value-class-pattern-tests]].

== <abbr title='Foire aux Questions'>FAQ</abbr>==
Cette section est '''informative'''.

Les questions souvent posées sur le modèle-classe-value. Une fois que cette section sera trop grosse, nous la migrerons sur une page wiki séparée (comme [[value-class-faq-fr]]).

<div class='discussion'>
* '''Pourquoi utiliser un élément 'vide' ? Pourquoi ne pas embarquer la donnée dans l'attribut de classe ?'''
** L'attribut de classe est inapproprié pour les valeurs de données embarquées, selon la spécification HTML4, qui établit que <code>class</code> est pour le ‘general purposing processing’, qui est défini comme ‘par ex. pour identifier des champs au moment d'extrire la donnée des pages provenant du HTML dans une base de données, traduire des documents HTML dans d'autres formats, etc.'. ‘General purpose processing’ ne s'étend pas à la donnée elle-même. En outre, cette méthode évite d'inventer une nouveau modèle de chaîne pour embarquer de la donnée.
* '''Pourquoi utiliser un élément 'empty' ? Pourquoi ne pas produire un nouvel attribut, comme 'data' ?'''
** Les microformats existent et fonctionnent en HTML4 et XHTML1 valide. Ceux-ci sont les standards actuels pour le développement web, et les microformats existent pour une utilisation ''maintenant''. A l'avenir, peut-être que les futures révisions du HTML offriront une autre solution. A cette heure, cette méthode a été testé dans les navigateurs, et crée une structure de document cohérente (où les données formats-machines et lisibles-par-les-humains sont soeurs).
* '''L'attribut <code>title</code> ne devrait être utilisé que pour du contenu !'''
** L'attribut <code>title</code> _est_ utilisé pour le contenu et se fait lire par les parseurs de microformats. Ceci existe pour les cas où la donnée ne peut pas être parsée avec suffisamment de précision provenant de ce que est communément publié, l'information visible. Ce modèle permet d'inclure les deux formes de contenu, tout en le maintenant invisible pour les consommateurs humains.
</div>

Vous pouvez aussi vous référer aux [[faq-fr|FAQ Microformats]] générales et aux [[principles-fr|principes]].

== Exemples dans la jungle ==
Cette section est '''informative'''.

Les sites et pages suivants ont démarré par baliser le contenu avec le modèle de classe-value, et ce sont par conséquent de bons endroits pour aller voir des exemples de contenu du vrai monde pour tester les implémentations (par ex. les parseurs). Si vous utiliser le modèle-classe-value dans votre contenu, sentez-vous libre de l'ajouter '''en haut''' de cette liste. Une fois que la liste sera trop grosse, nous produirons une page wiki séparée (comme [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] Cette page utilise toute une gamme de différents patterns pour à la fois hCard et hCalendar, en utilisant à la fois value et value-title, la plupart dérivée de l'application ci-dessus.
* Le [http://georgebrock.com/ flux d'activité de George Brocklehurst] et son [http://blog.georgebrock.com/ blog] utilisent "value-title" pour la propriété <code>published</code> de hAtom
* [http://ben-ward.co.uk/ La page personnelle de Ben Ward] utilise :
** "value-title" pour la propriété <code>bday</code> de hCard
** "value-title" pour la propriété <code>updated</code> de hAtom
* [http://microformats.org/ microformats.org] utilise :
** "value-title" pour la propriété <code>updated</code> de hAtom dans [[http://microformats.org/ microformats.org les billets du blog]]]
** séparation des values date et time pour la propriété <code>dtstart</code> de hCalendar dans [[events|la page wiki microformats.org des événements récents et à venir]]

''Ajoutez vos site/page(s) qui utilisent le modèle-classe-value ici, avec une brève description des fonctionnalités du modèle-classe-value que vous utilisez, avec quel(s) microformat(s) et quelle(s) propriétés.''

== Implémentations ==

Cette section est '''informative'''.

Les implémentations suivantes ont été développées pour soit générér ou parser les valeurs de propriété du modèle-classe-value. Si vous avez une implémentation du modèle-classe-value, sentez-vous libre de l'ajouter en '''haut''' de cette liste. Une fois que la liste sera trop grosse, nous produirons une page wiki séparée (comme [[value-class-implementations]]).

* [[Oomph]] Version 2 passe [[value-class-pattern-tests#Date_and_time_values|les tests des valeurs de date et heure]] et c'est une implémentation minutieuse du value-class-pattern.
* [[X2V]] v0.9.3 et suivantes :
** implemente [[#Date_and_time_values|Date and time values parsing]], y compris les valeurs horaires am/pm
*** passe par conséquent [[value-class-pattern-tests#Date_and_time_values|les tests de cas des valeurs de Date et heure]].
** implémente [[#hCalendar_date_implicite_dtend|hCalendar date dtend implicite]]
* [[Operator-fr|Operator]] a *quelque* implémentation du modèle-classe-value selon Michael Kaply, mais plus précisément savoir à quel degré c'est implémenté, pour quelles propriétés (types de propriétés) et quels microformats n'est actuellement pas connu.
* [[Optimus]] v0.8 et suivante implémente <code>value-title</code> comme [http://twitter.com/DmitryBaranovsk/status/1891253248 annoncé par Dmitry Baranovskiy].
* ... ajoutez vos implémentations qui parsent ou génèrent le modèle-classe-calue ici, avec les fonctionnalités que vous supportez (nous l'espérons toutes !) et notez toutes les limites s'il y en a.

== Articles ==
Les articles et billets de blog discutant du value class pattern, les plus récents en premier.
Quand cette section deviendra trop grosse, créez une page séparée comme ceci : [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] par Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- Un écrit très minutieux d'Emily Lewis sur le value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

==Pages en Rapport==
Cette section est '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard-fr#Extraction_de_Valeur|hCard : Extraction de Valeur]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data-fr|Machine Data in Microformats]]

== Références ==
Cette section est '''informative'''.
* [http://www.useit.com/alertbox/9608.html Jakob Nielsen: International Web Usability]

value-class-pattern-fr

2015-09-29T06:56:05Z

ChristopheDucanp:

<entry-title>Modèle de Classe Value</entry-title>

Le modèle de classe "value" provient de l'[[hcard-fr#Extraction_de_Valeur|extraction de valeur]] dans la hCard.

''Les auteurs pensent que le modèle-de-classe-value est désormais complet et prêt à l'emploi pour le balisage.
Les implémenteurs sont encouragés à mettre leurs sites à jour et fournir un [[value-class-pattern-feedback|feedback]].
'''Remarque''', le comportement précis du parsage pourrait être modifié en réponse aux feedbacks des implémenteurs, mais les méthodes sont stables.
Vous devriez suivre cette page pour les mises à jour.''

Voir aussi, l'[http://microformats.org/blog/2009/05/12/value-class-pattern/ annonce sur le blog] (à traduire).

__TOC__
; Editeurs

; URL raccourcie
: <kbd>http://tr.im/ClasseValue</kbd>

; Traduction en cours :
: [[User:ChristopheDucamp|Christophe Ducamp]]

Parfois, seule une partie d'un élément de contenu doit être utilisée comme la valeur d'une propriété d'un microformat.
Ceci peut arriver quand une propriété a des sous-propriétés optionnelles, telles que <code>tel: type</code> et <code>tel: value</code> dans la [[hcard-fr|hCard]].
D'autres fois, la structure la plus appropriée pour une propriété peut inclure d'autre contenu.

A ces fins, le nom spécial de classe <code>value</code> est utilisé pour marquer l'extraction pertinente de la donnée provenant d'un élément de contenu plus grand.

==Exemples Simples==

Voici le marquage pour un numéro de téléphone de domicile :

fragment vCard :

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

fragment hCard :

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

Dans ce cas, la <code>value</code> de <code>tel</code> est <code>+1.415.555.1212</code>, et non pas <code>Home: +1.415.555.1212</code>.

Parfois, la valeur pour une propriété microformats doit être découpée en plusieurs morceaux dans le contenu de l'élément représentant cette propriété.
Plusieurs éléments avec un nom de classe "value" (les éléments value) peuvent être utilisés pour extraire et concaténer ces morceaux en une valeur unique pour les propriétés microformats qui attendent des chaînes simples ou des valeurs tel.

Un autre exemple, cette fois-ci utilisant un numéro de téléphone localisée (France) :

<source lang=html4strict>

Home:
+33 (0) 1 42 31 23 23

</source>

Dans ce cas, la ''data'' valide pour le numéro de téléphone est <samp>+33142312323</samp>, mais la façon dont le numéro de téléphone est présenté en France inclura le <samp>(0)</samp>, pour un appel local.
Ce qui veut dire, qu'à partir de n'importe où dans le monde vous pouvez composer <kbd>+441423123123</kbd>, ou à partir de la France vous pouvez composer <kbd>0142312323</kbd>.
La publication locale communément utilisée interfère avec la donnée, parce que composer <kbd>'''+330'''142312323</kbd> est un numéro invalide.

Dans le marquage, deux classes <code>value</code> ciblent la partie de la chaîne du numéro de téléphone qui produit un numéro international valide, tout en permettant une présentation conventionnelle.

Un autre exemple, ajouter un nom de lieu à des coordonnées [[geo-fr|geo]] :

<source lang=html4strict>
Je flâne dans Montmartre rue Junot

48° 53' 16.3206", 2° 20' 5.9712"
(48.887867;2.3349922)


</source>

Alors que la chaîne complète est un point geo, c'est seulement les coordonnées encodées en décimales qui doivent être consommées par un analyseur de microformats,
ainsi la classe <code>value</code> l'isole de la forme en degrés, que l'auteur a inclus pour plus de complétude.

==Analyse Fondamentale==
# L'exemple de classe value ne s'applique uniquement qu'aux propriétés qui sont de simples chaînes, des valeurs énumérées, des numéros de téléphone et des dates-heures. L'exemple de classe value n'affecte pas l'analyse des propriétés de type email, URL, URI, UID.
# Là où un élément avec un tel nom de propriété de classe microformat a un descendant avec un nom de classe <code>value</code> (un élément "value"), les parseurs devraient utiliser la portion suivante de cet élément :
## si l'élément value est un élément <code>img</code> ou un élément <code>area</code>, utiliser alors la valeur d'attribut du <code>alt</code> de l'élément.
## si l'élément value est un élément <code>abbr</code>, utiliser alors la valeur d'attribut du <code>title</code> de l'élément.
## pour tout autre élément, utiliser son texte à l'intérieur.
# Là où il y a plusieurs descendants d'une propriété avec un nom de classe de <code>value</code> (plusieurs éléments value)
## si la propriété microformats attend une chaîne simple, une valeur énumérée ou un numéro de téléphone, alors les valeurs extraites des éléments value devraient être concaténées ''sans'' insérer de caractères supplémentaires ou d'espace-blanc.
## si la propriété microformats attend une valeur datetime, voir la section [[#Analyse_Date_et-heure|Analyse Date et heure]].
# Les descendants avec la classe <code>value</code> ne doivent pas être analysées plus profondément qu'à un niveau. Ce qui veut dire, là où il y a un élément <code>foo</code> avec la classe <code>value</code>
qui a un descendant <code>bar</code> avec la classe <code>value</code>, le contenu de <code>foo</code> est pris comme la <code>value</code>.
L'imbrication d'éléments supplémentaires avec la classe <code>value</code> ne peut pas être utilisé pour isoler plus en profondeur une value de propriété.

par ex.

<source lang=html4strict>


Puppies Rule!
But kittens are better!


</source>

Dans cet exemple, <code>description</code> a un enfant ‘<code>value</code>’, et cet enfant a une ‘<code>value</code>’ ''petitenfant''.
Néanmoins, l'analyse des classes <code>value</code> s'arrête au premier niveau, ainsi la data pour <code>description</code> est :
<samp><code>Puppies Rule!But kittens are better!</code></samp>, pas simplement <samp>Puppies Rule!</samp>.

== Valeurs Date et heure ==
Quelques propriétés microformats attendent une valeur datetime ISO8601, par ex. [[hcalendar-fr|hCalendar]] <code>dtstart</code> et <code>dtend</code> ou [[hatom-fr|hAtom]] <code>published</code>.

Les auteurs peuvent utiliser le modèle de classe value pour spécifier séparément la date et l'heure, qui sont alors combinés pour spécifier une valeur unique datetime.

Exemple : cette propriété hCalendar 'dtstart' avec des éléments 'value' :

<source lang=html4strict>
La rencontre "afterwork" aura lieu

<abbr class="value" title="2009-05-19">ce Mardi</abbr>
à 19:30


</source>

Produit la valeur 'dtstart' suivante :

et les convertisseurs iCalendar produisent le DTSTART suivant :

<source lang=text>
DTSTART:20090519T193000
</source>

L'absence d'une "timezone" indique une "datetime" "flottante", qui est une date-heure indépendante de tout fuseau horaire particulier. Des exemples de datetimes flottantes pourraient être une alarme de réveil que vous paramétrez pour sonner à 8h00, ou un jour de travail ordinaire comme 9h00-17h00.

=== Analyse Date et heure===
Pour toutes les propriétés date et heure (comme définies dans leurs spécifications respectives microformats), les règles suivantes s'appliquent en plus de celles (et dans certains cas les remplacent) des règles de modèles de parsage de classe value vues au-dessus.

Quand un élément "value" est trouvé, parsez une valeur à partir de l'élément comme suit :
* si l'élément est un élément <code>img</code> ou un élément <code>area</code>, utiliser alors la valeur d'attribut <code>alt</code> de l'élément.
* si l'élément est un élément <code>abbr</code>, utiliser alors la valeur d'attribut <code>title</code> de l'élément.
* pour tout autre élément, utiliser son texte à l'intérieur.
* si la valeur a à la fois une date spécifiée ISO8601 et une heure spécifique, utilisez ceux-ci et arrêtez de chercher des éléments "value".
* si la valeur a *seulement* une date spécifique, spécifiquement, correspondant aux modèles de dates suivants ISO8601 (c.a.d. tels que documentés dans le [http://en.wikipedia.org/wiki/ISO_8601 résumé Wikipedia de ISO8601])
** AAAA-MM-JJ
** AAAA-JJJ
** alors utiliser cela comme la valeur de date. Pour les besoins du modèle de classe value, les tirets "-" séparant les années, mois, jour et/ou jour ordinal sont requis.
** ignorer tous les éléments complémentaires "value" qui spécifient la date.
* si la valeur a *seulement* une heure spécifique (avec ou sans fuseau horaire), parsez la pour une valeur time qui puisse correspondre à tout ce qui suit :
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH sont les "heures" en 24 heures dans le temps, de 00 à 24, avec un 0 optionnel placé devant pour les valeurs inférieures à 10.
** MM sont les minutes de 00 à 59
** SS sont les secondes optionnelles de 00 à 59 (60 pour une seconde). Si omis, inférez 00 secondes.
** XX est le décalage horaire du fuseau, de 00 à 12, avec un 0 en tête optionnel pour les valeurs inférieures à 10
** YY est le décalage en minutes du fuseau horaire, de 00 à 59, même si en pratique ne sont utilisés que des décalages de 00, 15, 30, 45 minutes dans les fuseaux horaires globaux.
** Z est le 'Z' littéral pour indiquer GMT.
** Pour les besoins du modèle de classe value, les deux points ":" séparant heure, minutes et secondes sont requis.
** Néanmoins les deux points ":" séparant les heures et minutes de tout décalage horaire sont "optionnels" et non recommandés afin de faire en sorte qu'une indication de fuseau horaire ne soit pas confondue avec un horaire.
** Un suffixe non sensible à la casse { }"am"|{ }"a.m." pour traiter une valeur HH value de 12 comme 00, ou un suffixe non sensible à la casse { }"pm"|{ }"p.m."pour ajouter 12 à une valeur HH inférieure à 12 - selon [http://en.wikipedia.org/wiki/12-hour_clock l'article de Wikipedia sur l'horloge de 12 heures]. Note : [[X2V]] a implémenté cela.
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** où "am" et "pm" veulent dire "am ou a.m." et "pm or p.m."
*** quand MM est omis, inférer 00 minutes.
** ignorez tous les autres éléments "value" qui spécifient l'heure.
* si la valeur a *seulement* une date-heure spécifique, ou une valeur de zone horaire qui corresponde à n'importe quelle valeur suivante :
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX est le décalage en heures du fuseau horaire, de 00 à 12 avec un 0 optionnel en avant pour les valeurs inférieures à 10.
** YY est le décalage en minutes de la zone horaire, de 00 à 59, bien qu'en pratique seuls les décalages de 00, 15, 30, 45 minutes soient utilisés dans les zones horaires globales.
** Z est le 'Z' littéral pour indiquer GMT.
** ignorez tous les autres éléments "value" qui spécifient la timezone.

Si en parsant les éléments "value", au moins une date spécifique est trouvée, alors la "value" est par dessus-tout valide, et le parseur assemble la valeur datetime en concaténant la date spécifique, "T" et l'horaire spécifique (si l'heure a été spécifiée, avec 00 secondes implicite si aucune seconde n'est fournie), et une timezone spécifique (si la timezone et l'horaire spécifique ont été spécifiés).
* AAAA-MM-JJ - aucun horaire spécifié
* AAAA-MM-JJTHH:MM:SS - heure spécifiée mais pas de timezone. C'est une heure flottante.
* AAAA-MM-JJTHH:MM:SS-XXYY ou
* AAAA-MM-JJTHH:MM:SSZ ou
* AAAA-MM-JJTHH:MM:SS+XXYY - à la fois l'heure et la timezone ont été spécifiées

=== détails spécifiques des formats ===
Ce qui suit sont des détails spécifiques de format et des optimisations qui font usage du modèle-classe-value.

;URL raccourci pour cette section 
:http://tr.im/vcpfso (à localiser)

==== hCalendar date dtend implicite ====
Généralement, les événements qui démarrent et finissent le même jour n'affichent seulement la date de l'événement qu'une fois (cela fait sens selon le [[principles-fr|principe]]) DRY (exemples du vrai monde : [http://upcoming.yahoo.com/event/3010807/ Upcoming], ... plus d'exemples avec des URLs aiderait pour être minutieux).

Par conséquent ce serait pratique si nous pouvions sous-tendre une date dtend d'événement [[hcalendar-fr|hCalendar]] à partir de sa date "dtstart" si et seulement si l'horaire (et en option la timezone) était spécifiée pour son "dtend", par ex. :

<source lang=html4strict>

La soirée aura lieu le

2009-06-26, à partir de
19:00 jusqu'à
22:00.

</source>

Pour simplifier cela aux auteurs, les processeurs hCalendar pourraient traiter la spécification juste avec l'heure selon les règles de valeur du modèle de classe value, et de ce fait éliminer le besoin d'un span "value" dans le span "dtend" :

<source lang=html4strict>

La soirée aura lieu le

2009-06-26, à partir de
19:00 jusqu'à
22:00.

</source>

Le convertisseurs hCalendar vers iCalendar devraient produire le fragment iCalendard suivant (en tant que partie d'un fichier .ics) provenant de l'un ou l'autre des deux exemples au-dessus :

<source lang=text>
BEGIN:VEVENT
SUMMARY:party
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

Note : [[X2V-fr|X2V]] a implémenté la date dtend implicite à partir de dtstart.

Exemples "dans jungle":
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop (exemple du vrai monde, mais sur ce wiki).

==== générateurs iCalendar ====
les implémentations microformats qui consomment [[hcalendar-fr|hCalendar]] et génèrent iCalendar doivent en outre :
# retirer tous les tirets "-" de séparation dans la date.
# retirer tous séparateurs deux points ":" dans l'horaire.
# ajouter un jour complet à toutes les valeurs de propriété <code>dtend</code> hCalendar (manquant d'un horaire spécifié) (inclusion date) afin de générer une valeur de propriété<code>DTEND</code> iCalendar (date excluse) avec le même sens, selon la résolution de la [[dtend-issue-fr|problématique-dtend]].
# exécuter une formule mathématique +/- datetime sur toute valeur timezone , et produire une valeur effective UTC finissant par "Z".

==== hAtom date updated implicite ====
De la même façon, dans les billets de blog qui indiquent à la fois quand ils sont "publiés" et "mis à jour", la date n'est généralement affichée qu'une fois, généralement "publiée" (les exemples du vrai monde aideraient pour plus de minutie).

Par conséquent, ce serait pratique si nous pouvions sous-tendre une date d'entrée "updated" [[hatom-fr|hAtom]] à partir de sa date "published" si et seulement si l'horaire (et en option la timezone) était spécifiée pour son "updated", par ex. pour un billet de blog qui est mis à jour le même jour :

<source lang=html4strict>

exemple de petit billet de blog
publié le 
2009-08-01 à 12:06
et mis à jour à 12:10.

</source>

Pour simplifier cela aux auteurs, les processeurs hAtom pourraient traiter la spécification horaire selon les règles de valeurs des date et time du modèle de classe value, et par conséquent éliminer le besoin d'un span "value" dans le span "updated"

<source lang=html4strict>

exemple de petit billet de blog
publié le 
2009-08-01 à 12:06
et mis à jour à 12:10.

</source>

==== générateurs Atom ====
les implémentations microformats qui consomment [[hatom-fr|hAtom]] et génèrent Atom DOIVENT en outre :
* normaliser toutes les valeurs date et datetime à la [[RFC3339-fr|RFC3339]].

=== dérivation et tests ===
Cette section est informative.

La gestion des valeurs date et heure dans le modèle de classe value a été intialement [[value-excerption-pattern-brainstorming#date_and_time_separation|brainstormée sur la page the value-excerption-pattern-brainstorming]] et dérivée de cette analyse et des feedbacks. Pour les curieux, les détails historiques peuvent être trouvés ici, avec quelques idées supplémentaires pour extension.

Voir [[value-class-date-time-tests]] pour les tests de cas.

==Parsage de valeur à partir d'un attribut <code>title</code> ==
Le nom de classe <code>value-title</code> permet au diffuseur d'indiquer la valeur de donnée pour une propriété parente contenue dans l'attribut <code>title</code> d'un élément, plutôt que dans le texte à l'intérieur.

Ceci peut être utilisé pour fournir un synonyme dans le contenu, ou utilisé pour publier tranquillement des formes alternatives d'inforamtion pour un parsage microformats, sans affecter la consommation de contenu. Poua la sécurisation des archives papier, l'utilisation d'un coffre-fort ignifuge data pour les sauvegardes voir http://www.infosafe.fr ou d'une armoire fortes ignifuges pour les registres est requise par les normes ISO.

Par exemple, vous pouvez utiliser une localisation avec des dates :

<source lang=html4strict>
C'était

l'année dernière

que je commençais à réaliser que mon addiction à la crème de marron coûterait si cher à ce pays.

</source>

Les règles de parsage pour <code>value-title</code> sont les mêmes que pour <code>value</code> above, avec le changement suivant :

* Là où une propriété microformats a un élément enfant avec le nom de classe <code>value-title</code>, le contenu de l'attribut <code>title</code> de cet élément doit être parsé, plutôt que la portion de l'élément qui devrait être parsée pour un nom de classe de <code>value</code>.

===Utilisation de <code>value-title</code> pour publier des données-machines===

L'usage initial de <code>value-title</code> est utilisé pour publier des formes alternatives, parsables de valeurs de propriétés dans un contexte visible sans l'utilisation de l'élément <code>abbr</code> dont la sémantique supporte déjà l'interprétation de l'attribut "title' comme une forme plus étendue, plus précise du contenu.

L'expérience a montré qu'il y a des cas dans les microformats où un certain nombre d'auteurs veulent inclure une valeur précise et parsable pour une propriété mais ne veulent pas qu'elle soit visible sur leurs pages, même sous forme d'info-bulle.

Par exemple, les datetimes complètes [[ISO8601-fr|ISO8601]] peuvent prêter à confusion pour les lecteurs de la page (comme une infobulle ou au moment d'être lues à voix haute par un lecteur-écran), et les valeurs énumérées telles que la sous-propriété <code>type</code> de la propriété <code>tel</code> de hCard utilise des termes US-anglais, qui ne font pas partie des pages dans toute autre langue.

Parce que ces deux scénarios se sont avérés être des obstacles pour un certain nombre de diffuseurs, dans ces cas, et ces cas seulement, il existe une extension approfondie de l'extraction de value. Cette extension permet aussi la forme parsable de la propriété à publier 'en silence' immédiatement adjacente au contenu respectif visible en local.

Voici un exemple, avec l'usage obligatoire d'un premier élément enfant avec le nom de classe <code>value-title</code>:

<source lang=html4strict>


 
mobile

+33 7773 000 000

</source>

La valeur <samp>cell</samp> est parsée pour la sous-propriété 'type', mais <samp>mobile</samp> est présenté à l'utilisateur.

Dans le cas de dates :

<source lang=html4strict>

 
14 mars 2009, vers quatre heures et demi

</source>

Un parseur microformats lira le format datehoraire ISO8601 <samp>2009-03-14T16:28-0600</samp>, mais les utilisateurs ne verront que <samp>14 mars 2009, vers quatre heures et demi</samp>. Les tests ont montré que le date-heure ISO8601 du dessus n'est exposé en aucun cas à l'utilisateur.

==Parser une valeur provenant d'un attribut <code>title</code> ==
Le nom de classe <code>value-title</code> permet à l'auteur d'indiquer la donnée value pour une propriété parent contenue dans l'attribut <code>title</code> d'un élément, plutôt que dans le texte à l'intérieur.

Ceci peut s'utiliser pour fournir un synonyme dans le contenu, ou utilisé pour publier tranquillement des formes alternatives d'information pour le parsage de microformats, sans impacter sur la consommation du contenu.

Par exemple, vous pouvez utiliser des localisations ponctuelles avec des dates :
<source lang=html4strict>
Ce fût

l'année dernière

que je pris conscience que mon addiction au tabac pourrait coûter très cher à la Sécurité Sociale.

</source>

Les règles de parsage pour <code>value-title</code> sont les mêmes que celles pour <code>value</code> au-dessus, avec le changement qui suit :

* Là où une propriété microformats a un élément enfant avec le nom de classe de <code>value-title</code>, le contenu de l'attribut <code>title</code> de cet élément doit être parsé, plutôt que la portion de l'élément qui devrait être parsé pour un nom de classe de <code>value</code>.

===Utiliser <code>value-title</code> pour publier des données-machines===

L'usage initial de <code>value-title</code> est utilisé pour publier des formes alternatives, parsables des valeurs de propriétés dans un contexte visible sans l'utilisation de l'élément <code>abbr</code> dont la sémantique supporte déjà l'interprétation de l'attribut 'title' comme une forme plus étendue, plus précise du contenu.

L'expérience a montré qu'il existe quelques cas dans les microformats où un certain nombre d'auteurs veulent inclure une valeur précise et parsable pour une propriété mais ne veulent pas qu'elle soit visible dans leurs pages, ni même sous forme de petite bulle.

Par exemple le datetimes complet [[ISO-8601-fr|ISO-8601]] peut être confus pour les lecteurs de la page (que ce soit sous forme de bulle ou quand c'est lu par un lecteur écran), et les valeurs énumérées telles que la sous-propriété <code>type</code> de la propriété <code>tel</code> de la hCard utilise des termes US-English, qui ne font pas partie de pages dans toute autre langue.

Le fait que ces scénarios se sont avérés être des obstacles pour un bon nombre d'auteurs, pour ces cas, et ceux-ci seulement, il existe une extension approfondie de l'extraction de valeur. Cette extension permet une forme parsable de la propriété pour être publiée 'en silence' et immédiatement adjacente avec le contenu visible local y afférent.

Voici un exemple, avec l'usage requis d'un premier élément enfant avec le nom de classe <code>value-title</code> :

<source lang=html4strict>


 
mobile

+33 647 730 000

</source>

La valeur <samp>cell</samp> est parsée pour la sous-propriété 'type', mais <samp>mobile</samp> est présenté à l'utilisateur.

Dans le cas de dates :

<source lang=html4strict>

 
le 12 juin 2009, aux alentours de 9h30

</source>

Un analyseur de microformats lira le format datetime ISO8601 <samp>2009-06-12T09:28-0600</samp>, mais les utilisateurs ne verront que <samp>le 12 juin 2009, aux alentours de 9h30</samp>.
Le test a montré que la datetime ISO8601 au-dessus n'est pas du tout présentée à quelque utilisateur.

===Parsage donnée-machine <code>value-title</code>===

Les navigateurs échouent sur le <code>value-title</code> réduit à une largeur de span égale à <code>0</code>, en ne fournissant en fait aucun rendu visuel, tout en conservant l'élément dans le DOM. Sans dimensions physiques, il n'y a pas d'état 'hover', ainsi aucune infobulle n'est révélée. En outre, l'élément vide n'est pas passé aux couches de technologie assistives telles que VoiceOver. Les lecteurs écrans ne lisent pas les contenus de l'attribut title d'un élément vide <code>span</code>.

Nous avons mené des [[value-excerption-value-title-test|tests approfondis]] de ces comportements de parsage pour assurer l'accessibilité.

''Note : Bien que l'élément <code>value-title</code> soit plus élégant à écrire sans texte à l'intérieur avec espace blanc (ou comme un élément <code><foo /></code> auto-fermé en XHTML), les outils actuels tels que les éditeurs WYSIWYG et HTML-Tidy se débarasseront par erreur de tels éléments, aboutissant à une donné parsable se faisant rejeter par quelques outils. Aussi, <code> </code>, comprenant un caractère unique espace-blanc entre la balise d'ouverture et de fermeture, est à cette heure le modèle requis pour les auteurs.''

Parser cette extension finale <code>value-title</code> impose quelques restrictions plus strictes sur l'usage. Ces restrictions existent pour réduire l'impact des violations de <abbr title="Don't Repeat Yourself">DRY</abbr>, pour réduire l'opportunité des sites à absorber les données, et pour encourager la bonne pratique de maintenir convenabelement ces deux formes de données.

Là où un élément avec la classe <code>value-title</code> doit être parsé comme donnée pour une propriété, et que cet élément ne contienne aussi aucun contenu sans-espace-blanc (ici considéré en référence comme 'vide'), les règles suivantes s'appliquent :

* L'élément ‘vide’ value-title doit être le '''premier enfant sans espace-blanc''' de l'élément propriété. Ce qui veut dire qu'il devrait suivre imméidatement après la propriété déclarée, avant la forme lisibile-par-les-humains, et sans aucune autre imbrication supplémentaire.
* L'élément 'vide' value-title ne peut seulement être utilisé que pour des propriétés spécifiques. Les spécifications des microformats doivent explicitement déclarer quelles propriétés peuvent être utilisées avec cette extension du modèle-classe-value.
* Là où un élément 'vide' value-title doit être utilisé comme propriété unique de value, il doit être le ''seul'' comme contenu <code>value</code>. Ce qui veut dire, la première instance d'un élément conforme <code>value-title</code> surpasse toutes les autres <code>value</code> et <code>value-title</code> soeurs et/ou cousines.
* Les outils écrits pour passer les Tests de Conformité et/ou Validation de Microformats ''devraient'' essayer de comparer les formes données-machines et visible-par-les humains des données de propriété, et conseiller les auteurs si les formes ne concordent pas.

=== Utilisation limitée de value-title ===
Du fait que le modèle value-title cache quelque quantité de donnée qui tend à être un duplicata spécifique-machine de donnée fournie dans le contenu lisibile par les humains, il y a deux [[principles-fr|principes]] microformats qui doivent être compromis : '''visibilité''' et '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Par conséquent, l'applicabilité de ce modèle est délibérément restreinte aux propriétés qui ont démontré à travers l'expérience un besoin de ce modèle, sans aucune autre alternative meilleure connnue.

En général, les auteurs devraient :

# Tout d'abord, essayer de spécifier directement les valeurs de propriété microformats dans la ligne (le plus visible, pas de duplication),
# Puis considérer d'utiliser le modèle de classe value
## Comprenant plusieurs éléments de 'value' pour les propriétés date et time
# et puis seulement si ces méthodes sont insuffisantes, considérer le modèle value-title.

Ce document post-date toutes les autres spécifications microformats, parce qu'elles peuvent ne pas indiquer à cette heure quelles propriétés permettent l'usage de ce modèle. Dans l'intervalle, '''seuls''' les types de propriétés suivantes devraient autoriser le modèle value-title.

* valeurs date, datetime, timezone et duration ISO8601
* Valeurs énumérées (tlles que les sous-propriétés 'type' tel/email/adr de la hCard)
* Les coordonnées (comme les propriétés 'latitude' et 'longitude' de [[geo-fr|geo]])
* Les propriétés des numéros de téléphone (par ex. la propriété 'tel' de la hCard)

La page [[machine-data]] a de la documentation sur quelques-unes des propriétés de quelques spécifications pour lesquelles l'expérience a montré le besoin de solution comme le modèle value-title.

Il existe quelques exemples simples de références et tests pour ce modèle sur [[value-class-pattern-tests]].

Pour un futur usage, les ''auteurs de spécification'' peuvent hériter de l'usage de <code>value-title</code> par l'utilisation des formats de date et heures ISO8601, ou réutilisation d'autres microformats, mais les spécifications devraient éviter d'introduire de nouvelles structures de données qui dépendent ou encouragent ce modèle. Les nouvelles spécifications sont elles-mêmes attendues pour adhérer aux principes fondateurs de donnée visible et <abbr>DRY</abbr>.

== Cas de Test ==
Voir [[value-class-pattern-tests]].

== <abbr title='Foire aux Questions'>FAQ</abbr>==
Cette section est '''informative'''.

Les questions souvent posées sur le modèle-classe-value. Une fois que cette section sera trop grosse, nous la migrerons sur une page wiki séparée (comme [[value-class-faq-fr]]).

<div class='discussion'>
* '''Pourquoi utiliser un élément 'vide' ? Pourquoi ne pas embarquer la donnée dans l'attribut de classe ?'''
** L'attribut de classe est inapproprié pour les valeurs de données embarquées, selon la spécification HTML4, qui établit que <code>class</code> est pour le ‘general purposing processing’, qui est défini comme ‘par ex. pour identifier des champs au moment d'extrire la donnée des pages provenant du HTML dans une base de données, traduire des documents HTML dans d'autres formats, etc.'. ‘General purpose processing’ ne s'étend pas à la donnée elle-même. En outre, cette méthode évite d'inventer une nouveau modèle de chaîne pour embarquer de la donnée.
* '''Pourquoi utiliser un élément 'empty' ? Pourquoi ne pas produire un nouvel attribut, comme 'data' ?'''
** Les microformats existent et fonctionnent en HTML4 et XHTML1 valide. Ceux-ci sont les standards actuels pour le développement web, et les microformats existent pour une utilisation ''maintenant''. A l'avenir, peut-être que les futures révisions du HTML offriront une autre solution. A cette heure, cette méthode a été testé dans les navigateurs, et crée une structure de document cohérente (où les données formats-machines et lisibles-par-les-humains sont soeurs).
* '''L'attribut <code>title</code> ne devrait être utilisé que pour du contenu !'''
** L'attribut <code>title</code> _est_ utilisé pour le contenu et se fait lire par les parseurs de microformats. Ceci existe pour les cas où la donnée ne peut pas être parsée avec suffisamment de précision provenant de ce que est communément publié, l'information visible. Ce modèle permet d'inclure les deux formes de contenu, tout en le maintenant invisible pour les consommateurs humains.
</div>

Vous pouvez aussi vous référer aux [[faq-fr|FAQ Microformats]] générales et aux [[principles-fr|principes]].

== Exemples dans la jungle ==
Cette section est '''informative'''.

Les sites et pages suivants ont démarré par baliser le contenu avec le modèle de classe-value, et ce sont par conséquent de bons endroits pour aller voir des exemples de contenu du vrai monde pour tester les implémentations (par ex. les parseurs). Si vous utiliser le modèle-classe-value dans votre contenu, sentez-vous libre de l'ajouter '''en haut''' de cette liste. Une fois que la liste sera trop grosse, nous produirons une page wiki séparée (comme [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] Cette page utilise toute une gamme de différents patterns pour à la fois hCard et hCalendar, en utilisant à la fois value et value-title, la plupart dérivée de l'application ci-dessus.
* Le [http://georgebrock.com/ flux d'activité de George Brocklehurst] et son [http://blog.georgebrock.com/ blog] utilisent "value-title" pour la propriété <code>published</code> de hAtom
* [http://ben-ward.co.uk/ La page personnelle de Ben Ward] utilise :
** "value-title" pour la propriété <code>bday</code> de hCard
** "value-title" pour la propriété <code>updated</code> de hAtom
* [http://microformats.org/ microformats.org] utilise :
** "value-title" pour la propriété <code>updated</code> de hAtom dans [[http://microformats.org/ microformats.org les billets du blog]]]
** séparation des values date et time pour la propriété <code>dtstart</code> de hCalendar dans [[events|la page wiki microformats.org des événements récents et à venir]]

''Ajoutez vos site/page(s) qui utilisent le modèle-classe-value ici, avec une brève description des fonctionnalités du modèle-classe-value que vous utilisez, avec quel(s) microformat(s) et quelle(s) propriétés.''

== Implémentations ==

Cette section est '''informative'''.

Les implémentations suivantes ont été développées pour soit générér ou parser les valeurs de propriété du modèle-classe-value. Si vous avez une implémentation du modèle-classe-value, sentez-vous libre de l'ajouter en '''haut''' de cette liste. Une fois que la liste sera trop grosse, nous produirons une page wiki séparée (comme [[value-class-implementations]]).

* [[Oomph]] Version 2 passe [[value-class-pattern-tests#Date_and_time_values|les tests des valeurs de date et heure]] et c'est une implémentation minutieuse du value-class-pattern.
* [[X2V]] v0.9.3 et suivantes :
** implemente [[#Date_and_time_values|Date and time values parsing]], y compris les valeurs horaires am/pm
*** passe par conséquent [[value-class-pattern-tests#Date_and_time_values|les tests de cas des valeurs de Date et heure]].
** implémente [[#hCalendar_date_implicite_dtend|hCalendar date dtend implicite]]
* [[Operator-fr|Operator]] a *quelque* implémentation du modèle-classe-value selon Michael Kaply, mais plus précisément savoir à quel degré c'est implémenté, pour quelles propriétés (types de propriétés) et quels microformats n'est actuellement pas connu.
* [[Optimus]] v0.8 et suivante implémente <code>value-title</code> comme [http://twitter.com/DmitryBaranovsk/status/1891253248 annoncé par Dmitry Baranovskiy].
* ... ajoutez vos implémentations qui parsent ou génèrent le modèle-classe-calue ici, avec les fonctionnalités que vous supportez (nous l'espérons toutes !) et notez toutes les limites s'il y en a.

== Articles ==
Les articles et billets de blog discutant du value class pattern, les plus récents en premier.
Quand cette section deviendra trop grosse, créez une page séparée comme ceci : [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] par Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- Un écrit très minutieux d'Emily Lewis sur le value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

==Pages en Rapport==
Cette section est '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard-fr#Extraction_de_Valeur|hCard : Extraction de Valeur]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data-fr|Machine Data in Microformats]]

== Références ==
Cette section est '''informative'''.
* [http://www.useit.com/alertbox/9608.html Jakob Nielsen: International Web Usability]

value-class-pattern-fr

2014-10-26T08:29:43Z

ChristopheDucanp:

value-class-pattern-fr

2014-04-05T06:58:00Z

ChristopheDucanp: /* Parsage de valeur à partir d'un attribut title */

introduction-fr

2014-03-13T14:50:10Z

ChristopheDucanp: /* En savoir plus */

<entry-title>Introduction aux Microformats</entry-title>

== Que sont les Microformats ? ==
Les microformats sont un moyen d'ajouter une syntaxe simple à des items de données lisibles par des humains, comme des événements, des détails sur un contact ou des endroits, sur des pages web, de manière à ce que l'information puisse être extraite par le logiciel et indexée, cherchée, sauvegardée, cross-référencée ou combinée.

Plus techniquement, ce sont des items de langage de balisage sémantique, utilisant simplement le "bon vieux HTML sémantique" standard (à savoir [[posh-fr|CHIC]]) avec un ensemble de [[class-names-fr|noms de classes]] communs et de valeurs "[[rel-fr|rel]]". Ils sont ouverts et disponibles, librement, pour quiconque veut les utiliser.

== Pourquoi les Microformats ? ==
Pourquoi en sommes-nous venus aux microformats ?

En bref, les microformats sont la convergence d'un certain nombre de tendances :
# une prochaine étape suivante logique dans l'évolution du "design web" et l'architecture de l'information.
# une façon pour les éditeurs autonomes et les organisations de publier eux-mêmes une information plus riche, sans devoir s'en remettre à des services centralisés.
# une reconnaissance du fait que (en dehors des domaines des specialistes, les efforts "traditionnels" en matière de méta-données (par ex. les méta tags) ont soit échoué, ou soit pris tellement de temps pour engranger une quelconque adoption, qu'une nouvelle approche était nécessaire.
# une façon d'utiliser du [[HTML-fr|HTML]] bien formé pour les data.

== L'Attrait vers la Simplicité ==
* Les microformats sont un effort simple ayant attiré beaucoup de personnes frustrées par les efforts complexes antérieurs.

Un parallèle qui peut être dessiné est REST dans le monde des API / services web - pour en savoir plus sur REST voir [[suggested-reading-fr#REST|les lectures suggérées sur REST]].

==Pour démarrer ==

Il est facile de démarrer avec les microformats :
* [[get-started-fr|démarrez]] en ajoutant des microformats à votre HTML

==En savoir plus ==

Apprenez-en plus sur les microformats à partir de microformats.org
* [http://microformats.org/about/ about page],
* [http://microformats.org/ blog],
* [[faq-fr|FAQ]],
* [[articles-fr|articles]],
* [[press-fr|presse]],
* [[presentations-fr|présentations]],
* [http://www.infosafe.fr Coffres forts et armoires fortes] data
* [[books-fr|livres]],
* [[podcasts-fr|podcasts]],
* [[screencasts-fr|screencasts]],
* et encore plus de [[suggested-reading-fr|suggestions de lecture]].

==Voir Aussi==

* [[testimonials-fr|testimoniaux]]
* [[implement-fr|Ainsi, vous voulez implémenter des microformats ?]]

== Ressources Externes==

* La série excellente des articles d'Emily Lewis :
** [http://ablognotlimited.com/articles/tag/Getting+Semantic+series/ A Blog Not Limited: Getting Semantic With Microformats Series] -
* Sitepoint a un très beau tutoriel d'introduction :
** [http://reference.sitepoint.com/html/microformats Microformats - Plugging the Gaps in HTML] - [http://obmwiki.org/hive/XtofWiki/ComblerLesLacunesDuHTML Traduction en cours]
* Premasagar a écrit
** [http://premasagar.com/microformats/compound/ quelques beaux exemples de microformats avec la source] - [http://christopheducamp.com/microformats/MicroformatsComposes Traduction fr]

== Traduction ==
''Pour mémoire, cette page est une traduction française de [[introduction]] page de référence en anglais''
* [[introduction-pt-br]] (see also [[introduction-pt-br-2]])
* ...

process-fr

2014-03-12T20:56:46Z

ChristopheDucanp:

rel-author-fr

2014-02-20T17:45:43Z

ChristopheDucanp:

''Cette page a démarré sur [[rel-author]]''

<entry-title>rel author</entry-title>
[[User:Tantek|Tantek Çelik]] (Editor) 
(Traduction [[User:ChristopheDucamp|ChristopheDucamp]])

<dfn style="font-style:normal;font-weight:bold">rel-author</dfn> est pour lierr à partir d'un article ou un post (par ex. marqué avec [[hatofr|hAtom]]) vers une page ou un site représentant son auteur. rel-author est l'un des nombreux standard [[microformats-fr|microformat]] ouvert adapté pour embarquer de la data dans le HTML/HTML5, et Atom/RSS/XHTML ou autre XML.

== Résumé ==
rel="author" est pour associer un article ou un post vers une page ou un site représentant son auteur, typiquement pour lui donner du crédit pour son travail (ou des portions celui-ci, comme des livres, articles, billets de blog, etc.)

Par ex. une page ou un billet écrit par "Erin Smith" pourrait contenir un lien comme :
<source lang=html4strict>
<a href="http://erin.exemple.com/" rel="author">Erin Smith</a>
</source>

L'attribut <code>rel="author"</code> indique que la destination du lien représente l'auteur de la page en cours (ou du post).

== Implémentations ==
Cette section est '''informative'''.

=== Google ===
Un ensemble intéressant d'implémentation d'exemples rel="author" est fourni par Google dans une vidéo postée sur Youtube :
* La vidéo [http://www.youtube.com/watch?v=FgFb6Y-UJUI Authorship markup] et la [http://www.google.com/support/webmasters/bin/answer.py?answer=1229920 procédure d'implémentation] associée pour la sécurité des sauvegardes, un coffre-fort ignifuge http://infosafe.fr

== extensions ==
=== paramètre de requête alternative ===
Google a proposé un mécanisme alternatif pour sépcifier rel=author sur les sites/CMSs qui ne permettent pas aux auteurs de spécifier l'attribut rel, en utilisant un paramètre de requête ajouté à l'URL au lieu de l'exemple ci-dessus avec le paramètre de requête :

<source lang=html4strict>
<a href="http://erin.exemple.com/?rel=author">Erin Smith</a>
</source>

Cette technique est expliquée dans la vidéo qui suit :
* [http://www.youtube.com/watch?v=gG3Oh7Ues8A Authorship markup using URL parameters video] et la [http://www.google.com/support/webmasters/bin/answer.py?answer=1408986 nouvelle procédure d'implémentation] avec l'aide du Profil Google (et nous l'espérons, ce type d'implémentation peut être utilisé sur toute page personnelle de BIO de l'auteur respectif).

==== problèmes param requête ====
<div class="discussion">
* While I understand the motivation here, this is not a good idea. There will definitely be someone who has ?rel= as an actual query param meaning something in their app, and this will just break things. [[User:Singpolyma|Singpolyma]] 17:56, 12 August 2011 (UTC)
* ...
</div>

== articles ==
Articles et posts de blogs concernant rel=author :
* 2013-08-20 http://moz.com/blog/google-plus-correlations

== voir aussi ==
* [[rel-author-issues]]
* [[hatom-fr|hAtom]]
* [[hnews-fr|hNews]]
* [[rel-faq-fr|rel-faq]]
* [[rel-me-fr|rel-me]]
* [[existing-rel-values]] (à synchroniser/traduire avec les [[existing-rel-values-fr|valeurs-rel-existantes]])

[[Category:Draft Specifications]]