vcard-suggestions-fr: Difference between revisions
m ([sync'd]) |
m ([fr: translated section]) |
||
Line 1: | Line 1: | ||
<h1> suggestions vCard </h1> | <h1> suggestions vCard </h1> | ||
{{TOC-right}} | |||
En tant que résultat de l'expérience d'utiliser [[hcard-fr|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr|véritables sites web du monde entier]], nous avons découvert quelques aspects de la {{RFC2426-fr}} vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon les propriétés {{RFC2426-fr}} avec une section "new" pour les nouvelles propriétés. | En tant que résultat de l'expérience d'utiliser [[hcard-fr|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr|véritables sites web du monde entier]], nous avons découvert quelques aspects de la {{RFC2426-fr}} vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon les propriétés {{RFC2426-fr}} avec une section "new" pour les nouvelles propriétés. | ||
Line 15: | Line 15: | ||
=== <span id="3.3.1_TEL_Type_Definition">TEL Type Definition</span> === <!--span préserve l'ancienne ID--> | === <span id="3.3.1_TEL_Type_Definition">TEL Type Definition</span> === <!--span préserve l'ancienne ID--> | ||
:'''Voir : {{RFC2426-fr}} section 3.3.1 | :'''Voir : {{RFC2426-fr}} section 3.3.1 | ||
* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL". | * Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL". | ||
** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL. | ** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL. | ||
Line 33: | Line 31: | ||
=== <span id="3.3.2_EMAIL_Type_Definition">EMAIL Type Definition</span> === <!--span préserve l'ID précédente--> | === <span id="3.3.2_EMAIL_Type_Definition">EMAIL Type Definition</span> === <!--span préserve l'ID précédente--> | ||
:'''Voir : {{RFC2426-fr}} section 3.3.2''' | :'''Voir : {{RFC2426-fr}} section 3.3.2''' | ||
Line 49: | Line 46: | ||
====Initiales==== | ====Initiales==== | ||
N" (Voir sous propriété {{RFC2426-fr}} section 3.1.2) ; pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre", dont le prénom pourrait être, disons, "Adrien" ou "Norbert") ; afin de permettre des valeurs comme : | N" (Voir sous propriété {{RFC2426-fr}} section 3.1.2) ; pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre", dont le prénom pourrait être, disons, "Adrien" ou "Norbert") ; afin de permettre des valeurs comme : | ||
Line 59: | Line 55: | ||
au lieu du plus guindé : | au lieu du plus guindé : | ||
<pre> | <pre> | ||
Line 74: | Line 69: | ||
</pre> | </pre> | ||
et : | |||
<pre> | <pre> | ||
Line 107: | Line 102: | ||
<!--triées par ordre alphabétique--> | <!--triées par ordre alphabétique--> | ||
=== | ===Dates Alternatives=== | ||
Pour les chiffres historiques où aucune naissance ou date de décès ne son connus une paire de dates "'''flourished'''" ou "'''flourished from'''"+"'''flourished to'''" serait utile. | |||
En généalogie, quelques personnes n'ont pas de date de naissance enregistrée, mais leur date de baptême est connue | |||
===<span id=" | ===<span id="Evidence date de décès">Décès</span>=== | ||
aussi connue comme "date of death" | |||
* | *voir [[hcard-date-of-death-fr|hcard-date-of-death]] | ||
===Genre=== | ===Genre=== |
Revision as of 14:38, 3 February 2008
suggestions vCard
En tant que résultat de l'expérience d'utiliser hCard pour baliser les personnes, organisations et informations de contacts en général sur de véritables sites web du monde entier, nous avons découvert quelques aspects de la RFC2426 vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon les propriétés RFC2426 avec une section "new" pour les nouvelles propriétés.
- Auteurs
- Tantek Çelik
- Andy Mabbett
- Traduction en cours
- Christophe Ducamp
Raccourci :
- Cette page peut être référencée sous http://microformats.org/wiki/vs-fr
Suggestions pour les Propriétés Existantes
Les suggestions pour l'amélioration pourrait inclure de nouvelles fonctionnalités et d'autre modifications majeurs à la spécification, organisées sous des titres qui reflètent les numéros de section de la RFC 2426 vCard et des titres. Pour les erreurs de documentation, corrections, errata pour la vCard, reportez-vous svp à vcard-errata.
TEL Type Definition
- Voir : RFC2426 section 3.3.1
- Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : Birmingham City Council (303 1119). Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".
- +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.
- +1 Andy Mabbett : Il existe un nombre limité de types. Notez aussi la problématique cell vs mobile.
- Le "type" pour "TEL" manque d'une option "freephone". Ce pourrait être bien de considérer d'ajouter une valeur "freephone" au "type" pour "TEL". Généralement les numéros de freephone ne sont pas accessibles à partir de l'étranger ainsi cela pourrait aider les parseurs à quelque chose ?
- Le "type" pour "TEL" manque d'une option "SMS short code". (Soulevé dans e-mail, 2008-01-08 par Michael Smethurst)
- Semble que le TEL TYPE 'sms' est une option d'implémentation viable --Guillaume 12:17, 8 Jan 2008 (PST).
- FYI. Quelques partiques existantes de logiciel Personal Information Manager :
- Le Carnet d'Adresses Mac OS X permet de personnaliser les étiquettes TEL mais ne personnalise pas TEL TYPE, même si l'étiquette de personnalisation TEL ressemble à un TEL TYPE
- Microsoft Outlook ne permet pas de personnaliser les valeurs TEL TYPE. Aussi Microsoft Outlook a un tel type "Company" mais malheureusement il n'est pas mappé vers quoi que ce soit dans vCard, ce qui veut dire que si vous exporter un contact avec un tel de société, il est perdu.
- Windows Mobile 6 affiche SMS comme un service qui est uniquement disponible si le tel type est 'mobile'
- Thunderbird 2 (Mac) ne permet pas e personnaliser les valeurs TEL TYPE.
Note : ce pourrait être une bonne idée de regarder proposed registry for "tel:" URI parameters ; tout spécialement "phone-context" URI parameter, parce que cela essaye de résoudre un problème similaire (selon e-mail, 2008-01-08).
EMAIL Type Definition
- Voir : RFC2426 section 3.3.2
- Le "type" pour "EMAIL" manque de distinction pour différentes types d'email, par ex. work ou home.
- Le "type" pour "EMAIL" manque de distinction pour donner une alternative à l'emil comme un formulaire de contact.
URL Type Définition
- voir : RFC2426 section 3.6.8
Le "type" pour "URL" manque de distinction pour diffrents types d'URL, par ex. work ou home.
- En particulier, il devrait y avoir un "type" ou autre indicateur, pour une URL utilisée comme une OpenID.
Suggestions pour de Nouvelles Sous-propriétés
Initiales
N" (Voir sous propriété RFC2426 section 3.1.2) ; pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre", dont le prénom pourrait être, disons, "Adrien" ou "Norbert") ; afin de permettre des valeurs comme :
initials: A. N. family-name: Autre
au lieu du plus guindé :
given-name: A. N. family-name: Autre
Aussi pour les personnes dont le prénom et les initiales sont donnés :
given-name: Theophilus middle-initials: P. family-name: Wildebeest
et :
initials: J. given-name: Paul family-name: Getty
Body
"ADR" (voir la RFC2426 section 3.2.1) sous propriété ; pour les personnes (par ex dans la base lune proposée, l'expédition sur Mars) ou les lieux (par ex. cratère lunaire, montagne sur Mars) hors de la planète.
- Voir aussi geo-extension-nonWGS84-fr
Continent
"ADR" (voir RFC2426 section 3.2.1) sous propriété ; auto-explicatif.
Vessel
"ADR" (voir RFC2426 section 3.2.1) sous-propriété ; pour les personnes, sur disons des bateaux, plateformes pétrolières et même des véhicules spatiaux (par ex l'ISS)
Elevation
"GEO" (voir RFC2426 section 3.4.2) sous-propriété ; aussi connue sous "altitude" ou "depth".
Schema
"GEO" (voir RFC2426 section 3.4.2) sous-propriété ; pour les coordonnées utilisant un schéma non-WGS84 (terrestre et pour les autres corps)
- voir aussi geo-extension-nonWGS84
Language
(par ex. note) si toutes les propriétés ne devraient pas avoir un attribut "language", similaire à lang
en HTML de façon à ce que les agents puissent déterminer comment restituer, et si applicable, les prononcer.
Suggestions de Nouvelles Propriétés
Dates Alternatives
Pour les chiffres historiques où aucune naissance ou date de décès ne son connus une paire de dates "flourished" ou "flourished from"+"flourished to" serait utile.
En généalogie, quelques personnes n'ont pas de date de naissance enregistrée, mais leur date de baptême est connue
Décès
aussi connue comme "date of death"
- voir hcard-date-of-death
Genre
- Il n'existe pas de propriétés vCard pour le genre.
- Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc.. Voir aussi la discussion et genealogy-brainstorming#Gender.
- -1 Tantek : je pense que les tags/categories sont suffisamment bien à cette heure.
- +1 Andy Mabbett : les tags ne sont pas souvent pertinents, selon la discussion citée.
- Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc.. Voir aussi la discussion et genealogy-brainstorming#Gender.
voir genre-exemples et genealogy-brainstorming ; remarquer aussi recherche Google sur "vCard.Gender" .
Genre
Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc. Voir aussi la première discussion.
- -1 Tantek : Je pense que les tags/categories sont suffisamment bien à cette heure.
- +1 Andy Mabbett : les tags sont souvent non appropriés, comme selon la discussion citée.
Global Location Number
Global Location Number (GLN) - généralement utilisé dans les transactions de commerce électronique [1]. Andy Mabbett 06:43, 31 août 2007 (PDT)
Langues parlées
- ISO codes ?
- Capacité ausi d'indiquer la(es) langues de contact préférée(s).
- Per FajRo
méthode préférée de contact
Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.
- Per FajRo
Différenciateur de sujet
- Un "type" pour la vCard elle-même : person, organisation ou place (ou peut-être plus granulaire ou défini par l'utilisateur)
- dans le microformat hCard, l'utilisation de "fn" et "fn org" fair la différence entre les hCards de personnes et d'autres entités, mais nous avons peut-être besoin d'un différenciateur plus approfondi, disons entres les organisations et les lieux (y compris les immeubles, les divisions gouvernementales, les points de parcours, etc.) à déterminer à un certain niveau de granularité. Andy Mabbett 14:30, 11 Jul 2007 (PDT)
- Ceci peut ne plus être nécessaire pour hCard ; car l'usage de "fn [child-of-adr]", pour les endroits et autres lieux a été proposé et débattu (voir email of 2007-12-30. Andy Mabbett 14:04, 8 Jan 2008 (PST)
- dans le microformat hCard, l'utilisation de "fn" et "fn org" fair la différence entre les hCards de personnes et d'autres entités, mais nous avons peut-être besoin d'un différenciateur plus approfondi, disons entres les organisations et les lieux (y compris les immeubles, les divisions gouvernementales, les points de parcours, etc.) à déterminer à un certain niveau de granularité. Andy Mabbett 14:30, 11 Jul 2007 (PDT)
UN LOCCODE
- UN/LOCODE, l'United Nations Code for Trade and Transport Locations, est un schéma de codage géographique développé et maintenu par l'UNCE (United Nations Economic Commission for Europe), une unité des Nations Unies. UN/LOCODE assigne des codes aux lieux utilisés dans le commerce et le transport avec des fonctions tels que les ports de mer, terminaux rail et routier, aéroports, bureaux de postes et points de frontières.
Suggestions pour gérer les encodages
Le standard vCard spécifie que l'US-ASCII est supposé être l'encodage en l'absence d'un "MIME content type header" ou d'un paramètre CHARSET qui indiquerait autre chose. Ceci a été un choix malheureux. les fichiers vCard .vcf stockés sur un système de fichiers local ne contiennent pas de header MIME et les seul moyen d'utiliser en toute confiance un autre encodage que l'ASCII est de marquer chaque champ avec le label "CHARSET=". Ceci rend le flux vCard plus compliqué que nécessaire. Ceci pourrait être simplifié par une révision du standard qui spécifie UTF-8 comme l'encodage par défaut. Ceci pourrrait fonctionner en toute sécurité avec les fichiers existant vCard vcf, qui ne contiennent pas de header MIME de contenu. Le premier champ VERSION vCard serait le même encodé soit sous ASCII ou UTF-8, ainsi les lecteurs pourraient facilement déterminer quel est l'encodage par défaut.
Pour aller plus loin, ceux qui créent des lecteurs de vCard seraient encouragés à supporter les fichiers vCard .vcf à démarrer par une séquence UTF-8 BOM. Si lest trois premiers bits du fichier sont 0xEF 0xBB 0xBF, le fichier texte est encodé UTF-8, et le lecteur de vCard devrait supposer qu'UTF-8 est le défaut. Malheureusement beaucoup de lecteurs échouent aujourd'hui à reconnaître le UTF-8 BOM et voient le fichier comme une vCard corrompue.
Suggestions produites ailleurs
Attribute Exchange
Messagerie Instantanée
WebDAV
Extensions to WebDAV (CardDAV)
defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. This document defines the "addressbook-access" feature of CardDAV.
XEP-0154: User Profile
XEP-0154: User Profile spécifie comment représenter et gérer la donnée de profil concernant les utilisateurs de MI et d'autres entités Extensible Messaging and Presence Protocol (XMPP) en utilisant l'extension XMPP Data Forms. Elle a un nombre bien plus important de propriétés qu'une vCard, mais réinvente et redonne des noms des propriétés précédentes.
FOAF Spécification Vocabulaire
- FOAF Vocabulary Specification 0.91 - Namespace Document 2 November 2007 - OpenID Edition
Note
Le 24 novembre 2006, Paul Hoffman de l'Internet Mail Consortium, responsable du développement et de la promotion du standard vCard, a écrit en réponse à un email provenant de Andy Mabbett l'informant sur sa page web :
Il n'y a presque pas d'intérêt à réviser le standard vCard. Ceci du fait d'un manque d'énergie, pas d'un manque de bonnes suggestions.
Néanmoins, on pourra regarder en anglais events/2007-09-18-calconnect-vcard-workshop pour un événement avec la modification de la vCard à l'ordre du jour.
Voir aussi
- vCard errata
- vcard-implémentations
- hCard
- hcard-brainstorming#Post_vCard_additions
- vCard mailing list - un endroit pour soulever ces problématiques et où des problématiques similaires peuvent être trouvées.
- events/2007-09-18-calconnect-vcard-workshop
- A commentaire sur le language des types TEL, migré parce que ce n'était pas spécifique à vCard
mots-clés : vcard, ietf, rfc, standard