hcard-parsing-fr

From Microformats Wiki
Revision as of 20:56, 17 April 2007 by RxnOr3 (talk | contribs)
Jump to navigation Jump to search

parsage hCard

par Tantek Çelik

(traduction en cours Christophe Ducamp)

introduction

Quand j'ai d'abord conçu hCard, il était clair pour moi de savoir comment parser sans ambiguïté l'existence de hCards dans du (X)HTML arbitraire (et n'importe où pouvait être embarqué du (X)HTML arbitraire, par ex. RSS, Atom, "XML générique"), et les propriétés et valeurs de hCard.

J'ai travaillé directement avec Brian Suda pour capturer ces idées dans une implémentation, et Brian a écrit X2V, un script XSLT qui convertit les hCards en vCards, démontrant ainsi simultanément la parsabilité des hCards et l'utilité immédiate du contenu hCard interopérant avec les applications existantes massivement répandues de vCard.

Je vais maintenant documenter ces idées directement sur cette page, de façon à ce que des implémentations supplémentaires puissent être construites à partir de ces concepts élémentaires, plutôt que d'avoir à faire du reverse engineering sur X2V.

étendue

Bien que cette page soit écrite spécifiquement pour expliquer comment parser hCard, les concepts et algorithmes contenus à l'intérieur servent comme exemple pour la façon dont d'autres microformats composés vont se faire parser.

Gestion URL

Un parseur hCard peut commencer par un URL à récupérer.

Si l'URL manque d'un fragment identifiant, alors le parseur devrait parser la ressource complète récupérée pour les hCards.

Si l'URL a un fragment identifiant, alors le parseur ne devrait parser que le noeud indiqué par le fragment identifiant et ses descendants, chercher des hCards, démarrer avec le noeud indiqué, qui peut être lui-même un simple hCard.

nom classe racine

Chaque microformat composé commence par un élément racine avec un nom de classe relativement unique. Par cela, je veux dire un nom de classe qui n'est pas simplement un mot commun, et qui devra être peu probablement être utilisé à l'extérieur du contexte du microformat. En choisissant un tel nom de classe racine, le microformat évite (pour toutes les intentions pratiques) de rentrer en conflit avec des noms de classe existants qui peuvent exister dans le contexte (X)HTML. Ceci est essentiel pour permettre à de tels microformats composés d'être embarqués dans le contenu actuel, existant, tout comme le contenu futur.

Heureusement ce n'est pas un nouveau problème à résoudre. Les noms d'objets racine choisis pour la vCard (RFC 2426) et iCalendar (RFC 2445) ont eu de la même manière à éviter de telles collisions et l'ont fait en choisissant des noms qui devraient peu probablement être introduits à l'intérieur d'un objet contexte MIME. Le principe de réutilisation dicte le fait que nous devrions réutiliser les noms pour ces objets racine dans ces RFCs plutôt que d'inventer les nôtres. Compte tenu de la même sémantique, un design devrait réutiliser les noms, plutôt que d'inventer un second nom pour la même sémantique (une erreur commune de design produite dans des environnements qui requièrent des espaces-noms).

Dans la spécification vCard, les noms ne sont pas sensibles à la casse du aux (manques) d'exigences de leur contexte. Les noms de classes (X)HTML sont sensibles à la casse par ces spécifications. De ce fait, nous sommes obligés de choisir une casse canonique pour les noms de classe équivalents des noms d'objets, et des noms de propriétés de vCard. Toutes les bas de casse sont choisies pour suivre le réglage précédent (c'est à dire le modèle reuse) par le XHTML, ce qui devait de la même manière canoniser la casse de l'élément et les noms d'attributs que cela prenait du HTML4, qui lui-même était insensible à la casse du fait de son contexte (SGML). En outre, les raisons d'éviter le mélange de casse (par ex. la casse chatmot) dans le contexte de noms de classes peuvent être trouvées dans l'article A Touch of Class, spécifiquement, la section titrée Class sensitivity.

Par conséquent, le nom de classe racine d'un hCard est "vcard".

trouver des hCards

Un document (X)HTML indique qu'il peut contenir des hCards en référençant le hCard XMDP profile. Voir XMDP pour plus de détails.

Un parseur trouve des hCards dans un contexte (X)HTML en cherchant des éléments avec le nom de classe racine "vcard" tout simplement comme le fait le sélecteur de classe CSS suivant :

 .vcard

Par exemple, la règle de style CSS suivante fixe l'arrière plan de toutes les hCards en vert :

 .vcard { background: green; }

Notez que l'attribut de classe (X)HTML est un espace séparé par des noms de classe.

de ce fait tout ce qui suit sont des éléments racines valides hCard :