hcard-brainstorming-fr

From Microformats Wiki
Jump to navigation Jump to search

hCard Brainstorming

Cette page est pour brainstormer sur les différentes utilisation et les détails de hCard.

Auteurs

Contributeurs

Traduction en cours

Problèmes Etant Résolus

Quelques-un des problèmes que hCard aide à résoudre :

  • devoir saisir les cartes de visite qui deviennent obsolètes (s'abonner à la place à la hCard syndiquée de quelqu'un).
  • "mise à jour de votre info de contact email" ennuyeuse à partir de différents services d'informations de contacts centralisés.

Exemples

  • Voir exemples hCard, qui fournit plusieurs exemples illustrés instructifs, tout comme des exemples de hCard 1:1 pour chaque exemple dans la RFC 2426.

Utiliser la RFC2806 avec hCard

RFC 2806 defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : Uniform Resource Identifier (URI) SCHEMES 

tel   telephone [RFC2806]
fax   fax       [RFC2806]
modem modem     [RFC2806]

It is practical to write your tel number like this. 

<a class="tel"      href="tel:+1-919-555-7878">+1-919-555-7878</a>

or even 

<a class="tel"      href="tel:+1-919-555-7878">Mr Smith's phone</a>

You can add support for "tel:" to your desktop and to your browser

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing. 

a[href^="tel:"]:before {
    content: '\260f  ' !important;
    padding-left: 20px !important; }

a[href^="mailto:"]:before {
    content: '\2709  ' !important;
    padding-left: 20px !important; }

Encoder des attributs "modernes"

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples-fr#Nouveaux_Types_d.27Information_de_Contact

Still to be addressed:

  • iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
    • <a class="email" href="mailto:steve@mac.com">...
  • MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
  • Internet Relay Chat (IRC), use "irc:" URLs.

Styles CSS

Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code, then you can hide that tag in CSS with the following code: 

<span style="display: none">Hidden Data</span>

Transforming applications will still find the data and use it when converting hCards to vCards.

Auto-Découverte

There is currently a debate over the best way to add an auto discovery link to your HTML to extract the vCard.

On the page with the hCard encoding, the best link would be as follows: <link rel="alternate" type="text/vcard" href="..." /> this HTML page is an alternate view of the vCard.

EtanWexler disagrees with the value of the “type” attribute. The Internet Assigned Numbers Authority has no registration for a “text/vcard” type. The registered and appropriate type for vCard entities is “text/directory”, as defined in Internet RFC 2425, “A MIME Content-Type for Directory Information”. RFC 2426, “vCard MIME Directory Profile”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”. It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, Björn Höhrmann sent to the HTML Working Group a request for clarification on the issue.

When on a different page, referencing that encoded page in the href would not be an alternate view of the current page. So a different rel type must be established to decribe that relationship. The ideas vary from specific to vague. The list and categories follow: 

rel="contactinfo"
rel="profile"
rel="author"
rel='PIM'
rel='person'
rel='about'
rel='contact'
rel='hcard'
rel='microformat'

Example of mixing two rel types to a single page. rel="hcard xfn"

Note: using rel="vcard" indicates a link directly to a vCard. If the document links to an hCard instead, the indication is untrue and inappropriate.

Auto-Découverte pour XFN

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

améliorations geo

These improvements apply to both geo et hCard.

I (Tantek) have seen examples of where there is a human viewable/clickable presentation of a point on a map, and the desire to include the machine readable geo information with the same element, e.g. something like: 

<abbr class="geo" title="machine-readable-geo-info">
 human readable/clickable point on a map
</abbr>

But to do this we must specify a syntax for putting both the latitude and longitude into the title attribute as the machine-readable-geo-info.

Fortunately, there already is a syntax for that, in vCard RFC 2426 3.4.2: 

   Type value: A single structured value consisting of two float values
   separated by the SEMI-COLON character (ASCII decimal 59).

   Type special notes: This type specifies information related to the
   global position of the object associated with the vCard. The value
   specifies latitude and longitude, in that order (i.e., "LAT LON"
   ordering).

...

   Type example:

        GEO:37.386013;-122.082932

Thus: 

<abbr class="geo" title="37.386013;-122.082932">
 Mountain View, CA
</abbr>

I think this is pretty much a no-brainer, because the rules for parsing "geo" are simply altered to:


latitude longitude raccourci

