hcard-brainstorming-fr

From Microformats Wiki
Revision as of 18:56, 9 August 2007 by ChristopheDucamp (talk | contribs) (→‎Parsage: sync in progress)
Jump to navigation Jump to search

hCard Brainstorming

Cette page est pour brainstormer sur les différentes utilisation et les détails de hCard.

Auteurs

Contributeurs

(Traduction en cours Christophe Ducamp)

Problèmes Etant Résolus

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

  • devoir saisir les cartes de visite qui deviennent obsolètes (s'abonner à la place à la 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.

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

Du fait de l'utilisation potentielle de nicknames/handles/usernames 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

Le fait que la propriété "n" soit plus détaillée et structurée que la propriété "fn", et les exemples dans la jungle aient 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 suivant qui permettrait aux sites de n'utiliser que "n" et ses sous-propriétés.

"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 de hCard représenative

Moyens pour auto-découvrir la hCard représentaive pour une page, ce qui signifie la hCard qui signifie la personne/propriétaire de la page.

Applications pour l'auto-découverte de la hCard représentative pour la page

  • auto-extraction de vCard à partir de la page
  • découverte icône de profil (par ex. quelles personnes utilisent des gravatars)

L'option préférée est de n'utiliser que du HTML sémantique uniquement visible (CHIC).

Voici un scénario qui cadre le processus proposé d'auto-découverte :

  1. Je (en tant qu'utilisateur) donne l'URL de ma page personnelle ou ma hCard ou une autre URL de profil, vers un site qui veut une icône de profil
  2. Ce site y va et l'obtient (par ex. en utilisant hKit), et puis :
    1. verifie pour voir s'il existe une hCard <address> et l'utilise s'il la trouve. (s'il y a plus d'une telle hCard sur la page ?)
    2. vérifier pour voir s'il existe une hCard avec une propriété "url" sur un hyperlien rel="me" (parce que rel="me" ne fonctionne uniquement que pour une page en entier, si une hCard contient une telle URL, alors cette hCard doit représenter la page. voir XFN identity consolidation pour plus de détails.), et l'utilise s'il la trouve. (s'il existe plus d'une telle hCard sur la page ?)
    3. vérifie pour voir s'il existe une hCard avec une propriété "url" qui pointe vers la page en cours et l'utilise s'il la trouve. (s'il existe plus d'une telle hCard sur la page ?)
    4. autrement il utilise la première hCard qu'il trouve (ce qui dans les cas d'URLs de profils qui n'ont qu'une unique hCard comme sur Flickr, Zooomr, et Technorati, fonctionnera comme convenu).
  3. Le site regarde dans la hCard pour une propriété "logo" et utilise la première qu'il trouve
  4. Autrement il cherche une propriété "photo" et utilise la première s'il en trouve
  5. Autrement le site utilise une icone par défaut, mais s'abonne à l'URL avec la hCard et la vérifie pour un "logo" ou une "photo", disons, une fois par jour.

lien rel vCard d'auto-découverte

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.

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

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", e.g. (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'information comme le numéro de téléphone, l'anniversaire, etc.


Auto-Découverte pour 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.

Améliorations geo

voir geo-brainstorming

Autres cas d'utilisation

  • 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 pouir 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 parser hCard pour les règles actuelles de parsage de hCard.

Ajoutez des idées/propositions pour améliorer.ajouter ici au parsage hCard dans cette section du brainstorming hCard et assurez-vous d'inclure des URLs ves des exemples de hCards dans la jungle qui pourraient bénéficier des modifications de règles de parsage.

  • Parsage de Plusieurs Type /Optimisation du Type : la spec. le permet et la publication de hCard démontre l'utilisation de plusieurs désignation de types pour une valeur unique de tel. La syntaxe utilisée dans les exemples de publication où chacun semble aimer ça pourrait devenir encombrante. Parce que ces désignations de types sont tous des chaînes de mots uniques, il peut être posssible d'implémenter des règles supplémentaires de parsage pour autoriser plusieurs types à l'intérieur du même élément HTML. Gérer les délimiteurs peut être une problématique [expace, virgule, etc ?], et quelques uns des usages dns la jugnle de plusieurs types auraient besoin d'être localisés et examinés avant de considérer des règles de parsage supplémentaires le long de ces lignes. ChrisCasciano 10:21, 16 Apr 2007 (PDT) ]
  • Les parseurs pourraient calculer l'âge en cours des sujets de hCard à partir de la date de naissance. Andy Mabbett 07:47, 20 Apr 2007 (PDT)
  • pour les hCards avec une date de naissance, les parseurs 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 à la hCard, les parseurs pourraient au lieu de cela générer un hCalendar récurrent de l'anniversaire de la date de décès.. Andy Mabbett 08:08, 20 Apr 2007 (PDT)
  • ...


