ChristopheDucamp: {{hreview-related-pages-fr}}

2006-12-26T23:19:58Z

← Older revision		Revision as of 23:19, 26 December 2006
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}}

ChristopheDucamp at 18:18, 30 July 2006

2006-07-30T18:18:26Z

New page

<h1>Parsage hReview</h1>

par [http://tantek.com/log/ Tantek Çelik]

(traduction ([[Christophe Ducamp]]

== 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.

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.

__TOC__

== 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.

== étendue ==

Bien que cette page ait été écrite spécifiquement pour expliquer comment parser [[hreview-fr|hReview]], les concepts et algorithmes contenus dedans servent d'exemple pour la façon dont d'autres [[compound-microformat-fr|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.

hreview-parsing-fr - Revision history

ChristopheDucamp: {{hreview-related-pages-fr}}

ChristopheDucamp at 18:18, 30 July 2006