View source for hreview-brainstorming

<h1> hReview brainstorming </h1>

; Editor/Author: [http://tantek.com Tantek Çelik]

This document is for capturing thoughts on improving/iterating upon [[hreview|hReview]].


== hReview 0.3 thoughts ==

This iteration of hReview is directly in response to [[hreview-feedback]] and [[hreview-issues]].  See those documents for more details.

Changes from hReview 0.2:

* MUST (instead of SHOULD) use [[hcard|hCard]] for the item description of a business
* reviewer changes
** make reviewer *optional* per feedback from Ryan King and Mark Nottingham
** If reviewer is absent from the hReview, then look outside the hReview, in the context of the page, for the reviewer.  If there is no "reviewer" outside either, then use the <code><nowiki><address></nowiki></code> for the page.
** MUST (instead of SHOULD) use [[hcard|hCard]] to represent reviewer information
* SHOULD use [[hcalendar|hCalendar]] to represent an item of 'type' 'event'
** Accepted. We considered making this a MUST, and postponed it to the next version, based on publication experience with 0.3
* add one decimal digit of precision to ratings' numerical values.
* use [http://microformats.org/wiki/hcard#Value_excerpting the "value" construct from hCard] (as it is used in "tel" properties for example) to more explicitly markup the rating value when also providing (marking up) the best/worst of a rating.  need to also provide an example that does so.
* add [[rel-license]] to indicate the license of the hReview as a whole.
** add this to [[hatom]] as well!
* permit tags inside ratings to denote rated tags, the same as ratings inside tags per suggestion from Eran Globen.
* add [[include-pattern]] support to allow multiple reviews for the same item to not repeat the item info.
Informative improvements:
* Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag.  E.g. what does Food:18/30 mean?


== hReview 0.4 thoughts ==

* items of <code>type</code> <code>place</code> SHOULD use a nested [[geo]] or [[adr]] or [[hcard|hCard]] as the item itself.
* items of <code>type</code> <code>url</code> MUST specify a <code>url</code> property for the item (in hReview 0.3 having "url" property for the item is only a SHOULD)
* note that in the future, items of <code>type</code> <code>product</code> SHOULD use a nested [[product]] microformat.  [[hlisting|hListing]] has also shown that there may be need for a [[product]] microformat.
* note and clarify that item <code>type</code> of "url" means the review applies to *only* the resource present at that URL, whether it is an HTML page, an image, an mp3, whatever.  Whereas item type of "website" applies to everything at that URL and contained in any subdirectories thereof.
* is the <code>version</code> property needed?  currently it is optional and created invisibly by the [http://microformats.org/code/hreview/creator hReview creator]. It is not clear that it is necessary for parsing either, since all changes to hReview have been forward/backward compatible and it is our goal to continue to make compatible changes.
* is the <code>type</code> property needed?  It too is created invisibly by the [http://microformats.org/code/hreview/creator hReview creator].
* drop <code>self</code> from the <code>permalink</code>.  Even [[hatom|hAtom]] just uses <code>bookmark</code>, so should hReview.
* should allow multiple license
* item type fallback.  If the expected encapsulated microformat for a given item type (e.g. business / hCard) is not present, then fall back to parsing for item sub properties and construct an implied encapsulated microformat from those subproperties. Alternative, just take the fn, url, photo subproperties that are present as is, and don't bother to imply an hCard.
* implied "fn" inside item.  if there is no "fn" then treat the entire "item" as an "fn".

==Related pages==
{{hreview-related-pages}}