hcard-brainstorming-fr

2008-12-20T03:45:58Z

LicocOracv: lipasbasc

rolcorc4tel
boctrocorca
<h1> hCard Brainstorming </h1>
{{TOC-right}}
Cette page est pour brainstormer sur les diffÃÂ©rentes utilisation et les dÃÂ©tails de [[hcard-fr|hCard]].
Cette page contient des <em>propositions</em>. Pour l'ÃÂ©tat actuel, regardez svp [[hcard-fr|hCard]].
== Auteurs ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek ÃÂelik], prÃÂ©cÃÂ©demment chez [http://technorati.com Technorati, Inc]

== Contributeurs ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* [[User:AndyMabbett|Andy Mabbett]]
* ... et bien d'autres
(Traduction en cours [[Christophe Ducamp]])

== ProblÃÂ¨mes Etant RÃÂ©solus ==
Quelques-uns des problÃÂ¨mes que [[hcard-fr|hCard]] aide ÃÂ rÃÂ©soudre :
* devoir saisir les cartes de visite qui deviennent obsolÃÂ¨tes (s'abonner ÃÂ la place ÃÂ la [[hcard-fr|hCard]] syndiquÃÂ©e de quelqu'un).
* "mise ÃÂ jour de votre info de contact email" ennuyeuse ÃÂ partir de diffÃÂ©rents services d'informations de contacts centralisÃÂ©s.
* [[social-network-portability-fr|portabilitÃÂ© de rÃÂ©seau social]] ÃÂ travers l'utilisation de [[hcard-supporting-user-profiles-fr|hCard supportant les profils utilisateur]] et [[hcard-xfn-supporting-friends-lists-fr|hCard+XFN supportant les listes d'amis]]

== Endroits nommÃÂ©s ==
La plupart des hcards contiennent de l'information de contact pour les personnes et organisations. Mais les lieux qui se sont pas des organisations mÃÂ©ritent aussi leurs propres hCards (par ex la maison ou l'appartement de quelqu'un). Cette situation peut ÃÂªtre reprÃÂ©sentÃÂ©e en combinant "fn" et "extended-address".

=== combinaison de "fn" et "extended-address"===

