hcard-brainstorming-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
 
(64 intermediate revisions by 6 users not shown)
Line 1: Line 1:
<h1> hCard Brainstorming </h1>
<h1> hCard Brainstorming </h1>
Cette page est pour brainstormer sur les différentes utilisation et les détails de [[hcard-fr|hCard]].
{{TOC-right}}
 
Cette page est pour brainstormer sur les différentes utilisation et les détails de [[hcard-fr|hCard]].
__TOC__
Cette page contient des <em>propositions</em>. Pour l'état actuel, regardez svp [[hcard-fr|hCard]].
 
== Auteurs ==
== Auteurs ==
* [http://suda.co.uk/ Brian Suda]
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]
* [http://tantek.com/log/ Tantek Çelik], précédemment chez [http://technorati.com Technorati, Inc]


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


== Problèmes Etant Résolus ==
== Problèmes Etant Résolus ==
Quelques-uns des problèmes que [[hcard-fr|hCard]] aide à résoudre :
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).
* 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.
* "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&nbsp;locality" ou "fn&nbsp;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 &amp; 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 &amp; 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>
    &lt;georss:point&gt;45.256 -110.45&lt;/georss:point&gt;
    &lt;georss:featuretypetag&gt;city&lt;/georss:featuretypetag&gt;
    &lt;georss:relationshiptag&gt;is-centered-at&lt;/georss:relationshiptag&gt;
    &lt;georss:featurename&gt;Podunk&lt;/georss:featurename&gt;
</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 ==
== 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].
* 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 ===
=== 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]
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]


Line 41: Line 197:


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


Line 47: Line 203:


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


Line 69: Line 225:


== Encoder des attributs "modernes"  ==
== 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.
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.


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


Reste à régler :  
Restent à régler :  


* les adresses iChat mac.com , stocker simplement  "@mac.com" email addresses, par ex.
* les adresses iChat mac.com , stocker simplement  "@mac.com" email addresses, par ex.
Line 83: Line 238:
* Internet Relay Chat (IRC), utilisez "irc:" URLs.
* Internet Relay Chat (IRC), utilisez "irc:" URLs.


== Styles CSS ==
Non seulement vous pouvez créer une sémantique avec les valeurs hCard, mais vous pouvez tout aussi bien ajouter des styles CSS. Vous êtes libre de styler les termes avec les valeurs de hCard, mais ici vous pouvez 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, alors vous pouvez cacher ce tag dans la CSS avec le code suivant :
<pre><nowiki>
<span style="display: none">Donnée Cachée</span>
</nowiki></pre>
Les applications de transformation trouveront encore les données et les utiliseront au moment de convertir les hCards en vCards.


== Auto-Découverte ==
== Auto-Découverte ==
=== vCard auto extraction ===
=== découverte hCard représentative ===
Il existe actuellement un débat sur la meilleure façon d'ajouter un lien d'autodécouverte vers votre HTML pour extraire la vCard.
Compte tenu d'une page comportant une ou plusieurs hCards, quelle hCard est la hCard représentative pour la page ?


Sur la page avec l'encodage hCar, le meilleur lien serait comme suit :
Voir [[representative-hcard-fr|hCard-représentative]]


<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
=== relations hCard vers hCard  ===
cette page HTML est une vue alternative de la vCard.
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.


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”.  
==== 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.


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.
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


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.
Ces exemples pourraient être traités par le brainstorming suivant mini hCard vers hCard étendue.
 
=== hCard vers les relations hCard ===
 
Il existe plusieurs type de relations hCard vers hCard, ce qui veut dire, une hCard hyperliant vers une autre hCard qui bénéficierait des valeurs rel explicites décrites dans la relation spécifique.


==== 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 :
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 :


Line 138: Line 283:


