hcard-parsing-fr
parsage hCard
par Tantek Çelik
(traduction en cours Christophe Ducamp)
introduction
Quand j'ai initialement conçu hCard, il était clair pour moi de savoir comment parser sans ambiguïté tant l'existence de hCards dans du (X)HTML arbitraire (et n'importe où ce pouvait être embarqué dans du (X)HTML arbitraire, par ex. RSS, Atom, "XML générique") que les propriétés et valeurs de hCard.
J'ai travaillé directement avec Brian Suda pour saisir 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 identifiant de fragment, alors le parseur devrait parser la ressource complète retrouvée pour les hCards.
Si l'URL a un identitfiant de fragment, alors le parseur ne devrait parser que le noeud indiqué par l'identifiant de fragment et ses descendants, chercher des hCards, démarrer avec le noeud indiqué, qui peut lui-même être une simple hCard.
nom de 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 profil XMDP de hCard. 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 déclaration de 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 :