vcard-suggestions-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 10: Line 10:


=== 3.3.1 TEL Type Definition ===
=== 3.3.1 TEL Type Definition ===
* 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 34: Line 33:
===Elévation===
===Elévation===
*Voir [[geo-elevation-examples-fr|geo-elevation-exemples]]
*Voir [[geo-elevation-examples-fr|geo-elevation-exemples]]
== Suggestions pour gérer les encodages ==
The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.
Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.





Revision as of 11:49, 14 April 2007

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 Type Definition

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

Suggestions pour de Nouvelles Propriétés

Genre

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

Décès

  • Il n'y a pas moyen de baliser une personne comme étant décédée - soit par une marque "deceased" ou date-de-décès. Un moyen de contourner : ajouter le tag/category "deceased". Voir aussi la liste de discussion sur le tag pour 'deceased'
    • -1 Tantek : je pense que les tags/categories sont bien suffisantes à cette heure.
    • +1 Andy Mabbett : les tags sont souvent inappropriés, comme dans l'email cité. DoD est plus spécifique (et souvent utilisé dans la vraie vie pour les biographies et les nécrologies comme van Gogh sur Wikipedia). Notez aussi que Persondata de Wikipedia qui s'aligne très proche de la hCard mais a des champs supplémentairs de date et lieu de naissance. Andy Mabbett 13:06, 28 Jan 2007 (PST)
    • +1 for date-of-death Ciaran McNulty : la date-de-décès est une information utile dans quelques applications (tout particulièrement la généalogie).
    • -1 pour le flag 'deceased' Ciaran McNulty : le tag peut couvrir cette sorte de tag binaire.

Messagerie Instantanée

Elévation

Suggestions pour gérer les encodages

The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.

Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.


Note

Le 2006-11-24, 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.

Voir aussi