Revision as of 05:30, 14 December 2006

hCard

hCard est un format simple, ouvert, distribué, pour représenter les personnes, sociétés, organisations et lieux, en utilisant une représentation 1:1 des propriétés et valeurs du standard vCard (RFC2426) en XHTML sémantique. hCard est l'un des nombreux microformats standards ouverts adaptés pour l'embarquement dans (X)HTML, Atom, RSS, et le XML arbitraire.

Vous voulez démarrer dès à présent par écrire une hCard ? Utilisez le hCard creator pour écrire quelque information de contact et la publier, ou suivez les trucs pour la publication de hCard afin d'ajouter votre syntaxe hCard à votre page contact actuelle.

Spécification

Editeur

Tantek Çelik, Technorati, Inc.

Auteurs

Traduction française

Christophe Ducamp

Copyright

Cette spécification est (C) 2004-2024 par les auteurs. Néanmoins, les auteurs ont pour but de soumettre cette spécification à un corps de standards avec une politique libérale de copyright/licence telle que GMPG, IETF, et/ou W3C. Quiconque souhaite contribuer devrait lire avant de contribuer leurs principes de copyright, politiques et licences (par ex. les Principes GMPG) et être d'accord avec eux, y compris le fait de licencier toutes les contributions sous les licences nécessaires (par ex. CC-by 1.0 et suivantes).

Brevets

Cette spécification est sujette à une politique de brevets libres de droits, par ex. pour la Politique de Brevet du W3C, IETF RFC3667 et RFC3668.

Inspiration et Remerciements

Remerciements à : mon bon ami Vadim qui m'a présenté vCard il y a de nombreuses années, et si j'avais prêté alors un peu plus d'attention, j'aurais pu peut-être aider beaucoup de personnes à éviter de perdre du temps à réinventer beaucoup de roues des standards.

Introduction

