Microformats Wiki - User contributions [en]

hcard-issues

2009-02-02T11:58:29Z

XavierBadosa: Edited to improve source presentation in the 2009 wiki.

<entry-title> hCard issues </entry-title>
{{TOC-right}}
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

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

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See other [[issues]] also.

== closed issues ==
See: [[hcard-issues-resolved]]

== resolved issues ==
See: [[hcard-issues-resolved]]

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2006 ===

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#*** See also the proposal to use this pattern in [[representative-hcard]]
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. <strong>abbr-design-pattern</strong> would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>
<span class="tel" xml:lang="es">
<abbr class="type" title="home">Casa</abbr> (<span class="type">pref</span>erido):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]
*# To avoid [[i18n]] issues, microformats should keep its hands off content (this also affects [[hReview]]). [[abbr-design-pattern]] doesn't seem the right solution here. Someone from France suggested elsewhere to use the class value '''telwork''', etc. but again it's a dubious solution (remember that a ''tel'' can have a type of ''voice'' and ''work'' '''at the same time'''). I suggest considering:

<pre><nowiki>
<span class="tel home pref" xml:lang="es">
Casa (preferido):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>

It could be argued that somehow this solution violates the microformats [[principles|principle of visible data]]. Maybe it does, but [[i18n]] should come first because otherwise microformats violates the first rule: '''solve a specific problem''' (and the last: "enable and encourage decentralized and distributed development, content, services: explicitly encourage the original 'spirit of the Web'"). -[[User:XavierBadosa|Xavier Badosa]]

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-19</span> raised by <span class="fn">[[User::ChristinaHope|Christina Hope]]</span></span>
<div class="description">
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-31</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-04-19</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the [[abbr-design-pattern]] (or its successor) if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>