==== mini hCards et liens hCard étendus à proximité ====
==== mini hCards et liens hCard étendus à proximité ====
Quelques auteurs incluent des mini-hCards sur leurs pages personnelles (cad 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.
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", e.g. (espace blanc ajouté pour la lisibilité) :
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>
<pre><nowiki>
Published by  
Published by  
Line 150: Line 295:
</nowiki></pre>
</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'information comme le numéro de téléphone, l'anniversaire, etc.
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 ===
=== 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.
Un auteur aura 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 explicit 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.
Ceci fût suggéré par Jens Alfke le 20050606 durant le dîner des blogueurs WWDC.


==améliorations geo ==
=== 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.


Ces améliorations s'appliquent tant à [[geo-fr|geo]] qu'à [[hcard-fr|hCard]].
Sur la page avec l'encodage hCard, le meilleur lien serait comme suit :


I (Tantek) have seen examples of where there is a human viewable/clickable presentation of a point on a map, and the desire to include the machine readable geo information with the same element, e.g. something like:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
cette page HTML est une vue alternative de la vCard. 


<pre><nowiki>
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”.
<abbr class="geo" title="machine-readable-geo-info">
human readable/clickable point on a map
</abbr>
</nowiki></pre>


But to do this we must specify a syntax for putting both the latitude and longitude into the title attribute as the machine-readable-geo-info.
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.


Fortunately, there already is a syntax for that, in vCard RFC 2426 3.4.2:
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.
<pre>
  Type value: A single structured value consisting of two float values
  separated by the SEMI-COLON character (ASCII decimal 59).


  Type special notes: This type specifies information related to the
== Améliorations geo ==
  global position of the object associated with the vCard. The value
voir [[geo-brainstorming-fr|geo-brainstorming]]
  specifies latitude and longitude, in that order (i.e., "LAT LON"
  ordering).


== 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)
...
...
  Type example:
        GEO:37.386013;-122.082932
</pre>
Thus:
<pre><nowiki>
<abbr class="geo" title="37.386013;-122.082932">
Mountain View, CA
</abbr>
</nowiki></pre>
I think this is pretty much a no-brainer, because the rules for parsing "geo" are simply altered to:
=== latitude longitude raccourci ===
If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property  (e.g. following rules for parsing <code><nowiki><abbr title></nowiki></code>, <code><nowiki><img alt></nowiki></code> etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order.
=== geo liens ===
In addition, people may publish Google Maps links like this:
<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>
(N.B. I tried and failed to get Yahoo Maps and local to do something intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").
Is it worth permitting this to be a geo as well?
I'm raising this to make sure it is considered.
However, my first guess is NO for two reasons.
# No such examples in the wild have been documented or seen as of yet (I certainly haven't seen any).
# It would involve additional parsing requirements which are almost certainly going to be site/domain specific, and encoding a particular site's query parameter syntax into a format seems like a bad idea (against principle of decentralization). 
This could be mitigated if mapping services would simply accept the literal vCard GEO syntax "37.386013;-122.082932", e.g. http://maps.google.com/maps?q=37.386013;-122.082932 (which currently doesn't work) then we could make a simple rule such as for hyperlinks, parse the href attribute for a geo value at the end of the href, delimited before the value by a "=" (or perhaps "/" for services that use friendlier URLs).
* consider also <a href="http://www.rhaworth.myby.co.uk/oscoor_a.htm?SJ870099_region:GB_scale:25000" title="52.6866;-2.1937">SJ870099</a> which is widely used (so far without geo-title attribute) (Wikipedia, et al). Perhaps we should also support ''title="various maps of 52.6866;-2.1937"'' so that the title attribute can be used as was originally intended.
=== altitude ===
Quelques types ont demandé "altitude" comme une extension pour GEO. Actuellement, nous rejetons toutes les extensions propriété/valeur vers hCard/vCard.
=== radius/zoom ===
Kevin Marks a demandé "radius" ou "zoom" comme une extension pour GEO.  Actuellement nous rejetons toutes les extensions propriétés/valeurs vers hCard/vCard.
=== ISO 19136 ===
When it comes to anything geospatial, any unadorned / simple encoding must remain upwardly-compatible with the more sophisticated GML schema (Geography Markup Language ) which is also known as ISO 19136.  This is so that all the fundamental nuances underpinning geocoding ( different datums, different projections, elevation, etc etc ) can ultimately ( or sooner ? ) be completely accounted for.
If you don't know/supply your Coordinate Reference System CRS identifier, your location could fall 100s of metres away from the position intended ie plot in the wrong location on a map.  Appendix B of draft ISO/DIS 6709 highlights the variation among three commonly used systems.
=== ISO/DIS 6709 ===
Draft International Standard [http://en.wikipedia.org/wiki/ISO_6709 ISO/DIS 6709] specifies the standard representation of geographic point location by coordinates.  Section 6.3 notes the elements required required for geographic point location:
<blockquote>
In this International Standard, geographic point location shall be represented by five elements:
* a coordinate reference system identification;
* coordinate representing “x” horizontal position such as latitude;
* coordinate representing “y” horizontal position such as longitude;
* for three-dimensional point locations, a value representing vertical position through either height or depth;
* metadata associated with geographic point location(s) (ISO 19115)
</blockquote>
Annex H details the ISO standard for text string representation of point location.
H.6 Format
H.6.1 Elements shall be combined in a point location string in the following sequence:
a) Latitude
b) Longitude
c) if represented, height or depth
d) Coordinate Reference System identifier
H.6.2 The number of digits for latitude, longitude and height (depth) shall indicate the precision of available
data.
H.6.3 There shall be no separator between the elements for latitude, longitude, height (depth) and CRS.
NOTE The use of designators "+", "-" and "CRS" preceding the value part of each element permits the recognition of
the start of each element and the termination of the previous one.
H.6.4 The point location string shall be terminated. The terminator character shall be a solidus (/), unless
otherwise specified in the documentation associated with interchange.
It differs from the notation of vCard, for example.
If ISO6709 is used, it is likely to be able to write as follows.
<pre><nowiki>
examples
<abbr class="geo" title="+40-075CRSxxxx/">
Point represented as Degrees
</abbr>
<abbr class="geo" title="+401213.1-0750015.1+2.79CRSxxxx/">
Point represented as Degrees, minutes, seconds and decimal seconds, with +2.79 a height or depth as defined through the CRS.
</abbr>
</nowiki></pre>
=== ISO 19115 ===
ISO 19115:2003 defines the schema required for describing geographic information and services. It provides information about the identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data.
=== Geospatial Metadata ===
Geospatial metadata 'place category features' would enable map mashups of microformatted information, for example, show me a map of the nearest place of worship and associated disabled carparks.
http://www.linz.govt.nz/resources/esa-appl-schema-v1-9-5/esa-46.html#1804