parser l'hyperlien fax et modem

Pour la propriété "tel" en particulier, quand l'élément est :

  • <a href="fax:..."> OU <area href="fax:..."> : parser la valeur de l'attribue "href", en omettant le préfixe "fax:" et tout suffixe de requête "?" (s'il y en a), dans l'attribut. Pour des détails sur le schéma URL "fax:" voir RFC 2806. En outre, traiter cette instance de propriété "tel" comme ayant une sous-propriété type "fax" en plus de n'importe quelle sous-propriété tpe explicite sur la propriété "tel".
  • <a href="modem:..."> OU <area href="modem:..."> : parser la valeur de l'attribut 'href', en omettant le préfixe "modem: et tout suffixe de requête "?" (si présent), dans l'attribut. Pour les détails sur le schéma d'URL "modem:" voir la RFC 2806. En outre, traiter cette instance de propriété "tel" comme ayant une sous-propriété type "modem" en plus de tout ajout à n'importe quel type de sous-propriété exlicite sur la propriété 'tel'.


Noms de composants 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 with no children

Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect adr to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

sous-propritété adr implicite unique

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

It may be possible for parsers to parse out adr subproperties from a contiguous adr string. This would be an optimization for both adr and hCard.

This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way.

Exemples :

IBM's Employee Directory search returns hCards with the "adr" property which contain the "locality" and "country-name" data but unfortunately without being marked up as such, e.g.: 

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

We could first define a canonical ordering of how to parse for comma (and perhaps in some cases space) separated adr subproperties within an adr string e.g.:

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

FAQ adr sans enfants

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)

INPUT gestion de l'élément

In hcard-parsing, I've defined special-case handling for several elements according to more semantic exceptions, e.g. textual properties on the IMG element use the 'alt' attribute.

One element I forgot at the time was the INPUT element, specifically, <input type="text">. Another I forgot was the TEXTAREA element.


The simple suggestion is to add the following to hcard-parsing, specifically to the all properties sub-section:

  • <input type="text" value="...">: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty. Interactive useragents MUST use the current value of the element.
    • consider other input types also (e.g. checkbox, radio, hidden) and specify how to parse them as well.
  • <textarea>: use the text contents of the element. Interactive useragents MUST use the current value of the element.

Tantek

auto-remplisssage de formulaires

