vcard-suggestions-fr

From Microformats Wiki
Revision as of 18:46, 20 December 2008 by Brian (talk | contribs) (Reverted edits by DomraCricd (Talk) to last version by ChristopheDucamp)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

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)

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"

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.

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)

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

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


mots-clés : vcard, ietf, rfc, standard

Retrieved from "http://microformats.org/wiki/index.php?title=vcard-suggestions-fr&oldid=36257"