vcard-suggestions-fr

From Microformats Wiki
Revision as of 16:20, 5 January 2008 by ChristopheDucamp (talk | contribs) ([fr: sync'd with english version])
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 RFC 2426 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 le numéro de section de RFC 2426 pour amélioration des propriétés actuelles, et une section "new" pour les nouvelles propriétés.

Auteurs
Tantek Çelik
Andy Mabbett
Traduction en cours
Christophe Ducamp

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.

3.3.1 TEL Définition Type

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

3.3.2 EMAIL Définition Type

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

3.3.3 Suggestion pour Définition de Types D

Nous ne pouvons pas avoir un nom type générique parce que nous devons localiser en français. Aussi, pour nous le numéro de téléphone d'une hCard est : <div class="tel"> <span class="type">Travail</span> : <span class="value">0321596224</span> </div>

Comment un robot reconnaîtra ce type ? Nous ne pouvons pas spécifier chaque type dans chaque langue dans la spécification. C'est pourquoi je pense que quelque chose comme ceci serait mieux : Travail : <span class="telwork">0321596224</span>

SVP, utiliser les attributs class et id SEULEMENT pour les spécifications microformats ! #cdata et #data XML sont localisés ! Merci.

Suggestions pour de Nouvelles Propriétés

Genre

  • Il n'existe pas de propriétés de Carte pour le 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.

Evidence du Genre

Voir genre-exemples.

  • Beaucoup de pages publient de l'information de genre implicite, pas facilement parsable par une machine - en utilisant des noms (André, Andrée), des titres (Mr, Mrs, Miss), des relations (mari, frère), des pronoms (il, elle), etc. Ajoutez svp de telles pages avec leurs URLs spécifiques et citations de l'information explicite, et les genres implicites sur la page genre-examples.

Voir aussi genealogy-brainstorming

Décès

Date de Décès évidence

Messagerie Instantanée

Subject differentiator

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)

Elévation

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)

Initiales

Pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre") ; afin de permettre un marquage comme : 

<span class="vcard">
<span class="fn n">
<span class="initials">A. N.</span>
<span class="family-name">Autre</span>
</span>
</span>

Alternative dates

Pour les personnages historiques, où aucune date de naissance / ou date de décès ne sont connus, une parie date "étendue" ou "étendue à partir de"+"étendue vers" 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.

Continent

adr devrait avoir un code optionnel continent en propriété enfant.

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

WebDAV

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

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

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