hreview-brainstorming-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
mNo edit summary
 
m ({{hreview-related-pages-fr}})
 
(3 intermediate revisions by the same user not shown)
Line 10: Line 10:
== Idées hReview 0.3 ==
== Idées hReview 0.3 ==


Cette itération de hReview est directement en réponse à [[hreview-feedback-fr]] et aux [[hreview-issues-fr|problématiques hReview]].  Voir ces documents pour plus de détails.
Cette itération de hReview est directement en réponse à [[hreview-feedback-fr|hreview-feedback]] et aux [[hreview-issues-fr|problématiques hReview]].  Voir ces documents pour plus de détails.




Changes from hReview 0.2:
Modifications à partir de  hReview 0.2:


* MUST (instead of SHOULD) use [[hcard|hCard]] for the item description of a business
* DOIT (au lieu de DEVRAIT) utiliser [[hcard-fr|hCard]] pour la description item d'un business
* reviewer changes
* modifications reviewer
** make reviewer *optional* per feedback from Ryan King and Mark Nottingham
** rend le reviewer *optionnel* selon feedback de Ryan King et Mark Nottingham
** If reviewer is absent from the hReview, then look outside the hReview, in the context of the page, for the reviewer.  If there is no "reviewer" outside either, then use the <code><nowiki><address></nowiki></code> for the page.
** Si le reviewer est absent de la hReview, alors regardez en dehors de la hReview, dans le contexte de la page, pour le reviewer.  S'il n'y  pas de "reviewer" en dehors, alors utiliser  <code><nowiki><address></nowiki></code> pour la page.
** MUST (instead of SHOULD) use [[hcard|hCard]] to represent reviewer information
** DOIT (au lieu de DEVRAIT) utiliser [[hcard-fr|hCard]] pour représenter l'information reviewer
* SHOULD use [[hcalendar|hCalendar]] to represent an item of 'type' 'event'
* DEVRAIT utiliser [[hcalendar-fr|hCalendar]] pour représenter un item de 'type' 'event'
** Accepted. We considered making this a MUST, and postponed it to the next version, based on publication experience with 0.3
** Accepté. Nous avons considéré de faire de ça un MUST, et l'avons repoussé à la prochaine version, en se fondant sur l'expérience de publication avec 0.3
* add one decimal digit of precision to ratings' numerical values.
* ajouté un chiffre décimal de précision aux valeurs numériques de 'ratings'.
* use [http://microformats.org/wiki/hcard#Value_excerpting the "value" construct from hCard] (as it is used in "tel" properties for example) to more explicitly markup the rating value when also providing (marking up) the best/worst of a rating.  need to also provide an example that does so.
* utiliser [[hcard-fr#Extraction_de_Valeur|la "valeur" extraite de la hCard]] (comme elle est utilisée dans les propriétés "tel" par exemple) pour baliser plus explicitement la valeur de rating au moment aussi de fournir (baliser) le 'best/worst' d'un 'rating'.  besoin de fournir aussi un exemple qui fasse ainsi.
* add [[rel-license]] to indicate the license of the hReview as a whole.
* ajouté [[rel-license-fr|rel-license]] pour indiquer la licence de la hReview en tant qu'ensemble.
** add this to [[hatom]] as well!
** ajouté cela à [[hatom-fr|hAtom]] !
* permit tags inside ratings to denote rated tags, the same as ratings inside tags per suggestion from Eran Globen.
* tags permis dans les ratings pour indiquer les tags évalué, la même chose que les évaluations dans les tags selon une suggestion de Eran Globen.
* add [[include-pattern]] support to allow multiple reviews for the same item to not repeat the item info.
* ajouté support [[include-pattern-fr|include-pattern]] pour autoriser plusieurs critiques du même item pour ne pas répéter l'info item.
Informative improvements:
améliorations Informatives :
* Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag. E.g. what does Food:18/30 mean?
* Notez que les tags scalaires/évalués utiliseraient idéalement un espace tag qui explique les évaluations pour ce tag. Par exemple que veut dire Food:18/30 ?
* item type abandonné. Si le microformat attendu encapsulé pour un item type donné (par ex. business /hCard) n'est pas présent, alors repliez vers le parsage pour des sous-propriétés item et construisez un microformat implicite encapsulé à partir de ces sous-propriétés. Alternative, prenez simplement les sous-propriétés fn, url, photo qui sont présentes telles quelles, ne vous souciez pas de sous-entendre une hCard.
* "fn" implicite à l'intérieur de l'item. S'il n'y a pas de "fn" alors traitez l'"item" entier comme un "fn".


== Idées hReview 0.4 ==


== Idées hReview ==
* les items de <code>type</code> <code>place</code> DEVRAIENT utiliser un [[geo-fr|geo]] ou [[adr-fr|adr]] ou [[hcard-fr|hCard]] imbriqué comme l'item lui-même .
* les items de <code>type</code> <code>url</code> DOIVENT spécifier une propriété <code>url</code> pour l'item (dans hReview 0.3 en ayant une propriété "url" pour l'item n'est seulement qu'un DEVRAIT)
* notez qu'à l'avenir, les items de <code>type</code> <code>product</code> DEVRAIENT utiliser un microformat embarqué [[product-fr|product]].  [[hlisting-fr|hListing]] a aussi montré qu'il peut y avoir un besoin pour un microformat [[product-fr|product]].
* remarqué et clarifié que l'item <code>type</code> de "url" signifie que la critique ne s'applique *seulement* qu'à la ressource présente sur cet URL, que ce soit une page HTML, une image, un mp3, ou quoi que ce soit. Alors que l'item type "website" s'applique à tout cet URL et contenu dans n'importe quel sous-répertoire.
* est-ce que la propriété <code>version</code> est nécessaire ?  actuellement elle est optionnelle et créée invisiblement par le [http://microformats.org/code/hreview/creator hReview creator]. Il n'est pas clair qu'elle soit nécessaire pour le parsage, parce que toutes les modifications vers hReview ont été rendues compatibles avant/arrière et que c'est notre objectif que de continuer à produire des modifications compatibles.
* est-ce que la propriété <code>type</code> est nécessaire ?  Elle aussi est créée invisiblement par le [http://microformats.org/code/hreview/creator hReview creator].
* laisser tomber <code>self</code> à partir du <code>permalink</code>. Même [[hatom-fr|hAtom]] utilise simplement <code>bookmark</code>, ainsi devrait faire hReview.
* devrait autoriser plusieurs licences


* items of <code>type</code> <code>place</code> SHOULD use a nested [[geo]] or [[adr]] or [[hcard|hCard]] as the item itself.
==Pages apparentées==
* items of <code>type</code> <code>url</code> MUST specify a <code>url</code> property for the item (in hReview 0.3 having "url" property for the item is only a SHOULD)
{{hreview-related-pages-fr}}
* note that in the future, items of <code>type</code> <code>product</code> SHOULD use a nested [[product]] microformat.  [[hlisting|hListing]] has also shown that there may be need for a [[product]] microformat.
* note and clarify that item <code>type</code> of "url" means the review applies to *only* the resource present at that URL, whether it is an HTML page, an image, an mp3, whatever.  Whereas item type of "website" applies to everything at that URL and contained in any subdirectories thereof.
* is the <code>version</code> property needed?  currently it is optional and created invisibly by the [http://microformats.org/code/hreview/creator hReview creator]. It is not clear that it is necessary for parsing either, since all changes to hReview have been forward/backward compatible and it is our goal to continue to make compatible changes.
* is the <code>type</code> property needed?  It too is created invisibly by the [http://microformats.org/code/hreview/creator hReview creator].
* drop <code>self</code> from the <code>permalink</code>.  Even [[hatom|hAtom]] just uses <code>bookmark</code>, so should hReview.
* should allow multiple license

Latest revision as of 22:49, 26 December 2006

brainstorming hReview

Editeur/Auteur
Tantek Çelik
Traduction française en cours
Christophe Ducamp

Ce document est destiné à capturer des idées sur l'amélioration/l'itération sur hReview.


Idées hReview 0.3

Cette itération de hReview est directement en réponse à hreview-feedback et aux problématiques hReview. Voir ces documents pour plus de détails.


Modifications à partir de hReview 0.2:

  • DOIT (au lieu de DEVRAIT) utiliser hCard pour la description item d'un business
  • modifications reviewer
    • rend le reviewer *optionnel* selon feedback de Ryan King et Mark Nottingham
    • Si le reviewer est absent de la hReview, alors regardez en dehors de la hReview, dans le contexte de la page, pour le reviewer. S'il n'y pas de "reviewer" en dehors, alors utiliser <address> pour la page.
    • DOIT (au lieu de DEVRAIT) utiliser hCard pour représenter l'information reviewer
  • DEVRAIT utiliser hCalendar pour représenter un item de 'type' 'event'
    • Accepté. Nous avons considéré de faire de ça un MUST, et l'avons repoussé à la prochaine version, en se fondant sur l'expérience de publication avec 0.3
  • ajouté un chiffre décimal de précision aux valeurs numériques de 'ratings'.
  • utiliser la "valeur" extraite de la hCard (comme elle est utilisée dans les propriétés "tel" par exemple) pour baliser plus explicitement la valeur de rating au moment aussi de fournir (baliser) le 'best/worst' d'un 'rating'. besoin de fournir aussi un exemple qui fasse ainsi.
  • ajouté rel-license pour indiquer la licence de la hReview en tant qu'ensemble.
  • tags permis dans les ratings pour indiquer les tags évalué, la même chose que les évaluations dans les tags selon une suggestion de Eran Globen.
  • ajouté support include-pattern pour autoriser plusieurs critiques du même item pour ne pas répéter l'info item.

améliorations Informatives :

  • Notez que les tags scalaires/évalués utiliseraient idéalement un espace tag qui explique les évaluations pour ce tag. Par exemple que veut dire Food:18/30 ?
  • item type abandonné. Si le microformat attendu encapsulé pour un item type donné (par ex. business /hCard) n'est pas présent, alors repliez vers le parsage pour des sous-propriétés item et construisez un microformat implicite encapsulé à partir de ces sous-propriétés. Alternative, prenez simplement les sous-propriétés fn, url, photo qui sont présentes telles quelles, ne vous souciez pas de sous-entendre une hCard.
  • "fn" implicite à l'intérieur de l'item. S'il n'y a pas de "fn" alors traitez l'"item" entier comme un "fn".

Idées hReview 0.4

  • les items de type place DEVRAIENT utiliser un geo ou adr ou hCard imbriqué comme l'item lui-même .
  • les items de type url DOIVENT spécifier une propriété url pour l'item (dans hReview 0.3 en ayant une propriété "url" pour l'item n'est seulement qu'un DEVRAIT)
  • notez qu'à l'avenir, les items de type product DEVRAIENT utiliser un microformat embarqué product. hListing a aussi montré qu'il peut y avoir un besoin pour un microformat product.
  • remarqué et clarifié que l'item type de "url" signifie que la critique ne s'applique *seulement* qu'à la ressource présente sur cet URL, que ce soit une page HTML, une image, un mp3, ou quoi que ce soit. Alors que l'item type "website" s'applique à tout cet URL et contenu dans n'importe quel sous-répertoire.
  • est-ce que la propriété version est nécessaire ? actuellement elle est optionnelle et créée invisiblement par le hReview creator. Il n'est pas clair qu'elle soit nécessaire pour le parsage, parce que toutes les modifications vers hReview ont été rendues compatibles avant/arrière et que c'est notre objectif que de continuer à produire des modifications compatibles.
  • est-ce que la propriété type est nécessaire ? Elle aussi est créée invisiblement par le hReview creator.
  • laisser tomber self à partir du permalink. Même hAtom utilise simplement bookmark, ainsi devrait faire hReview.
  • devrait autoriser plusieurs licences

Pages apparentées

Retrieved from "http://microformats.org/wiki/index.php?title=hreview-brainstorming-fr&oldid=32141"