hreview-issues-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
mNo edit summary
m (Reverted edit of TpwQki, changed back to last version by Tantek)
 
(5 intermediate revisions by 4 users not shown)
Line 3: Line 3:
Voici des problématiques soulevées à l'extérieur à propos de [[hreview-fr|hReview]] ayant largement différents degrés de mérite. De ce fait quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont soulevées à nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des changements ou des explications améliorées dans la spec. Les problématiques proposées peuvent (et le pourront probablement) être éditées et récrites pour une meilleure concision, apporter clarté, calme, rationalité et autant que possible sous un point de vue neutre. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]
Voici des problématiques soulevées à l'extérieur à propos de [[hreview-fr|hReview]] ayant largement différents degrés de mérite. De ce fait quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont soulevées à nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des changements ou des explications améliorées dans la spec. Les problématiques proposées peuvent (et le pourront probablement) être éditées et récrites pour une meilleure concision, apporter clarté, calme, rationalité et autant que possible sous un point de vue neutre. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]


Voir les [[hcalendar-issues-fr|problématiques hcalendar]] et les  [[hcard-issues|problématiques hcard]] apparentées.
Voir les [[hcalendar-issues-fr|problématiques hcalendar]] et les  [[hcard-issues-fr|problématiques hcard]] apparentées.


== Gabarit ==
== Gabarit ==
Line 34: Line 34:
== gamme par défaut ==
== gamme par défaut ==
* 2006-02-23 soulevée par Andy Mabbett
* 2006-02-23 soulevée par Andy Mabbett
*# ''Not all marks give ratings "out of five". The value should be a percentage. Zero should be allowed.''
*# ''Ce ne sont pas toutes les marques qui donne des ratings "sur cinq". La valeur devrait être un pourcentage. Zéro devrait être permis.''
*#* REJETE IGNORES RESEARCH.  Most [[review-examples|real-world examples]] have a range of 1.0-5.0 not a percentage. You may set the "best" bound to 100 explicitly, and the "worst" bound to 0 explicitly per the spec if necessary.
*#* REJETE IGNORES RESEARCH.  La plupart des [[review-examples-fr|exemples du vrai monde]] ont une gamme de notation de 1.0-5.0 et pas un pourcentage. Vous pouvez paramtérer le "best" lié à 100 explicitement, et le "worst" lié à 0 explicitement par la spéc si c'est nécessaire.
*#* "most" != "all"; indeed, the page you cite has examples of "1-10" and "0-100%". I never claimed that many examples use percentages, but I'm sure a mathematician would explain that values in the range "1-5" may be expressed as percentages.
*#* "most" != "all"; bien sûr, la page que vous citez a des exemples de "1-10" et "0-100%". Je n'ai jamais prétendu que beaucoup d'exemples utilisent des pourcentages, mais suis sûr qu'un mathématicien expliquerait que les valeurs dans la gamme "1-5" peuvent être exprimées sous des pourcentages.
*#* REJETE RTFM.  Most examples are what the defaults are based on. Please re-read both the spec and the previous resolution, 1-10 is allowed (you have to explicitly set "best" to 10), and so is 0-100 (you have to explicitly set "worst" to 0 and "best" to 100).
*#* REJETE RTFM.  La plupart des exmples sont ce sur quoi sont basés les défauts. SVP relisez à la fois la spec et la résolution précédente, 1-10 est permis (vous devez explicitement régler "best" à 10), et ainsi est 0-100 (vous devez explicitement régler "worst" à 0 et "best" à 100).


== Clarifications sur la Spécification ==
== Clarifications sur la Spécification ==