If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Interactive useragents (e.g. operator on firefox) could detect such "insert hCard here" semantics in forms on pages, and let you "pre-fill" with *your* hCard info, and then all of a sudden we have a standard for forms auto-fill, rather than all the hacks that have gone into browsers since 1999 (starting with IE4.5/Mac which I'm pretty sure was the first to do forms auto-fill of an entire form with a single button press - not just auto-complete of each form field individually).

Obviously this would make sense to build into *existing* forms auto-fill features in Firefox and IE, and any other browsers that support it.

This way new sites could simply conform to the standard, rather than depend on hacks which parse label values etc. and imply things and get them wrong sometimes.

i18n advantages: hCard annotated form inputs would also be more international, thus avoiding the need for each browser to guess what is the "name" and "telephone" field in every language, so they can do forms auto-fill on any site regardless of language, not just English.

Tantek 16:24, 23 Jul 2007 (PDT)

Discussion contextuelle :

Fils de discussion clés :


En rapport :

Un résumé-clé :

The options discussed in a hypothetical hCard input system so far appear to be:

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


Marquage proposé : 

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

Marquage proposé : 

<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ématiques-clés/points de discussion

  • Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
 - Negative : this require re-coding the existing parsers
 - Positive : this could help to enable uf based auto form filling
 - Negative : this could help to enable uf based auto form filling (e.g. spam automation)
  • Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
 - Positive : this is in line with the current parsing model
  • Many parsers (e.g. operator) parse the loaded html not the dynamic DOM
 - Negative : parser doesn't pickup any updated form data after the page has loaded
 - e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
  • Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
 - Positive : this minimises the changes to current parsing rules
  • Empty values should be ignored when extracting hCards
  • hCards with all empty values should be ignored when listing/extracting hCards
  • Which form elements should be supported beyond input fields
 - Examples
   - title select that lists mr/mrs/ms/dr/etc.
   - checkboxes to choose which addresses to use
 - Option : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
 - 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

RobManson

Noms de classes ambigus

Au moment de publier automatiquement des hCards à partir de données pré-existantes, il n'est pas nécessairement possible de dire quels mots dans un nom vont aux propriétés hCard. Quand la structure d'un nom est inconnue, il est difficile de s'assurer qu'une hCard automatiquement publiée demeure valide.

Il n'y a actuellement pas de réponse facile à cela.

Une suggestion d'implémentation est un algorithme "best-guess" quelque chose qui serait dans les lignes de :

  1. Si le nom est en un mot, tenter une optimisation implicite du nickname
  2. If the name is two words, tenter optimisation implicite du "n"
  3. Pour trois mots ou plus
    1. Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
    2. Appliquer la grammaire "given-name additional-name(s) family-name"

L'argument derrière cette suggeston est qu'il est mieux de produire une bonne supposition et potentiellement mal catégoriser un composant nom ambigu que de générer une hCard invalide.


ADR sans enfants

Les parseurs (Operator, Tails, Presque Tous les Parseurs Universels de Microformats) attendent actuellement d'adr une ou plusieurs sous-propriétés. Il n'est pas claire à partir de la spec hCard que ce soit obligatoire (même si la RFC vCard l'exige) ; ni qu'il soit toujours possible pour un champ address dans un site web avec gabarits (ou CMS) d'être défini avec une telle granularité.

Considérez Wikipedia, dont les modèles ont souvent un champ "local" ou "lieu", utilisé par exemple sur ces articles concernant les gares de chemin de fer :

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

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 adre à partir d'une chaîne contigue adr. Ceci serait une optimisation pour à la fois adr et hCard.

Ceci peut aussi être trop difficile/complexe d'être fiable ou interopérable, mais cela vaut au moins la peine de documenter nos considérations et de les analyser dans un sens.

Exemples :

La recherche sur Annuaire des Employés IBM sur retourne les hCards avec la propriété "adr" qui contient les données "locality" et "country-name" mais malheureusement sans être marquées comme telles, par ex : 

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

Nous pourrions d'abord définir un ordre canonique sur la manière de parser les virgules (et peut-être dans certains cas l'espace) séparées des sous-propriétés adre à l'intérieur d'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.

  • US|USA|United States|United States of America - 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

INPUT element handling

In hcard-parsing, I've defined special-case handling for several elements according to more semantic exceptions, e.g. textual properties on the IMG element use the 'alt' attribute.

One element I forgot at the time was the INPUT element, specifically, <input type="text">. Another I forgot was the TEXTAREA element.


The simple suggestion is to add the following to hcard-parsing, specifically to the all properties sub-section:

  • <input type="text" value="...">: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty. Interactive useragents MUST use the current value of the element.
    • consider other input types also (e.g. checkbox, radio, hidden) and specify how to parse them as well.
  • <textarea>: use the text contents of the element. Interactive useragents MUST use the current value of the element.

Tantek

auto-remplissage de formulaire

If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Interactive useragents (e.g. operator on firefox) could detect such "insert hCard here" semantics in forms on pages, and let you "pre-fill" with *your* hCard info, and then all of a sudden we have a standard for forms auto-fill, rather than all the hacks that have gone into browsers since 1999 (starting with IE4.5/Mac which I'm pretty sure was the first to do forms auto-fill of an entire form with a single button press - not just auto-complete of each form field individually).

Obviously this would make sense to build into *existing* forms auto-fill features in Firefox and IE, and any other browsers that support it.

This way new sites could simply conform to the standard, rather than depend on hacks which parse label values etc. and imply things and get them wrong sometimes.

i18n advantages: hCard annotated form inputs would also be more international, thus avoiding the need for each browser to guess what is the "name" and "telephone" field in every language, so they can do forms auto-fill on any site regardless of language, not just English.

Tantek 16:24, 23 Jul 2007 (PDT)

Discussion historique :

Key threads:


Somewhat related:

One key summary:

The options discussed in a hypothetical hCard input system so far appear to be:

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ématiques Clés/points de discussion

  • Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
 - Negative : this require re-coding the existing parsers
 - Positive : this could help to enable uf based auto form filling
 - Negative : this could help to enable uf based auto form filling (e.g. spam automation)
  • Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
 - Positive : this is in line with the current parsing model
  • Many parsers (e.g. operator) parse the loaded html not the dynamic DOM
 - Negative : parser doesn't pickup any updated form data after the page has loaded
 - e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
  • Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
 - Positive : this minimises the changes to current parsing rules
  • Empty values should be ignored when extracting hCards
  • hCards with all empty values should be ignored when listing/extracting hCards
  • Which form elements should be supported beyond input fields
 - Examples
   - title select that lists mr/mrs/ms/dr/etc.
   - checkboxes to choose which addresses to use
 - Option : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
 - 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

RobManson

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 désirable que de faire crôitre 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.

Wikipedia's Persondata

Wikipedia's Persondata aligns very closely with hCard, but has additional date and place of birth & death fields. Andy Mabbett 13:02, 28 Jan 2007 (PST)

TODO

  • Le profil hCard needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
  • Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
  • Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
  • Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.
  • Clarify contradictory copyright statements, per http://microformats.org/discuss/mail/microformats-discuss/2007-July/010243.html

Styles CSS

Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code: 

<span style="display: none">Hidden Data</span>

Transforming applications will still find the data and use it when converting hCards to vCards.


Autres Implémentations/Idées

Suggestions Acceptées

Encoder les données de Sociétés comme une Carte de Visite (proposition)

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

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" (proposition)

Right now a parser first looks for an "n" element.

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.

BACKGROUND:

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.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

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.

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.


Suggestions Rejetées

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.

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: 

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

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.

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.

Métadonnées personnes de Wikipedia

Les métadonnées personnes de Wikipedia s'alignent très près de la hCard, mais elles ont des champs supplémentaires de date, lieux et dates de naissance et de décès.


TODO

  • Le profil hCard a besoin de vérification et peut-être d'un URL pour retrouver le véritable XMDP, plutôt qu'un texte <pre> sur une page wiki.
  • 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.
  • 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.
  • 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.


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 (ATTENTION : ceci est un CONTRE vraiment recommandé et va à l'encontre du principe des microformats que de baliser des données visibles) alors vous pouvez cacher ce tag dans la CSS avec le code suivant : 

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

Les applications de transformation trouveront encore les données et les utiliseront au moment de convertir les hCards en vCards.

Autres Implémentations/Idées

  • 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 and back.

Noms de composants Ambigus

Au moment de publier automatiquement des hCards à partir de données pré-existantes, il n'est pas nécessairement possible de dire quels mots dans un nom correspondent à quelles propriétés hCards. Quand la structure d'un nom est inconnue, il est difficile de s'assurer qu'une hCard automatiquement publiée reste valide.

Il n'y a actuellement pas de réponse facile à ceci.

Une suggestion d'implémentation est un algorithme 'best-guess' quelque chose qui pourrait s'écrire comme ça :

  1. Si le nom est en un mot, essayer

optimisation implicite du pseudo

  1. Si le nom est deux mots, essayer

optimisation implicite de n

  1. Pour trois mots ou plus
    1. Exécuter une recherche contre les combinaisons de sous-noms connus (par ex. 'Sarah Jane', 'Vander Wal')
    2. Appliquer la grammaire "given-name additional-name(s) family-name" (NDT :prénom, nom supplémentaire, nom de famille)

Le principal derrière cette suggestion est qu'il est mieux de faire une bonne supposition et potentiellement mal catégoriser un composant de nom ambigu que de générer une hCard invalide.

ADR sans enfants

Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect adr to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

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)

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)


Suggestions Acceptées

Donnée d'encodage Société sous une Business Card (proposition)

(Acceptée : http://microformats.org/wiki/hcard-fr#Info_Contact_Organisation )

Dans la jungle il y a plusieurs hCards qui ne valident pas parce que ce sont des entreprises qui ont omis la propriété "fn" en faveur de la propriété "org".

Proposition : les hCards représentant une entreprise ou une organisation DOIVENT régler fn ET org à la même valeur. Les parseurs peuvent alors utiliser cette équivalence, si détectée, pour traiter une hCard comme l'information de contact pour une entreprise ou une organisation plutôt qu'un individu.

Remarquez que le Carnet d'Adresses d'Apple supporte cette sémantique au moment d'importer les vCards.

Regardez Technorati Contact Info pour avoir un exemple.

Optimisation implicite "FN et N" (proposition)

A cette heure un parseur regarde d'abord la présence d'un élément "n".

Et s'il n'y a pas de "n" présent, il cherche un élément "fn" à utiliser pour insinuer un élément "n" selon les règles "propriét n implicite" dans la spécification.

HISTORIQUE :

Du fait de la prévalence d'utilisation de "pseudos" ou "handles" sur le Web, dans le contenu véritable 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 une solution de repli.

PROPOSITION :

Nous devrions considérer ajouter une optimisation plus implicite après les étapes documentées au-dessus et ce qui donne :

S'il n'y a pas de "fn" présent, alors chercher un élément "nickname" à utiliser pour sous-entendre à la fois le "fn", et le "n/given-name", laissant le "n/family-name" comme vide.

Ceci permettrait d'avoir un "nickname" seulement dans le hCards pour indiquer un individu sur un site web, ce qui est tout à fait usuel sur les blogs et critiques publiées sur le Web.

Suggestions Rejetées

Suggestion : L'utilisation de class="url" sur un tag <a> représenter une proprité URL hCard est redondant. En vertu du tag <a> vous savez que c'est une URL.

Rejeté. Ceci est une mauvaise suggestion même si cela apparaît pour réduire la redondance et rendre les choses plus propres, cela crée aussi quelques problèmes. Sans indiquer explicitement que c'est une URL alors n'importe quels tags <a> dans une 'vcard' seraient considérés 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, alors que si "url" est requis pour être explicitement listé dans la liste d'attribut de classe, alors en ne listant PAS, il pourrait être efficacement désactivé.


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.

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-brainstorming-fr&oldid=19461"