Le standard vCard (RFC2426), a été largement implémenté de façon interopérable. (par ex. dans l'application "Carnet d'Adresses" d'Apple intégrée dans MacOSX).

En outre, beaucoup de blogueurs s'identifient eux-mêmes par un nom et discutent avec leurs amis et familles. Avec juste un peu de structure, les blogueurs peuvent discuter avec des personnes dans leurs blogs d'une telle façon que les spiders et autres agrégateurs peuvent retrouver cette information, la convertir automatiquement en vCards et l'utiliser dans n'importe quelle application ou service vCard.

Cette spécification présente le format hCard, qui utilise une représentation 1:1 des propriétés et valeurs du standard vCard mentionné ci-dessus, en XHTML sémantique. Les blogueurs peuvent tout à la fois embarquer directement les hCards dans leurs pages web et les styler avec CSS pour les faire apparaître comme ils le désirent. En outre, hCard permet aux applications de retrouver directement l'information à partir des pages web sans avoir à référencer un fichier séparé.

Utilisez le hCard creator et copiez le code HTML qu'il génère sur votre blog ou site web pour publier votre information de contact.

Principes de Design XHTML Sémantique

Note : les Principes de Design XHTML Sémantique ont été écrits initialement dans le contexte de développement de hCard et hCalendar, par conséquent il peut être plus facile de comprendre ces principes dans le contexte de la méthodologie de design hCard (ce qui veut dire, lisez ça d'abord). Tantek

XHTML est construit sur du XML, et par conséquent les formats fondés sur XHTML peuvent être utilisés non seulement pour une présentation d'affichage pratique, mais aussi à des fins d'échanges de données. A bien des façons, les formats fondés sur XHTML illustrent le meilleur des mondes tant du HTML que du XML. Néanmoins au moment de construire des formats basés sur XHTML, cela aide d'avoir un ensemble de principes directeurs.

Réutilisez autant que possible le schéma (noms, objets, propriétés, valeurs, types, hiérarchies, contraintes) à partir des standards de référence établis et bien supportés. Evitez de redéclarer les contraintes exprimées dans le standard source. Des mentions à titre d'information peuvent passer.
1. Pour les types avec plusieurs composants, utilisez des éléments imbriqués avec des noms de classe équivalents aux noms des composants.
2. Les composants pluriels sont produits au singulier, et par conséquent plusieurs éléments imbriqués sont utilisés pour représenter plusieurs valeurs de texte qui sont délimitées par des virgules.
Utilisez la sémantique XHTML la plus précise pour construire des blocs pour chaque objet, etc.
Autrement utilisez un élément générique structurel (par ex. <span> ou <div>), ou l'élément contextuel approprié (par ex. un <li> dans un <ul> ou <ol>).
Utilisez des noms de classes basés sur des noms extraits du schéma original, à moins que le XHTML sémantique de construction de bloc ne représente précisément cette partie du schéma original. Si les noms dans le schéma original ne sont pas sensibles la casse, alors mettez tout dans un équivalent en bas de casse. Les noms de composants implicites en prose (plutôt qu'explicites dans le schéma défini) devraient aussi utiliser les équivalents bas de casse pour une facilité d'utilisation. Les espaces dans les noms des composants deviennent des caractères tiret '-'.
Pour finir, si le format de la donnée selon le schéma original est trop long et/ou non amical sur le plan humain, utilisez <abbr> au lieu d'un élément générique structurel, et placez les données littérales dans l'attribut 'title' (là où vont les expansions abbr), et l'équivalent le plus bref et le plus lisible humainement dans l'élément lui-même. De plus amples explications de cet usage de <abbr> : Human vs. ISO8601 dates problem solved

Format

En Général

Le standard vCard (RFC2426) forme la base du hCard.

Le format basique de hCard est d'utiliser les noms d'objet/propriété vCard en bas de casse pour les noms de classes, et de mapper l'imbrication des objects vCard directement dans les éléments imbriqués XHTML.

Plus d'Equivalents Sémantiques

Pour quelques propriétés, il existe quelques éléments HTML qui correspondent mieux et portent leurs sémantiques. Les propriétés suivantes DEVRAIENT être encodées avec le (X)HTML suivant :

URL dans vCard devient <a class="url" href="...">...</a> dans l'élément avec class="vcard" dans hCard.
De la même manière, EMAIL dans la vCard devient <a class="email" href="mailto:...">...</a>
PHOTO dans la vCard devient <img class="photo" src="..." alt="Photo de ..." /> ou <object class="photo" data="..." type="...">Photo de ...</object>
UID dans vCard devient simplement une autre sémantique appliquée à un URL spécifique (ou EMAIL) pour une hCard.

Propriétés Singulières vs. Plurielles

Pour les propriétés qui sont singulières (par ex. "N" et "FN"), le premier élément descendant avec cette classe devrait prendre effet, tous les autres étant ignorés.

Pour les propriétés qui peuvent être plurielles (par ex. "TEL"), chaque instance de classe devrait créer une instance de cette propriété.

Propriétés Singulières

Les propriétés Singulières : "FN", "N", "BDAY", "TZ", "GEO", "SORT-STRING", "UID", "CLASS".

Toutes les autres propriétés sont plurielles. Cette liste a été dérivée en analysant la sémantique des propriétés individuelles dans la RFC2426 vCard et en déterminant logiquement qu'elles DOIVENT être singulières selon leurs sémantiques. Voir propriétés hcard singulier pour des explications.

Propriétés Plurielles Singularisées

Parce que les noms de propriétés plurielles deviennent leurs équivalents singuliers, même si la propriété plurielle originale ne permettait qu'une valeur unique avec plusieurs composants, ces composants multiples sont représentés chacun avec leur propre singularité appelée propriété et la propriété est en fait multivalorisée et sujette au traitement ci-dessus des propriétés multivalorisées.

Lisible par Humain vs. Machine

Si un élément <abbr> est utilisé pour une propriété, alors l'attribut 'title' de l'élément <abbr> est la valeur de la propriété, au lieu de celle des contenus de l'élément, ce qui fournit à la place une version humainement présentable de la valeur.

Si un élément <a> est utilisé pour une ou plusieurs propriétés, il doit être traité comme suit :

Pour la propriété "PHOTO" et toute autre propriété qui prend un URL comme sa valeur, l'attribut href="..." fournit la valeur de la propriété.
Pour les autres propriétés, le contenu de l'élément est la valeur de la propriété.

Si un élément <img> est utilisé pour une ou plusieurs propriétés, il doit être traité comme suit :

Pour la propriété "PHOTO" et toute autre propriété qui prend un URL comme sa valeur, l'attribut src="..." fournit la valeur de la propriété.
Pour les autres propriétés, (NDT à vérifier) l'attribut <img> alt de l'élément est la valeur de la propriété.

Si un élément <object> est utilisé pour une ou plusieurs propriétés, il doit être traité comme suit :

Pour la propriété "PHOTO" et toute autre propriété qui prend une URL comme sa valeur, l'attribut data="..." fournit la valeur de la propriété.
Pour les autres propriétés, le contenu de l'élément est la valeur de la propriété.

Extraction de Valeur

Parfois, seule une partie d'un élément qui est l'équivalent pour une propriété devrait être utilisée pour la valeur de la propriété. Ceci survient généralement quand une propriété a un sous-type, comme TEL. Pour cette intention, le nom de classe spéciale "value" est introduit pour extraire le sous-ensemble de l'élément qui est la valeur de la propriété. Par exemple ici un fragment hCard pour marquer un numéro de téléphone de domicile :

vCard:

TEL;TYPE=HOME:+331.58.40.36.41

hCard:

<span class="tel">
 <span class="type">domicile</span>:
 <span class="value:+331.58.40.36.41</span>
</span>

Ce fragment de hCard pourrait s'afficher sous :

domicile: <span class="value:+331.58.40.36.41

Exceptions de Propriétés

vCard a plusieurs propriétés qui soit ne font pas de sens, ou sont déjà imbriquées dans le contexte d'une page web. Cette section explique ce qu'il faut (ou ne pas) faire avec elles :

Les propriétés NAME, PROFILE, SOURCE, PRODID, VERSION telles que définies dans les Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 de la RFC 2426.

Les éditeurs de contenus ne DOIVENT pas utiliser ces propriétés dans leurs hCards, et aussi les consommateurs/parsers de hCard DOIVENT IGNORER ces propriétés si elles sont trouvées dans une hCard. Au lieu de cela, les convertisseurs hCard vers vCard DEVRAIENT utiliser le titre de la page où la hCard est trouvée (c'est à dire l'élément <title> dans les documents (X)HTML) pour construire la propriété NOM, PEUVENT produire une valeur PROFILE de "VCARD" par RFC 2426, DEVRAIENT utiliser l'URL de la page où est trouvée la hCard pour construire la propriété SOURCE (c'est à dire peut-être comme un paramètre vers un URL/service qui convertir les hCards en vCards), pour un flux de sortie vCard (par ex. un fichier vcf). Seuls les services/applications qui produisent de véritables vCards devraient écrire la propriété PRODID, avec l'identifiant produit pour l'application/service. De la même façon, seuls de tels services/applications devraient écrire la propriété VERSION, avec la valeur "3.0" (sans guillemets) selon la RFC2426 Section 3.6.9.

Info Contact Organisation

Si les propriétés "FN" et "ORG" ont exactement la même valeur (généralement parce qu'elles sont réglées sur le même élément, par ex. class="fn org"), alors la hCard représente l'information de contact pour une société ou une organisation et devrait être traitée comme telle. Dans ce cas l'auteur DOIT aussi NE PAS régler la propriété "N", ou la régler (et n'importe quelles sous-propriétés) explicitement vers la chaîne vide "". Par conséquent les parseurs devraient gérer dans ce cas la propriété manquante "N" en sous-entendant des valeurs vides pour toutes les sous-propriétés "N".

Optimisation implicite "n"

Bien que vCard requiert que la propriété "N" soit présente, les auteurs de la spécification vCard (RFC 2426) n'incluent pas eux-mêmes les propriétés "N" dans leurs vCards près de fin de la spec (p.38). Cette contradiction apparente peut être résolue en permettant simplement à la propriété "FN" de sous-entendre les valeurs de la propriété "N" dans les cas typiques fournies dans la spec. Nous faisons cela explicitement dans hCard.

Si "FN" et "ORG" ne sont pas les mêmes (voir section précédente) et si la valeur de la propriété "FN" est exactement deux mots (séparés par un espace blanc) et s'il n'y a pas de propriété explicite "N", alors la propriété "N" est inférée à partir de la propriété "FN". Pour les "FN"s avec soit un mot voir au-dessous, et pour trois ou plus, l'auteur DOIT explicitement baliser le "N", exception faite pour le cas de l'information de contact organisation, voir au-dessus pour cela.

Le contenu de "FN" est brisé en deux "mots" séparés par un espace blanc.
Le premier mot de FN est interprété comme le "given-name" (prénom) pour la propriété "N".
Le second/dernier mot de "FN" est interprété comme le "family-name" pour la propriété "N".
Exception : Si le premier mot se finit par une "," virgule OU si le second mot est un caractère unique (optionnellement suivi par un point "."), alors le premier mot (moins la virgule à la fin s'il y en a) est interprété comme le "family-name" et le second mot est interprété comme le "given-name" (prénom).

Ceci permet une simplification dans le cas typique des gens déclarant :

prénom (espace) nom-de-famille
nom-de-famille (virgule) prénom
nom-de-famille (virgule) premier-prénom-initiale
nom-de-famille (espace) premier-prénom-initiale (point en option)

Optimisation implicite du "nickname"

Du fait de la prévalence de l'utilisation sur le web de pseudos/handles/nomsutilisateurs dans les contenus publiés sur le Web (par ex. les auteurs des critiques), hCard a aussi une optimisation implicite de "nickname" pour gérer cela.

De la même manière que l'optimisation sous-entendue "n", si "FN" et "ORG" ne sont pas les mêmes, et si la valeur de la propriété "FN" est exactement d'un mot, et s'il n'y a pas de propriété "N" explicite, alors :

Le contenu du "FN" est traité comme une valeur de propriété "nickname".
Les parseurs devraient gérer la propriété manquante "N" par des valeurs vides implicites pour toutes les sous-propriétés "N".

Note : la hCard peut avoir des valeurs de propriétés explicites supplémentaires "nickname" en plus du nickname sous-entendu.

Optimisation implicite "organization-name"

La propriété "ORG" a deux sous-propriétés, organization-name et organization-unit. Très souvent les auteurs ne publient que organization-name. De ce fait si une propriété "ORG" n'a pas d'"organization-name" dedans, alors la totalité des contenus DOIT être traitée comme le "organization-name".

Tags en tant que Catégories

Les catégories dans hCard peuvent en option être représentées par des tags avec rel-tag. Quand une propriété category est un rel-tag, le tag (comme défini par rel-tag) est utilisée pour cette catégorie.

Nom Classe Racine

Le nom de classe racine pour une hCard est "vcard".

Liste de propriétés

Ceci est la liste des propriétés (et sous-propriétés, entre parenthèses, comme ça) dans hCard, prise à partir de vCard :

fn, n (nom de famille, prénom, prénom supplémentaire, préfixe honorifique, suffixe honorifque), pseudo, chaîne de tri
url, email (type, value), tel (type, value)
adr (boîte postale, adresse étendue, adresse dans la rue, localité, région, code-postal, nom-pays, type, valeur), étiquette
geo (latitude, longitude), tz
photo, logo, sound, bday
title, role, org (nom-organisation, unité-organisation)
category, note
class, key, mailer, uid, rev

valeurs sous-propriété type

Le sous-propriété 'type' en particulier prend différentes valeurs selon quelle propriété est une sous-propriété de. Ces valeurs de sous-propriétés 'type' sont INSENSIBLES à la casse, ceci voulant dire que "Home" est équivalent à "home", tout comme elle est multivalorisée, par ex. un téléphone peut être domicile et préféré :

<span class="tel"><span class="type">Domicile</span> (<span class="type">pref</span>éré):
 <span class="value">+331.58.40.36.41</span>
</span>

Les listes suivantes sont informatives. Voir sections RFC2426 3.2.1 ADR, 3.3.1 TEL, et 3.3.2 EMAIL respectivement pour les valeurs type normatives. Elles sont répétées ici pour la facilité. La(es) valeur(s) de sous-propriétés type est (sont) d'abord dans chaque liste et toutes indiquées en LETTRES CAPITALES. Les types peuvent être multivalorisées.

adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, car, isdn, pcs
email type: INTERNET, x400, pref, "other IANA registered address types"

Profil XMDP

Voir hcard-profile pour le profil XMDP de hCard qui contient la liste complète ci-dessus de propriétés, avec des références à leurs définitions RFC 2426.

Détails Parsage

Voir hCard parsing.

Exemples

Cette section est informative.

Echantillon vCard

Voilà une vCard échantillon.

BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
ORG:Technorati
END:VCARD

et un équivalent en hCard avec différents éléments optimisés proprement. Voir hCard Exemple 1 pour la dérivation.

<div class="vcard">
 <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
 <div class="org">Technorati</div>
</div>

Cette carte pourrait être affichée comme :

Tantek Çelik
Technorati

Note : L'information de version n'est pas directement nécessaire dans le balisage hCard parce que la version sera définie par le profil de hCard qui est utilisé/référencé dans l'attribut 'profile' de l'élément <head>.

Plus d'Exemples

Voir exemples hCard pour plus d'exemples, y compris tous les exemples extraits de la RFC 2426 vCard convertie en hCard.

Exemples "dans la jungle"

Cette section est informative. Le nombre d'exemples de hCard dans la jungle a grandi bien au delà de la capacité d'être maintenu en ligne pour cette spécification. Ils ont migré sur une page séparée.

Voir Exemples hCard dans la jungle.

Implémentations

Cette section est informative. Le nombre d'implémentations de hCard a aussi grandi au delà de la capacité de pouvoir les maintenir sur cette même page. Elles ont été migré sur une page séparée.

Voir Implémentations hCard.

Applications Additionnelles

Cette section est informative.

Il existe de nombreux usages potentiels supplémentaires et d'applicatons pour les hCards sur le Web. Les suivants sont simplement quelques idées et possibilités que les types ont produit :

En tant que standard ouvert/format pour les Gravatars.
Baliser les auteurs individuels de billets de blog sur un blog de groupe
Baliser les noms des personnes et URLs dans une blogroll
Toute référence à des personnes dans les billets de blog (par ex au moment de les citer, ou de les référencer, ou de les décrire par leurs noms).
...

Références

Références Normatives

Références Informatives

Spécifications Qui Utilisent hCard

Travaux Equivalents

Pages Apparentées

hCard creator (feedback) - crééz votre propre hCard.
publication hCard - apprenez comment ajouter hCard à votre information de contact existante.
exemples hCard - exemple d'usage de différentes classes dans hCard,
hCard FAQ - Si vous avez quelque question à propos de hCard, vérifiez ici et si vous ne trouvez pas de réponses, ajoutez-y votre question !
parsage hCard - Détails de normes sur la manière de parser les hCards.
problématiques hCard - Merci d'ajouter toute problématique avec la spécification sur la page problématiques.
hCard profile - Le profil XMDP pour hCard

Cette spécification est un travail en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront ajoutés. Ces idées, problématiques et questions sont maintenues dans des pages séparées.

hCard Brainstorming - l'endroit où nous maintenons nos brainstorms et autres explorations en rapport avec hCard.
hCard tests - une page wiki avec de véritables hCards embarquées pour essayer le parsage.

Lectures Supplémentaires

Digital Web Magazine: Microformats Primer de Garrett Dimon a une bonne introduction à hCard
Practical Microformats with hCard de Drew McLellan
Local Search Engine Optimization using Microformats par Chris Silver Smith
Andrew D. Hume a écrit un billet de blog sur usable microformats qui discute de hCard
L'introduction à hCard de Jesse Skinner
Superbe billet de blog de Shaun Shull sur How Microformats Affect SEO, incluant sa hCard comme un exemple.
Voir aussi les blogs discutant de cette page et le tag hCard

@@ Line 263: / Line 263: @@
 == Implémentations ==
-Cette section est '''informative'''. Le nombre d'implémentations de hCard a aussi grandi au delà de la capacité de pouvoir les maintenir sur cette même page. Elles ont été migré sur une [[hcard-implementations|page séparée]].
+Cette section est '''informative'''. Le nombre d'implémentations de hCard a aussi grandi au delà de la capacité de pouvoir les maintenir sur cette même page. Elles ont été migré sur une [[hcard-implementations-fr|page séparée]].
 Voir [[hcard-implementations-fr|Implémentations hCard]].

hcard-fr: Difference between revisions