hreview-issues-fr

From Microformats Wiki
Revision as of 23:09, 26 December 2006 by ChristopheDucamp (talk | contribs)
Jump to navigation Jump to search

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). 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 note (submitted by Reuters), which recommends that the extended (delimited) format be used, and the 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 xsd:date and 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.
      • 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 thinking "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 easier for users.

Pages apparentées

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