* 2006-02-01 soulevée par [http://tantek.com Tantek].
* 2006-02-01 soulevée par [http://tantek.com Tantek].
*# ''The spec needs to clarify that there is only one "item" per "hreview".''
*# ''La spec a besoin de clarifier qu'il n'y a qu'un "item" par "hreview".''
*#* ACCEPTEE.  Resolved in hReview 0.3.
*#* ACCEPTEE.  Resolu dans hReview 0.3.




Line 60: Line 60:


* 2006-08-24 soulevée par [[User:Elias|Elias Sinderson]]
* 2006-08-24 soulevée par [[User:Elias|Elias Sinderson]]
*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical [http://www.w3.org/TR/NOTE-datetime note] (submitted by Reuters), which recommends that the extended (delimited) format be used, and the [http://www.w3.org/TR/html401/types.html#h-6.11 HTML 4.0 spec] uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the [http://www.w3.org/TR/xmlschema-2/#date xsd:date] and [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed / validated representation. Think of the children.
*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une [http://www.w3.org/TR/NOTE-datetime note] technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la [http://www.w3.org/TR/html401/types.html#h-6.11 spéc HTML 4.0] utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types [http://www.w3.org/TR/xmlschema-2/#date xsd:date] et [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] sont spécifiés comme étant le format étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
*#* REJETE. METHODOLOGIE INCORRECTE. "Require users to upconvert"??  No.  We optimize for publishers (the "users" in this context) more than developers. Whenever you find yourself saying or even <em>thinking</em> "require users", you're probably thinking along the wrong lines of reasoning. In particular we have already made the decision/resolution to permit the broader range of datetime values permitted by RFC2445, and explicitly included some shortcuts (e.g. timezone offsets) specifically to make things <em>easier</em> for <em>users</em>.
*#* REJETE. METHODOLOGIE INCORRECTE. "Oblige les utilisateurs à convertir" ??  Non.  Nous optimisons pour les éditeurs (les "utilisateurs" dans ce contexte) plus que pour les programmeurs. Chaque fois que vous vous retrouvez à dire ou même à <em>penser</em> "oblige les utilisateurs", vous pensez probablement sur de mauvaises lignes de raisonnement. En particulier, nous avons déjà pris la décision/résolution de permettre la plus large gamme de valeurs datetime permises par la RFC2445, et avons explicitement inclus quelques raccourcis  (par ex. timezone offsets) spécifiquement pour rendre les choses <em>plus faciles</em> pour les <em>utilisateurs</em>.


==Pages apparentées==
==Pages apparentées==
{{hreview-related-pages-fr}}
{{hreview-related-pages-fr}}

Latest revision as of 04:59, 9 June 2007

Problématiques hReview

Voici des problématiques soulevées à l'extérieur à propos de hReview ayant largement différents degrés de mérite. De ce fait quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont soulevées à nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des changements ou des explications améliorées dans la spec. Les problématiques proposées peuvent (et le pourront probablement) être éditées et récrites pour une meilleure concision, apporter clarté, calme, rationalité et autant que possible sous un point de vue neutre. Ecrivez bien vos problématiques. — Tantek

Voir les problématiques hcalendar et les problématiques hcard apparentées.

Gabarit

SVP utilisez ce format (copiez et collez cela à la fin de la liste pour ajouter vos problématiques) :

  • YYYY-MM-DD soulevée par VOTRENOM.
    1. Problématique 1 : Voici la première problématique que j'ai.
    2. Problématique 2 : Voici la seconde problématique que j'ai.

rel="self"

2005-01-04 par David Janes:

Atom définit rel="self" ici

La valeur "self" signifie que l'IRI dans la valeur de l'attribut href identifie une ressource équivalente à l'élément conteneur.

HTML rel="boomark" ici

fait référence à un bookmark. Un bookmark est un lien vers un point d'entrée clé dans un document étendu. L'attribut title peut être utilisé, par exemple, pour étiqueter le bookmark. Remarquez que plusieurs bookmarks peuvent être définis dans chaque document.

Parce que nous utilisons "bookmark" pour signifier le point d'entrée vers la hReview, le "self" n'est t'il pas redondant ou exagérément subtil ?

limite par défaut plus basse

gamme par défaut

  • 2006-02-23 soulevée par Andy Mabbett
    1. Ce ne sont pas toutes les marques qui donne des ratings "sur cinq". La valeur devrait être un pourcentage. Zéro devrait être permis.
      • REJETE IGNORES RESEARCH. La plupart des exemples du vrai monde ont une gamme de notation de 1.0-5.0 et pas un pourcentage. Vous pouvez paramtérer le "best" lié à 100 explicitement, et le "worst" lié à 0 explicitement par la spéc si c'est nécessaire.
      • "most" != "all"; bien sûr, la page que vous citez a des exemples de "1-10" et "0-100%". Je n'ai jamais prétendu que beaucoup d'exemples utilisent des pourcentages, mais suis sûr qu'un mathématicien expliquerait que les valeurs dans la gamme "1-5" peuvent être exprimées sous des pourcentages.
      • REJETE RTFM. La plupart des exmples sont ce sur quoi sont basés les défauts. SVP relisez à la fois la spec et la résolution précédente, 1-10 est permis (vous devez explicitement régler "best" à 10), et ainsi est 0-100 (vous devez explicitement régler "worst" à 0 et "best" à 100).

Clarifications sur la Spécification

  • 2006-02-01 soulevée par Tantek.
    1. La spec a besoin de clarifier qu'il n'y a qu'un "item" par "hreview".
      • ACCEPTEE. Resolu dans hReview 0.3.


Multilinguisme

  • 2006-03-22 soulevée par Fil
    1. l'auteur de la spec ne peut pas dire Pour les critiques anonymes, utilisez "anonymous" (sans guillemets) pour le nom complet de l'auteur. parce que ce mot ("anonymous") va apparaître sur la page, et n'est pas multilingue (et même en français, quelqu'un pourrait vouloir utiliser un autre mot, comme "un peureux anonyme")

Prix

  • 2006-04-04 soulevée par Evan.
    1. Cela ne semble pas possible de donner un price approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ou une gamme de prix. Les prix devraient presque toujours avoir une balise currency et un amount. Suggestion: <span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span>. Pour une gamme de prix, <span class="pricerange"><span class="price"> ... </span> jusqu'à <span class="price"> ... </span></span>.


Date and Time

  • 2006-08-24 soulevée par Elias Sinderson
    1. Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une note technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la spéc HTML 4.0 utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types xsd:date et xsd:dateTime sont spécifiés comme étant le format étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
      • REJETE. METHODOLOGIE INCORRECTE. "Oblige les utilisateurs à convertir" ?? Non. Nous optimisons pour les éditeurs (les "utilisateurs" dans ce contexte) plus que pour les programmeurs. Chaque fois que vous vous retrouvez à dire ou même à penser "oblige les utilisateurs", vous pensez probablement sur de mauvaises lignes de raisonnement. En particulier, nous avons déjà pris la décision/résolution de permettre la plus large gamme de valeurs datetime permises par la RFC2445, et avons explicitement inclus quelques raccourcis (par ex. timezone offsets) spécifiquement pour rendre les choses plus faciles pour les utilisateurs.

Pages apparentées

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