== Problématiques avec les Applications vCard ==
== Problématiques avec les Applications vCard ==
Line 305: Line 334:
== Questions Ouvertes ==
== Questions Ouvertes ==


Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.  
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>
<pre><nowiki>
...
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
<a href="mailto:jean.dupont@exemple.com" class="fn" rel="met">Jean Dupont</a>
...
...
</nowiki></pre>
</nowiki></pre>
Line 315: Line 344:
-- [http://suda.co.uk/ Brian Suda]
-- [http://suda.co.uk/ Brian Suda]


Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
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>
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
<a href="http://monsiteweb.com/" class="fn n">
     <span class="given-name">John</span>
     <span class="given-name">Jean</span>
     <span class="other-names">Q.</span>
     <span class="other-names">Q.</span>
     <span class="family-name">Public</span>
     <span class="family-name">Public</span>
Line 324: Line 353:
</nowiki></pre>
</nowiki></pre>


When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
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>
<pre><nowiki>
John Q. Public
Jean Q. Public


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


Either the white-space is preserved or it is not. Which should the transforming applications render?
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]
-- [http://suda.co.uk/ Brian Suda]


A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.
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]
-- [http://tantek.com/log/ Tantek]


Many of the Questions and Answers are relevant to both ["hCal"] and hCard.
Bon nombre des Questions et Réponses sont pertinentes pour à la fois ["hCal"] et hCard.


Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
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>
<pre><nowiki>
<span class="agent">  
<span class="agent">  
  <span class="vcard">
  <span class="vcard">
   <span class="email">
   <span class="email">
   <a class="internet" href="mailto:jfriday@host.com">
   <a class="internet" href="mailto:jeanvendredi@truc.com">
     <dfn>
     <dfn>
       <span class="fn">Joe Friday</span>
       <span class="fn">Jean Vendredi</span>
     </dfn>
     </dfn>
   </a>
   </a>
   </span>
   </span>
   <span class="tel">+1-919-555-7878</span>
   <span class="tel">+1-919-555-7878</span>
   <span class="title">Area Administrator, Assistant</span>
   <span class="title">Administrateur Aire, Assistant</span>
  </span>
  </span>
</span>
</span>
</nowiki></pre>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]
-- [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 ==
== Applications ==
Line 368: Line 421:


=== Icônes distribuées de commentateurs ===
=== 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.
* 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.


Line 406: Line 459:


=== Autres méthodes de prévention à considérer ===
=== Autres méthodes de prévention à considérer ===
* Using server-side code to implement character entities randomly
* Utiliser un code côté serveur pour implémenter les entités caractères au hasard
* Displaying the address in a way thought to be only human readable (thus breaking the link):
* Afficher l'adresse d'une façon pensée pour n'être lisible que par des humains (de ce fait cassant le lien):
** Using an image instead of text (could still be machine readable using OCR)
** Utiliser une image plutôt que du texte (pourrait être encore lu par les machines en utilisant un OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
** Utiliser un texte lisible par une machine qui charrie le besoin de l'éditer avant utilisation (par ex. SVP_PASDESPAM_nom@exemple_PASDESPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Utiliser un décryptage javascript côté client d'une adresse cryptée (oblige à avoir javascript)
* Pointing to an email form or other URL instead of an email address
* Pointer vers un formulaire email ou toute autre URL au lieu d'une adresse email


== Tutoriels ==
== Tutoriels ==
* How to hCard encode entries in Popular blog software.
* Comment encoder les entrées hCard dans les logiciels de blogs connus.
* Good reasons to publish your hCard
* Bonnes raisons de publier votre hCard
** as a business, get people to put you in their address book so they'll find you later
** en tant qu'entreprise, faire que les personnes vous placent dans leurs carnets d'adresses, ainsi elles vous trouveront plus tard.
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.
** 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 ==
== Parsage ==
Voir la page séparée [[hcard-parsing-fr|parser hCard]].
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>.


== additions aux Post vCard  ==
==== <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'.


Quelques personnes ont trouvé la vCard limitée en termes de données/propriétés/champs qu'elles voulaient exprimer dans l'information de contact. Quelques implémentations utilisent les extensions vCard pour exprimer de telles informations.
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>.


Cette section est pour la documentation de telles additions suggérées. Remarquez que nous aurons besoin d'évidence empirique d'exeples véritables venant du *vrai monde* sur le Web de personnes publiant cette information comme une partie de l'information de contact, avant de considérer de telles ajouts/extensions.
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]] :


* altitude. Extrait de [[hcard-issues-fr|hcard-problématiques]].
* <code>&lt;input type="text" value="..."&gt;</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.
** Aucune évidence fournie que l'information de contact sur le Web publie cette information.
** considérer d'autres saisies de types aussi (par ex. checkbox, radio, hidden) et spécifiez comme les parser.
* <code>&lt;textarea&gt;</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]]


