Microformats Wiki - User contributions [en]

review-examples

2006-01-26T16:21:11Z

B.K. DeLong: /* Centralized Implementations */

= Review Examples =

There have been several efforts to define data formats for posting "reviews" of products, services etc. on the Web.

This page serves to document the current list of review examples from real world sites for the design of a simple reviews [[microformat]]. -[http://tantek.com/log/ Tantek]

__TOC__

== Contributors ==

Copied from [[reviews-formats]] which itself was contributed from [http://developers.technorati.com/wiki/ReviewsFormats Technorati Developer's Wiki: ReviewsFormats])

* Tantek Çelik
* Niall Kennedy

== See Also ==
* [[review-formats]]
* [[review-brainstorming]]
* [[hreview|hReview]]

== Examples on the Web ==
Notice that '''author''' appears several times in the list below, and that it sometimes refers to the author of the review, and other times to the author of the book being reviewed. A parenthetical will be used to distinguish them now.

== Centralized Implementations ==
=== Insider Pages ===
Customer reviews of local businesses
* http://www.insiderpages.com

** author ''(review author)''
** rating (0 - 5 stars)
** business name
** review title
** review
** pros
** cons
** business category
** business address
** business phone number
** business e-mail address
** business website

=== Amazon.com ===
* http://www.amazon.com/

** author ''(book author)''
** publication date
** title
** description
** rating (1 to 5 stars)
*** overall and by category
**** declared value and a maximum possible value
* vote for or against component

==== Mini-review ====
Mini reviews are limited to products on some areas of the site.

* rating (1 to 5 stars)
** Their mini-review interface has an 'x,' but this does not mean a rating of '0,' but in their own verbiage 'Unrated.' So the interval is 1 to 5 starts, not 0 to 5 stars. --[[User:RyanKing|RyanKing]] 11:43, 18 Jan 2006 (PST)
* ownership status ([x] I own this)
* negative interest ([x] Not interested)

=== Blogcritics ===
* http://blogcritics.org/

* author ''(review author)''
* title
* publication date
* description
* reviewed work identifier
* reviewed work title
* reviewed work version
** release date
** Volume, issue
** edition
** translation
* reviewed work author(s)
* reviewed work publisher

=== Consumer Reviews ===
* reviewed item
* reviewed item version
* rating
** overall 1-100
** by category 1-5
* definition list of specifications

=== Epinions ===
* http://epinions.com/

* author ''(review author)''
* publication date
* title
* summary ("the bottom line")
* description
* rating overall and by category
* positive summary
* negative summary
* cost
* vote for or against product
* vote for or against review

=== Web site or page reviews ===
* http://en-us.sitereviews.org/
* http://www.stumbleupon.com/

=== Yahoo! Local ===
* http://local.yahoo.com/

* author ''(review author)''
* publication date
* title
* description
* rating
** overall and by category [1-5]
* positive summary
* negative summary

==== Restaurant ====
* usage datetime
* specific use

=== Nearlocal ===
* http://www.nearlocal.com/

=== Yelp ===
* http://www.yelp.com/

=== SF Survey ===
* http://sfsurvey.com/

=== Zagat ===
* rating by category
* cost
* description

=== delicious 3rd party ===
* http://alf.hubmed.org/rvw.htm

* rating (0-100%)
* tags (keywords, year, user-specified others)
* artist/author ''(work author)''
* title
* URL
* comments
* unique identifier

=== iTunes XML ===
* rating (0-100%)

=== review world ===
* http://www.revieworld.com/

=== Dinner Buzz ===
* http://www.dinnerbuzz.com/

=== TV.com ===
* http://www.tv.com

* rating (0-10 in increments of 0.1)
* classification
* summary
* full review
* agree or disagree

=== IMDB ===
* http://www.imdb.com

* voting
** rating (1-10)

* user comments
** User Name
** User Location
** Contains spoiler? (checkbox)
** Summary
** Vote (1-10)
** Comment text

== Analysis of Examples ==

=== Common review fields ===
* item
** optional:type of item (business, Web page/site, product, event, person, place, file, text)
** name/title of item being reviewed (string | ["hCard"] if business or person)
*** optional:URL (all additional information should be somewhere else, not in the review itself)
*** optional:image (URL)
* reviewer (["hCard"]|name|email|URL)
* review publication/authoring date (ISO8601 datetime)
* rating 1 to 5 (default max = 5, default min = 1)
* optional:tags (keyword,rating)*
* optional:comments (string)

== See Also ==
* [[review-formats]]
* [[review-brainstorming]]
* [[hreview|hReview]]

See [[hreview|hReview]] for the result and evolution of these thoughts on a microformat.

review-examples

2006-01-26T16:15:45Z

B.K. DeLong: /* TV.com */

= Review Examples =

There have been several efforts to define data formats for posting "reviews" of products, services etc. on the Web.

This page serves to document the current list of review examples from real world sites for the design of a simple reviews [[microformat]]. -[http://tantek.com/log/ Tantek]

__TOC__

== Contributors ==

Copied from [[reviews-formats]] which itself was contributed from [http://developers.technorati.com/wiki/ReviewsFormats Technorati Developer's Wiki: ReviewsFormats])

* Tantek Çelik
* Niall Kennedy

== See Also ==
* [[review-formats]]
* [[review-brainstorming]]
* [[hreview|hReview]]

== Examples on the Web ==
Notice that '''author''' appears several times in the list below, and that it sometimes refers to the author of the review, and other times to the author of the book being reviewed. A parenthetical will be used to distinguish them now.

== Centralized Implementations ==
=== Insider Pages ===
Customer reviews of local businesses
* http://www.insiderpages.com

** author ''(review author)''
** rating (0 - 5 stars)
** business name
** review title
** review
** pros
** cons
** business category
** business address
** business phone number
** business e-mail address
** business website

=== Amazon.com ===
* http://www.amazon.com/

** author ''(book author)''
** publication date
** title
** description
** rating (1 to 5 stars)
*** overall and by category
**** declared value and a maximum possible value
* vote for or against component

==== Mini-review ====
Mini reviews are limited to products on some areas of the site.

* rating (1 to 5 stars)
** Their mini-review interface has an 'x,' but this does not mean a rating of '0,' but in their own verbiage 'Unrated.' So the interval is 1 to 5 starts, not 0 to 5 stars. --[[User:RyanKing|RyanKing]] 11:43, 18 Jan 2006 (PST)
* ownership status ([x] I own this)
* negative interest ([x] Not interested)

=== Blogcritics ===
* http://blogcritics.org/

* author ''(review author)''
* title
* publication date
* description
* reviewed work identifier
* reviewed work title
* reviewed work version
** release date
** Volume, issue
** edition
** translation
* reviewed work author(s)
* reviewed work publisher

=== Consumer Reviews ===
* reviewed item
* reviewed item version
* rating
** overall 1-100
** by category 1-5
* definition list of specifications

=== Epinions ===
* http://epinions.com/

* author ''(review author)''
* publication date
* title
* summary ("the bottom line")
* description
* rating overall and by category
* positive summary
* negative summary
* cost
* vote for or against product
* vote for or against review

=== Web site or page reviews ===
* http://en-us.sitereviews.org/
* http://www.stumbleupon.com/

=== Yahoo! Local ===
* http://local.yahoo.com/

* author ''(review author)''
* publication date
* title
* description
* rating
** overall and by category [1-5]
* positive summary
* negative summary

==== Restaurant ====
* usage datetime
* specific use

=== Nearlocal ===
* http://www.nearlocal.com/

=== Yelp ===
* http://www.yelp.com/

=== SF Survey ===
* http://sfsurvey.com/

=== Zagat ===
* rating by category
* cost
* description

=== delicious 3rd party ===
* http://alf.hubmed.org/rvw.htm

* rating (0-100%)
* tags (keywords, year, user-specified others)
* artist/author ''(work author)''
* title
* URL
* comments
* unique identifier

=== iTunes XML ===
* rating (0-100%)

=== review world ===
* http://www.revieworld.com/

=== Dinner Buzz ===
* http://www.dinnerbuzz.com/

=== TV.com ===
* http://www.tv.com

* rating (0-10 in increments of 0.1)
* classification
* summary
* full review
* agree or disagree

== Analysis of Examples ==

=== Common review fields ===
* item
** optional:type of item (business, Web page/site, product, event, person, place, file, text)
** name/title of item being reviewed (string | ["hCard"] if business or person)
*** optional:URL (all additional information should be somewhere else, not in the review itself)
*** optional:image (URL)
* reviewer (["hCard"]|name|email|URL)
* review publication/authoring date (ISO8601 datetime)
* rating 1 to 5 (default max = 5, default min = 1)
* optional:tags (keyword,rating)*
* optional:comments (string)

== See Also ==
* [[review-formats]]
* [[review-brainstorming]]
* [[hreview|hReview]]

See [[hreview|hReview]] for the result and evolution of these thoughts on a microformat.

review-examples

2006-01-26T16:15:13Z

B.K. DeLong: /* Centralized Implementations */

= Review Examples =

There have been several efforts to define data formats for posting "reviews" of products, services etc. on the Web.

This page serves to document the current list of review examples from real world sites for the design of a simple reviews [[microformat]]. -[http://tantek.com/log/ Tantek]

__TOC__

== Contributors ==

Copied from [[reviews-formats]] which itself was contributed from [http://developers.technorati.com/wiki/ReviewsFormats Technorati Developer's Wiki: ReviewsFormats])

* Tantek Çelik
* Niall Kennedy

== See Also ==
* [[review-formats]]
* [[review-brainstorming]]
* [[hreview|hReview]]

== Examples on the Web ==
Notice that '''author''' appears several times in the list below, and that it sometimes refers to the author of the review, and other times to the author of the book being reviewed. A parenthetical will be used to distinguish them now.

== Centralized Implementations ==
=== Insider Pages ===
Customer reviews of local businesses
* http://www.insiderpages.com

** author ''(review author)''
** rating (0 - 5 stars)
** business name
** review title
** review
** pros
** cons
** business category
** business address
** business phone number
** business e-mail address
** business website

=== Amazon.com ===
* http://www.amazon.com/

** author ''(book author)''
** publication date
** title
** description
** rating (1 to 5 stars)
*** overall and by category
**** declared value and a maximum possible value
* vote for or against component

==== Mini-review ====
Mini reviews are limited to products on some areas of the site.

* rating (1 to 5 stars)
** Their mini-review interface has an 'x,' but this does not mean a rating of '0,' but in their own verbiage 'Unrated.' So the interval is 1 to 5 starts, not 0 to 5 stars. --[[User:RyanKing|RyanKing]] 11:43, 18 Jan 2006 (PST)
* ownership status ([x] I own this)
* negative interest ([x] Not interested)

=== Blogcritics ===
* http://blogcritics.org/

* author ''(review author)''
* title
* publication date
* description
* reviewed work identifier
* reviewed work title
* reviewed work version
** release date
** Volume, issue
** edition
** translation
* reviewed work author(s)
* reviewed work publisher

=== Consumer Reviews ===
* reviewed item
* reviewed item version
* rating
** overall 1-100
** by category 1-5
* definition list of specifications

=== Epinions ===
* http://epinions.com/

* author ''(review author)''
* publication date
* title
* summary ("the bottom line")
* description
* rating overall and by category
* positive summary
* negative summary
* cost
* vote for or against product
* vote for or against review

=== Web site or page reviews ===
* http://en-us.sitereviews.org/
* http://www.stumbleupon.com/

=== Yahoo! Local ===
* http://local.yahoo.com/

* author ''(review author)''
* publication date
* title
* description
* rating
** overall and by category [1-5]
* positive summary
* negative summary

==== Restaurant ====
* usage datetime
* specific use

=== Nearlocal ===
* http://www.nearlocal.com/

=== Yelp ===
* http://www.yelp.com/

=== SF Survey ===
* http://sfsurvey.com/

=== Zagat ===
* rating by category
* cost
* description

=== delicious 3rd party ===
* http://alf.hubmed.org/rvw.htm

* rating (0-100%)
* tags (keywords, year, user-specified others)
* artist/author ''(work author)''
* title
* URL
* comments
* unique identifier

=== iTunes XML ===
* rating (0-100%)

=== review world ===
* http://www.revieworld.com/

=== Dinner Buzz ===
* http://www.dinnerbuzz.com/

=== TV.com ===
* http://www.tv.com

** rating (0-10 in increments of 0.1)
** classification
** summary
** full review
** agree or disagree

== Analysis of Examples ==

=== Common review fields ===
* item
** optional:type of item (business, Web page/site, product, event, person, place, file, text)
** name/title of item being reviewed (string | ["hCard"] if business or person)
*** optional:URL (all additional information should be somewhere else, not in the review itself)
*** optional:image (URL)
* reviewer (["hCard"]|name|email|URL)
* review publication/authoring date (ISO8601 datetime)
* rating 1 to 5 (default max = 5, default min = 1)
* optional:tags (keyword,rating)*
* optional:comments (string)

== See Also ==
* [[review-formats]]
* [[review-brainstorming]]
* [[hreview|hReview]]

See [[hreview|hReview]] for the result and evolution of these thoughts on a microformat.

hreview

2006-01-24T15:15:07Z

B.K. DeLong: /* Examples in the wild */

= hReview 0.2 =

hReview is a simple, open, distributed reviews format suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. hReview is one of several [[microformats]] open standards.

__TOC__

== Draft Specification 2005-06-07 ==

=== Editor ===
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]

=== Authors ===
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]
* [http://360.yahoo.com/alidiabali Ali Diab],[http://yahoo.com Yahoo! Inc.]
* [http://spaces.msn.com/members/ianmcallister/ Ian McAllister], [http://microsoft.com/ Microsoft Corporation]
* [http://journals.aol.com/panzerjohn/abstractioneer John Panzer], [http://www.aol.com America Online, Inc.]
* [http://ifindkarma.com/blog Adam Rifkin], [http://labs.commerce.net/ CommerceNet Labs]
* [http://sippey.typepad.com/ Michael Sippey], [http://sixapart.com Six Apart, Ltd.]

== Introduction ==
Numerous web sites publish reviews using a broad variety of schema for all sorts of things from products (movies, music, books), to businesses (restaurants, hotels, stores), to events (concerts, theatre), to people (artists, leaders, celebrities), to places (landmarks, parks), to online resources (web pages, files), to reviews of reviews themselves.

In order to enable and encourage the sharing, distribution, syndication, and aggregation, of reviews, the authors propose the hReview microformat, an open standard for distributed reviews. The authors have researched numerous earlier attempts at ReviewsFormats, and have designed hReview around a simple minimal schema for reviews. Feedback is encouraged on the ["hReviewFeedback"] page.

=== Working Name ===
The name "hReview" is a working name for this microformat. The name was suggested as it shares much with the hCard and hCalendar microformats, despite not having an IETF RFC to reference for a normative schema.

=== Copyright ===
{{MicroformatCopyrightStatement2005}}

=== Patents ===
{{MicroFormatPatentStatement}}

=== Inspiration and Acknowledgments ===
Thanks to everyone who responded to the open call for implementor participation for hReview. The authors in particular wish to thank the following individuals for their constructive input and feedback: [http://www.richardault.com/ Richard Ault], [http://dannyayers.com Danny Ayers], [http://www.vertexdev.com/~jeff/ Jeffrey Barr],[http://adriancuthbert.blogspot.com/ Adrian Cuthbert],[http://jason.defillippo.com/ Jason DeFillippo], [http://www.hybernaut.com/bdv Brian Del Vecchio], Scott Derringer, [http://budgibson.com/home/ Bud Gibson], [http://joi.ito.com/ Joi Ito], [http://www.kanai.net/weblog/ Gen Kanai],[http://niallkennedy.com/ Niall Kennedy], [http://labs.commerce.net/wiki/index.php/Rohit_Khare Rohit Khare], [http://theryanking.com/ Ryan King], [http://www.jluster.org/ Jonas Luster], [http://epeus.blogspot.com/ Kevin Marks], [http://www.powazek.com/ Derek Powazek], [http://www.judysbook.com/ Jeff Rodenburg], [http://sifry.com/alerts/ David Sifry], [http://jystewart.net/ James Stewart], [http://kung-foo.tv/ Adriaan Tijsseling], [http://www.flashenabled.com/ Phillip Torrone], Thai Tran, [http://w6daily.winn.com/ Phillip Winn], [http://yohei-y.blogspot.com YAMAMOTO Yohei].

=== Scope ===
Reviews consistently share several common fields. Where possible hReview has been based on this minimal common subset.

==== Out of scope ====
Fields that are type-specific have been omitted from hReview. It is important that hReview be kept simple and minimal from the start. Additional features can be added as deemed necessary by practical implementation experience.

The concept of a "universal object identifier", that is, how to identify the same object/item/product across different shopping sites, though something very useful to have, is outside the scope of this format.

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
The hReview format is based on a set of fields common to numerous review sites and formats in use today on the web. Where possible field names have been chosen based on those defined by the related [[hcard|hCard]] and [[hcalendar|hCalendar]] standards.

=== Schema ===
The hReview schema consists of the following:

* hReview
** version. optional. text.
** summary. optional. text.
** item type. optional. product | business | event | person | place | website | url.
** item info. required. (fn || url || photo ) | [[hcard|hCard]] (for person or business).
** reviewer. required. [[hcard|hCard]] | fn | email | url.
** dtreviewed. required. ISO8601 absolute date time.
** rating. optional. integer [1-5], with optional alternate worst (default:1) and/or best (default:5), also integers.
** description. optional. text with optional valid XHTML markup.
** tags. optional. keywords or phrases, using RelTag, each with optional rating.
** permalink. optional.

=== Field details ===
The fields of the hReview schema represent the following:

'''version''':: This optional field permits hReview publishers to specify a particular version of hReview that their content uses. By omitting this field, the publisher is stating that implementations may interpret the hReviews according to any version of the hReview specification v0.2 or later. In practice the authors of this specification are comitted to maintaining backward compatibility with content produced using earlier versions of the specification. This field is syntax compatible with, and thus reuses the semantics of "VERSION" as defined in vCard RFC2426 section "3.6.9 VERSION Type Definition". The value of this field for this specification is "0.2".

'''summary''':: This optional field serves as a title for the review itself.

'''item type''':: This optional field "type" provides the type of the item being reviewed, one of the following: product, business, event, person, place, website, url.

'''item info''':: This required field MUST have at a minimum the name ("fn" - the formatted text corresponding to the name) of the item , SHOULD provide at least one URI ("url") for the item, and MAY provide at least one URL to a photo or depiction ("photo") of the item. For items of type person or business, the item info (fn, url, photo) SHOULD be encapsulated in an [[hcard|hCard]]. Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN ("url") for the item.

'''reviewer''':: The person who authored the review. An hCard representing the reviewer SHOULD be provided with full name and URL. Alternatively, just a name, email address, or URL to the person MAY be provided. To specify more than one of those, encapsulate them in an hCard. For anonymous reviews, use "anonymous" (without quotes) for the full name of the reviewer.

'''dtreviewed''':: This required field MUST provide an ISO8601 absolute date time of when the review was written or otherwise authored. This field SHOULD use UTC, but MAY use the time zone offset syntax.

'''rating''':: The rating is an integer from 1 to 5 inclusive indicating a rating for the item, higher indicating a better rating. Optionally a different integral "worst" value and/or "best" value MAY be specified (e.g. 6 from 0-10).

'''description''':: This optional field contains the full text representing the written opinion of the reviewer. The field MAY include valid XHTML markup (e.g. paragraphs). User agents SHOULD preserve any markup. Multiple descriptions or section descriptions (e.g. pros and cons, plusses and minusses) SHOULD be included in the description field.

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag|RelTag]] microformat for each individual keyword or phrase tag) that the reviewer associates with the item. The reviewer MAY optionally provide a tag-specific rating inside each [[rel-tag|RelTag]], e.g. ambience:5. Tag-specific ratings by default use the same range as an overall rating for the item if present, and MAY also have a custom worst...best range specified. Authors MAY enclose all tags for a review inside an element with a specific classname, e.g. "categories" (from vCard RFC2426 and iCalendar RFC2445), but are not required to do so.

'''permalink''':: This optional field is a URL for the hReview. In addition to using the <code><a href></code> tag for this field, the attribute <code>rel="self bookmark"</code> MUST be used to indicate that the hyperlink is a permalink for the review itself. If the hyperlink already contains a <code>rel</code> attribute, then the values <code>self</code> and <code>bookmark</code> MUST be included among the space-separated set of values in the attribute. Indexers MAY treat the permalink of a review as a unique ID in order to identify and collate the same review from multiple sources (such as indexing a page multiple times). The permalink MAY also be used to indicate or imply the origin of the review. Authors MAY use the classname of "permalink" on the element representing the permalink, but are not required to do so.

The following field names have been reused from the [[hcard|hCard]] and [[hcalendar|hCalendar]] microformats: <code>version, summary, fn, url, email, photo, description, categories</code>. In addition, items and reviewers described by hCards MAY contain any hCard field. The rel value "self" has been reused from the [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 specification].

=== More Semantic Equivalents ===

For some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:

* For any "url", use <code><a class="url" href="...">...</a></code> inside the element with class="hreview" in hReview.
* Similarly, any "email", use <code><nowiki><a class="email" href="mailto:...">...</a></nowiki></code>
* And for "photo", use <code><img class="photo" src="..." alt="Photo of ..." /></code>

* Ratings are often presented either as a set of images or characters, e.g. "***". For these, the <code><abbr></code> element is particularly useful, as such characters are an abbreviation for the precise rating, e.g. <code><abbr class="rating" title="3">***</abbr></code>. This is further explored in the next section.

==== Language ====
* To explicitly convey the natural language that an hReview is written in, use the standard (X)HTML 'lang' attribute on the element with class="hreview", e.g. <code><div class="hreview" lang="en"> ... </div></code> If portions of an hReview (e.g. the item name) are in a different language, use the 'lang' attribute on those portions.
* hReview processors which need to handle the language of reviews MUST process the standard (X)HTML 'lang' attribute as specified.

=== Human vs. Machine Readable ===
If an <code><abbr></code> element is used for a property, then its '<code>title</code>' attribute is used for the value of the property, instead of the contents of the element, which can then be used to provide a user-friendly alternate presentation of the value.

Similarly, if an <code><img /></code> element is used for one or more properties, it MUST be treated as follows:

# For the "photo" property and any other property that takes a URL as its value, the <code>src="..."</code> attribute provides the property value.
# For other properties, the <code><img /></code> element's '<code>alt</code>' attribute is the value of the property.

=== Notes ===
This section is informative.

* By marking up a review with the hReview microformat, the expectation is communicated that the review MAY be indexed. This has no impact on the copyright of the review itself.
* The enumerated list of item types is under development and may be extended.
* Each type may have custom hReview fields that follow the common set.
* Additional details about a particular item should be specified with the rest of the item's info at the URL provided for the item.
* Most rating systems use the range 1 to 5, and most of those represent the rating as a number of stars. Sites may use whatever graphic they wish to represent the rating.

== Examples ==
Here are a few examples of reviews from current web sites, and how they could be easily enhanced to support the hReview structured review microformat.

=== Restaurant reviews ===

Here is an example of a simple online restaurant review:

<pre><nowiki>
<div>
<span>5 stars out of 5 stars</span>
<h4>Crepes on Cole is awesome</h4>
<span>Reviewer: <span>Tantek</span> - April 18, 2005</span>
<blockquote><p>
Crepes on Cole is one of the best little creperies in San Francisco.
Excellent food and service. Plenty of tables in a variety of sizes
for parties large and small. Window seating makes for excellent
people watching to/from the N-Judah which stops right outside.
I've had many fun social gatherings here, as well as gotten
plenty of work done thanks to neighborhood WiFi.
</p></blockquote>
<p>Visit date: <span>April 2005</span></p>
<p>Food eaten: <span>Florentine crepe</span></p>
</div>
</nowiki></pre>

Adding hReview to this review is quite simple:

<pre><nowiki>
<div class="hreview">
<span><span class="rating">5</span> out of 5 stars</span>
<h4 class="summary"><span class="item fn">Crepes on Cole</span> is awesome</h4>
<span>Reviewer: <span class="reviewer fn">Tantek</span> -
<abbr class="dtreviewed" title="20050418T2300-0700">April 18, 2005</abbr></span>
<blockquote class="description"><p>
Crepes on Cole is one of the best little creperies in San Francisco.
Excellent food and service. Plenty of tables in a variety of sizes
for parties large and small. Window seating makes for excellent
people watching to/from the N-Judah which stops right outside.
I've had many fun social gatherings here, as well as gotten
plenty of work done thanks to neighborhood WiFi.
</p></blockquote>
<p>Visit date: <span>April 2005</span></p>
<p>Food eaten: <span>Florentine crepe</span></p>
</div>
</nowiki></pre>

Note that some of the properties of this sample review are not captured by hReview (visit date, food eaten). This is deliberate per the scope of keeping hReview minimal and simple.

This sample hReview could be rendered like this:

5 stars out of 5 stars<br />
'''Crepes on Cole is awesome'''<br />
Reviewer: Tantek - April 18, 2005<br />

<blockquote>Crepes on Cole is one of the best little creperies in San Francisco. Excellent food and service. Plenty of tables in a variety of sizes for parties large and small. Window seating makes for excellent people watching to/from the N-Judah which stops right outside. I've had many fun social gatherings here, as well as gotten plenty of work done thanks to neighborhood wifi.</blockquote>

Visit date: April 2005<br />
Food eaten: Florentine crepe<br />

==== Multidimensional Restaurant Review ====
Some restaurant reviews indicate ratings for different aspects of the restaurant. Such details are represented in hReview using tagged ratings. In addition, note the inline tags inside the description of this review.

Here is one such review in text format:

Cafe Borrone

1010 El Camino Real, Menlo Park, CA 94025, +1-650-327-0830;
cafeborrone.com

Food: 18/30; Ambience: 19/30; Service: 15/30; Price: $$...

This cafe is a welcoming oasis on the Peninsula. It even has a fountain
outside which cloaks the nearby sounds of El Camino traffic. Next door to a
superb indy bookstore, Cafe Borrone is an ideal spot to grab a coffee or a
snack to accompany a newly purchased book or imported periodical. Soups and
sandwich specials rotate daily. The corn chowder with croutons and big
chunks of cheese goes especially well with a freshly toasted mini-baguette.
Evenings are often crowded and may require sharing a table with a perfect
stranger. Espresso afficionados will appreciate the Illy coffee. Noise
levels can vary from peaceful in the late mornings to nearly overwhelming on
jazz band nights.

As an hReview:

<pre><nowiki>
<div class="hreview">
<div class="item vcard">
<div class="fn org summary">Cafe Borrone</div>
<span class="adr">
<span class="street-address">1010 El Camino Real</span>,
<span class="locality">San Francisco</span>,
<span class="region">CA</span>
<span class="postal-code">94025</span>,
</span>
<span class="tel"><span class="voice work">+1-650-327-0830</span></span>;
<a class="url" href="http://cafeborrone.com">cafeborrone.com</a>
</div>
<ul class="categories">
<li><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
Food: <span class="rating">18</span>/<span class="best">30</span></a>;</li>
<li><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
Ambience: <span class="rating">19</span>/<span class="best">30</span></a>;</li>
<li><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
Service: <span class="rating">15</span>/<span class="best">30</span></a>;</li>
<li><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
Price: <abbr class="rating" title="2">$$</abbr>...</a></li>
</ul>
<blockquote class="description"><p>
This <abbr class="type" title="business">
<a href="http://en.wikipedia.org/wiki/cafe" rel="tag">cafe</a></abbr>
is a welcoming oasis on the Peninsula.
It even has a fountain outside which nearly eliminates
the sounds of El Camino traffic. Next door to a superb indy bookstore,
Cafe Borrone is an ideal spot to grab a
<a href="http://en.wikipedia.org/wiki/coffee" rel="tag">coffee</a>
or a meal to accompany a newly purchased book or imported periodical.
<a href="http://technorati.com/tag/soup" rel="tag">Soups</a> and
<a href="http://technorati.com/tag/sandwich" rel="tag">sandwich</a>
specials rotate daily. The corn chowder with croutons and big chunks of cheese
goes especially well with a freshly toasted mini-baguette. Evenings are
often crowded and may require sharing a table with a perfect stranger.
<a href="http://flickr.com/photos/tags/espresso" rel="tag">Espresso</a>
afficionados will appreciate the
<a href="http://en.wikipedia.org/wiki/Illy" rel="tag">Illy</a> coffee.
Noise levels can vary from peaceful in the late mornings to nearly overwhelming on
<a href="http://en.wikipedia.org/wiki/jazz" rel="tag">jazz</a> band nights.
</p></blockquote>
Review (<a href="http://microformats.org/wiki/hreview">
hReview v<span class="version">0.2</span></a>)
by <span class="reviewer">anonymous</span>,
<abbr class="dtreviewed" title="20050428T2130-0700">April 28th, 2005</abbr>.
</div>
</nowiki></pre>

With an accompanying CSS style sheet like:

<pre><nowiki>
a.url { display:block }
ul.categories { margin:1em 0; padding:0 }
.categories li { display:inline }
</nowiki></pre>

This hReview could be presented similar to the original text:

Cafe Borrone<br />
1010 El Camino Real, Menlo Park, CA 94025, +1-650-327-0830;<br />
[http://cafeborrone.com/ cafeborrone.com]<br />
<br />
[http://en.wikipedia.org/wiki/Food Food: 18/30];
[http://flickr.com/photos/tags/Ambience Ambience: 19/30];
[http://en.wikipedia.org/wiki/Service Service: 15/30];
[http://en.wikipedia.org/wiki/Price Price: $$...]<br />

<blockquote>This [http://en.wikipedia.org/wiki/cafe cafe] is a welcoming oasis on the Peninsula. It even has a fountain outside which cloaks the nearby sounds of El Camino traffic. Next door to a superb indy bookstore, Cafe Borrone is an ideal spot to grab a [http://en.wikipedia.org/wiki/coffee coffee] or a snack to accompany a newly purchased book or imported periodical. [http://technorati.com/tag/soup Soups] and [http://technorati.com/tag/sandwich sandwich] specials rotate daily. The corn chowder with croutons and big chunks of cheese goes especially well with a freshly toasted mini-baguette. Evenings are often crowded and may require sharing a table with a perfect stranger. [http://flickr.com/photos/tags/espresso Espresso] afficionados will appreciate the [http://en.wikipedia.org/wiki/Illy Illy] coffee. Noise levels can vary from peaceful in the late mornings to nearly overwhelming on [http://en.wikipedia.org/wiki/jazz jazz] band nights.</blockquote>

Review ([http://microformats.org/wiki/hreview hReview v0.2]) by anonymous, April 28th, 2005.

=== Product review ===
Here is an example of a product review:

<pre><nowiki>
<div>
<a href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/">
<img src="http://images.amazon.com/images/P/B000089CJI.01._SCTHUMBZZZ_.jpg"
alt="Album cover photo: The Postal Service: Give Up." />
The Postal Service: Give Up</a>
<blockquote><p>
"The people thought they were just being rewarded for treating others
as they like to be treated, for obeying stop signs and curing diseases,
for mailing letters with the address of the sender... Don't wake me,
I plan on sleeping in..."
</p><p>
"Nothing Better" is a great track on this album, too...
</p></blockquote>
(*****)
</div>
</nowiki></pre>

Adding hReview to this review is also quite simple, but in this case requires a few more elements for the rating and reviewer which are required by hReview:

<pre><nowiki>
<div class="hreview">
<a class="item url" href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/">
<img src="http://images.amazon.com/images/P/B000089CJI.01._SCTHUMBZZZ_.jpg"
alt="Album cover photo: The Postal Service: Give Up. "
class="photo" />
<span class="fn">The Postal Service: Give Up</span></a>
<blockquote class="description"><p>
"The people thought they were just being rewarded for treating others
as they like to be treated, for obeying stop signs and curing diseases,
for mailing letters with the address of the sender... Don't wake me,
I plan on sleeping in..."
</p><p>
"Nothing Better" is a great track on this album, too...
</p></blockquote>
(<abbr class="rating" title="5">*****</abbr>)
<p class="reviewer vcard">Review by
<a class="url fn" href="http://ifindkarma.com/blog/">Adam Rifkin</a>,
<abbr class="dtreviewed" title="200502">February 2005</abbr>
</p>
</div>
</nowiki></pre>

And this hReview might be presented like this:

[Album cover photo: ]
[The Postal Service:]
[ Give Up ]

The Postal Service: Give Up

<blockquote>"The people thought they were just being rewarded for treating others as they like to be treated, for obeying stop signs and curing diseases, for mailing letters with the address of the sender... Don't wake me, I plan on sleeping in..."</blockquote>

<blockquote>"Nothing Better" is a great track on this album, too... </blockquote>

(*****)

Review by Adam Rifkin, February 2005.

=== Movie Review ===
Finally, here is an example of a movie review.

<pre><nowiki>
<div>
<span>anonymous, April 18th, 2005</span>
<div>
<a lang="zh" href="http://www.imdb.com/title/tt0299977/">
Ying Xiong (<span lang="en">HERO</span>)
</a>
</div>
<div>Rating: 4 out of 5</div>
<blockquote><p>
This movie has great visuals and music.
</p></blockquote>
</div>
</nowiki></pre>

With hReview:

<pre><nowiki>
<div class="hreview">
<span class="reviewer">
<span class="fn">anonymous</span>,
<abbr class="dtreviewed" title="20050418">April 18th, 2005</abbr>
</span>
<div class="item">
<a lang="zh" class="url fn" href="http://www.imdb.com/title/tt0299977/">
Ying Xiong (<span lang="en">HERO</span>)
</a>
</div>
<div>Rating: <span class="rating">4</span> out of 5</div>
<blockquote class="description"><p>
This movie has great music and visuals.
</p></blockquote>
</div>
</nowiki></pre>

Which could be presented like this:

anonymous, April 18th, 2005<br />
Ying Xiong (HERO)<br />
Rating: 4 out of 5<br />

This movie has great music and visuals.

== Examples in the wild ==
This section is '''informative'''.

The following sites have published hReviews, and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc. If you publish hReviews on your own page, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* [http://www.livejournal.com/users/danieljohn/ Daniel John] provides a [http://www.livejournal.com/users/danieljohn/58674.html scathing hReview of CIBC].
* [http://uk.movies.yahoo.com/movie-reviews/ Yahoo UK Movie Reviews] now supports hReview on all (>2000) reviews, e.g. [http://uk.movies.yahoo.com/h/Harry-Potter-and-the-Goblet-of-Fire/review-41195.html Harry Potter and the Goblet of Fire Review]
* [http://adam.typepad.com/impossiblethings/ Adam Hertz] wrote an [http://adam.typepad.com/impossiblethings/2005/11/soluna.html hReview of Soluna]
* [http://www.mattmcalister.com/blog/ Matt McAllister] wrote an [http://www.mattmcalister.com/blog/_archives/2005/11/16/1408893.html hReview of the TV show: "The Office"]
* [http://www.bmannconsulting.com/blog/bmann/ Boris Mann] wrote an [http://www.bmannconsulting.com/blog/bmann/doubletake-best-panorama-stitch-tool-for-mac-os-x hReview of DoubleTake, a panorama stitch tool for Mac OS X]
* [http://blog.ftwr.co.uk/ Peter Westwood] has written an [http://blog.ftwr.co.uk/archives/2005/10/03/blubeckers-hampton-court/ hReview of Blubeckers Hampton Court] and an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn Bucks Green, West Sussex]
* [http://dougal.gunters.org/blog/ Dougal] has published an [http://dougal.gunters.org/blog/2005/08/03/french-vanilla-latte hReview of Wolfgang Puck’s Gourmet French Vanilla Latte].
* [http://www.dinnerbuzz.com/ Dinnerbuzz] is a great site for posting tagged reviews of restaurants, and they publish and summarize all their reviews in hReview!
* [http://soldierant.net/ Bryce Glass] posted an [http://soldierant.net/archives/2005/06/product_review.html hReview of the Uniden ELBT 595 Bluetooth Cordless Phone].
* dda posted an [http://sungnyemun.org/wordpress/?p=20 hReview of hReview] :)
* An [http://tbp.xomerang.com/?p=3 hReview of Caffè Camardo coffee].
* [http://loadaveragezero.com/hnav/contact.php Douglas Clifton] posted [http://loadaveragezero.com/#May-12-2005 comments] regarding adapting his list of ~800 [http://loadaveragezero.com/app/drx Developer Resources] as a format for evaluating hReview.
* [http://www.oliverbrown.me.uk/ Oliver Brown] [http://www.oliverbrown.me.uk/2005/05/09/sitereviewsorg-supports-hreview-i-think/ has announced] that his [http://en-us.sitereviews.org/ SiteReviews.org] (which reviews websites) publishes its reviews using hReview, e.g. here is the [http://en-us.sitereviews.org/review-photomatt.net review on SiteReviews.org for photomatt.net].
* [http://www.myelin.co.nz/post/ Phillip Pearson] is publishing hReviews in the [http://coffee.gen.nz/rss/reviews RSS feed of cafe reviews] on his [http://coffee.gen.nz/ kiwi coffee review site], which of course has the reviews in HTML with embedded hReview markup as well.
* [http://station11.net/ticker/ Kjell] is publishing his link blog as a [http://station11.net/ticker/ list of hReviews].
* [http://epeus.blogspot.com/ Kevin Marks] has [http://epeus.blogspot.com/2005_04_01_epeus_archive.html#111484565269684374 published two hReviews] and used unicode "star" characters for his ratings!
* JamesStewart is publishing hReviews in the location pages at his [http://grwifi.net Grand Rapids WiFi site].
* [http://soldierant.net/ Soldier Ant] has [http://soldierant.net/archives/2005/06/product_review.html reviewed a cordless phone].
* [http://www.happenchance.co.uk/ Paul Livingstone] uses hreview to voice his opinion on [http://www.happenchance.co.uk/archives/2005/07/war_of_the_worl.php books], [http://www.happenchance.co.uk/archives/2005/03/im_going_to_fin.php movies] and [http://www.happenchance.co.uk/archives/2005/05/eels_carling_ac.php music].
* [http://www.stuffandnonsense.co.uk/ Andy Clarke] uses hReview for his [http://www.stuffandnonsense.co.uk/general/recommended-reading.html recommended reading list]
* [http://www.tjameswhite.com/blog Tim White] has begun implementing hReviews at [http://reviews.gale.com at work].
* [http://nachlin.com/ Jim Nachlin] has added hReview publishing to the CMS he uses to publish [http://daysofleisure.com/writing his blog].
* [http://whumpdotcom.livejournal.com/236856.html Bill Humphries] has reviewed the book "A Brother's Price" on his LiveJournal.

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse hReviews. If you have an hReview implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* [http://www.goodpic.com/mt/aws/index_us.html Goodpic] has written:
** [http://www.goodpic.com/mt/aws/index_us.html hReview creator for Amazon.com products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.uk products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.jp products]
** be sure to choose the "hRview" tab from among the choices on the page that says "You can choose from more than 30 designs, please click the tab to select categories."
* See the microformats.org [http://microformats.org/code/hreview/creator hReview creator]
* [http://www.eigaseikatu.com/ Eigaseikatu], one of the largest movie community sites in Japan, provides [http://www.eigaseikatu.com/hreview/ hReview creator] for movie review.
* [http://sungnyemun.org/wordpress/?p=22 hReview plugin for WordPress]
* [http://theryanking.com/ Ryan King] has an [http://theryanking.com/microformats/hreview-creator.html hReview Creator].
* [http://rvu.ning.com/ Rvu] is a [http://ning.com Ning] app that lets you write reviews of reviews and publishes them in hReview

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[rel-tag]]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc3986.txt RFC3986]
* [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0]

=== Informative References ===
* [http://www.w3.org/TR/REC-CSS1 CSS1]
* ISO.8601.1988
** International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
* [http://www.w3.org/TR/1998/NOTE-datetime-19980827 W3C NOTE-datetime-19980827]
* [http://www.ietf.org/rfc/rfc3667.txt RFC3667]
* [http://www.ietf.org/rfc/rfc3668.txt RFC3668]
* [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy]
* Other reviews efforts. See [[reviews-formats]].
* Contributed from http://developers.technorati.com/wiki/hReview.

==== Similar Work ====
* [[xoxo]]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

=== Changes from v0.1 ===
The following changes have been made in hReview v0.2:
# '''version'''. Added optional "version" field.
# '''language'''. Made explicit the reuse of (X)HTML 'lang' attribute to convey natural language information.
# '''tags requirement removed'''. Removed requirement of classname "tags" for the tags field, and thus removed the requirement to have an explicit tags field at all, permitting tags anywhere inside the hReview, e.g. inside the description.
# '''permalink requirement removed'''. Removed requirement of classname "permalink", as it is unnecessary, given that the permalink field explicitly requires a hyperlink with rel values of "self" and "bookmark".
# Updated examples accordingly.

== Discussions ==

* Feedback is encouraged on the [[hreview-feedback]] page.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hReview, check the [[hreview-faq|hReview FAQ]], and if you don't find answers, add your questions to the end!

=== Issues ===
* Please add any issues with the specification to the separate [[hreview-issues|hReview issues]] document.

rel-tag

2006-01-20T15:44:46Z

B.K. DeLong: /* Implementations */

= rel="tag" =
__TOC__

== Draft Specification 2005-01-10 ==
=== Editor/Author ===
[http://tantek.com/ Tantek Çelik]

=== Concept ===
[http://powazek.com/ Derek Powazek]
[http://epeus.blogspot.com/ Kevin Marks]

=== Copyright ===
{{MicroFormatCopyrightStatement2004}}

=== Patents ===
{{MicroFormatPatentStatement}}

== Abstract ==
[[Rel-Tag]] is one of several [[MicroFormats]]. By adding <code>rel="tag"</code> to a hyperlink, a page indicates that the destination of that hyperlink is an author-designated "tag" (or keyword/subject) of the current page. Note that a tag may just refer to a major portion of the current page (i.e. a blog post). e.g. by placing this link on a page,

<pre><nowiki><a href="http://technorati.com/tag/tech" rel="tag">tech</a></nowiki></pre>

the author indicates that the page (or some portion of the page) has the tag "tech".

The linked page SHOULD exist, and it is the linked page, rather than the link text, that defines the tag. The last path component of the URL
is the text of the tag, so

<pre><nowiki><a href="http://technorati.com/tag/tech" rel="tag">fish</a></nowiki></pre>

would indicate the tag "tech" rather than "fish".

== Scope ==
rel="tag" is specifically designed for "tagging" content, typically web pages (or portions thereof, like blog posts).

rel="tag" is NOT designed for "tagging" arbitrary URLs or external content. There is demand for a general decentralized syntax for tagging URLs, and that is certainly something to think about, but this is not meant for that.

== XMDP profile ==
<pre><nowiki>
<dl class="profile">
<dt id="rel">rel</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value.</p>
<dl>
<dt id="tag">tag</dt>
<dd>Indicates that the referred resource serves as a "tag",
or keyword/subject, for the referring page.</dd>
</dl>
</dd>
</dl>
</nowiki></pre>

== Tag Spaces ==

Tags are embedded in HTTP URIs in a well-defined manner so that the tag embedded in an HTTP URI can be mechanically extracted from that URI. Specifically, the last segment of the path portion of the URI (after the final "/" character) contains the tag value. For example, the URI <pre><nowiki>http://www.example.com/tags/foo</nowiki></pre> contains the tag "foo".

Thus, for the purposes of comparing two HTTP URIs as tags, the last segment of the path portion should be extracted and only that value (that value of the tag) should be compared.

''Need more formal language about comparison and extraction process.''

The destination of a rel="tag" hyperlink is required to be a tag space (a place that collates or defines tags), where the last segment of the path of the URL is the tag, e.g.

<pre><nowiki>http://technorati.com/tag/tech </nowiki></pre>

is a URL for the tag "tech".

Tags may only be placed in the URL path, and only in the last segment of the path. Tags may not be placed in query parameters or fragment identifiers. e.g.

<pre><nowiki>http://technorati.com/tag/tech?tag=fish#emu </nowiki></pre>

is still a URL for the tag "tech", not "fish" or "emu".

Since the only part of a tag space URL of which any structure is required is the last path segment, a tag space URL can be hosted at any domain. Authors may choose to link to a tag at a particular tag space in order to provide a specific meaning. E.g. a tag for technology could link to:

<pre><nowiki> http://en.wikipedia.org/wiki/Technology </nowiki></pre>

== Encoding issues ==
Spaces can be encoded either as <code>+</code> or <code>%20</code>. Unicode characters are encoded as specified in [http://www.ietf.org/rfc/rfc3986.txt RFC 3986]. For example:

<pre><nowiki><a href="http://technorati.com/tag/Sant%C3%A9+et+bien-%C3%AAtre" rel="tag">Santé et bien-être</a> </nowiki></pre>

== Tags Are Visible Metadata ==
<code>rel="tag"</code> hyperlinks are intended to be visible links on pages and posts. This is in stark contrast to meta keywords (which were invisible and typically never revealed to readers), and thus is at least somewhat more resilient to the problems which plagued meta keywords.

Making tag hyperlinks visible has the additional benefit of making it more obvious to readers if a page is abusing tag links, and thus providing more peer pressure for better behavior. It also makes it more obvious to authors, who may not always be aware what invisible metadata is being generated on their behalf.

As a result the invisible tag link syntax variant: <code><link rel="tag" href="..." /></code> SHOULD NOT be supported by implementations.

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse rel-tag links. If you have a rel-tag implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* [http://news.livejournal.com/86492.html?thread=24881884 LiveJournal] - see also [http://www.livejournal.com/support/faq.bml?cat=tags their FAQ regarding their tags support]
* [http://trac.labnotes.org/cgi-bin/trac.cgi/wiki/TagsLinks TagsLinks] Turn each tag into links that let you find related content on tagging services.
* [http://odeo.com ODEO] [http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html publishes] rel-tags for user entered tags.
* [http://evdb.com EVDB] publishes rel-tags for user entered tags.
* [http://dev.wp-plugins.org/wiki/BunnysTechnoratiTags "Tag plugin for wordpress"]
* Technorati first implemented rel-tag in its [http://technorati.com/tag/ Technorati Tags] service. Technorati indexes rel-tag tags.
* [http://consumingexperience.blogspot.com/2005/12/updated-multiple-word-technorati-tag.html Greasemonkey script for Firefox that generates tags for Blogger]

== References ==
=== Normative References ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML 1]
* [http://gmpg.org/xmdp/ XMDP]
* RFC 3986 specifies URL syntax. Section 3.3 specifies URL paths and path segments.

=== Informative References ===
* [[hreview|hReview]] uses rel-tag for tags and scalar tags
* [[xfolk|xFolk]] uses rel-tag to build a distributed remote resource tagging construct
* [http://developers.technorati.com/wiki/attentionxml Attention.XML] uses rel-tag for reader tagging of pages, posts, feeds
* [[hcard|hCard]] can use rel-tag for categories
* [[hcalendar|hCalendar]] can use rel-tag for categories
* [http://technorati.com/help/tags.html Using Technorati Tags]

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about rel-tag, check the [[rel-faq|rel FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[rel-tag-issues|rel-tag issues]] document.

implementations

2006-01-19T14:59:13Z

B.K. DeLong: /* LiveJournal */

=Microformats Implementors And Implementations=

This page lists the companies, applications, services, and sample code which support microformats, along with the developers responsible for doing so that have chosen to be listed. This is only a partial list. If you know other companies implementing microformats, please add them and list their services and what specific microformats they support.

__TOC__

== By Format ==

Most microformat specifications have an "implementations" section, e.g.:
* [http://microformats.org/wiki/hcalendar#Implementations hCalendar], [http://microformats.org/wiki/hcard#Implementations hCard], [http://microformats.org/wiki/rel-tag#Implementations rel-tag], [http://microformats.org/wiki/vote-links#Implementations vote-links], [http://microformats.org/wiki/xoxo#Implementations XOXO]

In addition, some microformat specifications have separate implementation pages:
* [[xfn-implementations]]

== By Tool ==
* [[greasemonkey]] scripts for Firefox

== By Company / Organization / Author ==

=== Avon ===
* [http://avon.com/ Avon] - publishes all 40,000+ Avon representatives' contact info with the [[hcard|hCard]] microformat.

=== BlogMatrix ===
* [http://www.blogmatrix.com BlogMatrix] - user information marked as [[hcard|hCard]], tag directories in [[xfolk]]/[[rel-tag]], enclosures are marked as [[rel-enclosure]].
* developers
** [http://blogmatrix.blogmatrix.com David Janes]

=== Drupal ===
* [http://hybernaut.com/upcoming-module Drupal Upcoming.org syndication module] emits [[hcalendar|hCalendar]]
* developers:
** [http://hybernaut.com/ Brian Del Vecchio]

=== EVDB ===
* [http://evdb.com EVDB] supports [[hcalendar|hCalendar]] for over 100,000 event listings and [[hcard|hCard]] for venues.

=== Flock ===
* [http://flock.com Flock] browser supports the [[rel-tag]] microformat.
* [http://flock.com/about Flock About] page supports [[hcard|hCard]] microformat.

=== Google ===
* [http://google.com/ Google] - supports [[rel-nofollow]]
* [http://www.google.com/webhp?as_rights=(cc_publicdomain%7Ccc_attribute%7Ccc_sharealike%7Ccc_noncommercial%7Ccc_nonderived) Google Creative Commons Search] - supports [[rel-license]]

=== Ice Rocket ===
* [http://icerocket.com] - [http://blogs.icerocket.com/tag/ supports] [[rel-tag]]

=== Iowa Military Veterans Band ===
* [http://www.iowamilitaryveteransband.com/members/ Iowa Military Veterans Band]

=== Karova ===
* [http://www.karova.com/ Karova] [http://www.karova.com/article.aspx?id=4 supports microformats]

=== Konqueror ===
* [http://www.konqueror.org/ Konqueror] - [http://flickr.com/photos/factoryjoe/68755089/ supports] [[hcard|hCard]]

=== Laughing Squid ===
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events listings support [[hcalendar|hCalendar]].

=== LiveJournal ===
* [http://www.livejournal.com LiveJournal] - LiveJournal supports tagging posts with [[rel-tag]].

=== LJFind ===
* [http://www.ljfind.com LJ-Find] - LJFind supports tagging posts with [[rel-tag]].

=== ODEO ===
* [http://odeo.com/ ODEO] [http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html noted] that they support microformats: [[rel-tag]], [[rel-enclosure]], [http://gmpg.org/xfn XFN].

=== Sunnyvale House Concerts ===
* [http://concerts.shrub.ca/shows Sunnyvale House Concerts] supports [[hcard|hCard]] and [[hcalendar|hCalendar]].

=== Technorati ===
* [http://technorati.com/ Technorati] supports and handles both [[vote-links]] and [[rel-nofollow]] for indicating whether a link should have any/positive/negative weighting towards the destination.
* [http://technorati.com/tag/ Technorati Tags index] - an index of blog posts tagged with the [[rel-tag]] open tagging standard.
* [http://tantek.com/microformats/hcard-creator.html hCard creator] - contributed to [http://microformats.org/code/hcard/creator microformats.org as open source]. This is a very simple, yet illustrative, open source user interface / form / script which creates an hCard in real-time as you type in a set of contact information.
* [http://theryanking.com/microformats/hcalendar-creator.html hCalendar creator] - contributed to [http://microformats.org/code/hcalendar/creator microformats.org as open source]. Similar, but for hCalendar.
* [http://theryanking.com/microformats/hreview-creator.html hReview creator] - contributed to [http://microformats.org/code/hreview/creator microformats.org as open source]. Similar, but for hReview.
* [http://tantek.com/microformats/buddylist2hcards.html iChat buddy list to hCards] - open source AppleScript to automatically convert one's buddy list in the MacOSX iChat AIM client into a valid XHTML 1.0 Strict list of hCards.
* [http://technorati.com/ Technorati] publishes its own contact information as [[hcard|hCard]]s: [http://technorati.com/about/ About page] lists their Media Contact, and their [http://technorati.com/press/ Press page] also lists their Press Contact, both as inline hCards.
* developers:
** [http://epeus.blogspot.com/ Kevin Marks]
** [http://theryanking.com Ryan King]
** [http://tantek.com/log/ Tantek Çelik]

=== Upcoming.org ===
* [http://upcoming.org Upcoming.org] - hCalendar support in events listings and individual events.

=== University of Bath ===
* [http://www.bath.ac.uk/ University of Bath] [http://www.bath.ac.uk/contact/ Person Finder] supports [[hcard|hCard]]

=== Web Essentials ===
* [http://we05.com/ Web Essentials] - supports [[hcard|hCard]] and [[hcalendar|hCalendar]], e.g. in their [http://we05.com/presenters.cfm list of presenters] and [http://we05.com/program.cfm program schedule].

=== WordPress ===
* [http://wordpress.org WordPress] supports [http://gmpg.org/xfn/ XFN] blogrolls through a very nice built-in user interface.

=== Yahoo ===
* [http://search.yahoo.com/cc/ Yahoo Creative Commons Search] - supports [[rel-license]] specifically to search for Creative Commons licensed content.

=== suda.co.uk ===
[http://suda.co.uk/ brian suda] has created several XSLT files to extract microformats from HTML. From that the [http://suda.co.uk/projects/X2V/ X2V] webservice/favelet emerged. The XSLT and favelet extracts [[hcard|hCard]] and to produces .vcf (vCard) files and [[hcalendar|hCalendar]] to produce .ics (iCal) files. Also in the labs is a universal XMDP validator and a site-wide search spider that recognizes 'no-follow', 'license' and other microformats so they can be used in a more semantic way when displaying search results.

=== other ===
* [http://greenbytes.de/tech/webdav/rfc2629.xslt rfc2629.xslt] now attempts to generate hCard information ([http://ietf.org/rfc/rfc2629 RFC2629] is an XML format for authoring RFCs and Internet Drafts, see [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html example document])
* [http://thedredge.org Andy Hume] uses the hcard format to mark-up the names and URLs of commentors on his blog.
* [http://web.mit.edu/glasser/www/JSCalendar/ JSCalendar] parses hCalendar and produces a displayable HTML table/CSS-based calendar.

==general info==
Some notes on initial thoughts around [[implementation-guidelines|Guidelines and Strategies for Implementing Microformats]]

irc

2006-01-18T15:01:08Z

B.K. DeLong: /* People on irc */

__NOTOC__
= Microformats IRC =

We have an IRC channel, [irc://irc.freenode.net#microformats #microformats on the freenode network].

There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.

== People on irc ==
A list of IRC regulars and their normal timezones.

* [[User:RyanKing|kingryan]] (-0800)
* [[User:EdwardOConnor|hober]] (-0800)
* [[User:RobertBachmann|RobertBachmann]] (+0100)
* [[User:Tantek|Tantek]] (-0800)
* [http://epeus.blogspot.com/ KevinMarks] (-0800)
* [[User:DimitriGlazkov|dglazkov]] (-0600)
* [[User:ChrisMessina|factoryjoe]] (-0800)
* [[User:IanHickson|Hixie]] (-0800)
* [[User:neuro|neuro`]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Cgriego|cgriego]] (-0600)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:Izo|IZO]]
* [[User:Fil|Fil]] (+0200)
* [[User:B.K._DeLong|bkdelong]] (-0500)

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [http://joi.ito.com/joiwiki/JiBot jibot]

== Logs ==

Available here: http://rbach.priv.at/Microformats-IRC/

== IRC meetups ==

The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.

irc

2006-01-18T15:00:50Z

B.K. DeLong: /* People on irc */

__NOTOC__
= Microformats IRC =

We have an IRC channel, [irc://irc.freenode.net#microformats #microformats on the freenode network].

There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.

== People on irc ==
A list of IRC regulars and their normal timezones.

* [[User:RyanKing|kingryan]] (-0800)
* [[User:EdwardOConnor|hober]] (-0800)
* [[User:RobertBachmann|RobertBachmann]] (+0100)
* [[User:Tantek|Tantek]] (-0800)
* [http://epeus.blogspot.com/ KevinMarks] (-0800)
* [[User:DimitriGlazkov|dglazkov]] (-0600)
* [[User:ChrisMessina|factoryjoe]] (-0800)
* [[User:IanHickson|Hixie]] (-0800)
* [[User:neuro|neuro`]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Cgriego|cgriego]] (-0600)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:Izo|IZO]]
* [[User:Fil|Fil]] (+0200)
* [[User:B.K._DeLong|bkdelong] (-0500)

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [http://joi.ito.com/joiwiki/JiBot jibot]

== Logs ==

Available here: http://rbach.priv.at/Microformats-IRC/

== IRC meetups ==

The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.

hcalendar-brainstorming

2006-01-17T02:24:13Z

B.K. DeLong: /* General Questions */

= hCalendar Brainstorming =
__TOC__
== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik]

= BEST-PRACTICES =
Along with the four base properties, you can define addtional properties through the use of the x-prop property. For best-practices for hCal to iCal transformers, it would be helpful if the transforming application added the following x-* properties:

* X-FROM-URL. The value of this property would be the URL of the page where the iCal representation was generated.
<pre><nowiki>
X-FROM-URL:http://example.com/page-containing-hCal-encoding.html
</nowiki></pre>

* X-WR-CALNAME. iCal.app recognizes this property as the "calendar name" for subscribed calendars. Thus transforming applications *should* take the <code><title>...</title></code> from the page being parsed, optionally append " events", and use that value for the X-WR-CALNAME property in the resulting feed. E.g. if the page had <code><title>Example Home Page</title></code> then the .ics output should have as part of the vcalendar object:
<pre><nowiki>
X-WR-CALNAME:Example Home Page
</nowiki></pre>

= Examples =
This is a growing example case written in iCal format and transformed to the corresponding XHTML. These conversions are open to community input.

<pre><nowiki>
BEGIN:VEVENT
CATEGORIES:foo,bar
SUMMARY: Short Title
DESCRIPTION: Full Description
DTSTART;VALUE=DATE:20040101
DTEND:20040101T235959Z
RRULE:FREQ=YEARLY;UNTIL=20080102T000000Z
URL;WORK:http://example.com
ATTENDEE;ROLE=CHAIR:MAILTO:JohnDoe@example.com
GEO:37.386013;-122.082932
END:VEVENT
</nowiki></pre>
<pre><nowiki>
<p class="vevent">

Categories:
<ul class="categories">
<li>foo</li>
<li>bar</li>
</ul>
<a href="http://example.com" class="summary">Short Title</a>
<span class="description">description</span>
<span class="geo"><span class="Lat">37.386013</span> <span class="Lon">-122.082932</span></span>



Date: <em class="dtstart">20040101</em> - <em class="dtend">20040101T235959Z</em>




<a class="attendee chair" href="mailto:JohnDoe@example.com">John Doe</a>


<p class="rrule">The event will be held <span class="freq">yearly</span> until <span class=""until">20080102T000000Z</span>.</p>

</p>
</nowiki></pre>

@@-need to look at nested tag examples
<pre><nowiki>
XHTML
<span class="description"><span class="summary">Short Title</span> to a longer article</span>

vCal
SUMMARY:Short Title
DESCRIPTION:Short Title to a longer article
</nowiki></pre>

== Examples from RFC 2445 ==

* <del>Note: this subsection is worthy of being the start of a new page: [[hcalendar-examples]], similar to [[hcard-examples]] -[http://tantek.com/log/ Tantek]</del>
* These examples are now all available on [[hcalendar-examples]] -[[User:RyanKing]]

With the abbr's title attribute being used rather than the node value, the actual data could vary and still represent the same vcalendar.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:19970714T170000Z
DTEND:19970715T035959Z
SUMMARY:Bastille Day Party
END:VEVENT
END:VCALENDAR
</nowiki></pre>

<pre><nowiki>
<span class="vcalendar">
<span class="vevent">
<abbr class="dtstart" title="19970714T170000Z">July 14th</abbr>
<abbr class="dtend" title="19970715T035959Z"></abbr>
<span class="summary">Bastille Day Party</span>
</span>
</span>
</nowiki></pre>

=== UID handling ===

The UID in iCal is represented in HTML as the id attribute in these examples. Any valid id in HTML is a valid UID in iCal, but not the contrapositive, a valid UID is NOT a valid HTML id. HTML ids can only start with a letter, not a number.

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123401@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970903T163000Z
DTEND:19970903T190000Z
SUMMARY:Annual Employee Review
CLASS:PRIVATE
CATEGORIES:BUSINESS,HUMAN RESOURCES
END:VEVENT
</nowiki></pre>

<pre><nowiki>
<span class="vcalendar">
<span class="vevent" id="19970901T130000Z-123402@host.com">
<abbr title="dtstamp" class="19970901T1300Z"></abbr>
<abbr title="dtstart" class="19970903T163000Z">September 3rd, 4:30pm</abbr>-
<abbr title="dtend" class="19970903T190000Z">7:00pm</abbr>
<span class="summary">Annual Employee Review</span>
<span class="class">private</span>
<ul class="categories">
<li>BUSINESS</li>
<li>HUMAN RESOURCES</li>
</ul>
</span>
</span>
</nowiki></pre>

<pre><nowiki>
BEGIN:VCALENDAR
BEGIN:VEVENT
UID:19970901T130000Z-123402@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970401T163000Z
DTEND:19970402T010000Z
SUMMARY:Laurel is in sensitivity awareness class.
CLASS:PUBLIC
CATEGORIES:BUSINESS,HUMAN RESOURCES
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR
</nowiki></pre>
<pre><nowiki>
<span class="vcalendar">
<span class="vevent" id="19970901T130000Z-123402@host.com">
<abbr title="dtstamp" class="19970901T1300Z"></abbr>
<abbr title="dtstart" class="19970401T163000Z">April 1st 4:30pm</abbr>-
<abbr title="dtend" class="19970402T010000Z">1:00am</abbr>
<span class="summary">Laurel is in sensitivity awareness class.</span>
<span class="class">PUBLIC</span>
<ul class="categories">
<li>BUSINESS</li>
<li>HUMAN RESOURCES</li>
</ul>
<span class="transp">Transparent</span>
</span>
</span>
</nowiki></pre>

=== RRULE handling ===

The way RRULE is encoded should be discussed.

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123403@host.com
DTSTAMP:19970901T1300Z
DTSTART:19971102
SUMMARY:Our Blissful Anniversary
CLASS:CONFIDENTIAL
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
RRULE:FREQ=YEARLY
END:VEVENT
</nowiki></pre>
<pre><nowiki>
<span class="vcalendar">
<span class="vevent" id="19970901T130000Z-123403@host.com">
<abbr title="dtstart" class="19970901T1300Z"></abbr>
<abbr title="dtend" class="19971102">November 2nd</abbr>
<span class="summary">Our Blissful Anniversary</span>
<span class="class">CONFIDENTIAL</span>
<ul class="categories">
<li>ANNIVERSARY</li>
<li>PERSONAL</li>
<li>SPECIAL OCCASION</li>
</ul>
<span class="rrule"><span class="freq">YEARLY</span></span>
</span>
</span>
</nowiki></pre>

== Examples from real world event sites ==

=== Laughing Squid ===

Laughing Squid had the following [http://laughingsquid.com/squidlist/calendar/9584/2005/4/7 multiple occurence event example]:

Thu, Apr 7 : Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm

In addition, later on in the description, it says:

April 7-21, 2005

This is actually quite a non-trivial example, because the event lasts for different durations on different days (4 hours, 7 hours, 6 hours).

Because of the differing durations, the specification requires that *each* instance of this recurring event be explicitly specified.

But first we markup the starting date and time explicitly:
<pre>
<abbr class="dtstart" title="20050407T1200-0700">Thu, Apr 7</abbr> :
</pre>
Then we put in the quite lengthy explicit specification of every other time the event occurs, marked up around the human readable description.
<pre>
<abbr class="rdate" title="20050407T1200-0700/PT7H, 20050408T1200-0700/PT7H,
20050409T1200-0700/PT7H, 20050410T1200-0700/PT6H, 20050412T1200-0700/PT4H,
20050413T1200-0700/PT4H, 200504014T1200-0700/PT7H, 20050415T1200-0700/PT7H,
20050416T1200-0700/PT7H, 20050417T1200-0700/PT6H, 20050419T1200-0700/PT4H,
20050420T1200-0700/PT4H, 20050421T1200-0700/PT7H" >
Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm
</abbr>
</pre>

The RDATE "PERIOD" format is fairly straightforward. You simply list *each* occurrence of the event, separated by commas. Each occurrence consists of the ISO8601 datetime of the start of the event, followed by a slash "/", followed by *either* the duration of the event (e.g. 7 hours = PT7H), *or* a complete ISO8601 datetime of the end of the event. I chose to use the duration of the event for this example for reason of brevity.

Note that "value=period:" is unnecessary in the rdate value since the parser can infer "value=period:" from the presence of a "/" in the title attribute value.

With simpler repeating events, or perhaps events which only repeat a day or two, their hCalendar markup may be more illustrative of how to do this in a general way.

= CSS Styles =
Since the hCal properties are added in as CSS styles, you can style them along with any normal CSS style. You are free to style these properties in any fashion you want (see specific notes), but here are a few examples that you can use.

== Preserving White-space ==
If you are encoding data that requires tabs, returns, or other white-space to be perserved you can use the following CSS property to do so in HTML.
<pre><nowiki>
<span style="white-space: pre">
This white-space
will be
preserved
</span>
</nowiki></pre>
white-space can take one of three different parameters; normal, pre, and no-wrap.

== Not recommended ==

The following CSS styling techniques are not recommended:

=== Hiding Data ===
It is possible to encode additional data without it being displayed in the HTML, by using the CSS style property 'display'.
<pre><nowiki>
<span style="display:none">Hidden Data</span>
</nowiki></pre>
This data will be found by any transforming application and will be properly encoded into an iCal file.

'''You SHOULD NOT do this because it violates the visibility priniciple.'''

= Tutorials =
How to include hCal encodings into your favourite Blogging Software.

= Open Questions =
== General Questions ==
Q: Should Transforming applications purely extract the information and ignore validity? or should there be some checking, or should this be left to the importing application? (i.e. DTSTART;VALUE=DATE: This-Is-Not-a-proper-date)

A: The simpler the better. Other than checking for perhaps X(HT)ML validity, it should be a simple translator, because presumably the receiving iCalendar application has to have malformed .ics handling already. Let's avoid duplicating that. -- [http://tantek.com/ Tantek Çelik]

Q: What about multiple of the instances same vCal entity? (two instances of DTSTART) Is this left up to the importing application, or should the XSLT transformation fail?

A: Same as previous. Leave it up to the importing application to interpret it per the iCalendar spec, e.g. what does RFC2445 say about two instances of DTSTART? -- [http://tantek.com/ Tantek Çelik]

From RFC2445:
4.1.2 Multiple Values
Some properties defined in the iCalendar object can have multiple values. The general rule for encoding multi-valued items is to simply create a new content line for each value, including the property name. However, it should be noted that some properties support encoding multiple values in a single property by separating the values with a COMMA character (US-ASCII decimal 44). Individual property definitions should be consulted for determining whether a specific property allows multiple values and in which of these two forms.

Other than that, it does not mention what to do ABOUT invalid data, or which of the multiple entries takes precedence. The only mention of duplicate instances is in the RRULE and EXDATE rules where events exclusions/inclusions overlap. Then duplicate instances are ignore. If it is explicitly written for those items, but NOT for things like DTSTART, then it is difficult to assume duplicate instances are ignored for them as well.

Each of the Components (VEVENT, ...) define which properties can exisit and in what quantity. So multiple DTSTART properties are NOT allowed.
-- [http://suda.co.uk Brian Suda]

Q: Should vCal entitles be represented in XHTML in classes ONLY on block-level element? or should some like VEVENT be block-level and others be of any? does this impact the semantics at all?

A: I don't think the (X)HTML notion of "block-level" should have any bearing whatsoever on vCal entities. You should be able to say <span class="vevent"> or <div class="vevent"> and either should work.

Q: Should the transforming application add any additional information to the iCalendar representation other than what was encoded in the HTML? (i.e. UID, the unique identifier might not be present in the HTML code, but could be generated by the transforming application and added to the iCal file. Should this be allowed? or should the transforming app ONLY be allowed to add X-PROPERTY properties?) IF it was not explicitly encoded in the HTML should it be left out? What about default values?

Q: If we are looking at the most semantic way to encoding iCalendar data in HTML then several other attributes should be considered besides just 'class'. There are two other candidated, ID and REL. The ID tag MUST be unique within the XHTML file (this could be used for the UID property). The REL attribute can ONLY be applied to 'a' and 'link' tags, but might be helpful. Are namespac<ETH>H �n option? xml:lang, xml:base, are there any others that might be more semantically correct to encode this data?

Q: To help distinguish xparam values from other actual CSS styles, should we assume/mandate that all values in a class attribute within an encoded iCal component class attribute (<x class="vevent|vtodo|...">) be considered an xparam?

A: If you are using other CSS styles (e.g. "center", "bluebox", "greenline", etc.) nested within an iCal component, those should be avoided and the styles applied to the list of iCal properties instead/also?

<pre><nowiki>
.center, .vevent { text-align: center; }
</nowiki></pre>

Q: What about cases where the words "yesterday", "last year", or "last week" was used? How should we represent this? Is this overkill or not appropriate for hcard ? - [[User:B.K._DeLong]]

A: I took a stab at "yesterday" and just added a dtstart of the previous day. Not sure how to represent a single year or whole week - [[User:B.K._DeLong]]

<pre><nowiki>
<abbr class="dtstart" title="20050114">Yesterday's</abbr>
</nowiki></pre>

== Recurring Events ==

Recurring events are tricky. First, there's the question of whether to follow ''For types with multiple components, use nested elements with class names equivalent to the names of the components'' a la
<pre>
<nowiki><div class="rrule">every <em class="interval">1</em>
<em class="freq">WEEKLY</em> on <em class="byday">TU</em>
until <em class="until">2004-11-01</em></div></nowiki>
</pre>
... or ...
<pre>
<nowiki><abbr class="rrule" title="FREQ=WEEKLY;COUNT=17;INTERVAL=2;BYDAY=TH"> every other
Thursday for 34 weeks</abbr></nowiki>
</pre>
... as in [http://microformats.org/discuss/mail/microformats-discuss/2005-August/000516.html Tantek's 1 Aug msg].

[http://www.w3.org/People/Connolly/ DanC] has been experimenting with representing his PDA calendar in hCalendar:

* in [http://dev.w3.org/cvsweb/2001/palmagent/ palmagent], there's dangerSync.py which uses the XMLRPC interface and spits out RDF data. Then asHCal.xsl converts that to hCalendar
* then in [http://www.w3.org/2002/12/cal/ the RDF Calendar workspace], there's [http://www.w3.org/2002/12/cal/glean-hcal.xsl glean-hcal.xsl] that turns hCalendar into RDF Calendar, and finally,
* in [http://www.w3.org/2000/10/swap/ SWAP] there's [http://www.w3.org/2000/10/swap/pim/toIcal.py toIcal.py] that turns RDF Calendar to .ics format.

So I can go from my sidekick to .ics with one Makefile.

[http://dev.w3.org/cvsweb/2001/palmagent/event-test.html events-test.html] is a test file that has all the constructs from my PDA data, in hCalendar. In particular, it uses the nested element representation of recurring events. glean-hcal.xsl would be much less fun to write if it had to parse <nowiki>title="FREQ=WEEKLY;COUNT=17;INTERVAL=2;BYDAY=TH"</nowiki>.

Then there's the question of "every tuesday afternoon at 2pm Chicago time". This isn't expressible using [[datetime-design-pattern]]. There are some good reasons for that, but it leaves a rather large and uncomfortable gap in hCalendar.

== Encoding Questions ==
The way dates are encoded is not always the most user friendly. If i want to encode january 1st, 2005, that is <code><span class="dtstart">20050101</span></code>, which is displayed as 20050101. If we are marking-up comma seperated values, like FN, with each sub-element inside their own tag, then the date should be allowed the same.

(However, FN is in the RFC2426 spec and vCard schema, these individual date terms are not, therefore the reasoning in the last sentence is incorrect. -[http://tantek.com/log/ Tantek])

<pre><nowiki>
20050101
<span class="dtstart"><span class="Year">2005</span><span class="Month">01</span><span class="Day">01</span></span>
</nowiki></pre>
With this encoding, then YYYYMMDD schema can be rearranged for different cultures, DD-MM-YYYY for UK, MM-DD-YYYY for US, etc.
<pre><nowiki>
02-01-2005
<span class="dtstart"><span class="Month">02</span>-<span class="Day">01</span>-<span class="Year">2005</span></span>
01-02-2005
<span class="dtstart"><span class="Day" title="first">01</span>-<span class="Month" title="Feb">02</span>-<span class="Year">2005</span></span>
</nowiki></pre>
Both of the above encodings are equal, the '-' seperator is ignored by the transforming application. -- [http://suda.co.uk Brian Suda]

Agreed that the way dates are encoded is not always the most user friendly, but there is an easier solution to this, once you think of what is actually going on in the difference between ISO8601 dates, and dates the way humans use them. Humans typically use an abbrevation or shorthand for a date, like "tomorrow", or "Tuesday", or "the 4th", or perhaps "July 4th". Thus it makes sense to permit this in hCalendar, using the <code><abbr></code> tag which provides the ability to markup the human-familiar short form of some data or language, while preserving the long form in the 'title' attribute.

E.g. for the above example of a start date of January 1st, 2005, you could use this markup:

<pre><nowiki>
<abbr class="dtstart" title="20050101">January 1st, 2005</abbr>
</nowiki></pre>

Which would display as <code>January 1st, 2005</code> but would provide the respective ISO8601 date in the title attribute. - [http://tantek.com/log Tantek]

= TODO =
A HTML head profile needs creation and a home.

== Applications ==
A simple implementation of transforming/extracting vCal data from an XHTML file is available for testing. A bookmarklet is also available. The code will be updated as the spec is finalised.
http://suda.co.uk/projects/X2V/

== Parsing ==

Need to write up an [[hcalendar-parsing]] document, similar to [[hcard-parsing]].

=== Tabular Data ===

Many calendars are posted in tabular form, where the headings on the columns and rows have property values that apply to the cells which themselves are events.

(TODO: document "How To" for marking up tabular event listings)

To enable mark these up with [[hcalendar|hCalendar]], we must parse additional semantic attributes from HTML4.

When parsing, in addition to the special case rules documented in [[hcard-parsing]]:

* If the element is a table data cell <code><td></code>, then:
*# parse its "headers" attribute as a space separated set of local IDs
*# find the <code><td></code> and <code><th></code> elements referenced by those IDs (call them header cells) and consider them part of the element being parsed as follows:
*## Treat the header cells as children of the element, ordered by the order of ids in its "headers" attribute, immediately following the last child node (text or element) or the element. (The basic idea is that the content from those header cells is used to construct the VEVENT, but secondary to (AFTER) the content in the data cell itself, so that the data cell can customize/override part of the data in the header, e.g. if the header cell included both start time and location, and the event was being held at a different location).
*## Parse the "axis" attribute of a header cell as a comma-separated list of categories. These categories must be used in addition to (and before) any class names on that header cell for determining whether it is a property of the VEVENT.

== Relationships with other microformats ==

In a [http://www.technologyreview.com/articles/04/10/frauenfelder1004.asp Technology Review interview], TBL said "It would have the relationships between the event and the various people chairing it.".

We should have examples of how hCalendar events can indicate such relationships, both in the format and in the presentation.
E.g.:
* Would it just link to URLs for the various people? (e.g. to their homepages/blogs etc.)
* Would it include hCards for the various people?
* Would it link to hCards for various people?
* Perhaps allow all the above?

== Mime-Type ==
According to RFC2445, the proposed media type value is 'text/calendar'.

A standard vCalendar file has an extension of .vcs and MIME type of text/x-vCalendar. If you use iCalendar, the MIME type is "text/Calendar" and the extension is .ics.

Text/X-vCalendar Content Type
The vCalendar object can also be passed as a non-standard MIME media type. This would be useful in order to clearly identify the vCalendar object in an electronic mail message body part. A non-standard, vCalendar object should be identified as the MIME type/subtype "text/x-vCalendar".

@@ - i have to do some more investigation, but (i think) vCalendar is a subset of iCalendar, so many of the same encodings will work for both, but this document is dealing with iCalendar RFC2445 representation!

== Button ==

We need to come up with a nice <code>[ hCal | friendly ]</code> button to indicate that event info on a page/site is using hCalendar. - [http://tantek.com/log/ Tantek].

Possibilities:
* <code>[ hCal | friendly ]</code>
* <code>[ hCal | aware ]</code>
* <code>[ hCal | inside ]</code>
* <code>[ Valid | hCalendar ]</code> - though that would require writing an hCalendar validator which people could link to.
* <code>[ <icon> | hCalendar ]</code> where <icon> could be some generic calendar looking thing, or it could be a PHP generated image with the actual date in the icon, kind of like how the Apple iCal icon updates in the dock automatically.

And then we have to pick colors and all that stuff - [http://tantek.com/log/ Tantek].

Other ideas:
* <code>[ hCal | enabled ]</code>
* <code>[ hCal | available ]</code> - kind of an off-hand reference to being available for meetings, etc.

- [http://meyerweb.com/ Eric]

== Including More of iCalendar ==

=== Free/Busy information ===

See [http://www.ifreebusy.com/cyclical/blog/ Neil Jensen]'s [http://www.ifreebusy.com/cyclical/blog/calendar/3 analysis of how to represent the iCalendar VFREEBUSY object in hCalendar].

In order to show free/busy information, we could either use the existing vevent class (with empty location, summary, etc. properties) or create a new vfreebusy class. We should create a new vfreebusy class because it is consistent with the XHTML design principles, particularly point #4, "Use class names based on names from the original schema...".

In the iCalendar standard, the vfreebusy calendar component frequently has more than one freebusy property, and also may have a number of other properties such as organizer. For example:

<pre><nowiki>
BEGIN:VFREEBUSY
ORGANIZER:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
</nowiki></pre>

So, our hCalendar representation should include separate elements for the vfreebusy calendar component (defined once) and the freebusy property (possibly defined many times):

<pre><nowiki>
<span class="vfreebusy">
<span class="freebusy">
<abbr class="dtstart" title="20050721T1000-0800">
July 21, 2005 - 10:00
</abbr> -
<abbr class="dtend" title="20050721T1100-0800">
11:00
</abbr>
</span><br/>
<span class="freebusy">
<abbr class="dtstart" title="20050722T1000-0800">
July 22, 2005 - 10:00
</abbr> -
<abbr class="dtend" title="20050722T1100-0800">
11:00
</abbr>
</span><br/>
</span>
</nowiki></pre>

According to RFC2445, "When publishing a "VFREEBUSY" calendar component, the property is used to specify the calendar that the published busy time came from." The property type is CAL-ADDRESS, and can include "non-standard, language, common name and directory entry reference" property parameters. CAL-ADDRESS is "...a URI as defined by [RFC 1738] or any other IANA registered form...".

From what I've seen, Microsoft Outlook typically populates this property with the email address of the calendar owner, which initially made me think of using hCard to specify the organizer. However, given that the property refers to the calendar and not necessarily the person who owns or has published it, I think we should use a new organizer element, as shown below:

<pre><nowiki>
BEGIN:VFREEBUSY
ORGANIZER:jsmith@host.com
FREEBUSY:20050314T133000Z/20050314T163000Z
END:VFREEBUSY
</nowiki></pre>

becomes

<pre><nowiki>
<span class="vfreebusy">
organizer: <span class="organizer">jsmith@host.com</span>
<span class="freebusy">
<abbr class="dtstart" title="20050314T133000Z">
March 14, 2005 - 13:30
</abbr> -
<abbr class="dtend" title="20050314T163000Z">
16:30
</abbr>
</span><br/>
</span>
</nowiki></pre>

Hmmm, this looks a little funny when the organizer is so obviously an email address, but at least it is semantically correct. The other problem that I can now see occurring is when the organizer property has parameters, for example (from the iCalendar spec):

<pre><nowiki>
ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ
ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com
</nowiki></pre>

Perhaps it's best to use the same approach described in "Human vs. ISO8601 dates problem solved"; use the abbr element like so:

<pre><nowiki>
<span class="vfreebusy">
<span class="freebusy">
organizer: <abbr class="organizer" title="CN=JohnSmith;DIR=ldap://host.com:6666/o=3DDC%20Associ
ates,c=3DUS??(cn=3DJohn%20Smith):MAILTO:jsmith@host1.com">jsmith@host1.com</abbr>
<abbr class="dtstart" title="20050314T133000Z">
March 14, 2005 - 13:30
</abbr> -
<abbr class="dtend" title="20050314T163000Z">
16:30
</abbr>
</span>
</span>
</nowiki></pre>

=== To-Do information ===

The [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting - 23 Aug 2005] uses class="vtodo" to capture action items. Clearly recording action items from a meeting and publishing them as minutes is a good practical example use of the VTODO object on the web.

What's the scenario for usage though?

What kind of indexer/aggregator application would find these VTODO items and what would it do with them?

Perhaps with some way of figuring out who the to-do item is assigned to ("ATTENDEE"), who assigned it ("DELEGATED-FROM"), and a whitelisting of who, perhaps the "ORGANIZER" property, (and their domains/URLs) that a user would accept assignments from, a user could aggregate to-do items assigned from other folks. Then question remains how to update the status ("STATUS") (RFC 2445 4.8.1.11 Status) on that to-do item when it is (a) completed ("COMPLETED"), (b) abandoned/cut/rejected ("CANCELLED"), (c) some progress is made ("IN-PROCESS") etc. There certainly seems to be sufficient expressiveness in VTODO and its properties to do a decentralized to-do list / task distribution system. Could be very interesting for helping open source projects and other distributed teams do project management using the Web.

= References =
== Normative References ==
* [http://www.ietf.org/rfc/rfc2445.txt RFC 2445]
* [http://gmpg.org/xmdp/ XMDP]

== Informative References ==
* [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars HTMLForCalendars (FOO camp)] - presented just a few days before this, hopefully these efforts can be combine

* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.ietf.org/rfc/rfc2446.txt iTIP RFC2446]
* [http://www.ietf.org/rfc/rfc2447.txt iMIP RFC2447]
* [http://www.ietf.org/rfc/rfc3283.txt Guide to Internet Calendaring RFC3283]

== Other Implementations/Ideas ==
* [http://www.nehmer.net/~bergie/openpsa-calendar-horizontal.jpg OpenPSA calendar screenshot]
* [http://www.w3.org/2002/12/cal/ RDF Calendar Workspace] - some older work done with RDF, not really applicable to the simple XHTML case, but perhaps worthy of analysis for when and why they may have diverged from established iCalendar schemas.
* [http://planb.nicecupoftea.org/archives/000072.html 2003 RDF icalendar work, xCal references]

== Blogs About Calendaring ==
* http://staff.washington.edu/oren/weblog2/

hcalendar-faq

2006-01-17T02:18:14Z

B.K. DeLong: /* Q&A */

= hCalendar FAQ =

This page is for documenting Q&A about [[hcalendar|hCalendar]]. If you have a new question to ask, Please consider first asking your question on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] list.

== Q&A ==

# ''How do I use a class inside <span class="vcalendar"> when I don't want the element I use it on to be a property of the calendar?''
#*Use a class name that isn't a defined iCalendar property name.
# ''What happens if the class is used both inside and outside <span class="vcalendar">?''
#* That works fine.
# ''What do I do if I want to add styling to a group of calendar events, especially if the calendar contains dynamic content? ''
#* You can write style rules that incorporate both the context of said group (say it is in an ordered list with class name "group" for example) and the events, e.g.:<code>ol.group .vevent { /* insert common styling here */ } </code>
# ''What do you do if you don't want the calendar or card to be displayed?''
#* If you don't want the calendar or card to be displayed, why are you publishing it on the Web?
# ''What if you don't want specific properties to show up?''
#* You can trivially use CSS to hide (or otherwise alter the display) of certain properties. E.g. if you want to hide the "location" from all your VEVENTs you would write a rule like this: <code> .vevent .location { display:none } </code>. This won't, however, keep the properties from being read in the HTML source.
# ''If we use <abbr> title for the ISODate, how do we specify a different tooltip?''
#* For reasons of metadata transparency and visibility, it is recommended that you DO NOT specify a different tooltip. However, if in your particular content or application you must, you can do so with a nested span e.g. <code> <abbr title="20050221"><span title="tooltip text">Feb. 21st</span></abbr></code>
# ''Would the use of <acronym> for DTSTART be just as good as <abbr>?''
#* It could be, but there is no need. The <abbr> element is also preferred as it is better defined. The <acronym> element, and in particular, the term "acronym" means different things to different people, and thus we are not using it in [[hcalendar|hCalendar]].
# ''What happens if a browser doesn't support <abbr>?''
#* Then the human readable contents inside the element are displayed, which is the desirable behavior.
# ''How is [[hcalendar|hCalendar]] different from xCalendar, i.e. [http://www.ietf.org/internet-drafts/draft-hare-xcalendar-03.txt draft iCalendar XML guidelines submitted to the IETF]?''
#* hCalendar and xCalendar are actually very similar in that they are both based on iCalendar standard, RFC2445. However, xCalendar is a way of representing iCalendar files using non-standard XML element names and attributes. This is inadequate and unwieldly for serving on web pages. xCalendar is still a separate, encapsulated document in the context of the web, that requires yet another namespace. Nobody would ever look at an xCalendar XML file in the context of their ordinary browsing, unless it's XSLTed into something else, e.g. hCalendar. On the other hand, [[hcalendar|hCalendar]] is easily embeddable into normal XHTML web pages, easily stylable with CSS, cleanly separates human presentable date information vs. machine parsable ISO-8601 dates, etc. With hCalendar, calendar and events content appears both to the human user *and* to hCalendar-aware machine implementations, parsers, indexers, etc., on *today's* web.
# ''Can you provide more precise location data for an hCalendar event such at latitude and longitude?''
#* Yes, it is possible, by overlaying an [[hcard|hCard]] with the location markup, e.g. using your lat long example (taking the values as given, someone feel free to fix these to be the real values). The code example(s) are presumed to be inside an element with a class name of "vevent". See the [[hcalendar-location-hcard-example]] page for details. For more discussions of location data, geographic data, and research into current and potential future formats, see the [[location-formats|location formats]] page.
# ''When transforming an hcalendar to an ics file, do I have to convert the time to UTC?''
#* Yes. The iCalendar format does not permit the time to be published with an offset. hCalendars can be published with offsets, because this promotes accuracy, as it can more easily be verified (timezone math is hard), but tools which transform hCalendar to iCalendar must transformat times to UTC.
# ''How are recurring events represented?''
#* If you take a look at [http://microformats.org/wiki/hcalendar-examples#Example_3 Example 3], there is a proposed means using an <em>RRULE</em> property along with a <em>freq</em> sub-property. It's a start - more brainstorming at [http://microformats.org/wiki/hcalendar-brainstorming#Recurring_Events hcalendar-brainstorming].
# ''How does one markup just the year as opposed to an entire date? e.g. to represent age, or discussing "the past year" ?

hcalendar-faq

2006-01-17T02:10:49Z

B.K. DeLong: /* Q&A */

= hCalendar FAQ =

This page is for documenting Q&A about [[hcalendar|hCalendar]]. If you have a new question to ask, Please consider first asking your question on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] list.

== Q&A ==

# ''How do I use a class inside <span class="vcalendar"> when I don't want the element I use it on to be a property of the calendar?''
#*Use a class name that isn't a defined iCalendar property name.
# ''What happens if the class is used both inside and outside <span class="vcalendar">?''
#* That works fine.
# ''What do I do if I want to add styling to a group of calendar events, especially if the calendar contains dynamic content? ''
#* You can write style rules that incorporate both the context of said group (say it is in an ordered list with class name "group" for example) and the events, e.g.:<code>ol.group .vevent { /* insert common styling here */ } </code>
# ''What do you do if you don't want the calendar or card to be displayed?''
#* If you don't want the calendar or card to be displayed, why are you publishing it on the Web?
# ''What if you don't want specific properties to show up?''
#* You can trivially use CSS to hide (or otherwise alter the display) of certain properties. E.g. if you want to hide the "location" from all your VEVENTs you would write a rule like this: <code> .vevent .location { display:none } </code>. This won't, however, keep the properties from being read in the HTML source.
# ''If we use <abbr> title for the ISODate, how do we specify a different tooltip?''
#* For reasons of metadata transparency and visibility, it is recommended that you DO NOT specify a different tooltip. However, if in your particular content or application you must, you can do so with a nested span e.g. <code> <abbr title="20050221"><span title="tooltip text">Feb. 21st</span></abbr></code>
# ''Would the use of <acronym> for DTSTART be just as good as <abbr>?''
#* It could be, but there is no need. The <abbr> element is also preferred as it is better defined. The <acronym> element, and in particular, the term "acronym" means different things to different people, and thus we are not using it in [[hcalendar|hCalendar]].
# ''What happens if a browser doesn't support <abbr>?''
#* Then the human readable contents inside the element are displayed, which is the desirable behavior.
# ''How is [[hcalendar|hCalendar]] different from xCalendar, i.e. [http://www.ietf.org/internet-drafts/draft-hare-xcalendar-03.txt draft iCalendar XML guidelines submitted to the IETF]?''
#* hCalendar and xCalendar are actually very similar in that they are both based on iCalendar standard, RFC2445. However, xCalendar is a way of representing iCalendar files using non-standard XML element names and attributes. This is inadequate and unwieldly for serving on web pages. xCalendar is still a separate, encapsulated document in the context of the web, that requires yet another namespace. Nobody would ever look at an xCalendar XML file in the context of their ordinary browsing, unless it's XSLTed into something else, e.g. hCalendar. On the other hand, [[hcalendar|hCalendar]] is easily embeddable into normal XHTML web pages, easily stylable with CSS, cleanly separates human presentable date information vs. machine parsable ISO-8601 dates, etc. With hCalendar, calendar and events content appears both to the human user *and* to hCalendar-aware machine implementations, parsers, indexers, etc., on *today's* web.
# ''Can you provide more precise location data for an hCalendar event such at latitude and longitude?''
#* Yes, it is possible, by overlaying an [[hcard|hCard]] with the location markup, e.g. using your lat long example (taking the values as given, someone feel free to fix these to be the real values). The code example(s) are presumed to be inside an element with a class name of "vevent". See the [[hcalendar-location-hcard-example]] page for details. For more discussions of location data, geographic data, and research into current and potential future formats, see the [[location-formats|location formats]] page.
# ''When transforming an hcalendar to an ics file, do I have to convert the time to UTC?''
#* Yes. The iCalendar format does not permit the time to be published with an offset. hCalendars can be published with offsets, because this promotes accuracy, as it can more easily be verified (timezone math is hard), but tools which transform hCalendar to iCalendar must transformat times to UTC.
# ''How are recurring events represented?''
#* If you take a look at [http://microformats.org/wiki/hcalendar-examples#Example_3 Example 3], there is a proposed means using an <em>RRULE</em> property along with a <em>freq</em> sub-property. It's a start.
# ''How does one markup just the year as opposed to an entire date? e.g. to represent age, or discussing "the past year" ?

User:B.K. DeLong

2006-01-17T01:56:54Z

B.K. DeLong: /* User: B.K. DeLong */

<h1>B.K. DeLong</h1>

bkdelong is B.K. DeLong, Head Research Analyst for HALO Worldwide - http://www.haloworldwide.com. Web: http://www.brain-stream.com. Email: bkdelong@pobox.com

hcalendar-faq

2006-01-17T01:45:44Z

B.K. DeLong: /* Q&A */

= hCalendar FAQ =

This page is for documenting Q&A about [[hcalendar|hCalendar]]. If you have a new question to ask, Please consider first asking your question on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] list.

== Q&A ==

# ''How do I use a class inside <span class="vcalendar"> when I don't want the element I use it on to be a property of the calendar?''
#*Use a class name that isn't a defined iCalendar property name.
# ''What happens if the class is used both inside and outside <span class="vcalendar">?''
#* That works fine.
# ''What do I do if I want to add styling to a group of calendar events, especially if the calendar contains dynamic content? ''
#* You can write style rules that incorporate both the context of said group (say it is in an ordered list with class name "group" for example) and the events, e.g.:<code>ol.group .vevent { /* insert common styling here */ } </code>
# ''What do you do if you don't want the calendar or card to be displayed?''
#* If you don't want the calendar or card to be displayed, why are you publishing it on the Web?
# ''What if you don't want specific properties to show up?''
#* You can trivially use CSS to hide (or otherwise alter the display) of certain properties. E.g. if you want to hide the "location" from all your VEVENTs you would write a rule like this: <code> .vevent .location { display:none } </code>. This won't, however, keep the properties from being read in the HTML source.
# ''If we use <abbr> title for the ISODate, how do we specify a different tooltip?''
#* For reasons of metadata transparency and visibility, it is recommended that you DO NOT specify a different tooltip. However, if in your particular content or application you must, you can do so with a nested span e.g. <code> <abbr title="20050221"><span title="tooltip text">Feb. 21st</span></abbr></code>
# ''Would the use of <acronym> for DTSTART be just as good as <abbr>?''
#* It could be, but there is no need. The <abbr> element is also preferred as it is better defined. The <acronym> element, and in particular, the term "acronym" means different things to different people, and thus we are not using it in [[hcalendar|hCalendar]].
# ''What happens if a browser doesn't support <abbr>?''
#* Then the human readable contents inside the element are displayed, which is the desirable behavior.
# ''How is [[hcalendar|hCalendar]] different from xCalendar, i.e. [http://www.ietf.org/internet-drafts/draft-hare-xcalendar-03.txt draft iCalendar XML guidelines submitted to the IETF]?''
#* hCalendar and xCalendar are actually very similar in that they are both based on iCalendar standard, RFC2445. However, xCalendar is a way of representing iCalendar files using non-standard XML element names and attributes. This is inadequate and unwieldly for serving on web pages. xCalendar is still a separate, encapsulated document in the context of the web, that requires yet another namespace. Nobody would ever look at an xCalendar XML file in the context of their ordinary browsing, unless it's XSLTed into something else, e.g. hCalendar. On the other hand, [[hcalendar|hCalendar]] is easily embeddable into normal XHTML web pages, easily stylable with CSS, cleanly separates human presentable date information vs. machine parsable ISO-8601 dates, etc. With hCalendar, calendar and events content appears both to the human user *and* to hCalendar-aware machine implementations, parsers, indexers, etc., on *today's* web.
# ''Can you provide more precise location data for an hCalendar event such at latitude and longitude?''
#* Yes, it is possible, by overlaying an [[hcard|hCard]] with the location markup, e.g. using your lat long example (taking the values as given, someone feel free to fix these to be the real values). The code example(s) are presumed to be inside an element with a class name of "vevent". See the [[hcalendar-location-hcard-example]] page for details. For more discussions of location data, geographic data, and research into current and potential future formats, see the [[location-formats|location formats]] page.
# ''When transforming an hcalendar to an ics file, do I have to convert the time to UTC?''
#* Yes. The iCalendar format does not permit the time to be published with an offset. hCalendars can be published with offsets, because this promotes accuracy, as it can more easily be verified (timezone math is hard), but tools which transform hCalendar to iCalendar must transformat times to UTC.
# ''How are recurring events represented?''
# ''How does one markup just the year as opposed to an entire date? e.g. to represent age, or discussing "the past year" ?

hcalendar-faq

2006-01-17T01:45:08Z

B.K. DeLong: /* Q&A */

= hCalendar FAQ =

This page is for documenting Q&A about [[hcalendar|hCalendar]]. If you have a new question to ask, Please consider first asking your question on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss] list.

== Q&A ==

# ''How do I use a class inside <span class="vcalendar"> when I don't want the element I use it on to be a property of the calendar?''
#*Use a class name that isn't a defined iCalendar property name.
# ''What happens if the class is used both inside and outside <span class="vcalendar">?''
#* That works fine.
# ''What do I do if I want to add styling to a group of calendar events, especially if the calendar contains dynamic content? ''
#* You can write style rules that incorporate both the context of said group (say it is in an ordered list with class name "group" for example) and the events, e.g.:<code>ol.group .vevent { /* insert common styling here */ } </code>
# ''What do you do if you don't want the calendar or card to be displayed?''
#* If you don't want the calendar or card to be displayed, why are you publishing it on the Web?
# ''What if you don't want specific properties to show up?''
#* You can trivially use CSS to hide (or otherwise alter the display) of certain properties. E.g. if you want to hide the "location" from all your VEVENTs you would write a rule like this: <code> .vevent .location { display:none } </code>. This won't, however, keep the properties from being read in the HTML source.
# ''If we use <abbr> title for the ISODate, how do we specify a different tooltip?''
#* For reasons of metadata transparency and visibility, it is recommended that you DO NOT specify a different tooltip. However, if in your particular content or application you must, you can do so with a nested span e.g. <code> <abbr title="20050221"><span title="tooltip text">Feb. 21st</span></abbr></code>
# ''Would the use of <acronym> for DTSTART be just as good as <abbr>?''
#* It could be, but there is no need. The <abbr> element is also preferred as it is better defined. The <acronym> element, and in particular, the term "acronym" means different things to different people, and thus we are not using it in [[hcalendar|hCalendar]].
# ''What happens if a browser doesn't support <abbr>?''
#* Then the human readable contents inside the element are displayed, which is the desirable behavior.
# ''How is [[hcalendar|hCalendar]] different from xCalendar, i.e. [http://www.ietf.org/internet-drafts/draft-hare-xcalendar-03.txt draft iCalendar XML guidelines submitted to the IETF]?''
#* hCalendar and xCalendar are actually very similar in that they are both based on iCalendar standard, RFC2445. However, xCalendar is a way of representing iCalendar files using non-standard XML element names and attributes. This is inadequate and unwieldly for serving on web pages. xCalendar is still a separate, encapsulated document in the context of the web, that requires yet another namespace. Nobody would ever look at an xCalendar XML file in the context of their ordinary browsing, unless it's XSLTed into something else, e.g. hCalendar. On the other hand, [[hcalendar|hCalendar]] is easily embeddable into normal XHTML web pages, easily stylable with CSS, cleanly separates human presentable date information vs. machine parsable ISO-8601 dates, etc. With hCalendar, calendar and events content appears both to the human user *and* to hCalendar-aware machine implementations, parsers, indexers, etc., on *today's* web.
# ''Can you provide more precise location data for an hCalendar event such at latitude and longitude?''
#* Yes, it is possible, by overlaying an [[hcard|hCard]] with the location markup, e.g. using your lat long example (taking the values as given, someone feel free to fix these to be the real values). The code example(s) are presumed to be inside an element with a class name of "vevent". See the [[hcalendar-location-hcard-example]] page for details. For more discussions of location data, geographic data, and research into current and potential future formats, see the [[location-formats|location formats]] page.
# ''When transforming an hcalendar to an ics file, do I have to convert the time to UTC?''
#* Yes. The iCalendar format does not permit the time to be published with an offset. hCalendars can be published with offsets, because this promotes accuracy, as it can more easily be verified (timezone math is hard), but tools which transform hCalendar to iCalendar must transformat times to UTC.
# ''How are recurring events represented?''

# ''How does one markup just the year as opposed to an entire date? e.g. to represent age, or discussing "the past year" ?

hcalendar-faq

2006-01-17T01:42:04Z

B.K. DeLong: /* Q&A */

adr-examples

2006-01-17T01:26:24Z

B.K. DeLong:

<h1>More ADR examples</h1>

<h2>LOCALITY and other ADR fragments</h2>

Using the <strong>adr</strong> microformat should not just be limited to full datasets of information.
In some cases, people reference regions or localities sans any additional information.

By marking these cases up, use of microformats, (particularly <strong>adr</strong>), will skyrocket.

For instance - with the below post, we reference a city but nothing else.
Because I marked up the city name with the <em>locality</em> property, I added the <em>adr</em>
property to the block-level parent element that contains the relevant <em>locality</em> property.

<h3>Example:</h3>

<pre><nowiki>
<p class="adr">Unbelievable. Yesterday's high temperature in <span
class="locality">Salem</span> it was 57 degrees out. </p>
</nowiki></pre>

<h2>Use of the <code><abbr></code> element</h2>

Semantically-correct <strong>adr</strong> markup would use the <code><abbr></code> element while
using the <em>region</em>, <em>country</em> and perhaps other <strong>adr</strong> properties.

<h3>Example:</h3>

<pre><nowiki>
<abbr class="region" title="California">CA</a>,
<abbr class="country" title="United States">US</abbr>
</nowiki></pre>

For the full country names in the <code>title</code> attribute of the <code><abbr></code> element when using the <em>country</em> property,
use [http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html ISO 3166-1].

adr-examples

2006-01-17T01:25:02Z

B.K. DeLong:

<h1>More ADR examples</h1>

<h2>LOCALITY and other ADR fragments</h2>

Using the <strong>adr</strong> microformat should not just be limited to full datasets of information.
In some cases, people reference regions or localities sans any additional information.

By marking these cases up, use of microformats, (particularly <strong>adr</strong>), will skyrocket.

For instance - with the below post, we reference a city but nothing else.
Because I marked up the city name with the <em>locality</em> property, I added the <em>adr</em>
property to the block-level parent element that contains the relevant <em>locality</em> property.

<h3>Example:</h3>

<pre><nowiki>
<p class="adr">Unbelievable. Yesterday's high temperature in <span
class="locality">Salem</span> it was 57 degrees out. </p>
</nowiki></pre>

<h2>Use of the <code><abbr></code> element</h2>

Semantically-correct <strong>adr</strong> markup would use the <code><abbr></code> element while
using the <em>region</em>, <em>country</em> and perhaps other <strong>adr</strong> properties.

<h3>Example:</h3>

<pre><nowiki>
<abbr class="region" title="California">CA</a>,
<abbr class="country" title="United States">US</abbr>
</nowiki></pre>

For the full country names in the <code>title</code> attribute of the <code><abbr></code> element,
use [http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html ISO 3166-1].

adr-examples

2006-01-17T01:05:14Z

B.K. DeLong:

<h1>More ADR examples</h1>

<h2>LOCALITY and other ADR fragments</h2>

Using the <strong>adr</strong> microformat should not just be limited to full datasets of information.
In some cases, people reference regions or localities sans any additional information.

By marking these cases up, use of microformats, (particularly <strong>adr</strong>), will skyrocket.

For instance - with the below post, we reference a city but nothing else.
Because I marked up the city name with the "locality" property, I added the "adr"
class to the block-level parent element that contains the relevant locality name.

<h3>Example:</h3>

<pre><nowiki>
<p class="adr">Unbelievable. Yesterday's high temperature in <span
class="locality">Salem</span> it was 57 degrees out. </p>
</nowiki></pre>

<h2>Use of the <code><abbr></code> element</h2>

Semantically-correct <strong>adr</strong> markup would use the <code><abbr></code> HTML element while
using the region, country and perhaps other <strong>adr</strong> properties.

<h3>Example:</h3>

<pre><nowiki>
<abbr class="region" title="California">CA</a>,
<abbr class="country" title="United States">US</abbr>
</nowiki></pre>

For the full country names in the title attribute of the <code><abbr></code> element,
use [http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html ISO 3166-1].

adr

2006-01-17T01:03:09Z

B.K. DeLong: /* More Examples */

= adr =

'''adr''' (working name, pronounced "adder") is a simple format for marking up address information, suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. '''adr''' is a 1:1 representation of the ''adr'' property in the vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) in XHTML, one of several open [[microformats|microformat]] standards.
__TOC__

== Draft Specification ==
=== Editor/Author ===
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]

=== Copyright ===
{{MicroFormatCopyrightStatement2005}}

=== Patents ===
{{MicroFormatPatentStatement}}

=== Inspiration and Acknowledgments ===
Thanks to everyone who participated in the [[geo-bof-2005-06-30|Geo Microformat BOF at O'Reilly's Where 2.0 conference]], and in particular to [http://radar.oreilly.com/nat/ Nat Torkington] and Vee McMillen of [http://oreilly.com O'Reilly] for [http://conferences.oreillynet.com/cs/where2005/view/e_sess/7476 arranging and hosting the BOF].

== Introduction and Background ==
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]), has been broadly and interoperably implemented (e.g. Apple's Address Book application). The [[hcard|hCard]] microformat has similarly received significant adoption, from numerous sites publishing the format, to hCard to vCard proxies, to clientside javascript parsers.

At the [http://conferences.oreillynet.com/where/ Where 2.0 conference] in June 2005, there was widespread recognition that the community needed a way to simply and easily publish visible, extractable, address information on the Web, given how often bloggers, and numerous other sites publish address information. The [[geo-bof-2005-06-30|geo microformat BOF]] discussed this very topic, and concluded with a consensus decision to just try using ''adr'' from vCard/hCard.

This specification introduces the '''adr''' microformat, which is a 1:1 representation of the aforementioned ''adr'' property from the vCard standard, by simply reusing the ''adr'' property and sub-properties as-is from the [[hcard|hCard]] microformat.

Publishers can both embed '''adr''' addresses directly in their web pages and feeds, as well as markup existing addresses in the context of the rest of the information in their web pages and feeds.

If the publisher knows and is publishing the ''name'' of the location in addition to its address, then the publisher MUST use [[hcard|hCard]] instead of just '''adr''' to publish the name and address of the location.

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== Singular Properties ===

Note that all the properties in '''adr''' are singular properties, and thus the first descendant element with that class should take effect, any others being ignored.

=== Human vs. Machine readable ===

If an <code><abbr></code> element is used for a property, then the <code>title</code> attribute of the <code><abbr></code> element is the value of the property, instead of the contents of the element, which instead provide a human presentable version of the value.

Similarly, if an <code><img></code> element is used for one or more properties, it must be treated as follows:
# For the <code>PHOTO</code> property and any other property that takes a <abbr title="Uniform Resource Locator">URL</abbr> as its value, the <code>src</code> attribute provides the property value.
# For other properties, the <code><img></code> element's <code>alt</code> attribute is the value of the property.

=== Value excerpting ===

Sometimes only part of an element which is the equivalent for a property should be used for the value of the property. For this purpose, the special class name <code>value</code> is used to excerpt out the subset of the element that is the value of the property. See [[hcard|hCard]] for details on this.

=== Root Class Name ===

The root class name for an '''adr''' address is <code>adr</code>.

=== Property List ===

This is the list of properties in '''adr''', taken from [[hcard|hCard]]:

* <code>post-office-box</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>

The <code>type</code> sub-property is omitted because without the context of a type of address for ''whom'', it doesn't make much sense.

=== XMDP Profile ===

See [[hcard-profile]] for the [http://gmpg.org/xmdp XMDP] profile of hCard which contains the above complete list of properties, with references to their RFC 2426 definitions.

=== Parsing Details ===
See [[hcard-parsing|hCard parsing]], with the only difference being that "adr" is the root class name, rather than "vcard".

== Examples ==
This section is informative.

=== Sample adr ===

Here is a sample adr:

<pre><nowiki>
<div class="adr">
<div class="street-address">665 3rd St.</div>
<div class="extended-address">Suite 207</div>
<span class="locality">San Francisco</span>,
<span class="region">CA</span>
<span class="postal-code">94107</span>
<div class="country-name">U.S.A.</div>
</div>
</nowiki></pre>

This adr might be displayed as:

<pre>665 3rd St.
Suite 207
San Francisco, CA 94107
U.S.A.</pre>

=== More Examples ===

See [http://microformats.org/wiki/hcard-examples#3.2.1_ADR_Type_Definition hCard example ADR] for more examples.

See [http://microformats.org/wiki/adr-examples adr examples] for additional uses of ADR.

== Examples in the wild ==
This section is '''informative'''.

The following sites have published adrs, outside their normal context of hCards, and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc., in addition to [[hcard|hCard]] examples in the wild. If you find adrs outside of hCards anywhere else, feel free to add them to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* ...
* ...

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse adrs outside the context of hCards. If you have an adr implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* The [http://tantek.com/microformats/hcard-creator.html hCard creator], though it creates complete hCards, can also be used simply to create adrs by filling out the address portion and simply copy and pasting the <div class="adr"> element and its contents.

== References ==
=== Normative References ===
* [[hcard|hCard]]

=== Informative References ===
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426] ([http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426])
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]

=== Similar Work ===
* [[geo]]
* [[hcalendar|hCalendar]]
* [[XOXO]]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hCard, check the [[hcard-faq|hCard FAQ]] first, and if you don't find answers, add your questions! (Odds are that any '''adr''' question will apply to [[hCard]] as well).
* See also [http://microformats.org/discuss/ for other methods of feedback].

=== Issues ===
* Please add any issues with the specification to the separate [[hcard-issues|hCard issues]] document. Ditto.

adr-examples

2006-01-17T01:01:00Z

B.K. DeLong:

<h1>More ADR examples</h1>

<h2>LOCALITY and other ADR fragments</h2>

Using the ADR microformat should not just be limited to full datasets of information.
In some cases, people reference regions or localities sans any additional information.

By marking these cases up, use of microformats, (particularly ADR), will skyrocket.

For instance - with the below post, we reference a city but nothing else.
Because I marked up the city name with the "locality" property, I added the "adr"
class to the block-level parent element that contains the relevant locality name.

<h3>Example:</h3>

<pre><nowiki>
<p class="adr">Unbelievable. Yesterday's high temperature in <span
class="locality">Salem</span> it was 57 degrees out. </p>
</nowiki></pre>

<h2>Use of the <code><abbr></code> element</h2>

Semantically-correct ADR markup would use the <code><abbr></code> HTML element while
using the region, country and perhaps other ADR properties.

<h3>Example:</h3>

<pre><nowiki>
<abbr class="region" title="California">CA</a>,
<abbr class="country" title="United States">US</abbr>
</nowiki></pre>

For the full country names in the title attribute of the <code><abbr></code> element,
use [http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html ISO 3166-1].

adr-examples

2006-01-17T01:00:13Z

B.K. DeLong:

<h1>More ADR examples</h1>

<h2>LOCALITY and other ADR fragments</h2>

Using the ADR microformat should not just be limited to full datasets of information.
In some cases, people reference regions or localities sans any additional information.

By marking these cases up, use of microformats, (particularly ADR), will skyrocket.

For instance - with the below post, we reference a city but nothing else.
Because I marked up the city name with the "locality" property, I added the "adr"
class to the block-level parent element that contains the relevant locality name.

<h3>Example:</h3>

<pre><nowiki>
<p class="adr">Unbelievable. Yesterday's high temperature in <span
class="locality">Salem</span> it was 57 degrees out. </p>
</nowiki></pre>

<h2>Use of the <code>>abbr<</code></h2>

Semantically-correct ADR markup would use the <code><abbr></code> HTML element while
using the region, country and perhaps other ADR properties.

<h3>Example:</h3>

<pre><nowiki>
<abbr class="region" title="California">CA</a>,
<abbr class="country" title="United States">US</abbr>
</nowiki></pre>

For the full country names in the title attribute of the <code><abbr></code> element,
use [http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html ISO 3166-1].

adr-examples

2006-01-17T00:45:40Z

B.K. DeLong: /* More examples of the ADR microformat */

== More ADR examples ==

Using the ADR microformat should not just be limited to full datasets of information.
In some cases, people reference regions or localities sans any additional information.

By marking these cases up, use of microformats, (particularly ADR), will skyrocket.

For instance, with the below post, I reference a city but nothing else.
Because I marked up the city name with the locality property, I added the "adr"
class to the block-level parent element that contains the relevant locality name.

Example:

<pre><nowiki>
<p class="adr">Unbelievable. Yesterday's high temperature in <span
class="locality">Salem</span> it was 57 degrees out. </p>
</nowiki></pre>

Semantically-correct ADR markup would use the ABBR HTML element while
using the region, country and perhaps other ADR properties.

Example:

<pre><nowiki>
<abbr class="region" title="California">CA</a>,
<abbr class="country" title="United States">US</abbr>
</nowiki></pre>

For the full country names in the title attribute of the ABBR element,
use [http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html ISO 3166-1].

adr

2006-01-17T00:24:28Z

B.K. DeLong: /* More Examples */

= adr =

'''adr''' (working name, pronounced "adder") is a simple format for marking up address information, suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. '''adr''' is a 1:1 representation of the ''adr'' property in the vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) in XHTML, one of several open [[microformats|microformat]] standards.
__TOC__

== Draft Specification ==
=== Editor/Author ===
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]

=== Copyright ===
{{MicroFormatCopyrightStatement2005}}

=== Patents ===
{{MicroFormatPatentStatement}}

=== Inspiration and Acknowledgments ===
Thanks to everyone who participated in the [[geo-bof-2005-06-30|Geo Microformat BOF at O'Reilly's Where 2.0 conference]], and in particular to [http://radar.oreilly.com/nat/ Nat Torkington] and Vee McMillen of [http://oreilly.com O'Reilly] for [http://conferences.oreillynet.com/cs/where2005/view/e_sess/7476 arranging and hosting the BOF].

== Introduction and Background ==
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]), has been broadly and interoperably implemented (e.g. Apple's Address Book application). The [[hcard|hCard]] microformat has similarly received significant adoption, from numerous sites publishing the format, to hCard to vCard proxies, to clientside javascript parsers.

At the [http://conferences.oreillynet.com/where/ Where 2.0 conference] in June 2005, there was widespread recognition that the community needed a way to simply and easily publish visible, extractable, address information on the Web, given how often bloggers, and numerous other sites publish address information. The [[geo-bof-2005-06-30|geo microformat BOF]] discussed this very topic, and concluded with a consensus decision to just try using ''adr'' from vCard/hCard.

This specification introduces the '''adr''' microformat, which is a 1:1 representation of the aforementioned ''adr'' property from the vCard standard, by simply reusing the ''adr'' property and sub-properties as-is from the [[hcard|hCard]] microformat.

Publishers can both embed '''adr''' addresses directly in their web pages and feeds, as well as markup existing addresses in the context of the rest of the information in their web pages and feeds.

If the publisher knows and is publishing the ''name'' of the location in addition to its address, then the publisher MUST use [[hcard|hCard]] instead of just '''adr''' to publish the name and address of the location.

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== Singular Properties ===

Note that all the properties in '''adr''' are singular properties, and thus the first descendant element with that class should take effect, any others being ignored.

=== Human vs. Machine readable ===

If an <code><abbr></code> element is used for a property, then the <code>title</code> attribute of the <code><abbr></code> element is the value of the property, instead of the contents of the element, which instead provide a human presentable version of the value.

Similarly, if an <code><img></code> element is used for one or more properties, it must be treated as follows:
# For the <code>PHOTO</code> property and any other property that takes a <abbr title="Uniform Resource Locator">URL</abbr> as its value, the <code>src</code> attribute provides the property value.
# For other properties, the <code><img></code> element's <code>alt</code> attribute is the value of the property.

=== Value excerpting ===

Sometimes only part of an element which is the equivalent for a property should be used for the value of the property. For this purpose, the special class name <code>value</code> is used to excerpt out the subset of the element that is the value of the property. See [[hcard|hCard]] for details on this.

=== Root Class Name ===

The root class name for an '''adr''' address is <code>adr</code>.

=== Property List ===

This is the list of properties in '''adr''', taken from [[hcard|hCard]]:

* <code>post-office-box</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>

The <code>type</code> sub-property is omitted because without the context of a type of address for ''whom'', it doesn't make much sense.

=== XMDP Profile ===

See [[hcard-profile]] for the [http://gmpg.org/xmdp XMDP] profile of hCard which contains the above complete list of properties, with references to their RFC 2426 definitions.

=== Parsing Details ===
See [[hcard-parsing|hCard parsing]], with the only difference being that "adr" is the root class name, rather than "vcard".

== Examples ==
This section is informative.

=== Sample adr ===

Here is a sample adr:

<pre><nowiki>
<div class="adr">
<div class="street-address">665 3rd St.</div>
<div class="extended-address">Suite 207</div>
<span class="locality">San Francisco</span>,
<span class="region">CA</span>
<span class="postal-code">94107</span>
<div class="country-name">U.S.A.</div>
</div>
</nowiki></pre>

This adr might be displayed as:

<pre>665 3rd St.
Suite 207
San Francisco, CA 94107
U.S.A.</pre>

=== More Examples ===

See [http://microformats.org/wiki/hcard-examples#3.2.1_ADR_Type_Definition hCard example ADR] for more examples.

See adr-examples

== Examples in the wild ==
This section is '''informative'''.

The following sites have published adrs, outside their normal context of hCards, and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc., in addition to [[hcard|hCard]] examples in the wild. If you find adrs outside of hCards anywhere else, feel free to add them to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* ...
* ...

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse adrs outside the context of hCards. If you have an adr implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* The [http://tantek.com/microformats/hcard-creator.html hCard creator], though it creates complete hCards, can also be used simply to create adrs by filling out the address portion and simply copy and pasting the <div class="adr"> element and its contents.

== References ==
=== Normative References ===
* [[hcard|hCard]]

=== Informative References ===
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426] ([http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426])
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]

=== Similar Work ===
* [[geo]]
* [[hcalendar|hCalendar]]
* [[XOXO]]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hCard, check the [[hcard-faq|hCard FAQ]] first, and if you don't find answers, add your questions! (Odds are that any '''adr''' question will apply to [[hCard]] as well).
* See also [http://microformats.org/discuss/ for other methods of feedback].

=== Issues ===
* Please add any issues with the specification to the separate [[hcard-issues|hCard issues]] document. Ditto.