hreview-parsing-fr

Parsage hReview

par Tantek Çelik

(traduction (Christophe Ducamp

introduction

Quand hReview a été initialement développé, il était clair pour moi de l'expérience avec le développement de hCard et hCalendar que chaque propriété, valeur et structure étant introduite dans hReview était parsable sans ambiguité, à la fois pour l'existence de hReviews dans le (X)HTML arbitraire (et n'importe où où ce (X)HTML arbitraire peut être embarqué, par exemple RSS, Atom, "XML générique"), et dans les propriétés et valeurs en général.

L'objectif de ce document est de saisir les spécificités de la façon de parser hReview et toutes ses propriétés afin d'augmenter l'interopérabilité du format.

statut

Ce document est un brouillon incomplet. Utilisez le document parsage hCard pour un guide là où existe des trous. En fait, beaucoup de cela sera clairement reconnu par quiconque familier avec le parsage hCard parce qu'ayant été copié-collé à partir de cette source. A un certain point (peut-être après avoir écrit parsage hCard), je résumerai les aspects communs du parsage de microformat composé et écrirai un document distinct parsage qui gèrera tous les aspects généraux tel que la gestion d'url, la recherche du nom de classe racine, la recherche de propriétés, le traitement de microformats embarqués comme des emballeurs etc.

étendue

Bien que cette page ait été écrite spécifiquement pour expliquer comment parser hReview, les concepts et algorithmes contenus dedans servent d'exemple pour la façon dont d'autres microformats composés doivent être parsés.

gestion d'URL

Un parseur hReview peut commencer par un URL à retrouver.

Si l'URL manque d'un identiant fragment, alors le parseur devrait parser la ressource entière retrouvée pour le hReview.

Si l'URL a un identifiant fragment, alors le parseur ne devrait seulement parser que le noeud indiqué par l'identifiant fragment et ses descendants, chercher les hReviews, démarrant par le noeud indiqué, qui peut lui-même être un hReview unique.

nom de classe racine

Chaque microformat composé démarre 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 doit être contraire à avoir été utilisé en dehors du contexte du microformat. En choisissant un tel nom de classe, le microformat évite (pour tous les objectifs pratiques) de rentrer en collision avec les noms de classes 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 à venir.