== TODO ==
==== 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?


* Le [[hcard-profile-fr|profil hCard]] a besoin de vérification et peut-être d'un URL pour retrouver le véritable XMDP, plutôt qu'un texte &lt;pre&gt; sur une page wiki.
==== Problèmes clé/points de discussion ====
* Compléter la traduction des exemples extraits de la spec vCard dans hCard, et la placer sur une page séparé d'exemples de hCard.
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
* Créer un exemple "riche" mais réaliste de hCard, disons par exemple un commercial, qui veut mettre tout un paquet d'information de contact sur son site web afin de pouvoir être trouvé/contacté facilement.
  - ''Negative'' : this require adding a bit of special case to existing parsers to handle these elements
* Fournir des exemples sur la manière d'encoder des comptes de messagerie instantanée. Imaginer quels seraient les URLS mailto: ou aim: dans hCard et comment cela apparaîtrait dans vCard. Et jeter un oeil sur ce que les applications vCard font aujourd'hui des adresses IM.
  - ''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 minimizes 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.


== Références ==
[[User:RobManson|RobManson]]
=== 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]


== Autres Implémentations/Idées ==
=== multiple type parsing ===
* [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
* 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) ]
* It would also be possible to convert XFN and hCard to FoaF and back.


=== parsage hyperlien fax et modem ===
For the "tel" property in particular, when the element is:
* <code>&lt;a href="fax:..."&gt;</code> OR <code>&lt;area href="fax:..."&gt;</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>&lt;a href="modem:..."&gt;</code> OR <code>&lt;area href="modem:..."&gt;</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.


== Noms de composants Ambigus  ==
=== 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.
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.
Line 463: Line 631:
One implementation suggestion is a 'best-guess' algorithm, something along the lines of:
One implementation suggestion is a 'best-guess' algorithm, something along the lines of:


# If the name is one word, attempt [[hcard-fr#hcard-fr#Optimisation_implicite_du_.22nickname.22|optimisation implicite du pseudo]]
# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard-fr#hcard-fr#Optimisation_implicite_.22n.22|optimisation implicite de n]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
Line 471: Line 639:
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.
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.


== Suggestions Acceptées==
===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).


