Microformats Wiki - User contributions [en]

events/2008-03-07-sxsw-interactive

2008-03-04T22:12:42Z

MikeKaply: /* attendees */

<h1>SXSW Interactive 2008</h1>
{{TOC-right}}
One of several [[events]] where microformats will undoubtedly be mentioned, discussed, and perhaps even iterated or even created (per the [[process]] of course).

==Subscribe==
You can:
*Add this event to your Calendar: http://feeds.technorati.com/events/microformats.org/wiki/events/2008-03-07-sxsw-interactive
*Subscribe to this event: webcal://feeds.technorati.com/events/microformats.org/wiki/events/2008-03-07-sxsw-interactive

== details ==
<div class="vevent">
;When
:<span class="dtstart">2008-03-07</span>–<span class=dtend>2008-03-11</span>
;Where
:<span class="location vcard"><span class="fn org">Austin Convention Center</span>, <span class="adr"><span class="locality">Austin</span>, <span class="region">Texas</span> <span class="country-name">USA</span></span></span>
;What
:<span class="summary">SxSWi</span>
;Web
:<span class="url">http://2008.sxsw.com/</span>
</div>

'''[http://technorati.com/events/microformats.org/wiki/events/microformats.org/wiki/events/2008-03-07-sxsw-interactive Add this event to your diary or calendar program]''' http://www.boogdesign.com/images/buttons/microformat_hcalendar.png

