hreview-issues

(Difference between revisions)

Jump to: navigation, search
(resolved datetime issue)
m (add related pages template)
Line 61: Line 61:
*# ''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.
*#* REJECTED. INCORRECT METHODOLOGY. "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>.
*#* REJECTED. INCORRECT METHODOLOGY. "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>.
 +
 +
==Related pages==
 +
{{hreview-related-pages}}

Revision as of 14:28, 4 December 2006

Contents

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. 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

See related hcalendar-issues and hcard-issues.

Template

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

rel="self"

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?

default lower bound

default range

Specification Clarifications


Multilinguism

Price

Date and Time

Related pages

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

Views