=== Donnée d'encodage Company sous une Business Card (proposition) ===
* '''gender'''
** Voir [[vcard-suggestions-fr#Genre]]


(Acceptée : http://microformats.org/wiki/hcard-fr#Info_Contact_Organisation )
* '''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 &lt;pre&gt; 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.
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.
Line 481: Line 790:
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.
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-fr#organisation_vs._individu Apple Address Book supports this semantic when importing vCards].
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.
See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.


=== Optimisation implicite "FN et N" (proposition) ===
=== Optimisation Implicite "FN et N" ===


Right now a parser first looks for an "n" element.
A cette heure, un parseur cherche d'abord un élément "n".


And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.
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 :
HISTORIQUE :


Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.
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 :
PROPOSITION :


We should consider adding one more implied optimization after the steps documented above and that is:
Nous devrions imaginer ajouter une ou plusieurs optimisations implicites après les étapes documentés au-dessus et c'est :


If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.
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".


This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
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:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:ChrisMessina|ChrisMessina]] - note : plusieurs nicknames alternatifs devraient être aussi permis
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]


== Suggestions Rejetées ==
== tel work implicite ==


Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''
=== Problème ===


Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
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>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
Line 521: Line 877:
</nowiki></pre>
</nowiki></pre>


There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.
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 ==  
== Pages en rapport ==
{{hcard-related-pages-fr}}
{{hcard-related-pages-fr}}

Latest revision as of 14:15, 24 June 2009

hCard Brainstorming

Cette page est pour brainstormer sur les différentes utilisation et les détails de hCard. Cette page contient des propositions. Pour l'état actuel, regardez svp hCard.

Auteurs

Contributeurs

(Traduction en cours Christophe Ducamp)

Problèmes Etant Résolus

Quelques-uns des problèmes que hCard aide à résoudre :

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'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 class="fn extended-address"), alors :

  1. La hCard représente l'information de contact pour un endroit et DEVRAIT être traitée en tant que tel.
  2. 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.
  3. 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

<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>

Exemples potentiels dans la jungle

  • Le lieu "Phone Boxes by the Sealife Centre" sur Upcoming est actuellement marqué sous "fn org":
<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>

Ceci pourrait être marqué comme :

<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>

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.

<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>

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 GeoRSS simple contient l'exemple suivant de lieu nommé dans la section "Additional Properties" qui référence un featurename tag.

Feature Type, Feature Name, and Relationship Tags

The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.

    <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>

Une recherche sur featurename sur georss.org échoue pour trouver d'autres références, y compris une définition.

Un 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. Flickr, 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éé 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 à 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 Flickr et 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 à 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. class="fn nickname"), alors

  1. Le contenu "fn" est traité comme la valeur de propriété "nickname".
  2. 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 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-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 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 :

<span class="vcard">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span>

serait traité du point de vue d'un parsage comme :

<span class="vcard"><span class="n">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span></span>

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

<span class="vcard"><span class="fn n">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span></span>

Exemples

  • Voir exemples hCard, qui fournit plusieurs exemples illustrés instructifs, tout comme des exemples de hCard 1:1 pour chaque exemple dans la RFC 2426.

Utiliser la RFC2806 avec hCard

La 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 : Uniform Resource Identifier (URI) SCHEMES

tel   telephone [RFC2806]
fax   fax       [RFC2806]
modem modem     [RFC2806]

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

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

ou même :

<a class="tel" href="tel:+1-919-555-7878">Le téléphone de Monsieur Bloïc</a>

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 sources telagent pour des URIs tel)
  • Dans Mozilla, Dizzy
  • Dans Internet Explorer, 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.

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

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

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.
    • <a class="email" href="mailto:loic@mac.com">...
  • 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 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 :

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 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-exemples pour 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 FactoryCity, les billets de blogs ont des mini-hcards pour "published by", à savoir (espace blanc ajouté pour la lisibilité) :

Published by 
<span class="vcard author">
 <a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
  Chris Messina
 </a>
</span>

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 :

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

Le type approprié et enregistré pour les entités vCard est “text/directory”, comme défini dans la RFC 2425 Internet “A MIME Content-Type for Directory Information”. RFC 2426, “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, Björn Höhrmann a envoyé au HTML Working Group une 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

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 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 Date de Décès est disponible)

...

Problématiques avec les Applications vCard

Voir 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.

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

-- 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 :

<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>

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 :

Jean Q. Public

    Jean
    Q.
    Public

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

-- 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.

-- 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  ? Ceci peut donner à la hCard quelque valeur ajoutée sémantique à l'intérieur du document XHTML.

<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>

-- Ben Ward


  • Si la réponse à la question Q au-dessus est "oui", pouquoi ne pas utiliser ce qui suit ?
<dfn class="fn">Joe Friday</dfn>

ou

<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>

Ceci marquerait la hCard entière comme l'"instance de définition".

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.

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." WilleRaab 16:55, 23 Jul 2007 (PDT)

  • Voir 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 :

  1. Vu l'URL d'un commentateur, chercher un élément <address> avec le nom de classe "vcard" sur l'URL du commentateut. L'élément <address> est supposé être l'information de contact pour la page. (voir hCard FAQ pour plus d'infos), aussi cela fait du sens.
  2. Puis, chercher le premier élément dans cette hCard qui ait un nom de classe de "logo".
  3. En espérant que cet élément soit un <img>, et si oui, utiliser son src pour recevoir l'icone du commentateur.
  4. Basta. Vous avez des icônes de commentateurs distribuées !

Prévention du Spam

hCard utilise les liens mailto: et par conséquent, il hérite automatiquement des inconvénients des liens mailto: : 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). 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 :

<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a> 

Exemple de lien "encodé" (avec l'ajout de rel-nofollow) :

<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;exemple.com">john.smith&#064;exemple.com</a>

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.

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 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 acronym

Choix :

  • Traiter explicitement acronym comme le même que abbr, selon la sémantique de l'attribut 'title' sur acronym en particulier, comme défini dans HTML4.01.
  • Traiter explictement acronym comme le même que span, et décourager l'usage de acronym.

input element handling

Dans parsage hCard, j'ai défini de la gesion de cas spéciaux pour plusieurs éléments selon plus d'exceptions sémantiques, par ex. les propriétés textuelles sur l'élément img utilisent l'attribut 'alt'.

Un élément que j'ai oublié à cette heure était l'élément input, spécifiquement <input type="text">. Un autre que j'ai oublié était l'élément textarea.

La suggestion simple est d'ajouter le parsage hCard suivant, spécifiquement à la sous-section toutes propriétés :

  • <input type="text" value="...">: 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 DOIT utiliser la 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.
  • <textarea> :utilise les contenus texte de l'élément. Les agents-utilisateurs interactifs DOIT utiliser la the valeur en cours de l'élément.

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 sur 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 et IE et tout autre navigateur qui le supporte.

Pour en savoir plus à ce propos, regardez le billet de blog 2007 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 : 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.

Tantek 16:24, 23 Jul 2007 (PDT)

Discussion historique:

Fils clé :


Quelque part en rapport

Un résumé clé :

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:

<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>
 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:

<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>
 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:

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 minimizes 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.

RobManson

multiple type parsing

  • Multiple Type parsing / Type Optimization : La spec le permet, et la 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 [ ChrisCasciano 10:21, 16 Apr 2007 (PDT) ]

parsage hyperlien fax et modem

For the "tel" property in particular, when the element is:

  • <a href="fax:..."> OR <area href="fax:..."> : 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.
  • <a href="modem:..."> OR <area href="modem:..."> : 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:

  1. If the name is one word, attempt implied nickname optimization
  2. If the name is two words, attempt implied n optimization
  3. For three or more words
    1. Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
    2. 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 adr 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 :

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" :

sous-propriété adr unique implicite

I propose that, where adr 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 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". 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. 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". 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. 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 et 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'Annuaire des Employés d'IBM cherche les 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 :

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

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 Google's geocoder 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.

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. 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. Andy Mabbett 08:06, 20 Apr 2007 (PDT)
    • SI /quand la 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". 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 problématiques hCard.
  • 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).

par conséquent regarder (et ajouter à): 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 a déjà fait ça. D'autres efforts en rapport :

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

Persondata sur la Wikipedia anglo-saxonne est très proche de hCard, mais a des champs supplémentaires de dates et lieux de naissance. Andy Mabbett 13:02, 28 Jan 2007 (PST)

TODO

  • Le 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 :

<span style="display: none">Donnée Cachée</span>

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

Suggestions Acceptées

Encoder les données de Sociétés sous une Business Card

( Accepté 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 Apple Address Book supports this semantic when importing vCards.

See the 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.

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

[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.

<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>

[Supermarketguru.com]

   <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>

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. 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 :

<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>

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

Références Informatives

Pages en rapport

La spécification hCard est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront rajoutés. Ces idées, problématiques et questions sont maintenues sur des pages distinctes.