== related events ==
Please add links / brief description to specific sessions and meetups during SXSW Interactive 2008 that relate to microformats, and consider creating separate event wiki pages for them as well.
* 2008-03-07
* 2008-03-08
** 6pm-7pm microformats meetup in the hallway outside the main sessions (proposed)
** 6pm-8pm [http://upcoming.yahoo.com/event/418886/ GeekAustin SXSW Happy Hour]. description includes literally: "microformats, OpenID, microformats, rich APIs, sexy but functional design, XFN, mashups, cute little widgets, um and microformats."
* 2008-03-09
* 2008-03-10
** 5pm-6pm [[events/2008-03-10-sxsw-portability-panel|Building Portable Social Networks panel at South by Southwest Interactive 2008]]
* 2008-03-11

== tags ==
Please use ''all'' of the following tags when tagging related content (blog posts, photos):

tags: '''sxsw sxsw08 sxsw2008 sxswi sxswi08 sxswi2008 microformats'''

== attendees ==
Add yourself alphabetically sorted by family name if you are attending (with dates attending in parentheses)

* [[User:Tantek|Tantek Çelik]] (2008-03-05...2008-03-16)
* Ryan King
* Michael Kaply

== photographs ==
Please use ''all'' of the following tags when tagging related photos:

tags: '''sxsw sxsw08 sxsw2008 sxswi sxswi08 sxswi2008 microformats'''


* ...

== notes ==
Session comments and Q&A.
* ...

== articles and blog posts ==
Articles and blog posts following up on the meetup. Newest first.

Please use ''all'' of the following tags when tagging related blog posts:

tags: '''sxsw sxsw08 sxsw2008 sxswi sxswi08 sxswi2008 microformats'''

* ...



== related pages==
{{events-related-pages}}

adr-singular-properties

2008-03-04T19:52:56Z

MikeKaply:

<h1>adr singular properties</h1>

This is an atttempt to determine the singular properties in [[adr|adr]].

=== post-office-box ===

An address typically would only one post office box. Mail could not be split between two boxes.

=== extended-address ===

This could in theory be plural, if there were things like suite number, building. etc.

=== street-address ===

An address typically would only one have one street-address.

=== locality ===

An address typically would only one have one locality.

=== region ===

An address typically would only one have one region.

=== postal-code ===

An address typically would only one have one postal code.

=== country-name ===

An address typically would only one have one country.

hcard-parsing

2008-02-07T18:10:54Z

MikeKaply: /* parsing hCard properties and values */

<h1>hCard parsing</h1>
{{TOC-right}}
by [http://tantek.com/log/ Tantek Çelik]

== introduction ==

When I first conceived of [[hcard|hCard]], it was clear to me how to unambiguously parse both for the existence of hCards in arbitrary (X)HTML (and anywhere that arbitrary (X)HTML can be embedded, e.g. RSS, Atom, "generic XML"), and hCard properties and values.

I worked directly with Brian Suda to capture these thoughts in an implementation, and Brian wrote X2V, an XSLT script that converts hCards to vCards, thus simultaneously demonstrating the parsability of hCards, and the immediate utility of hCard content interoperating with widespread existing vCard applications.

I am now documenting those thoughts directly here so that additional implementations, rather than having to reverse engineer X2V, can be built directly from these elementary concepts.

== scope ==
Although this page is written specifically to explain how to parse [[hcard|hCard]], the concepts and algorithms contained therein serve as an example for how other [[compound-microformat|compound microformats]] are to be parsed.

== URL handling ==
An hCard parser may begin with a <abbr title="Uniform Resource Locator">URL</abbr> to retrieve.

If the <abbr>URL</abbr> lacks a [http://www.w3.org/TR/html401/intro/intro.html#h-2.1.2 fragment identifier], then the parser should parse the entire retrieved resource for [[hcard|hCards]].

If the <abbr>URL</abbr> has a fragment identifier, then the parser should parse ''only'' the node indicated by the fragment identifier and its descendants, looking for [[hcard|hCards]], starting with the indicated node, which may itself be a single [[hcard|hCard]].

== root class name ==
Each compound microformat starts with a root element with a relatively unique class name. By that I mean a class name which isn't simply a common word, and is unlikely to have been used outside the context of the microformat. By choosing such a root class name the microformat avoids (for all practical purposes) colliding with existing class names that may exist within the (X)HTML context. This is essential to enabling such compound microformats to be ''embedded'' inside current, existing content, as well as future content.

Fortunately this is not a new problem to solve. The root object names chosen for vCard (RFC 2426) and iCalendar (RFC 2445) similarly had to avoid such collisions and did so by choosing names that were unlikely to have been introduced into a MIME object context. The principle of ''reuse'' dictates that we should reuse the names for these root objects in those RFCs rather than invent our own. Given the same semantics, a design should reuse the names, rather than inventing a second name for the same semantic (a common design mistake made in environments that require namespaces).

In the vCard specification, the names are case-insensitive due to the (lack of) requirements of their context. (X)HTML class names are case sensitive per those specifications. Thus we are required to pick a canonical case for the class name equivalents of vCard object and property names. All lowercase is chosen to follow the precedent (i.e. ''reuse'' the pattern) set by XHTML, which similarly had to canonicalize the case of element and attribute names that it took from HTML4, which itself was case-insensitive due to its context (SGML). Additionally, reasons for avoiding mixed-case (e.g. camel case) in the context of class names may be found in the essay [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class], specifically, the section titled [http://tantek.com/log/2002/12.html#atoc_csensitivity Class sensitivity].

Thus the root class name of an [[hcard|hCard]] is "vcard".

== finding hCards ==
An (X)HTML document indicates that it may contain [[hcard|hCards]] by referencing the [[hcard-profile|hCard XMDP profile]]. See [http://gmpg.org/xmdp/description XMDP] for more details.

A parser finds [hcard|hCards] in an (X)HTML context by looking for elements with the root class name ''vcard'' just as the following [http://www.w3.org/TR/REC-CSS2/selector.html#class-html CSS class selector] does:
<pre>
.vcard
</pre>

For example, the following CSS style statement sets the background of all [hcard|hCards] to green:
<pre>
.vcard { background: green; }
</pre>

Note that the (X)HTML class attribute is a space separated set of class names.

Thus all of the following are valid hCard root elements:
* <code><div class="vcard"> </div></code>
* <code><span class="attendee vcard"> </span></code>
* <code><address class="vcard author"> </address></code>
* <code><li class="reviewer vcard first"> </li></code>

Once the root element of an [[hCard]] is found, that element and all its descendants (except those inside nested hCards) are all that is needed to parse the [[hCard]].

Thus it is possible for a well-formed [[hCard]] to be extracted from an overall non well-formed context, if the parser has the ability to find elements by class name within that non well-formed context.

== nested hCards ==
When parsing an hCard, if a parser finds a nested hCard, it should treat that hCard as its own object, and treat properties of the nested hCard as only belonging to the nested hCard, not the containing hCard.

This is essential for example for handling use of the "agent" property to nest an hCard that is the agent of another hCard. See [[hcard-examples-rfc2426#AGENT_Example_2|hCard examples from RFC2426 AGENT Example 2]] for an actual example.

Similarly, parsers should treat nested [[hCalendar]], [[hReview]], [[hResume]] [[xFolk]] in the same way, properties inside them {{must}} only apply to the nested microformat, not to the containing microformat.

All references below to "inside the hCard", "within the contents of the hCard", and similar phrasing {{must}} be interpreted with taking this nesting rule into account.

== hCard properties ==
The complete list of class names for hCard properties are documented in the [[hcard-profile|hCard profile]].

=== forward compatible parsing ===

When parsing the contents of an [[hCard]], any unrecognized class names must be ignored.

Similarly, unrecognized values for [[hCard]] properties must also be ignored.

=== finding hCard properties ===
To parse an hCard for an hCard property (e.g. "fn"), the parser simply looks for the first element with that class name inside the hCard.

This can also be expressed as the first element that matches this CSS selector:

<pre>
.vcard .fn /* note exception for nested hCards, see below */
</pre>

Some properties, like "fn", should only appear once, and thus the parser stops looking for the property after it has found the first occurrence in document order. Additional occurrences are ignored.

Other properties, like "adr", "email", "url", "tel", etc., may (and often do) appear more than once, and thus the parser continues to look for each occurrence within the contents of the hCard.

==== not finding nested hCard properties ====
Per the [[#nested_hCards|nested hCards rule]], properties inside a nested hCard {{must not}} apply to the current hCard being parsed. E.g. elements with class name "fn" that match this CSS selector:

<pre>
.vcard .vcard .fn
</pre>

{{must not}} affect the outer hCard.

=== parsing hCard properties and values ===
In general, once an element for a property is found, that element is used for the value.

In particular, once an element for a property is found:
# first, look for [[hcard-parsing#class_value_handling|class value children]] and use them as [[hcard-parsing#class_value_handling|described below]]
# otherwise, if there is a [[hcard-parsing#more_semantic_exceptions|more semantic exception]], use that as [[hcard-parsing#more_semantic_exceptions|described below]]
# finally, always fallback to using the contents of the element for the value

==== class value handling ====

For all properties, if the element for a property has one or more children with a class name of "value", then concatenate the node values for all those child elements with class name of "value", in their document order, and use that concatenation as the value of the property. (also called value excerpting)

==== more semantic exceptions ====

There are several exceptions to accomodate [http://microformats.org/wiki/hcard#Semantic_XHTML_Design_Principles semantic XHTML and more semantic equivalents].

===== email property =====
For the "email" property in particular, when the element is:
* <code><a href="mailto:..."></code> OR <code><area href="mailto:..."></code> : parse the value of the 'href' attribute, omitting the "mailto:" prefix and any "?" query suffix (if present), in the attribute. For details on the "mailto:" URL scheme, see RFC 2368.

===== tel property =====
For the "tel" property in particular, when the element is:
* <code><a href="tel:..."></code> OR <code><area href="tel:..."></code> : parse the value of the 'href' attribute, omitting the "tel:" prefix and any "?" query suffix (if present), in the attribute. For details on the "tel:" URL scheme, see RFC 2806.

===== properties of type URL or URI =====
For properties that may take type URL or URI parsers MUST handle relative URLs/URIs and normalize them to their respective absolute URLs/URIs, following the containing document's language's rules for resolving relative URLs/URIs (e.g. <base> for HTML, xml:base for XML).

===== properties of type URL or URI or UID =====
For properties that may take type URL, URI, or UID, when the element for that property is:
* <code><a href></code> OR <code><area href></code> : use the value of the 'href' attribute.
* <code><img src></code> : use the value of the 'src' attribute. If the 'src' is a "data:" URL, use the MIME type in that "data:" URL for the TYPE subproperty.
* <code><object data></code> : use the value of the 'data' attribute for the value. If the 'data' is a "data:" URL, use the MIME type in that "data:" URL for the TYPE subproperty, otherwise if the the 'type' attribute is present, us that for the TYPE subproperty.

===== properties not of type URL or URI or UID =====
For properties with values NOT of type URL, URI, or UID, when the element for a property is:
* <code><img alt></code> OR <code><area alt></code> : use the value of the 'alt' attribute.

===== all properties =====
For all properties, when the element for a property is:
* <code><abbr title></code>: use the value of the 'title' attribute. If there is no 'title' attribute then use the contents of the element.
** For properties which take an ISO8601 datetime value, parsers *should* pad any necessary precision (e.g. seconds), and *should* normalize any datetimes with timezone offsets, (e.g. <code>20050814T2305-0700</code>) into UTC (<code>20050815T060500Z</code>). Note that floating dates and times MUST NOT be made into UTC/Z absolute time zoned values.
* <code><br /></code> OR <code><hr /></code>: the value is the empty string. These two elements do not represent any semantics and thus it is probably an error (at least an abuse) for an author to use them with microformats class names. Nonetheless, if found, treat the value as empty.

==== white-space handling ====

hCard parsers should handle white-space parsing per XML white-space handling rules, with the following two additions:

# <code><pre></code> handling. Any content parsed as part of an hCard property that is inside a <pre> element must preserve all white-space per XML white-space preservation rules.
# <code><br /></code> handling. Any occurrence of a <code><br /></code> inside the element(s) for a value must be treated as a carriage-return (\n) in the respective location in the value.

=== hCard sub-properties ===

There are some hCard properties whose values themselves have structure (AKA structured type value) and are composed of multiple pieces, which we refer to as sub-properties.

For example, the "n" property consists of the sub-properties "family-name", "given-name", "additional-name", "honorific-prefix", and "honorific-suffix".

E.g. from section 3.1.2 of RFC 2426, modified to include Ph.D.

<pre>
N:Public;John;Quinlan;Mr.;Esq.,Ph.D.
</pre>

In [[hCard]] this "n" property would be marked up as

<pre>
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-name">Quinlan</span>
<span class="family-name">Public</span>,
<span class="honorific-suffix">Esq.</span>,
<span class="honorific-suffix">Ph.D.</span>
</span>
</pre>

Which would be rendered as:

Mr. John Quinlan Public, Esq., Ph.D.

=== hCard property parameters ===

Some hCard properties have one or more parameters, most often "type", with an enumerated set of values. We represent the specific ''value'' of the parameter as a class name on an element inside the element representing the property.

For example, the "adr" property has a type parameter which takes the values: "dom", "intl", "post", "parcel", "home", "work", "pref".

The "type" parameter is treated like a sub-property.

To encode the "type" of an "adr" property, a nested element with class="type" is used to markup the value of the type parameter.

Example with the "tel" property with a value of type "work":

<pre>
<span class="tel">
<span class="type">work</span>:
<span class="value">+1.123.456.7890</span>
</span>
</pre>

=== Value excerpting ===

Note the element with class="value" used in the above example.

Sometimes only part of an element which is the equivalent for a property should be used for the value of the property. This typically occurs when a property has a subtype, like TEL. For this purpose, the special class name "value" is introduced to excerpt out the subset of the element that is the value of the property.

Per the section in hCard on [[hcard#type_with_unspecified_value|type with unspecified value]], if the subtype is specified on a property, and there is no descendant of the property element with class name of "value", then the remainder (excluding the subtype) of the property element is considered the value.

== Include Pattern and Table Headers ==

When processing elements from the [[include-pattern]] or table headers inclusion methods, such elements should be processed as if they were inline.

== Proposed Additions ==
These are proposed additions to hCard parsing. Implementations MAY follow these conventions in order to gain implementation experience, and SHOULD report back on the results.

=== DEL element handling ===

When dealing with an HTML document that is hCard encoded, the parser SHOULD honor the <code><del></code> element.

There are two possibilities here (adopting both may be possible):

1. Skip any occurences of <code><del></code> elements and their contents entirely inside the contents of a property.

2. If the <code><del></code> element is used for a property itself, it could be useful as a way communication the of tombstoning / obsoleting of that particular property value, and thus while a parser that is converting to a vCard SHOULD simply do what is indicated in (1), applications which parsed hCard directly (rather than only supporting vCard) COULD treat such occurences of <code><del></code> elements as a way to remove obsolete information (with user confirmation of course) from a local contact information store.

=== Plain Text Formatting of Structural/Semantic HTML ===
There are several structural/semantic elements in HTML which have useful default styling which could be converted into ASCII (AKA Plain Text) equivalents as a low resolution way of communicating that structure. Note that <code><br /></code> and <code><pre></code> are already handled in the section above titled [http://microformats.org/wiki/hcard-parsing#white-space_handling White-space Handling].

When parsing the hCard <code>note</code> property (or <code>description</code> in hCalendar and hReview), hierarchically convert the following HTML tags into their plain text styling equivalents.

* <code><div></code>, <code></div></code>, <code><dl></code>, <code></dl></code>, <code><dt></code>, <code></li></code>, <code></dd></code> - Append a soft <code>\n</code> to the output. By "soft <code>\n</code>", we mean only do so if there isn't already a line break (in contrast to a "hard" (implied by default) <code>\n</code>). Two things in particular order to ensure that <code><div> <div></code> does not result in two <code>\n</code> characters in a row:
*# only output the <code>\n</code> if something other than whitespace (including <code>\n</code>) was outputted immediately previously.
*# omit any immediately subsequent whitespace characters.
* <code><li></code> - Append a soft <code>\n</code> and then </code> * </code>. (Note: Indenting the contents of the list item is not particularly practical, since that would require line-breaking, and that would depend on knowing the width of when the plain text is rendered. Wrapping to 70 characters may be a good assumption for plain text email, but is probably a very bad assumption for vCard output).
* <code></dt></code> - Append <code>:\n</code>
* <code><dd></code> - Append a soft <code>\n</code> and then </code> </code> (two space ASCII 32 characters).
* <code><h1></code>, <code></h1></code>, <code><h2></code>, <code></h2></code>, <code><h3></code>, <code></h3></code>, <code><h4></code>, <code></h4></code>, <code><h5></code>, <code></h5></code>, <code><h6></code>, <code></h6></code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>. (Note: we may want to consider some conventions to indicate the heading level. Perhaps only the relative heading level inside the property matters, e.g. whatever level HTML heading is seen first is treated as a first level heading, then any subsequent HTML heading elements are treated relative to that original heading (this is because it is likely that the property is embedded somewhere deep inside an HTML document following higher heading levels). Any subsequent higher level headings should perhaps cause a warning, and then simply be treated as a first level heading. Given that, the [http://microformats.org/wiki/wiki-formats#straw_proposals straw proposal for heading syntax] from Ian Hickson is one reasonable possibility, with the only issue being that for first and second level headings, how wide to make the line of '-'s or '='s, which is a similar problem to the line-breaking problem noted above when considering indenting the contents of list-items. Thus perhaps it might be sufficient to simply set a first level heading in ALL CAPS (same as the third level heading in Ian's proposed syntax), and let second and deeper level headings be simply implied by the "one line of text with two line breaks both before and after" convention. Rarely has there been more than one level of heading found within a DESCRIPTION property, and I've never seen more than two even if it is possible.)
* <code><p></code>, <code></p></code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>. (Note: Typical books indent the start of a paragraph approximately three spaces "<code> </code>", and implementations may wish to consider doing so as well. Keep in mind that on the Web, typical paragraphs do not start with a first line indent.)
* <code><q></code>, <code></q></code> - Append a double-quote '"' character.
* <code><sub></code> - Append an open parenthesis "("
* <code></sub></code> - Append a a close parenthesis ")".
* <code><sup></code> - Append an open bracket "["
* <code></sup></code> - Append a a close bracket "[". <code><sup></code> are often used for footnotes which in plain text are often formatted as bracketed numbers.
* <code><table></code>, <code></table></code>, <code><tbody></code>, <code></tbody></code>, <code><thead></code>, <code></thead></code>, <code><tfoot></code>, <code></tfoot></code>, <code><tr></code>, <code></tr></code>, <code><caption></code>, <code></caption></code> - Append a soft <code>\n</code>. Of course one could try to do a lot more with representing the structure of the table, but that is almost certainly more work than it is worth, nevermind the complexities introduced by COLSPAN, ROWSPAN etc. At least by approximating the table sections and rows the table may be more readable.
* <code></td></code>, <code></th></code> - Append a space and a tab character (ASCII 32, ASCII 9 respectively). It's not clear that what subsequent application would be able to make use of this visually, but at least the tabular nature of the structure is indicated and it makes it possible to copy and paste the table into something that handles tabular content like a spreadsheet and have the tabular structure reflected.

==== More challenging elements ====
* <code><ol></code> - it would be nice to number list items inside an ordered list rather than bullet them, but keeping track of list item numbers/counts is a non-trivial piece of state information for the parser to deal with, and thus we are omitting this behavior for now.

==== Use of CSS computed styles instead of HTML default styles ====
Rather than assuming the default presentation for these elements, and using that for the basis of plain text formatting, a parser could use the respective equivalent computed style properties and use those instead. However, requiring an hCard parser to also implement Cascading Style Sheets (e.g. CSS1) is out of scope. Some environments (i.e. a browser DOM) may already provide this information, and in that case, it may be easy for an hCard parser (e.g. a clientside javascript parser) to use computed style properties. E.g. instead of the elements above, the following computed styles could be used:
* display:block - Append a soft <code>\n</code>
** text-indent (non-zero value, on an element with display:block or display:list-item) - Append a number of spaces equivalent to value of the text-ident property divided by the computed font-size property of the element.
** margin-top, margin-bottom (non-zero value, on an element with display:block or display:list-item) - Append a number of "\n" equivalent to the value divided by the computed font-size property of the element. Obviously this won't properly collapse vertical margins.
* display:list-item - Append a soft <code>\n</code> followed by " * "
* etc.
This is enough extra work that I'm not sure it is worth spending the time documenting more equivalents. The above are sufficient to illustrate the possibility.

== Outstanding Issues ==

=== Issues 3 ===

Might be worth considering defining the parsing in terms of the DOM, so that it applies to HTML and XHTML equally without ambiguity.

== Resolved Issues ==

This section is informative.

The following issues have been explored and resolved inline in the text of hcard-parsing above.

=== Resolved as of 2005-09-16 ===

==== ISSUE 1 ====

Should we make plural sub-property names into singular versions and simply allow multiple instances? I.e. the singular honorific prefix would make more sense if it was classed as such, and the list implied by the value for honorific-suffixes could be made more explicit (and thus more easily machine parseable):

<pre>
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-names">Quinlan</span>
<span class="family-name">Public</span>,
<span class="honorific-suffix">Esq.</span>,
<span class="honorific-suffix">Ph.D.</span>
</span>
</pre>

RESOLUTION: Adopt singular class name equivalents for plural property and sub-property names.

==== ISSUE 2 ====

Restricting the "type" sub-property values to being expressed in class names seems less than ideal. It's taking a piece of information which is very often visible in the content, and forcing it to be invisible.

Here is an example of an extensive bit of contact information on a web page:

http://www.patchlink.com/company/contact.html

<pre>
Mailing Address
3370 N. Hayden Road, #123-175
Scottsdale, AZ 85251-6632

Physical Address
8515 E Anderson
Scottsdale, AZ 85255
</pre>

Note that the type information for each "adr" is explicit in the content. This content could be marked up like this:

<pre>
<div class="adr">
<abbr style="display:block" class="type" title="postal,parcel">Mailing Address</abbr>
<div class="street-address">3370 N. Hayden Road, #123-175</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>
<span class="postal-code">85251-6632</span>
</div>
<div class="adr">
<abbr style="display:block" class="type" title="work,pref">Physical Address</abbr>
<div class="street-address">8515 E Anderson</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>
<span class="postal-code">85255</span>
</div>
</pre>

RESOLUTION: The "type" parameter MUST be marked-up when content is available (like the above two examples). We are ditching the type-value-as-another class name pattern.

In addition since there are some potentical problems with the "type" parameter for TEL and EMAIL properties. Since there are no defined sub-properties (unlike ADR's post-code, locality, etc) the entire node-value of TEL is taken as the value. For example:
<pre>
<span class="tel">+1.123.456.7890 <abbr class="type" title="work">(work)</abbr></span>
</pre>
would be represented in vCard as:
<pre>
TEL;TYPE=work:+123.456.7890 (work)
</pre>

We are introducing another sub-property class="value" to enable excerpting of a the value of an element of for a property.

<pre>
<span class="tel"><span class="value">+1.123.456.7890</span> <abbr class="type" title="work">(work)</abbr></span>
</pre>

Then parsers would first need to look for class="value" and take the node value of that if it exists rather than class="tel".

If one or more child elements with the class name of "value" are present inside the element for a property, then concatenate the node values of those child elements (in the order found) and use that as the value of the property. This would be before using the node value of the element for a property itself.

== References ==

=== Normative References ===
* [[hcard|hCard]]
* vCard (RFC 2426)
* [http://w3.org/TR/XHTML1 XHTML 1.0 Recommendation]
* [http://w3.org/TR/html401 HTML 4.01 Recommendation]
* [http://gmpg.org/xmdp/ XMDP]

=== Informative References ===
* [http://w3.org/TR/REC-CSS1 CSS1 Recommendation]

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

include-pattern-issues

2007-08-03T20:29:35Z

MikeKaply: /* Include-Pattern Issues */

=Include-Pattern Issues=

See: [http://microformats.org/discuss/mail/microformats-dev/2006-May/000097.html A summary of issues with the include pattern].

* {{OpenIssue}} 2007-08-03D raised by [http://www.kaply.com/weblog/ Mike Kaply].
*# ''Issue 1: It needs to be explicit that the only classname on the object/etc should be include. Having classnames on the object is not necessary since the premise is that the object node is REPLACED by the referenced node.''

==Related Pages==
{{include-pattern-related-pages}}

hcard-issues

2007-08-03T19:12:09Z

MikeKaply: /* Issues */

<h1> hCard issues </h1>

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]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

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

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

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

See also related [[hcalendar-issues]].

__TOC__

== Issues ==

* {{OpenIssue}} 2007-08-03 raised by [http://www.kaply.com/weblog/ [User:MikeKaply|MikeKaply]]].
*# ''Issue 1: When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''
*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".

*{{OpenIssue}} 2007-04-24 raised by [[User:Singpolyma|singpolyma]]
*# ''What is the 'Label' property for''

*{{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
*#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 <code>abbr-design-pattern</code> if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?

* {{OpenIssue}} 2007-04-09 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Why is [[geo]] still a draft, when it's included in the already-published [[hcard|hCard]] spec?

* {{OpenIssue}} 2007-03-31 raised by [[User:AndyMabbett|Andy Mabbett]]
*# 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)

* {{OpenIssue}} 2007-03-26 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Parsers (Operator, Tails) currently expect <code>adr</code> to have one or more children. It is not clear from the spec that that's mandatory; nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. See [[hcard-brainstorming#ADR with no children]] for discussion.

* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
*# ''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?
* {{OpenIssue}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 raised elsewhere] by [[User:JamesCraig]]
*#internationalisation Note: <code>country-code</code> may be missing. Usually a postal-code prefix such as "FIN-00630 Helsinki" or "L-4750 Petange" (Luxembourg).
* {{OpenIssue}} 2007-02-02 raised by [[User::DerrickPallas|Derrick Pallas]]
*# [[adr]] says that all of it's properties are singular; however, "street-address" is listed as zero-or-more.
* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values?
* {{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]]
* 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# ''Proposal to use the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki>
<span xml:lang="en">Home (preferred): <span class="tel type:home type:pref">+1.415.555.1212</span></span>
<span xml:lang="es">Casa (preferido): <span class="tel type:home type:pref">+1.415.555.1212</span></span>
</nowiki></pre>
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].
*#* Clarified proposal, leaving REJECTED.
* 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. <br/>Examples: (1) <pre><nowiki><p>
<span class="vcard">
<span class="fn">Christina Hope</span>& nbsp;& nbsp;& nbsp;
<span class="department">Information Technology</span>& nbsp;& nbsp;& nbsp;
<span class="role">Website Coordinator</span>& nbsp;& nbsp;& nbsp;
<span display="none" class="region"></span>
<span class="tel"> x3408</span> & nbsp;& nbsp;& nbsp;
<span class="email"><a href="mailto:chope@example.com">chope@example.com</a></span>
</span></p></nowiki></pre>''

:: Try <pre><nowiki><p class="vcard">
<span class="fn">Christina Hope</span>
<span class="department">Information Technology</span>
<span class="role">Website Coordinator</span>
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</p></nowiki></pre>

::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.

::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)

* {{OpenIssue}} 2006-12-15 raised ([http://microformats.org/discuss/mail/microformats-discuss/2006-December/007730.html on 2006-12-14, on the mailing list]) by Joe Andrieu.
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparently intentional], but possibly requiring further extension. [[User:AndyMabbett|Andy Mabbett]]

* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.

* {{OpenIssue}} 2006-12-07 raised by RyanKing.
*# ''hCard org-fn matching should use organization-name, if given.''
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.

* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.

* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]
*# The specification should be "stand alone", and not normally require reference to the vCard specification.
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]

* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)

* {{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.
*#** 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).

* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.

* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code><abbr title="[MiddleName]" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code><abbr class="honorific-suffix" title="Junior">Jr.</abbr></code> etc.
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:
<pre><nowiki>
<span class="adr">
<span class="type">work</span>:
...
</span>
</nowiki></pre>
<pre><nowiki>
<span class="tel">
<span class="type">work</span>:
<span class="value">123.456.7890</span>
</span>
</nowiki></pre>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* 2006-04-06 raised by [[User:Evan|Evan]].
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki><span class="category">food</span></nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)

* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''

* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)

* 2006-02-19 raised by Miika Mäkinen.
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.

* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See also [[geo-extension-elevation]].

*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''

* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.

* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).

* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJECTED VAGUE. Which implementations? And which examples?
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''

* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''
*#* A: ACCEPTED FAQ. Type value.

* 2005-07-23 raised by DanConnolly
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.
*# ''...but I find example data with class="Given-Name"''
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.
*# ''..and code that supports it [data with class="Given-Name"].''
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.

* 2005-07-22 raised by DanConnolly
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:
*#*# Set "fn" and "org" to the same value. E.g. <code><span class="fn org">W3C</span></code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code><span class="fn"></span><span class="org">W3C</span></code> or
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code>
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.

=== Canonical/Authoritative Hcard ===

* {{OpenIssue}} 2006-01-23 raised by David Janes (?).
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].
** Other suggestions? "authoritative", "canonical"?
** Problems with this suggestion?
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a ''claim'' by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use ''this'' hCard as the one true source of this individual's contact information.
*** To summarize: authentication/trust is a separate topic.
** What exactly is the scope of the problem to solve here?
*** (IRC) (10:47:44) sreynen: for example, all of the examples I've seen involve a single person publishing multiple hCards of himself
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?
** "me" (and, depending on usage, "self") are not appropriate for content referring to third- parties. [[User:AndyMabbett|Andy Mabbett]]
''TODO:'' please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.

* 2007-03-28 raised by [[User:JamesCraig|James Craig]]
*#[[internationalization|Internationalization]] (i18n) issue for implied optimization of FN. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.
*#* ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.

== Closed Issues ==
Resolved issues that have no further actions to take.

* ...

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

vcard-implementations

2007-06-28T20:30:44Z

MikeKaply: /* Contributors */

<h1> vCard implementations </h1>

In the development of [[hcard|hCard]] and proxies like X2V, we have discovered various behaviors and quirks of vCard implementations. See also the [[vcard-errata]].

__TOC__

== Contributors==
* Tantek Çelik
* Brian Suda
* Steve Robillard

== Microsoft Outlook ==

version? platform?

=== single import ===
Outlook (either 2003 or 2007 beta version) appears to only support one vCard per VCF. There are some
third-party products that attempt to fix this [http://www.sperrysoftware.com/Outlook/Vcard-Converter.asp]

=== URL handling ===

URL without non-standard TYPE parameter seems to be ignored.

=== ADR handling ===

Appears to not support the post-office-box sub-property of ADR.

=== Escaped Commas ===

Outlook 2003 does not strip the backslashes from escaped commas (i.e., SR-PS\, Inc.) on import.

=== Microsoft Outlook 2003 ===

The following was verified on Outlook 2003 SP2 running on Windows XP Pro SP2

==== URL ====

URL is changed to URL;HOME: and is not visible anywhere normally in Outlook. It is visible in the Contact Properties window under the "All Fields" when selecting "Frequently-used fields" from the "Select from:" drop-down box. It is also exported when exporting as a vCard.

==== ADR ====

ADR; is changed to ADR;POSTAL:

ADR; is copied to LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE: with city/state/zip changed to use carriage return and comma seperation. IE:
<pre>ADR;CHARSET=utf-8:;;address1;city;state;zip;</pre>
is changed to:
<pre>ADR;POSTAL:;;address1;city;state;zip
LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:address1=0D=0Acity, state zip</pre>

==== N ====

When exporting a vCard, copies FN into N when N is blank. Does not do this when importing a vCard.

Outlook 2003 does not handle comma separation in the properties of N. For this vCard.

<pre>
BEGIN:VCARD
FN;CHARSET=UTF-8:Mr. Dr. John Maurice Benjamin Doe Ph.D.\, J.D.
N;CHARSET=UTF-8:Doe;John;Maurice,Benjamin;Mr.,Dr.;Ph.D.,J.D.
END:VCARD
</pre>

The result in Outlook is:

Mr.,Dr. Mr. Dr. John Maurice Benjamin Doe Ph.D.\, J.D.

==== TEL ====

Drops TEL if TYPE is not specified.

TEL;TYPE=work: is changed to TEL;WORK;VOICE:

==== GEO (lack of support) ====

GEO is dropped.

==== LOGO (lack of support) ====

Will not import or export vCard image references, but does support images internally in it's own contact management system.

== Windows Address Book (WAB) ==
Version 6.00.X Win98 and Win XP Pro

=== vCard ENCODING ===
UTF-8 encoded vCard import prompts error as unrecognised vCard format. US ASCII 20127 encoded vCard successfully imported

=== ADR ===
If you do NOT specify TYPE=HOME,WORK,... then no address information is imported

=== TEL ===
If you do NOT specify TYPE=HOME,WORK,... then no address information is imported

=== PHOTO ===
Does not support Images

=== NOTE ===
According to the example in the RFC spec, all commas should be escaped, but WAB does not Un-escape them, leaving \, in the notes field.

== Microsoft Entourage ==

On Mac OS X. Entourage versions 10 and 11.

=== general comments ===
* Entourage versions 10 and 11 export vCard files as UTF-16, big endian, with Mac classic line endings (a single CR). The file does contain the proper UTF-16 BE BOM at the start, making identification of the file contents simpler.

* Importing vCards: Entourage 11 will look for a BOM when importing a vCard file. It respects UTF-16 BE, UTF-16 LE, and UTF-8 BOMs. With no BOM, Entourage 11 will attempt to import the vCard file as an 8-bit stream using the current system encoding (for example, Mac Roman).

* Entourage 12 (under development) is expected to have better vCard standard conformance, exporting vCard files as UTF-8 (with individual fields properly labelled with "charset=utf-8") and using Windows (CR+LF) line endings. When importing vCard files without a BOM, it wil assume UTF-8 encoding but will respect "charset=" tags if present.

== Apple Address Book ==

On Mac OS X 10.3 (Panther) and 10.4 (Tiger).

=== general comments ===
* There are issues with importing UTF-8 vCards. Apple Address Book appears to treat .vcf files in the file system NOT as UTF-8, but rather perhaps Mac Roman?
** Workaround: Explicitly specify the UTF-8 charset for vCard properties/fields that have non-ASCII-7 characters.
* Importing multiple vCards with the same fn/n results in duplicate entries in the Address Book. Basically, Address Book assumes that every vCard present in a single .vcf file represents a different person, even if the fn/n are the same etc.
** Workarounds:
*** Only markup one hCard per person, per page (has potential implications for [[hresume|hResume]]).
*** Have the converting application/service (e.g. X2V), do automerging of hCards with the same fn/n and generate a .vcf stream with one vCard per unique fn/n.
* Apple Address Book 4.0.4 (Mac OS X 10.4) exports vCard files as UTF-16 big endian with no BOM and Mac (CR) line endings, if the vCard record contains any non-ASCII data (for example Japanese characters). If the entire vCard record can be represented in ASCII, it is exported as an ASCII encoded file with Windows (CR+LF) line endings.

=== organization vs. individual ===

Summary: FN==ORG organization semantic supported for both import and export.

For organization contact info, sets the FN and ORG to the name of the organization and N to empty on exported vCards.

Also treats imported vCards like that as organization contact info cards visibly in the UI.

=== geo (lack of support) ===

The GEO field is ignored on imported vCards. It is only saved as part of the NOTE.

=== source (lack of support) ===

The SOURCE property is not supported on imported vCards. It is only saved as part of the NOTE.

=== logo (lack of support) ===

The LOGO property is totally ignored and not even saved as part of the NOTE.

=== photo (limitations) ===

The PHOTO property can only take inline encoded data. URL values for are ignored.

=== url (limitations) ===

Only ONE URL property value is supported (whereas multiple *should* be supported, just like EMAIL).

=== adr (behaviour) ===

If you do NOT specify which type of address information it is (like HOME or WORK) it is assumed to be a WORK address.

=== categories (behaviour) ===

Behavior confirmed on versions:
* default on OSX.3
* Version 4.03 (483) on OSX.

Summary: Exports native "Groups" as vCard CATEGORIES. Ignores CATEGORIES field when importing a vCard.

The UI lets you create distinct "Groups" which you can then drag contacts into. Contacts can be in more than one group. Upon exporting a contact that is in one or more Groups, those Groups are listed in the CATEGORIES field.

However, when importing vCards, the CATEGORIES field is totally ignored by Address Book.
# It does not add vCards with a category that matches a current Group to that Group.
# It does not create new Groups for vCards with new categories.
# It does not even add the CATEGORIES to the end of the notes field.
Though presumably it SHOULD do #1 and #2. Would also be nice if it simply let you edit the groups/categories for a contact simply as a list of tags for that contact.

== Evolution ==

On Linux.

=== geo (lack of support) ===

* ichigo, Frederic to fill in details

== Nokia series 60 address book ==

=== Line endings ===

The Contacts application on Nokia series 60 handsets will only open vCards with Windows (\r\n) line endings. Any other line ending styles will cause an error message.

This is actually reasonable behaviour because the vCard spec explicitly states \r\n should be used, but many applications will accept \n delimited vCards without complaint, and may microformat services produce \n delimited output.

== Palm Desktop 4.1.4 ==

=== vCard import ===

Palm Desktop 4.1.4 appears to fail importing a vcard if it has a NAME specified in the vcard.

hatom-issues

2007-06-20T17:42:17Z

MikeKaply: /* Feed <i>updated</i> (atom:<i>updated</i>) */

__TOC__

= hAtom 0.2 =

== atom:category scheme ==

* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''rel-tag tagspaces should map to atom:category schemes''
*#* hAtom already defines how to map term and label. It seems that the tagspace can easily map to scheme

==Geo==
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

== Relationship of rel-bookmark to url+uid ==
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the hCard and hCalendar permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

== Datetime format (atom:<i>updated</i> and atom:<i>published</i>) ==
* 2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]
** Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
*** ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use

== Feed <i>id</i> (atom:<i>id</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to. The Feed permalink should be used as the feed ID.

== Feed <i>permalink</i> (atom:<i>permalink</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>
** I'm proposing the following rules:
**# a Feed Permalink element is identified by [[rel-bookmark]] at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
**# a Feed Permalink element represents the concept of an Atom link in a feed.
**# if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI
** 2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
** 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
** 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
*** "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
*** IMO this would be good enough for at least 80% of the cases.
** 2006-04-12 [[User:DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.
** [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

== Feed <i>updated</i> (atom:<i>updated</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# The Feed Updated element is identified by the class name <code>updated</code> at the feed level (inside a Feed element but not inside an Entry element)
**# If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.
** 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"
** 2007-06-20 [[User:MikeKaply]] The "youngest" thing is a really bad idea. If a page has 100 hAtom entries, a parser would have to go through all 100 looking for a low date. That's crazy.

== Feed <i>title</i> (atom:<i>title</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
**# a Feed SHOULD have an Feed Title
**# a Feed Title element represents the concept of an Atom feed title
**# if the Feed Title is missing, use
**#* <del>the first <code><h#></code> element in the Feed, or</del>
**#* the <code><title></code> of the page, or
**#* assume it is the empty string
** 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.
** 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings
** 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?
** 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
** 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

== Feed <i>author</i> and Entry author (atom:<i>author</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules for Feed author:
**# a Feed Author element is represented by class name <code>author</code> at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed Author element represents the concept of a Atom author
**# a Feed Author element MUST be encoded in a [[hcard|hCard]]
**# a Feed Author element SHOULD be encoded in a <code><address></code> element
**# a Feed MAY have more than one Feed Author elements
**# if the Feed Author is missing
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>
** I'm proposing the following rules for entry author:
**# an Entry Author element is represented by class name <code>author</code>
**# an Entry Author element represents the concept of an Atom author
**# an Entry Author element MUST be encoded in an [[hcard|hCard]]
**# an Entry Author element SHOULD be encoded in an <code><address></code> element
**#<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
**# <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise the Entry is invalid hAtom</ins>
**# an Entry MAY have more than one Entry Author elements
** [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
** 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

== Entry <i>id</i> (atom:<i>id</i>) ==
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
** --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
** 2006-12-31 response by [[User:ComputerKid|Emanla Eraton]] No, it shouldn't be a permalink. It should be a "tag:" id for entries.
** 2007-06-06 [[RyanKing]] - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [http://www.w3.org/TR/html401/types.html#type-name], while tag URIs require them [http://www.faqs.org/rfcs/rfc4151.html].

== Author ==

=== author as an hcard is too much to require ===

The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>

== Other Questions and Issues ==

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Required? -- Blogger Issue ===

moved to [[hatom-brainstorming]]

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===

moved to [[hatom-brainstorming]]

= pre 0.1 issues =

'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])'''

=== Initial proposal ===

<code>atomfeed</code> (or rather, "atom-entry")

* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** hfeed

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

* <code>feed</code> (Atom consistency)
* <code>atom-feed</code> (Atom consistency with prefix)
* <code>hfeed</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 MarkRickerby
** +1 DannyAyers

==== Discussion ====

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Initial Proposal ===

<code>atomentry</code> (or rather, "atom-entry")

* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[DavidJanes]]
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[MarkRickerby]]
** +1 [[DannyAyers]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p>

== Entry Title (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''

=== proposals ===

The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[Tantek]]
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[BenjaminCarlyle]], atom:entry/title only
** +½ [[DavidJanes]], atom:entry/title only
** +½ [[PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[DavidJanes]] see my note below
** -1 [[Tantek]] (does not mean the "name" of the post/entry)
** +1 [[BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==

'''STATUS - RESOLVED going with entry-content'''

* <code>content</code> (Atom consistency)
** -1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
** -1 KevinMarks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 KevinMarks
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[Tantek]]
** +1 KevinMarks
** +1 [[ChrisCasciano]]
* <code>atom-content</code>
** +0.5 [[Tantek]]
* <code>hcontent</code>
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.

=== Discussion ===
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')

== Entry Summary (atom:summary) ==

'''STATUS - RESOLVED - going with 'entry-summary''''

The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 KevinMarks
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs

=== Discussion ===
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

* <code>rel="bookmark"</code> (HTML consitency)
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 KevinMarks

=== Discussion ===
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

== Entry Published (atom:published) ==

'''STATUS - RESOLVED TENTATIVE - 'updated' '''

* <code>published</code> (Atom consistency)
** +0.5 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>VJOURNAL CREATED</code>

=== Discussion ===
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Updated (atom:updated) ==

'''STATUS - RESOLVED - 'updated''''

* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +½ Paul Bryson, Not as human readable
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
go back throught [[blog-post-examples]] to see what conventions we have.
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Author (atom:author) ==

'''STATUS - RESOLVED - 'author' required, should use <code><address></code>'''

* <code>author</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]

=== Discussion ===
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is <address> not sufficient for 'author' semantics?
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what <address> implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].

== Entry Contributor (atom:contributor) ==
** -1 Tantek (see Discussion)
* <code>contributor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

=== Discussion ===
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''

== Entry Geo (geo:Point) ==
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

=== GeoRSS Resources ===
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions and Comments ==

=== Limitations ===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

=== Relationship to hReview definitions needs clarification ===
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

[[Tantek]]: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

=== hCards ===

[[DavidJanes]]: Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

RESOLVED: MUST use hCard for author.

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>

=== Comparisons ===

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--[[Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

=== Repeated Elements ===
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].

Your thoughts please... -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.

=== Opaqueness ===
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.

==== Opaqueness of other microformat elements ====
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- [[BenjaminCarlyle]]

* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.

==== Opaqueness of summary and content ====
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

=== Identification ===
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

=== HTML Title ===
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

=== rel-tag ===
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]

* [[Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

=== Excess disambiguation rules? ===
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

=== Dependencies ===
==== mfo ====
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples]].

=== Is atom:content necessary? ===
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

=== Published as default value for atom:updated ===
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.
: + 1 [[User:RobertBachmann|Robert Bachmann]]

=== Designating the page author ===

(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

* How do I designate the page author(s)?
** <code>class="author"</code> outside of the hAtom entry?
** <code><address class="author"></code> outside of the hAtom entry?
** <code><address></code> outside of the hAtom feed (i.e. at the page level)?
* How do I designate the feed author(s)?

(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.

==== Proposal ====
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.

= See Also =
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

= Template =

Please use this format (copy and paste this to the end of the list to add your issues):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

rel-tag-faq

2007-06-06T18:07:03Z

MikeKaply: /* rel-tag frequently asked questions */

= rel-tag frequently asked questions =

This document serves to answer and discuss frequently asked questions specifically about the [[rel-tag]] microformat. You may want to read the [[rel-faq]] first as it answers many common questions about the HTML4 "rel" and "rev" attributes, and their linktype values. If you have a new question to ask, first consider asking on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss list].

== Q&A ==

# ''Where does a tagging link belong? Does the tagging link only need to appear in my Web feed (RSS / Atom)? Does the tagging link need to appear on the page where my specific blog entry lies? Does the tagging link need to appear everywhere that I can possibly imagine?''
#* In short, tagging links belong in all the places and formats in which you published tagged content. The Web page is the primary location where users read content and where search engines index. Thus the Web page is a place where you should absolutely include your [[rel-tag]] links. To tag your blog posts, put the [[rel-tag]] links inside them, visibly. The Web feeds are simply alternate ways of publishing your blog posts, and thus should include the full content of your blog posts, [[rel-tag]] links intact.
# ''Where shouldn't I use rel-tag?''
#* rel-tag expresses a particular relationship (a) between the page you are on and (b) the target of a link. If you're not asserting this relationship, don't use rel-tag. In particular:
#** don't use rel-tag in [http://en.wikipedia.org/wiki/Tag_cloud Tag Clouds]
#** don't use rel-tag to refer to the pages http://www.technorati.com/tag/xyz, http://del.icio.us/tag/xyz, http://www.flickr.com/photos/tags/xyz/ (and so forth) if you're not asserting "this page is tagged 'xyz'"
# ''The format specifies that the tag must "come after the last / in the path". Will something like <code><nowiki>http://example.com/index.php/TAG</nowiki></code> work? Or does it have to be a "real" directory or [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite]? -- [[User:Singpolyma|singpolyma]] 23:51, 24 Jan 2006 (PST)''
#* The key is the URL. Whether that URL is generated from a database or a directory does not matter. The URL matters.
#** My question, however, was about whether that URL form ( <code><nowiki>http://example.com/index.php/TAG</nowiki></code> ) would be valid, since there is the dot in "index.php".
#*** Yes, the URL in the example is valid (or legal or conformant or whatever you want to call it to minimize confusion). The dot (period, full stop, U+002E) is free to appear in most places in a URL, even in the middle of a path-segment that is not the last path-segment. (The latest specification for URLs, "[http://gbiv.com/protocols/uri/rfc/rfc3986.html Uniform Resource Identifier (URI): Generic Syntax]", is RFC 3986.)
# ''I'm developing a web application which uses tagging, and so of course I want to use [[rel-tag]]. For this application, I want nice, clean URLs. I was planning to use [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map a clean URL onto my underlying scripts. How do I use Apache's [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map <code><nowiki>http://example.org/~user/app/tag/car</nowiki></code> to <code><nowiki>http://example.org/~user/app/script.php?tag=car</nowiki></code> ?''
#* One solution involves changing the script to inspect the path for the tag (via the variable "PATH_INFO"), rather than inspecting the query:
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/([^/]+)$ script.php/$1 [last]
</Directory></nowiki></pre>
#* For people who can edit the server's main configuration file, the following untested configuration code may work. Corrections are welcome.
<pre><nowiki>RewriteEngine On
RewriteMap tag int:escape
RewriteRule ^/~user/app/tag/([^/]+)$ /~user/app/script.php?tag=${tag:$1} [last]</nowiki></pre>
#* The following configuration code, left over from a previous contribution to this document, does a poor job according to tests. The following code fails to enforce the [[rel-tag]] rules about the tag corresponding to the last non-empty path-segment. The following code fails to transcode the tag for safe use in the URL query. Consider that a request on <code><nowiki>http://example.org/~user/app/tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/not-a-tag/the-tag</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=not-a-tag/the-tag</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/the-tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=the-tag/</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/attack&intent=destroy</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=attack&intent=destroy</nowiki></code> .
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/(.*)$ script.php?tag=$1
</Directory></nowiki></pre>
<ol start="4">
<li>''Does a rel tag still have meaning if the link redirects? If the HTTP server returns a 302 status code, does the rel-tag have meaning? Is there a formal rule that indexers should follow the link to the final, resolved destination? Or is there a formal rule that a rel tag should be ignored if URL of its link does not return a status code of 200?''
* ..next answer
</li>
</ol>

===CSS selector===
*How do you write a CSS selector for rel-tag?
** <code>a[rel~="tag"] { color: green }</code>

===Are tags case sensitive?===
*Are tags case sensitive. Is "Dog" the same tag as "dog" and "DOG"?
**{{AwaitingAnswer}}

===Multi-word tags===
*How should a multi-word tag be made? For instance, if using Wikipedia as a name space, a page about a Black Redstart (a bird) would be tagged '''Black_Redstart''', with an underscore [http://en.wikipedia.org/wiki/Black_Redstart]. Is there any way of aliasing alternatives ("BlackRedstart", "Black-Redstart", etc.)? Is any particular format preferable?
** Existing bevavior
*** delicious supports combined tags
*** flickr supports multi-word tags with spaces but collapses spaces when searching
*** ma.gnolia supports multi-word tags with spaces
*** technorati supports multi-word tags with spaces
**{{AwaitingAnswer}}

===Tags with file extensions===
*Is <code><a rel="tag" href="<nowiki>http://example.com/cheese.htm</nowiki>">cheese</a></code> a valid tag for "cheese"? Ditto ".asp" or ".php" variants? If not, why not?

Any file-name extension in the last path segment is part of the tag value:

*<nowiki>http://example.com/cheese.htm</nowiki> ⇒ cheese.htm
*<nowiki>http://example.com/cheese.asp</nowiki> ⇒ cheese.asp
*<nowiki>http://example.com/cheese.php</nowiki> ⇒ cheese.php

The [[rel-tag|rel-tag specification]] is clear on how to extract a tag from a URL. Special treatment for file-name extensions is not part of the extraction. Brian Suda gave an [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008538.html explanation on the microformats-discuss list]. Consider the following URLs, the tags that the following URLs give under the current specification, and the effect of requiring special treatment for file-name extensions on the tags that the following URLs give.

*http://en.wikipedia.org/wiki/.htaccess
*http://en.wikipedia.org/wiki/.Net
*http://en.wikipedia.org/wiki/India.Arie
*http://en.wikipedia.org/wiki/ASN.1
*[http://en.wikipedia.org/wiki/L.I.E. http://en.wikipedia.org/wiki/L.I.E.]

===What about Scope?===
Since rel-tag is a feature used in many other microformats, the question often arises: "What is the scope of the tag?" For instance, a rel-tag may appear inside of an [[xfolk xFolk]] entry and on first glance it may appear that the tag should only apply to that entry. However, current publishing practice seems to indicate anything appearing on a page is likely related to the content of the page. Therefore, the interpretation is that not only does the rel-tag apply its direct container but to all containers and to the document as a whole; it contains the xFolk entry. This is a departure from strict knowledge theory in favor of real-world usage.

As another example, you may link to your friend Joe with XFN and hCard, indicating in his categories that Joe is interested in swimming, which you loathe. Since the article is primarily about you and not about Joe's hobbies and because the rel-tag is inside an hCard, you may expect that the rel-tag does not apply to the document; however, the document does contain information about swimming, albeit tiny, namely that your friend likes it. In this way, rel-tag is binary: it indicates direction (yes or no) but not magnitude. This equivalent to a free-text search sans [[http://en.wikipedia.org/wiki/tf-idf tf-idf]]; i.e. without a notion of term relevance.

The upshot of this is that rel-tags can have downward scope but not upward scope.

===Encoding and decoding the tag text in JavaScript===
If you want to get the text of the tag using JavaScript, you should use decodeURIComponent() to get a text representation of the tag, not escape. decodeURIComponent will properly handle UTF-8.

==Related pages==
{{rel-tag-related-pages}}
**{{AwaitingAnswer}}

rel-values-issues

2007-06-06T16:03:53Z

MikeKaply: /* Issues */

= rel Issues =

These are externally raised issues about the general use of rel with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well.

== Issues ==

Please use this format:
* {{OpenIssue}} YYYY-MM-DD raised by AUTHORNAME
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

* {{OpenIssue}} 2007-06-06 raised by [[MikeKaply|Mike Kaply]]
*# ''Are the rel microformats only valid on anchor tags (<A>)?''

==Related pages==
[[rel-tag-issues]]

rel-values-issues

2007-06-06T16:02:53Z

MikeKaply: /* Related pages */

rel-values-issues

2007-06-06T16:00:57Z

MikeKaply:

hcalendar-examples-in-wild

2007-04-04T21:05:18Z

MikeKaply: /* New Examples */

<h1>hCalendar Examples in the wild</h1>

This page is an '''informative''' section of the [[hcalendar|hCalendar specification]].

The following sites have published events using [[hcalendar|hCalendar]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc.

If events on your site are marked up with hCalendar, feel free to add it to the top of this list. Please be sure to include at least one URL of a page on your site that includes actual [[hcalendar|hCalendar]] markup. Examples added without the URL of a page with hCalendar markup may be removed.

Want to get started with writing an [[hcalendar|hCalendar]] event? Use the [http://microformats.org/code/hcalendar/creator hCalendar creator] to write up an event and publish it, or follow the [[hcalendar-authoring|hCalendar authoring tips]] to add hCalendar markup to your page of upcoming events or events you mention in blog posts, wikis, etc.

Don't forget that you can add one of our [[buttons#hCalendar|buttons]] to the page, to indicate the presence of hCalendar microformats. For example: http://www.boogdesign.com/images/buttons/microformat_hcalendar.png. If you can link it back to [[hcalendar|hCalendar]] (or even page on your website, about your use of the microformat), so much the better!

==New Examples==

Please add new examples to the '''top''' of this section.
* [http://last.fm last.fm] - uses hCalendar on all concert announcements.
** Example here: [http://www.last.fm/event/75615 Rise Against at Arena, Wien]
* [http://www.radiotimes.com Radio Times] - now mark up all their radio and TV listings.
**The hCals on listings are good, but on pages for individual programmes, they have no date/times - for instance [http://www.radiotimes.com/ListingsServlet?event=10&channelId=56&programmeId=57876521&jspLocation=/jsp/prog_details_fullpage.jsp]
** Would benefit from using [[include-pattern]] for channel name in main listings. This would facilitate the writing of parsers to set audio or video recording software. [[User:AndyMabbett|Andy Mabbett]]
* [http://nederlandskamerkoor.nl Dutch Chamber Choir] uses hCalendar to notify visitors of their tour schedule.
* [http://cloudislands.com Cloud Islands] uses hCalendar to notify our customers about the conferences we'll be attending.
* [http://www.international.unt.edu UNT International] uses hCalendar for events (see esp. [http://www.international.unt.edu/offices/welcome/events/intlweek/calendar International Week 2007 Event Calendar])
* [http://www.rockisland.com/%7elopezmuseum/index.html The Lopez Island Historical Society and Museum] uses hCalendar for events
* [http://futureofwebapps.com/schedule.html Future of Web Apps London] lists its schedule in hcalendar.
* [http://leicesteryha.org.uk/cgi-bin/leoprog Leicester YHA Group's programme page] uses hCalendar and hCard to mark up forthcoming events and their organisers.
* [http://www.wadip.org.uk/pages/events.php Wadhurst Independent Photography events] lists forthcoming events in hCalendar format.
* [http://xlntads.com/about-xlntads/development-schedule.php XLNTads-development schedule] has their project development schedule timeline marked up in hcal (as well as contacts in hCard)
* [http://www.jaama.co.uk Jaama] have their event details as iCal downloads on their [http://www.jaama.co.uk/HS_Seminars.aspx workshops] page.
* [http://3amproductions.net 3AM Productions] has employee education ([http://3amproductions.net/jason.php Jason], [http://3amproductions.net/gilbert.php Gilbert]) marked up in hCalendar
* The [http://neatta.org New England Antique Tractor & Truck Association] (of all sites) has their 15 upcoming events marked up in hCalendar (as well as contacts in hCard and classifieds in hListing)
* [http://diarised.com Diarised] is a quick and simple online tool to help pick the best time for a meeting, uses hCalendar for meeting information.
* [http://etnies.com/ etnies.com] uses hCalendar on each sports home page ([http://etniesskate.com/ etniesskate.com]) and the [http://etnies.com/extra/calendar/ calendar of events] page.
* [http://www.mdas.org/ La maison des associations de Strasbourg] uses hCalendar on event pages.
* [http://nuggetshoops.com/schedule.php NuggetsHoops] , an NBA fansite, uses hCalendar for each remaining game in the current season.
* [http://wikevent.org WikEvent] aims to make it as easy as possible to put events on the web with semantic markup, including hCalendar for events and hCard for venues and artists.
* [http://fundyfilm.ca/calendar/ The Fundy Film Society] uses hCalendar for their calendar of upcoming film screenings.
* Psychology Press and Routledge's Behavioral Sciences' publishing division have implemented hCalendar on their conferences listings on 17 of their websites (example on the conference listing on their [http://www.clinicalpsychologyarena.com/resources/conferences.asp Clinical Psychology Arena])
* [http://jhtc.org Jewish High Tech Community] uses hCalendar on event pages.
*[http://www.gore-tex.com/remote/Satellite?c=fabrics_content_c&cid=1162322807952&pagename=goretex_en_US%2Ffabrics_content_c%2FKnowWhatsInsideDetail Gore-Tex "Know What's Inside"] tour dates in hCalendar by [http://microformats.org/wiki/User:Csarven csarven]
* [http://finetoothcog.com/site/stolen_bikes Finetoothcog] uses hCalendar to markup when bikes are stolen.
* [https://www.urbanbody.com/information/contact-us Urban Body Men's Clothing] uses hCalendar for business hours and hCard for business locations.
* [http://www.infoiasi.ro The website of the Faculty of Computer Science], "A. I. Cuza" University Iaşi, Romania, uses hCalendar to markup events.
* [http://www.crosbyheritage.co.uk/events/ Colin Crosby Heritage Tours] uses hCalendar to markup events.
* [http://www.facebook.com Facebook] use hCalendar to markup events.
* [http://www.newbury-college.ac.uk/ Newbury College UK] uses a smattering of hCalendar and hCard
* [http://07.pagesd.info/ardeche/agenda.aspx 07.pagesd.info] uses hCalendar and hCard to mark up events of the Ardèche département in France.
* [http://climbtothestars.org Stephanie Booth] announced the [http://climbtothestars.org/archives/2006/09/14/microformats-et-bloggy-friday-doctobre/ Bloggy Friday for October 2006] using hCalendar.
* The [http://www.westmidlandbirdclub.com/ West Midland Bird Club], in the English Midlands, uses hCal (with nested hCard) on its [http://www.westmidlandbirdclub.com/diary/ diary of birding events].
* [http://www.comtec-ars.com/press-releases/ ComTec audience response systems' press releases] use hCalendar as a method to organize by title and date.
* [http://webdirections.org/program/ The Web Directions Conference (Sydney Australia)] uses hCalendar for their program. It uses axis and headers for events in a table, and demonstrates how easy it is to make the whole thing downloadable using X2V.
* [http://www.thestreet.org.au/ The Street Theatre (Canberra, Australia)] now uses hCalendar for performances on its [http://www.thestreet.org.au/whats_on.htm What's On] page.
* [http://www.clacksweb.org.uk Clackmannanshire Council] uses hCalendar on its [http://www.clacksweb.org.uk/community/events/ event diary] listing pages and individual event pages.
* [http://www.markthisdate.com/ Calendarportal MarkThisDate.com] now uses hCalendar for all calendars. On our website visitors can add calendars and download calendars to Outlook, Lotus Notes, iCal, Netvibes, 30Boxes, Google Calendar and many others. Over 600 calendars were already uploaded.
* [http://mogue.jp/ mogue] uses hCalendar at [http://mogue.jp/event/1000/ event detail] pages.
* [http://www.gustavus.edu/events/nobelconference/2006/schedule.cfm 2006 Nobel Conference] uses hCalendar for the conference schedule
* [http://www.geekinthepark.co.uk Geek in the Park] uses hCalendar for the event information. -- by [[User:Trovster|trovster]]
* [http://www.besancon.fr/ official site of Besançon (France)] for its events
* [http://2006.dconstruct.org/schedule/ Conference schedule for d.Construct 2006] is published using hCalendar.
* [http://local.yahoo.com Yahoo Local] now supports hCalendar
* We used hcalendar for the [http://www.fuckparade.org/flyer/2006/ F’parade flyer 2006], a counter demonstration to the Love Parade in Berlin, alas the '''Firefox tails extension''' doesn't get a summary when it's an alt-text in an image.
* [http://www.harper-adams.ac.uk/press/events.cfm Harper Adams University College] uses hCalendar to mark up all University events on the Homepage and Events Calendar page.
* [http://www.capital.edu/ Capital University] uses hCalendar on multiple pages to provide feeds of events, relevant to page content
* [http://www.thesession.org/events/ The Session events] uses hCalendar to mark up concerts, festivals and workshops related to Irish traditional music.
* [http://rubyandrails.org/usergroups/newcastle ncl.rb] uses hCalendar to mark up new meetings.
* [http://gross.org.za/calendar GROSSUG Calendar] - Uses hCalendar to mark up meetings and other events.
* [http://www.webanalyticsassociation.org/en/calendarevents/search.asp Web Analytics Association] - hCalendar microformat is in place on all Tendenci sites on the calendar events search page and consolidated list page.
* [http://www.tendenci.com/en/calendarevents/search.asp Tendenci Calendar Events] with hCalendar
* [http://www.argolon.com/2006/04/17/web20-conference-in-dublin/ Web2.0 Conference in Dublin] hCalendar event
* [http://www.meetup.com/ Meetup.com] has marked up [http://www.meetup.com/cities/us/ny/new_york city event calendars], [http://photo.meetup.com/100/events/ group event lists], and [http://www.meetup.com/ signed-in homepages] with hCalendar.
* [http://ukwindsurfing.com/ ukwindsurfing.com] has marked upcoming events with hCalendar, and the [http://ukwindsurfing.com/events/ events page] in a table.
* [http://ocono.com/ ocono.com] has marked up it's "Upcoming Events" list with hCalendar.
* [http://www.austinbloggers.org/ Austin Bloggers] has marked up their "Upcoming Events" box with hCalendar ([http://www.austinbloggers.org/blog/a/001123.html announcement]).
* Ning's cloneable Group app has [[hcalendar|hCalendar]] markup on its [http://group.ning.com/index.php?controller=event&action=list event calendar] and [http://group.ning.com/index.php?controller=event&action=view&id=727220 event detail] pages.
* [http://tantek.com/microformats/2006/03-01-TechPlenAgenda.html Agenda: W3C Technical Plenary Day, March 1 2006] has [[hcard|hCard]] and [[hcalendar|hCalendar]] markup. ([http://www.w3.org/2006/03/01-TechPlenAgenda.html original here]).
* The National Arbor Day Foundation has started using hCalendars for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].
* [http://www.stateofflux.com/ State of Flux street art site] has started adding events in hCalendar format
* The [http://barcamp.org/#BarCamps BarCamp home page lists upcoming BarCamps marked up with hCalendar] and even has a "Subscribe..." link.
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the schedule and events for the week with hCalendar.
* [http://www.code4lib.org/2006/schedule code4lib Conference 2006 Schedule] is marked up with hCalendar as [http://www.code4lib.org/node/65 announced on their blog].
* [http://grouper.ieee.org/groups/754 IEEE 754 Working Group] - trying hCalendar for upcoming meetings.
* [http://www.pehuen.org/node/494 Elecciones 2005 Chile] - the first spanish language hCalendar event found in the wild.
* [http://www.codewitch.org/it/2005/11/17/no-creative-commons-no-party/ Giocolando » No Creative Commons? No Party!] is marked up with hCalendar
* [http://www.cmprofessionals.org/events/calendar.html CM Pros Events Calendar] by Bob Doyle
* [http://www.midgard-project.org/community/events/ Midgard CMS Event calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius]
* [http://www.iowamilitaryveteransband.com/schedule/ Iowa Military Veterans Band Schedule] - hCalendar markup [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ added by Scott Reynen]
* [http://www.funfairgames.net/weblog/posts/00000011.html Upcoming events on Jason A.R. Moody Amusements Weblog] posted by Jason Moody on 15 Oct 2005. [http://www.funfairgames.net/weblog/index.html His weblog] in general has hCalendar events posted inside the blog posts.
* [http://tantek.com/microformats/2005/syndicate/tracks-sessions-schedule.html Syndicate - Tracks & Sessions]
* [http://tantek.com/microformats/2005/web2/program.html Web 2.0 Conference schedule page marked up with hCalendar]
* [http://www.thisiscmon.com/ C'MON] is a rock band from Canada, and their [http://www.thisiscmon.com/shows/ tour dates] have been marked up by [http://www.d2digitalmedia.com/ Ray Dickman] with hCalendar.
* [http://ifreebusy.com/ ifreebusy.com] will display freebusy information using hCalendar. See this [http://ifreebusy.com/neiljensen/freebusy/ example].
* [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.
* [http://www.asdvbonaparte.nl/ ASDV Bonaparte] is a Dutch debating society. Their events calendar has been marked up with the hCalendar conventions.
* [http://chocnvodka.blogware.com/blog Suw Charman] has marked up [http://suw.org.uk/archives/category/events/ her events] with hCalendar.
* [http://www.blogbusinesssummit.com/ Blog Business Summit] has published their [http://www.blogbusinesssummit.com/details.htm event details] marked up with hCalendar.
* [http://eventful.com Eventful.com] publishes all events with hCalendar and venues with [[hcard|hCard]]. Took them only 15 minutes to implement both! Their Atom feeds also contain hCalendar/hCard.
* [http://upcoming.org Upcoming.org] publishes all events and lists of events with hCalendar. Took them only an hour to add hCalendar support to the site.
** The dtend values for events with no time specified (like [http://upcoming.org/event/110145/ | Burning Man] are not exclusive. This causes problems when sending the microformats info to places like Google. They do correct the dtend when exporting to Outlook though. They have been made aware of the problem.
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events, [http://laughingsquid.com/squidlist/calendar/9949/2005/5/9 e.g. this party], now supports hCalendar.
* [http://paulschreiber.com/ Paul] Schreiber's [http://concerts.shrub.ca/ Sunnyvale House Concerts] site publishes hCalendar event information for upcoming concerts. In addition the [http://concerts.shrub.ca/shows Past Shows] page contains hCalendar events for all past concerts.
* [http://www.complexspiral.com/ Complex Spiral Consulting], both in the "Events" box on left side, and the separate [http://www.complexspiral.com/events/ Events page].
* [http://tantek.com/log Tantek's Thoughts], specifically the "Events" roll in the right-most column.
* [http://suda.co.uk/projects/holidays/ Lesser Known Holidays], a list of holidays on [http://suda.co.uk suda.co.uk] that can be imported via iCal and hCal so you can compare actual transformation versus intended.
* [http://norman.walsh.name/2005/itinerary/ Norm Walsh's travel schedule] use hCalendar as well as GRDDL.
* [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting] uses hCalendar to record date-related decisions, and uses a vtodo microformat to record action items.
* The [http://lufgi4.informatik.rwth-aachen.de Laboratory for Dependable Distributed Systems] publishes it's [http://lufgi4.informatik.rwth-aachen.de/cfps list of notable CfPs on dependability and security] with hCalendar-todo elements.
* The [http://laughingsquid.com/laughing-squid-10th-anniversary-party/ Laughing Squid 10th Anniversary Party] has an hcalendar page.
* SPRACI has hcalendar versions of its nightlife/clubbing/gigs/festivals listings for many cities worldwide - eg: [http://www.spraci.com/listhcalendar.php?parea=sydney&category=all Events in Sydney] (check the [http://www.spraci.com/api/ API] pages in the faq section of [http://www.spraci.com/ SPRACI] for more info about the area/city keywords and category tags to use to get data for your city/categories
* WWF-Australia events calendars: [http://wwf.org.au/act/events/ What's on], [http://wwf.org.au/act/volunteer/ Volunteer]
* [http://rubyholic.com rubyholic] uses hCalendar to publish calendars for ruby groups.
* [http://www.bath.ac.uk/whats-on/ University of Bath What's On] uses hCalendar on individual event pages
* The [http://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm program] marked up with hCalendar

===World Cup Kick-off===
* [http://www.worldcupkickoff.com/ World Cup KickOff] where you can download and keep all the fixtures you are interested in so you will never miss a single game of the 2006 football World Cup!
** This link was on the [http://www.lifehacker.com/software/sports/world-cup-start-times-for-ical-etc-175393.php Lifehackers site] and made its way to the yahoo news site:

<blockquote>
Mon May 22, 4:00 PM ET
The World Cup, one of the world's most watched sporting events, is almost upon us. If you've ever tried to follow your favorite team through the Cup you know that it can sometimes be difficult to know when they're on. World Cup Kickoff can help.

World Cup KickOff is all you will ever need for knowing all the match details for the upcoming World Cup 2006. Whether you use your mobile phone, MS Outlook, Apple iCal or Mozilla Calendar, you can download and keep all the fixtures you are interested in so you will never miss a single game!

Next tip? We'll show you how to get up at 2 AM to watch your matches. ;0) Thanks to Tom for the tip!
</blockquote>

== Examples with some problems ==
If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hcalendar | hCalendar spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hcalendar-faq| hCalendar FAQ]], or raise any queries on [[hcalendar-issues| hCalendar issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you.
* I'd be happy if some future french Pinko-marketing meetings (CantineCamp) could require the use of hCalendar for listing some informal lunches in Paris. [http://www.wikiservice.at/fractal/wikidev.cgi?FR/PinkoMarketing/CantineCampParis10 CantineCampParis10 is an example] to include a hCalendar + hCard markup on the wiki-page. When converting to vCard, "Mendès" accent is malformed in a french outlook 2003 "address book". I've looked UTF-8 example but could not find any way to correct. Any idea ? -- [[User:ChristopheDucamp|xtof]] 01:09, 26 Mar 2007 (PDT)
* [http://www.joomlamug.com Joomla! Melbourne User Group] uses hCalendar markup for listing of all events.
** No examples on cited page. [[User:AndyMabbett|Andy Mabbett]] 15:06, 31 Jan 2007 (PST)
* [http://www.webfeet.org/events.html Webfeet events] includes hCalendar markup in its aggregated events lists.
** <s>Possibly a case where <nowiki><abbr></nowiki> won't work for dtstart/dtend as there are many events listed under a single date. [[User:Webf|Webf]] 15:19, 15 Jan 2007 (PST)</s>
**Malformed e.g <code><nowiki><span class="dtstart" title="20070120"></span></nowiki></code> [[User:AndyMabbett|Andy Mabbett]] 15:41, 15 Jan 2007 (PST)
** Continue the discussion under [[hcalendar-issues|hCalendar Issues]] perhaps. [[User:Webf|Webf]] 22:25, 15 Jan 2007 (PST)
* [http://www.theatrestudies.llc.ed.ac.uk/ Theatre Studies: European Theatre] at the University of Edinburgh uses hCalendar to markup news and events on the index page.
**<s>Uses "display:none" on image. [[User:AndyMabbett|Andy Mabbett]] 15:32, 13 Nov 2006 (PST)</s> Removed img tag from hCard
* [http://www.bokle.de/ s'Bokle] is a German music pub. Their events calendar has been marked up with hCalendar.
** improper use of rrule --[[User:RyanKing|RyanKing]] 16:04, 6 Jan 2006 (PST)
* [http://plan9.tryphon.org/nancy/list Plan9] - Uses hCalendar to mark up events !
** <s>dtstart/dtend are implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006</s> --[[User:Tim|Tim]] 13:34, 4 Mar 2007 (PST) Fixed now
* [http://www.socaltech.com socalTECH] is a news and information site. Their front page event listing is marked up with hCalendar.
** dtstart/dtend implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006
* [http://www.multipack.co.uk The Multipack] features a vevent for the next meeting information.
** dtstart/dtend are implemented on em element [[User:TomArmitage|Tom Armitage]] June 23, 2006
* [http://paulschreiber.com/ Paul] Schreiber's [http://iceoasis.shrub.ca/ unofficial schedule site] publishes hCalendar information for upcoming hockey games at [http://www.iceoasis.com/ Ice Oasis]
** dtstart/dtend are implemented on td element [[User:TomArmitage|Tom Armitage]] June 23, 2006

- whilst Tails parses the "title" attribute for dtstart/dtend on <em>any</em> element (does Tails still do this?), that is incorrect. The title attribute only provides semantics for the <code><nowiki><abbr></nowiki></code> element, while for elements in general like <code><nowiki><span></nowiki></code>, only the contents of the element are used. This is a simplification and see [[hcard-parsing|hCard parsing]] for details. Technorati Microformats Search only looks for the title attribute on <code><nowiki><abbr></nowiki></code> tags per the rules from [[hcard-parsing|hCard parsing]] which apply to [[hcalendar-parsing|hCalendar parsing]] as well.

== Reviewed Examples ==
If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

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

hcalendar-examples-in-wild

2007-04-04T21:03:44Z

MikeKaply: /* New Examples */

<h1>hCalendar Examples in the wild</h1>

This page is an '''informative''' section of the [[hcalendar|hCalendar specification]].

The following sites have published events using [[hcalendar|hCalendar]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc.

If events on your site are marked up with hCalendar, feel free to add it to the top of this list. Please be sure to include at least one URL of a page on your site that includes actual [[hcalendar|hCalendar]] markup. Examples added without the URL of a page with hCalendar markup may be removed.

Want to get started with writing an [[hcalendar|hCalendar]] event? Use the [http://microformats.org/code/hcalendar/creator hCalendar creator] to write up an event and publish it, or follow the [[hcalendar-authoring|hCalendar authoring tips]] to add hCalendar markup to your page of upcoming events or events you mention in blog posts, wikis, etc.

Don't forget that you can add one of our [[buttons#hCalendar|buttons]] to the page, to indicate the presence of hCalendar microformats. For example: http://www.boogdesign.com/images/buttons/microformat_hcalendar.png. If you can link it back to [[hcalendar|hCalendar]] (or even page on your website, about your use of the microformat), so much the better!

==New Examples==

Please add new examples to the '''top''' of this section.
* [http://last.fm last.fm] - uses hCalendar on all concert announcements.
** Example here: [http://www.last.fm/event/75615 Rise Against at Arena, Wien]
* [http://www.radiotimes.com Radio Times] - now mark up all their radio and TV listings.
**The hCals on listings are good, but on pages for individual programmes, they have no date/times - for instance [http://www.radiotimes.com/ListingsServlet?event=10&channelId=56&programmeId=57876521&jspLocation=/jsp/prog_details_fullpage.jsp]
** Would benefit from using [[include-pattern]] for channel name in main listings. This would facilitate the writing of parsers to set audio or video recording software. [[User:AndyMabbett|Andy Mabbett]]
* [http://nederlandskamerkoor.nl Dutch Chamber Choir] uses hCalendar to notify visitors of their tour schedule.
* [http://cloudislands.com Cloud Islands] uses hCalendar to notify our customers about the conferences we'll be attending.
* [http://www.international.unt.edu UNT International] uses hCalendar for events (see esp. [http://www.international.unt.edu/offices/welcome/events/intlweek/calendar International Week 2007 Event Calendar])
* [http://www.rockisland.com/%7elopezmuseum/index.html The Lopez Island Historical Society and Museum] uses hCalendar for events
* [http://futureofwebapps.com/schedule.html Future of Web Apps London] lists its schedule in hcalendar.
* [http://leicesteryha.org.uk/cgi-bin/leoprog Leicester YHA Group's programme page] uses hCalendar and hCard to mark up forthcoming events and their organisers.
* [http://www.wadip.org.uk/pages/events.php Wadhurst Independent Photography events] lists forthcoming events in hCalendar format.
* [http://xlntads.com/about-xlntads/development-schedule.php XLNTads-development schedule] has their project development schedule timeline marked up in hcal (as well as contacts in hCard)
* [http://www.jaama.co.uk Jaama] have their event details as iCal downloads on their [http://www.jaama.co.uk/HS_Seminars.aspx workshops] page.
* [http://3amproductions.net 3AM Productions] has employee education ([http://3amproductions.net/jason.php Jason], [http://3amproductions.net/gilbert.php Gilbert]) marked up in hCalendar
* The [http://neatta.org New England Antique Tractor & Truck Association] (of all sites) has their 15 upcoming events marked up in hCalendar (as well as contacts in hCard and classifieds in hListing)
* [http://diarised.com Diarised] is a quick and simple online tool to help pick the best time for a meeting, uses hCalendar for meeting information.
* [http://etnies.com/ etnies.com] uses hCalendar on each sports home page ([http://etniesskate.com/ etniesskate.com]) and the [http://etnies.com/extra/calendar/ calendar of events] page.
* [http://www.mdas.org/ La maison des associations de Strasbourg] uses hCalendar on event pages.
* [http://nuggetshoops.com/schedule.php NuggetsHoops] , an NBA fansite, uses hCalendar for each remaining game in the current season.
* [http://wikevent.org WikEvent] aims to make it as easy as possible to put events on the web with semantic markup, including hCalendar for events and hCard for venues and artists.
* [http://fundyfilm.ca/calendar/ The Fundy Film Society] uses hCalendar for their calendar of upcoming film screenings.
* Psychology Press and Routledge's Behavioral Sciences' publishing division have implemented hCalendar on their conferences listings on 17 of their websites (example on the conference listing on their [http://www.clinicalpsychologyarena.com/resources/conferences.asp Clinical Psychology Arena])
* [http://jhtc.org Jewish High Tech Community] uses hCalendar on event pages.
*[http://www.gore-tex.com/remote/Satellite?c=fabrics_content_c&cid=1162322807952&pagename=goretex_en_US%2Ffabrics_content_c%2FKnowWhatsInsideDetail Gore-Tex "Know What's Inside"] tour dates in hCalendar by [http://microformats.org/wiki/User:Csarven csarven]
* [http://finetoothcog.com/site/stolen_bikes Finetoothcog] uses hCalendar to markup when bikes are stolen.
* [https://www.urbanbody.com/information/contact-us Urban Body Men's Clothing] uses hCalendar for business hours and hCard for business locations.
* [http://www.infoiasi.ro The website of the Faculty of Computer Science], "A. I. Cuza" University Iaşi, Romania, uses hCalendar to markup events.
* [http://www.crosbyheritage.co.uk/events/ Colin Crosby Heritage Tours] uses hCalendar to markup events.
* [http://www.facebook.com Facebook] use hCalendar to markup events.
* [http://www.newbury-college.ac.uk/ Newbury College UK] uses a smattering of hCalendar and hCard
* [http://07.pagesd.info/ardeche/agenda.aspx 07.pagesd.info] uses hCalendar and hCard to mark up events of the Ardèche département in France.
* [http://climbtothestars.org Stephanie Booth] announced the [http://climbtothestars.org/archives/2006/09/14/microformats-et-bloggy-friday-doctobre/ Bloggy Friday for October 2006] using hCalendar.
* The [http://www.westmidlandbirdclub.com/ West Midland Bird Club], in the English Midlands, uses hCal (with nested hCard) on its [http://www.westmidlandbirdclub.com/diary/ diary of birding events].
* [http://www.comtec-ars.com/press-releases/ ComTec audience response systems' press releases] use hCalendar as a method to organize by title and date.
* [http://webdirections.org/program/ The Web Directions Conference (Sydney Australia)] uses hCalendar for their program. It uses axis and headers for events in a table, and demonstrates how easy it is to make the whole thing downloadable using X2V.
* [http://www.thestreet.org.au/ The Street Theatre (Canberra, Australia)] now uses hCalendar for performances on its [http://www.thestreet.org.au/whats_on.htm What's On] page.
* [http://www.clacksweb.org.uk Clackmannanshire Council] uses hCalendar on its [http://www.clacksweb.org.uk/community/events/ event diary] listing pages and individual event pages.
* [http://www.markthisdate.com/ Calendarportal MarkThisDate.com] now uses hCalendar for all calendars. On our website visitors can add calendars and download calendars to Outlook, Lotus Notes, iCal, Netvibes, 30Boxes, Google Calendar and many others. Over 600 calendars were already uploaded.
* [http://mogue.jp/ mogue] uses hCalendar at [http://mogue.jp/event/1000/ event detail] pages.
* [http://www.gustavus.edu/events/nobelconference/2006/schedule.cfm 2006 Nobel Conference] uses hCalendar for the conference schedule
* [http://www.geekinthepark.co.uk Geek in the Park] uses hCalendar for the event information. -- by [[User:Trovster|trovster]]
* [http://www.besancon.fr/ official site of Besançon (France)] for its events
* [http://2006.dconstruct.org/schedule/ Conference schedule for d.Construct 2006] is published using hCalendar.
* [http://local.yahoo.com Yahoo Local] now supports hCalendar
* We used hcalendar for the [http://www.fuckparade.org/flyer/2006/ F’parade flyer 2006], a counter demonstration to the Love Parade in Berlin, alas the '''Firefox tails extension''' doesn't get a summary when it's an alt-text in an image.
* [http://www.harper-adams.ac.uk/press/events.cfm Harper Adams University College] uses hCalendar to mark up all University events on the Homepage and Events Calendar page.
* [http://www.capital.edu/ Capital University] uses hCalendar on multiple pages to provide feeds of events, relevant to page content
* [http://www.thesession.org/events/ The Session events] uses hCalendar to mark up concerts, festivals and workshops related to Irish traditional music.
* [http://rubyandrails.org/usergroups/newcastle ncl.rb] uses hCalendar to mark up new meetings.
* [http://gross.org.za/calendar GROSSUG Calendar] - Uses hCalendar to mark up meetings and other events.
* [http://www.webanalyticsassociation.org/en/calendarevents/search.asp Web Analytics Association] - hCalendar microformat is in place on all Tendenci sites on the calendar events search page and consolidated list page.
* [http://www.tendenci.com/en/calendarevents/search.asp Tendenci Calendar Events] with hCalendar
* [http://www.argolon.com/2006/04/17/web20-conference-in-dublin/ Web2.0 Conference in Dublin] hCalendar event
* [http://www.meetup.com/ Meetup.com] has marked up [http://www.meetup.com/cities/us/ny/new_york city event calendars], [http://photo.meetup.com/100/events/ group event lists], and [http://www.meetup.com/ signed-in homepages] with hCalendar.
* [http://ukwindsurfing.com/ ukwindsurfing.com] has marked upcoming events with hCalendar, and the [http://ukwindsurfing.com/events/ events page] in a table.
* [http://ocono.com/ ocono.com] has marked up it's "Upcoming Events" list with hCalendar.
* [http://www.austinbloggers.org/ Austin Bloggers] has marked up their "Upcoming Events" box with hCalendar ([http://www.austinbloggers.org/blog/a/001123.html announcement]).
* Ning's cloneable Group app has [[hcalendar|hCalendar]] markup on its [http://group.ning.com/index.php?controller=event&action=list event calendar] and [http://group.ning.com/index.php?controller=event&action=view&id=727220 event detail] pages.
* [http://tantek.com/microformats/2006/03-01-TechPlenAgenda.html Agenda: W3C Technical Plenary Day, March 1 2006] has [[hcard|hCard]] and [[hcalendar|hCalendar]] markup. ([http://www.w3.org/2006/03/01-TechPlenAgenda.html original here]).
* The National Arbor Day Foundation has started using hCalendars for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].
* [http://www.stateofflux.com/ State of Flux street art site] has started adding events in hCalendar format
* The [http://barcamp.org/#BarCamps BarCamp home page lists upcoming BarCamps marked up with hCalendar] and even has a "Subscribe..." link.
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the schedule and events for the week with hCalendar.
* [http://www.code4lib.org/2006/schedule code4lib Conference 2006 Schedule] is marked up with hCalendar as [http://www.code4lib.org/node/65 announced on their blog].
* [http://grouper.ieee.org/groups/754 IEEE 754 Working Group] - trying hCalendar for upcoming meetings.
* [http://www.pehuen.org/node/494 Elecciones 2005 Chile] - the first spanish language hCalendar event found in the wild.
* [http://www.codewitch.org/it/2005/11/17/no-creative-commons-no-party/ Giocolando » No Creative Commons? No Party!] is marked up with hCalendar
* [http://www.cmprofessionals.org/events/calendar.html CM Pros Events Calendar] by Bob Doyle
* [http://www.midgard-project.org/community/events/ Midgard CMS Event calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius]
* [http://www.iowamilitaryveteransband.com/schedule/ Iowa Military Veterans Band Schedule] - hCalendar markup [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ added by Scott Reynen]
* [http://www.funfairgames.net/weblog/posts/00000011.html Upcoming events on Jason A.R. Moody Amusements Weblog] posted by Jason Moody on 15 Oct 2005. [http://www.funfairgames.net/weblog/index./wwf.org.au/act/volunteer/ Volunteer]
* [http://rubyholic.com rubyholic] uses hCalendar to publish calendars for ruby groups.
* [http://www.bath.ac.uk/whats-on/ University of Bath What's On] uses hCalendar on individual event pages
* The [http://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm program] marked up with hCalendar

===World Cup Kick-off===
* [http://www.worldcupkickoff.com/ World Cup KickOff] where you can download and keep all the fixtures you are interested in so you will never miss a single game of the 2006 football World Cup!
** This link was on the [http://www.lifehacker.com/software/sports/world-cup-start-times-for-ical-etc-175393.php Lifehackers site] and made its way to the yahoo news site:

<blockquote>
Mon May 22, 4:00 PM ET
The World Cup, one of the world's most watched sporting events, is almost upon us. If you've ever tried to follow your favorite team through the Cup you know that it can sometimes be difficult to know when they're on. World Cup Kickoff can help.

World Cup KickOff is all you will ever need for knowing all the match details for the upcoming World Cup 2006. Whether you use your mobile phone, MS Outlook, Apple iCal or Mozilla Calendar, you can download and keep all the fixtures you are interested in so you will never miss a single game!

Next tip? We'll show you how to get up at 2 AM to watch your matches. ;0) Thanks to Tom for the tip!
</blockquote>

== Examples with some problems ==
If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hcalendar | hCalendar spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hcalendar-faq| hCalendar FAQ]], or raise any queries on [[hcalendar-issues| hCalendar issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you.
* I'd be happy if some future french Pinko-marketing meetings (CantineCamp) could require the use of hCalendar for listing some informal lunches in Paris. [http://www.wikiservice.at/fractal/wikidev.cgi?FR/PinkoMarketing/CantineCampParis10 CantineCampParis10 is an example] to include a hCalendar + hCard markup on the wiki-page. When converting to vCard, "Mendès" accent is malformed in a french outlook 2003 "address book". I've looked UTF-8 example but could not find any way to correct. Any idea ? -- [[User:ChristopheDucamp|xtof]] 01:09, 26 Mar 2007 (PDT)
* [http://www.joomlamug.com Joomla! Melbourne User Group] uses hCalendar markup for listing of all events.
** No examples on cited page. [[User:AndyMabbett|Andy Mabbett]] 15:06, 31 Jan 2007 (PST)
* [http://www.webfeet.org/events.html Webfeet events] includes hCalendar markup in its aggregated events lists.
** <s>Possibly a case where <nowiki><abbr></nowiki> won't work for dtstart/dtend as there are many events listed under a single date. [[User:Webf|Webf]] 15:19, 15 Jan 2007 (PST)</s>
**Malformed e.g <code><nowiki><span class="dtstart" title="20070120"></span></nowiki></code> [[User:AndyMabbett|Andy Mabbett]] 15:41, 15 Jan 2007 (PST)
** Continue the discussion under [[hcalendar-issues|hCalendar Issues]] perhaps. [[User:Webf|Webf]] 22:25, 15 Jan 2007 (PST)
* [http://www.theatrestudies.llc.ed.ac.uk/ Theatre Studies: European Theatre] at the University of Edinburgh uses hCalendar to markup news and events on the index page.
**<s>Uses "display:none" on image. [[User:AndyMabbett|Andy Mabbett]] 15:32, 13 Nov 2006 (PST)</s> Removed img tag from hCard
* [http://www.bokle.de/ s'Bokle] is a German music pub. Their events calendar has been marked up with hCalendar.
** improper use of rrule --[[User:RyanKing|RyanKing]] 16:04, 6 Jan 2006 (PST)
* [http://plan9.tryphon.org/nancy/list Plan9] - Uses hCalendar to mark up events !
** <s>dtstart/dtend are implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006</s> --[[User:Tim|Tim]] 13:34, 4 Mar 2007 (PST) Fixed now
* [http://www.socaltech.com socalTECH] is a news and information site. Their front page event listing is marked up with hCalendar.
** dtstart/dtend implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006
* [http://www.multipack.co.uk The Multipack] features a vevent for the next meeting information.
** dtstart/dtend are implemented on em element [[User:TomArmitage|Tom Armitage]] June 23, 2006
* [http://paulschreiber.com/ Paul] Schreiber's [http://iceoasis.shrub.ca/ unofficial schedule site] publishes hCalendar information for upcoming hockey games at [http://www.iceoasis.com/ Ice Oasis]
** dtstart/dtend are implemented on td element [[User:TomArmitage|Tom Armitage]] June 23, 2006

- whilst Tails parses the "title" attribute for dtstart/dtend on <em>any</em> element (does Tails still do this?), that is incorrect. The title attribute only provides semantics for the <code><nowiki><abbr></nowiki></code> element, while for elements in general like <code><nowiki><span></nowiki></code>, only the contents of the element are used. This is a simplification and see [[hcard-parsing|hCard parsing]] for details. Technorati Microformats Search only looks for the title attribute on <code><nowiki><abbr></nowiki></code> tags per the rules from [[hcard-parsing|hCard parsing]] which apply to [[hcalendar-parsing|hCalendar parsing]] as well.

== Reviewed Examples ==
If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

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

hcalendar-examples-in-wild

2007-04-04T20:07:50Z

MikeKaply: /* New Examples */

<h1>hCalendar Examples in the wild</h1>

This page is an '''informative''' section of the [[hcalendar|hCalendar specification]].

The following sites have published events using [[hcalendar|hCalendar]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc.

If events on your site are marked up with hCalendar, feel free to add it to the top of this list. Please be sure to include at least one URL of a page on your site that includes actual [[hcalendar|hCalendar]] markup. Examples added without the URL of a page with hCalendar markup may be removed.

Want to get started with writing an [[hcalendar|hCalendar]] event? Use the [http://microformats.org/code/hcalendar/creator hCalendar creator] to write up an event and publish it, or follow the [[hcalendar-authoring|hCalendar authoring tips]] to add hCalendar markup to your page of upcoming events or events you mention in blog posts, wikis, etc.

Don't forget that you can add one of our [[buttons#hCalendar|buttons]] to the page, to indicate the presence of hCalendar microformats. For example: http://www.boogdesign.com/images/buttons/microformat_hcalendar.png. If you can link it back to [[hcalendar|hCalendar]] (or even page on your website, about your use of the microformat), so much the better!

==New Examples==

Please add new examples to the '''top''' of this section.
* [http://last.fm last.fm] - uses hCalendar on all concert announcements.
** Example here: [http://www.last.fm/event/75615 Rise Against at Arena, Wien]
* [http://www.radiotimes.com Radio Times] - now mark up all their radio and TV listings.
**The hCals on listings are good, but on pages for individual programmes, they have no date/times - for instance [http://www.radiotimes.com/ListingsServlet?event=10&channelId=56&programmeId=57876521&jspLocation=/jsp/prog_details_fullpage.jsp]
** Would benefit from using [[include-pattern]] for channel name in main listings. This would facilitate the writing of parsers to set audio or video recording software. [[User:AndyMabbett|Andy Mabbett]]
* [http://nederlandskamerkoor.nl Dutch Chamber Choir] uses hCalendar to notify visitors of their tour schedule.
* [http://cloudislands.com Cloud Islands] uses hCalendar to notify our customers about the conferences we'll be attending.
* [http://www.international.unt.edu UNT International] uses hCalendar for events (see esp. [http://www.international.unt.edu/offices/welcome/events/intlweek/calendar International Week 2007 Event Calendar])
* [http://www.rockisland.com/%7elopezmuseum/index.html The Lopez Island Historical Society and Museum] uses hCalendar for events
* [http://futureofwebapps.com/schedule.html Future of Web Apps London] lists its schedule in hcalendar.
* [http://leicesteryha.org.uk/cgi-bin/leoprog Leicester YHA Group's programme page] uses hCalendar and hCard to mark up forthcoming events and their organisers.
* [http://www.wadip.org.uk/pages/events.php Wadhurst Independent Photography events] lists forthcoming events in hCalendar format.
* [http://xlntads.com/about-xlntads/development-schedule.php XLNTads-development schedule] has their project development schedule timeline marked up in hcal (as well as contacts in hCard)
* [http://www.jaama.co.uk Jaama] have their event details as iCal downloads on their [http://www.jaama.co.uk/HS_Seminars.aspx workshops] page.
* [http://3amproductions.net 3AM Productions] has employee education ([http://3amproductions.net/jason.php Jason], [http://3amproductions.net/gilbert.php Gilbert]) marked up in hCalendar
* The [http://neatta.org New England Antique Tractor & Truck Association] (of all sites) has their 15 upcoming events marked up in hCalendar (as well as contacts in hCard and classifieds in hListing)
* [http://diarised.com Diarised] is a quick and simple online tool to help pick the best time for a meeting, uses hCalendar for meeting information.
* [http://etnies.com/ etnies.com] uses hCalendar on each sports home page ([http://etniesskate.com/ etniesskate.com]) and the [http://etnies.com/extra/calendar/ calendar of events] page.
* [http://www.mdas.org/ La maison des associations de Strasbourg] uses hCalendar on event pages.
* [http://nuggetshoops.com/schedule.php NuggetsHoops] , an NBA fansite, uses hCalendar for each remaining game in the current season.
* [http://wikevent.org WikEvent] aims to make it as easy as possible to put events on the web with semantic markup, including hCalendar for events and hCard for venues and artists.
* [http://fundyfilm.ca/calendar/ The Fundy Film Society] uses hCalendar for their calendar of upcoming film screenings.
* Psychology Press and Routledge's Behavioral Sciences' publishing division have implemented hCalendar on their conferences listings on 17 of their websites (example on the conference listing on their [http://www.clinicalpsychologyarena.com/resources/conferences.asp Clinical Psychology Arena])
* [http://jhtc.org Jewish High Tech Community] uses hCalendar on event pages.
*[http://www.gore-tex.com/remote/Satellite?c=fabrics_content_c&cid=1162322807952&pagename=goretex_en_US%2Ffabrics_content_c%2FKnowWhatsInsideDetail Gore-Tex "Know What's Inside"] tour dates in hCalendar by [http://microformats.org/wiki/User:Csarven csarven]
* [http://finetoothcog.com/site/stolen_bikes Finetoothcog] uses hCalendar to markup when bikes are stolen.
* [https://www.urbanbody.com/information/contact-us Urban Body Men's Clothing] uses hCalendar for business hours and hCard for business locations.
* [http://www.infoiasi.ro The website of the Faculty of Computer Science], "A. I. Cuza" University Iaşi, Romania, uses hCalendar to markup events.
* [http://www.crosbyheritage.co.uk/events/ Colin Crosby Heritage Tours] uses hCalendar to markup events.
* [http://www.facebook.com Facebook] use hCalendar to markup events.
* [http://www.newbury-college.ac.uk/ Newbury College UK] uses a smattering of hCalendar and hCard
* [http://07.pagesd.info/ardeche/agenda.aspx 07.pagesd.info] uses hCalendar and hCard to mark up events of the Ardèche département in France.
* [http://climbtothestars.org Stephanie Booth] announced the [http://climbtothestars.org/archives/2006/09/14/microformats-et-bloggy-friday-doctobre/ Bloggy Friday for October 2006] using hCalendar.
* The [http://www.westmidlandbirdclub.com/ West Midland Bird Club], in the English Midlands, uses hCal (with nested hCard) on its [http://www.westmidlandbirdclub.com/diary/ diary of birding events].
* [http://www.comtec-ars.com/press-releases/ ComTec audience response systems' press releases] use hCalendar as a method to organize by title and date.
* [http://webdirections.org/program/ The Web Directions Conference (Sydney Australia)] uses hCalendar for their program. It uses axis and headers for events in a table, and demonstrates how easy it is to make the whole thing downloadable using X2V.
* [http://www.thestreet.org.au/ The Street Theatre (Canberra, Australia)] now uses hCalendar for performances on its [http://www.thestreet.org.au/whats_on.htm What's On] page.
* [http://www.clacksweb.org.uk Clackmannanshire Council] uses hCalendar on its [http://www.clacksweb.org.uk/community/events/ event diary] listing pages and individual event pages.
* [http://www.markthisdate.com/ Calendarportal MarkThisDate.com] now uses hCalendar for all calendars. On our website visitors can add calendars and download calendars to Outlook, Lotus Notes, iCal, Netvibes, 30Boxes, Google Calendar and many others. Over 600 calendars were already uploaded.
* [http://mogue.jp/ mogue] uses hCalendar at [http://mogue.jp/event/1000/ event detail] pages.
* [http://www.gustavus.edu/events/nobelconference/2006/schedule.cfm 2006 Nobel Conference] uses hCalendar for the conference schedule
* [http://www.geekinthepark.co.uk Geek in the Park] uses hCalendar for the event information. -- by [[User:Trovster|trovster]]
* [http://www.besancon.fr/ official site of Besançon (France)] for its events
* [http://2006.dconstruct.org/schedule/ Conference schedule for d.Construct 2006] is published using hCalendar.
* [http://local.yahoo.com Yahoo Local] now supports hCalendar
* We used hcalendar for the [http://www.fuckparade.org/flyer/2006/ F’parade flyer 2006], a counter demonstration to the Love Parade in Berlin, alas the '''Firefox tails extension''' doesn't get a summary when it's an alt-text in an image.
* [http://www.harper-adams.ac.uk/press/events.cfm Harper Adams University College] uses hCalendar to mark up all University events on the Homepage and Events Calendar page.
* [http://www.capital.edu/ Capital University] uses hCalendar on multiple pages to provide feeds of events, relevant to page content
* [http://www.thesession.org/events/ The Session events] uses hCalendar to mark up concerts, festivals and workshops related to Irish traditional music.
* [http://rubyandrails.org/usergroups/newcastle ncl.rb] uses hCalendar to mark up new meetings.
* [http://gross.org.za/calendar GROSSUG Calendar] - Uses hCalendar to mark up meetings and other events.
* [http://www.webanalyticsassociation.org/en/calendarevents/search.asp Web Analytics Association] - hCalendar microformat is in place on all Tendenci sites on the calendar events search page and consolidated list page.
* [http://www.tendenci.com/en/calendarevents/search.asp Tendenci Calendar Events] with hCalendar
* [http://www.argolon.com/2006/04/17/web20-conference-in-dublin/ Web2.0 Conference in Dublin] hCalendar event
* [http://www.meetup.com/ Meetup.com] has marked up [http://www.meetup.com/cities/us/ny/new_york city event calendars], [http://photo.meetup.com/100/events/ group event lists], and [http://www.meetup.com/ signed-in homepages] with hCalendar.
* [http://ukwindsurfing.com/ ukwindsurfing.com] has marked upcoming events with hCalendar, and the [http://ukwindsurfing.com/events/ events page] in a table.
* [http://ocono.com/ ocono.com] has marked up it's "Upcoming Events" list with hCalendar.
* [http://www.austinbloggers.org/ Austin Bloggers] has marked up their "Upcoming Events" box with hCalendar ([http://www.austinbloggers.org/blog/a/001123.html announcement]).
* Ning's cloneable Group app has [[hcalendar|hCalendar]] markup on its [http://group.ning.com/index.php?controller=event&action=list event calendar] and [http://group.ning.com/index.php?controller=event&action=view&id=727220 event detail] pages.
* [http://tantek.com/microformats/2006/03-01-TechPlenAgenda.html Agenda: W3C Technical Plenary Day, March 1 2006] has [[hcard|hCard]] and [[hcalendar|hCalendar]] markup. ([http://www.w3.org/2006/03/01-TechPlenAgenda.html original here]).
* The National Arbor Day Foundation has started using hCalendars for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].
* [http://www.stateofflux.com/ State of Flux street art site] has started adding events in hCalendar format
* The [http://barcamp.org/#BarCamps BarCamp home page lists upcoming BarCamps marked up with hCalendar] and even has a "Subscribe..." link.
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the schedule and events for the week with hCalendar.
* [http://www.code4lib.org/2006/schedule code4lib Conference 2006 Schedule] is marked up with hCalendar as [http://www.code4lib.org/node/65 announced on their blog].
* [http://grouper.ieee.org/groups/754 IEEE 754 Working Group] - trying hCalendar for upcoming meetings.
* [http://www.pehuen.org/node/494 Elecciones 2005 Chile] - the first spanish language hCalendar event found in the wild.
* [http://www.codewitch.org/it/2005/11/17/no-creative-commons-no-party/ Giocolando » No Creative Commons? No Party!] is marked up with hCalendar
* [http://www.cmprofessionals.org/events/calendar.html CM Pros Events Calendar] by Bob Doyle
* [http://www.midgard-project.org/community/events/ Midgard CMS Event calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius]
* [http://www.iowamilitaryveteransband.com/schedule/ Iowa Military Veterans Band Schedule] - hCalendar markup [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ added by Scott Reynen]
* [http://www.funfairgames.net/weblog/posts/00000011.html Upcoming events on Jason A.R. Moody Amusements Weblog] posted by Jason Moody on 15 Oct 2005. [http://www.funfairgames.net/weblog/index./wwf.org.au/act/volunteer/ Volunteer]
* [http://rubyholic.com rubyholic] uses hCalendar to publish calendars for ruby groups.
* [http://www.bath.ac.uk/whats-on/ University of Bath What's On] uses hCalendar on individual event pages
* The [http://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm program] marked up with hCalendar

===World Cup Kick-off===
* [http://www.worldcupkickoff.com/ World Cup KickOff] where you can download and keep all the fixtures you are interested in so you will never miss a single game of the 2006 football World Cup!
** This link was on the [http://www.lifehacker.com/software/sports/world-cup-start-times-for-ical-etc-175393.php Lifehackers site] and made its way to the yahoo news site:

<blockquote>
Mon May 22, 4:00 PM ET
The World Cup, one of the world's most watched sporting events, is almost upon us. If you've ever tried to follow your favorite team through the Cup you know that it can sometimes be difficult to know when they're on. World Cup Kickoff can help.

World Cup KickOff is all you will ever need for knowing all the match details for the upcoming World Cup 2006. Whether you use your mobile phone, MS Outlook, Apple iCal or Mozilla Calendar, you can download and keep all the fixtures you are interested in so you will never miss a single game!

Next tip? We'll show you how to get up at 2 AM to watch your matches. ;0) Thanks to Tom for the tip!
</blockquote>

== Examples with some problems ==
If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hcalendar | hCalendar spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hcalendar-faq| hCalendar FAQ]], or raise any queries on [[hcalendar-issues| hCalendar issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you.
* I'd be happy if some future french Pinko-marketing meetings (CantineCamp) could require the use of hCalendar for listing some informal lunches in Paris. [http://www.wikiservice.at/fractal/wikidev.cgi?FR/PinkoMarketing/CantineCampParis10 CantineCampParis10 is an example] to include a hCalendar + hCard markup on the wiki-page. When converting to vCard, "Mendès" accent is malformed in a french outlook 2003 "address book". I've looked UTF-8 example but could not find any way to correct. Any idea ? -- [[User:ChristopheDucamp|xtof]] 01:09, 26 Mar 2007 (PDT)
* [http://www.joomlamug.com Joomla! Melbourne User Group] uses hCalendar markup for listing of all events.
** No examples on cited page. [[User:AndyMabbett|Andy Mabbett]] 15:06, 31 Jan 2007 (PST)
* [http://www.webfeet.org/events.html Webfeet events] includes hCalendar markup in its aggregated events lists.
** <s>Possibly a case where <nowiki><abbr></nowiki> won't work for dtstart/dtend as there are many events listed under a single date. [[User:Webf|Webf]] 15:19, 15 Jan 2007 (PST)</s>
**Malformed e.g <code><nowiki><span class="dtstart" title="20070120"></span></nowiki></code> [[User:AndyMabbett|Andy Mabbett]] 15:41, 15 Jan 2007 (PST)
** Continue the discussion under [[hcalendar-issues|hCalendar Issues]] perhaps. [[User:Webf|Webf]] 22:25, 15 Jan 2007 (PST)
* [http://www.theatrestudies.llc.ed.ac.uk/ Theatre Studies: European Theatre] at the University of Edinburgh uses hCalendar to markup news and events on the index page.
**<s>Uses "display:none" on image. [[User:AndyMabbett|Andy Mabbett]] 15:32, 13 Nov 2006 (PST)</s> Removed img tag from hCard
* [http://www.bokle.de/ s'Bokle] is a German music pub. Their events calendar has been marked up with hCalendar.
** improper use of rrule --[[User:RyanKing|RyanKing]] 16:04, 6 Jan 2006 (PST)
* [http://plan9.tryphon.org/nancy/list Plan9] - Uses hCalendar to mark up events !
** <s>dtstart/dtend are implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006</s> --[[User:Tim|Tim]] 13:34, 4 Mar 2007 (PST) Fixed now
* [http://www.socaltech.com socalTECH] is a news and information site. Their front page event listing is marked up with hCalendar.
** dtstart/dtend implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006
* [http://www.multipack.co.uk The Multipack] features a vevent for the next meeting information.
** dtstart/dtend are implemented on em element [[User:TomArmitage|Tom Armitage]] June 23, 2006
* [http://paulschreiber.com/ Paul] Schreiber's [http://iceoasis.shrub.ca/ unofficial schedule site] publishes hCalendar information for upcoming hockey games at [http://www.iceoasis.com/ Ice Oasis]
** dtstart/dtend are implemented on td element [[User:TomArmitage|Tom Armitage]] June 23, 2006

- whilst Tails parses the "title" attribute for dtstart/dtend on <em>any</em> element (does Tails still do this?), that is incorrect. The title attribute only provides semantics for the <code><nowiki><abbr></nowiki></code> element, while for elements in general like <code><nowiki><span></nowiki></code>, only the contents of the element are used. This is a simplification and see [[hcard-parsing|hCard parsing]] for details. Technorati Microformats Search only looks for the title attribute on <code><nowiki><abbr></nowiki></code> tags per the rules from [[hcard-parsing|hCard parsing]] which apply to [[hcalendar-parsing|hCalendar parsing]] as well.

== Reviewed Examples ==
If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

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

hatom-issues-fr

2007-02-27T17:06:24Z

MikeKaply: /* Feed <i>title</i> (atom:<i>title</i>) */

__TOC__

= hAtom 0.2 =

Cette section est destinées à discuter de ce que vous aimeriez voir dans la prochaine version de hAtom, c'est à dire 0.2.

==Geo==
*2006-02-03 soulevée par Brian
*# Nous pouvons utiliser le microformat [[geo-fr|geo]] dans [[hatom-fr|hAtom]] pour représenter un élément GeoRSS

== Relation de rel-bookmark vers url+uid ==
Le concept de permalien est disponible dans hCard et hCalendar sous les classes url et uid. Cette combinaison fait correspondre la sémantique du permalien en indiquant que l'url devrait être déréréférencée pour trouver une version dynamique ou mise à jour du contenu, et que cette url est un id unique stable qui peut être utilisé pour identifier le contenu.

hAtom 0.1 utilise rel-bookmark pour le concept du permalien. L'état actuel du [[uid-brainstorming-fr]] indique que le concept permalien hCard et hCalendar doit être probablement utilisé dans les microformats subséquents. Ce peut être important de réconcilier hAtom avec cette trajectoire. Les réconciliations possibles comprennent :

1) Laisser les choses telles qu'elles sont. Les deux concepts des permaliens doivent être maintenus séparés.

2) Traiter les deux concepts comme équivalents. Permettre les deux dans hAtom et considérer permettre les deux dans d'autres formats. Par ex <a rel="bookmark" href="http://example.com/"> trouvera les valeurs uid et url si elles ne sont pas fournies explicitement.

3) Choisir l'un sur l'autre pour hAtom et peut être aussi pour les futurs microformats. "url uid" permet quelque plus grande liberté (l'uid peut être pointé comme un uid non url), mais ce n'est pas clair à cette étape si cette liberté est garanties ou recommandable à autoriser.

== Fil <i>XXX</i> (atom:<i>xxx</i>) ==

Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

== Format Datetime (atom:<i>updated</i> et atom:<i>published</i>) ==
<small>2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.

== Feed <i>id</i> (atom:<i>id</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.
The Feed permalink should be used as the feed id.

== Feed <i>permalink</i> (atom:<i>permalink</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

I'm proposing the following rules:

* a Feed Permalink element is identified by [[rel-bookmark]] at the feed level*
* a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
* a Feed Permalink element represents the concept of an Atom link in a feed.
* if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.

: 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
: 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
: "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
: IMO this would be good enough for at least 80% of the cases.

* 2006-04-12 [[User:DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.

* [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

== Feed <i>updated</i> (atom:<i>updated</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to.
I'm proposing the following rules:

* The Feed Updated element is identified by the class name <code>updated</code> at the feed level*
* If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.

Algorithm:

<pre>
$a = array();
for each $entry in $feed {
if ($entry.updated)
$a.add(pad_datetime($entry.updated))
else
$a.add(pad_datetime($entry.published))
}
$a.sort_by( datetime_to_utc($element) )
$feed_updated = $a[0];
</pre>

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"

== Feed <i>title</i> (atom:<i>title</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to.

I'm proposing the following rules:

* a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
* a Feed SHOULD have an Feed Title
* a Feed Title element represents the concept of an Atom feed title
* if the Feed Title is missing, use
** <del>the first <code><h#></code> element in the Feed, or</del>
** the <code><title></code> of the page, or
** assume it is the empty string

* 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.

:: 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
:: 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings

* 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?

: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.

* 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

== Feed <i>author</i> et Entrée author (atom:<i>author</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

I'm proposing the following rules for Feed author:

* a Feed Author element is represented by class name <code>author</code> at the feed level*
* a Feed Author element represents the concept of a Atom author
* a Feed Author element MUST be encoded in a [[hcard|hCard]]
* a Feed Author element SHOULD be encoded in a <code><address></code> element
* a Feed MAY have more than one Feed Author elements
* if the Feed Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>

I'm proposing the following rules for entry author:

* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an Atom author
* an Entry Author element MUST be encoded in an [[hcard|hCard]]
* an Entry Author element SHOULD be encoded in an <code><address></code> element
*<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
* <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the Entry is invalid hAtom
</ins>
* an Entry MAY have more than one Entry Author elements
<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
: 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

== Entrée <i>XXX</i> (atom:<i>xxx</i>) ==

Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

== Entrée <i>id</i> (atom:<i>id</i>) ==
<small>2006-04-01 soulevée par [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>id</i> est requis pour atom:entry. De ce fait il devrait être dipsonible aussi dans hATom.

L'Entrée permalien devrait être utilisée comme l'id d'entrée.

* --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT) : J'ajouterais "Seulement si l'attribut id n'est pas défini pour l'élément qui contient l'entrée.3 L'attribut id peut être un uri tag. Si vous utilisez toujours le permalient Entry comme l'id d'entrée et le fil Atom utilise les tags uris, vous finiriez avec deux ids différents pour la même entrée/

<small>2006-12-31 réponse par [[User:ComputerKid|Emanla Eraton]]</small>
Non, ce ne devrait pas être un permalien. Ce devrait être un "tag:" id pour les entrées.

== Author ==

=== author en tant que hCard est bien trop comme exigence ===

The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.

* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>

== Autres Questions et Problématiques ==

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Exigée ? -- Problématique de Blogger ===
The [[hatom-fr|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? -- [[User:Singpolyma|singpolyma]] 05:45, 28 Mar 2006 (PST)

* [[DavidJanes]]: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example <code>title="day month-name year, hour12:minute ampm tz"</code>) but I think this is asking too much from creators and parsers.

** [[User:Singpolyma|singpolyma]] 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats. My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs ''cannot'' be parsed by other's hAtom parers as hAtom is now unless they too are so leniant.

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
The [[hatom-fr|hAtom]] 0.1 spec states the follwing two items about the Feed element:

# the Feed element is optional and, if missing, is assumed to be the page
# hAtom documents MAY have multiple Feed elements

I'm concerned about the implementation details of multiple feeds and that the current 0.1 spec isn't sufficient to define multiple distinct feeds in a single html document and that even if some of those areas were modified if there are real mechanisms out there to support a document with multiple feeds.

To provide examples of how multiple feeds might reside in a document under hAtom 0.1 I've created this collection of [http://placenamehere.com/mf/hatom_tests/ hAtom multiple feed tests]

Some of the questions that need to be answered (more details and some conclusions at a later time):

# Can a unique reference be made to each feed? Are there ambiguous references?
# Can a unique label or feed name be generated from each feed for the purpose of selection by the subscriber?
#* Using the feed title seems to be an option. It is likely (thought not guaranteed) that it is unique.
# What changes need to be made to the spec to make the publishing of multiple feeds in a document less ambiguous?
#* [[User:RobertBachmann|Robert Bachmann]] (2006-05-23): IMO the simplest soultion would be to require that each feed element MUST have an XHTML id attribute.
# What rules are needed for the detection, selection and consumption of feed documents so that people can select and maintain a subscription to the proper feed?
# How should a consuming application deal with potential changes to feeds found in a document over time (either id changes, additional feeds added, removal of feed, etc)? (this issue could be generalized to single feed documents as well)
# [[User:ChrisCasciano|Chris Casciano]] (2006-07-24): A good chat session on this issue can be found [http://rbach.priv.at/Microformats-IRC/2006-05-25#T224929 here]

==== Règles Brouillons pour plusieurs fils ====
(2006-07-24): Written by [[User:ChrisCasciano|Chris Casciano]]

* If there is only one feed on a page spec+parsing rules from 0.1 apply
* If there are multiple feeds, each feed should explicitly define the root hfeed element with both class="hfeed" and a fragment identifier (id).
* Specific feeds can be addressed via their fragment id.
* If no fragment id is specified for a page with multiple hatom feeds then their content is merged via atom's SOURCE semantics

===== Discussion de Règles Brouillons =====
* Issue: what is the result of trying to address a feed at a non-existing fragment identifier? Same as no fragment id specified, or a not found error?
* Issue: for authors, is there any way we can control a redirect for a feed addressed via fragment id?
* Issue: are there any other long term management issues or other authoring considerations we need to think about for 0.2?
* Issue: is the reliance on class + id too strict? we may be losing other non-ambiguous constructs for sake of simplicity (e.g. roots are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)

= hAtom 0.1 =

'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).

__TOC__

== Contributeurs ==
* Danny Ayers
* Robert Bachmann
* Paul Bryson
* Benjamin Carlyle
* Chris Casciano
* Tantek Çelik
* David Janes
* Ryan King
* Kevin Marks
* Scott Reynen
* Brian

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])'''

=== Proposition Initiale ===

<code>atomfeed</code> (or rather, "atom-entry")

* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** hfeed

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

* <code>feed</code> (Atom consistency)
* <code>atom-feed</code> (Atom consistency with prefix)
* <code>hfeed</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 MarkRickerby
** +1 DannyAyers

==== Discussion ====

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Proposition Initiale===

<code>atomentry</code> (or rather, "atom-entry")

* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[DavidJanes]]
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[MarkRickerby]]
** +1 [[DannyAyers]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p>

== Entrée Titre (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''

=== propositions ===

The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[Tantek]]
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[BenjaminCarlyle]], atom:entry/title only
** +½ [[DavidJanes]], atom:entry/title only
** +½ [[PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[DavidJanes]] see my note below
** -1 [[Tantek]] (does not mean the "name" of the post/entry)
** +1 [[BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==

'''STATUS - RESOLVED going with entry-content'''

* <code>content</code> (Atom consistency)
** -1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
** -1 KevinMarks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 KevinMarks
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[Tantek]]
** +1 KevinMarks
** +1 [[ChrisCasciano]]
* <code>atom-content</code>
** +0.5 [[Tantek]]
* <code>hcontent</code>
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.

=== Discussion ===
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')

== Entry Summary (atom:summary) ==

'''STATUS - RESOLVED - going with 'entry-summary''''

The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 KevinMarks
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs

=== Discussion ===
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

* <code>rel="bookmark"</code> (HTML consitency)
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 KevinMarks

=== Discussion ===
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
** +0.5 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>VJOURNAL CREATED</code>

=== Discussion ===
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Updated (atom:updated) ==

'''STATUS - RESOLVED - 'updated''''

* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +½ Paul Bryson, Not as human readable
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
go back throught [[blog-post-examples]] to see what conventions we have.
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Author (atom:author) ==

'''STATUS - RESOLVED - 'author' required, should use <code><address></code>'''

* <code>author</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]

=== Discussion ===
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is <address> not sufficient for 'author' semantics?
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what <address> implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].

== Entry Contributor (atom:contributor) ==
** -1 Tantek (see Discussion)
* <code>contributor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

=== Discussion ===
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''

== Entry Geo (geo:Point) ==
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

=== Ressources GeoRSS ===
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions et Commentaires ==

=== Limites===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

=== Les relations vers les définitions hReview ont besoin de clarification ===
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

[[Tantek]]: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

=== hCards ===

[[DavidJanes]]: Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

RESOLVED: MUST use hCard for author.

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>

=== Comparisons ===

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--[[Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

=== Eléments répétés===
Nous permettons à certains éléments d'être répétés, comme un Permalien d'Entrée, l'Entrée Publiée et le Titre de l'Entreée, même s'il peut y avoir au plus une valeur réelle. Nous fournissons des règles de "désambiguation" pour trouver quelle est la vraie valeur. Voir [[hatom-fr#Nesting_Rules|ici]], [[hatom-fr#Entrée_Title|ici]], [[hatom-fr#Entrée_Permalink|ici]] et [[hatom#Entrée_Publiée|ici]].

Vos idées, svp... -- [[User:DavidJanes|David Janes]]

'''STATUT - RESOU'''. La spec a des règles explicites de désambiguation pour tous ces items s'ils apparaissent plusieurs fois.

=== Opacité ===
Si vous avez des soucis à propos de l'[[hatom-fr#hAtom_Opaque-fr|opacité]], ce qui veut dire arrêter l'interprétation en dessous de certains éléments hAtom, soulevez-les là.

==== Opacité des autres éléments microformat ====
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- [[BenjaminCarlyle]]

* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.

==== Opacité du résumé et du contenu ====
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

=== Identification ===
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

=== HTML Title ===
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

=== rel-tag ===
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]

* [[Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

=== Excess disambiguation rules? ===
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

=== Dépendances ===
==== mfo ====
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples-fr]].

=== Is atom:content necessary? ===
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

=== Published as default value for atom:updated ===
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.
: + 1 [[User:RobertBachmann|Robert Bachmann]]

=== Désigner l'auteur de la page ===

(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

* How do I designate the page author(s)?
** <code>class="author"</code> outside of the hAtom entry?
** <code><address class="author"></code> outside of the hAtom entry?
** <code><address></code> outside of the hAtom feed (i.e. at the page level)?
* How do I designate the feed author(s)?

(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.

==== Proposition ====
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.

== Entry Updated Obligé ? -- Blogger ==
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].
*# The [[hatom-fr|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern-fr]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...

= See Also =
* [[hatom-fr|hAtom]] - la proposition draft
* [[hatom-faq-fr|hAtom-faq]] - base de connaissance
* [[blog-post-brainstorming-fr|billets de blogs-brainstorming]]
* [[blog-post-formats-fr|billets de blogs-formats]]
* [[blog-post-examples-fr|billets de blogs - exemples]]
* [[blog-description-format-fr]] - comme décrire un blog (à l'opposition des entrées individuelles, ce qui est ce que nous faisons ici)
* [[mfo-examples-fr|mfo-exemples]]
* [[naming-principles-fr|principes de nommage]]

= Gabarit =

SVP utilisez ce format (copiez et coller ça à la fin de la liste pour ajouter vos problématiques) :
* AAAA-MM-JJ soulevé par [http://votrepageperso.exemple.com VOTRENOM].
*# ''Problématique 1 : Voici la première problématique que je rencontre.''
*# ''Problématique 2 : Voici la seconde problématique que je rencontre.''

hatom-issues

2007-02-26T18:46:21Z

MikeKaply: /* Feed <i>title</i> (atom:<i>title</i>) */

__TOC__

= Cited example issue =

= Cited example issue =

Andy Mabbett moved the Joomla! Melbourne User Group link to the "Examples with some problems" area of [[hatom]] and I was wondering what the problem is with it... as Operator and Tails have no problems identifying the hAtomised content. which is why I'm confused by Andy's comments about no cited examples. Can someone please offer some assistance?
:I didn't find any hAtom content on that page. I can see it now, so have moved it back. Apologies if I was mistaken. [[User:AndyMabbett|Andy Mabbett]] 01:29, 25 Feb 2007 (PST)

= hAtom 0.2 =

This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.

==Geo==
*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

== Relationship of rel-bookmark to url+uid ==
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the hCard and hCalendar permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

== Feed <i>XXX</i> (atom:<i>xxx</i>) ==

Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

== Datetime format (atom:<i>updated</i> and atom:<i>published</i>) ==
<small>2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.

== Feed <i>id</i> (atom:<i>id</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.
The Feed permalink should be used as the feed ID.

== Feed <i>permalink</i> (atom:<i>permalink</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

I'm proposing the following rules:

* a Feed Permalink element is identified by [[rel-bookmark]] at the feed level*
* a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
* a Feed Permalink element represents the concept of an Atom link in a feed.
* if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.

: 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
: 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
: "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
: IMO this would be good enough for at least 80% of the cases.

* 2006-04-12 [[User:DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.

* [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

== Feed <i>updated</i> (atom:<i>updated</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to.
I'm proposing the following rules:

* The Feed Updated element is identified by the class name <code>updated</code> at the feed level*
* If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.

Algorithm:

<pre>
$a = array();
for each $entry in $feed {
if ($entry.updated)
$a.add(pad_datetime($entry.updated))
else
$a.add(pad_datetime($entry.published))
}
$a.sort_by( datetime_to_utc($element) )
$feed_updated = $a[0];
</pre>

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"

== Feed <i>title</i> (atom:<i>title</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to.

I'm proposing the following rules:

* a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
* a Feed SHOULD have an Feed Title
* a Feed Title element represents the concept of an Atom feed title
* if the Feed Title is missing, use
** <del>the first <code><h#></code> element in the Feed, or</del>
** the <code><title></code> of the page, or
** assume it is the empty string

* 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.

:: 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
:: 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings

* 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?

: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.

* 2007-12-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

== Feed <i>author</i> and Entry author (atom:<i>author</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

I'm proposing the following rules for Feed author:

* a Feed Author element is represented by class name <code>author</code> at the feed level*
* a Feed Author element represents the concept of a Atom author
* a Feed Author element MUST be encoded in a [[hcard|hCard]]
* a Feed Author element SHOULD be encoded in a <code><address></code> element
* a Feed MAY have more than one Feed Author elements
* if the Feed Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>

I'm proposing the following rules for entry author:

* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an Atom author
* an Entry Author element MUST be encoded in an [[hcard|hCard]]
* an Entry Author element SHOULD be encoded in an <code><address></code> element
*<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
* <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the Entry is invalid hAtom
</ins>
* an Entry MAY have more than one Entry Author elements
<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
: 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

== Entry <i>XXX</i> (atom:<i>xxx</i>) ==

Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

== Entry <i>id</i> (atom:<i>id</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to.

The Entry permalink should be used as the entry id.

* --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.

<small>2006-12-31 response by [[User:ComputerKid|Emanla Eraton]]</small>

No, it shouldn't be a permalink. It should be a "tag:" id for entries.

== Author ==

=== author as an hcard is too much to require ===

The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>

== Other Questions and Issues ==

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Required? -- Blogger Issue ===
The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? -- [[User:Singpolyma|singpolyma]] 05:45, 28 Mar 2006 (PST)

* [[DavidJanes]]: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example <code>title="day month-name year, hour12:minute ampm tz"</code>) but I think this is asking too much from creators and parsers.

** [[User:Singpolyma|singpolyma]] 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats. My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs ''cannot'' be parsed by other's hAtom parers as hAtom is now unless they too are so leniant.

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
The [[hatom|hAtom]] 0.1 spec states the follwing two items about the Feed element:

# the Feed element is optional and, if missing, is assumed to be the page
# hAtom documents MAY have multiple Feed elements

I'm concerned about the implementation details of multiple feeds and that the current 0.1 spec isn't sufficient to define multiple distinct feeds in a single html document and that even if some of those areas were modified if there are real mechanisms out there to support a document with multiple feeds.

To provide examples of how multiple feeds might reside in a document under hAtom 0.1 I've created this collection of [http://placenamehere.com/mf/hatom_tests/ hAtom multiple feed tests]

Some of the questions that need to be answered (more details and some conclusions at a later time):

# Can a unique reference be made to each feed? Are there ambiguous references?
# Can a unique label or feed name be generated from each feed for the purpose of selection by the subscriber?
#* Using the feed title seems to be an option. It is likely (thought not guaranteed) that it is unique.
# What changes need to be made to the spec to make the publishing of multiple feeds in a document less ambiguous?
#* [[User:RobertBachmann|Robert Bachmann]] (2006-05-23): IMO the simplest soultion would be to require that each feed element MUST have an XHTML id attribute.
# What rules are needed for the detection, selection and consumption of feed documents so that people can select and maintain a subscription to the proper feed?
# How should a consuming application deal with potential changes to feeds found in a document over time (either id changes, additional feeds added, removal of feed, etc)? (this issue could be generalized to single feed documents as well)
# [[User:ChrisCasciano|Chris Casciano]] (2006-07-24): A good chat session on this issue can be found [http://rbach.priv.at/Microformats-IRC/2006-05-25#T224929 here]

==== Draft Rules for multiple feeds ====
(2006-07-24): Written by [[User:ChrisCasciano|Chris Casciano]]

* If there is only one feed on a page spec+parsing rules from 0.1 apply
* If there are multiple feeds, each feed should explicitly define the root hfeed element with both class="hfeed" and a fragment identifier (id).
* Specific feeds can be addressed via their fragment id.
* If no fragment id is specified for a page with multiple hatom feeds then their content is merged via atom's SOURCE semantics

===== Discussion of Draft Rules =====
* Issue: what is the result of trying to address a feed at a non-existing fragment identifier? Same as no fragment id specified, or a not found error?
* Issue: for authors, is there any way we can control a redirect for a feed addressed via fragment id?
* Issue: are there any other long term management issues or other authoring considerations we need to think about for 0.2?
* Issue: is the reliance on class + id too strict? we may be losing other non-ambiguous constructs for sake of simplicity (e.g. roots are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)

= hAtom 0.1 =

'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).

__TOC__

== Contributors ==
* Danny Ayers
* Robert Bachmann
* Paul Bryson
* Benjamin Carlyle
* Chris Casciano
* Tantek Çelik
* David Janes
* Ryan King
* Kevin Marks
* Scott Reynen
* Brian

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])'''

=== Initial proposal ===

<code>atomfeed</code> (or rather, "atom-entry")

* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** hfeed

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

* <code>feed</code> (Atom consistency)
* <code>atom-feed</code> (Atom consistency with prefix)
* <code>hfeed</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 MarkRickerby
** +1 DannyAyers

==== Discussion ====

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Initial Proposal ===

<code>atomentry</code> (or rather, "atom-entry")

* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[DavidJanes]]
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[MarkRickerby]]
** +1 [[DannyAyers]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p>

== Entry Title (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''

=== proposals ===

The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[Tantek]]
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[BenjaminCarlyle]], atom:entry/title only
** +½ [[DavidJanes]], atom:entry/title only
** +½ [[PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[DavidJanes]] see my note below
** -1 [[Tantek]] (does not mean the "name" of the post/entry)
** +1 [[BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==

'''STATUS - RESOLVED going with entry-content'''

* <code>content</code> (Atom consistency)
** -1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
** -1 KevinMarks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 KevinMarks
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[Tantek]]
** +1 KevinMarks
** +1 [[ChrisCasciano]]
* <code>atom-content</code>
** +0.5 [[Tantek]]
* <code>hcontent</code>
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.

=== Discussion ===
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')

== Entry Summary (atom:summary) ==

'''STATUS - RESOLVED - going with 'entry-summary''''

The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 KevinMarks
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs

=== Discussion ===
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

* <code>rel="bookmark"</code> (HTML consitency)
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 KevinMarks

=== Discussion ===
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
** +0.5 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>VJOURNAL CREATED</code>

=== Discussion ===
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Updated (atom:updated) ==

'''STATUS - RESOLVED - 'updated''''

* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +½ Paul Bryson, Not as human readable
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
go back throught [[blog-post-examples]] to see what conventions we have.
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Author (atom:author) ==

'''STATUS - RESOLVED - 'author' required, should use <code><address></code>'''

* <code>author</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]

=== Discussion ===
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is <address> not sufficient for 'author' semantics?
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what <address> implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].

== Entry Contributor (atom:contributor) ==
** -1 Tantek (see Discussion)
* <code>contributor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

=== Discussion ===
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''

== Entry Geo (geo:Point) ==
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

=== GeoRSS Resources ===
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions and Comments ==

=== Limitations ===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

=== Relationship to hReview definitions needs clarification ===
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

[[Tantek]]: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

=== hCards ===

[[DavidJanes]]: Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

RESOLVED: MUST use hCard for author.

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>

=== Comparisons ===

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--[[Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

=== Repeated Elements ===
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].

Your thoughts please... -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.

=== Opaqueness ===
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.

==== Opaqueness of other microformat elements ====
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- [[BenjaminCarlyle]]

* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.

==== Opaqueness of summary and content ====
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

=== Identification ===
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

=== HTML Title ===
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

=== rel-tag ===
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]

* [[Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

=== Excess disambiguation rules? ===
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

=== Dependencies ===
==== mfo ====
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples]].

=== Is atom:content necessary? ===
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

=== Published as default value for atom:updated ===
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.
: + 1 [[User:RobertBachmann|Robert Bachmann]]

=== Designating the page author ===

(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

* How do I designate the page author(s)?
** <code>class="author"</code> outside of the hAtom entry?
** <code><address class="author"></code> outside of the hAtom entry?
** <code><address></code> outside of the hAtom feed (i.e. at the page level)?
* How do I designate the feed author(s)?

(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.

==== Proposal ====
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.

== Entry Updated Required? -- Blogger ==
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...

= See Also =
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

= Template =

Please use this format (copy and paste this to the end of the list to add your issues):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

User:MikeKaply

2007-02-16T17:23:50Z

MikeKaply:

http://www.kaply.com/weblog

events/2007-03-12-sxsw-growth-evolution-of

2007-02-16T17:23:24Z

MikeKaply: /* Would Like to Attend */

<h1>The Growth and Evolution of Microformats at SXSW 2007</h1>

One of several microformats [[events]].

__TOC__

== Summary ==
The Growth and Evolution of Microformats is a [http://2007.sxsw.com/interactive/programming/panels/ confirmed panel presentation] session to be held at the 2007 [http://2007.sxsw.com/ SXSW] Interactive Festival, on Monday, March 12th from 11:30am-12:30pm in Austin, Texas.

== Tags ==
Please use ''all'' of the following tags when tagging content (blog posts, photos) published related to the microformats session at SXSW interactive 2007:

tags: '''microformats sxsw sxsw07 sxsw2007 sxswi sxswi07 sxswi2007 microformatssxsw microformatssxsw2007 microformatssxswi microformatssxswi2007'''

== Panelists ==
*[[User:Tantek|Tantek Çelik]] (moderator)
*[[User:Phae|Frances Berriman]]
*..

== Session Description ==
SUBJECT TO CHANGE / UPDATE:

In its first year, microformats.org ushered in the rapid adoption of key formats for publishing and sharing [[rel-tag|tags]], [[rel-license|licenses]], [[hcard|contacts]], [[xfn|relationships]], [[hcalendar|events]] and [[hreview|reviews]] on the Web. See what new microformats are being developed for [[hresume|resumes]], [[hlisting|classified listings]], [[media-info|music, and media]], as well as how tens of millions of established microformats on web sites of individuals, companies, and organizations are driving innovations in desktop applications and advancing personal data portability.

== Attending ==
Please add your name here if you are attending this session, speaking or not.

*[[User:Tantek|Tantek Çelik]]
*[[User:Phae|Frances Berriman]]
*[[User:Veeliam|William Lawrence]]
*[[User:Adactio|Jeremy Keith]]
*[[User:RyanKing|Ryan King]]
*..

== Would Like to Attend ==
Please add your name here if you might be around Austin and would like to attend.
* [[User:MikeKaply|Mike Kaply]]

== Session Comments and Q&A ==
* ...

== Photos ==
* ...

== Blog Posts ==
* ...

events/2007-03-12-sxsw-growth-evolution-of

2007-02-16T17:22:54Z

MikeKaply: /* Would Like to Attend */

<h1>The Growth and Evolution of Microformats at SXSW 2007</h1>

One of several microformats [[events]].

__TOC__

== Summary ==
The Growth and Evolution of Microformats is a [http://2007.sxsw.com/interactive/programming/panels/ confirmed panel presentation] session to be held at the 2007 [http://2007.sxsw.com/ SXSW] Interactive Festival, on Monday, March 12th from 11:30am-12:30pm in Austin, Texas.

== Tags ==
Please use ''all'' of the following tags when tagging content (blog posts, photos) published related to the microformats session at SXSW interactive 2007:

tags: '''microformats sxsw sxsw07 sxsw2007 sxswi sxswi07 sxswi2007 microformatssxsw microformatssxsw2007 microformatssxswi microformatssxswi2007'''

== Panelists ==
*[[User:Tantek|Tantek Çelik]] (moderator)
*[[User:Phae|Frances Berriman]]
*..

== Session Description ==
SUBJECT TO CHANGE / UPDATE:

In its first year, microformats.org ushered in the rapid adoption of key formats for publishing and sharing [[rel-tag|tags]], [[rel-license|licenses]], [[hcard|contacts]], [[xfn|relationships]], [[hcalendar|events]] and [[hreview|reviews]] on the Web. See what new microformats are being developed for [[hresume|resumes]], [[hlisting|classified listings]], [[media-info|music, and media]], as well as how tens of millions of established microformats on web sites of individuals, companies, and organizations are driving innovations in desktop applications and advancing personal data portability.

== Attending ==
Please add your name here if you are attending this session, speaking or not.

*[[User:Tantek|Tantek Çelik]]
*[[User:Phae|Frances Berriman]]
*[[User:Veeliam|William Lawrence]]
*[[User:Adactio|Jeremy Keith]]
*[[User:RyanKing|Ryan King]]
*..

== Would Like to Attend ==
Please add your name here if you might be around Austin and would like to attend.
* http://microformats.org/wiki/User:MikeKaply

== Session Comments and Q&A ==
* ...

== Photos ==
* ...

== Blog Posts ==
* ...

vcard-implementations

2007-02-07T20:56:48Z

MikeKaply: /* Microsoft Outlook */

icalendar-implementations

2007-02-07T20:41:52Z

MikeKaply: /* iCalendar implementations */

= iCalendar implementations =

In the development of [[hcalendar|hCalendar]] and proxies like X2V, we have discovered various behaviors and quirks of RFC 2445 iCalendar implementations.

This page is here for keeping track of them.

== Contributors==
* Tantek Çelik
* [[DimitriGlazkov|Dimitri Glazkov]]

== Products ==

=== iCal.app ===

platform: OSX

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== KOrganizer ===

platform: All Linux, *BSD, etc. (Wherever KDE runs)

==== subscription handling ====

supports the non-standard "webcal:" protocol, as well as "http:", "ftp:", "fish:", etc.

=== Evolution ===

platform: Fedora Core 3

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Sunbird ===

AKA [http://www.mozilla.org/projects/calendar/sunbird.html Mozilla Sunbird]

platform: XP, others?

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Microsoft Outlook ===

platform: 2003

==== Importing of VEvents ====

Requires <code>UID</code>, <code>DTSTAMP</code>, and <code>METHOD</code>

If any of the three is not present, returns this message:

<pre>
This error can appear if you have attempted to save a recurring Lunar appointment in iCalendar format.
To avoid this error, set the appointment option to Gregorian instead of Lunar.
</pre>

After some testing, this seems to be the generic message to indicate a problem with event import.

No such restriction is placed on [http://www.imc.org/pdi/vcal-10.txt iCal 1.0] events. So, if <code>VERSION:1.0</code> is output instead of <code>VERSION:2.0</code>, the only required field is <code>DTSTART</code>.
Note that <code>VERSION</code> property may be omitted. In this case, value inferred as <code>1.0</code>.

===== Minimal valid iCal 2.0 event, importable by MS Outlook 2003 =====
<pre>
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
UID:0
DTSTAMP:20060601T080000
DTSTART:20060601T080000
END:VEVENT
END:VCALENDAR
</pre>

===== Minimal valid iCal 1.0 event, importable by MS Outlook 2003 =====

<pre>
BEGIN:VCALENDAR
BEGIN:VEVENT
DTSTART:20060601T080000
END:VEVENT
END:VCALENDAR
</pre>

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

icalendar-implementations

2007-02-02T22:03:47Z

MikeKaply: /* Microsoft Outlook */

hcard-brainstorming

2007-01-24T15:00:46Z

MikeKaply: /* geo links */

<h1> hCard Brainstorming </h1>
This page is for brainstorming about various uses and details of [[hcard|hCard]].

__TOC__

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code, then you can hide that tag in CSS with the following code:
<pre><nowiki>
<span style="display: none">Hidden Data</span>
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Auto-Discovery ==

=== vCard auto extraction ===
There is currently a debate over the best way to add an auto discovery link to your HTML to extract the vCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by
<span class="vcard author">
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>
</span>
</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==

These improvements apply to both [[geo]] and [[hcard|hCard]].

I (Tantek) have seen examples of where there is a human viewable/clickable presentation of a point on a map, and the desire to include the machine readable geo information with the same element, e.g. something like:

<pre><nowiki>
<abbr class="geo" title="machine-readable-geo-info">
human readable/clickable point on a map
</abbr>
</nowiki></pre>

But to do this we must specify a syntax for putting both the latitude and longitude into the title attribute as the machine-readable-geo-info.

Fortunately, there already is a syntax for that, in vCard RFC 2426 3.4.2:
<pre>
Type value: A single structured value consisting of two float values
separated by the SEMI-COLON character (ASCII decimal 59).

Type special notes: This type specifies information related to the
global position of the object associated with the vCard. The value
specifies latitude and longitude, in that order (i.e., "LAT LON"
ordering).

...

Type example:

GEO:37.386013;-122.082932
</pre>

Thus:
<pre><nowiki>
<abbr class="geo" title="37.386013;-122.082932">
Mountain View, CA
</abbr>
</nowiki></pre>

I think this is pretty much a no-brainer, because the rules for parsing "geo" are simply altered to:

=== latitude longitude shorthand ===

If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property (e.g. following rules for parsing <code><nowiki><abbr title></nowiki></code>, <code><nowiki><img alt></nowiki></code> etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order.

=== geo links ===

In addition, people may publish Google Maps links like this:

<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>

or Yahoo! Maps links like this:

<a href="http://maps.yahoo.com/#lat=37.386013&lon=-122.082932&mag=3">this spot</a>

Is it worth permitting this to be a geo as well?

I'm raising this to make sure it is considered.

However, my first guess is NO for two reasons.

# No such examples in the wild have been documented or seen as of yet (I certainly haven't seen any).
# It would involve additional parsing requirements which are almost certainly going to be site/domain specific, and encoding a particular site's query parameter syntax into a format seems like a bad idea (against principle of decentralization).

This could be mitigated if mapping services would simply accept the literal vCard GEO syntax "37.386013;-122.082932", e.g. http://maps.google.com/maps?q=37.386013;-122.082932 (which currently doesn't work) then we could make a simple rule such as for hyperlinks, parse the href attribute for a geo value at the end of the href, delimited before the value by a "=" (or perhaps "/" for services that use friendlier URLs).

* consider also <a href="http://www.rhaworth.myby.co.uk/oscoor_a.htm?SJ870099_region:GB_scale:25000" title="52.6866;-2.1937">SJ870099</a> which is widely used (so far without geo-title attribute) (Wikipedia, et al). Perhaps we should also support ''title="various maps of 52.6866;-2.1937"'' so that the title attribute can be used as was originally intended.

=== altitude ===

Some folks have asked for "altitude" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.

=== radius/zoom ===

Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.
=== ISO 19136 ===
When it comes to anything geospatial, any unadorned / simple encoding must remain upwardly-compatible with the more sophisticated GML schema (Geography Markup Language ) which is also known as ISO 19136. This is so that all the fundamental nuances underpinning geocoding ( different datums, different projections, elevation, etc etc ) can ultimately ( or sooner ? ) be completely accounted for.

If you don't know/supply your Coordinate Reference System CRS identifier, your location could fall 100s of metres away from the position intended ie plot in the wrong location on a map. Appendix B of draft ISO/DIS 6709 highlights the variation among three commonly used systems.

=== ISO/DIS 6709 ===
Draft International Standard [http://en.wikipedia.org/wiki/ISO_6709 ISO/DIS 6709] specifies the standard representation of geographic point location by coordinates. Section 6.3 notes the elements required required for geographic point location:

<blockquote>
In this International Standard, geographic point location shall be represented by five elements:
* a coordinate reference system identification;
* coordinate representing “x” horizontal position such as latitude;
* coordinate representing “y” horizontal position such as longitude;
* for three-dimensional point locations, a value representing vertical position through either height or depth;
* metadata associated with geographic point location(s) (ISO 19115)
</blockquote>

Annex H details the ISO standard for text string representation of point location.

H.6 Format

H.6.1 Elements shall be combined in a point location string in the following sequence:

a) Latitude

b) Longitude

c) if represented, height or depth

d) Coordinate Reference System identifier

H.6.2 The number of digits for latitude, longitude and height (depth) shall indicate the precision of available
data.

H.6.3 There shall be no separator between the elements for latitude, longitude, height (depth) and CRS.
NOTE The use of designators "+", "-" and "CRS" preceding the value part of each element permits the recognition of
the start of each element and the termination of the previous one.

H.6.4 The point location string shall be terminated. The terminator character shall be a solidus (/), unless
otherwise specified in the documentation associated with interchange.

It differs from the notation of vCard, for example.

If ISO6709 is used, it is likely to be able to write as follows.
<pre><nowiki>
examples
<abbr class="geo" title="+40-075CRSxxxx/">
Point represented as Degrees
</abbr>

<abbr class="geo" title="+401213.1-0750015.1+2.79CRSxxxx/">
Point represented as Degrees, minutes, seconds and decimal seconds, with +2.79 a height or depth as defined through the CRS.
</abbr>

</nowiki></pre>

=== ISO 19115 ===
ISO 19115:2003 defines the schema required for describing geographic information and services. It provides information about the identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data.

=== Geospatial Metadata ===
Geospatial metadata 'place category features' would enable map mashups of microformatted information, for example, show me a map of the nearest place of worship and associated disabled carparks.
http://www.linz.govt.nz/resources/esa-appl-schema-v1-9-5/esa-46.html#1804

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
<span class="given-name">John</span>
<span class="other-names">Q.</span>
<span class="family-name">Public</span>
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>
<span class="agent">
<span class="vcard">
<span class="email">
<a class="internet" href="mailto:jfriday@host.com">
<dfn>
<span class="fn">Joe Friday</span>
</dfn>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Area Administrator, Assistant</span>
</span>
</span>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page.

== Post vCard additions ==

Some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information.

This section is for documentation of such suggested additions. Note, we will require empirical evidence of actual *real world* examples on the Web of people publishing this information as part of contact information, before considering such additions/extensions.

* altitude. From [[hcard-issues]].
** No evidence provided that contact information on the Web publishes this information.

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.

== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF and back.

== Ambiguous name components ==

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>
<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>
</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

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

geo

2007-01-23T21:13:00Z

MikeKaply: /* Examples in the wild */

<h1> geo </h1>

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

== Draft Specification ==

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

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

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

=== Inspiration and Acknowledgments ===
Thanks to everyone who participated in the [[geo-bof-2005-06-30|Geo Microformat BOF at O'Reilly's Where 2.0 conference]], and in particular to [http://radar.oreilly.com/nat/ Nat Torkington] and Vee McMillen of [http://oreilly.com O'Reilly] for [http://conferences.oreillynet.com/cs/where2005/view/e_sess/7476 arranging and hosting the BOF]. Thanks to Chris Hibbbert for providing the [http://www.geocaching.com/seek/cache_details.aspx?guid=dc4754bf-64d5-4f28-8715-45ad2505c86f real world geo-caching example].

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

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

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

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

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

If the publisher knows and is publishing the address of the location, OR if the address of the location was what was actually entered by a human, and the publisher simply turned that into lat/long using some sort of a service, then the publisher SHOULD use [[adr]] to publish the actual human entered address information since that communicates far more semantic information than a simple geo lat/long coordinate.

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

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

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

=== Human vs. Machine readable ===

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

=== Value excerpting ===

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

=== Root Class Name ===

The root class name for an geo location is <code>geo</code>.

=== Property List ===

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

* latitude
* longitude

=== XMDP Profile ===

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

=== Parsing Details ===

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

== Examples ==

This section is informative.

=== Example from RFC2426 ===

Section 3.4.2 of RFC2426 has a simple geo example:

<pre><nowiki>
GEO:37.386013;-122.082932
</nowiki></pre>

this vCard fragment as a geo, as [http://microformats.org/wiki/hcard-examples#3.4.2_GEO_Type_Definition first documented on the hCard examples page]:

<pre><nowiki>
<span class="geo">
<span class="latitude">37.386013</span>,
<span class="longitude">-122.082932</span>
</span>
</nowiki></pre>

this geo could be displayed as:

37.386013, -122.082932

=== Real world geo example ===

Here is a sample of published lat/long info (from [http://www.geocaching.com/seek/cache_details.aspx?guid=dc4754bf-64d5-4f28-8715-45ad2505c86f geocaching: Noble Steed]):

<pre><nowiki>
N 37° 24.491 W 122° 08.313
</nowiki></pre>

With geo markup:

<pre><nowiki>
<div class="geo">
<abbr class="latitude" title="37.408183">N 37° 24.491</abbr>
<abbr class="longitude" title="-122.13855">W 122° 08.313</abbr>
</div>
</nowiki></pre>

This geo might be displayed as:

<abbr class="latitude" title="37.408183">N 37° 24.491</abbr>
<abbr class="longitude" title="-122.13855">W 122° 08.313</abbr>

Note that since the real world example used a more human readable presentation of the geo coordinates, we use the [[abbr-design-pattern]] to keep that more human readable presentation, and in addition provide the respective absolute numerical values for the geo.

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

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

*Wikitravel now has the facility to add co-ordinates for the subject of the article, and publishes them as a 'geo' microformat - e.g. [http://wikitravel.org/en/Birmingham_%28England%29 Wikitravel - Birmingham]; see [http://wikitravel.org/shared/Tech:Add_SpecialMap_using_Mapstraction_link_for_geo-tagged_pages_and_for_single_listings The announcement].
* [http://flickr.com/ Flickr] now [http://blog.flickr.com/flickrblog/2006/08/great_shot_wher.html supports the geo microformat] on all [http://flickr.com/map/ geotagged photos]. Within 11 days of launch there are now over 3M+ photos (as of 20060907) marked up with the "geo" microformat.
* [http://ocono.com/ ocono.com] has marked each of it's "Upcoming Events" items with lat/long values.
* [http://harry.hchen1.com/mylife.htm Harry Chen has marked up his geo location]
* [http://www.multimap.com Multimap.com] uses the geo microformat to mark up latitude and longitude values on map pages.
* [http://rasterweb.net/raster/ Pete Prodoehl] geotags posts on his blog.
* [http://07.pagesd.info/ 07.pagesd.info] uses the geo microformat to mark up latitude and longitude values for each commune of the Ardèche département in France.
* [http://www.openguides.org/ OpenGuides] has support for the geo microformat in svn, and for now you can see it in action on the [http://cotswolds.openguides.org/ Cotswolds OpenGuide]
* [http://www.w3.org/People/Connolly/events/ Dan Connoly's Index of Events] has a few geos
** Notes that two of the geos are considered invalid because they use commas instead of semicolons

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

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

* [http://code.highearthorbit.com/greaseroute/index.php GreaseRoute] is a GreaseMonkey user script (also available as a simple Firefox Extension) which will add icons for displaying the MapQuest map of a [[geo]]. Written by [http://highearthorbit.com Andrew Turner]
* [http://www.podster.de/page/geotest podster.de] finds geo markups in podcast RSS Feeds and maps soundseeing episodes on a map (German only)
* [http://blog.codeeg.com/ Calvin Yu] has written a [http://blog.codeeg.com/2006/01/28/using-microformats-to-plot-my-favorite-places/ web service that will allow you plot and describe places on a Yahoo Map easily] using [[hreview|hReview]] and [[geo]].
* [http://bluesmoon.blogspot.com/ Philip Tellis] has written a [http://bluesmoon.blogspot.com/2006/01/of-microformats-and-geocoding.html javascript to add maps to geo markup on pages]
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding geos and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* [http://bluesmoon.blogspot.com/ Philip Tellis] has written some javascript to [http://bluesmoon.blogspot.com/2006/01/of-microformats-and-geocoding.html convert the geo microformat to a google map] using [[geo]].
* Brian Suda has written some [http://suda.co.uk/projects/microformats/geo/ geo extracting] code to convert geo microformats to KML for use with Google Maps and Google Earth. There is also a bookmarklet to extract the data and pass it to google maps automatically. He is working on a GeoRSS version for Yahoo! Maps as well.
* Fil explains [http://www.jquery.info/spip.php?article7 how to use the geo microformat with the javascript library jQuery] [http://jquery.com].
* [http://georss.org/geopress GeoPress] is a WordPress (http://wordpress.org) plugin that supports embedding adrs, geo, maps (dynamically switchable between Google-Yahoo-Microsoft Maps), and GeoRSS (http://georss.org) feeds. Written by [http://highearthorbit.com Andrew Turner]

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

=== Informative References ===
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426] ([http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426])
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.census.gov/geo/www/tiger/tigermap.html TIGER Map Service]
* [http://en.wikipedia.org/wiki/Geotagging Wikipedia article on GeoTagging]

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

== Related Work ==
* [[luna]] (proposal for geo-style microformat for co-ordinates on The Moon)
* [[mars]] (proposal for geo-style microformat for co-ordinates on the planet Mars)
* [[geo-extension-strawman]] - extends [[geo]] to include the above, and for representing coordinates on other planets, moons etc.
* [[thoughts-on-extending-the-geo-microformat|thoughts on addind time and reference system]] to the geo microformat, that could also be used for places on other celestial bodies

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

== See Also ==
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].
* [http://wikitravel.org/en/Wikitravel:Geocoding#Sources_for_lat.2Flongs Sources for latitude/ longitude coordinates]

== Related Pages ==

{{geo-related-pages}}
* Proposals for changes, additions and other thoughts about [[geo]] may be found in the [[hcard-brainstorming|hCard brainstorming]] page.
* If you have any questions about [[geo]], check the [[hcard-faq|hCard FAQ]] first, and if you don't find answers, add your questions! Odds are that any geo question will apply to hCard as well.

firefox-extensions

2007-01-09T23:12:02Z

MikeKaply: /* Operator */

A list of extensions for the [http://www.mozilla.com/ FireFox web browser], which detect or extract microformats.

==Current==

===Operator===

[https://addons.mozilla.org/firefox/4106/ Operator] has rapidly found favour with microformat developers (not least for its functions as a validator) and end-users. It provides an architecture for microformat parsing which is likely to be incorporated into the core of future versions of FireFox.

See also:
*[http://labs.mozilla.com/2006/12/introducing-operator Mozilla Labs' Operator announcement]
*[http://www.kaply.com/weblog/ Operator author's blog]
*[http://www.kaply.com/weblog/2006/12/over-at-labs Customise Operator]

The following niggles are thus relatively minor:

*Bug: [https://www2.blogger.com/comment.g?blogID=3488289&postID=952454745445946731 new links (from other apps) are opened in new Firefox windows rather than new tabs.]
** Fixed in next release: See [http://rbach.priv.at/Microformats-IRC/2007-01-05#T173801 IRC conversation of 2006-01-05]
*Bug: [https://www2.blogger.com/comment.g?blogID=3488289&postID=952454745445946731 tab bar is hidden when only one tab open]
** Fixed in next release: See [https://www2.blogger.com/comment.g?blogID=3488289&postID=952454745445946731 developer's blog comment (5th item down)]
*Not implemented: fn optimization
** Fixed in next release.
*Not implemented: include pattern (other than for hCard)
**Will be fixed in a future release

===Tails===
*[http://blog.codeeg.com/tails-firefox-extension-03/ Tails]
**[http://code.google.com/p/tails-firefox-extension/ Tails on Google Code]

===Web Developer===
While the [http://chrispederick.com/work/webdeveloper/ Web Developer extension] includes no microforamt-specific tools, it has several which greatly aid microformat publishers, not least the ability to display <code>class</code>, <code>ID</code>, <code>object</code> and <code>abbr</code> values in-line.

==Archaic==

===Tails Export===
*[https://addons.mozilla.org/firefox/2240/ Tails Export]
**'''Not yet compatible with FireFox 2.0+'''

==Forthcoming==

===BlueOrganiser===
* [http://www.adaptiveblue.com/ BlueOrganiser]
**'''plans''' to include microformats; see: [http://blog.adaptiveblue.com/?cat=31 Blue Organiser blog post about plans to use microformats]

===LinkAlert===
*[http://conlan89.googlepages.com/linkalert LinkAlert]
**Will consider adding rel in a future update.

===ReminderFox===
*[http://reminderfox.mozdev.org/ ReminderFox]
**Have hCalendar support on the [http://reminderfox.mozdev.org/userrequests.html ReminderFox "to do" list].

===Firefox developments===

Mozilla are "brainstorming" developments for Firefox 3.0 and beyond, and have [http://wiki.mozilla.org/Firefox/Feature_Brainstorming:Microformat_Handling a page on microformat handling]

==See also==
*[[bookmarklets]]
*[[greasemonkey]] - a powerful tool for customizing Firefox.
*[https://addons.mozilla.org/search.php?app=firefox&q=RSS RSS extensions] - for viewing hAtom feeds via third-party converters

firefox-extensions

2007-01-06T22:29:58Z

MikeKaply: /* Operator */

A list of extensions for the [http://www.mozilla.com/ FireFox web browser], which detect or extract microformats.

==Current==

===Operator===
*[https://addons.mozilla.org/firefox/4106/ Operator]
**See also [http://labs.mozilla.com/2006/12/introducing-operator Mozilla Labs Operator announcement]
**See also [http://www.kaply.com/weblog/index.html Operator author's blog]
**Bug: [https://www2.blogger.com/comment.g?blogID=3488289&postID=952454745445946731 new links (from other apps) are opened in new Firefox windows rather than new tabs.]
*** Fixed in next release: See [http://rbach.priv.at/Microformats-IRC/2007-01-05#T173801 IRC conversation of 2006-01-05]
**Bug: [https://www2.blogger.com/comment.g?blogID=3488289&postID=952454745445946731 tab bar is hidden when only one tab open]
*** Fixed in next release: See [https://www2.blogger.com/comment.g?blogID=3488289&postID=952454745445946731 developer's blog comment (5th item down)]
**Not implemented: fn optimization
*** Fixed in next release.

===Tails===
*[http://blog.codeeg.com/tails-firefox-extension-03/ Tails]
**[http://code.google.com/p/tails-firefox-extension/ Tails on Google Code]

==Archaic==

===Tails Export===
*[https://addons.mozilla.org/firefox/2240/ Tails Export]
**'''Not yet compatible with FireFox 2.0+'''

==Forthcoming==

===BlueOrganiser===
* [http://www.adaptiveblue.com/ BlueOrganiser]
**'''plans''' to include microformats; see: [http://blog.adaptiveblue.com/?cat=31 Blue Organiser blog post about plans to use microformats]

===ReminderFox===
*[http://reminderfox.mozdev.org/ ReminderFox]
**Have hCalendar support on the [http://reminderfox.mozdev.org/userrequests.html ReminderFox "to do" list].

===Firefox developments===

Mozilla are "brainstorming" developments for Firefox 3.0 and beyond, and have [http://wiki.mozilla.org/Firefox/Feature_Brainstorming:Microformat_Handling a page on microformat handling]

==See also==
*[[bookmarklets]]
*[[greasemonkey]] - a powerful tool for customizing Firefox.
*[https://addons.mozilla.org/search.php?app=firefox&q=RSS RSS extensions] - for viewing hAtom feeds via third-party converters

irc-people

2007-01-05T15:38:26Z

MikeKaply: /* unsorted */

A list of [[irc|IRC]] regulars sorted by nick and their normal timezones (winter/summer).

* [[User:Adam Craven|AdamCraven]] (+0000)
* [[User:Amette|amette]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)
* [[User:Ben Ward|BenWard]] (+0000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:BenWest|bewest]] (-0800/-0700)
* [[User:Bob Jonkman|BobJonkman]] (-0500/-0400)
* [[User:Boneill|boneill]] (+0000)
* [[User:Brian|briansuda]] (+0000)
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)
* [[User:Cgriego|cgriego]] (-0600/-0500)
* [[User:CharlesRoper|charles_r]] (0000/+0100)
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)
* [[User:ChristopherStJohn|cks]] (-0600/-0500)
* [[User:Cloud|Cloud]] (+0000)
* [[User:Csarven|csarven]] (-0500/-0400)
* [[User:DanC|DanC]] (-0600/-0500)
** office hours: Wednesday afternoons, America/Chicago time
* [[User:DannyAyers|danja]] (+0100/+0200)
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:DeanEro|deanero]] (-0800/-0700)
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)
* [[User:EdwardOConnor|hober]] (-0800/-0700)
* [[User:Enric|enric]] (-0800/-0700)
* [[User:Evan|evanpro]] (-0500)
* [[User:Fil|Fil]] (+0200)
* [[User:Grantbow|Grantbow]] (-0800/-0700)
* [[User:Hlb|hlb]] (+0800-0700)
* [[User:IanHickson|Hixie]] (-0800/-0700)
* [[User:Izo|IZO]]
* [[User:JamieKnight|jammie_]] (+1000/0000)
* [[User:JoeGregorio|jcgregorio]]
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)
* [[User:JasonK|jkridner]]] (-0600/-0500)
* [[User:Kapowaz|kapowaz]] (+0000/+0100)
* [[User:Keri Henare|kerihenare]] (+1200)
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* [[User:Lachlan Hunt|Lachy]] (+1000/+1100)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)
* [[User:CiaranMc|McNulty]] (+0000/+0100)
* [[User:SteveIvy|monkinetic/redmonk]] (-0700)
* [[User:neuro|neuro`]]
* [[User:NTollervey|ntoll]] (+0000/+0100)
* [[User:Phae|Phae]] (+0000/+0100)
* [[User:PriitLaes|plaes]] (+0200/+0300)
* [[User:DavidOsolkowski|qid]] (-0500)
* [[User:Remi|Remi]] (-0500/-0400)
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)
* [[User:Ronnos|Ron Kok]] (+0000)
* [[User:RyanKing|kingryan]] (-0800/-0700)
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* [[User:Dana Benson|Snowden]] (-0800/-0700)
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)
* [[User:Tantek|Tantek]] (-0800/-0700)
* [[User:Trovster|trovster]] (-0800/-0700)
* [[User:Tyler|Tyler Roehmholdt]] (-0800/-0700)
* [[User:Vant|vant]] (+0900)
* [[User:Veeliam|William Lawrence]] (-0800/-0700)

== unsorted ==
* [[User:Dan Kubb|dkubb]] (-0800/-0700)
* [[User:Ed Summers|edsu]] (-0500/-0400)
* [[User:Smackman|Steve Farrell]] (-0800/-0700)
* [[User:Enric|Enric]] (-0800/-0700)
* [[User:Charlvn|Charl]] (+0200/+0200)
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)
* [[User:IwaiMasaharu|iwaim]] (+0900)
* [[User:Richard Conyard|WhiskeyM]] (+0000)
* [[User:Ianloic|yakk]] (-0800/-0700)
* [[User:Ashley|Ashley]] (+1000)
* [[User:SuperPhly|SuperPhly]] (-600/-500)
* [[User:Colin_Barrett|cbarrett]] (-1000)
* [[User:HenriBergius|bergie]] (+0200/+0300)
* [[User:JacksonWilkinson|whafro]] (-0500/-0400)
* [[User:Adactio|Jeremy Keith]] (+0000)
* [[User:JulianStahnke|Julian Stahnke]] (+0000)
* [[User:MikeKaply|mkaply]] (-0600/-0500)

include-pattern-feedback

2007-01-03T17:08:06Z

MikeKaply: /* Parsing for include-pattern */

= Include Pattern Feedback =

Feedback about [[include-pattern]].

== Objects and Browser Behavior ==

Over at Yahoo! Local, we were using the object include pattern for all our hReviews on business detail pages and review listings. That is, until we realized that Safari and Internet Explorer both try to embed the entire page with every OBJECT call. (Firefox correctly recognizes that it's a local object and doesn't reload anything.)

On a page with 20+ reviews, this means a substantial increase in load time and memory consumption. As a result of this (bad) browser behavior, we removed the objects entirely.

Any suggestions for workarounds or modifications to the pattern?

-- AndyBaio 29 Jun 2006

Can you use the hyperlink option with DHMTL/Ajax to perform replacements in advanced browsers? (Simon Willison's <code>[http://simon.incutio.com/archive/2003/03/25/getElementsBySelector getElementsBySelector()]</code> may be helpful)
<a href="#id" class="include" title=""></a>
with something like:
//Works only for linked include-pattern definition at microformats.org
//Requires Simon Willison's getElementsBySelector()
// and normal IE workaround for addEventListener()
addEventListener( window, 'load', function() {
var myIncludes = document.getElementsBySelector( 'a[href].include' ), a, e;
for( var i=0; a=myIncludes[i]; i++ ) if (a.href.charAt(0)=='#') {
e = document.getElementsBySelector( a.href )[0].cloneNode( true );
a.parentNode.replaceChild( e, a );
}
})
--[[User:RichHall|RichHall]] 00:51, 23 Oct 2006 (PDT)

My hResume page [http://robert.o-rourke.org seen here] caused Safari <ins>2.0</ins> some major issues. The page was jumping between object elements when a link was hovered eventually causing the browser to crash. You can follow the thread on the [http://www.mail-archive.com/listdad%40webstandardsgroup.org/msg06078.html WSG mail archive].

It seems that while the object element may be more semantically appropriate it <del>is not</del> <ins>may not be</ins> usable in lieu of the issues raised in Safari.

--[[User:SanchoTheFat|Robert O'Rourke]] 12:08, 3 Nov 2006 (PST)

Which version of Safari? Please be specific as many Safari OBJECT bugs were fixed in Safari 2.x.

-- [[User:Tantek|Tantek]] 13:39, 3 Nov 2006 (PST)

== Hyperlink Include - Screen Reader Testing ==

Some [http://microformats.org/discuss/mail/microformats-discuss/2006-July/004693.html concerns have been raised] over the implications using empty hyperlinks may have on assistive devices such as screen readers. One concern is that an empty link may be read out, partially read out or result in some other confusing scenario for the user.

In response, a [http://allinthehead.com/demo/include.html test page] consisting of a number of empty hyperlinks in the style suggested by the pattern has been created. A 'good' result is that none of the links be read out.

=== Test Results: JAWS 7.0 with Firefox 1.5/Win ===

Tested by [[User:Phae|Frances Berriman]] 2006-07-21.

* 31 dash include dash Mozilla Firefox
* Page has no links
* 31 dash include

Conclusion: the hyperlink include pattern presented no usability issues for this screen reader.

=== Proprietary attribute ===
HTML tidy on the [http://allinthehead.com/demo/include.html test page] gives:
:Warning: <a> proprietary attribute "data"

The [http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fallinthehead.com%2Fdemo%2Finclude.html W3C validator is similarly unimpressed].

[[User:AndyMabbett|AndyMabbett]] 14:22, 22 Oct 2006 (PDT)

==== Use href ====
To clarify, links on the [http://allinthehead.com/demo/include.html test page] should be changed to use the <code>href</code> attribute as described at [[include-pattern]] (without <code>href</code> attributes, the elements probably won't register as hyperlinks, but anchors). Set <code>title=""</code> to fix empty link behavior for many assistive devices. --[[User:RichHall|RichHall]] 23:31, 22 Oct 2006 (PDT)

==== Test page corrected ====
2006-10-25: This error has been corrected on the [http://allinthehead.com/demo/include.html test page]. Any tests should probably be re-run in light of this.

== Unclear status ==

It's not clear, either from the main Wiki page or [[include-pattern]], whether this is an agreed standard, a draft, or just a proposal. [[User:AndyMabbett|AndyMabbett]] 03:14, 18 Oct 2006 (PDT)

* [[include-pattern]] is not its own proposal, draft, or spec. It is a design pattern, as listed on the [[Main_Page|wiki home page]] that is included in other proposals, drafts. and specs. ''Recommend for adding to the [[include-pattern-faq]].
**And that is not clear, either from the main Wiki page or [[include-pattern]]. [[User:AndyMabbett|AndyMabbett]] 16:40, 18 Oct 2006 (PDT)
***ACCEPTED. Will further clarify relationship between patterns and formats. [[User:Tantek|Tantek]] 16:48, 18 Oct 2006 (PDT)

==Parsing for include-pattern==

''Note: this issue is obsolete. On a IRC conversation 2007-01-03, Mike Kaply admitted that he figured this out, which is to apply all includes first into the parse tree before looking for any properties. -Tantek''

''To be more specific, what finally occurred to me is that the object pattern is simply about grabbing nodes from another vcard and using them in this vcard. So the implementor responsibility is just to clone the dom node from the other vcard and replace the object with the corresponding nodes. Works great. (of course I also had to clone the entire vcard since I can't manipulate the DOM like that without changing the page) -mkaply''

In an [http://rbach.priv.at/Microformats-IRC/2007-01-02#T205847 IRC discussion] with [http://www.kaply.com/weblog/ Mike Kaply] (author of the [https://addons.mozilla.org/firefox/4106/ Operator] extension for Firefox) we discussed the difficulty of parsing for an [[include-pattern]] in [[hresume|hResume]]. Mike asks:
<blockquote>I'm really wondering why the <code>object</code> stuff doesn't point back to the entire vCard. I don't understand why the spec has it point to individual items.</blockquote>
The problem was thought to be a weakness in the specification, which doesn't specify what part of the data is in the content that is pointed to by the <code>object</code>.

Currently, to overcome this a parser needs to follow this logic:
::IF I don't find an <code>fn</code>, look for an <code>object</code>. IF there is an <code>object</code>, do a <code>getelementbyid</code> on that <code>ID</code>, but yet there was nothing about that <code>object</code> that said that the content I was looking for in the other card was an <code>fn</code>

Two things may help in overcoming this difficulty:

# Change the spec to have the include-pattern reference the entire vCard, with the intent that any data not found in this vCard use the other vCard
# Include the element of the reference, where the class attribute on <code><object></code> has "include" plus the element that needs to be included. For example:
<pre><nowiki><object
class="include fn" data="#vcard-name">myname</object> </nowiki></pre>

Additionally, I pointed out that using the <code><object></code> element to contain the reference makes Microsoft's Internet Explorer throw an error "Your current security settings prohibit ActiveX controls on this page. As a result, the page may not display correctly." Of course, there is no ActiveX content on an include-pattern.

[[User:Bob Jonkman|Bob Jonkman]] 21:15, 2 Jan 2007 (PST)

rel-tag

2006-12-23T21:38:59Z

MikeKaply: /* Implementations */

<h1> rel-tag </h1>

__TOC__

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

[http://epeus.blogspot.com/ Kevin Marks]

=== Concept ===
[http://powazek.com/ Derek Powazek]

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

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

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

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

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

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

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

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

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

rel="tag" is NOT designed for "tagging" arbitrary URLs or external content. There is demand for a general decentralized syntax for tagging URLs external to the current page, but this is not meant for that. See [[xfolk|xFolk]] and [[hreview|hReview]] for ways to tag arbitrary URLs.

If you need to define tags as part of a more specialised format, rel="tag" is the recommended way to do so, and [[xfolk|xFolk]], [[hreview|hReview]], [[hcard |hCard]] and [[hcalendar|hCalendar]] all do this.
== XMDP profile ==
<pre><nowiki>
<dl class="profile">
<dt id="rel">rel</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value.</p>
<dl>
<dt id="tag">tag</dt>
<dd>Indicates that the referred resource serves as a "tag",
or keyword/subject, for the referring page.</dd>
</dl>
</dd>
</dl>
</nowiki></pre>

== Tag Spaces ==

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

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

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

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

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

is a URL for the tag "tech".

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

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

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

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

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

Trailing slashes in tag URLs are ignored, that is:

<pre><nowiki> http://technorati.com/tag/Technology/ </nowiki></pre>
as a rel-tag URL is treated as:
<pre><nowiki> http://technorati.com/tag/Technology </nowiki></pre>

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

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

Note that if using Wikipedia as a tagspace, as discussed above, you should use <code>%20</code> as they remap '+' to <code>%2B</code>, causing a page with a plus sign in the title (which usually does not exist) to appear.

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

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

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

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

The following sites have implemented rel-tag, and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc. If your site marked up with rel-tag, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* [http://yedda.com Yedda] - Yedda publishes rel-tags for all of the tags the people entered on themselves as well as on all tags entered on questions asked on Yedda.
* [http://www.lingr.com Lingr] publishes rel-tags for all user entered tags.
* [http://odeo.com ODEO] [http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html publishes] rel-tags for user entered tags.
* [http://evdb.com EVDB] publishes rel-tags for user entered tags.

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

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

* Nutch has a [[rel-tag]] parser [http://www.mail-archive.com/nutch-commits@lucene.apache.org/msg01014.html committed to their svn repository].
* [http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver Extension suite] from the [http://webstandards.org/ Web Standards Project] enables rel-tagging from within Dreamweaver 8.
* [http://scooch.gr0w.com/ Scooch] slide show creator allows authors to generate rel-tags and group slide shows by rel-tag via a list or cloud with tag usage count.
* The Freetag plugin for the [http://www.s9y.org Serendipity] blog software supports rel-tags on a per-entry basis, as well as inside of its tag clouds. (The Freetag plugin is available inside of SPARTACUS)
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding rel-tags and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* [http://www.truist.com/blog/493/trutags-a-tagging-plugin-for-textpattern tru_tags] is a plugin for [http://textpattern.com/ Textpattern] that supports rel-tagging blog posts via the Keywords field.
* [http://news.livejournal.com/86492.html?thread=24881884 LiveJournal] - see also [http://www.livejournal.com/support/faq.bml?cat=tags their FAQ regarding their tags support]
* [http://trac.labnotes.org/cgi-bin/trac.cgi/wiki/TagsLinks TagsLinks] Turn each tag into links that let you find related content on tagging services.
* [http://dev.wp-plugins.org/wiki/BunnysTechnoratiTags Tag plugin for WordPress]
** Note that some sites using WordPress (http://microformatique.com/ for instance) are getting incorrect tags. The tag is ?cat=12 instead of the actual tag value.
* [http://noone.org/blog/tags/Tagging Tag plugin for Blosxom]
* Technorati first implemented rel-tag in its [http://technorati.com/tag/ Technorati Tags] service. Technorati indexes rel-tag tags.
* [http://consumingexperience.blogspot.com/2005/12/updated-multiple-word-technorati-tag.html Greasemonkey script for Firefox that generates tags for Blogger]
* [http://tools.microformatic.com/help/xhtml/rel-lint/ rel-lint] is a validation tool by [[User:DrewMcLellan|Drew McLellan]] that will validate existence of rel-tag attributes.

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

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

== Discussions ==
* Feedback is encouraged on the [[rel-tag-feedback]] page.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].
* History: [http://www.powazek.com/2005/07/000532.html How Tags Happened at Technorati] by [http://www.powazek.com/ Derek Powazek]

=== Q&A ===
* If you have any questions about rel-tag, check the [[rel-faq|rel FAQ]] first for general rel attribute questions, then check the [[rel-tag-faq|rel-tag FAQ]], and then if you don't find answers, ask your question on the [http://microformats.org/discuss microformats-discuss] mailing list.

==Related pages==
{{rel-tag-related-pages}}

hcard-examples-rfc2426

2006-12-13T20:27:03Z

MikeKaply:

<h1>hCard examples</h1>

Example [[hcard|hCards]].

== Authors ==
* [http://tantek.com/log Tantek Çelik]
* Brian Suda

== Instructive Examples ==

=== Authors of Pages and Posts ===
[http://www.w3.org/TR/html401/struct/global.html#h-7.5.6 Per the HTML4.01 specification], authors should be using the <code><address></code> element to indicate the "contact information for a document or a major part of a document." E.g.

<pre><nowiki>
<address>
<a href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

By adding [[hcard|hCard]] to such existing semantic XHTML, you can explicitly indicate the name of the person, their URL, etc.:

<pre><nowiki>
<address class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

This could be displayed as:

[http://tantek.com/ Tantek Çelik]

This works not only for whole pages, but also for "major part[s]" of pages, e.g. blog posts.

See the [http://microformats.org/blog/ microformats.org blog] (view the source) for a live example. The author of every blog post on the microformats.org blog is marked up as an <code><address class="vcard"></code> element like the example shown above.

=== References to People and Organizations ===

A common pattern in blog posts is to link mentions of people's names to their blogs, and/or organizations to their home pages. E.g.:

<pre><nowiki>
<cite><a href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<a href="http://irs.gov/">Internal Revenue Service</a>.
</nowiki></pre>

By adding hCard to such markup, you can explicitly indicate both the person and the organization by name and URL:

<pre><nowiki>
<cite class="vcard"><a class="fn url" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

Note the class names "fn org url" on the hyperlink surrounding the IRS. Using the same value (or element for that matter) for "fn" and "org" indicates that the hCard describes an organization rather than a person.

This could be displayed as:

''[http://meyerweb.com/ Eric Meyer]'' wrote a post (''[http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/ Tax Relief]'') about an unintentionally humorous letter
he received from the [http://irs.gov/ Internal Revenue Service].

=== hCard and XFN ===
==== References to People in Blog Posts ====

In the above example, one person (the blogger) is referring to another person (Eric Meyer). In addition to using hCard to explicitly mark up the reference as a person, the blogger can use [http://gmpg.org/xfn/ XFN] (the XHTML Friends Network) to indicate their relationship to Eric Meyer, e.g.:

<pre><nowiki>
<cite class="vcard"><a class="fn url" rel="friend colleague met" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

It would be displayed the same as the previous example.

==== References to People in Blogrolls ====

Many bloggers are using XFN (often using an easy user interface like that built into [http://wordpress.org WordPress]) to explicitly indicate their relationships to the people in their blogrolls:

<pre><nowiki>
<ul>
<li><a href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li><a href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

By adding hCard markup to an XFN Friendly blogroll, you can explicitly indicate the name and URL of the person in addition to their relationship:

<pre><nowiki>
<ul>
<li class="vcard"><a class="fn url" href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li class="vcard"><a class="fn url" href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

This could be displayed as:
* [http://meyerweb.com Eric Meyer]
* [http://photomatt.net Matt Mullenweg]

For more information on XFN, see the [http://gmpg.org/xfn/ XFN home page], [http://gmpg.org/xfn/join joining XFN], and [http://gmpg.org/xfn/background background on XFN].

This technique is used in the [http://factorycity.net/projects/wp-microformatted-blogroll/ WP Microformatted Blogroll] plugin.

=== New Types of Contact Info ===

Since vCard was designed, there have been numerous other services that provide individuals with addresses or other means of contact, e.g. instant messaging, voip, etc.

Does this mean that vCard (and hence hCard) must be extended to represent these?

Thanks to the flexibility of the URL property, the answer is no, no extensions are necessary. Instead, we use the proper URL for the service which identifies the service (protocol, machine, and/or path), and place the individual's address inside that.

==== AOL Instant Messenger (AIM) ====

AOL Instant Messenger (AIM) ids can be represented using the <code>aim:</code> protocol. Many who publish their AIM ids do so with clickable URLs e.g.:

<pre><nowiki>
<a href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

Thus for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

==== Yahoo Messenger ====

Similarly, Yahoo Instant Messenger (YIM) ids can be represented using the <code>ymsgr:</code> protocol. And similarly many publish their YIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

Again, for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

==== MSN Messenger ====

<strike>Unfortunately, AFAIK, there is no hacked up defacto protocol for opening an MSN IM session with an MSN userid (which themselves are just email addresses). Thus we must simply resort to marking them up as email addresses, and expect that consumers may use some heuristic, such as "hotmail.com email addresses are also MSN IM ids". -Tantek</strike>

MSN Messenger (MSNIM) ids can be represented using the <code>msnim:</code> protocol. And similarly many publish their MSNIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

For hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

Updated 14 May 2006 - [http://www.wackomenace.co.uk/ Ruben]

Ruben, I tried this, and "msnim:" is an unrecognized protocol on MacOSX.4 (this is with the latest MSN Messenger for Mac installed and running and logged int). Could you provide links to documentation about "msnim:" and links to actual pages that publish their MSNIM ids this way? I don't know of any - [http://tantek.com/ Tantek]

: Tantek, Wikipedia's [http://en.wikipedia.org/wiki/History_of_Windows_Live_Messenger History of Windows Live Messenger] states that MSN Messenger 7.5 for Windows, among other things, introduced: "the msnim protocol handler, allowing Web sites to provide links which automatically add a contact or start conversations (for example clicking on link msnim:chat?contact=login@passport.net will start chat conversation with user login@passport.net).". The Mac version is notoriously lagging behind, sadly. --''[[User:Chucker|chucker]] 11:33, 29 Jun 2006 (PDT)''

It also seems that the msnim protocol handler in only supported by Microsoft Internet Explorer 7 (haven't tried earlier versions) on Windows. Latest versions of Firefox, Opera and Netscape Navigator doesn't recognize the protocol. Well, for at least, not at the moment. - [http://www.juhaliikala.com/ Juha Liikala]

==== XMPP (Jabber) ====

[http://www.xmpp.org/ Extensible Messaging and Presence Protocol (XMPP)] ids can be represented using the <code>xmpp:</code> protocol, e.g.:

<pre><nowiki>
<a class="url" href="xmpp:username@jabberservice.com">IM with username@jammerservice.com</a>
</nowiki></pre>

The protocol allows much richer URLs, see [http://www.faqs.org/rfcs/rfc4622.html RFC4622].

There are not many current [http://wiki.jabber.org/index.php/XMPP_URIs#Jabber_Clients clients supporting the protocol].

==== Skype ====

Skype can be represented using the <code>skype:</code> protocol. It can be used to open a chat session or make a Skype call.

<pre><nowiki>
<a href="skype:echo-chinese?chat">IM with the Skype echo service (Chinese) </a>
</nowiki></pre>

<pre><nowiki>
<a href="skype:echo-chinese?call">Skype call to Skype echo service (Chinese) </a>
</nowiki></pre>

Thus for hCard, we could adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="skype:echo-chinese?chat">IM with the Skype echo service (Chinese)</a>
</nowiki></pre>

<pre><nowiki>
<a class="url" href="skype:echo-chinese?call">Skype call to Skype echo service (Chinese)</a>
</nowiki></pre>

==== Site profiles ====
Bloggers often indicate their identity on content hosting services using the URL to their home page, feed or profile on those services. By labeling them as URL properties, these additional facets of identity can be publish in an hCard as well.

* [http://del.icio.us delicious]:
** <code><a class="url" href="http://del.icio.us/rbach">Robert Bachmann's links</a></code>
* [http://flickr.com Flickr]:
** <code><a class="url" href="http://flickr.com/photos/tantek/">See my photos</a></code>
** <code><a class="url" href="http://flickr.com/people/tantek/">Flickr profile</a></code>
* [http://technorati.com/ Technorati]:
** <code><a class="url" href="http://technorati.com/profile/tantek/">Technorati profile</a></code>
* Add more here...
** ....

=== Organizations and Departments ===

Departments are marked up using the "organization-unit" class name inside the "org" element, with the "organization-name" specifically marked up to distinguish it from the department:

<pre><nowiki>
<div class="vcard">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit">Apprenticeship Training Center</div>
</div>
</div>
</nowiki></pre>

The department may also be part of the address, in which case, you may want to explicitly mark it up as the "extended-address" in addition to the "organization-unit".

<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit extended-address">Apprenticeship Training Center</div>
</div>
<div class="street-address">2531 Barrington Court</div>
<span class="locality">Hayward</span>,
<abbr title="California" class="region">CA</abbr>
<span class="postal-code">94545</span>
</div>
</div>
</nowiki></pre>

Note that by nesting the org inside the address we avoided having to duplicate the department name.

== RFC 2426 examples in hCard ==

These are 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

Mark Pilgrim has made these hCard examples available as separate files:
* http://diveintomark.org/projects/greasemonkey/hcard/tests/

=== 2.4.2 VCARD ===

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n
TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERNET:\n
jfriday@host.com\nEND:VCARD\n
</nowiki></pre>

This vCard fragment has one property whose value is another vCard, and could be represented as an hCard fragment with an embedded hCard, literally (with the unnecessary type=internet default omitted, and the implied n optimization):

<pre><nowiki>
<div class="agent vcard">
<a class="email fn" href="mailto:jfriday@host.com">Joe Friday</a>
<div class="tel">+1-919-555-7878</div>
<div class="title">Area Administrator, Assistant</div>
</div>
</nowiki></pre>

this hCard could be displayed as:

[mailto:jfriday@host.com Joe Friday]<br />
+1-919-555-7878<br />
Area Administrator, Assistant

=== 3.1.1 FN Type Definition ===

<pre><nowiki>
FN:Mr. John Q. Public\, Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">Mr. John Q. Public, Esq.</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Q. Public, Esq.

=== 3.1.2 N Type Definition ===

==== Example 1 ====

<pre><nowiki>
N:Public;John;Quinlan;Mr.;Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-name">Quinlan</span>
<span class="family-name">Public</span>,
<span class="honorific-suffix">Esq.</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Quinlan Public, Esq.

==== Example 2 ====

<pre><nowiki>
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Dr.</span>
<span class="given-name">John</span>
<span class="additional-name">Philip</span>
<span class="additional-name">Paul</span>
<span class="family-name">Stevenson</span>,
<span class="honorific-suffix">Jr.</span>,
<span class="honorific-suffix">M.D.</span>,
<span class="honorific-suffix">A.C.P.</span>
</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Dr. John Philip Paul Stevenson, Jr., M.D., A.C.P.

=== 3.1.3 NICKNAME Type Definition ===

==== Example 1 ====

<pre><nowiki>
NICKNAME:Robbie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Robbie</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Robbie

==== Example 2 ====

<pre><nowiki>
NICKNAME:Jim,Jimmie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Jim</span>,
<span class="nickname">Jimmie</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Jim, Jimmie

=== 3.1.4 PHOTO Type Definition ===

==== Example 1 ====
<pre><nowiki>
PHOTO;VALUE=uri:http://www.abc.com/pub/photos/jqpublic.gif
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<img class="photo" src="http://www.abc.com/pub/photos/jqpublic.gif" alt="" />
</nowiki></pre>

==== Example 2 ====
<pre><nowiki>
PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment (line breaks inserted into src value for readability):

<pre><nowiki>
<img class="photo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

=== 3.1.5 BDAY Type Definition ===

==== Example 1 ====

<pre><nowiki>
BDAY:1996-04-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>

==== Example 2 ====

<pre><nowiki>
BDAY:1953-10-15T23:10:00Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>

==== Example 3 ====

<pre><nowiki>
BDAY:1987-09-27T08:30:00-06:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>

=== 3.2.1 ADR Type Definition ===

<pre><nowiki>
ADR;TYPE=dom,home,postal,parcel:;;123 Main
Street;Any Town;CA;91921-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>
</nowiki></pre>

this hCard fragment could be displayed as:

<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>

=== 3.2.2 LABEL Type Definition ===

<pre><nowiki>
LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA 91921-1234
\nU.S.A.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Please use the following address label for
<div class="label">
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>
</div>
</nowiki></pre>

'''Note:''' the above hCard fragment uses a <pre> tag inside a property value to capture/represent explicit carriage returns ("\n" characters) from the vCard fragment.

this hCard fragment could be displayed as:

Please use the following address label for
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>

=== 3.3.1 TEL Type Definition ===

<pre><nowiki>
TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tel">
<abbr class="type" title="pref">my</abbr>
<span class="type">work</span>
<abbr class="type" title="voice">phone</abbr>, with
<abbr class="type" title="msg">voicemail</abbr>:
<span class="value">+1-213-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

my work phone, with voicemail: +1-213-555-1234

=== 3.3.2 EMAIL Type Definition ===

==== Example 1 ====

<pre><nowiki>
EMAIL;TYPE=internet:jqpublic@xyz.dom1.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jqpublic@xyz.dom1.com">email jqpublic</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jqpublic@xyz.dom1.com email jqpublic]

==== Example 2 ====

<pre><nowiki>
EMAIL;TYPE=internet:jdoe@isp.net
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jdoe@isp.net">email jdoe</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jdoe@isp.net email jdoe]

==== Example 3 ====

<pre><nowiki>
EMAIL;TYPE=internet,pref:jane_doe@abc.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jane_doe@abc.com">
<abbr class="type" title="pref">preferred</abbr>
email for jane_doe
</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jane_doe@abc.com preferred email for jane_doe]

=== 3.3.3 MAILER Type Definition ===

<pre><nowiki>
MAILER:PigeonMail 2.1
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.
</nowiki></pre>

this hCard fragment could be displayed as:

Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.

=== 3.4.1 TZ Type Definition ===

==== Example 1 ====

<pre><nowiki>
TZ:-05:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tz">-05:00</span>
</nowiki></pre>

this hCard fragment could be displayed as:

-05:00
==== Example 2 ====

<pre><nowiki>
TZ;VALUE=text:-05:00; EST; Raleigh/North America
;This example has a single value, not a structure text value.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="tz"
title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">
EST
</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="tz" title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">EST</abbr>

=== 3.4.2 GEO Type Definition ===

<pre><nowiki>
GEO:37.386013;-122.082932
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="geo">
<span class="latitude">37.386013</span>,
<span class="longitude">-122.082932</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

37.386013, -122.082932

=== 3.5.1 TITLE Type Definition ===

<pre><nowiki>
TITLE:Director\, Research and Development
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="title">Director, Research and Development</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Director, Research and Development

=== 3.5.2 ROLE Type Definition ===

<pre><nowiki>
ROLE:Programmer
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="role">Programmer</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Programmer

=== 3.5.3 LOGO Type Definition ===

==== Example 1 ====

<pre><nowiki>
LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="http://www.abc.com/pub/logos/abccorp.jpg" alt="my logo" />
</nowiki></pre>

this hCard fragment could be displayed as (note: I used a real URL for the image):

http://microformats.org/img/mf-lg-ora.gif

==== Example 2 ====

<pre><nowiki>
LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.5.4 AGENT Type Definition ===

==== Example 1 ====

<pre><nowiki>
AGENT;VALUE=uri:
CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="agent" href="CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com">JQPUBLIC</a>
</nowiki></pre>

this hCard fragment could be displayed as:

JQPUBLIC

==== Example 2 ====

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555-
1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="agent vcard">
<a class="email fn n" href="mailto:sthomas@host.com">Susan Thomas</a>,
<span class="tel">+1-919-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:sthomas@host.com Susan Thomas], +1-919-555-1234

Note: the vCard in the AGENT property vCard fragment is actually invalid since it lacks an "N" property. However, the hCard version *is* valid, since I added the "n" class name to the example.

=== 3.5.5 ORG Type Definition ===

<pre><nowiki>
ORG:ABC\, Inc.;North American Division;Marketing
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="org">
<span class="organization-name">ABC, Inc.</span>,
<span class="organization-unit">North American Division</span>,
<span class="organization-unit">Marketing</span>,
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

ABC, Inc., North American Division, Marketing

=== 3.6.1 CATEGORIES Type Definition ===

==== Example 1 ====

<pre><nowiki>
CATEGORIES:TRAVEL AGENT
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">TRAVEL AGENT</span>
</nowiki></pre>

this hCard fragment could be displayed as:

TRAVEL AGENT

==== Example 2 ====

<pre><nowiki>
CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">INTERNET</span>,
<span class="category">IETF</span>,
<span class="category">INDUSTRY</span>,
<span class="category">INFORMATION TECHNOLOGY</span>
</nowiki></pre>

this hCard fragment would be displayed as:

INTERNET, IETF, INDUSTRY, INFORMATION TECHNOLOGY

=== 3.6.2 NOTE Type Definition ===

<pre><nowiki>
NOTE:This fax number is operational 0800 to 1715
EST\, Mon-Fri.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<p class="note">This fax number is operational 0800 to 1715 EST, Mon-Fri.</p>
</nowiki></pre>

this hCard fragment could be displayed as:

This fax number is operational 0800 to 1715 EST, Mon-Fri.

=== 3.6.3 PRODID Type Definition ===

<pre><nowiki>
PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
</nowiki></pre>

Note, this vCard property actually doesn't make sense as a hCard property, since it really should be filled in by whatever code transforms the hCard into a vCard, e.g. Brian Suda's X2V.

=== 3.6.4 REV Type Definition ===

==== Example 1 ====

<pre><nowiki>
REV:1995-10-31T22:27:10Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>

==== Example 2 ====

<pre><nowiki>
REV:1997-11-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>

=== 3.6.5 SORT-STRING Type Definition ===

==== Example 1 ====

<pre><nowiki>
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Harten
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n"
<span class="honorific-prefix">Sir</span>
<span class="fn">
<span class="given-name">Rene</span>
<span class="family-name">
van der <span class="sort-string">Harten</span>
</span>
</span>
(<span class="additional-name">J.</span>),
<span class="honorific-suffix">R.D.O.N.</span>
</span>
</nowiki></pre>

Note: The string "Harten" was NOT repeated in the hCard, even though it WAS repeated in the vCard (3 times! In N, FN, and SORT-STRING). The "SORT-STRING" property provides another good demonstration of how hCard enables better adherence to the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] than vCard.

this hCard fragment could be displayed as:

Sir Rene van der Harten (J.), R.D.O.N.

==== Example 2 ====

<pre><nowiki>
FN:Robert Pau Shou Chang
N:Pau;Shou Chang;Robert
SORT-STRING:Pau
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn n">
<span class="additional-name">Robert</span>
<span class="family-name sort-string">Pau</span>
<span class="given-name">Shou Chang</span>
</span>
</nowiki></pre>

Note: Not only was the string "Pau" was NOT repeated in the hCard (better [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] adherence again), even though it WAS repeated in the vCard, but in this case since the "family-name" and "sort-string" are the same, we were able to use [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_2:_element_conservation element conservation] and use only one element for both properties.

this hCard fragment could be displayed as:

Robert Pau Shou Chang

==== Example 3 ====

<pre><nowiki>
FN:Osamu Koura
N:Koura;Osamu
SORT-STRING:Koura
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Osamu <span class="sort-string">Koura</span>
</span>
</nowiki></pre>

Note: This example, in addition to illustrating better support for the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle], also makes use of the [http://microformats.org/wiki/hcard#Implied_.22N.22_Optimization Implied "N" Optimization].

this hCard fragment could be displayed as:

Osamu Koura

==== Example 4 ====

<pre><nowiki>
FN:Oscar del Pozo
N:del Pozo Triscon;Oscar
SORT-STRING:Pozo
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="fn">
<span class="given-name">Oscar</span>
del <span class="sort-string">Pozo</span>
</span>
<span class="family-name" style="display:none">
del Pozo Triscon
</span>
</span>
</nowiki></pre>

Note: This example unfortunately could not completely adhere to the DRY principle due to the "FN" using a *substring* of the family-name, and in addition thus had to hide the extra "family-name" string value using CSS display:none, which in general should be avoided. Suggestion welcome for improvements on this hCard fragement.

this hCard fragment could be displayed as:

Oscar del Pozo

==== Example 5 ====

<pre><nowiki>
FN:Christine d'Aboville
N:d'Aboville;Christine
SORT-STRING:Aboville
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Christine d'<span class="sort-string">Aboville</span>
</span>
</nowiki></pre>

Note: This example re-demonstrates the same hCard advantages/efficiencies demonstrated in [http://microformats.org/wiki/hcard-examples#Example_3_3 example 3] above.

this hCard fragment could be displayed as:

Christine d'Aboville

=== 3.6.6 SOUND Type Definition ===

==== Example 1 ====

<pre><nowiki>
SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8.
19960229T080000.xyzMail@host1.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound" type="audio/basic"
data="CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@host1.com">
pronounciation of "JOHN Q PUBLIC"
</object>
</nowiki></pre>

this hCard fragment would probably be displayed as

pronounciation of "JOHN Q PUBLIC"

unless your browser supports the MIME type "audio/basic" (defined in [http://www.rfc-editor.org/rfc/rfc2046.txt RFC2046 section 4.3]) and has some way of retrieving "CID:" urls.

==== Example 2 ====
<pre><nowiki>
SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound"
data="data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...the remainder of "B" encoded binary data...">
pronounciation
</object>
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.6.7 UID Type Definition ===

<pre><nowiki>
UID:19950401-080045-40000F192713-0052
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
Unique id:
<span class="uid">19950401-080045-40000F192713-0052</span>
</nowiki></pre>

this hCard fragment could be displayed as

Unique id:19950401-080045-40000F192713-0052

Note: in practice I don't think I've seen globally unique IDs for "contact info" records published on the web, but perhaps I am not considering enough examples.

=== 3.6.8 URL Type Definition ===

<pre><nowiki>
URL:http://www.swbyps.restaurant.french/~chezchic.html
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="url" href="http://www.swbyps.restaurant.french/~chezchic.html">Chez Chic</a>
</nowiki></pre>

this hCard fragment could be displayed as

[http://www.swbyps.restaurant.french/~chezchic.html Chez Chic]

=== 3.7.1 CLASS Type Definition ===

==== Example 1 ====

<pre><nowiki>
CLASS:PUBLIC
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PUBLIC</span>
</nowiki></pre>

this hCard fragment could be displayed as

PUBLIC

==== Example 2 ====

<pre><nowiki>
CLASS:PRIVATE
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PRIVATE</span>
</nowiki></pre>

this hCard fragment could be displayed as

PRIVATE

==== Example 3 ====

<pre><nowiki>
CLASS:CONFIDENTIAL
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">CONFIDENTIAL</span>
</nowiki></pre>

this hCard fragment could be displayed as

CONFIDENTIAL

=== 3.7.2 KEY Type Definition ===

<pre><nowiki>
KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="key" type="application/octet-stream"
data="data:application/octet-stream;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==">
Key
</object>

</nowiki></pre>

this hCard fragment could be displayed as

Key

Note: Because of the lack of a TYPE value in the RFC2426 example, I substituted application/octet-stream. Clearly for it to be of some use, the type specified must be some sort of key or certificate mime type.

=== 7. Authors' Addresses ===

<pre><nowiki>
BEGIN:vCard
VERSION:3.0
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
;Raleigh;NC;27613-3502;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
TEL;TYPE=FAX,WORK:+1-919-676-9564
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:vCard

BEGIN:vCard
VERSION:3.0
FN:Tim Howes
ORG:Netscape Communications Corp.
ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
CA; 94043;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
TEL;TYPE=FAX,WORK:+1-415-528-4164
EMAIL;TYPE=INTERNET:howes@netscape.com
END:vCard
</nowiki></pre>

Note that both of these vCards are invalid since they lack the REQUIRED "N" property which is quite ironic, since these are the vCards of the authors themselves.

Nonetheless, these vCards can be represented by the following hCards:

<pre><nowiki>
<div class="vcard">
<a class="url fn" href="http://home.earthlink.net/~fdawson">Frank Dawson</a>
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
<a class="email" href="mailto:Frank_Dawson@Lotus.com">
<span class="type">pref</span><span>erred email</span>
</a>,
<a class="email" href="mailto:fdawson@earthlink.net">
alternate email
</a>
</div>
<div class="vcard">
<a class="email fn" href="mailto:howes@netscape.com">Tim Howes</a>
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>
</nowiki></pre>

this hCards could be displayed as

<div class="vcard">
[http://home.earthlink.net/~fdawson Frank Dawson]
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
[mailto:Frank_Dawson@Lotus.com preferred email],
[mailto:fdawson@earthlink.net alternate email]
</div>

<div class="vcard">
[mailto:howes@netscape.com Tim Howes]
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>

== Test Cases ==

These are [[hcard|hCard]] examples which have been found to be particularly useful in finding bugs in hCard parsers (e.g. X2V).

=== Problem with BDAY Information ===

this example:

<pre>

<div class="bday">
<dt>Birthday</dt>
<dd>
<abbr class="value" title="1985-10-27T00:00:00Z">October 27, 1985</abbr>
</dd>
</div>
</pre>

ought to produce "BDAY:1985-10-27T00:00:00Z" but it produces "BDAY:Birthday October 27\, 1985". interesting is that the apple addressbook is still willing to accept it in this way.

=== case-INSENSITIVITY of type values ===

* "home" vs. "Home"

this example works with X2V:

<pre>
<div class="tel">
<dt>Phone (<span class="type">home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

this does not, but should. but instead it becomes just TEL without a type in the vcard

<pre>
<div class="tel">
<dt>Phone (<span class="type">Home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

=== GEO parsing ===
The following hCard:

<pre><nowiki>
<div class="vcard">
<span class="fn n">
<a class="url" href="http://t37.net">
<span class="given-name">Fréderic</span>
<span class="family-name">de Villamil</span>
</a>
</span>
<span class="nickname">neuro</span>
<a class="email" href="mailto:neuroNOSPAM@t37.net">
<span class="type">pref</span><span>erred email</span>
</a>
<span class="org">Omatis</span>
<span class="adr">
<abbr class="type" title="dom">France</abbr>
<span class="type">home</span> address
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<span class="street-address">12 rue Danton</span>
<span class="locality">Le Kremlin-Bicetre</span>
<span class="postal-code">94270</span>
<span class="country-name">France</span>
</span>
<span class="geo">
<abbr class="latitude" title="48.816667">N 48° 81.6667</abbr>
<abbr class="longitude" title="2.366667">E 2° 36.6667</abbr>
</span>
</div>
</nowiki>
</pre>

Should be translated into the following vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
URL:http://t37.net
ORG:Omatis;;
NICKNAME:neuro
FN:Fréderic de Villamil
N:de Villamil;Frederic;;Mr.;
EMAIL;TYPE=INTERNET,PREF:neuroNOSPAM@t37.net
ADR;TYPE=HOME:;;12 rue danton;le Kremlin-Bicetre;;94270;France
GEO:48.816667;2.366667
END:VCARD
</nowiki></pre>

X2V currently (2005-12-18) fails to parse/export the GEO property at all.

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

hcard-examples-rfc2426

2006-12-13T17:58:12Z

MikeKaply:

<h1>hCard examples</h1>

Example [[hcard|hCards]].

== Authors ==
* [http://tantek.com/log Tantek Çelik]
* Brian Suda

== Instructive Examples ==

=== Authors of Pages and Posts ===
[http://www.w3.org/TR/html401/struct/global.html#h-7.5.6 Per the HTML4.01 specification], authors should be using the <code><address></code> element to indicate the "contact information for a document or a major part of a document." E.g.

<pre><nowiki>
<address>
<a href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

By adding [[hcard|hCard]] to such existing semantic XHTML, you can explicitly indicate the name of the person, their URL, etc.:

<pre><nowiki>
<address class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

This could be displayed as:

[http://tantek.com/ Tantek Çelik]

This works not only for whole pages, but also for "major part[s]" of pages, e.g. blog posts.

See the [http://microformats.org/blog/ microformats.org blog] (view the source) for a live example. The author of every blog post on the microformats.org blog is marked up as an <code><address class="vcard"></code> element like the example shown above.

=== References to People and Organizations ===

A common pattern in blog posts is to link mentions of people's names to their blogs, and/or organizations to their home pages. E.g.:

<pre><nowiki>
<cite><a href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<a href="http://irs.gov/">Internal Revenue Service</a>.
</nowiki></pre>

By adding hCard to such markup, you can explicitly indicate both the person and the organization by name and URL:

<pre><nowiki>
<cite class="vcard"><a class="fn url" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

Note the class names "fn org url" on the hyperlink surrounding the IRS. Using the same value (or element for that matter) for "fn" and "org" indicates that the hCard describes an organization rather than a person.

This could be displayed as:

''[http://meyerweb.com/ Eric Meyer]'' wrote a post (''[http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/ Tax Relief]'') about an unintentionally humorous letter
he received from the [http://irs.gov/ Internal Revenue Service].

=== hCard and XFN ===
==== References to People in Blog Posts ====

In the above example, one person (the blogger) is referring to another person (Eric Meyer). In addition to using hCard to explicitly mark up the reference as a person, the blogger can use [http://gmpg.org/xfn/ XFN] (the XHTML Friends Network) to indicate their relationship to Eric Meyer, e.g.:

<pre><nowiki>
<cite class="vcard"><a class="fn url" rel="friend colleague met" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

It would be displayed the same as the previous example.

==== References to People in Blogrolls ====

Many bloggers are using XFN (often using an easy user interface like that built into [http://wordpress.org WordPress]) to explicitly indicate their relationships to the people in their blogrolls:

<pre><nowiki>
<ul>
<li><a href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li><a href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

By adding hCard markup to an XFN Friendly blogroll, you can explicitly indicate the name and URL of the person in addition to their relationship:

<pre><nowiki>
<ul>
<li class="vcard"><a class="fn url" href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li class="vcard"><a class="fn url" href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

This could be displayed as:
* [http://meyerweb.com Eric Meyer]
* [http://photomatt.net Matt Mullenweg]

For more information on XFN, see the [http://gmpg.org/xfn/ XFN home page], [http://gmpg.org/xfn/join joining XFN], and [http://gmpg.org/xfn/background background on XFN].

This technique is used in the [http://factorycity.net/projects/wp-microformatted-blogroll/ WP Microformatted Blogroll] plugin.

=== New Types of Contact Info ===

Since vCard was designed, there have been numerous other services that provide individuals with addresses or other means of contact, e.g. instant messaging, voip, etc.

Does this mean that vCard (and hence hCard) must be extended to represent these?

Thanks to the flexibility of the URL property, the answer is no, no extensions are necessary. Instead, we use the proper URL for the service which identifies the service (protocol, machine, and/or path), and place the individual's address inside that.

==== AOL Instant Messenger (AIM) ====

AOL Instant Messenger (AIM) ids can be represented using the <code>aim:</code> protocol. Many who publish their AIM ids do so with clickable URLs e.g.:

<pre><nowiki>
<a href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

Thus for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

==== Yahoo Messenger ====

Similarly, Yahoo Instant Messenger (YIM) ids can be represented using the <code>ymsgr:</code> protocol. And similarly many publish their YIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

Again, for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

==== MSN Messenger ====

<strike>Unfortunately, AFAIK, there is no hacked up defacto protocol for opening an MSN IM session with an MSN userid (which themselves are just email addresses). Thus we must simply resort to marking them up as email addresses, and expect that consumers may use some heuristic, such as "hotmail.com email addresses are also MSN IM ids". -Tantek</strike>

MSN Messenger (MSNIM) ids can be represented using the <code>msnim:</code> protocol. And similarly many publish their MSNIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

For hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

Updated 14 May 2006 - [http://www.wackomenace.co.uk/ Ruben]

Ruben, I tried this, and "msnim:" is an unrecognized protocol on MacOSX.4 (this is with the latest MSN Messenger for Mac installed and running and logged int). Could you provide links to documentation about "msnim:" and links to actual pages that publish their MSNIM ids this way? I don't know of any - [http://tantek.com/ Tantek]

: Tantek, Wikipedia's [http://en.wikipedia.org/wiki/History_of_Windows_Live_Messenger History of Windows Live Messenger] states that MSN Messenger 7.5 for Windows, among other things, introduced: "the msnim protocol handler, allowing Web sites to provide links which automatically add a contact or start conversations (for example clicking on link msnim:chat?contact=login@passport.net will start chat conversation with user login@passport.net).". The Mac version is notoriously lagging behind, sadly. --''[[User:Chucker|chucker]] 11:33, 29 Jun 2006 (PDT)''

It also seems that the msnim protocol handler in only supported by Microsoft Internet Explorer 7 (haven't tried earlier versions) on Windows. Latest versions of Firefox, Opera and Netscape Navigator doesn't recognize the protocol. Well, for at least, not at the moment. - [http://www.juhaliikala.com/ Juha Liikala]

==== XMPP (Jabber) ====

[http://www.xmpp.org/ Extensible Messaging and Presence Protocol (XMPP)] ids can be represented using the <code>xmpp:</code> protocol, e.g.:

<pre><nowiki>
<a class="url" href="xmpp:username@jabberservice.com">IM with username@jammerservice.com</a>
</nowiki></pre>

The protocol allows much richer URLs, see [http://www.faqs.org/rfcs/rfc4622.html RFC4622].

There are not many current [http://wiki.jabber.org/index.php/XMPP_URIs#Jabber_Clients clients supporting the protocol].

==== Skype ====

Skype can be represented using the <code>skype:</code> protocol. It can be used to open a chat session or make a Skype call.

<pre><nowiki>
<a href="skype:echo-chinese?chat">IM with the Skype echo service (Chinese) </a>
</nowiki></pre>

<pre><nowiki>
<a href="skype:echo-chinese?call">Skype call to Skype echo service (Chinese) </a>
</nowiki></pre>

Thus for hCard, we could adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="skype:echo-chinese?chat">IM with the Skype echo service (Chinese)</a>
</nowiki></pre>

<pre><nowiki>
<a class="url" href="skype:echo-chinese?call">Skype call to Skype echo service (Chinese)</a>
</nowiki></pre>

==== Site profiles ====
Bloggers often indicate their identity on content hosting services using the URL to their home page, feed or profile on those services. By labeling them as URL properties, these additional facets of identity can be publish in an hCard as well.

* [http://del.icio.us delicious]:
** <code><a class="url" href="http://del.icio.us/rbach">Robert Bachmann's links</a></code>
* [http://flickr.com Flickr]:
** <code><a class="url" href="http://flickr.com/photos/tantek/">See my photos</a></code>
** <code><a class="url" href="http://flickr.com/people/tantek/">Flickr profile</a></code>
* [http://technorati.com/ Technorati]:
** <code><a class="url" href="http://technorati.com/profile/tantek/">Technorati profile</a></code>
* Add more here...
** ....

=== Organizations and Departments ===

Departments are marked up using the "organization-unit" class name inside the "org" element, with the "organization-name" specifically marked up to distinguish it from the department:

<pre><nowiki>
<div class="vcard">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit">Apprenticeship Training Center</div>
</div>
</div>
</nowiki></pre>

The department may also be part of the address, in which case, you may want to explicitly mark it up as the "extended-address" in addition to the "organization-unit".

<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit extended-address">Apprenticeship Training Center</div>
</div>
<div class="street-address">2531 Barrington Court</div>
<span class="locality">Hayward</span>,
<abbr title="California" class="region">CA</abbr>
<span class="postal-code">94545</span>
</div>
</div>
</nowiki></pre>

Note that by nesting the org inside the address we avoided having to duplicate the department name.

== RFC 2426 examples in hCard ==

These are 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

Mark Pilgrim has made these hCard examples available as separate files:
* http://diveintomark.org/projects/greasemonkey/hcard/tests/

=== 2.4.2 VCARD ===

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n
TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERNET:\n
jfriday@host.com\nEND:VCARD\n
</nowiki></pre>

This vCard fragment has one property whose value is another vCard, and could be represented as an hCard fragment with an embedded hCard, literally (with the unnecessary type=internet default omitted, and the implied n optimization):

<pre><nowiki>
<div class="agent vcard">
<a class="email fn" href="mailto:jfriday@host.com">Joe Friday</a>
<div class="tel">+1-919-555-7878</div>
<div class="title">Area Administrator, Assistant</div>
</div>
</nowiki></pre>

this hCard could be displayed as:

[mailto:jfriday@host.com Joe Friday]<br />
+1-919-555-7878<br />
Area Administrator, Assistant

=== 3.1.1 FN Type Definition ===

<pre><nowiki>
FN:Mr. John Q. Public\, Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">Mr. John Q. Public, Esq.</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Q. Public, Esq.

=== 3.1.2 N Type Definition ===

==== Example 1 ====

<pre><nowiki>
N:Public;John;Quinlan;Mr.;Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-name">Quinlan</span>
<span class="family-name">Public</span>,
<span class="honorific-suffix">Esq.</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Quinlan Public, Esq.

==== Example 2 ====

<pre><nowiki>
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Dr.</span>
<span class="given-name">John</span>
<span class="additional-name">Philip</span>
<span class="additional-name">Paul</span>
<span class="family-name">Stevenson</span>,
<span class="honorific-suffix">Jr.</span>,
<span class="honorific-suffix">M.D.</span>,
<span class="honorific-suffix">A.C.P.</span>
</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Dr. John Philip Paul Stevenson, Jr., M.D., A.C.P.

=== 3.1.3 NICKNAME Type Definition ===

==== Example 1 ====

<pre><nowiki>
NICKNAME:Robbie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Robbie</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Robbie

==== Example 2 ====

<pre><nowiki>
NICKNAME:Jim,Jimmie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Jim</span>,
<span class="nickname">Jimmie</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Jim, Jimmie

=== 3.1.4 PHOTO Type Definition ===

==== Example 1 ====
<pre><nowiki>
PHOTO;VALUE=uri:http://www.abc.com/pub/photos/jqpublic.gif
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<img class="photo" src="http://www.abc.com/pub/photos/jqpublic.gif" alt="" />
</nowiki></pre>

==== Example 2 ====
<pre><nowiki>
PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment (line breaks inserted into src value for readability):

<pre><nowiki>
<img class="photo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

=== 3.1.5 BDAY Type Definition ===

==== Example 1 ====

<pre><nowiki>
BDAY:1996-04-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>

==== Example 2 ====

<pre><nowiki>
BDAY:1953-10-15T23:10:00Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>

==== Example 3 ====

<pre><nowiki>
BDAY:1987-09-27T08:30:00-06:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>

=== 3.2.1 ADR Type Definition ===

<pre><nowiki>
ADR;TYPE=dom,home,postal,parcel:;;123 Main
Street;Any Town;CA;91921-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>
</nowiki></pre>

this hCard fragment could be displayed as:

<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>

=== 3.2.2 LABEL Type Definition ===

<pre><nowiki>
LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA 91921-1234
\nU.S.A.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Please use the following address label for
<div class="label">
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>
</div>
</nowiki></pre>

'''Note:''' the above hCard fragment uses a <pre> tag inside a property value to capture/represent explicit carriage returns ("\n" characters) from the vCard fragment.

this hCard fragment could be displayed as:

Please use the following address label for
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>

=== 3.3.1 TEL Type Definition ===

<pre><nowiki>
TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tel">
<abbr class="type" title="pref">my</abbr>
<span class="type">work</span>
<abbr class="type" title="voice">phone</abbr>, with
<abbr class="type" title="msg">voicemail</abbr>:
<span class="value">+1-213-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

my work phone, with voicemail: +1-213-555-1234

=== 3.3.2 EMAIL Type Definition ===

==== Example 1 ====

<pre><nowiki>
EMAIL;TYPE=internet:jqpublic@xyz.dom1.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jqpublic@xyz.dom1.com">email jqpublic</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jqpublic@xyz.dom1.com email jqpublic]

==== Example 2 ====

<pre><nowiki>
EMAIL;TYPE=internet:jdoe@isp.net
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jdoe@isp.net">email jdoe</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jdoe@isp.net email jdoe]

==== Example 3 ====

<pre><nowiki>
EMAIL;TYPE=internet,pref:jane_doe@abc.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jane_doe@abc.com">
<abbr class="type" title="pref">preferred</abbr>
email for jane_doe
</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jane_doe@abc.com preferred email for jane_doe]

=== 3.3.3 MAILER Type Definition ===

<pre><nowiki>
MAILER:PigeonMail 2.1
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.
</nowiki></pre>

this hCard fragment could be displayed as:

Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.

=== 3.4.1 TZ Type Definition ===

==== Example 1 ====

<pre><nowiki>
TZ:-05:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tz">-05:00</span>
</nowiki></pre>

this hCard fragment could be displayed as:

-05:00
==== Example 2 ====

<pre><nowiki>
TZ;VALUE=text:-05:00; EST; Raleigh/North America
;This example has a single value, not a structure text value.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="tz"
title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">
EST
</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="tz" title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">EST</abbr>

=== 3.4.2 GEO Type Definition ===

<pre><nowiki>
GEO:37.386013;-122.082932
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="geo">
<span class="latitude">37.386013</span>,
<span class="longitude">-122.082932</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

37.386013, -122.082932

=== 3.5.1 TITLE Type Definition ===

<pre><nowiki>
TITLE:Director\, Research and Development
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="title">Director, Research and Development</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Director, Research and Development

=== 3.5.2 ROLE Type Definition ===

<pre><nowiki>
ROLE:Programmer
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="role">Programmer</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Programmer

=== 3.5.3 LOGO Type Definition ===

==== Example 1 ====

<pre><nowiki>
LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="http://www.abc.com/pub/logos/abccorp.jpg" alt="my logo" />
</nowiki></pre>

this hCard fragment could be displayed as (note: I used a real URL for the image):

http://microformats.org/img/mf-lg-ora.gif

==== Example 2 ====

<pre><nowiki>
LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.5.4 AGENT Type Definition ===

==== Example 1 ====

<pre><nowiki>
AGENT;VALUE=uri:
CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="agent" href="CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com">JQPUBLIC</a>
</nowiki></pre>

this hCard fragment could be displayed as:

JQPUBLIC

==== Example 2 ====

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555-
1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="agent vcard">
<a class="email fn n" href="mailto:sthomas@host.com">Susan Thomas</a>,
<span class="tel">+1-919-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:sthomas@host.com Susan Thomas], +1-919-555-1234

Note: the vCard in the AGENT property vCard fragment is actually invalid since it lacks an "N" property. However, the hCard version *is* valid, since I added the "n" class name to the example.

=== 3.5.5 ORG Type Definition ===

<pre><nowiki>
ORG:ABC\, Inc.;North American Division;Marketing
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="org">
<span class="organization-name">ABC, Inc.</span>,
<span class="organization-unit">North American Division</span>,
<span class="organization-unit">Marketing</span>,
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

ABC, Inc., North American Division, Marketing

=== 3.6.1 CATEGORIES Type Definition ===

==== Example 1 ====

<pre><nowiki>
CATEGORIES:TRAVEL AGENT
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">TRAVEL AGENT</span>
</nowiki></pre>

this hCard fragment could be displayed as:

TRAVEL AGENT

==== Example 2 ====

<pre><nowiki>
CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">INTERNET</span>,
<span class="category">IETF</span>,
<span class="category">INDUSTRY</span>,
<span class="category">INFORMATION TECHNOLOGY</span>
</nowiki></pre>

this hCard fragment would be displayed as:

INTERNET, IETF, INDUSTRY, INFORMATION TECHNOLOGY

=== 3.6.2 NOTE Type Definition ===

<pre><nowiki>
NOTE:This fax number is operational 0800 to 1715
EST\, Mon-Fri.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<p class="note">This fax number is operational 0800 to 1715 EST, Mon-Fri.</p>
</nowiki></pre>

this hCard fragment could be displayed as:

This fax number is operational 0800 to 1715 EST, Mon-Fri.

=== 3.6.3 PRODID Type Definition ===

<pre><nowiki>
PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
</nowiki></pre>

Note, this vCard property actually doesn't make sense as a hCard property, since it really should be filled in by whatever code transforms the hCard into a vCard, e.g. Brian Suda's X2V.

=== 3.6.4 REV Type Definition ===

==== Example 1 ====

<pre><nowiki>
REV:1995-10-31T22:27:10Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>

==== Example 2 ====

<pre><nowiki>
REV:1997-11-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>

=== 3.6.5 SORT-STRING Type Definition ===

==== Example 1 ====

<pre><nowiki>
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Harten
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n"
<span class="honorific-prefix">Sir</span>
<span class="fn">
<span class="given-name">Rene</span>
<span class="family-name">
van der <span class="sort-string">Harten</span>
</span>
</span>
(<span class="additional-name">J.</span>),
<span class="honorific-suffix">R.D.O.N.</span>
</span>
</nowiki></pre>

Note: The string "Harten" was NOT repeated in the hCard, even though it WAS repeated in the vCard (3 times! In N, FN, and SORT-STRING). The "SORT-STRING" property provides another good demonstration of how hCard enables better adherence to the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] than vCard.

this hCard fragment could be displayed as:

Sir Rene van der Harten (J.), R.D.O.N.

==== Example 2 ====

<pre><nowiki>
FN:Robert Pau Shou Chang
N:Pau;Shou Chang;Robert
SORT-STRING:Pau
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn n">
<span class="additional-name">Robert</span>
<span class="family-name sort-string">Pau</span>
<span class="given-name">Shou Chang</span>
</span>
</nowiki></pre>

Note: Not only was the string "Pau" was NOT repeated in the hCard (better [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] adherence again), even though it WAS repeated in the vCard, but in this case since the "family-name" and "sort-string" are the same, we were able to use [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_2:_element_conservation element conservation] and use only one element for both properties.

this hCard fragment could be displayed as:

Robert Pau Shou Chang

==== Example 3 ====

<pre><nowiki>
FN:Osamu Koura
N:Koura;Osamu
SORT-STRING:Koura
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Osamu <span class="sort-string">Koura</span>
</span>
</nowiki></pre>

Note: This example, in addition to illustrating better support for the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle], also makes use of the [http://microformats.org/wiki/hcard#Implied_.22N.22_Optimization Implied "N" Optimization].

this hCard fragment could be displayed as:

Osamu Koura

==== Example 4 ====

<pre><nowiki>
FN:Oscar del Pozo
N:del Pozo Triscon;Oscar
SORT-STRING:Pozo
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="fn">
<span class="given-name">Oscar</span>
del <span class="sort-string">Pozo</span>
</span>
<span class="family-name" style="display:none">
del Pozo Triscon
</span>
</span>
</nowiki></pre>

Note: This example unfortunately could not completely adhere to the DRY principle due to the "FN" using a *substring* of the family-name, and in addition thus had to hide the extra "family-name" string value using CSS display:none, which in general should be avoided. Suggestion welcome for improvements on this hCard fragement.

this hCard fragment could be displayed as:

Oscar del Pozo

==== Example 5 ====

<pre><nowiki>
FN:Christine d'Aboville
N:d'Aboville;Christine
SORT-STRING:Aboville
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Christine d'<span class="sort-string">Aboville</span>
</span>
</nowiki></pre>

Note: This example re-demonstrates the same hCard advantages/efficiencies demonstrated in [http://microformats.org/wiki/hcard-examples#Example_3_3 example 3] above.

this hCard fragment could be displayed as:

Christine d'Aboville

=== 3.6.6 SOUND Type Definition ===

==== Example 1 ====

<pre><nowiki>
SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8.
19960229T080000.xyzMail@host1.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound" type="audio/basic"
data="CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@host1.com">
pronounciation of "JOHN Q PUBLIC"
</object>
</nowiki></pre>

this hCard fragment would probably be displayed as

pronounciation of "JOHN Q PUBLIC"

unless your browser supports the MIME type "audio/basic" (defined in [http://www.rfc-editor.org/rfc/rfc2046.txt RFC2046 section 4.3]) and has some way of retrieving "CID:" urls.

==== Example 2 ====
<pre><nowiki>
SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound"
data="data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...the remainder of "B" encoded binary data...">
pronounciation
</object>
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.6.7 UID Type Definition ===

<pre><nowiki>
UID:19950401-080045-40000F192713-0052
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
Unique id:
<span class="uid">19950401-080045-40000F192713-0052</span>
</nowiki></pre>

this hCard fragment could be displayed as

Unique id:19950401-080045-40000F192713-0052

Note: in practice I don't think I've seen globally unique IDs for "contact info" records published on the web, but perhaps I am not considering enough examples.

=== 3.6.8 URL Type Definition ===

<pre><nowiki>
URL:http://www.swbyps.restaurant.french/~chezchic.html
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="url" href="http://www.swbyps.restaurant.french/~chezchic.html">Chez Chic</a>
</nowiki></pre>

this hCard fragment could be displayed as

[http://www.swbyps.restaurant.french/~chezchic.html Chez Chic]

=== 3.7.1 CLASS Type Definition ===

==== Example 1 ====

<pre><nowiki>
CLASS:PUBLIC
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PUBLIC</span>
</nowiki></pre>

this hCard fragment could be displayed as

PUBLIC

==== Example 2 ====

<pre><nowiki>
CLASS:PRIVATE
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PRIVATE</span>
</nowiki></pre>

this hCard fragment could be displayed as

PRIVATE

==== Example 3 ====

<pre><nowiki>
CLASS:CONFIDENTIAL
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">CONFIDENTIAL</span>
</nowiki></pre>

this hCard fragment could be displayed as

CONFIDENTIAL

=== 3.7.2 KEY Type Definition ===

<pre><nowiki>
KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="key" type="application/octet-stream"
data="data:application/octet-stream;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==">
Key
</object>

</nowiki></pre>

this hCard fragment could be displayed as

Key

Note: Because of the lack of a TYPE value in the RFC2426 example, I substituted application/octet-stream. Clearly for it to be of some use, the type specified must be some sort of key or certificate mime type.

=== 7. Authors' Addresses ===

<pre><nowiki>
BEGIN:vCard
VERSION:3.0
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
;Raleigh;NC;27613-3502;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
TEL;TYPE=FAX,WORK:+1-919-676-9564
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:vCard

BEGIN:vCard
VERSION:3.0
FN:Tim Howes
ORG:Netscape Communications Corp.
ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
CA; 94043;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
TEL;TYPE=FAX,WORK:+1-415-528-4164
EMAIL;TYPE=INTERNET:howes@netscape.com
END:vCard
</nowiki></pre>

Note that both of these vCards are invalid since they lack the REQUIRED "N" property which is quite ironic, since these are the vCards of the authors themselves.

Nonetheless, these vCards can be represented by the following hCards:

<pre><nowiki>
<div class="vcard">
<a class="url fn" href="http://home.earthlink.net/~fdawson">Frank Dawson</a>
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
<a class="email" href="mailto:Frank_Dawson@Lotus.com">
<span class="type">pref<span>erred</span> email</span>
</a>,
<a class="email" href="mailto:fdawson@earthlink.net">
alternate email
</a>
</div>
<div class="vcard">
<a class="email fn" href="mailto:howes@netscape.com">Tim Howes</a>
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>
</nowiki></pre>

this hCards could be displayed as

<div class="vcard">
[http://home.earthlink.net/~fdawson Frank Dawson]
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
[mailto:Frank_Dawson@Lotus.com preferred email],
[mailto:fdawson@earthlink.net alternate email]
</div>

<div class="vcard">
[mailto:howes@netscape.com Tim Howes]
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>

== Test Cases ==

These are [[hcard|hCard]] examples which have been found to be particularly useful in finding bugs in hCard parsers (e.g. X2V).

=== Problem with BDAY Information ===

this example:

<pre>

<div class="bday">
<dt>Birthday</dt>
<dd>
<abbr class="value" title="1985-10-27T00:00:00Z">October 27, 1985</abbr>
</dd>
</div>
</pre>

ought to produce "BDAY:1985-10-27T00:00:00Z" but it produces "BDAY:Birthday October 27\, 1985". interesting is that the apple addressbook is still willing to accept it in this way.

=== case-INSENSITIVITY of type values ===

* "home" vs. "Home"

this example works with X2V:

<pre>
<div class="tel">
<dt>Phone (<span class="type">home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

this does not, but should. but instead it becomes just TEL without a type in the vcard

<pre>
<div class="tel">
<dt>Phone (<span class="type">Home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

=== GEO parsing ===
The following hCard:

<pre><nowiki>
<div class="vcard">
<span class="fn n">
<a class="url" href="http://t37.net">
<span class="given-name">Fréderic</span>
<span class="family-name">de Villamil</span>
</a>
</span>
<span class="nickname">neuro</span>
<a class="email" href="mailto:neuroNOSPAM@t37.net">
<span class="type">pref<span>erred</span> email</span>
</a>
<span class="org">Omatis</span>
<span class="adr">
<abbr class="type" title="dom">France</abbr>
<span class="type">home</span> address
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<span class="street-address">12 rue Danton</span>
<span class="locality">Le Kremlin-Bicetre</span>
<span class="postal-code">94270</span>
<span class="country-name">France</span>
</span>
<span class="geo">
<abbr class="latitude" title="48.816667">N 48° 81.6667</abbr>
<abbr class="longitude" title="2.366667">E 2° 36.6667</abbr>
</span>
</div>
</nowiki>
</pre>

Should be translated into the following vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
URL:http://t37.net
ORG:Omatis;;
NICKNAME:neuro
FN:Fréderic de Villamil
N:de Villamil;Frederic;;Mr.;
EMAIL;TYPE=INTERNET,PREF:neuroNOSPAM@t37.net
ADR;TYPE=HOME:;;12 rue danton;le Kremlin-Bicetre;;94270;France
GEO:48.816667;2.366667
END:VCARD
</nowiki></pre>

X2V currently (2005-12-18) fails to parse/export the GEO property at all.

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

hcard-examples-rfc2426

2006-12-13T17:54:26Z

MikeKaply:

<h1>hCard examples</h1>

Example [[hcard|hCards]].

== Authors ==
* [http://tantek.com/log Tantek Çelik]
* Brian Suda

== Instructive Examples ==

=== Authors of Pages and Posts ===
[http://www.w3.org/TR/html401/struct/global.html#h-7.5.6 Per the HTML4.01 specification], authors should be using the <code><address></code> element to indicate the "contact information for a document or a major part of a document." E.g.

<pre><nowiki>
<address>
<a href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

By adding [[hcard|hCard]] to such existing semantic XHTML, you can explicitly indicate the name of the person, their URL, etc.:

<pre><nowiki>
<address class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

This could be displayed as:

[http://tantek.com/ Tantek Çelik]

This works not only for whole pages, but also for "major part[s]" of pages, e.g. blog posts.

See the [http://microformats.org/blog/ microformats.org blog] (view the source) for a live example. The author of every blog post on the microformats.org blog is marked up as an <code><address class="vcard"></code> element like the example shown above.

=== References to People and Organizations ===

A common pattern in blog posts is to link mentions of people's names to their blogs, and/or organizations to their home pages. E.g.:

<pre><nowiki>
<cite><a href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<a href="http://irs.gov/">Internal Revenue Service</a>.
</nowiki></pre>

By adding hCard to such markup, you can explicitly indicate both the person and the organization by name and URL:

<pre><nowiki>
<cite class="vcard"><a class="fn url" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

Note the class names "fn org url" on the hyperlink surrounding the IRS. Using the same value (or element for that matter) for "fn" and "org" indicates that the hCard describes an organization rather than a person.

This could be displayed as:

''[http://meyerweb.com/ Eric Meyer]'' wrote a post (''[http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/ Tax Relief]'') about an unintentionally humorous letter
he received from the [http://irs.gov/ Internal Revenue Service].

=== hCard and XFN ===
==== References to People in Blog Posts ====

In the above example, one person (the blogger) is referring to another person (Eric Meyer). In addition to using hCard to explicitly mark up the reference as a person, the blogger can use [http://gmpg.org/xfn/ XFN] (the XHTML Friends Network) to indicate their relationship to Eric Meyer, e.g.:

<pre><nowiki>
<cite class="vcard"><a class="fn url" rel="friend colleague met" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

It would be displayed the same as the previous example.

==== References to People in Blogrolls ====

Many bloggers are using XFN (often using an easy user interface like that built into [http://wordpress.org WordPress]) to explicitly indicate their relationships to the people in their blogrolls:

<pre><nowiki>
<ul>
<li><a href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li><a href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

By adding hCard markup to an XFN Friendly blogroll, you can explicitly indicate the name and URL of the person in addition to their relationship:

<pre><nowiki>
<ul>
<li class="vcard"><a class="fn url" href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li class="vcard"><a class="fn url" href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

This could be displayed as:
* [http://meyerweb.com Eric Meyer]
* [http://photomatt.net Matt Mullenweg]

For more information on XFN, see the [http://gmpg.org/xfn/ XFN home page], [http://gmpg.org/xfn/join joining XFN], and [http://gmpg.org/xfn/background background on XFN].

This technique is used in the [http://factorycity.net/projects/wp-microformatted-blogroll/ WP Microformatted Blogroll] plugin.

=== New Types of Contact Info ===

Since vCard was designed, there have been numerous other services that provide individuals with addresses or other means of contact, e.g. instant messaging, voip, etc.

Does this mean that vCard (and hence hCard) must be extended to represent these?

Thanks to the flexibility of the URL property, the answer is no, no extensions are necessary. Instead, we use the proper URL for the service which identifies the service (protocol, machine, and/or path), and place the individual's address inside that.

==== AOL Instant Messenger (AIM) ====

AOL Instant Messenger (AIM) ids can be represented using the <code>aim:</code> protocol. Many who publish their AIM ids do so with clickable URLs e.g.:

<pre><nowiki>
<a href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

Thus for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

==== Yahoo Messenger ====

Similarly, Yahoo Instant Messenger (YIM) ids can be represented using the <code>ymsgr:</code> protocol. And similarly many publish their YIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

Again, for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

==== MSN Messenger ====

<strike>Unfortunately, AFAIK, there is no hacked up defacto protocol for opening an MSN IM session with an MSN userid (which themselves are just email addresses). Thus we must simply resort to marking them up as email addresses, and expect that consumers may use some heuristic, such as "hotmail.com email addresses are also MSN IM ids". -Tantek</strike>

MSN Messenger (MSNIM) ids can be represented using the <code>msnim:</code> protocol. And similarly many publish their MSNIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

For hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

Updated 14 May 2006 - [http://www.wackomenace.co.uk/ Ruben]

Ruben, I tried this, and "msnim:" is an unrecognized protocol on MacOSX.4 (this is with the latest MSN Messenger for Mac installed and running and logged int). Could you provide links to documentation about "msnim:" and links to actual pages that publish their MSNIM ids this way? I don't know of any - [http://tantek.com/ Tantek]

: Tantek, Wikipedia's [http://en.wikipedia.org/wiki/History_of_Windows_Live_Messenger History of Windows Live Messenger] states that MSN Messenger 7.5 for Windows, among other things, introduced: "the msnim protocol handler, allowing Web sites to provide links which automatically add a contact or start conversations (for example clicking on link msnim:chat?contact=login@passport.net will start chat conversation with user login@passport.net).". The Mac version is notoriously lagging behind, sadly. --''[[User:Chucker|chucker]] 11:33, 29 Jun 2006 (PDT)''

It also seems that the msnim protocol handler in only supported by Microsoft Internet Explorer 7 (haven't tried earlier versions) on Windows. Latest versions of Firefox, Opera and Netscape Navigator doesn't recognize the protocol. Well, for at least, not at the moment. - [http://www.juhaliikala.com/ Juha Liikala]

==== XMPP (Jabber) ====

[http://www.xmpp.org/ Extensible Messaging and Presence Protocol (XMPP)] ids can be represented using the <code>xmpp:</code> protocol, e.g.:

<pre><nowiki>
<a class="url" href="xmpp:username@jabberservice.com">IM with username@jammerservice.com</a>
</nowiki></pre>

The protocol allows much richer URLs, see [http://www.faqs.org/rfcs/rfc4622.html RFC4622].

There are not many current [http://wiki.jabber.org/index.php/XMPP_URIs#Jabber_Clients clients supporting the protocol].

==== Skype ====

Skype can be represented using the <code>skype:</code> protocol. It can be used to open a chat session or make a Skype call.

<pre><nowiki>
<a href="skype:echo-chinese?chat">IM with the Skype echo service (Chinese) </a>
</nowiki></pre>

<pre><nowiki>
<a href="skype:echo-chinese?call">Skype call to Skype echo service (Chinese) </a>
</nowiki></pre>

Thus for hCard, we could adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="skype:echo-chinese?chat">IM with the Skype echo service (Chinese)</a>
</nowiki></pre>

<pre><nowiki>
<a class="url" href="skype:echo-chinese?call">Skype call to Skype echo service (Chinese)</a>
</nowiki></pre>

==== Site profiles ====
Bloggers often indicate their identity on content hosting services using the URL to their home page, feed or profile on those services. By labeling them as URL properties, these additional facets of identity can be publish in an hCard as well.

* [http://del.icio.us delicious]:
** <code><a class="url" href="http://del.icio.us/rbach">Robert Bachmann's links</a></code>
* [http://flickr.com Flickr]:
** <code><a class="url" href="http://flickr.com/photos/tantek/">See my photos</a></code>
** <code><a class="url" href="http://flickr.com/people/tantek/">Flickr profile</a></code>
* [http://technorati.com/ Technorati]:
** <code><a class="url" href="http://technorati.com/profile/tantek/">Technorati profile</a></code>
* Add more here...
** ....

=== Organizations and Departments ===

Departments are marked up using the "organization-unit" class name inside the "org" element, with the "organization-name" specifically marked up to distinguish it from the department:

<pre><nowiki>
<div class="vcard">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit">Apprenticeship Training Center</div>
</div>
</div>
</nowiki></pre>

The department may also be part of the address, in which case, you may want to explicitly mark it up as the "extended-address" in addition to the "organization-unit".

<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit extended-address">Apprenticeship Training Center</div>
</div>
<div class="street-address">2531 Barrington Court</div>
<span class="locality">Hayward</span>,
<abbr title="California" class="region">CA</abbr>
<span class="postal-code">94545</span>
</div>
</div>
</nowiki></pre>

Note that by nesting the org inside the address we avoided having to duplicate the department name.

== RFC 2426 examples in hCard ==

These are 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

Mark Pilgrim has made these hCard examples available as separate files:
* http://diveintomark.org/projects/greasemonkey/hcard/tests/

=== 2.4.2 VCARD ===

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n
TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERNET:\n
jfriday@host.com\nEND:VCARD\n
</nowiki></pre>

This vCard fragment has one property whose value is another vCard, and could be represented as an hCard fragment with an embedded hCard, literally (with the unnecessary type=internet default omitted, and the implied n optimization):

<pre><nowiki>
<div class="agent vcard">
<a class="email fn" href="mailto:jfriday@host.com">Joe Friday</a>
<div class="tel">+1-919-555-7878</div>
<div class="title">Area Administrator, Assistant</div>
</div>
</nowiki></pre>

this hCard could be displayed as:

[mailto:jfriday@host.com Joe Friday]<br />
+1-919-555-7878<br />
Area Administrator, Assistant

=== 3.1.1 FN Type Definition ===

<pre><nowiki>
FN:Mr. John Q. Public\, Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">Mr. John Q. Public, Esq.</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Q. Public, Esq.

=== 3.1.2 N Type Definition ===

==== Example 1 ====

<pre><nowiki>
N:Public;John;Quinlan;Mr.;Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-name">Quinlan</span>
<span class="family-name">Public</span>,
<span class="honorific-suffix">Esq.</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Quinlan Public, Esq.

==== Example 2 ====

<pre><nowiki>
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Dr.</span>
<span class="given-name">John</span>
<span class="additional-name">Philip</span>
<span class="additional-name">Paul</span>
<span class="family-name">Stevenson</span>,
<span class="honorific-suffix">Jr.</span>,
<span class="honorific-suffix">M.D.</span>,
<span class="honorific-suffix">A.C.P.</span>
</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Dr. John Philip Paul Stevenson, Jr., M.D., A.C.P.

=== 3.1.3 NICKNAME Type Definition ===

==== Example 1 ====

<pre><nowiki>
NICKNAME:Robbie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Robbie</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Robbie

==== Example 2 ====

<pre><nowiki>
NICKNAME:Jim,Jimmie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Jim</span>,
<span class="nickname">Jimmie</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Jim, Jimmie

=== 3.1.4 PHOTO Type Definition ===

==== Example 1 ====
<pre><nowiki>
PHOTO;VALUE=uri:http://www.abc.com/pub/photos/jqpublic.gif
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<img class="photo" src="http://www.abc.com/pub/photos/jqpublic.gif" alt="" />
</nowiki></pre>

==== Example 2 ====
<pre><nowiki>
PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment (line breaks inserted into src value for readability):

<pre><nowiki>
<img class="photo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

=== 3.1.5 BDAY Type Definition ===

==== Example 1 ====

<pre><nowiki>
BDAY:1996-04-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>

==== Example 2 ====

<pre><nowiki>
BDAY:1953-10-15T23:10:00Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>

==== Example 3 ====

<pre><nowiki>
BDAY:1987-09-27T08:30:00-06:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>

=== 3.2.1 ADR Type Definition ===

<pre><nowiki>
ADR;TYPE=dom,home,postal,parcel:;;123 Main
Street;Any Town;CA;91921-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>
</nowiki></pre>

this hCard fragment could be displayed as:

<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>

=== 3.2.2 LABEL Type Definition ===

<pre><nowiki>
LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA 91921-1234
\nU.S.A.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Please use the following address label for
<div class="label">
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>
</div>
</nowiki></pre>

'''Note:''' the above hCard fragment uses a <pre> tag inside a property value to capture/represent explicit carriage returns ("\n" characters) from the vCard fragment.

this hCard fragment could be displayed as:

Please use the following address label for
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>

=== 3.3.1 TEL Type Definition ===

<pre><nowiki>
TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tel">
<abbr class="type" title="pref">my</abbr>
<span class="type">work</span>
<abbr class="type" title="voice">phone</abbr>, with
<abbr class="type" title="msg">voicemail</abbr>:
<span class="value">+1-213-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

my work phone, with voicemail: +1-213-555-1234

=== 3.3.2 EMAIL Type Definition ===

==== Example 1 ====

<pre><nowiki>
EMAIL;TYPE=internet:jqpublic@xyz.dom1.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jqpublic@xyz.dom1.com">email jqpublic</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jqpublic@xyz.dom1.com email jqpublic]

==== Example 2 ====

<pre><nowiki>
EMAIL;TYPE=internet:jdoe@isp.net
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jdoe@isp.net">email jdoe</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jdoe@isp.net email jdoe]

==== Example 3 ====

<pre><nowiki>
EMAIL;TYPE=internet,pref:jane_doe@abc.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jane_doe@abc.com">
<abbr class="type" title="pref">preferred</abbr>
email for jane_doe
</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jane_doe@abc.com preferred email for jane_doe]

=== 3.3.3 MAILER Type Definition ===

<pre><nowiki>
MAILER:PigeonMail 2.1
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.
</nowiki></pre>

this hCard fragment could be displayed as:

Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.

=== 3.4.1 TZ Type Definition ===

==== Example 1 ====

<pre><nowiki>
TZ:-05:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tz">-05:00</span>
</nowiki></pre>

this hCard fragment could be displayed as:

-05:00
==== Example 2 ====

<pre><nowiki>
TZ;VALUE=text:-05:00; EST; Raleigh/North America
;This example has a single value, not a structure text value.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="tz"
title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">
EST
</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="tz" title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">EST</abbr>

=== 3.4.2 GEO Type Definition ===

<pre><nowiki>
GEO:37.386013;-122.082932
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="geo">
<span class="latitude">37.386013</span>,
<span class="longitude">-122.082932</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

37.386013, -122.082932

=== 3.5.1 TITLE Type Definition ===

<pre><nowiki>
TITLE:Director\, Research and Development
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="title">Director, Research and Development</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Director, Research and Development

=== 3.5.2 ROLE Type Definition ===

<pre><nowiki>
ROLE:Programmer
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="role">Programmer</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Programmer

=== 3.5.3 LOGO Type Definition ===

==== Example 1 ====

<pre><nowiki>
LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="http://www.abc.com/pub/logos/abccorp.jpg" alt="my logo" />
</nowiki></pre>

this hCard fragment could be displayed as (note: I used a real URL for the image):

http://microformats.org/img/mf-lg-ora.gif

==== Example 2 ====

<pre><nowiki>
LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.5.4 AGENT Type Definition ===

==== Example 1 ====

<pre><nowiki>
AGENT;VALUE=uri:
CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="agent" href="CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com">JQPUBLIC</a>
</nowiki></pre>

this hCard fragment could be displayed as:

JQPUBLIC

==== Example 2 ====

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555-
1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="agent vcard">
<a class="email fn n" href="mailto:sthomas@host.com">Susan Thomas</a>,
<span class="tel">+1-919-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:sthomas@host.com Susan Thomas], +1-919-555-1234

Note: the vCard in the AGENT property vCard fragment is actually invalid since it lacks an "N" property. However, the hCard version *is* valid, since I added the "n" class name to the example.

=== 3.5.5 ORG Type Definition ===

<pre><nowiki>
ORG:ABC\, Inc.;North American Division;Marketing
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="org">
<span class="organization-name">ABC, Inc.</span>,
<span class="organization-unit">North American Division</span>,
<span class="organization-unit">Marketing</span>,
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

ABC, Inc., North American Division, Marketing

=== 3.6.1 CATEGORIES Type Definition ===

==== Example 1 ====

<pre><nowiki>
CATEGORIES:TRAVEL AGENT
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">TRAVEL AGENT</span>
</nowiki></pre>

this hCard fragment could be displayed as:

TRAVEL AGENT

==== Example 2 ====

<pre><nowiki>
CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">INTERNET</span>,
<span class="category">IETF</span>,
<span class="category">INDUSTRY</span>,
<span class="category">INFORMATION TECHNOLOGY</span>
</nowiki></pre>

this hCard fragment would be displayed as:

INTERNET, IETF, INDUSTRY, INFORMATION TECHNOLOGY

=== 3.6.2 NOTE Type Definition ===

<pre><nowiki>
NOTE:This fax number is operational 0800 to 1715
EST\, Mon-Fri.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<p class="note">This fax number is operational 0800 to 1715 EST, Mon-Fri.</p>
</nowiki></pre>

this hCard fragment could be displayed as:

This fax number is operational 0800 to 1715 EST, Mon-Fri.

=== 3.6.3 PRODID Type Definition ===

<pre><nowiki>
PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
</nowiki></pre>

Note, this vCard property actually doesn't make sense as a hCard property, since it really should be filled in by whatever code transforms the hCard into a vCard, e.g. Brian Suda's X2V.

=== 3.6.4 REV Type Definition ===

==== Example 1 ====

<pre><nowiki>
REV:1995-10-31T22:27:10Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>

==== Example 2 ====

<pre><nowiki>
REV:1997-11-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>

=== 3.6.5 SORT-STRING Type Definition ===

==== Example 1 ====

<pre><nowiki>
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Harten
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n"
<span class="honorific-prefix">Sir</span>
<span class="fn">
<span class="given-name">Rene</span>
<span class="family-name">
van der <span class="sort-string">Harten</span>
</span>
</span>
(<span class="additional-name">J.</span>),
<span class="honorific-suffix">R.D.O.N.</span>
</span>
</nowiki></pre>

Note: The string "Harten" was NOT repeated in the hCard, even though it WAS repeated in the vCard (3 times! In N, FN, and SORT-STRING). The "SORT-STRING" property provides another good demonstration of how hCard enables better adherence to the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] than vCard.

this hCard fragment could be displayed as:

Sir Rene van der Harten (J.), R.D.O.N.

==== Example 2 ====

<pre><nowiki>
FN:Robert Pau Shou Chang
N:Pau;Shou Chang;Robert
SORT-STRING:Pau
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn n">
<span class="additional-name">Robert</span>
<span class="family-name sort-string">Pau</span>
<span class="given-name">Shou Chang</span>
</span>
</nowiki></pre>

Note: Not only was the string "Pau" was NOT repeated in the hCard (better [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] adherence again), even though it WAS repeated in the vCard, but in this case since the "family-name" and "sort-string" are the same, we were able to use [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_2:_element_conservation element conservation] and use only one element for both properties.

this hCard fragment could be displayed as:

Robert Pau Shou Chang

==== Example 3 ====

<pre><nowiki>
FN:Osamu Koura
N:Koura;Osamu
SORT-STRING:Koura
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Osamu <span class="sort-string">Koura</span>
</span>
</nowiki></pre>

Note: This example, in addition to illustrating better support for the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle], also makes use of the [http://microformats.org/wiki/hcard#Implied_.22N.22_Optimization Implied "N" Optimization].

this hCard fragment could be displayed as:

Osamu Koura

==== Example 4 ====

<pre><nowiki>
FN:Oscar del Pozo
N:del Pozo Triscon;Oscar
SORT-STRING:Pozo
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="fn">
<span class="given-name">Oscar</span>
del <span class="sort-string">Pozo</span>
</span>
<span class="family-name" style="display:none">
del Pozo Triscon
</span>
</span>
</nowiki></pre>

Note: This example unfortunately could not completely adhere to the DRY principle due to the "FN" using a *substring* of the family-name, and in addition thus had to hide the extra "family-name" string value using CSS display:none, which in general should be avoided. Suggestion welcome for improvements on this hCard fragement.

this hCard fragment could be displayed as:

Oscar del Pozo

==== Example 5 ====

<pre><nowiki>
FN:Christine d'Aboville
N:d'Aboville;Christine
SORT-STRING:Aboville
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Christine d'<span class="sort-string">Aboville</span>
</span>
</nowiki></pre>

Note: This example re-demonstrates the same hCard advantages/efficiencies demonstrated in [http://microformats.org/wiki/hcard-examples#Example_3_3 example 3] above.

this hCard fragment could be displayed as:

Christine d'Aboville

=== 3.6.6 SOUND Type Definition ===

==== Example 1 ====

<pre><nowiki>
SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8.
19960229T080000.xyzMail@host1.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound" type="audio/basic"
data="CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@host1.com">
pronounciation of "JOHN Q PUBLIC"
</object>
</nowiki></pre>

this hCard fragment would probably be displayed as

pronounciation of "JOHN Q PUBLIC"

unless your browser supports the MIME type "audio/basic" (defined in [http://www.rfc-editor.org/rfc/rfc2046.txt RFC2046 section 4.3]) and has some way of retrieving "CID:" urls.

==== Example 2 ====
<pre><nowiki>
SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound"
data="data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...the remainder of "B" encoded binary data...">
pronounciation
</object>
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.6.7 UID Type Definition ===

<pre><nowiki>
UID:19950401-080045-40000F192713-0052
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
Unique id:
<span class="uid">19950401-080045-40000F192713-0052</span>
</nowiki></pre>

this hCard fragment could be displayed as

Unique id:19950401-080045-40000F192713-0052

Note: in practice I don't think I've seen globally unique IDs for "contact info" records published on the web, but perhaps I am not considering enough examples.

=== 3.6.8 URL Type Definition ===

<pre><nowiki>
URL:http://www.swbyps.restaurant.french/~chezchic.html
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="url" href="http://www.swbyps.restaurant.french/~chezchic.html">Chez Chic</a>
</nowiki></pre>

this hCard fragment could be displayed as

[http://www.swbyps.restaurant.french/~chezchic.html Chez Chic]

=== 3.7.1 CLASS Type Definition ===

==== Example 1 ====

<pre><nowiki>
CLASS:PUBLIC
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PUBLIC</span>
</nowiki></pre>

this hCard fragment could be displayed as

PUBLIC

==== Example 2 ====

<pre><nowiki>
CLASS:PRIVATE
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PRIVATE</span>
</nowiki></pre>

this hCard fragment could be displayed as

PRIVATE

==== Example 3 ====

<pre><nowiki>
CLASS:CONFIDENTIAL
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">CONFIDENTIAL</span>
</nowiki></pre>

this hCard fragment could be displayed as

CONFIDENTIAL

=== 3.7.2 KEY Type Definition ===

<pre><nowiki>
KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="key" type="application/octet-stream"
data="data:application/octet-stream;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==">
Key
</object>

</nowiki></pre>

this hCard fragment could be displayed as

Key

Note: Because of the lack of a TYPE value in the RFC2426 example, I substituted application/octet-stream. Clearly for it to be of some use, the type specified must be some sort of key or certificate mime type.

=== 7. Authors' Addresses ===

<pre><nowiki>
BEGIN:vCard
VERSION:3.0
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
;Raleigh;NC;27613-3502;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
TEL;TYPE=FAX,WORK:+1-919-676-9564
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:vCard

BEGIN:vCard
VERSION:3.0
FN:Tim Howes
ORG:Netscape Communications Corp.
ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
CA; 94043;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
TEL;TYPE=FAX,WORK:+1-415-528-4164
EMAIL;TYPE=INTERNET:howes@netscape.com
END:vCard
</nowiki></pre>

Note that both of these vCards are invalid since they lack the REQUIRED "N" property which is quite ironic, since these are the vCards of the authors themselves.

Nonetheless, these vCards can be represented by the following hCards:

<pre><nowiki>
<div class="vcard">
<a class="url fn" href="http://home.earthlink.net/~fdawson">Frank Dawson</a>
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
<a class="email" href="mailto:Frank_Dawson@Lotus.com">
<span class="type">pref<span>erred</span> email</span>
</a>,
<a class="email" href="mailto:fdawson@earthlink.net">
alternate email
</a>
</div>
<div class="vcard">
<a class="email fn" href="mailto:howes@netscape.com">Tim Howes</a>
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>
</nowiki></pre>

this hCards could be displayed as

<div class="vcard">
[http://home.earthlink.net/~fdawson Frank Dawson]
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
[mailto:Frank_Dawson@Lotus.com preferred email],
[mailto:fdawson@earthlink.net alternate email]
</div>

<div class="vcard">
[mailto:howes@netscape.com Tim Howes]
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>

== Test Cases ==

These are [[hcard|hCard]] examples which have been found to be particularly useful in finding bugs in hCard parsers (e.g. X2V).

=== Problem with BDAY Information ===

this example:

<pre>

<div class="bday">
<dt>Birthday</dt>
<dd>
<abbr class="value" title="1985-10-27T00:00:00Z">October 27, 1985</abbr>
</dd>
</div>
</pre>

ought to produce "BDAY:1985-10-27T00:00:00Z" but it produces "BDAY:Birthday October 27\, 1985". interesting is that the apple addressbook is still willing to accept it in this way.

=== case-INSENSITIVITY of type values ===

* "home" vs. "Home"

this example works with X2V:

<pre>
<div class="tel">
<dt>Phone (<span class="type">home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

this does not, but should. but instead it becomes just TEL without a type in the vcard

<pre>
<div class="tel">
<dt>Phone (<span class="type">Home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

=== GEO parsing ===
The following hCard:

<pre><nowiki>
<div class="vcard">
<span class="fn n">
<a class="url" href="http://t37.net">
<span class="given-name">Fréderic</span>
<span class="family-name">de Villamil</span>
</a>
</span>
<span class="nickname">neuro</span>
<a class="email" href="mailto:neuroNOSPAM@t37.net">
<span class="type">pref<span>erred</span> email</span>
</a>
<span class="org">Omatis</span>
<span class="adr">
<abbr class="type" title="dom">France</abbr>
<span class="type">home</span> address
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<span class="street-address">12 rue Danton</span>
<span class="locality">Le Kremlin-Bicetre</span>
<span class="postal-code">94270</span>
<span class="country-name">France</span>
</span>
<span class="geo">
<abbr class="latitude" title="48.816667">N 48° 81.6667</abbr>
<abbr class="longitude" title="2.366667">E 2° 36.6667</abbr>
</span>
</div>
</nowiki>
</pre>

Should be translated into the following vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
URL:http://t37.net
ORG:Omatis;;
NICKNAME:neuro
N:de Villamil;Frederic;;Mr.;
EMAIL;TYPE=INTERNET,PREF:neuroNOSPAM@t37.net
ADR;TYPE=HOME:;;12 rue danton;le Kremlin-Bicetre;;94270;France
GEO:48.816667;2.366667
END:VCARD
</nowiki></pre>

X2V currently (2005-12-18) fails to parse/export the GEO property at all.

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

hreview-examples-in-wild

2006-12-11T21:16:37Z

MikeKaply: /* New Examples */

<h1>hReview Examples in the wild </h1>
This page is an '''informative''' section of the [[hreview|hReview]] specification.

The following sites have published [[hreview|hReviews]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc.

If you publish hReviews on your own site, feel free to add it to the top of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hreview|hReview]] markup. Examples added without a URL to a page with hReview markup may be removed.

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

== New Examples ==
* [http://www.board-crazy.co.uk Board Crazy Skateboarding] uses hReviews for all [http://www.board-crazy.co.uk/skate-reviews.php skateboarding product reviews].
** hReviews include the rating inside of the description - 12/11/2006
* [http://local.yahoo.com Yahoo Local] now supports hReviews for all the user feedback and ratings about places in their search results
*[http://corkd.com/ Cork'd] is a community site for reviewing and sharing wine. Member-created "Tasting Notes" are published using hReview.
*[[User:ChrisCasciano]] has started using hReview in his blog postings including these reviews of [http://chunkysoup.net/article/211/TechnoratisNewToys Pingerati and Technorati Microformat Search].
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
* [http://tech.yahoo.com/ Yahoo! Tech] has launched with hReview markup on all their reviews! Hat tips: [http://nerddawg.blogspot.com/2006/05/hreview-microformat-on-yahoo-tech.html Ashish Shetty] and [http://jeremy.zawodny.com/blog/archives/006729.html Jeremy Zawodny] both via [http://www.moskalyuk.com/blog/yahoo-tech-tip-of-the-day/1058 Alex Moskalyuk]. [http://jeremy.zawodny.com/blog/archives/006729.html#comment-27779 Alex says]: "when we launched, the press reported on 300,000 tech products in our database. Some popular items, like [http://tech.yahoo.com/pr/apple-ipod-video-30gb-black-mp3-player/1992981873 this Apple iPod], have over 200 reviews."
* [http://3spots.blogspot.com/2006/05/social-bookmarking-smarking.html 3spots: Social + bookMARKING = Smarking] has an hReview of
[http://smarking.com/ Smarking.com] (a social bookmarking service) which marks up their tagged links with [[xfolk|xFolk]].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://www.pacificspirit.com Dave Orchard] provides hreview marked [http://www.pacificspirit.com/Restaurants-Vancouver.html Vancouver Restaurant reviews]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://3spots.blogspot.com/2006/04/what-is-wikio-definitely-web-20-but.html hReview of Wikio]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://jg.typepad.com/ciel/ Joan] has published [http://jg.typepad.com/ciel/2006/02/daniel_bouluds_.html an hReview of Garçon]
** hReviews include the rating inside of the description - 12/11/2006
*[http://zipingo.typepad.com/ Zipingo Team Blog], a collaborative blog by the Zipingo Product Development Team at Intuit, used the hReview format to tag [http://zipingo.typepad.com/my_weblog/2005/12/finding_an_elec.html the backstory] of a review on a San Mateo electrician, written by one of the Zipingo team members ZipingoJim. Jim's post also links to his review on [http://www.zipingo.com Zipingo], a consumer opinion site.
** hReview does not have an item
* [http://ukfilmreview.blogspot.com/ UK Film Review] a new blog using hReview format to review Films and DVD releases in the UK
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.debaser.it/ DeBaser.it] publishes music reviews (in Italian) supporting hReview.
* [http://blog.ftwr.co.uk/ Peter Westwood] posted an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn]
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.livejournal.com/users/danieljohn/ Daniel John] provides a [http://www.livejournal.com/users/danieljohn/58674.html scathing hReview of CIBC].
** hReview does not have an item
* [http://uk.movies.yahoo.com/movie-reviews/ Yahoo UK Movie Reviews] now supports hReview on all (>2000) reviews, e.g. [http://uk.movies.yahoo.com/h/Harry-Potter-and-the-Goblet-of-Fire/review-41195.html Harry Potter and the Goblet of Fire Review]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://adam.typepad.com/impossiblethings/ Adam Hertz] wrote hReviews of [http://adam.typepad.com/impossiblethings/2005/11/soluna.html Soluna] and [http://adam.typepad.com/impossiblethings/2006/05/cafe_gibraltar.html Cafe Gibraltar]
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.mattmcalister.com/blog/ Matt McAllister] wrote an [http://www.mattmcalister.com/blog/_archives/2005/11/16/1408893.html hReview of the TV show: "The Office"]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.bmannconsulting.com/blog/bmann/ Boris Mann] wrote an [http://www.bmannconsulting.com/blog/bmann/doubletake-best-panorama-stitch-tool-for-mac-os-x hReview of DoubleTake, a panorama stitch tool for Mac OS X]
** hReview does not have an item
* [http://blog.ftwr.co.uk/ Peter Westwood] has written an [http://blog.ftwr.co.uk/archives/2005/10/03/blubeckers-hampton-court/ hReview of Blubeckers Hampton Court] and an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn Bucks Green, West Sussex]
** hReviews include the rating inside of the description - 12/11/2006
* [http://dougal.gunters.org/blog/ Dougal] has published an [http://dougal.gunters.org/blog/2005/08/03/french-vanilla-latte hReview of Wolfgang Puck’s Gourmet French Vanilla Latte].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.dinnerbuzz.com/ Dinnerbuzz] is a great site for posting tagged reviews of restaurants, and they publish and summarize all their reviews in hReview!
* [http://soldierant.net/ Bryce Glass (Soldier Ant)] posted an [http://soldierant.net/archives/2005/06/product_review.html hReview of the Uniden ELBT 595 Bluetooth Cordless Phone].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* dda posted an [http://sungnyemun.org/wordpress/?p=20 hReview of hReview] :)
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* An [http://tbp.xomerang.com/?p=3 hReview of Caffè Camardo coffee].
** No hreview on page even though the page claims to be an hreview
* [http://loadaveragezero.com/hnav/contact.php Douglas Clifton] posted [http://loadaveragezero.com/#May-12-2005 comments] regarding adapting his list of ~800 [http://loadaveragezero.com/app/drx Developer Resources] as a format for evaluating hReview.
* [http://www.oliverbrown.me.uk/ Oliver Brown] [http://www.oliverbrown.me.uk/2005/05/09/sitereviewsorg-supports-hreview-i-think/ has announced] that his [http://en-us.sitereviews.org/ SiteReviews.org] (which reviews websites) publishes its reviews using hReview, e.g. here is the [http://en-us.sitereviews.org/review-photomatt.net review on SiteReviews.org for photomatt.net].
* [http://www.myelin.co.nz/post/ Phillip Pearson] is publishing hReviews in the [http://coffee.gen.nz/rss/reviews RSS feed of cafe reviews] on his [http://coffee.gen.nz/ kiwi coffee review site], which of course has the reviews in HTML with embedded hReview markup as well.
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://station11.net/ticker/ Kjell] is publishing his link blog as a [http://station11.net/ticker/ list of hReviews].
** hReviews have no fn specified on the item - 12/11/2006
* [http://epeus.blogspot.com/ Kevin Marks] has [http://epeus.blogspot.com/2005_04_01_epeus_archive.html#111484565269684374 published two hReviews] and used unicode "star" characters for his ratings!
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* JamesStewart is publishing hReviews in the location pages at his [http://grwifi.net Grand Rapids WiFi site].
* [http://www.happenchance.co.uk/ Paul Livingstone] uses hreview to voice his opinion on [http://happenchance.co.uk/reading/ books] and [http://happenchance.co.uk/listening/ music].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.stuffandnonsense.co.uk/ Andy Clarke] uses hReview for his [http://www.stuffandnonsense.co.uk/general/recommended-reading.html recommended reading list].
** hReviews have no fn specified on the item - 12/11/2006
* [http://nachlin.com/ Jim Nachlin] has added hReview publishing to the CMS he uses to publish [http://daysofleisure.com/writing his blog].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://whumpdotcom.livejournal.com/236856.html Bill Humphries] has reviewed the book "A Brother's Price" on his LiveJournal.
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.thinkvitamin.com/ Vitamin] uses hReview on it's [http://www.thinkvitamin.com/reviews/ reviews] section (e.g. a [http://www.thinkvitamin.com/reviews/webapps/fluxiom/ review of Fluxiom]).
* [http://www.openguides.org/ OpenGuides] has support for the hReview microformat in svn, and for now you can see it in action on the [http://cotswolds.openguides.org/ Cotswolds OpenGuide].
** hReview does not have an item
* [http://paulgoscicki.com Paul Goscicki] is publishing his [http://paulgoscicki.com/#wp_movie_ratings movie ratings] using hReview.
* [http://www.cellphones.ca/ Cell Phones etc.] is using hReviews for user-contributed [http://www.cellphones.ca/cell-phones/reviews/ cell phone reviews].
* [http://www.liptrot.org Adam Liptrot] publishes movie reviews using hReview and hCard. See article at [http://www.liptrot.org/journal/entries/movies_and_microformats/ Movies and Microformats].
* [http://www.webteacher.ws Web Teacher] is using hReview for book reviews in both the hReview creator format and a modified format. See a modified example at [http://www.webteacher.ws/2006/11/review-web-design-complete.html Web Design: A Complete Introduction].
** hReviews include the rating inside of the description - 12/11/2006
* [http://niftylist.co.uk/ The nifty list UK.] is using hReviews for user-contributed [http://niftylist.co.uk/mobiles/ mobile phone reviews].
** hReview does not have an item

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

hreview-examples-in-wild

2006-12-11T20:00:11Z

MikeKaply: /* New Examples */

<h1>hReview Examples in the wild </h1>
This page is an '''informative''' section of the [[hreview|hReview]] specification.

The following sites have published [[hreview|hReviews]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc.

If you publish hReviews on your own site, feel free to add it to the top of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hreview|hReview]] markup. Examples added without a URL to a page with hReview markup may be removed.

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

== New Examples ==
* [http://www.board-crazy.co.uk Board Crazy Skateboarding] uses hReviews for all [http://www.board-crazy.co.uk/skate-reviews.php skateboarding product reviews].
* [http://local.yahoo.com Yahoo Local] now supports hReviews for all the user feedback and ratings about places in their search results
*[http://corkd.com/ Cork'd] is a community site for reviewing and sharing wine. Member-created "Tasting Notes" are published using hReview.
*[[User:ChrisCasciano]] has started using hReview in his blog postings including these reviews of [http://chunkysoup.net/article/211/TechnoratisNewToys Pingerati and Technorati Microformat Search].
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
* [http://tech.yahoo.com/ Yahoo! Tech] has launched with hReview markup on all their reviews! Hat tips: [http://nerddawg.blogspot.com/2006/05/hreview-microformat-on-yahoo-tech.html Ashish Shetty] and [http://jeremy.zawodny.com/blog/archives/006729.html Jeremy Zawodny] both via [http://www.moskalyuk.com/blog/yahoo-tech-tip-of-the-day/1058 Alex Moskalyuk]. [http://jeremy.zawodny.com/blog/archives/006729.html#comment-27779 Alex says]: "when we launched, the press reported on 300,000 tech products in our database. Some popular items, like [http://tech.yahoo.com/pr/apple-ipod-video-30gb-black-mp3-player/1992981873 this Apple iPod], have over 200 reviews."
* [http://3spots.blogspot.com/2006/05/social-bookmarking-smarking.html 3spots: Social + bookMARKING = Smarking] has an hReview of [http://smarking.com/ Smarking.com] (a social bookmarking service) which marks up their tagged links with [[xfolk|xFolk]].
*[http://www.pacificspirit.com Dave Orchard] provides hreview marked [http://www.pacificspirit.com/Restaurants-Vancouver.html Vancouver Restaurant reviews]
** hReviews have invalid item/fn markup and do not contain dtreviewed - 12/11/2006
*[http://3spots.blogspot.com/2006/04/what-is-wikio-definitely-web-20-but.html hReview of Wikio]
*[http://jg.typepad.com/ciel/ Joan] has published [http://jg.typepad.com/ciel/2006/02/daniel_bouluds_.html an hReview of Garçon]
*[http://zipingo.typepad.com/ Zipingo Team Blog], a collaborative blog by the Zipingo Product Development Team at Intuit, used the hReview format to tag [http://zipingo.typepad.com/my_weblog/2005/12/finding_an_elec.html the backstory] of a review on a San Mateo electrician, written by one of the Zipingo team members ZipingoJim. Jim's post also links to his review on [http://www.zipingo.com Zipingo], a consumer opinion site.
* [http://mincedmedia.blogspot.com/ Minced Media], a media blog by author/writer [http://www.kimbayne.com Kim M. Bayne], used the hReview format to tag her rant about [http://mincedmedia.blogspot.com/2005/09/old-yeller.html customer service]. Future reviews of business and media will contain hReview.
* [http://ukfilmreview.blogspot.com/ UK Film Review] a new blog using hReview format to review Films and DVD releases in the UK
* [http://www.debaser.it/ DeBaser.it] publishes music reviews (in Italian) supporting hReview.
* [http://blog.ftwr.co.uk/ Peter Westwood] posted an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn]
* [http://www.livejournal.com/users/danieljohn/ Daniel John] provides a [http://www.livejournal.com/users/danieljohn/58674.html scathing hReview of CIBC].
* [http://uk.movies.yahoo.com/movie-reviews/ Yahoo UK Movie Reviews] now supports hReview on all (>2000) reviews, e.g. [http://uk.movies.yahoo.com/h/Harry-Potter-and-the-Goblet-of-Fire/review-41195.html Harry Potter and the Goblet of Fire Review]
* [http://adam.typepad.com/impossiblethings/ Adam Hertz] wrote hReviews of [http://adam.typepad.com/impossiblethings/2005/11/soluna.html Soluna] and [http://adam.typepad.com/impossiblethings/2006/05/cafe_gibraltar.html Cafe Gibraltar]
* [http://www.mattmcalister.com/blog/ Matt McAllister] wrote an [http://www.mattmcalister.com/blog/_archives/2005/11/16/1408893.html hReview of the TV show: "The Office"]
* [http://www.bmannconsulting.com/blog/bmann/ Boris Mann] wrote an [http://www.bmannconsulting.com/blog/bmann/doubletake-best-panorama-stitch-tool-for-mac-os-x hReview of DoubleTake, a panorama stitch tool for Mac OS X]
* [http://blog.ftwr.co.uk/ Peter Westwood] has written an [http://blog.ftwr.co.uk/archives/2005/10/03/blubeckers-hampton-court/ hReview of Blubeckers Hampton Court] and an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn Bucks Green, West Sussex]
* [http://dougal.gunters.org/blog/ Dougal] has published an [http://dougal.gunters.org/blog/2005/08/03/french-vanilla-latte hReview of Wolfgang Puck’s Gourmet French Vanilla Latte].
* [http://www.dinnerbuzz.com/ Dinnerbuzz] is a great site for posting tagged reviews of restaurants, and they publish and summarize all their reviews in hReview!
* [http://soldierant.net/ Bryce Glass] posted an [http://soldierant.net/archives/2005/06/product_review.html hReview of the Uniden ELBT 595 Bluetooth Cordless Phone].
* dda posted an [http://sungnyemun.org/wordpress/?p=20 hReview of hReview] :)
* An [http://tbp.xomerang.com/?p=3 hReview of Caffè Camardo coffee].
* [http://loadaveragezero.com/hnav/contact.php Douglas Clifton] posted [http://loadaveragezero.com/#May-12-2005 comments] regarding adapting his list of ~800 [http://loadaveragezero.com/app/drx Developer Resources] as a format for evaluating hReview.
* [http://www.oliverbrown.me.uk/ Oliver Brown] [http://www.oliverbrown.me.uk/2005/05/09/sitereviewsorg-supports-hreview-i-think/ has announced] that his [http://en-us.sitereviews.org/ SiteReviews.org] (which reviews websites) publishes its reviews using hReview, e.g. here is the [http://en-us.sitereviews.org/review-photomatt.net review on SiteReviews.org for photomatt.net].
* [http://www.myelin.co.nz/post/ Phillip Pearson] is publishing hReviews in the [http://coffee.gen.nz/rss/reviews RSS feed of cafe reviews] on his [http://coffee.gen.nz/ kiwi coffee review site], which of course has the reviews in HTML with embedded hReview markup as well.
* [http://station11.net/ticker/ Kjell] is publishing his link blog as a [http://station11.net/ticker/ list of hReviews].
* [http://epeus.blogspot.com/ Kevin Marks] has [http://epeus.blogspot.com/2005_04_01_epeus_archive.html#111484565269684374 published two hReviews] and used unicode "star" characters for his ratings!
* JamesStewart is publishing hReviews in the location pages at his [http://grwifi.net Grand Rapids WiFi site].
* [http://soldierant.net/ Soldier Ant] has [http://soldierant.net/archives/2005/06/product_review.html reviewed a cordless phone].
* [http://www.happenchance.co.uk/ Paul Livingstone] uses hreview to voice his opinion on [http://www.happenchance.co.uk/archives/2005/07/war_of_the_worl.php books], [http://www.happenchance.co.uk/archives/2005/03/im_going_to_fin.php movies] and [http://www.happenchance.co.uk/archives/2005/05/eels_carling_ac.php music].
* [http://www.stuffandnonsense.co.uk/ Andy Clarke] uses hReview for his [http://www.stuffandnonsense.co.uk/general/recommended-reading.html recommended reading list].
* [http://www.tjameswhite.com/blog Tim White] has begun implementing hReviews at [http://reviews.gale.com at work].
* [http://nachlin.com/ Jim Nachlin] has added hReview publishing to the CMS he uses to publish [http://daysofleisure.com/writing his blog].
* [http://whumpdotcom.livejournal.com/236856.html Bill Humphries] has reviewed the book "A Brother's Price" on his LiveJournal.
* [http://www.thinkvitamin.com/ Vitamin] uses hReview on it's [http://www.thinkvitamin.com/reviews/ reviews] section (e.g. a [http://www.thinkvitamin.com/reviews/webapps/fluxiom/ review of Fluxiom]).
* [http://www.openguides.org/ OpenGuides] has support for the hReview microformat in svn, and for now you can see it in action on the [http://cotswolds.openguides.org/ Cotswolds OpenGuide].
* [http://paulgoscicki.com Paul Goscicki] is publishing his [http://paulgoscicki.com/#wp_movie_ratings movie ratings] using hReview.
* [http://www.cellphones.ca/ Cell Phones etc.] is using hReviews for user-contributed [http://www.cellphones.ca/cell-phones/reviews/ cell phone reviews].
* [http://www.liptrot.org Adam Liptrot] publishes movie reviews using hReview and hCard. See article at [http://www.liptrot.org/journal/entries/movies_and_microformats/ Movies and Microformats].
* [http://www.webteacher.ws Web Teacher] is using hReview for book reviews in both the hReview creator format and a modified format. See a modified example at [http://www.webteacher.ws/2006/11/review-web-design-complete.html Web Design: A Complete Introduction].
* [http://niftylist.co.uk/ The nifty list UK.] is using hReviews for user-contributed [http://niftylist.co.uk/mobiles/ mobile phone reviews].

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