===2008===

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-01</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]</span>
<div class="description">
*# The "n" optimization rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
<span class="fn locality">New York</span></nowiki></code>; <code><nowiki><span class="fn label">Asia</span></nowiki></code>, since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary"><span class="dtstart">2008-01-09</span> <span id="tel-type-lang">2008- moved from vcard-suggestions</span></span>
<div class="description">
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : <span class="telwork">0321596224</span></nowiki> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-02</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>n</code>" optimization rules (<code>nickname</code>, <code>fn</code>) should not apply where the <code>fn</code> is also the <code>role</code> or <code>title</code>: e.g <code><nowiki>
<span class="fn role">Webmaster</span></nowiki></code>; <code><nowiki><span class="fn title">Duty Manager</span></nowiki></code>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-06</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# It seems to me that FN has been reused beyond its original vCard scope of person names, to cover any name. This led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>fn</code>" optimization rule should not apply where the full <code>fn</code> is also the <code>nickname</code>: e.g <code><nowiki><span class="fn nickname">Plastic Bertram</span></nowiki></code>, since a given-name+family-name pair is not usually a nickname. (But how to deal with pseudonyms such as "Maurice Micklewhite (known professionally as Michael Caine)"?)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# Is "n" optional or mandatory? The spec says yes (with exceptions) the cheat-sheet says no. Parsers and common practice seem to indicate not.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# "<code>nickname</code>" and "<code>fn</code>" optimization does not work for some or all names in Asian languages. See [http://zh.wikipedia.org/wiki/%E6%B9%AF%E5%A7%86%C2%B7%E5%85%8B%E9%AD%AF%E6%96%AF Tom Cruise on Chinese Wikipedia], where the <code>fn</code> and nickname are the same. This could be partly remedied by not applying such optimization when the page's (or element's) language is set to one of a set of affected languages (may also apply to other languages, such as Greek). '''Cpmment from people fluent in such languages would be welcome.'''
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-08</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# The required FN makes it difficult to use hCard in HTML Tables without resorting to hiding information (as in http://www.bo.ingv.it/contents/INGV-Bologna/Staff.html) or using the [[include-pattern]]. Perhaps FN should not be required if some N are present. Originally raised in [http://rbach.priv.at/Microformats/IRC/2008-02-08#T181749]
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-06-01</span> raised by <span class="fn">[[User:Kornel|Kornel]]</span></span>
<div class="description">
*# I need clarification how should "more semantic equivalents" be interpreted inside values (when they don't have relevant class name, but are inside another parsed element)
*#* <code><nowiki><span class="email"><a href="mailto:href">nodetext</a></span></nowiki></code> – is it "href", "nodetext" or an error? What if there are multiple links inside?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><abbr title="title">nodetext</abbr></span></nowiki></code> – is it "title" or "nodetext"?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><img alt="alt">nodetext</span></nowiki></code> – is it "alt", "nodetext" or both?
*#** A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><abbr title="title"><span class="value">nodetext</span></abbr></span></nowiki></code> – "title", "nodetext" or both?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="url"><img src="src" alt="alt">nodetext</span></nowiki></code> – "src", "alt", "nodetext" or "altnodetext"?
*#** A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><div class="category"><a rel="tag bookmark" href="href">nodetext</a></div></code> – is it a tag? What if there are multiple links inside?
*#** Not sure how other parsers treat this, but Cognition will create two categories based on this. One because of the [rel-tag], based on the final component of the URL; and the second category because of class=category, based on the node text. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Does <code>agent</code> property has to be a hCard?
*#* Is <code><span class="agent">Joe Sixpack</span></code> allowed?
*#** Yes. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* Is <code><span class="agent"><div class="vcard">…</div></span></code> ok?
*#** [http://buzzword.org.uk/cognition/ Cognition] doesn't specifically support this format - they'll be parsed as two separate hCards. The "outer" hCard will have an "agent" property containing the unparsed node text for the inner hCard, as if you'd used a plain string for the agent as per the previous example. If you want to provide an hCard for the agent, and have it parsed as such, Cognition requires that you use: <code><div class="agent vcard">…</div></code>. (There is also the separate issue that it is illegal in HTML to nest a DIV within a SPAN.) [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* What about <code><a class="agent" href="card.vcf">…</a></code>?
*#** I don't think many hCard parsers also parse vCard. If they support vCard it's probably as an output format rather than input. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is value of <code><abbr></code> without <code>title</code> empty or should it be interpreted like <code><span></code>?
*#* I think consensus is that the node text should be used. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Does <code><acronym></code> work like <code><abbr></code>?
*#* Not as per spec, but some parsers do treat it like <code><abbr></code>. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is this allowed: <code><nowiki><div class="photo">http://example.com/photo.jpg</div></nowiki></code>?
*#* Yes, though it ''may'' cause problems for some naive parsers, and is probably less useful for humans viewing the page. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is it allowed to use <code><nowiki>http://</nowiki></code> URLs in <code>email</code>? or <code><nowiki>mailto:</nowiki></code> in <code>url</code>?
*#* Non-SMTP e-mail addresses can be used - the presence of a e-mail "type" of "x400" confirms this - so e-mail addresses which don't start with "mailto:" and do not contain an @-sign are theoretically possible. But given the prevalence of SMTP for mail delivery on the modern Internet, I don't see why this would be useful. For "url" it is often useful to encode non-HTTP URIs, such as FTP addresses or URIs for use with various instant messaging protocols, but given the existence of the "email" property, I don't see that it makes sense to encode "mailto" URIs. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is it allowed/required to use <code>mailto:</code> when e-mail is in non-<code><a></code>, e.g. <code><nowiki><span class="email">mailto:joe@example.com</span></nowiki></code>
*#* Yes, but for copy-and-pastability I'd recommend leaving out the "mailto:" prefix. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# If value of a property is empty (<code><nowiki><span class="email"></span></nowiki></code>) should it be interpreted as unknown value? ignored completely like it didn't exist? an error?
*# Can hCard contain nested hCard <i>anywhere</i>? or only outside any property or only inside <code>agent</code>?
*#* Yes, though naive parsers may have problems. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Can <code>organi'''s'''ation-name</code> (note spelling) be interpreted by parsers?
*#* It should not. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is <code>type</code> class ignored in values anywhere? It is ignored in <code><div class="tel"><span class="type">Work</span> 555</div></code>, but is it in <code><div class="fn"><span class="type">Work</span> Joe</div></code>?
*#* It doesn't have any special meaning within "fn", so should not be ignored. That is, the person's name would be parsed as "Work Joe". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-06-15</span> raised by <span class="fn">[[User:Kornel|Kornel]]</span></span>
<div class="description">
*# RFC 2426 allows TYPE for LABEL, however [[hcard-cheatsheet|hCard cheatsheet]] does not list any subproperties for <code>label</code>. Is this intentional? Is <code>label</code>'s <code>type</code> allowed in hCard?
** I raised this very issue on the mailing list about a month ago, but received no responses. Given that hCard claims to be a "a 1:1 representation of vCard (RFC2426) properties and values in semantic HTML or XHTML" (direct quote from [[hcard|spec]]), I think it's reasonable to infer that these types *are* allowed, but simply undocumented so far. I'll be including support for them in the next alpha of Cognition. [[User:TobyInk|TobyInk]] 23:59, 15 Jun 2008 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-11</span> raised by <span class="fn">[[User:mephtu|mephtu]]</span></span>
<div class="description discussion">
* I am concerned that hCard usage will foster widespread abuse of personal datamining by scrapers/spammers, as a standard markup of personal information formalizes the structure of such information which until now has been loosely encoded as formatting markup (e.g. HTML).
** The nice thing about microformats is that you are not required to publish everything. If you are not comfortable publishing your email, address, phone or other information, then you don't have to. If you are already publishing it on the web, then by adding microformats you are disambiguating a plain string of text and a string as meaning your name. [[User:Brian|Brian]] 08:56, 12 Dec 2008 (UTC)
*** That is true, but it does more tightly associate e-mail addresses with other information. Spammers could use this to tie an e-mail address to other personal/contact details and make their messages less spammy in an attempt to fool filters. For example, some filters will raise the spam score of a message if the "To" field contains just an e-mail address, and not the recipient's name - hCard provides spammers with a fairly reliable way of finding out that name. I don't think this is a ''huge'' concern, but it is a slight concern which shouldn't be entirely dismissed. [[User:TobyInk|TobyInk]] 16:37, 12 December 2008 (UTC)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-16</span> raised by <span class="fn">[[User:Tantek|Tantek Çelik]]</span></span>
<div class="description">
*# The "n" optimization rule for turning an fn of "WORD C." into an n given-name initial of "C" and family-name of "WORD" should be dropped, as it was not based on sufficient usage in practice (based on why I put it in there in the first place), and (a) it actually interferes with some broad usage in historical practice, e.g. on Pownce user's names were abbrevated as "GIVEN F." where GIVEN was their given-name and F was there family-name initial and (b) may have problems with non-Western name abbreviations also.
*#* suggested resolution: drop respective "n" optimization rule, and suggest markup for any use of abbreviated name components with abbr tag, e.g. <code><nowiki><span class="fn">Tantek <abbr>Ç.</abbr></span></nowiki></code>
*#** Could retain the rule when a comma or semicolon is found between the two parts though. [[User:TobyInk|TobyInk]] 22:39, 16 December 2008 (UTC)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-16</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="description">
*# '''n''' is listed as a required property. Sometimes this is implicit from the '''fn''', and that's fine. However, when <code><nowiki><span class="fn">Foo</span></nowiki></code> is found, "Foo" is implicitly a nickname, so the hCard still has no '''n''' property — does such an hCard still need an explicit '''n''' added?
</div>
</div>

