hreview-issues-fr

From Microformats Wiki
Revision as of 23:03, 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. Not all marks give ratings "out of five". The value should be a percentage. Zero should be allowed.
      • REJETE IGNORES RESEARCH. Most 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.
      • "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.
      • 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).

Clarifications sur la Spécification

  • 2006-02-01 soulevée par Tantek.
    1. The spec needs to clarify that there is only one "item" per "hreview".
      • ACCEPTEE. Resolved in 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=11863"