hreview-issues

(Difference between revisions)

Jump to: navigation, search
m (Open Issues)
(added resolved, closed sections, sorted issues accordingly, wiki cleanup)
Line 1: Line 1:
-
= hReview issues =
+
<h1> hReview issues </h1>
-
These are externally raised issues about [[hreview|hReview]] with broadly varying degrees of merit.  Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions.  Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.  Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]
+
These are externally raised issues about [[hreview|hReview]] with broadly varying degrees of merit.  Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions.  Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.   
 +
 
 +
'''IMPORTANT''': Please read the [[hreview-faq|hReview FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.
 +
 
 +
Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]
 +
 
 +
Please add new issues to the '''top''' of the list.  Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues.  Duplicate issue additions will be reverted.
See related [[hcalendar-issues]] and [[hcard-issues]].
See related [[hcalendar-issues]] and [[hcard-issues]].
-
== Template ==
+
__TOC__
-
Please use this format (copy and paste this to the end of the list to add your issues):
+
== Issues ==
-
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
+
-
*# ''Issue 1: Here is the first issue I have.''
+
-
*# ''Issue 2: Here is the second issue I have.''
+
-
== rel=&quot;self&quot; ==
+
=== rel=&quot;self&quot; ===
OpenIssue 2005-01-04 by [[User:DavidJanes|David Janes]]:
OpenIssue 2005-01-04 by [[User:DavidJanes|David Janes]]:
Line 26: Line 29:
Since we're using &quot;bookmark&quot; to mean the entry point to the hReview, isn't the &quot;self&quot; redundant or overly subtle?
Since we're using &quot;bookmark&quot; to mean the entry point to the hReview, isn't the &quot;self&quot; redundant or overly subtle?
-
== default lower bound ==
+
=== Multilinguism ===
 +
*{{OpenIssue}} 2006-03-22 raised by Fil
 +
*# the reviewer spec can't say ''For anonymous reviews, use "anonymous" (without quotes) for the full name of the reviewer.'' as this word ("anonymous") is going to be apparent on the page, and is not multilingual (and even in English someone might want to use another word, like "an anonymous coward")
 +
 +
=== Price ===
 +
* {{OpenIssue}} 2006-04-04 raised by [[User:Evan|Evan]].
 +
*# It doesn't seem possible to give an approximate, average, or absolute '''price''' of the product or service in question. Examples: for a piece of software, the suggested retail price. For a restaurant, average price of an entree, ''or'' a '''price range'''. Prices should almost definitely have a ''currency'' marker and an ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. For a range, ''<nowiki><span class="pricerange"><span class="price"> ... </span> to <span class="price"> ... </span></span></nowiki>''.
 +
 +
== Template ==
 +
Please use this format (copy and paste this to the beginning of the list to add your issues):
 +
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
 +
*# ''Issue 1: Here is the first issue I have.''
 +
*# ''Issue 2: Here is the second issue I have.''
 +
 +
== Resolved Issues ==
 +
Issues that are resolved but may have outstanding [[to-do]] items.
 +
* ...
 +
 +
== Closed Issues ==
 +
Resolved issues that have no further actions to take.
 +
 +
=== default lower bound ===
* YYYY-MM-DD????? raised by [[User:ScottReynen|Scott Reynen]]
* YYYY-MM-DD????? raised by [[User:ScottReynen|Scott Reynen]]
*# ''Why is the default lower bound 1 when the [[reviews-formats|real world examples]] almost all have a lower bound of 0?''
*# ''Why is the default lower bound 1 when the [[reviews-formats|real world examples]] almost all have a lower bound of 0?''
*#* REJECTED INVALID ASSUMPTION.  Most [[review-examples|real-world examples]] have a lower bound of 1, not 0.
*#* REJECTED INVALID ASSUMPTION.  Most [[review-examples|real-world examples]] have a lower bound of 1, not 0.
-
== default range ==
+
=== default range ===
* 2006-02-23 raised by Andy Mabbett
* 2006-02-23 raised by Andy Mabbett
*# ''Not all marks give ratings "out of five". The value should be a percentage. Zero should be allowed.''
*# ''Not all marks give ratings "out of five". The value should be a percentage. Zero should be allowed.''
Line 39: Line 63:
*#* REJECTED 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).
*#* REJECTED 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).
-
== Specification Clarifications ==
+
=== Specification Clarifications ===
-
 
+
* 2006-02-01 raised by [http://tantek.com Tantek].
* 2006-02-01 raised by [http://tantek.com Tantek].
*# ''The spec needs to clarify that there is only one "item" per "hreview".''
*# ''The spec needs to clarify that there is only one "item" per "hreview".''
*#* ACCEPTED.  Resolved in hReview 0.3.
*#* ACCEPTED.  Resolved in hReview 0.3.
-
== Multilinguism ==
+
=== Date and Time ===
-
 
+
-
*{{OpenIssue}} 2006-03-22 raised by Fil
+
-
*# the reviewer spec can't say ''For anonymous reviews, use "anonymous" (without quotes) for the full name of the reviewer.'' as this word ("anonymous") is going to be apparent on the page, and is not multilingual (and even in English someone might want to use another word, like "an anonymous coward")
+
-
 
+
-
== Price ==
+
-
 
+
-
* {{OpenIssue}} 2006-04-04 raised by [[User:Evan|Evan]].
+
-
*# It doesn't seem possible to give an approximate, average, or absolute '''price''' of the product or service in question. Examples: for a piece of software, the suggested retail price. For a restaurant, average price of an entree, ''or'' a '''price range'''. Prices should almost definitely have a ''currency'' marker and an ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. For a range, ''<nowiki><span class="pricerange"><span class="price"> ... </span> to <span class="price"> ... </span></span></nowiki>''.
+
-
 
+
-
== Date and Time ==
+
-
 
+
* 2006-08-24 raised by [[User:Elias|Elias Sinderson]]
* 2006-08-24 raised by [[User:Elias|Elias Sinderson]]
*# ''Issue 1: (This is copied from the hcalendar-issues page, as it applies to hreview as well.) 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.
*# ''Issue 1: (This is copied from the hcalendar-issues page, as it applies to hreview as well.) 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.

Revision as of 03:57, 29 April 2007

hReview issues

These are externally raised issues about hReview with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

IMPORTANT: Please read the hReview FAQ before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

Please add new issues to the top of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

See related hcalendar-issues and hcard-issues.

Contents


Issues

rel="self"

OpenIssue 2005-01-04 by David Janes:

Atom defines rel="self" here

The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.

HTML rel="boomark" here

Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.

Since we're using "bookmark" to mean the entry point to the hReview, isn't the "self" redundant or overly subtle?

Multilinguism

Price

Template

Please use this format (copy and paste this to the beginning of the list to add your issues):

Resolved Issues

Issues that are resolved but may have outstanding to-do items.

Closed Issues

Resolved issues that have no further actions to take.

default lower bound

default range

Specification Clarifications

Date and Time

Related pages

hreview-issues was last modified: Wednesday, December 31st, 1969

Views