== template ==

{{issues-format}}

== related pages ==
{{hcard-related-pages}}</nowiki>

User:XavierBadosa

2009-02-02T11:46:06Z

XavierBadosa: /* Me */

==Me==

<div class="vcard">

I'm <span class="fn">Xavier Badosa</span>, from <span class="adr"><span class="locality">Barcelona</span></span>. I've been doing web experiments since 1995 (more at <span class="url">http://xavierbadosa.com</span>).

I'm interested in the [[i18n]] issues of microformats.

</div>

hreview

2008-06-27T06:13:40Z

XavierBadosa: Removed reference to hReview creator link not functioning

<h1> hReview 0.3 </h1>

[[hreview|hReview]] is a simple, open, distributed format, suitable for embedding reviews (of products, services, businesses, events, etc.) in HTML, XHTML, Atom, RSS, and arbitrary XML. hReview is one of several [[microformats]] open standards.

Want to get started with writing an [[hreview|hReview]]? Use the [http://microformats.org/code/hreview/creator hReview creator] to write a review and publish it.

== Microformats Draft Specification 2006-02-22 ==
; 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])

Microformats [http://microformats.org/wiki/hreview#Copyright copyright] and [http://microformats.org/wiki/hreview#Patents patents] statements apply.

__TOC__

== 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 both numerous [[review-examples]] in the wild and earlier attempts at [[review-formats]], and have designed hReview around a simple minimal schema for reviews. Feedback is encouraged on the [[hreview-feedback|hReview feedback]] page.

{{rfc-2119-intro}}

=== 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], Mark Nottingham, [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 ('''<code>hreview</code>''')
** '''<code>version</code>'''. optional. text.
** '''<code>summary</code>'''. optional. text.
** item '''<code>type</code>'''. optional. product | business | event | person | place | website | url.
** '''<code>item</code>''' info. required. '''<code>fn</code>''' ('''<code>url</code>''' || '''<code>photo</code>''' ) | '''[[hcard|hCard]]''' (for person or business) | '''[[hcalendar|hCalendar]]''' (for event)
** '''<code>reviewer</code>'''. optional. '''[[hcard|hCard]]'''.
** '''<code>dtreviewed</code>'''. optional. ISO8601 absolute date time.
** '''<code>rating</code>'''. optional. fixed point integer [1.0-5.0], with optional alternate '''<code>worst</code>''' (default:1.0) and/or '''<code>best</code>''' (default:5.0), also fixed point integers, and explicit '''<code>value</code>'''.
** '''<code>description</code>'''. optional. text with optional valid HTML markup.
** tags. optional. keywords or phrases, using '''[[rel-tag]]''', each with optional rating.
** permalink. optional, using '''[[rel-bookmark]]''' and '''[[rel-self]]'''.
** license. optional, using '''[[rel-license]]'''.

=== 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.3".

'''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. If omitted, then in some cases the item type may be inferred. If the item is also an [[hcard|hCard]], then the item type is a "business" or a "person" based upon which of those the hCard represents. If the item is also an [[hcalendar|hCalendar]] event, then the item type is an "event".

'''item info''':: This required field {{must}} have at a minimum the name ("fn" - the formatted text corresponding to the name, except for an event item which {{must}} have the "summary" property inside the respective hCalendar "vevent") of ''the'' item (an hReview describes only one 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) {{must}} be encapsulated in an [[hcard|hCard]]. For items of type event, the item info {{should}} be encapsulated in an [[hcalendar|hCalendar]] "vevent". Non-URL unique item IDs (e.g. ISBNs, UPCs) {{may}} be represented as a URN ("url") for the item. Encapsulated microformats (e.g. [[hcard|hCard]] and [[hcalendar|hCalendar]] events for now) may be set on the item itself (e.g. class="item vcard"). However, when using item info subproperties ("fn", "url", "photo"), they {{must}} be nested <em>inside</em> the item element.

'''reviewer''':: The optional field specifies the person who authored the review. If the reviewer is specified, an hCard representing the reviewer {{must}} be provided. For anonymous reviews, use "anonymous" (without quotes) for the full name of the reviewer. If no "reviewer" is found inside the hReview, parsers {{should}} look outside the hReview, in the context of the page, for the "reviewer". If there is no "reviewer" outside either, then parsers {{should}} use the author defined by the containing document language, e.g. for HTML documents, the <code><nowiki><address></nowiki></code> contact info for the page (which is ideally marked up as an [[hcard|hCard]] as well), for Atom 1.0 the <code><nowiki><entry></nowiki></code> <code><nowiki><author></nowiki></code> if present and if not the <code><nowiki><feed></nowiki></code> <code><nowiki><author></nowiki></code>, for RSS the <code><nowiki><author></nowiki></code> inside the containing <code><nowiki><item></nowiki></code> element.

'''dtreviewed''':: This optional field when present {{must}} provide an [[ISO-8601|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. If dtreviewed is absent from the hReview, then look outside the hReview, in the surrounding context. If the context is an [[hatom|hAtom]] entry, use its "published" (or "updated" if that is missing) datetime as the dtreviewed, if not present on the entry, use the "published" (or "updated" if that is missing) of the feed. Otherwise use the creation date (or modified date if that is missing) information according to the containing document language (e.g. "published"/"updated" similarly for Atom feeds), then protocol (e.g. HTTP Last-Modified, or file system last modified datetime) as the dtreviewed.

'''rating''':: The rating is a fixed point integer (one decimal point of precision) from 1.0 to 5.0 inclusive indicating a rating for the item, higher indicating a better rating by default. Optionally a different integral "worst" value and/or "best" value {{may}} be specified to indicate a different range (e.g. 6 from 0-10). The "best" value may be numerically smaller than the "worst" value.

'''description''':: This optional field contains the full text representing the written opinion of the reviewer. The field {{may}} include valid HTML 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]] 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]], 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}} also invert this structure for the same semantic if it is more convenient for their markup, that is, place the [[rel-tag]] inside a rating to indicate a rated tag. Note: rated tags {{should}} ideally use a tag space that explains what the ratings for that tag mean. E.g. Food:18/30 {{should}} link to a tags space for Food that explains what an 18 out of 30 means for the Food tag.

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

'''license''':: This optional field links to the license under which the contents of the hReview itself is licensed, using the '''[[rel-license]]''' microformat.

The following field names have been reused from the [[hcard|hCard]] and [[hcalendar|hCalendar]] microformats: <code>version, summary, fn, url, photo, description</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 the class name 'hreview' in hReview.
* 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.0">***</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 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 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.

=== Object Includes ===

hReview 0.3 includes support for the object [[include-pattern]].

Often a single page lists an item, and then several reviews for that item. In order to avoid having to repeat the item info for each review of the item, the first review should be marked up as an hReview, with a unique "id" attribute on the item info, and then following reviews should use the object [[include-pattern]] to include the item info from the first review.

=== 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 which the publisher may explicitly specify using [[rel-license]] as specified above.
* 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.0 to 5.0, and most of those represent the rating as a number (and possibly half) 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.

Want to get started with writing an [[hreview|hReview]]? Use the [http://microformats.org/code/hreview/creator hReview creator] to write a review and publish it on your blog.

=== 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">Crepes on Cole is awesome</h4>
<span class="reviewer vcard">Reviewer: <span class="fn">Tantek</span> -
<abbr class="dtreviewed" title="20050418T2300-0700">April 18, 2005</abbr></span>
<div class="description item vcard"><p>
<span class="fn org">Crepes on Cole</span> is one of the best little
creperies in <span class="adr"><span class="locality">San Francisco</span></span>.
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></div>
<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 />

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.

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">Menlo Park</span>,
<span class="region">CA</span>
<span class="postal-code">94025</span>,
</span>
<span class="tel">+1-650-327-0830</span>;
<a class="url" href="http://cafeborrone.com">cafeborrone.com</a>
</div>
<ul>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
Food: <span class="value">18</span>/<span class="best">30</span></a>;</li>
<li class="rating"><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
Ambience: <span class="value">19</span>/<span class="best">30</span></a>;</li>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
Service: <span class="value">15</span>/<span class="best">30</span></a>;</li>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
Price: <abbr class="value" title="2">$$</abbr>...</a></li>
</ul>
<div 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></div>
Review (<a href="http://microformats.org/wiki/hreview">
hReview v<span class="version">0.3</span></a>)
by <span class="reviewer vcard"><span class="fn">anonymous</span></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 { margin:1em 0; padding:0 }
ul 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 />

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.

Review ([http://microformats.org/wiki/hreview hReview v0.3]) 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"><span class="item">
<a class="url fn" 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" />
The Postal Service: Give Up</a></span>
<div 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></div>
(<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

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

"Nothing Better" is a great track on this album, too...

(*****)

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 vcard">
<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>
<div class="description"><p>
This movie has great music and visuals.
</p></div>
</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 number of hReview examples in the wild has expanded far beyond the capacity of being kept inline in this specification. They have been moved to a [[hreview-examples-in-wild|separate page]].

See [[hreview-examples-in-wild|hReview Examples in the wild]].

== Implementations ==
This section is '''informative'''. The number of hReview implementations has also expanded beyond the capacity of keeping them inline. They have been moved to a [[hreview-implementations|separate page]].

See [[hreview-implementations|hReview Implementations]].

== 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://www.ietf.org/rfc/rfc4287.txt RFC4287] (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]
* [http://local.yahoo.com/details?id=21359628 Crepes on Cole reviews on Yahoo! Local]
* Other reviews efforts. See [[reviews-formats]].
* Contributed from http://developers.technorati.com/wiki/hReview.

==== Similar Work ====
* [[hlisting-proposal|hListing]]
* [[xoxo|XOXO]]

=== Copyright ===
{{MicroformatCopyrightStatement2005}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

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

== 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.2 ===
The following changes have been made in hReview v0.3 over [[hreview-v0.2|hReview v0.2]]:

Normative changes:
# MUST (instead of SHOULD) use [[hcard|hCard]] for the item description of a business or person
# "reviewer" changes
## Made reviewer *optional* per feedback from Ryan King and Mark Nottingham
## If reviewer is absent from the hReview, then look outside the hReview, in the context of the page, for the reviewer. If there is no "reviewer" outside either, then use the author information according to the containing document language (e.g. <code><nowiki><address></nowiki></code> for HTML pages) as the reviewer.
## MUST (instead of SHOULD) use [[hcard|hCard]] to represent reviewer information
# "dtreviewed" changes
## Made dtreviewed *optional* per feedback from Ryan King and Mark Nottingham
## If dtreviewed is absent from the hReview, then look outside the hReview, in the surrounding context. If the context is an [[hatom|hAtom]] entry, use its "published" (or "updated" if that is missing) datetime as the dtreviewed, if not present on the entry, use the "published" (or "updated" if that is missing) of the feed. Otherwise use the information according to the containing document language (e.g. "published"/"updated" similarly for Atom feeds), then protocol (e.g. HTTP Last-Modified, or file system last modified datetime).
# SHOULD use [[hcalendar|hCalendar]] to represent an item of 'type' 'event'
# Added one decimal digit of precision to ratings' numerical values based on publisher experience.
# Use [http://microformats.org/wiki/hcard#Value_excerpting the "value" construct from hCard] (as it is used in "tel" properties for example) to more explicitly markup the rating value when also providing (marking up) the best/worst of a rating.
# Added [[rel-license]] to indicate the license of the hReview as a whole.
# Permit tags inside ratings to denote rated tags, the same as ratings inside tags per suggestion from Eran Globen.
# Add [[include-pattern]] support to allow multiple reviews for the same item to not repeat the item info.

Informative changes (several, but in particular):
# Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag. E.g. to explain what Food:18/30 means.
# Updated examples accordingly.

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

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

hcard-issues

2008-06-26T07:49:01Z

XavierBadosa: /* 2007 */

<h1> hCard issues </h1>
{{TOC-right}}
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

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

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See other [[issues]] also.

== closed issues ==
See: [[hcard-issues-resolved]]

== resolved issues ==
See: [[hcard-issues-resolved]]

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2006 ===

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#*** See also the proposal to use this pattern in [[representative-hcard]]
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. <strong>abbr-design-pattern</strong> would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>
<span class="tel" xml:lang="es">
<abbr class="type" title="home">Casa</abbr> (<span class="type">pref</span>erido):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]
*# To avoid [[i18n]] issues, microformats should keep its hands off content (this also affects [[hReview]]). [[abbr-design-pattern]] doesn't seem the right solution here. Someone from France suggested elsewhere to use the class value '''telwork''', etc. but again it's a dubious solution (remember that a ''tel'' can have a type of ''voice'' and ''work'' '''at the same time'''). I suggest considering:<pre><nowiki>
<span class="tel home pref" xml:lang="es">
Casa (preferido):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>It could be argued that somehow this solution violates the microformats [[principles|principle of visible data]]. Maybe it does, but [[i18n]] should come first because otherwise microformats violates the first rule: '''solve a specific problem''' (and the last: "enable and encourage decentralized and distributed development, content, services: explicitly encourage the original 'spirit of the Web'"). -[[User:XavierBadosa|Xavier Badosa]]

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-19</span> raised by <span class="fn">[[User::ChristinaHope|Christina Hope]]</span></span>
<div class="description">
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-31</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-04-19</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the [[abbr-design-pattern]] (or its successor) if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>

===2008===

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-01</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]</span>
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
<span class="fn locality">New York</span></nowiki></code>; <code><nowiki><span class="fn label">Asia</span></nowiki></code>, since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary"><span class="dtstart">2008-01-09</span> <span id="tel-type-lang">2008- moved from vcard-suggestions</span></span>
<div class="description">
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : <span class="telwork">0321596224</span></nowiki> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-02</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>n</code>" optimisation rules (<code>nickname</code>, <code>fn</code>) should not apply where the <code>fn</code> is also the <code>role</code> or <code>title</code>: e.g <code><nowiki>
<span class="fn role">Webmaster</span></nowiki></code>; <code><nowiki><span class="fn title">Duty Manager</span></nowiki></code>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-06</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# It seems to me that FN has been reused beyond its original vCard scope of person names, to cover any name. This led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>fn</code>" optimisation rule should not apply where the full <code>fn</code> is also the <code>nickname</code>: e.g <code><nowiki><span class="fn nickname">Plastic Bertram</span></nowiki></code>, since a given-name+family-name pair is not usually a nickname. (But how to deal with pseudonyms such as "Maurice Micklewhite (known professionally as Michael Caine)"?)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# Is "n" optional or mandatory? The spec says yes (with exceptions) the cheat-sheet says no. Parsers and common practice seem to indicate not.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# "<code>nickname</code>" and "<code>fn</code>" optimisation does not work for some or all names in Asian languages. See [http://zh.wikipedia.org/wiki/%E6%B9%AF%E5%A7%86%C2%B7%E5%85%8B%E9%AD%AF%E6%96%AF Tom Cruise on Chinese Wikipedia], where the <code>fn</code> and nickname are the same. This could be partly remedied by not applying such optimisation when the page's (or element's) language is set to one of a set of affected languages (may also apply to other languages, such as Greek). '''Cpmment from people fluent in such languages would be welcome.'''
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-08</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# The required FN makes it difficult to use hCard in HTML Tables without resorting to hiding information (as in http://www.bo.ingv.it/contents/INGV-Bologna/Staff.html) or using the [[include-pattern]]. Perhaps FN should not be required if some N are present. Originally raised in [http://rbach.priv.at/Microformats/IRC/2008-02-08#T181749]
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-06-01</span> raised by <span class="fn">[[User:Kornel|Kornel]]</span></span>
<div class="description">
*# I need clarification how should "more semantic equivalents" be interpreted inside values (when they don't have relevant class name, but are inside another parsed element)
*#* <code><nowiki><span class="email"><a href="mailto:href">nodetext</a></span></nowiki></code> – is it "href", "nodetext" or an error? What if there are multiple links inside?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><abbr title="title">nodetext</abbr></span></nowiki></code> – is it "title" or "nodetext"?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><img alt="alt">nodetext</span></nowiki></code> – is it "alt", "nodetext" or both?
*#** A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><abbr title="title"><span class="value">nodetext</span></abbr></span></nowiki></code> – "title", "nodetext" or both?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="url"><img src="src" alt="alt">nodetext</span></nowiki></code> – "src", "alt", "nodetext" or "altnodetext"?
*#** A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><div class="category"><a rel="tag bookmark" href="href">nodetext</a></div></code> – is it a tag? What if there are multiple links inside?
*#** Not sure how other parsers treat this, but Cognition will create two categories based on this. One because of the [rel-tag], based on the final component of the URL; and the second category because of class=category, based on the node text. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Does <code>agent</code> property has to be a hCard?
*#* Is <code><span class="agent">Joe Sixpack</span></code> allowed?
*#** Yes. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* Is <code><span class="agent"><div class="vcard">…</div></span></code> ok?
*#** [http://buzzword.org.uk/cognition/ Cognition] doesn't specifically support this format - they'll be parsed as two separate hCards. The "outer" hCard will have an "agent" property containing the unparsed node text for the inner hCard, as if you'd used a plain string for the agent as per the previous example. If you want to provide an hCard for the agent, and have it parsed as such, Cognition requires that you use: <code><div class="agent vcard">…</div></code>. (There is also the separate issue that it is illegal in HTML to nest a DIV within a SPAN.) [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* What about <code><a class="agent" href="card.vcf">…</a></code>?
*#** I don't think many hCard parsers also parse vCard. If they support vCard it's probably as an output format rather than input. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is value of <code><abbr></code> without <code>title</code> empty or should it be interpreted like <code><span></code>?
*#* I think consensus is that the node text should be used. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Does <code><acronym></code> work like <code><abbr></code>?
*#* Not as per spec, but some parsers do treat it like <code><abbr></code>. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is this allowed: <code><nowiki><div class="photo">http://example.com/photo.jpg</div></nowiki></code>?
*#* Yes, though it ''may'' cause problems for some naive parsers, and is probably less useful for humans viewing the page. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is it allowed to use <code><nowiki>http://</nowiki></code> URLs in <code>email</code>? or <code><nowiki>mailto:</nowiki></code> in <code>url</code>?
*#* Non-SMTP e-mail addresses can be used - the presence of a e-mail "type" of "x400" confirms this - so e-mail addresses which don't start with "mailto:" and do not contain an @-sign are theoretically possible. But given the prevalence of SMTP for mail delivery on the modern Internet, I don't see why this would be useful. For "url" it is often useful to encode non-HTTP URIs, such as FTP addresses or URIs for use with various instant messaging protocols, but given the existence of the "email" property, I don't see that it makes sense to encode "mailto" URIs. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is it allowed/required to use <code>mailto:</code> when e-mail is in non-<code><a></code>, e.g. <code><nowiki><span class="email">mailto:joe@example.com</span></nowiki></code>
*#* Yes, but for copy-and-pastability I'd recommend leaving out the "mailto:" prefix. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# If value of a property is empty (<code><nowiki><span class="email"></span></nowiki></code>) should it be interpreted as unknown value? ignored completely like it didn't exist? an error?
*# Can hCard contain nested hCard <i>anywhere</i>? or only outside any property or only inside <code>agent</code>?
*#* Yes, though naive parsers may have problems. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Can <code>organi'''s'''ation-name</code> (note spelling) be interpreted by parsers?
*#* It should not. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is <code>type</code> class ignored in values anywhere? It is ignored in <code><div class="tel"><span class="type">Work</span> 555</div></code>, but is it in <code><div class="fn"><span class="type">Work</span> Joe</div></code>?
*#* It doesn't have any special meaning within "fn", so should not be ignored. That is, the person's name would be parsed as "Work Joe". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-06-15</span> raised by <span class="fn">[[User:Kornel|Kornel]]</span></span>
<div class="description">
*# RFC 2426 allows TYPE for LABEL, however [[hcard-cheatsheet|hCard cheatsheet]] does not list any subproperties for <code>label</code>. Is this intentional? Is <code>label</code>'s <code>type</code> allowed in hCard?
** I raised this very issue on the mailing list about a month ago, but received no responses. Given that hCard claims to be a "a 1:1 representation of vCard (RFC2426) properties and values in semantic HTML or XHTML" (direct quote from [[hcard|spec]]), I think it's reasonable to infer that these types *are* allowed, but simply undocumented so far. I'll be including support for them in the next alpha of Cognition. [[User:TobyInk|TobyInk]] 23:59, 15 Jun 2008 (PDT)
</div>
</div>

== template ==

{{issues-format}}

== related pages ==
{{hcard-related-pages}}</nowiki>

User:XavierBadosa

2008-06-26T07:41:23Z

XavierBadosa:

==Me==

<div class="vcard">

I'm <span class="fn">Xavier Badosa</span>, from <span class="adr"><span class="locality">Barcelona</span></span>. I've being doing web experiments since 1995 (for example, <span class="url">http://www.badosa.com</span> or <span class="url">http://www.inlibris.com</span>).

I'm interested in the [[i18n]] issues of microformats.

</div>

hcard-issues

2008-06-26T07:24:59Z

XavierBadosa: /* 2007 */

<h1> hCard issues </h1>
{{TOC-right}}
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

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

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See other [[issues]] also.

== closed issues ==
See: [[hcard-issues-resolved]]

== resolved issues ==
See: [[hcard-issues-resolved]]

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2006 ===

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#*** See also the proposal to use this pattern in [[representative-hcard]]
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. <strong>abbr-design-pattern</strong> would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>
<span class="tel" xml:lang="es">
<abbr class="type" title="home">Casa</abbr> (<span class="type">pref</span>erido):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]
*# To avoid I18n issues, microformats should keep its hands off content (this also affects [[hReview]]). [[abbr-design-pattern]] doesn't seem the right solution here. Someone from France suggested elsewhere to use the class value '''telwork''', etc. but again it's a dubious solution (remember that a ''tel'' can have a type of ''voice'' and ''work'' '''at the same time'''). I suggest considering:<pre><nowiki>
<span class="tel home pref" xml:lang="es">
Casa (preferido):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>It could be argued that somehow this solution violates the microformats [[principles|principle of visible data]]. Maybe it does, but I18n should come first because otherwise microformats violates the first rule: '''solve a specific problem'''. -[[User:XavierBadosa|Xavier Badosa]]

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-19</span> raised by <span class="fn">[[User::ChristinaHope|Christina Hope]]</span></span>
<div class="description">
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-31</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-04-19</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the [[abbr-design-pattern]] (or its successor) if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>

===2008===

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-01</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]</span>
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
<span class="fn locality">New York</span></nowiki></code>; <code><nowiki><span class="fn label">Asia</span></nowiki></code>, since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary"><span class="dtstart">2008-01-09</span> <span id="tel-type-lang">2008- moved from vcard-suggestions</span></span>
<div class="description">
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : <span class="telwork">0321596224</span></nowiki> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-02</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>n</code>" optimisation rules (<code>nickname</code>, <code>fn</code>) should not apply where the <code>fn</code> is also the <code>role</code> or <code>title</code>: e.g <code><nowiki>
<span class="fn role">Webmaster</span></nowiki></code>; <code><nowiki><span class="fn title">Duty Manager</span></nowiki></code>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-06</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# It seems to me that FN has been reused beyond its original vCard scope of person names, to cover any name. This led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The "<code>fn</code>" optimisation rule should not apply where the full <code>fn</code> is also the <code>nickname</code>: e.g <code><nowiki><span class="fn nickname">Plastic Bertram</span></nowiki></code>, since a given-name+family-name pair is not usually a nickname. (But how to deal with pseudonyms such as "Maurice Micklewhite (known professionally as Michael Caine)"?)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# Is "n" optional or mandatory? The spec says yes (with exceptions) the cheat-sheet says no. Parsers and common practice seem to indicate not.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]</span>
<div class="description">
*# "<code>nickname</code>" and "<code>fn</code>" optimisation does not work for some or all names in Asian languages. See [http://zh.wikipedia.org/wiki/%E6%B9%AF%E5%A7%86%C2%B7%E5%85%8B%E9%AD%AF%E6%96%AF Tom Cruise on Chinese Wikipedia], where the <code>fn</code> and nickname are the same. This could be partly remedied by not applying such optimisation when the page's (or element's) language is set to one of a set of affected languages (may also apply to other languages, such as Greek). '''Cpmment from people fluent in such languages would be welcome.'''
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-08</span> raised by <span class="fn">[[User:Guillaume Lebleu| Guillaume Lebleu]]</span></span>
<div class="description">
*# The required FN makes it difficult to use hCard in HTML Tables without resorting to hiding information (as in http://www.bo.ingv.it/contents/INGV-Bologna/Staff.html) or using the [[include-pattern]]. Perhaps FN should not be required if some N are present. Originally raised in [http://rbach.priv.at/Microformats/IRC/2008-02-08#T181749]
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-06-01</span> raised by <span class="fn">[[User:Kornel|Kornel]]</span></span>
<div class="description">
*# I need clarification how should "more semantic equivalents" be interpreted inside values (when they don't have relevant class name, but are inside another parsed element)
*#* <code><nowiki><span class="email"><a href="mailto:href">nodetext</a></span></nowiki></code> – is it "href", "nodetext" or an error? What if there are multiple links inside?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><abbr title="title">nodetext</abbr></span></nowiki></code> – is it "title" or "nodetext"?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><img alt="alt">nodetext</span></nowiki></code> – is it "alt", "nodetext" or both?
*#** A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="fn"><abbr title="title"><span class="value">nodetext</span></abbr></span></nowiki></code> – "title", "nodetext" or both?
*#** Parsed as "nodetext" [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><nowiki><span class="url"><img src="src" alt="alt">nodetext</span></nowiki></code> – "src", "alt", "nodetext" or "altnodetext"?
*#** A matter of debate recently. Some parsers as "nodetext", others as "altnodetext". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* <code><div class="category"><a rel="tag bookmark" href="href">nodetext</a></div></code> – is it a tag? What if there are multiple links inside?
*#** Not sure how other parsers treat this, but Cognition will create two categories based on this. One because of the [rel-tag], based on the final component of the URL; and the second category because of class=category, based on the node text. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Does <code>agent</code> property has to be a hCard?
*#* Is <code><span class="agent">Joe Sixpack</span></code> allowed?
*#** Yes. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* Is <code><span class="agent"><div class="vcard">…</div></span></code> ok?
*#** [http://buzzword.org.uk/cognition/ Cognition] doesn't specifically support this format - they'll be parsed as two separate hCards. The "outer" hCard will have an "agent" property containing the unparsed node text for the inner hCard, as if you'd used a plain string for the agent as per the previous example. If you want to provide an hCard for the agent, and have it parsed as such, Cognition requires that you use: <code><div class="agent vcard">…</div></code>. (There is also the separate issue that it is illegal in HTML to nest a DIV within a SPAN.) [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*#* What about <code><a class="agent" href="card.vcf">…</a></code>?
*#** I don't think many hCard parsers also parse vCard. If they support vCard it's probably as an output format rather than input. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is value of <code><abbr></code> without <code>title</code> empty or should it be interpreted like <code><span></code>?
*#* I think consensus is that the node text should be used. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Does <code><acronym></code> work like <code><abbr></code>?
*#* Not as per spec, but some parsers do treat it like <code><abbr></code>. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is this allowed: <code><nowiki><div class="photo">http://example.com/photo.jpg</div></nowiki></code>?
*#* Yes, though it ''may'' cause problems for some naive parsers, and is probably less useful for humans viewing the page. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is it allowed to use <code><nowiki>http://</nowiki></code> URLs in <code>email</code>? or <code><nowiki>mailto:</nowiki></code> in <code>url</code>?
*#* Non-SMTP e-mail addresses can be used - the presence of a e-mail "type" of "x400" confirms this - so e-mail addresses which don't start with "mailto:" and do not contain an @-sign are theoretically possible. But given the prevalence of SMTP for mail delivery on the modern Internet, I don't see why this would be useful. For "url" it is often useful to encode non-HTTP URIs, such as FTP addresses or URIs for use with various instant messaging protocols, but given the existence of the "email" property, I don't see that it makes sense to encode "mailto" URIs. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is it allowed/required to use <code>mailto:</code> when e-mail is in non-<code><a></code>, e.g. <code><nowiki><span class="email">mailto:joe@example.com</span></nowiki></code>
*#* Yes, but for copy-and-pastability I'd recommend leaving out the "mailto:" prefix. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# If value of a property is empty (<code><nowiki><span class="email"></span></nowiki></code>) should it be interpreted as unknown value? ignored completely like it didn't exist? an error?
*# Can hCard contain nested hCard <i>anywhere</i>? or only outside any property or only inside <code>agent</code>?
*#* Yes, though naive parsers may have problems. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Can <code>organi'''s'''ation-name</code> (note spelling) be interpreted by parsers?
*#* It should not. [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
*# Is <code>type</code> class ignored in values anywhere? It is ignored in <code><div class="tel"><span class="type">Work</span> 555</div></code>, but is it in <code><div class="fn"><span class="type">Work</span> Joe</div></code>?
*#* It doesn't have any special meaning within "fn", so should not be ignored. That is, the person's name would be parsed as "Work Joe". [[User:TobyInk|TobyInk]] 08:30, 1 Jun 2008 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-06-15</span> raised by <span class="fn">[[User:Kornel|Kornel]]</span></span>
<div class="description">
*# RFC 2426 allows TYPE for LABEL, however [[hcard-cheatsheet|hCard cheatsheet]] does not list any subproperties for <code>label</code>. Is this intentional? Is <code>label</code>'s <code>type</code> allowed in hCard?
** I raised this very issue on the mailing list about a month ago, but received no responses. Given that hCard claims to be a "a 1:1 representation of vCard (RFC2426) properties and values in semantic HTML or XHTML" (direct quote from [[hcard|spec]]), I think it's reasonable to infer that these types *are* allowed, but simply undocumented so far. I'll be including support for them in the next alpha of Cognition. [[User:TobyInk|TobyInk]] 23:59, 15 Jun 2008 (PDT)
</div>
</div>

== template ==

{{issues-format}}

== related pages ==
{{hcard-related-pages}}</nowiki>