If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property (e.g. following rules for parsing <abbr title>, <img alt> etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order.

geo liens

In addition, people may publish Google Maps links like this:

<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>

(N.B. I tried and failed to get Yahoo Maps and local to do something intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").

Is it worth permitting this to be a geo as well?

I'm raising this to make sure it is considered.

However, my first guess is NO for two reasons.

  1. No such examples in the wild have been documented or seen as of yet (I certainly haven't seen any).
  2. It would involve additional parsing requirements which are almost certainly going to be site/domain specific, and encoding a particular site's query parameter syntax into a format seems like a bad idea (against principle of decentralization).

This could be mitigated if mapping services would simply accept the literal vCard GEO syntax "37.386013;-122.082932", e.g. http://maps.google.com/maps?q=37.386013;-122.082932 (which currently doesn't work) then we could make a simple rule such as for hyperlinks, parse the href attribute for a geo value at the end of the href, delimited before the value by a "=" (or perhaps "/" for services that use friendlier URLs).

altitude

Some folks have asked for "altitude" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.

radius/zoom

Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.

ISO6709

There is a description method for geographic coordinates named ISO6709 though some differs from the notation of vCard. It can describe latitude and the longitude. Height is optional. If ISO6709 is used, it is likely to be able to write as follows. 

examples
<abbr class="geo" title="+37.386013-122.082932/">
 Mountain View, CA
</abbr>

<abbr class="geo" title="+275916+0865640+8850/">
 Mount Everest
</abbr>

Problématiques avec les Applications vCard

Voir vcard-implémentations.

Questions Ouvertes

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile. 

...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...

-- Brian Suda

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example: 

<a href="http://mywebsite.com/" class="fn n">
    <span class="given-name">John</span>
    <span class="other-names">Q.</span>
    <span class="family-name">Public</span>
</a>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN: 

John Q. Public

    John
    Q.
    Public

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- Brian Suda

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- Tantek

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with ? This may give the hCard some added semantic value in the XHTML document. 

<span class="agent"> 
 <span class="vcard">
  <span class="email">
   <a class="internet" href="mailto:jfriday@host.com">
    <dfn>
       <span class="fn">Joe Friday</span>
    </dfn>
   </a>
  </span>
  <span class="tel">+1-919-555-7878</span>
  <span class="title">Area Administrator, Assistant</span>
 </span>
</span>

-- Ben Ward

Applications

Les Applications qui sont conscientes des hCards ou qui peuvent convertir les hCards en formats vCard.

favelet(s) de copie hCards

  • Je pense qu'un Favelet fonctionnerait bien ici. Quand vous trouvez une page qui est compatible hCard, vous cliquez sur le favlet et vous obtenez vous-même une vCard. C'est fait ! Voir X2V dans la section des implémentations de la spec hCard.

Icônes distribuées de commentateurs

  • Voir using hCards in your blog pour un exemple de hCards utilisées pour les auteurs des commentaires (commentateurs). Le système utilisé là, "Gravatars", est un site centralisé qui sert les icônes de commentateurs qui exige un login, etc.

Et si nous donnions à chaque commentateur l'option d'héberger sa propre icône ?

Une implémentation d'icône de commentateur distribué pourrait fonctionner comme ça :

  1. Vu l'URL d'un commentateur, chercher un élément <address> avec le nom de classe "vcard" sur l'URL du commentateut. L'élément <address> est supposé être l'information de contact pour la page. (voir hCard FAQ pour plus d'infos), aussi cela fait du sens.
  2. Puis, chercher le premier élément dans cette hCard qui ait un nom de classe de "logo".
  3. En espérant que cet élément soit un <img>, et si oui, utiliser son src pour recevoir l'icone du commentateur.
  4. Basta. Vous avez des icônes de commentateurs distribuées !

Prévention du Spam

hCard utilise les liens mailto: et par conséquent, il hérite automatiquement des inconvénients des liens mailto: : Ces liens peuvent être facilement détectés par les spiders d'email (utilisé par les spammeurs).

Les adresses email sont piochées comme toute autre lien crawlé par un moteur de recherche et les crawleurs de confiance peuvent être dissuadés d'ajouter de l'emphase tout en indexant ces liens en incluant rel="nofollow" (Voir rel-nofollow). Néanmoins, les adresses email utilisées pour le spam sont crawlées par les spiders d'email qui ignoreront probablement cet attribut.

Il existe des moyens d'empêcher la détection d'adresses email par les simples spiders d'email, tout en retenant une totale compatibilité avec les applications (X)HTML. Un moyen commun est d'"encoder" le "m" de "mail" et "@" avec des entités caractères, à ce stade c'est imprudent de suivre une convention de seulement encoder les caractères spécifiques parce que les spiders email peuvent aussi piocher ça :

Exemple de lien original : 

<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>

Exemple de lien "encodé" (avec l'ajout de rel-nofollow) : 

<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;exemple.com">john.smith&#064;exemple.com</a>

Les simples spiders email qui ne font pas le décodage d'entité caractère ne pourront par conséquent pas trouver votre adresse email.

Note : Peut-être qu'il y a ou aura des spiders email qui peuvent décoder les entités, ainsi cette technique n'aidera que pour les spiders email de mauvaise qualité.

(Voir aussi : http://rbach.priv.at/Misc/2005/EmailSpiderTest)

Autres méthodes de prévention à considérer

  • Using server-side code to implement character entities randomly
  • Displaying the address in a way thought to be only human readable (thus breaking the link):
    • Using an image instead of text (could still be machine readable using OCR)
    • Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
  • Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
  • Pointing to an email form or other URL instead of an email address

Tutoriels

  • How to hCard encode entries in Popular blog software.
  • Good reasons to publish your hCard
    • as a business, get people to put you in their address book so they'll find you later
    • as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

Parsage

Voir la page séparée parser hCard.

additions aux Post vCard

Quelques personnes ont trouvé la vCard limitée en termes de données/propriétés/champs qu'elles voulaient exprimer dans l'information de contact. Quelques implémentations utilisent les extensions vCard pour exprimer de telles informations.

Cette section est pour la documentation de telles additions suggérées. Remarquez que nous aurons besoin d'évidence empirique d'exeples véritables venant du *vrai monde* sur le Web de personnes publiant cette information comme une partie de l'information de contact, avant de considérer de telles ajouts/extensions.

  • altitude. Extrait de hcard-problématiques.
    • Aucune évidence fournie que l'information de contact sur le Web publie cette information.


TODO

  • Le profil hCard a besoin de vérification et peut-être d'un URL pour retrouver le véritable XMDP, plutôt qu'un texte <pre> sur une page wiki.
  • Compléter la traduction des exemples extraits de la spec vCard dans hCard, et la placer sur une page séparé d'exemples de hCard.
  • Créer un exemple "riche" mais réaliste de hCard, disons par exemple un commercial, qui veut mettre tout un paquet d'information de contact sur son site web afin de pouvoir être trouvé/contacté facilement.
  • Fournir des exemples sur la manière d'encoder des comptes de messagerie instantanée. Imaginer quels seraient les URLS mailto: ou aim: dans hCard et comment cela apparaîtrait dans vCard. Et jeter un oeil sur ce que les applications vCard font aujourd'hui des adresses IM.

Références

Références Normatives

Références Informatives

Autres Implémentations/Idées

  • Representing vCard Objects in RDF/XML This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
  • It would also be possible to convert XFN and hCard to FoaF and back.


Noms de composants Ambigus

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

  1. If the name is one word, attempt implied nickname optimization
  2. If the name is two words, attempt implied n optimization
  3. For three or more words
    1. Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
    2. Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

Suggestions Acceptées

Donnée d'encodage Company sous une Business Card (proposition)

( Acceptée : http://microformats.org/wiki/hcard-fr#Info_Contact_Organisation )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that Apple Address Book supports this semantic when importing vCards.

See the Technorati Contact Info for an example.

Optimisation implicite "FN et N" (proposition)

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

HISTORIQUE :

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSITION :

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.

Suggestions Rejetées

Suggestion: The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example: 

<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

La collection de tests hcard et hcalendar avait été annoncée dans le message du 7 juin de User:RyanKing.

Gérée dans un repository hg. hg/mercurial est un système distribué de contrôle de révision. Ce peut être un peu embêtant de désapprendre les habitudes de cvs ; il existe quelques bon diagrammes dans les dias d'une présentation du 19 juin que Bryan O'Sullivan a faite chez google. La page de présentations mercurial a aussi un lien vers une vidéo de 50 minutes.

Tests Externes

Ceux-ci sont résumés par les tests au-dessus, c'est bien ça ?

DanConnolly est en train de travailler sur hcardTest.html ; la version actuelle est toujours disponible. (Je ne sais pas pourquoi cvsweb utilise l'url ordinaire pour le changelog plutôt que la version actuelle.)

MarkPilgrim maintient un ensemble de tests hCard pour utilisation avec son parseur hCard


Pages en rapport

La spécification hCard est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront rajoutés. Ces idées, problématiques et questions sont maintenues sur des pages distinctes.

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-brainstorming-fr&oldid=11373"