hreview-parsing-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
mNo edit summary
 
m ({{hreview-related-pages-fr}})
 
Line 4: Line 4:




(traduction ([[Christophe Ducamp]]
(traduction ([[Christophe Ducamp]])


== introduction ==
== introduction ==


Quand [[hreview-fr|hReview]] a été initialement développé, il était clair pour moi de l'expérience avec le développement de [[hcard-fr|hCard]] et [[hcalendar-fr|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.
Quand [[hreview-fr|hReview]] a été initialement développé, il était clair pour moi de l'expérience avec le développement de [[hcard-fr|hCard]] et [[hcalendar-fr|hCalendar]] que chaque propriété, valeur et structure étant introduites 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.
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.
Line 17: Line 17:
== statut ==
== statut ==


Ce document est un brouillon incomplet. Utilisez le document [[hcard-parsing-fr|parsage hCard]] pour un guide là où existe des trous. En fait, beaucoup de cela sera clairement reconnu par quiconque familier avec le [[hcard-parsing-fr|parsage hCard]] parce qu'ayant été copié-collé à partir de cette source. A un certain point (peut-être après avoir écrit [[hcalendar-parsing-fr|parsage hCard]]), je résumerai les aspects communs du parsage de  [[compound-microformat-fr|microformat composé]] et écrirai un document distinct [[parsing-fr|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.
Ce document est un brouillon incomplet. Utilisez le document [[hcard-parsing-fr|parsage hCard]] pour un guide là où existe des trous. En fait, beaucoup de cela sera clairement reconnu par quiconque familier avec le [[hcard-parsing-fr|parsage hCard]] parce qu'ayant été copié-collé à partir de cette source. A un certain point (peut-être après avoir écrit le [[hcalendar-parsing-fr|parsage hCard]]), je résumerai les aspects communs du parsage de  [[compound-microformat-fr|microformat composé]] et écrirai un document distinct [[parsing-fr|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 embarqueurs etc.


== étendue ==
== étendue ==
Line 27: Line 27:
Un parseur hReview peut commencer par un URL à retrouver.
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 manque d'un fragment identifieur, 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.
Si l'URL a un fragment identifieur, alors le parseur ne devrait ''seulement'' parser que le noeud indiqué par le fragment identifieur 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 ==
== 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.
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.
== Pages en rapport ==
{{hreview-related-pages-fr}}

Latest revision as of 23:19, 26 December 2006

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 introduites 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 le 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 embarqueurs 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 fragment identifieur, alors le parseur devrait parser la ressource entière retrouvée pour le hReview.

Si l'URL a un fragment identifieur, alors le parseur ne devrait seulement parser que le noeud indiqué par le fragment identifieur 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.

Pages en rapport