'''Proposition''' : De la mÃÂªme maniÃÂ¨re que l'[[hcard-fr#Info_Contact_Organisation|information de contact de l'organisation]], si la propriÃÂ©tÃÂ© "fn" et une propriÃÂ©tÃÂ© "extended-address" ont la mÃÂªme valeur exacte (gÃÂ©nÃÂ©ralement elles sont rÃÂ©glÃÂ©es sur le mÃÂªme ÃÂ©lÃÂ©ment, c'est ÃÂ dire <code>class="fn extended-address"</code>), alors :

# La hCard reprÃÂ©sente l'information de contact pour un endroit et DEVRAIT ÃÂªtre traitÃÂ©e en tant que tel.
# L'auteur aussi NE DOIT PAS rÃÂ©gler la propriÃÂ©tÃÂ© "N" ou la rÃÂ©gler (et toutes ses sous-propriÃÂ©tÃÂ©s) expicitement vers la chaÃÂ®ne vide.
# Les parseurs DEVRAIENT gÃÂ©rer la propriÃÂ©tÃÂ© "n" manquante en supposant des valeurs vides pour toutes les sous-propriÃÂ©tÃÂ©s "n".

'''Proposition plus poussÃÂ©e''' : Imaginez aussi une hCard pour une ville, "Birmingham, England" : Birmingham peut ÃÂªtre le "fn" et la "locality", mais ce n'est pas une "extended-address". Peut-ÃÂªtre que la rÃÂ¨gle devrait ÃÂªtre que la hCard est pour l'endroit si le "fn" est sur n'importe quel compsant de l'adresse (c'est ÃÂ dire "fn locality" ou "fn street-address") ?

=== Exemples dans la jungle ===

* Le lieu nommÃÂ© "Picnic benches" dan l'adresse "Picnic benches, South Park, San Francisco, California" dns [http://adactio.com/journal/1364/ un billet de blog sur adactio.com].
<pre><nowiki>
<span class="vcard">
<span class="adr">
<span class="fn extended-address">Picnic benches</span>
<span class="street-address">South Park</span>
<span class="locality">San Francisco</span>
<span class="region">California</span>
</span>
</span>
</nowiki></pre>

==== Exemples potentiels dans la jungle ====

* Le lieu "Phone Boxes by the Sealife Centre" [http://upcoming.yahoo.com/venue/5668/ sur Upcoming] est actuellement marquÃÂ© sous "fn org":
<pre><nowiki>
<div class="vcard">
<div class="fn org">Phone Boxes by the Sealife Centre</div>
<div class="adr">
<span class="street-address">Marine Parade</span><br />
<span class="locality">Brighton & Hove</span>,
<span class="region">England</span>
<span class="postal-code">BN2 1TB</span><br />
<span class="country">United Kingdom</span><br />
<span class="tel">01273 606674</span>
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>
Ceci pourrait ÃÂªtre marquÃÂ© comme :
<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="fn extended-address">Phone Boxes by the Sealife Centre</div>
<span class="street-address">Marine Parade</span><br />
<span class="locality">Brighton & Hove</span>,
<span class="region">England</span>
<span class="postal-code">BN2 1TB</span><br />
<span class="country">United Kingdom</span><br />
<span class="tel">01273 606674</span>
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>

===ProblÃÂ©matiques===
L'exemple au-dessus semble ÃÂªtre une solution ÃÂ©lÃÂ©gante, mais une variÃÂ©tÃÂ© plus grande d'exemples de pages publiÃÂ©es de la sorte sont demandÃÂ©es, pour ÃÂªtre certain que cela croise tous les scÃÂ©narios communs. Ceux-ci devraient inclure des cas dans lesquels "adr" n'est pas dÃÂ©jÃÂ utilisÃÂ© ; remarquez que dans ce cas un niveau supplÃÂ©mentaire d'imrication est exigÃÂ©. Les implications de cela, pour les hcards dÃÂ©jÃÂ publiÃÂ©s, devraient ÃÂªtre prises en considÃÂ©ration.

Aussi, que penser des hcards pour les endroits publiÃÂ©s, qui incluent dÃÂ©jÃÂ une "extended address" ?

par ex.

<pre><nowiki>
<div class="vcard">
<span class="fn org">Powell's Pool</span>
<span class="adr">
<span class="extended-address">Sutton Park</span>
<span class="locality">Birmingham</span>
<span class="country-name">England</span>
</span>
</div>
</nowiki></pre>

[[User:AndyMabbett|Andy Mabbett]] 05:40, 15 Dec 2007 (PST)

=== formats location nommÃÂ©s ===
Les efforts prÃÂ©cÃÂ©dents sur les formats de lieux nommÃÂ©s :

==== Simple GeoRSS featurename ====
Le vocabulaire [http://georss.org/simple GeoRSS simple] contient l'exemple suivant de lieu nommÃÂ© dans la section "Additional Properties" qui rÃÂ©fÃÂ©rence un <strong><code>featurename</code></strong> tag.

<blockquote><h3>Feature Type, Feature Name, and Relationship Tags</h3><p>The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.</p><pre><nowiki>
<georss:point>45.256 -110.45</georss:point>
<georss:featuretypetag>city</georss:featuretypetag>

<georss:relationshiptag>is-centered-at</georss:relationshiptag>

<georss:featurename>Podunk</georss:featurename>
</nowiki></pre></blockquote>

Une [http://www.google.com/search?q=site%3Ageorss.org%20featurename recherche sur featurename sur georss.org] ÃÂ©choue pour trouver d'autres rÃÂ©fÃÂ©rences, y compris une dÃÂ©finition.

Un [http://lists.eogeo.org/pipermail/georss/2006-December/000895.html email sur la liste georss datant de dÃÂ©c 2006] fait apparaÃÂ®tre le fil de notes "featurename, other missing bits from the site" qu'il existe "there is some updating to do" en rÃÂ©ponse ÃÂ la problÃÂ©matique que ces descriptions de "featurename" ne sont pas prÃÂ©sentes sur le GeoRSS Simple et sur le ModÃÂ¨le GeoRSS. GeoRSS GML ne fait aucune mention des propriÃÂ©tÃÂ©s non-gÃÂ©omÃÂ©triques."

== FN sÃÂ©mantique pseudo ==
Il existe beaucoup de sites (par ex. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) qui permettent ÃÂ l'utilisateur d'avoir '''ÃÂ la fois''' un login/handle/alias en plusieurs mots, '''et''' de ne pas montrer son ''vrai'' noms (fn, n, given-name, family-name etc.).

Pour les personnes reprÃÂ©sentÃÂ©es par les pages profil de ces sites, le mieux que nous puissions faire est de baliser leurs login/handle/alias sous leurs "nickname". Initialement, nous avions pensÃÂ© que de tels pseudos etc. n'ÃÂ©taient que des mots uniques et de ce fait nous avons crÃÂ©ÃÂ© [[hcard-fr#Optimisation_implicite_du_.22nickname.22|l'optimisation implicite du nickname]] en rapport, oÃÂ¹ vous pouvez baliser le pseudo sous un "fn" et faire qu'il soit automatiquement rÃÂ©glÃÂ© comme une valeur de propriÃÂ©tÃÂ© "nickname", et des valeurs vides poiur toutes les sous-valeurs "n".

Afin de gÃÂ©rer les pseudos en plusieurs mots, similaire ÃÂ [[hcard-fr#Info_Contact_Organisation|l'information de l'information dans la hCard]] la mÃÂ©thode suivante est proposÃÂ©e :

=== combinaison du "fn" et "nickname" ===
Du fait de l'utilisation potentielle de nicknames/handles/nomsutilisateurs en plusieurs mots dans le contenu publiÃÂ©s sur le Web (par ex. sur des sites comme [http://flickr.com Flickr] et [http://consumating.com/ Consumating]), hCard a un mÃÂ©canisme pour spÃÂ©cifier un "fn" en plusieurs mots qui est aussi un "nickname" sans affecter toutes les sous-propriÃÂ©tÃÂ©s "n" qui sont spÃÂ©cifiÃÂ©es autrement, et sous-entendant explicitement des valeurs par dÃÂ©faut pour les sous-propriÃÂ©tÃÂ©s "n".

Similaire ÃÂ [[hcard-fr#Optimisation_implicite_du_.22nickname.22|l'optimisation implicite du nickname]], si la propriÃÂ©tÃÂ© "fn" et une propriÃÂ©tÃÂ© "nickname" ont la mÃÂªme valeur exacte (typiquement parce qu'elles sont rÃÂ©glÃÂ©es sur le mÃÂªme ÃÂ©lÃÂ©ment, par ex. <code>class="fn nickname"</code>), alors

# Le contenu "fn" est traitÃÂ© comme la valeur de propriÃÂ©tÃÂ© "nickname".
# Les parseurs devraient gÃÂ©rer la propriÃÂ©tÃÂ© "n" manquante en sous-entendant les valeurs vides pour toutes les sous-propriÃÂ©tÃÂ©s "n".

== FN implicite ÃÂ partir de N ==
Parce que la propriÃÂ©tÃÂ© "n" est plus dÃÂ©taillÃÂ©e et structurÃÂ©e que la propriÃÂ©tÃÂ© "fn", et parce que les [[hcard-examples-in-wild-fr|exemples dans la jungle]] ont montrÃÂ© que trÃÂ¨s souvent ce qui est spÃÂ©cifiÃÂ© pour les sous-propriÃÂ©tÃÂ©s "n" est aussi spÃÂ©cifiÃÂ© pour la propriÃÂ©tÃÂ© "fn", nous pourrions ajouter l'optimisation implicite suivante qui permettrait aux sites de n'utiliser que "n" et ses sous-propriÃÂ©tÃÂ©s.

En outre, quelque sites n'ont pas du texte contigu et ininterrompu qui reprÃÂ©sente la valeur dÃÂ©sirÃÂ©e "fn", et aurait plutÃÂ´t le "fn" implicite ÃÂ partir des sous-propriÃÂ©tÃÂ©s "n". Par exemple, "Citizen Space Citizens" sur [[hcard-examples-in-wild-fr|hCard-exemples-dans-la-jungle]].

=== "fn" implicite ÃÂ partir de l'optimisation de "n" ===
Si une hCard n'a pas de "fn", et dispose d'une propriÃÂ©tÃÂ© "n" avec une ou plusieurs sous-propriÃÂ©tÃÂ©s, alors la valeur de la propriÃÂ©tÃÂ© "fn" peut ÃÂªtre tirÃÂ©e implicitement en concatÃÂ©nant les valeurs de la sous-propriÃÂ©tÃÂ© "n" comme suit, avec un espace entre chaque valeur de sous-propriÃÂ©tÃÂ©s, et plusieurs instances de sous-propriÃÂ©tÃÂ©.

* 'honorific-prefix'es (comme trouvÃÂ© dans l'ordre du document)
* 'given-name'
* 'additional-name's (comme trouvÃÂ© dans l'ordre du document)
* 'family-name'
* 'honorific-suffix'es (comme trouvÃÂ© dans l'ordre du document)

== N Implicite provenant de ses sous-propriÃÂ©tÃÂ©s ==
Le fait que les sous-propriÃÂ©tÃÂ©s "n" soient nommÃÂ©es suffisamment uniquement (ce qui veut dire, elles ne sont pas utilisÃÂ©es par toute autre propriÃÂ©tÃÂ© hCard), et que "n" est l'une des [[hcard-singular-properties-fr|propriÃÂ©tÃÂ©s singuliÃÂ¨res hcard]], il est possible de considÃÂ©rÃÂ©rer d'abandonner la propriÃÂ©tÃÂ© en elle-mÃÂªme "n" pour la hCard et simplement la rediriger en utilisant les sous-propriÃÂ©tÃÂ©s, telles que les propriÃÂ©tÃÂ©s de la hCard.

=== "n" implicite ÃÂ partir de ses sous-propriÃÂ©tÃÂ©s===
Si une hCard n'a ni propriÃÂ©tÃÂ©s "fn" ni "n", alors le champ entier de la hCard est considÃÂ©rÃÂ© pour ÃÂªtre ÃÂ l'intÃÂ©rieur et une propriÃÂ©tÃÂ© implicite "n".

par ex. ce marquage :
<pre><nowiki>
<span class="vcard">
<span class="given-name">Tantek</span>
<span class="family-name">ÃÂelik</span>
</span>
</nowiki></pre>
serait traitÃÂ© du point de vue d'un parsage comme :

<pre><nowiki>
<span class="vcard"><span class="n">
<span class="given-name">Tantek</span>
<span class="family-name">ÃÂelik</span>
</span></span>
</nowiki></pre>

Ce qui veut dire, avec l'optimisation '''"fn" implicite ÃÂ partir de optimisation "n" ''', serait alors en fait traitÃÂ©e comme :

<pre><nowiki>
<span class="vcard"><span class="fn n">
<span class="given-name">Tantek</span>
<span class="family-name">ÃÂelik</span>
</span></span>
</nowiki></pre>

* une requÃÂªte en rapport tirÃÂ©e de la liste de diffusion : http://microformats.org/discuss/mail/microformats-discuss/2007-September/010791.html

== Exemples ==
* Voir [[hcard-examples-fr|exemples hCard]], qui fournit plusieurs exemples illustrÃÂ©s instructifs, tout comme des exemples de hCard 1:1 pour chaque exemple dans la [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Utiliser la RFC2806 avec hCard ===
La [http://www.ietf.org/rfc/rfc2806.txt RFC 2806] dÃÂ©finit le schÃÂ©ma tÃÂ©lÃÂ©phone "tel:", "fax:" et "modem:" pour gÃÂ©rer les communications tÃÂ©lÃÂ©phoniques avec des URIs de la mÃÂªme faÃÂ§on que "mailto:" est dÃÂ©fini pour l'email. Cela fait partie de la liste des schÃÂ©mas enregistrÃÂ©s par IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

Il est pratique d'ÃÂ©crire votre numÃÂ©ro de tÃÂ©lÃÂ©phone comme ceci.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

ou mÃÂªme :

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Le tÃÂ©lÃÂ©phone de Monsieur BloÃÂ¯c</a>
</nowiki></pre>

Vous pouvez ajouter du support pour le "tel:" vers votre bureau et vers votre navigateur

* Pour Gnome, edit ~/.gnome/Gnome et ajoutez quelque chose ÃÂ la section vers les gestionnaires URL. (Dan Connolly utilise ÃÂ§a pour recevoir galeon afin de lancer telnum ÃÂ partir de [http://dev.w3.org/cvsweb/2001/telagent/ sources telagent] pour des URIs tel)
* Dans Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* Dans Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

Sur le front CSS... Vous pourriez ajouter par exemple automagiquement une icÃÂ´ne. J'ai mis la propriÃÂ©tÃÂ© !important pour ceux qui veulent l'ajouter ÃÂ leurs propres feuilles de style dans leurs navigateurs, ainsi ils connaissent les types de liens au moment de naviguer.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoder des attributs "modernes" ==
Depuis que la vCard a ÃÂ©tÃÂ© initialisÃÂ©e, diffÃÂ©rentes technologies interactives et schÃÂ©mas d'adressage ont ÃÂ©tÃÂ© largement adoptÃÂ©s. Bien qu'il n'y ait pas de propriÃÂ©tÃÂ©s spÃÂ©cifiques pour ces technologies / schÃÂ©mas d'adressage, elles peuvent ÃÂªtre capturÃÂ©es sous des URLs ou des adresses email.

Ceci a ÃÂ©tÃÂ© dÃÂ©sormais couchÃÂ© pour la plupart. Voir :

http://microformats.org/wiki/hcard-examples-fr#Nouveaux_Types_d.27Information_de_Contact

Restent ÃÂ rÃÂ©gler :

* les adresses iChat mac.com , stocker simplement "@mac.com" email addresses, par ex.
** <code><nowiki><a class="email" href="mailto:loic@mac.com">...</nowiki></code>
* MSN Instant Messenger, vous pouvez stocker de simples adresses email "@hotmail.com" ou "@msn.com" ou "@passport.com" email addresses.
* Internet Relay Chat (IRC), utilisez "irc:" URLs.

== Auto-DÃÂ©couverte ==
=== dÃÂ©couverte hCard reprÃÂ©sentative ===
Compte tenu d'une page comportant une ou plusieurs hCards, quelle hCard est la hCard reprÃÂ©sentative pour la page ?

Voir [[representative-hcard-fr|hCard-reprÃÂ©sentative]]

=== relations hCard vers hCard ===
Il existe plusieurs types de relations hCard vers hCard, ce qui veut dire, une hCard faisant un hyperlien vers une autre hCard qui pourrait bÃÂ©nÃÂ©ficier des valeurs rel explicites qui ont dÃÂ©crit la relation spÃÂ©cifique.

==== home page vers page contact ====
Bon nombre d'individus et d'organisations s'identifient eux-mÃÂªmes ÃÂ travers leurs URLs, et puis incluent une page sÃÂ©parÃÂ©e pour leur information de contact. Ceci est une pratique existante qui pourrait ÃÂªtre reprÃÂ©sentÃÂ©e avec des microformats.

Exemples :
* Ryan King, http://theryanking.com/ , http://theryanking.com/contact/
* Tantek ÃÂelik, http://tantek.com/ , http://tantek.pbwiki.com/ContactCard/
* Google, http://www.google.com/ , http://www.google.com/intl/fr/contact/index.html

Ces exemples pourraient ÃÂªtre traitÃÂ©s par le brainstorming suivant mini hCard vers hCard ÃÂ©tendue.

==== mini hCard vers hCard ÃÂ©tendue ====
Peut-ÃÂªtre que le type le plus commun du lien de hCard vers hCard, par ex. d'une page personnelle ou blog vers la page de contact de la personne/ÃÂ propos, peut-ÃÂªtre constituÃÂ©e de seulement un nom et un URL, qui pointe vers une hCard ÃÂ©tendue. Exemples dans la junge :

Dans cette instance, les valeurs rel possibles pourraient comprendre :
* rel="expanded"
* rel="definitive" - le problÃÂ¨me avec ÃÂ§a est que la hCard ÃÂ©tendue n'est pas nÃÂ©cessairement une version dÃÂ©finitive.
* rel="canonical" - de la mÃÂªme faÃÂ§on, la hCard ÃÂ©tendue n'est pas nÃÂ©cesairement un URL canonique. Ce peut simplement ÃÂªtre *une* version ÃÂ©tendue, pas *la* version ÃÂ©tendue.

Les valeurs rel qui suivent ont ÃÂ©tÃÂ© suggÃÂ©rÃÂ©es, mais ne sont vraiment pas une bonne idÃÂ©e du fait qu'elle sous-tendent une dÃÂ©pendance pour ajouter une nouvelle valeur rel pour n'importe quel nouveau microformat qui pourrait avoir une mini version pointant vers une version plus ÃÂ©tendue :
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Voici quelques valeurs plus gÃÂ©nÃÂ©riques qui ont ÃÂ©tÃÂ© suggÃÂ©rÃÂ©es et qui peut-ÃÂªtre font encore moins de sens :
* rel='microformat' - ceci ne fait aucun sens quand vous imaginez un monde oÃÂ¹ presque chaque page contiendra des microformats.
* rel='about' - qu'est-ce que "about" ÃÂ ÃÂ faire ÃÂ propos d'une personne ou mÃÂªme de la paternitÃÂ© d'auteur ?
* rel="profile" - devrait ÃÂªtre rÃÂ©servÃÂ© pour signifier qu'il y a ici un profil [[xmdp|XMDP]] pour la page en cours.
* rel='PIM' - pas sÃÂ»r de la maniÃÂ¨re dont cela puisse faire quelque sens.

==== mini hCard vers site distant ====
Selon les instructions trouvÃÂ©es dans [[hcard-examples-fr|hCard-exemples]] pour [[hcard-examples-fr# RÃÂ©fÃÂ©rences_aux_Personnes_dans_les_Blogrolls|baliser les personnes dans les blogrolls]], vous pourriez avoir une hCard de votre site pour une autre personne qui lie ensuite vers le site web de cette autre personne. Devrait-il y avoir une valeur rel qui indique cette "mini-hcard" pour la relation "person" ?

==== mini hCards et liens hCard ÃÂ©tendus ÃÂ proximitÃÂ© ====
Quelques auteurs incluent des mini-hCards sur leurs pages personnelles (par ex. dans leurs billets de blogs) et ÃÂ cette heure ces mini-hcards ne pointent pas vraiment vers des versions ÃÂ©tendues. NÃÂ©anmoins, parfois elles sont un lien sÃÂ©parÃÂ© mais ÃÂ proximitÃÂ© sur la mÃÂªme page comme "ÃÂ propos" ou "contact" qui lie vraiment vers une hCard ÃÂ©tendue.

Par ex. sur [http://factoryjoe.com/blog/ FactoryCity], les billets de blogs ont des mini-hcards pour "published by", ÃÂ savoir (espace blanc ajoutÃÂ© pour la lisibilitÃÂ©) :
<pre><nowiki>
Published by
<span class="vcard author">
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>
</span>
</nowiki></pre>

Sur ces mÃÂªme pages de blogs, il y a un lien ÃÂ©tiquetÃÂ© "Contact Information" qui lie vers http://factoryjoe.com/blog/hcard/ qui a une hCard avec plus d'informations comme le numÃÂ©ro de tÃÂ©lÃÂ©phone, l'anniversaire, etc.

=== Auto-DÃÂ©couverte pour XFN ===
Un auteur publiera gÃÂ©nÃÂ©ralement son information XFN sur une page spÃÂ©cifique, plutÃÂ´t que sur toutes les pages. En particulier, une page spÃÂ©cifique ÃÂ partir de la page d'accueil de son blog et par consÃÂ©quent ce serait utile d'avoir une valeur rel explicite pour aider ÃÂ l'auto-dÃÂ©couverte de l'information XFN.

Ceci fÃÂ»t suggÃÂ©rÃÂ© par Jens Alfke le 20050606 durant le dÃÂ®ner des blogueurs WWDC.

=== auto-dÃÂ©couverte lien vCard rel ===
Une possibilitÃÂ© similaire est un lien d'auto-dÃÂ©couverte dans l'en-tÃÂªte du document qui pourrait pointer vers une URL (peut-ÃÂªtre avac transformation) vers une version vCard de la hCard reprÃÂ©sentative.

Sur la page avec l'encodage hCard, le meilleur lien serait comme suit :

<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
cette page HTML est une vue alternative de la vCard.

Le [http://www.iana.org/assignments/media-types/text/ type appropriÃÂ© et enregistrÃÂ©] pour les entitÃÂ©s vCard est Ã¢ÂÂtext/directoryÃ¢ÂÂ, comme dÃÂ©fini dans la RFC 2425 Internet Ã¢ÂÂ[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]Ã¢ÂÂ. RFC 2426, Ã¢ÂÂ[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]Ã¢ÂÂ, spÃÂ©cifie le profil vCard pour les entitÃÂ©s Ã¢ÂÂtext/directoryÃ¢ÂÂ entities, que le profil champ header MIME/HTTP Ã¢ÂÂContent-TypeÃ¢ÂÂ indiquerait avec un paramÃÂ¨tre Ã¢ÂÂprofileÃ¢ÂÂ quelle valeur est Ã¢ÂÂVCARDÃ¢ÂÂ.

Il n'est pas clair si l'attribut HTML/XHTML Ã¢ÂÂtypeÃ¢ÂÂ permet des valeurs avec les paramÃÂ¨tres. Le 2004-05-23, [http://bjoern.hoehrmann.de/ BjÃÂ¶rn HÃÂ¶hrmann] a envoyÃÂ© au [http://www.w3.org/2002/05/html/charter HTML Working Group] une [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de demande de clarification] sur la problÃÂ©matique.

Quand on est sur une page diffÃÂ©rente, rÃÂ©fÃÂ©rencer cette page encodÃÂ©e dans le href ne serait ''pas'' une vue alternative de la page en cours. Par consÃÂ©quent rel="alternate" peut ne pas ÃÂªtre appropriÃÂ©. Le problÃÂ¨me de la valeur rel ÃÂ utiliser est plus grand que les liens vers les vCards.

== AmÃÂ©liorations geo ==
voir [[geo-brainstorming-fr|geo-brainstorming]]

== Autres cas d'utilisation ==
Ajoutez svp vos suggestions !
Le microformat hCard pourraient ÃÂªtre utilisÃÂ© pour :
* Calculer et afficher l'ÃÂ¢ge du sujet "ÃÂ la date du jour"
J'ai (Tantek) vu des exemples oÃÂ¹ il y a une prÃÂ©sentation visualisable / cliquable d'un point sur une carte et le dÃÂ©sir d'inclure l'information geo lisible par la machine avec le mÃÂªme ÃÂ©lÃÂ©ment, par ex. quelque chose comme :
* Calculer et afficher l'ÃÂ¢ge du sujet ÃÂ sa mort (si une [[hcard-date-of-death-fr|Date de DÃÂ©cÃÂ¨s]] est disponible)
* GÃÂ©nÃÂ©rer un iCal rÃÂ©current pour un anniversaire de sujet vivant
* GÃÂ©nÃÂ©rer un iCal rÃÂ©current pour un "anniversaire de naissance" d'un sujet dÃÂ©cÃÂ©dÃÂ© (si une [[hcard-date-of-death-fr|Date de DÃÂ©cÃÂ¨s]] est disponible)
...

== ProblÃÂ©matiques avec les Applications vCard ==
Voir [[vcard-implementations-fr|vcard-implÃÂ©mentations]].

== Questions Ouvertes ==

Q : parce que beaucoup des composants utiliseraient des classes CSS pour encoder les donnÃÂ©es, il est possible de MIXER deux profils diffÃÂ©rents. (par ex. hCard et XFN). Il n'y a pas de vÃÂ©ritables contraintes sur oÃÂ¹/comment exÃÂ©cuter les noms de classes, ceux-ci sont basÃÂ©s sur le profil html, parce qu'il est difficile d'associer le texte dans l'attribut vers un profil spÃÂ©cifique.

<pre><nowiki>
...
<a href="mailto:jean.dupont@exemple.com" class="fn" rel="met">Jean Dupont</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q : PrÃÂ©server l'Espace Blanc ? Les applications qui transforment devraient-elles prÃÂ©server les caractÃÂ¨res espaces blancs supplÃÂ©mentaires ? Par exemple :
<pre><nowiki>
<a href="http://monsiteweb.com/" class="fn n">
<span class="given-name">Jean</span>
<span class="other-names">Q.</span>
<span class="family-name">Public</span>
</a>
</nowiki></pre>

Quand c'est transformÃÂ© en une vCard, la propriÃÂ©tÃÂ© N piochera ÃÂ part les tags span et crÃÂ©era la valeur pour le N sÃÂ©parÃÂ©e correctement par des signes deux points (:). La propriÃÂ©tÃÂ© FN prendra une chaÃÂ®ne et l'affichera simplement. Il existe deux restitutions possibles pour FN :

<pre><nowiki>
Jean Q. Public

Jean
Q.
Public
</nowiki></pre>

Soit l'espace blanc est prÃÂ©servÃÂ© ou il ne l'est pas. Qu'est-ce que devraient restituter les applications transformates ?

-- [http://suda.co.uk/ Brian Suda]

R : L'application de parsage devrait suivre les rÃÂ¨gles d'ÃÂ©clatement de l'espace blanc du type mime qu'elle retrouve. Par ex. si elle trouve un document "text/html", elle devrait faire de la suppression d'espace blanc HTML.

-- [http://tantek.com/log/ Tantek]

Bon nombre des Questions et RÃÂ©ponses sont pertinentes pour ÃÂ la fois ["hCal"] et hCard.

Q : Qu'est ce qui serait appropriÃÂ© pour emballer le nom du propriÃÂ©taire de vCard avec <dfn/> ? Ceci peut donner ÃÂ la hCard quelque valeur ajoutÃÂ©e sÃÂ©mantique ÃÂ l'intÃÂ©rieur du document XHTML.
<pre><nowiki>
<span class="agent">
<span class="vcard">
<span class="email">
<a class="internet" href="mailto:jeanvendredi@truc.com">
<dfn>
<span class="fn">Jean Vendredi</span>
</dfn>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Administrateur Aire, Assistant</span>
</span>
</span>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

* Si la rÃÂ©ponse ÃÂ la question Q au-dessus est "oui", pouquoi ne pas utiliser ce qui suit ?
<pre><nowiki>
<dfn class="fn">Joe Friday</dfn>
</nowiki></pre>
ou
<pre><nowiki>
<span class="agent">
<dfn class="vcard">
<span class="email">
<a class="internet" href="mailto:jfriday@host.com">
<span class="fn">Joe Friday</span>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Area Administrator, Assistant</span>
</dfn>
</span>
</nowiki></pre>
Ceci marquerait la hCard entiÃÂ¨re comme l'"instance de dÃÂ©finition".

[[User:Bob Jonkman|Bob Jonkman]] 10:07, 13 Jul 2007 (PDT)

== Applications ==
Les Applications qui sont conscientes des hCards ou qui peuvent convertir les hCards en formats vCard.

=== favelet(s) de copie hCards ===
* Je pense qu'un Favelet fonctionnerait bien ici. Quand vous trouvez une page qui est compatible hCard, vous cliquez sur le favlet et vous obtenez vous-mÃÂªme une vCard. C'est fait ! Voir X2V dans la section des implÃÂ©mentations de la spec [[hcard-fr|hCard]].

=== IcÃÂ´nes distribuÃÂ©es de commentateurs ===
''L'URL en rÃÂ©fÃÂ©rence dans cette section n'est plus disponible. Les idÃÂ©es sur l'utilisation d'icÃÂ´nes sont nÃÂ©anmons toujours pertinentes."'' [[User:WilleRaab|WilleRaab]] 16:55, 23 Jul 2007 (PDT)
* Voir [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] pour un exemple de hCards utilisÃÂ©es pour les auteurs des commentaires (commentateurs). Le systÃÂ¨me utilisÃÂ© lÃÂ , "Gravatars", est un site centralisÃÂ© qui sert les icÃÂ´nes de commentateurs qui exige un login, etc.

Et si nous donnions ÃÂ chaque commentateur l'option d'hÃÂ©berger sa propre icÃÂ´ne ?

Une implÃÂ©mentation d'icÃÂ´ne de commentateur distribuÃÂ© pourrait fonctionner comme ÃÂ§a :

# Vu l'URL d'un commentateur, chercher un ÃÂ©lÃÂ©ment <code><address></code> avec le nom de classe "vcard" sur l'URL du commentateut. L'ÃÂ©lÃÂ©ment <code><address></code> est supposÃÂ© ÃÂªtre l'information de contact pour la page. (voir [[hcard-faq-fr|hCard FAQ]] pour plus d'infos), aussi cela fait du sens.
# Puis, chercher le premier ÃÂ©lÃÂ©ment dans cette hCard qui ait un nom de classe de "logo".
# En espÃÂ©rant que cet ÃÂ©lÃÂ©ment soit un <code><img></code>, et si oui, utiliser son src pour recevoir l'icone du commentateur.
# Basta. Vous avez des icÃÂ´nes de commentateurs distribuÃÂ©es !

== PrÃÂ©vention du Spam ==
hCard utilise les liens <code>mailto:</code> et par consÃÂ©quent, il hÃÂ©rite automatiquement des inconvÃÂ©nients des liens <code>mailto:</code> :
Ces liens peuvent ÃÂªtre facilement dÃÂ©tectÃÂ©s par les spiders d'email (utilisÃÂ© par les spammeurs).

Les adresses email sont piochÃÂ©es comme toute autre lien crawlÃÂ© par un moteur de recherche et les crawleurs de confiance peuvent ÃÂªtre dissuadÃÂ©s d'ajouter de l'emphase tout en indexant ces liens en incluant rel="nofollow" (Voir [[rel-nofollow-fr|rel-nofollow]]). NÃÂ©anmoins, les adresses email utilisÃÂ©es pour le spam sont crawlÃÂ©es par les spiders d'email qui ignoreront probablement cet attribut.

Il existe des moyens d'empÃÂªcher la dÃÂ©tection d'adresses email par les simples spiders d'email, tout en retenant une totale compatibilitÃÂ© avec les applications (X)HTML.
Un moyen commun est d'"encoder" le "m" de "mail" et "@" avec des entitÃÂ©s caractÃÂ¨res, ÃÂ ce stade c'est imprudent de suivre une convention de seulement encoder les caractÃÂ¨res spÃÂ©cifiques parce que les spiders email peuvent aussi piocher ÃÂ§a :

Exemple de lien original :
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Exemple de lien "encodÃÂ©" (avec l'ajout de rel-nofollow) :
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;exemple.com">john.smith&#064;exemple.com</a>
</nowiki></pre>

Les simples spiders email qui ne font pas le dÃÂ©codage d'entitÃÂ© caractÃÂ¨re ne pourront par consÃÂ©quent pas trouver votre adresse email.

''Note :'' Peut-ÃÂªtre qu'il y a ou aura des spiders email qui peuvent dÃÂ©coder les entitÃÂ©s, ainsi cette technique n'aidera que pour les spiders email de mauvaise qualitÃÂ©.

(Voir aussi : http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Autres mÃÂ©thodes de prÃÂ©vention ÃÂ considÃÂ©rer ===
* Utiliser un code cÃÂ´tÃÂ© serveur pour implÃÂ©menter les entitÃÂ©s caractÃÂ¨res au hasard
* Afficher l'adresse d'une faÃÂ§on pensÃÂ©e pour n'ÃÂªtre lisible que par des humains (de ce fait cassant le lien):
** Utiliser une image plutÃÂ´t que du texte (pourrait ÃÂªtre encore lu par les machines en utilisant un OCR)
** Utiliser un texte lisible par une machine qui charrie le besoin de l'ÃÂ©diter avant utilisation (par ex. SVP_PASDESPAM_nom@exemple_PASDESPAM.com)
* Utiliser un dÃÂ©cryptage javascript cÃÂ´tÃÂ© client d'une adresse cryptÃÂ©e (oblige ÃÂ avoir javascript)
* Pointer vers un formulaire email ou toute autre URL au lieu d'une adresse email

== Tutoriels ==
* Comment encoder les entrÃÂ©es hCard dans les logiciels de blogs connus.
* Bonnes raisons de publier votre hCard
** en tant qu'entreprise, faire que les personnes vous placent dans leurs carnets d'adresses, ainsi elles vous trouveront plus tard.
** en tant qu'entreprise avec une liste d'emails, faire que les personnes vous ajoutent (avec l'adresse email) ÃÂ leurs carnets d'adresses de faÃÂ§on ÃÂ ce que leurs listes d'emails fonctionne via le carnet d'adresses.

[http://www.elanceur.org/MicroFormats/StylezvoshCardsavecCSS.html Stylisez les hCards avec CSS] est un texte sur la maniÃÂ¨re d'utiliser CSS pour faire une prÃÂ©sentation amÃÂ©liorÃÂ©e de contenus des hCards.

== Parsage ==
Voir la page sÃÂ©parÃÂ©e [[hcard-parsing-fr|hCard parsage]] pour les rÃÂ¨gles actuelles de parsage de la hCard.

Ajoutez idÃÂ©es/propositions pour amÃÂ©liorer/ajouter au parsage hCard ici de cette section du brainstorming hCard, et assurez-vous d'inclure des URLs vers des exemples de hCards dans la jungle qui pourraient bÃÂ©nÃÂ©ficier des changements de rÃÂ¨gles de parsage.

=== Gestion HTML SÃÂ©mantique SupplÃÂ©mentaire ===
==== gestion ÃÂ©lÃÂ©ment <code>acronym</code> ====
Choix :
* Traiter explicitement <code>acronym</code> comme le mÃÂªme que <code>abbr</code>, selon la sÃÂ©mantique de l'attribut '<code>title</code>' sur <code>acronym</code> en particulier, comme dÃÂ©fini dans HTML4.01.
* Traiter explictement <code>acronym</code> comme le mÃÂªme que <code>span</code>, et dÃÂ©courager l'usage de <code>acronym</code>.

==== <code>input</code> element handling ====
Dans [[hcard-parsing-fr|parsage hCard]], j'ai dÃÂ©fini de la gesion de cas spÃÂ©ciaux pour plusieurs ÃÂ©lÃÂ©ments selon [[hcard-parsing-fr#plus_d'exceptions_sÃÂ©mantiques|plus d'exceptions sÃÂ©mantiques]], par ex. les propriÃÂ©tÃÂ©s textuelles sur l'ÃÂ©lÃÂ©ment <code>img</code> utilisent l'attribut 'alt'.

Un ÃÂ©lÃÂ©ment que j'ai oubliÃÂ© ÃÂ cette heure ÃÂ©tait l'ÃÂ©lÃÂ©ment <code>input</code>, spÃÂ©cifiquement <code><nowiki><input type="text"></nowiki></code>. Un autre que j'ai oubliÃÂ© ÃÂ©tait l'ÃÂ©lÃÂ©ment <code>textarea</code>.

La suggestion simple est d'ajouter le [[hcard-parsing-fr|parsage hCard]] suivant, spÃÂ©cifiquement ÃÂ la sous-section [[hcard-parsing-fr#toutes_propriÃÂ©tÃÂ©s|toutes propriÃÂ©tÃÂ©s]] :

* <code><input type="text" value="..."></code>: utilise la valeur de l'attribut 'value'. S'il n'y a pas d'attribut 'value' alors traiter la valeur comme vide. Les agents-utilisateurs interactifs {{must-fr}} utiliser la [http://www.w3.org/TR/html4/interact/forms.html#current-value valeur en cours] de l'ÃÂ©lÃÂ©ment.
** considÃÂ©rer d'autres saisies de types aussi (par ex. checkbox, radio, hidden) et spÃÂ©cifiez comme les parser.
* <code><textarea></code> :utilise les contenus texte de l'ÃÂ©lÃÂ©ment. Les agents-utilisateurs interactifs {{must-fr}} utiliser la the [http://www.w3.org/TR/html4/interact/forms.html#current-value valeur en cours] de l'ÃÂ©lÃÂ©ment.

[[User:Tantek|Tantek]]

==== auto-remplissage formulaires ====
Si vous allez sur un site qui a besoin de votre information de contact pour quelque chose, disons un site d'ecommerce pour l'encaissement, et si les champs de formulaire sont marquÃÂ©s avec la sÃÂ©mantique hCard comme au-dessus, alors peut-ÃÂªtre que nous pourrions considÃÂ©rer faire que cela puisse signifier "insÃÂ©rer ici votre hCard".

Les agents utilisateurs interactifs (par ex. [[operator-fr|Operator]] sur [[firefox-fr|Firefox]]) pourrait dÃÂ©tecter une telle sÃÂ©mantique "insÃÂ©rer ici votre hCard" dans les formulaires sur les pages, et vous laisser "prÃÂ©-remplir" avec votre info de hcard, et puis immÃÂ©diatement, nous avons un standard pour les auto-remplissages de formulaires, plutÃÂ´t que tous les hacks qui sont rentrÃÂ©s dans les navigateurs depuis 1999 (ÃÂ commencer par IE4.5/Mac qui j'en suis vraiment certain fÃÂ»t le premier ÃÂ produire des auto-remplisseurs de formulaire d'un formulaire complet avec un seul bouton ÃÂ presser - pas juste auto-complÃÂ©ter individuellement chaque champ de formulaire).

Evidemment cela ferait sens de construire dans des formulaires *existants* des fonctionnalitÃÂ©s d'auto-remplissage dans [[Firefox-fr|Firefox]] et [[IE-fr|IE]] et tout autre navigateur qui le supporte.

Pour en savoir plus ÃÂ ce propos, regardez le billet de blog 2007 [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] par David Baron, un employÃÂ© chez Mozilla.

De cette maniÃÂ¨re les nouveaux sites pourraient simplement se conformer au standard, plutÃÂ´t que de s'appuyer sur des hacks qui persent les valeurs label etc. et sous-tendent des choses et se trompent eux-mÃÂªmes parfois.

'''Avantages [[i18n-fr|i18n]]''' : les saisies de formulaires hCard seraient aussi plus internationaux, ÃÂ©vitant de ce fait pour chaque navigateur ÃÂ supposer quel est le champ "name" et "telephone" dans chaque langeu, ainsi ils peuvent produire des auto-remplissages de formulaires sur n'importe quel site quelle que soit la langue, pas juste l'anglais.

[[User:Tantek|Tantek]] 16:24, 23 Jul 2007 (PDT)

==== Discussion historique: ====

Fils clÃÂ© :
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Quelque part en rapport
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

Un rÃÂ©sumÃÂ© clÃÂ© :
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html

Les options discutÃÂ©es dans un systÃÂ¨me de saisie hypothÃÂ©tique de hCard apparaÃÂ®t cette heure ÃÂªtre :

1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Proposed markup:

<pre><nowiki>
<form class="vcard-input" ...>
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" />
<input type="text" class="family-name" name="last_name" />
</fieldset>
...
</form>
</nowiki></pre>

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Proposed markup:

<pre><nowiki>
<form ...>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Rob" />
<input type="text" class="family-name" name="last_name" value="Manson" />
</fieldset>
...
</div>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Scott" />
<input type="text" class="family-name" name="last_name" value="Reynen" />
</fieldset>
...
</div>
</form>
</nowiki></pre>

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

==== ProblÃÂ¨mes clÃÂ©/points de discussion ====
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
- ''Negative'' : this require adding a bit of special case to existing parsers to handle these elements
- ''Positive'' : this could help to enable uf based auto form filling
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
- ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. [[Operator]]) parse the loaded html not the dynamic DOM
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
- ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
- ''Examples''
- title select that lists mr/mrs/ms/dr/etc.
- checkboxes to choose which addresses to use
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
- Unworkable. Cannot require clientside javascript.
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields
- hypothetical comment assuming more complexity beyond.

[[User:RobManson|RobManson]]

=== multiple type parsing ===
* Multiple Type parsing / Type Optimization : La spec le permet, et la [[hcard-authoring-fr#Num.C3.A9ros_de_T.C3.A9l.C3.A9phone|publication de hCard]] dÃÂ©montre l'usage de plusieurs dÃÂ©signations de types pour une valeur unique de tel. La syntaxe utilisÃÂ©e dans les exemples de publication oÃÂ¹ chacun semble comme s'il pouvait devenir encombrant. Du fait qeu ces dÃÂ©signations de type soient toutes des chaÃÂ®nes uniques de 'mot' il peut ÃÂªtre possible d'implÃÂ©menter des rÃÂ¨gles supplÃÂ©mentaires de parsage pour plusieurs types dans le mÃÂªme ÃÂ©lÃÂ©ment HTML. GÃÂ©rer les dÃÂ©limiteurs peut ÃÂªtre un problÃÂ¨me [espace, virgule, etc?], et quelques-un des usages dans-la-jungle de plusieurs types auraient besoin d'ÃÂªtre repÃÂ©rÃÂ©s et examinÃÂ©s avant de considÃÂ©rer quelques rÃÂ¨gles supplÃÂ©mentaires de parsage le long de ces lignes [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]

=== parsage hyperlien fax et modem ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

=== composants nom ambigus ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR sans enfants===
Les parseurs (Operator, Tails, Presque Tous les Parseurs Universels de Microformats) s'attendent actuellement ÃÂ ce que <code>adr</code> ait une ou plusieurs sous-propriÃÂ©tÃÂ©s. Il n'est pas clair en partant de la spec hCard de savoir ce qui est obligatoire (bien que la RFC vCard l'exige) ; ni qu'il ne soit toujours possible pour un champ address dans un site web modÃÂ©lisÃÂ© (ou un CMS) d'ÃÂªtre dÃÂ©fini avec une telle granularitÃÂ©.

Regardez Wikipedia dont les gabarits ont souvent un champ "locale" ou "place" utilisÃÂ©s par exemple sur les gares de chemin de fer :

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" dans le modÃÂ¨le) est une '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" est un '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" est une '''city'''

De la mÃÂªme maniÃÂ¨re, le modÃÂ¨le Wikipedia pour les organisations, dans lequel une adresse de siÃÂ¨ge social "headquarters" (pour une entreprise par exemple) peut contenir une adresse postale partielle, ou juste une paire "city/county" ou "city/country" :

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

==== sous-propriÃÂ©tÃÂ© adr unique implicite ====
I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

==== sous propriÃÂ©tÃÂ©s adr implicites ====
Il peut ÃÂªtre possible pour les parseurs de parser les sous-propriÃÂ©tÃÂ©s adr ÃÂ partir d'une chaÃÂ®ne contigue adr. Ce serait une optimisation pour ÃÂ la fois [[adr-fr|adr]] et [[hcard-fr|hCard]].

Ce peut ÃÂªtre aussi bien trop difficile/complexe pour ÃÂªtre fiable ou inter-opÃÂ©rable, mais ÃÂ§a vaut la peine au moins de documenter ici nos considÃÂ©ration et analyses.

Exemples :

L'[http://www.ibm.com/contact/employees/us/ Annuaire des EmployÃÂ©s d'IBM] cherche les [http://www.ibm.com/contact/employees/servlets/lookup?country=us&language=en&search_country=all&lastname=Kaply&firstname=Michael retours de hCards avec la propriÃÂ©tÃÂ© "adr"] qui contient les donnÃÂ©es "locality" et "country-name" mais malheureusement sans ÃÂªtre marquÃÂ©e ainsi, par ex :

<pre><nowiki>
<td class="adr">Austin, USA</td>
</nowiki></pre>

Nous pourrions d'abord dÃÂ©finir un ordre canonnique sur la faÃÂ§on de parser les sous propriÃÂ©tÃÂ©s sÃÂ©parÃÂ©es par des virgules (et peut-ÃÂªtre dans certains cas les espaces) dans une chaÃÂ®ne adr par ex :

* 'post-office-box'
* 'street-address'
* 'extended-address'
* 'locality'
* 'region'
* 'postal-code'
* 'country-name'

Given a dictionary of country names and abbreviations, it may be feasible to parse for a country name at the end of the adr string, and then apply country/locale specific parsing rules to the rest of the adr string.

E.g.
* from a theoretical dictionary of country names:
** US|USA|United States|United States of America|Etats-Unis d'Amerique
* parse the remainder of the adr string backwards as follows:
** preceding that, look for a 5 or 9 digit (with optional dash '-' separator between digits 5 and 6) postal-code, and if found use it for the 'postal-code'
** preceding that, look for the name of a US state (e.g. California or any of the other states or territories available from a canonical list) or 2 letter state abbreviation (e.g. CA), and if found use it for the 'region' subproperty
** preceding that, look for the name of a US city (e.g. San Francisco, Los Angeles or any other US city available from a canonical list) or common city abbreviation (e.g. SF, LA), and if found use it for the 'locality'
** preceding that, look for common extended address details, such as: #|apt|apartment|suite|ste followed by a word consisting of letters and numbers, and if found use it for the 'extended-address'
** preceding that, look for a common street name bracketed by the street number (an integer with optional fraction and/or letter), and an optional street type (av|ave|avenue|blvd|boulevard|cir|circle|pl|place|st|street), and if found use it for the 'street-address'
** preceding that, look for a common post office box, with the pobox literal string: pob|pobox|PO Box followed by a word consisting of numbers and letters, and if found use it for the 'post-office-box'
* ... other countries

The above heuristic (not quite well specified enough to be an algorithm, yet) would allow parsing of the IBM Employee Directory result documented above.

There are a lot of existing geocoder APIs that turn unstructured addresses into structured ones - we should examine these for patterns and best practices. eg [http://www.google.com/apis/maps/documentation/#Geocoding_Structured Google's geocoder] [http://exogen.case.edu/projects/geopy/ geopy calls multiple ones]

==== adr sans enfants FAQ ====
I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty)

Q: What should a parser do with an "adr" property lacking any subproperties?

A: A parser SHOULD do nothing with such an "adr" property. A parser MAY provide the text content of such an "adr" property in the results of its parsing as a freeform value of the "adr" property. Note that the vCard standard does not allow for any such freeform value of its "adr" property (in vCard the "adr" property MUST be structured) and thus that MAY suggestion to parsers only applies in situations (such as APIs, JSON return values) where it is possible to return a freeform value for the "adr" property.

[[User:Tantek|Tantek]] 09:20, 2 Aug 2007 (PDT)

== Rappels Anniversaire ==
*Les consommateurs de hCard pourraient calculer l'ÃÂ¢ge en cours des sujets hCard, ÃÂ partir de la date de naissance. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*pour les hCards avec Date de Naissance, les clients hCard pourraient gÃÂ©nÃÂ©rer et exporter un hCalendar rÃÂ©current. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**SI /quand la [[hcard-date-of-death-fr|Date de DÃÂ©cÃÂ¨s]] est ajoutÃÂ©e ÃÂ hCard, les parseurs pourraient gÃÂ©nÃÂ©rer ÃÂ la place un hCalendar rÃÂ©current "anniversaire de la mort". [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)

== Ajouts Post vCard ==
Conserver les propriÃÂ©tÃÂ©s et valeurs de la hCard comme une reprÃÂ©sentaiton 1:1 des propriÃÂ©tÃÂ©s et valeurs de la vCard a de nombreux avantages comme la simplicitÃÂ©, la stabilitÃÂ©, l'interopÃÂ©rabilitÃÂ© avec le grand nombre d'applications vCard existantes etc.

NÃÂ©anmoins certains ont trouvÃÂ© la vCard limitÃÂ©e en termes de donnÃÂ©es/propriÃÂ©tÃÂ©s/champs qu'ils veulent exprimer dans l'information de contact. Quelques implÃÂ©mentations utilisent les extensions vCard pour exprimer une telle information (citation demandÃÂ©e).

Cette section est pour documenter de telles additions suggÃÂ©rÃÂ©es. L'ÃÂ©vidence empirique d'exemples vÃÂ©ritables venant du *vrai monde* sur le Web de personnes publiant cette information serait un bon pas en avant pour de considÃÂ©rer de tels ajouts/extensions.

* '''altitude'''. En provenance [[hcard-issues-fr|problÃÂ©matiques hCard]].
**Voir [[geo-elevation-examples-fr]]
* '''vat-number''' : pour les numÃÂ©ros de TVA des sociÃÂ©tÃÂ©s, qui sont beaucoup utilisÃÂ©s en Europe et ont besoin d'ÃÂªtre publiÃÂ©s sur les publications belges (y compris les sites web).

* '''gender'''
** Voir [[vcard-suggestions-fr#Genre]]

* '''date-of-death'''
** Voir [[hcard-date-of-death-fr|Date de DÃÂ©cÃÂ¨s]]

par consÃÂ©quent regarder (et ajouter ÃÂ ): [[vcard-suggestions-fr|vcard-suggestions]]

Un autre chemin ÃÂ considÃÂ©rer est le dÃÂ©veloppement d'un autre microformat qui inclut une hCard et puis l'augmente avec des propriÃÂ©tÃÂ©s supplÃÂ©mentaires pour un domaine particulier. Dans beaucoup de sens [[hresume-fr|hResume]] a dÃÂ©jÃÂ fait ÃÂ§a. D'autres efforts en rapport :
* [[genealogy-fr|genealogy]]
* [[profile-fr|profile]]

Utiliser la hCard comme un bloc de construction stabel pour des microformats supplÃÂ©mentaires peut sembler plus souhaitable que de faire croÃÂ®tre incrÃÂ©mentalement la hCard elle-mÃÂªme.

Bien sÃÂ»r si la vCard ÃÂ©tait ÃÂ©tendue en elle-mÃÂªme, ceci peut fournir l'impulsion pour ajouter de telles extensions ÃÂ hCard afin de de maintenir l'ÃÂ©quivalence 1:1 de la reprÃÂ©sentation des propriÃÂ©tÃÂ©s/valeurs.

==DonnÃÂ©es de Personnes de Wikipedia==
[http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] sur la Wikipedia anglo-saxonne est trÃÂ¨s proche de hCard, mais a des champs supplÃÂ©mentaires de dates et lieux de naissance. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==
* Le [[hcard-profile-fr|hCard-profil]] a besoin de vÃÂ©rification et peut-ÃÂªtre d'une URL pour retrouver le XMDP vÃÂ©ritable, plutÃÂ´t qu'un texte sous <pre> sur une page wiki.
* ComplÃÂ©tez la traduction des exemples provenant de la spec vCard en hCard, et placez les sur une page sÃÂ©parÃÂ©e d'exemples.
* CrÃÂ©er un exemple "riche" mais rÃÂ©aliste de hCard, disons par exmple pour un vendeur, qui veut placer tout un paquet d'information de contacts sur son site web afin de pouvoir les retrouver/contacter aisÃÂ©ment.
* Fournir des exemples sur la maniÃÂ¨re d'encode les comptes de Messagerie InstantanÃÂ©e. Imaginer ce que serait les URLs mailto: ou aim: dans la hCard et comment cela apparaÃÂ®tra dans la vCard. Et jetez un oeil ÃÂ ce que les appliations vCard font aujourd'hui des messageries instantanÃÂ©es.
* Clarifier les dÃÂ©clarations contradictoires de copyright, selon http://microformats.org/discuss/mail/microformats-discuss/2007-July/010243.html

== Styles CSS ==
Non seulement vous pouvez crÃÂ©er de la sÃÂ©mantique avec les valeurs hCard, mais pouvez y ajouter des styles CSS ÃÂ volontÃÂ©. Vous ÃÂªtes libre de styler les termes comme vous voulez, mais ici nous pouvons lister quelques idÃÂ©es sur la faÃÂ§on de styler les termes.

Si vous voulez encoder des donnÃÂ©es hCard, mais ne voulez PAS l'afficher dans le code HTML (ATTENTION : ceci est vraiment NON RECOMMANDE, et gÃÂ©nÃÂ©ralement contre le principe microformats de marque de la donnÃÂ©e visible), alors vous pouvez cacher ce tag en CSS avec le code suivant :
<pre><nowiki>
<span style="display: none">DonnÃÂ©e CachÃÂ©e</span>
</nowiki></pre>
Les applications de transformation trouveront encore la donnÃÂ©e et l'utiliseront au moment de convertir les hCards en vCards.

== Autres ImplÃÂ©mentations/IdÃÂ©es ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.
* [http://microid.org/ MicroID in hCard]

== Suggestions AcceptÃÂ©es ==

=== Encoder les donnÃÂ©es de SociÃÂ©tÃÂ©s sous une Business Card ===

( AcceptÃÂ© [[hcard-fr#Info_Contact_Organisation|hCard Info Contact Organisation]] )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Optimisation Implicite "FN et N" ===

A cette heure, un parseur cherche d'abord un ÃÂ©lÃÂ©ment "n".

Et ensuite si "n" n'est pas prÃÂ©sent, il chercher un ÃÂ©lement "fn" ÃÂ utiliser pour tirer implicitement un ÃÂ©lÃÂ©ment "n" selon les rÃÂ¨gles de la "propriÃÂ©tÃÂ© n implicite" dans la spÃÂ©c.

HISTORIQUE :

Du fait de la prÃÂ©valence de l'usage de "nicknames" ou "pseudos" sur le Web, dans le vÃÂ©ritable contenu publiÃÂ© sur le Web (par ex. les auteurs de critiques), il y a eu une discussion ÃÂ propos de l'ajout d'un raccourci "fn" au raccourci "n" qui utilisait le "nickname" comme solution de repli.

PROPOSITION :

Nous devrions imaginer ajouter une ou plusieurs optimisations implicites aprÃÂ¨s les ÃÂ©tapes documentÃÂ©s au-dessus et c'est :

Si aucun "fn" n'est prÃÂ©sent, alors chercher un ÃÂ©lÃÂ©ment "nickname" ÃÂ utiliser pour sous-tendre ÃÂ la fois le "fn" et le "n/given-name", en laissant vide le "n/family-name".

Ceci permettrait des hCards uniquement avec "nickname" pour indiquer l'individu sur un site web, ce qui est tout ÃÂ fait commun sur les blogs et critiques publiÃÂ©s sur le web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note : plusieurs nicknames alternatifs devraient ÃÂªtre aussi permis
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== tel work implicite ==

=== ProblÃÂ¨me ===

Some phone numbers are not always documented of type 'work'. The type 'work' is usually implied from context.

=== Exemples dans la jungle ===

[[http://www.nvidia.com/page/contact_information.html NVidia contact information]]

Only 'Tel' is specified. The fact that it is of type 'work' can be assumed from the context: the name of an organization is present.

<pre>
<P><B>NVIDIA CORPORATE OFFICE:</B> <BR>
2701 San Tomas Expressway<BR>
Santa Clara, CA 95050<BR>
Tel: 408-486-2000<BR>

Fax: 408-486-2200<BR>
...
</P>
</pre>

[[http://www.supermarketguru.com/page.cfm/369 Supermarketguru.com]]

<pre>
<p>
<font face="Verdana, Helvetica, Arial" size=2>
<b>Phil Lempert:</b> <a href="mailto:plempert@supermarketguru.com">plempert@supermarketguru.com</a><br>
</font>
<font face="Verdana, Helvetica, Arial, sans-serif" size=2>SupermarketGuru.com<br>
3015 Main Street, Suite 320<BR>Santa Monica, California 90405<br>
Telephone: 323-860-3070
</font>
</p>
</pre>

Here only 'Telephone:' is specified, a FN is present ('Phil Lempert') but because an ORG is present ('SupermarketGuru.com'), it can be safely implied that '323-860-3070' is a tel or type work.

=== Proposition ===

If an ORG is present in a VCARD, a TEL with no TYPE has an implied TYPE 'work'

==== Commentaires ====
* Though it may be safe to make that assumption for the given example (and though it might have been wise to make this rule from the outset), we now can't know that it will alwyas be safe to do so, for all pre-existing hCards. Consider people whose organisation represents voluntary work, honorary roles and so forth. [[User:AndyMabbett|Andy Mabbett]] 00:33, 8 Jan 2008 (PST)

== Suggestions rejetÃÂ©es ==

Suggestion : ''L'utilisation de class="url" sur une balise <a> pour reprÃÂ©senter une propriÃÂ©tÃÂ© URL hCard est redondante. Par la vertu de la balise <a> vous savez que c'est une URL.''

RejetÃÂ©. Ceci est une mauvaise suggestion du fait que bien qu'elle semble rÃÂ©duire la redondance et garder les choses plus propres, elle crÃÂ©e aussi quelques problÃÂ¨mes. Sans faire remarquer explicitement que c'est une URL alors n'importe quels tags <a> dans une 'vcard' seraient considÃÂ©rÃÂ©es comme une URL, par exemple :
<pre><nowiki>
<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>
</nowiki></pre>

Il n'y a pas moyen de "dÃÂ©sactiver" l'encodage de l'URL W3C, tandis que si "url" requis avait beoin d'ÃÂªtre listÃÂ© explicitement dans liste d'attribut de classe, alors en ne listant PAS elle pourrait ÃÂªtre en fait dÃÂ©sactivÃÂ©e..

== RÃÂ©fÃÂ©rences ==
=== RÃÂ©fÃÂ©rences Normatives ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]

=== RÃÂ©fÃÂ©rences Informatives ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

== Pages en rapport ==
{{hcard-related-pages-fr}}

Microformats Wiki - User contributions [en]

hcard-brainstorming-fr