Microformats Wiki - User contributions [en]

Category:public domain license

2007-07-17T03:00:32Z

ChrisCasciano: template is 'release' not 'license'

By adding the public domain license template to your user profile page, you can ensure that your contributions to the microformats.org community wiki and mailing lists are available as openly as possible. As more users choose to adopt it, much of the wiki's content will become available under clear, free terms.

You can add it to your profile by logging in, clicking on your name at the very top fo the web page (next to a user icon), and pasting the following text:

<nowiki>
{{public-domain-release}}
</nowiki>

User:ChrisCasciano

2007-07-17T02:59:30Z

ChrisCasciano:

== Chris Casciano ==

Freelance web developer working in the NY/NJ, USA area. Often on [[irc]] as pnhChris

=== Projects ===

* Textpattern Microformat Plugin - [http://placenamehere.com/TXP/pnh_mf/ pnh_mf].
* [http://placenamehere.com/mf/nnwextract/ Extract Microformats] script for NetNewsWire
* [http://placenamehere.com/mf/netnewswire/ Subscibe To hAtom] script for NetNewsWire [NOTE: obsoleted by NNW's own integration]
* [http://placenamehere.com/mf/ other random mf stuff]

=== Sites ===

* [http://placenamehere.com Place Name Here]
* [http://chunkysoup.net ChunkySoup.net]

----
{{public-domain-release}}

User:ChrisCasciano

2007-07-17T02:59:05Z

ChrisCasciano: /* Chris Casciano */

User:ChrisCasciano

2007-07-17T02:57:15Z

ChrisCasciano: /* Chris Casciano */

hcard-parsing

2007-04-16T17:22:39Z

ChrisCasciano: reverting after moving parsing suggestion to hcard-brainstorming

<h1>hCard parsing</h1>

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

== 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 URL to retrieve.

If the URL lacks a fragment identifier, then the parser should parse the entire retrieved resource for hCards.

If the URL has a fragment identifier, then the parser should parse ''only'' the node indicated by the fragment identifier and its descendants, looking for hCards, starting with the indicated node, which may itself be a single 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 hCards by referencing the [[hcard-profile|hCard XMDP profile]]. See [http://gmpg.org/xmdp/description XMDP] for more details.

A parser finds hCards in an (X)HTML context by looking for elements with the root class name "vcard" just as the following CSS class selector does:
<pre>
.vcard
</pre>

For example, the following CSS style rule sets the background of all 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 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.

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

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

==== more semantic exceptions ====

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

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.

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

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.

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.

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.

== 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 DESCRIPTION property, 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><tbodygt;</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}}

hcard-brainstorming

2007-04-16T17:21:05Z

ChrisCasciano: /* Parsing - multiple type optimizations */

<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

== FN Nickname semantic ==

There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

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

==== Proposed Parsing Rule ====

If the tel property is on an <code>a</code>, <code>area</code> or <code>object</code> and the scheme of the @href or @data is 'tel', 'fax' or 'modem', use the @href or @data value, sans URI scheme.

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

== 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 ==
''See [[geo-brainstorming]]''

== 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 for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]
* ...

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

* vat-number : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

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

== 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 (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), 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.

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

==ADR with no children==
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

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

== 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]

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

hcard-parsing

2007-04-16T17:08:57Z

ChrisCasciano: /* Proposed Additions */

<h1>hCard parsing</h1>

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

== 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 URL to retrieve.

If the URL lacks a fragment identifier, then the parser should parse the entire retrieved resource for hCards.

If the URL has a fragment identifier, then the parser should parse ''only'' the node indicated by the fragment identifier and its descendants, looking for hCards, starting with the indicated node, which may itself be a single 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 hCards by referencing the [[hcard-profile|hCard XMDP profile]]. See [http://gmpg.org/xmdp/description XMDP] for more details.

A parser finds hCards in an (X)HTML context by looking for elements with the root class name "vcard" just as the following CSS class selector does:
<pre>
.vcard
</pre>

For example, the following CSS style rule sets the background of all 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 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.

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

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

==== more semantic exceptions ====

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

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.

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

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.

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.

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.

== 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 DESCRIPTION property, 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><tbodygt;</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.

=== Multiple Type parsing ===
The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue, and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:08, 16 Apr 2007 (PDT)]

== 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}}

governance-issues

2007-03-23T15:41:59Z

ChrisCasciano: my take

== Issue Summary 2007-02-28 ==
=== Editor ===
[http://www.opendarwin.org/~drernie/ Ernest Prabhakar]

=== Contributors ===
*[[User:AndyMabbett|Andy Mabbett]]
* Joe Andrieu
* Phae
* Ryan Cannon
* Colin Barrett
* ... Please add yourself.

== Preamble ==
Over the last year, a few people (AndyMabbett, JoeAndrieu, ErnestPrabhakar) have raised issues about how the Microformats wiki, mailing list, and community are governed. This page is here to discuss ideas for documenting, formalizing, and/or improving our collective governance.

== Abstract ==
Governance has [http://www.phac-aspc.gc.ca/vs-sb/voluntarysector/glossary.html been defined] as "the traditions, institutions and processes that determine how power is exercised, how citizens are given a voice, and how decisions are made on issues of public concern." In the context of Microformats, it covers:
* Rules (both written and unwritten) expected of community members
* Who the various Admins are
* What powers Admins have
* Rules for how/when Admins can/should use those powers
* How to questioning/appealing a decision by an Admin
* How to become an Admin
* How to question/change any of these

While not all of these need to be explicitly spelled out, a healthy community our size requires a broad shared understanding of these facts -- as well as acceptance of them as "legitimate."

== Who Are Admins ==
* 2007-01-04 raised by [[User:DrErnie|DrErnie]] on [[microformats-issues]], before this page existed, and moved from there
*# ''As discussed in [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008011.html], there exist various concerns about the lack of clarity regarding governance of the list, wiki, and the specifications themselves. While agree that there does need to be some form of strong leadership to preserve the integrity of the community, I agree with [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008022.html Colin Barrett] when he said:''
:::"I think there should be bit more visible superstructure around just who is in this "cabal". It seems to me like the Editors/Authors of the various specs form the majority it of it, but perhaps that should be made a bit more apparent, and the "powers" of an editor (essentially, the ability to veto changes to the wiki, it seems) outlined a bit and some information about how to become an editor (AFIACT, make numerous, quality edits to the Wiki that the other editors approve of)."
:An entry has been added to the FAQ regarding [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F Who controls microformats?].[[User:DrErnie|Dr. Ernie]] 08:48, 2 Feb 2007 (PST)

== Mailing List Unmoderation Discussion ==
Discussion from [[mailing-list-unmoderation]].

* I'm glad to see this issue getting traction. However, I'm curious why Ernie's standing in the community is relevant to the issue of unmoderating Andy. Tantek, could you explain why that has been presented as an integral part of this decision making process? Clearly, personal clout always shapes one's ability to influence the community; however, I doubt it should be officially incorporated in these "proceedings". Shouldn't every member of the community have an equal hearing under whatever governance procedures we use? [[User:JoeAndrieu|JoeAndrieu]] 09:38, 19 Mar 2007 (PDT)

:[http://microformats.org/discuss/mail/microformats-discuss/2007-March/009066.html Tantek also said]: "''Ernie, as someone who has made overwhelmingly positive contributions to the microformats community, IMHO the occasional OT post is reasonable'".
* I believe the statement was added to give context to the appealing member of the community. i.e. Ernie is a long standing, good contributor, as opposed to someone new who has no experience with this particular community or someone who has had little or no interaction with the community until now, and also negates it being a personal statement (rather he is interested in community as a whole, instead of being a friend of the Andy and having a personal goal, for example). Basically, he is a person with a certain amount of credibility and trustworthiness. [[User:Phae|Phae]] 10:25, 19 Mar 2007 (PDT)
* Agreed, Phae, Ernie is such a person and that is Tantek's point. But should one need to be a "friend of the court" to bring an action? That practice reinforces a culture of privilege that has historically proven antithetical to transparency and equality, both characteristics of good governance, IMO. It is great to see the powers-that-be responding to Ernie's request. It is also a bit frustrating that only those deemed meritorious by the peerage can call forth due process and that Andy's own efforts to speak on his behalf--referencing my previous request to do the same--were summarily dismissed by Tantek because they were "adversarial." Any robust governance should, IMO, work independent of privilege and be capable of addressing adversarial situations without arbitrary limits on the speech of those whose liberties are under challenge.--[[User:JoeAndrieu|JoeAndrieu]] 14:18, 19 Mar 2007 (PDT)
** Point taken and appreciated, but this is the first incident to come to this kind of a situation where someone else has felt the need to step in, and just happened to also involve someone that is felt to be a member of good standing. I'd like to hope that if another member of the community had felt a similar way and had chosen to bring it up, that it would also have been dealt with in this open manner (and I'm sure this incident will be brought up in the future). Hopefully this incident will be a good test case to better structure future interactions with administration. I can't personally comment on Andy's own appeals. [[User:Phae|Phae]] 14:45, 19 Mar 2007 (PDT)
**Agreed. The first efforts to work through a process like this are bound to be less than ideal. However, I'd like to get on the record two main points that appear problematic.
# [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008490.html my previous request to do the same] was not, in fact, dealt with in this open manner. Rather it decayed into a defensive debate about governance generally, leaving poor Andy stuck in moderated censure. Perhaps I'm not the most diplomatic sort, but the issue on the table is not about me. It is about Andy's continuing moderation.
# The [[mailing-list-unmoderation|unmoderation wiki page]] for Andy is effectively a public hearing on Andy's standing and privileges in the community, especially with [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009066.html Tantek's request] that no replies be sent to the email list on the topic. I find it particularly disturbing that Andy's efforts to contribute to that hearing have been [http://microformats.org/wiki?title=mailing-list-unmoderation&diff=14419&oldid=14416 repeatedly] [http://microformats.org/wiki?title=mailing-list-unmoderation&diff=14456&oldid=14454 dismissed] by Tantek (see the [http://microformats.org/wiki?title=mailing-list-unmoderation&action=history history] for a complete list). While It probably wasn't the best form for Andy to edit my comment directly, he should, IMO, have a way to voice his opinion on the matter. He's been threatened with a ban if he does so on the mailing list. Is there another venue that is more appropriate than the wiki page taking input and votes on his unmoderation?--[[User:JoeAndrieu|JoeAndrieu]] 20:19, 19 Mar 2007 (PDT)
* Shouldn't this point be moot? According to the terms of the moderation, it will be lifted "if he successfully sends only topical / positive / improving email to the lists for one week." Once the week passed, this moderation ought to have been lifted automatically, and should not require a vote, right? --[[User:RCanine|Ryan Cannon]]
** At least one message was rejected during that first week, thus moderation was left as is, with the attention of the admins etc. focused on other higher priority matters. Given the higher quality of messages *with* moderation (as compared to before), some have made the statement that moderation is "working" and thus should be kept. [[User:Tantek|Tantek]] 08:58, 22 Mar 2007 (PDT)
* I dislike moderation because I find it causes me to be hesitant with my own contributions in some cases. Since I don't often know how long a message has been queued its hard for me to judge if my reply would be helpful, or if the moderated poster has already moved along with the rest of the discussion so I err on the side of moving onto something else. doesn't hurt me, but I feel sometimes it might not help with the overall discussions depth or conclusion. . Thus, I think the burden should be heavy to continue moderation for any length of time without a decision to unmoderate or outright ban. [[User:ChrisCasciano|ChrisCasciano]] 11:40, 23 Mar 2007 (ET)

== Examples ==
''Note: This is not to take a position on whether or not any of these decisions were appropriate or inappropriate. Rather, the existence of these events demonstrates the need to document why and how such decisions were -- or should be -- made and/or appealed.''

* Labelling microformats schema discussions as [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003551.html off-topic]
** Already covered by the [[microformats]] principles.
* Issue rejection [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008864.html governance]
* Negative, PoV and derogatory edit summary content such as "[http://microformats.org/wiki?title=hcard-authoring&diff=13621&oldid=12276#Add_To_Address_Book_Links smelled of excessive political correctness worrying]" and "[http://microformats.org/wiki?title=to-do&curid=1110&diff=13989&oldid=13988&rcid=23801 removed non-productive comment]".
** Removal of negative content from the wiki is not a negative. The Admins use their best judgment.
*[[rejected-formats#Pavatar|listing of items as "rejected"]] when [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008271.html requests for evidence of said rejection] reveal none.
** Not every email can be answered, nor should anyone expect them to be. In this case the rejection is in the mailing list archives.
* Despite an assurance that "all of the admins will be apropriately (sic) listed on the wiki page [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008526.html]", the [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F list given in FAQ] is prefaced with the qualifier "including".
** Reference for assurance? No such assurance should ever have been given.
* Removal of disputed edits / removal of negative content from the wiki
**[http://microformats.org/wiki?title=mailing-list-unmoderation&diff=next&oldid=14416 mailing-list-unmoderation (16:12, 19 Mar 2007)]
**[http://microformats.org/wiki?title=governance&curid=3084&diff=0&oldid=14390&rcid=24255 governance (12:50, 19 Mar 2007)]
** [http://microformats.org/wiki?title=governance-issues&diff=14401&oldid=14396 governance-issues (14:55, 19 Mar 2007)]
**[http://microformats.org/wiki?title=mailing-lists&curid=1297&diff=14391&oldid=14389&rcid=24254 mailing-lists (12:42, 19 Mar 2007)]

== Proposal ==

# Create a publicly-visible ''microformats-admin'' mailing list, for easily identifying and contacting all admins
# Document a forum/mechanism/process where individuals concerned about admin actions can legitimately raise their concerns, to ensure substantive issues are addressed
# Maintain a [[governance]] page that captures and describes
## the identity of current Admins
## how to contact them
## the process for becoming an Admin
## the specific kinds of behavior warranting Admin intervention
## how/when suspended/moderated individuals can return to "good standing"
## how to appeal an Admin decision/action

== Petition ==

We acknowledge that the microformats list and wiki is not a democracy, and that one of the key goals of microformats is to have as little process and structure as possible. However, at the same time we believe that the "dictatorship" needs to not merely ''be'', but ''be seen as'' "benevolent." This includes some minimal level of transparency and due process to ensure that there are legitimate ways for ordinary members to speak out if they feel (rightly or wrongly) that a particular administrative action was unwise or unfair. Whether that is similar to the '''[[#Proposal]]''' above, or a counter-proposal by the ''admin'' team, we believe that something is necessary.
:''Please add your vote here''
*+1 Ernest Prabhakar
*+1 Joe Andrieu

== Resources ==

* http://www.shirky.com/writings/group_enemy.html

mailing-list-unmoderation

2007-03-23T15:31:16Z

ChrisCasciano: my +1

Andy Mabbett was [http://rbach.priv.at/Microformats-IRC/2007-01-04#T011730 moderated (rather than banned for a week) on 2007-01-04] on the microformats mailing lists at the time for both his frequent/excessive off-topic posts, and his ignoring of several warnings from admins to please stop doing so (see microformats-discuss archives for details). Ernie P. (a longstanding overwhelmingly positive contributor to the community) has [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009063.html proposed unmoderating Andy at this point, 2007-03-19]. Please add your opinion at the end:
* +1 Ernie P.
* +1 David Janes
* +1 Nic James Ferrier
* +1 Tantek
* +1 Scott Reynen
* +1 Steve Ganz
* +1 Joe Andrieu
* +1 M. Jackson Wilkinson
* +1 BenWest
* +1 Chris Foote (Spike)
* -0.5 Edward O'Connor (hober)
* +1 Tim Whtie
* +1 Ryan Cannon
* +1 Phae
* +1 [[User:ChrisCasciano|ChrisCasciano]]
* ... add your opinion (+1 unmoderate, 0 no opinion, -1 keep moderated) and your name

===Discussion===
Moved to [[governance-issues#Mailing_List_Unmoderation_Discussion|a section on the governance issues page]].

Main Page

2007-03-22T16:35:37Z

ChrisCasciano: /* Getting Started */

__NOTOC__
<h1>Microformats Wiki</h1>

'''Hello!''' Welcome to the microformats wiki. If you haven't already done so, please see the [[introduction]] page.

Please read [[how-to-play]] before making any edits.

Please read [[process]] before proposing any new microformats.

__TOC__

==Getting Started==

[[what-are-microformats|What are microformats]]? [[what-can-you-do-with-microformats|What can you do with them]]?

The [http://microformats.org/about/ about page], [http://microformats.org/ latest news], plus recent [[press]], [[presentations]], [[books]], [[podcasts]], and [[screencasts]] are also good places for some background information. Our [[cheatsheets]] are handy if you need a quick reminder about a particular microformat. We even have a [[spellcheck|spell-check dictionary]] of microformat-related terms.

Frequently asked questions about this wiki and microformats in general are answered in the [[faq|FAQ]], and there is a [[glossary]].

Want to learn more in person? Check out [[events|microformats events]].

==Definition==

One popular definition from our [http://microformats.org/discuss/ mailing list] (see also: [[mailing-lists]]) is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

Simply put: "Microformats are a codification of convention." -- [http://easy-reader.net Aaron Gustafson]

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== How to contribute ==

Do you want to help take microformats to the next level? You can:

*Check out our open [[to-do|to do list]] for things to help get done.
*Join the [http://microformats.org/discuss mailing lists] and [[irc|IRC Channel]] to learn and help answer questions about microformats.
*[[advocacy|Advocate]] the use of microformats.
*help to [[Main_Page#microformats_wiki_in_other_languages|translate this microformats wiki into other languages]] to make microformats globally accessible.
*Find [[orphans|orphaned]] pages, and add links to them.

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]], [[examples-in-the-wild]])
* [[hcalendar|hCalendar]] - [http://microformats.org/code/hcalendar/creator hcalendar creator]
* [[hcard|hCard]] - [http://microformats.org/code/hcard/creator hcard creator]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]]
* [[geo|geo]]
* [[hatom|hAtom]]
* [[hresume|hResume]]
* [[hreview|hReview]] - [http://microformats.org/code/hreview/creator hreview creator]
* [[rel-directory]]
* [[rel-enclosure]]
* [[rel-home]]
* [[rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk|xFolk]]

== Design Patterns ==

{{design_patterns}} 

== Exploratory Discussions ==
Per the microformats [[process]]: research and analysis of real-world [[examples]], existing formats, and brainstorming to motivate the microformat. Please check [[rejected-formats]] before making additions.

* alternates [[alternates-brainstorming|alternates brainstorming]], [[alternates-examples|alternates examples]]
*[[attention]]
* blog description [[blog-description-examples|blog description examples]]
* blog info [[blog-info-examples|blog info examples]]
* blog post [[blog-post-examples|examples]], [[blog-post-formats|blog post formats]], and [[blog-post-brainstorming|blog post brainstorming]] (yielded the [[hatom|hAtom]] draft)
* book [[book-examples|book examples]], [[book-formats|book formats]], and [[book-brainstorming|book brainstorming]]
* chat [[chat-examples|chat examples]], [[chat-formats|chat formats]], and [[chat-brainstorming|chat brainstorming]]
* citation [[citation|citation effort]], [[citation-examples|citation examples]], [[citation-formats|citation formats]], [[citation-brainstorming|citation brainstorming]], and [[citation-faq|citation FAQ]]
* code [[code-examples| code examples]], [[code-brainstorming|code brainstorming]]{{NewMarker}}
* comment [[comment-problem|comment problem]], [[comment-examples|comment examples]], and [[comments-formats|comment formats]] (Some stuff needs to be extracted from [[comments-formats]])
* [[collection-description|collection description]] {{NewMarker}}
* [[course-catalog]]; [[course-catalog-examples]] {{NewMarker}}
* [[currency]]; [[currency-examples]]; [[currency-brainstorming]]; [[currency-proposal]]; [[currency-issues]]
* [[depend-examples]]: examples of dependency graphs, especially as they relate to software {{NewMarker}}
* [[digital-signatures]]: incorporation of digital signatures in Microformatted data; ([[digitalsignature-examples|digital-signature examples]], [[digitalsignature-brainstorming|digital-signatures brainstorming]]) {{NewMarker}}
* directions [[directions-examples|directions examples]] {{NewMarker}}
* directory inclusion [[directory-inclusion-examples|directory inclusion examples]], [[directory-inclusion-formats|directory inclusion formats]]. (see also [[rel-directory]])
* distributed conversation [[distributed-conversation|distributed conversation overview]], [[distributed-conversation-brainstorming|distributed conversation brainstorming]], [[distributed-conversation-examples|distributed conversation examples]], and [[distributed-conversation-formats|distributed conversation formats]]
* forms [[forms-examples|forms examples]]
* genealogy [[genealogy-formats|genealogy examples]]
* group [[group-brainstorming|group brainstorming]] and [[group-examples|group examples]]
* items [[items-brainstorming|items brainstorming]] and [[items-examples|items examples]]
* hash [[hash-examples|hash examples]]
* job listing [[job-listing-examples|job listing examples]] and [[job-listing-brainstorming|job listing brainstorming]]
* last modified [[last-modified-examples|last modified examples]], [[last-modified-formats|last modified formats]], and [[last-modified-brainstorming|last modified brainstorming]]
* hListing [[hlisting-proposal|hListing proposal]], and [[hlisting-feedback|hListing feedback]]
** Also, listing [[listing-examples|examples]], [[listing-formats|formats]], and [[listing-brainstorming|brainstorming]]
* [[product|hProduct]] - [[product-brainstorming|hProduct brainstorming]] | [[product-examples|hProduct examples]]
* [[htodo|hToDo]]
* location [[location-formats|location formats]]. (see also [[adr]] and [[geo]])
* [[luna]] ([[geo]]-like co-ordinates, for places on The Moon) - see also [[geo-extension-strawman]] a possible implementation {{UpdateMarker}}
* [[mars]] ([[geo]]-like co-ordinates, for places on the planet Mars) - see also [[geo-extension-strawman]] a possible implementation {{UpdateMarker}}
* measures and measurement units [[measure]]
* [[media-info]] ([[media-info-examples|media-info examples]], [[media-info-formats|media-info formats]], [[media-info-brainstorming|media-info brainstorming]])
* meeting minutes [[meeting-minutes-examples|meeting minutes examples]], [[meeting-minutes-formats|meeting minutes formats]], and [[meeting-minutes-brainstorming|meeting minutes brainstorming]]
* metalink [[metalink-examples|metalink examples]] {{NewMarker}}
* microsummary [[microsummary-brainstorming|microsummary brainstorming]]
* [[mfo-examples|MFO examples]]
* music [[music-examples|music examples]]
* [[operating-hours]]: [[operating-hours-examples]] ..of stores, restaurants, etc. {{UpdateMarker}}
* [[payment]]
* photo note [[photo-note-examples|photo note examples]]
*[[question-answer]], [[question-answer-brainstorming]]; [[question-answer-examples]] {{NewMarker}}
* recipe [[recipe-examples|recipe examples]], [[recipe-brainstorming]] {{UpdateMarker}}
* rel-product [[rel-product-brainstorming|rel-product brainstorming]]
* requirements testing [[requirements-testing|requirements testing overview]], and [[requirements-testing-examples|requirements testing examples]]
* [[rest-examples|REST examples]]
* resume [[resume-brainstorming|resume brainstorming]], and [[resume-formats|resume formats]]
* review [[review-examples|review examples]], and [[review-formats|review formats]] (yielded the [[hreview|hReview]] draft)
* search results [[search-results-example|search results example]]
* show [[show-brainstorming|show brainstorming]]
* showroll [[showroll-brainstorming|brainstorming]]
* [[species]] - for the marking up of the scientific names of living things: [[species-examples]]; [[species-brainstorming]] {{UpdateMarker}}
* table [[table-examples|examples]]
* tagspeak [[tagspeak-examples|tagspeak examples]]
* tagcloud [[tagcloud-examples|tagcloud examples]], and [[tagcloud-brainstorming|tagcloud brainstorming]].
* [[thoughts-on-extending-the-geo-microformat|thoughts on extending the geo microformat]], [http://microformats.telemetry.gr examples] {{NewMarker}}
* transit table [[transit-table-examples|transit table examples]]
* [[uid]]
* widget [[widget-examples|widget examples]], and [[widget-brainstorming|widget brainstorming]]
* [[wiki-formats|wiki formats]]
* work of art [[work-of-art|work of art overview]], [[workofart-examples|work of art examples]], [[workofart-formats|work of art formats]], and [[workofart-brainstorming|work of art brainstorming]]
*[[xmdp-brainstorming|XMDP brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples-in-the-wild]]
* [[implementations]]
* [[zen-garden]]

== Tools, Test Cases and Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[accessibility]]
*[[faqs-for-rdf]]
*[[icalendar-implementations]]
*[[internationalization]]
*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[http://hg.microformats.org/ Source code repository] -- [[mercurial-quick-start|HowTo: Download code from the repository]]
*[[vcard-implementations]], [[vcard-errata]], [[vcard-suggestions]]
*[[why-are-content-standards-hard]]
* [[profile-examples-in-wild|Profile examples, in the wild]]

== shared work areas ==
* [[buttons]]
* [[icons]] {{NewMarker}}
* [[spread-microformats]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[events]]
* [[to-do]]
* [[user-interface]]
* [[marked-for-deletion]]
* [[microformats-issues]] {{NewMarker}} - issues related to more than one microformat.

== microformats wiki in other languages ==

You may read and edit microformats articles in many other languages:

* languages with over 100 articles
** [[Main_Page-fr|Français (French)]] {{UpdateMarker-fr}}
* languages with over 10 articles
** [[Main_Page-pt-br| Português (Brazilian Portuguese)]] {{NewMarker-pt-br}}
** [[Main_Page-ja|日本語 (Japanese)]]
* languages with over 2 articles
** [[Main_Page-es|Español (Spanish)]]
** [[Main_Page-de|Deutsch (German)]]

==== microformats translations elsewhere ====
These are off-site pages/sites with translations about microformats. If you are working on one of these, please consider translating the main microformats website!
* [http://mikroformate.pbwiki.com/ Deutsch (German) mikroformate.pbwiki.com] {{NewMarker-de}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate this microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微格式 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])
* Does somebody want to see a Dutch translation???

hcard-faq

2006-11-07T05:19:03Z

ChrisCasciano: /* Why is url property necessary */

<h1> hCard FAQ </h1>

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

<h2> Q&A </h2>

=== Should I use ADDRESS for hCards ===
''Should I use the more semantic <code><nowiki><address></nowiki></code> element for my hCards?''
* Yes the <code><nowiki><address></nowiki></code> element is more semantic, but it is ''too'' specifically semantic for most hCard uses. The poorly named <code><nowiki><address></nowiki></code> element really means <contact-info-for-this-web-page>. The [http://www.w3.org/TR/html401/struct/global.html#h-7.5.6 HTML4 definition of the ADDRESS element] says it is used "to supply contact information for a document or a major part of a document such as a form." Therefore <code><nowiki><address></nowiki></code> should be used for an hCard ONLY IF that hCard represents the contact information for the page or major part thereof. One example of such a usage is on [http://tantek.com/log/ Tantek's blog]. Another way of saying this is the following two statements: Every <address> on a page SHOULD be an hCard. But not every hCard should be an <code><nowiki><address></nowiki></code>. <br /> In short, '''DO NOT''' use <code><nowiki><address></nowiki></code> to markup addresses in general. Only use it to markup the contact information for the page (or major part thereof), and when doing so, use it to markup ''the entire'' contact information (via <address class="vcard">), not just the address of the contact.

=== Why is url property necessary ===
''Why is it necessary to put class name "url" on URL elements in the hCard when those hyperlinks already start with "http://", and that is enough to distinguish them from email links?''
* The classname "url" is necessary to explicitly distinguish hyperlinks that are URL elements for the hCard, from other hyperlinks that may be related to the item or otherwise in the same containing element but should not be included in the hCard. Common links that may appear in the document but not be contact information are action related links (download data, add to friends list, etc.) contact hyperlinks (email, internal site messaging, autodialers), as well as hyperlinks to photos, or other random hyperlinks that happen to be inside the hCard.

=== How do I support an existing vCard URL ===
''I already have a vCard that I keep up-to-date. I don't want to change any references to it because it might break something else, what can I do?''
* You can use .HTACCESS to rewrite links to your vCard to a webservice that converts a page to the vCard dynamically, to do this you need to add something similar to your .htaccess file
<pre>
RewriteRule ^path/to/old.vcf http://suda.co.uk/projects/X2V/get-vcard.php\?uri=http://example.com/hCard_encoded.htm&filename=old.vcf
</pre>

Now you shouldn't have to do anything else, all links to the "old.vcf" are redirected to the webservice and will return a new vCard that is dynamially generated from your page.

I think that using 'Redirect' is better than using mod_rewrite (is not enabled on some hosts) --Robert Bachmann
<pre>
Redirect /path/to/old.vcf http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://example.com/hCard_encoded.htm&filename=old.vcf
</pre>

=== What are plural hCard properties ===
''Is there a list of all hCard properties which can be plural?''<br />
''Is there a list of all the properties which can have multiple instances?''
* There is the [[hcard#Property_List|list of hCard properties]], and the list of [[hcard#Singular_properties|singular hCard properties]]. Everything that is not singular is plural. This list was presented explicitly (after much analysis of RFC2426) because it was too hard to read RFC2426 and reliably grok which properties were singular vs. plural.

Old previous answer:
* We have avoided *duplicating* (or providing a shortcut for) the "can this property occur multiple times or not" deliberately in order to avoid repeating a constraint from RFC 2426 vCard, and thus potentially getting it wrong. Here is the way to determine whether or not a particular property can occur multiple times (is a plural property / may have multiple instances or values).
* Check the [[hcard-profile|hCard XMDP profile]] for the property definition.
* If the property definition references a plural form in RFC 2426 (e.g. honorific-suffix references honorific suffixes), then the property is a plural property.
* Else go check the referenced section in RFC 2426 which should state explicitly whether or not the property is plural or singular.
* Else (if RFC 2426 is *not* explicit) then the property is plural.

=== What does FN stand for ===

''What does FN stand for?''
* FN stands for "Formatted Name." From Section 3.1.1 of the RFC:
<blockquote>Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents.</blockquote>
* The reasoning behind this seems to be that, while N gives us a structured name, FN gives us the human-readable, formatted name which is assembled from its structured parts in a culturally dependant way.

=== How is gender represented ===
''How do you represent gender in hCard?''
* There is no GENDER property in [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]. [[hcard|hCard]] is following the schema from vCard for interoperability reasons. If you want, it is possible to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female:
<pre><nowiki>
<span class="honorific-prefix">Mr.</span>
</nowiki></pre>
or
<pre><nowiki>
<span class="honorific-prefix">Ms.</span>
</nowiki></pre>

Note that there is also a [http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/vcard_name.asp page on MSDN that mentions vCard and "gender"]. Not sure what to make of that.

=== Can an hCard contains extra elements ===
''Is it OK for an hCard node to contain extra elements?''
* Yes, parsers will ignore anything they don't understand.

=== Can a GEO be inferred from an ADR in an hCard ===
''Can I automatically add GEO from an address when transfoming an hCard to vCard if it is not present?''
* No, an address represents a building which is a polygon, whereas a GEO only represents a single point

=== X2V does not convert email with name as plain text ===
''X2V doesn't convert my email address correctly, it is in the form href="FirstName LastName <Email@example.com>"''
* While that form of email address works for some programs such as outlook, it is not a valid mailto: value (see [http://www.faqs.org/rfcs/rfc2368.html RFC2368]) the FirstName and LastName should be omitted.

One possible valid hCard markup would be:

<pre><nowiki>
<span class="vcard">
<span class="fn">Firstname Lastname</span>
&lt;<a class="email" href="mailto:Email@example.com">Email@example.com</a>&gt;
</span>
</nowiki></pre>



This might be displayed as:
<div style="border: thin dashed black">
Firstname Lastname <[http://email@example.com email@example.com]>
</div>

=== What hCard properties are required ===
''What properties are required in an hCard?''
* The only required properties are 'fn' (the formatted name) and 'n' (the structured name), but 'n' can under certain circumstances be inferred from the <code>fn</code> property. See the [[hcard#Implied_.22n.22_Optimization|Implied N Optimization]] for details.

=== Does N property require all subproperties ===
''If I use the 'n' property, do I have to use ALL of the sub-properties?''
* No, You can use as many or as few as you need to mark-up the name, but at a minimum you should at least use the 'given-name' and 'family-name' sub-properties if at all possible. If all you have is a nickname/handle/userid, then consider simply marking it up as an 'fn' property and taking advantage of the [http://microformats.org/wiki/hcard#Implied_.22nickname.22_Optimization Implied "nickname" Optimization].

=== Do FN and N need to be on same element ===
''Do the 'fn' and 'n' properties have to be on the same element?''
* No, you can have two separate elements, for example:
<pre><nowiki>
<p class="vcard">My name is
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-name">Q</span>
<span class="family-name">Public</span>
</span>
but you can just call me
<span class="fn">Johnny</span>
</p>
</nowiki></pre>

=== How do you convert a vCard to an hCard ===
''Is there a way to convert a vCard to an hCard?''
* There is no canonical conversion from a vCard to an hCard because you can construct an hCard in many different ways while expressing the same semantics. If you would like to recommend a suggested template hCard to use when displaying vCards in a browser, please propose it to the [http://microformats.org/discuss mailing list].

=== Are descendant elements recognized in a microformat ===
''Are descendants recognized in a microformat property?''
* Yes, for example:
<pre><nowiki>
<span class="country-name">United States <small>of</small> America</span>
</nowiki></pre>
The output would be "United States of America".

=== Do properties like TEL use all descendants ===
''Do properties like TEL use all descendants?'' e.g. <pre><nowiki><span class="tel"><span class="type">Home</span>:<span class="value">+1.234.567.8900</span></span></nowiki></pre><br>''Shouldn't that output be "TEL:Home: +1.234.567.8900"?''
* No. class="value" is used to denote a sub-element which is used for the value of the property. See [[hcard#Value_excerpting|Value excerpting]] for more details.

=== Can you have multiple value elements ===
''Can you have multiple class="value" elements inside a property and what happens to them?''
* Sure, for example:
<code><nowiki><span class="tel"><span class="type">Home</span>:<span class="value">+1</span>.<span class="value">234</span>.<span class="value">567</span>.<span class="value">8900</span></span>
</nowiki></code><br> would output: "+12345678900".

=== Can you mix properties and the root class name ===
''<span id="nesting-properties">Can you put properties on the same element as the root class for a microformat? E.g. class="vcard fn"?</span>''
* No, for several reasons:
** It breaks the simple contextual CSS selector rule for finding and styling property values: .rootname .propertyname which will make it more difficult to write scoped CSS for the properties. For more on why this is important see the [[faq#Class_interactions|microformats FAQ regarding class interactions]].
** It will result in more confusion for parsers which may be parsing nested microformats.

=== Can you mix a property and its subproperties ===
''Can singular sub-properties be mixed with parents?''
* No, all sub-properties MUST be on elements inside their parents.

=== Can you use query strings on email ===
''What happened to the Query String on my email address?''
* Query strings are removed from email addresses because they are not valid for importing to vCards

=== Are ADR and TEL types case sensitive ===
''Is the list of possible types for an ADR and TEL case sensitive?''
* No, enumerated values are case-INsensitive, therefore Home, home, HOME, etc. are all equivalent.

=== How does GEO work with ABBR ===
''What happens to the GEO sub-properties when GEO is used with ABBR?''
* The GEO property can be represented two different ways:
<pre>
<nowiki>
<span class="geo">
<span class="latitude">123.45</span>
<span class="longitude">67.89</span>
</span>

<abbr class="geo" title="123.45;67.89">My House</abbr>
</nowiki>
</pre>
When used with an <abbr> element the latitude and longitude are seperated by a semicolon.

=== Why is the root class name vcard ===
''Why is the root class="vcard" and not 'hcard'?''
* The reason is historical, hCard is based off of the vCard specification.

=== How do you markup a phone extension ===
''How do I mark-up a phone extension in hCard?''
There doesn't seem to be a way to declare a telephone extension in the vCard RFC2426 spec, the suggested way is currently:
<pre><nowiki>
<span class="tel">
<span class="type">cell</span>: <span class="value">800 555-1212 x 1234</span>
</span>
</nowiki></pre>

=== How do you encode IM accounts ===
''How do I encode my IM account in hCard?''
* see [[hcard-examples#New_Types_of_Contact_Info|hCard examples: New Types of Contact Info]]

=== Can you hCard the deceased ===
''How do you make an hCard for the deceased?''
* vCards were never designed to handle date-of-death, please refer to the biographical or [[genealogy-formats]] microformat

=== Any plans for xparams ===
''Are there plans to include x-parameters in future versions of hCard?''
* No. The problem is that each of these x-parameters are vendor specific and are not part of the RFC. Secondly, there is no way to be 100% sure that 'x-foobar' is not just a content-specific HTML class name that the publisher is using for CSS styling.

=== What is a word in implied optimizations ===
''What constitutes a "word" for the purpose of 'implied-n optimization'?''
* "N" can be implied from "FN" when the content of "FN" is broken into two "words" separated by whitespace. For this purpose, a "word" is any sequence of non-whitespace characters including but not limited to low- and high-range alphanumerics and punctuation. A "word" can be characterised by the following regular expression: <pre><nowiki>/\S+/</nowiki></pre>

=== How do you create non English tooltips ===
''My website is not in English and i want the tooltips to be in my native language''
* Properties such as class="type" require an enumerated list of English words. It is possible to use your native language for the displaying tooltip, but still use the English work for the class="type" without it being shown.
<pre><nowiki>
<abbr class="type" title="home">
<span title="[your native word for home here]">
to my home
</span>
</abbr>
</nowiki>
</pre>
Having an span with a title attribute inside the abbr element will only display the title on the span, where you have the text (your native word for home here).

licensing-examples

2006-10-19T00:53:42Z

ChrisCasciano: /* Photos (reuse) */

= Licensing Examples =

== Introduction ==

Actual examples of [[licensing]] and attribution for web pages, embedded works and derivatives thereof in practice on the web with URLs to the originals.

== Table of Contents ==

__TOC__

== Real World Examples ==

All of these examples include licensing, so they are categorized based on what is licensed and required and complementary information provided (e.g., attribution and related commerce).

=== Web pages ===

* [http://creativecommons.org Creative Commons]
** See bottom of page -- "Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 2.5 License" with [[rel-license]]'d link to license.
* [http://technorati.com/ Technorati]
** See "CC License" link to license on every page, unclear what is being licensed
* [http://en.wikinews.org/wiki/Small_aircraft_crashes_into_NYC_building WikiNews]
** See "...available under terms of the Creative Commons Attribution 2.5 License..." with license link
* Millions of such pages

=== Photos ===
* [http://flickr.com/photos/dongkwan/266246701/ Flickr]
** See (cc) some rights reserved link to license
** One of approximately 20m licensed images on Flickr
* [http://commons.wikimedia.org/wiki/Image:000_0025.jpg Wikimedia Commons]
** See license name/link. This photo is also dual licensed under GFDL.
** [http://commons.wikimedia.org/wiki/Category:Creative_Commons_licenses Thousands of similar images.]

=== Photos (reuse) ===
* [http://blog.newsvine.com/_news/2006/08/01/308898-publish-flickr-photos-to-your-newsvine-column Newsvine]
** See attribution and license link under photo -- [http://unanimocracy.newsvine.com/_news/2006/10/18/405591-traffic-reports-and-advertising example]
* [http://creativecommons.org/weblog/entry/5874 Creative Commons blog]
** See attribution and license link under photo
* [http://www.geograph.org.uk/photo/169491 Geograph Britsh Isles]
** cc-by-sa 2.0 attribution and licence under photo

=== Videos ===
* [http://blip.tv/file/18132 blip.tv]
** Click on "details" tab, link to license
** Thousands(?) of these
* [http://www.lulu.tv/?p=3562 lulu.tv]
** See "cc license" link to license
** Thousands(?) of these
* [http://www.geekentertainment.tv/2006/10/06/yahoo-locks-in-hackers-for-24-hours/ Geek Entertainment TV]
** Generic "all content on this site is licensed..." license button/link at bottom of right sidebar, meant to apply to videos too
* [http://www.archive.org/details/PaulAlien Internet Archive]
** See license button/link
** Thousands of these

=== Audio ===
*[http://www.jamendo.com/us/album/2806/ Jamendo]
** CC license button/link under tracklist
** [http://www.jamendo.com/us/?p=stats Same for 1696 albums]
*[http://www.artistserver.com/artist/index.cfm/a/14355/xmuzik_rekordz ArtistServer.com]
** "CC some rights reserved" graphic/link next to each track
** ~5000 such tracks
* [http://eze.dmusic.com/music/license/262157 DMusic.com]
** License full URL/link
** thousands(?) of same
* [http://ccmixter.org/media/files/DNA/7371 ccMixter]
** See (by:) license icon/link to license among other descriptive info for track
** [http://ccmixter.org/stats 5183 such tracks]
* [http://www.archive.org/details/hr038 Internet Archive]
** See public domain icon/link to dedication
** Thousands of similar
* [http://freesound.iua.upf.edu/samplesViewSingle.php?id=2523 Freesound]
** See "license" heading/button/link
** ~20,000 of same
* [http://www.garageband.com/song?%7Cpe1%7CS8LTM0LdsaSlYFiyZm0 GarageBand]
** See license button/link
** Thousands(?) of same
* [http://www.opsound.org/artist/jankenpopp/ Opsound]
** See "ccbysa2.0" link to license for each track
* [http://www.soundclick.com/bands/pagemusic.cfm?bandID=275014 Soundclick]
** See "CC license" link next to some tracks
** [http://www.soundclick.com/genres/cc_license.cfm?pathnow=/genres/cc_license.cfm 278,939 such tracks]
* [http://www.simuze.nl/live/ Simuze]
** See "licentie" icons/link in table of "nieuwe uplods" for each track

=== Audio (reuse) ===
*[http://ccmixter.org/media/files/norelpref/7427 ccMixter]
** See "users samples from" attributing source works

=== Attribution to creator ===
*[http://www.greglondon.com/bountyhunters/bountyhunters.htm Bounty Hunters, Map Makers & Gold Miners]
** See under "The following information is provided for attribution purposes"
*** Author's Name: Greg London
*** Title of Work: Bounty Hunters
*** URL: http://www.GregLondon.com/cc/by

=== Attribution to journal or other publisher ===
*[http://compbiol.plosjournals.org/perlserv/?request=get-document&doi=10.1371%2Fjournal.pcbi.0020131 Public Library of Science]
**Attribution (citation) to "Hamelryck T, Kent JT, Krogh A (2006) Sampling Realistic Protein Conformations Using Local Structural Bias. PLoS Comput Biol 2(9): e131"

=== Attribution to collective ===
*[http://codebook.jot.com/WikiHome Code v2 wiki]
** See bottom of page (emphasis added) "This wiki is licensed under the Creative Commons Attribution-ShareAlike 2.5 license. By editing or posting to this wiki, you agree that your contributions will be licensed under a Creative Commons Attribution-ShareAlike license, and you agree to waive attribution for your contributions with the understanding that '''copyrighted material made available from this wiki will be attributed to the wiki itself, namely the Code v.2 Wiki. Please link back to this site when giving attribution.'''"

=== Attribution with work title ===
* See "Bounty Hunters" above

=== Attribution with link required ===
* See "Bounty Hunters" above
* See "Code v2 wiki" above

=== Attribution waived ===
* [http://www.theviolinsite.com/legal.html The Violin Site]
** "Music released under this licence on Mutopia is given the additional permission that attribution is not required in audio derivatives of the work."

=== Attribution to derivative's source work ===
* See ccMixter above.

=== Attribution with description of derivative use ===
* Needed

=== Commercial licensing availability ===
* [http://magnatune.com/artists/albums/anup-embrace/ Magnatune]
** See "license" link
** One of [http://magnatune.com/info/stats/ 499 albums] with same structure
* [http://www.beatpick.com/Sinapsya Beatpick]
** See "license" link
** One of ~100 albums at BeatPick with same structure
* [http://shotgunconcepts.blogspot.com/2006/09/macys-anne-mcdonald.html Shotgun Marketing]
** See "buy this content" button bottom of page above CC license button
** Part of [http://scoopt.com/words/ ScooptWords] program.

=== Purchase related media availability ===
* See Magnatune above, "buy" link
* See Beatpick above, "buy" link
* [https://www.cruxy.com/info/5784 Dead bird photo]
** See "this work is licensed" and "buy this image"
** Cruxy.com provides same structure for any media type

=== Donation related to work availability ===
* See Jamendo above, "support this artist" link

=== Rights warranty/idemnification availability ===
* [http://docly.com/docly/view.asp?docid={2360EFD8-79CA-4C07-9681-BE103A343899} Docly]
** See license link
** See orange "n" followed by numbers link, supposedly to a verification page
* [http://www.registeredcommons.org/view/167/0/7838 Registered Commons]
** See license link
** This would presumably be a page linked to by publisher from elsewhere for verification purposes

=== License notice with content hash ===
* See DMusic above
* See Registered Commons above
* ccMixter and Internet Archive audio examples above include content hash in hidden-to-humans RDF-in-a-comment

Main Page

2006-08-11T15:24:25Z

ChrisCasciano: reverting spam

__NOTOC__
= Microformats Wiki =

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

[[what-are-microformats|What are microformats]]? And [[what-can-you-do-with-microformats|what can you do with them]]? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]], [[presentations]], [[podcasts]], and [[screencasts]] are also a good place for some background reading/listening. Frequently asked questions are answered in the [[faq]]. Want something or want to contribute? Help with things [[to-do]]. Want to learn more in person? Check out microformats [[events]].

One popular definition from our [http://microformats.org/discuss/ mailing list] (see also: [[mailing-lists]]) is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]]
* [[geo|geo]]
* [[hatom|hAtom]] {{NewMarker}}
* [[hresume|hResume]] {{NewMarker}}
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[rel-home]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk|xFolk]]

== Design Patterns ==

{{design_patterns}} 

== Exploratory Discussions ==
Research and analysis of real-world [[examples]], existing formats, and brainstorming to motivate the microformat.
*[[attention]]
* blog description [[blog-description-examples|examples]]
* blog info [[blog-info-examples|examples]]
* blog post [[blog-post-examples|examples]], [[blog-post-formats|formats]], and [[blog-post-brainstorming|brainstorming]] (yielded the [[hatom|hAtom]] draft)
* book [[book-examples|examples]], [[book-formats|formats]], and [[book-brainstorming|brainstorming]]
* chat [[chat-examples|examples]], [[chat-formats|formats]], and [[chat-brainstorming|brainstorming]]
* citation [[citation|effort]], [[citation-examples|examples]], [[citation-formats|formats]], [[citation-brainstorming|brainstorming]], and [[citation-faq|FAQ]]
* comment [[comment-problem|problem]], [[comment-examples|examples]], and [[comments-formats|formats]] (Some stuff needs to be extracted from [[comments-formats]])
* currency [[currency-examples|examples and brainstorming]] {{NewMarker}}
* directions [[directions-examples|examples]] {{NewMarker}}
* directory inclusion [[directory-inclusion-examples|examples]], [[directory-inclusion-formats|formats]]. (see also [[rel-directory]])
* distributed conversation [[distributed-conversation|overview]], [[distributed-conversation-brainstorming|brainstorming]], [[distributed-conversation-examples|examples]], and [[distributed-conversation-formats|formats]]
* forms [[forms-examples|examples]]
* genealogy [[genealogy-formats|examples]]
* group [[group-brainstorming|brainstorming]] and [[group-examples|examples]]
* hash [[hash-examples|examples]]
* last modified [[last-modified-examples|examples]], [[last-modified-formats|formats]], and [[last-modified-brainstorming|brainstorming]]
* hListing [[hlisting-proposal|proposal]], and [[hlisting-feedback|feedback]] {{NewMarker}}
** Also, listing [[listing-examples|examples]], [[listing-formats|formats]], and [[listing-brainstorming|brainstorming]]
* location [[location-formats|formats]]. (see also [[adr]] and [[geo]])
* media info [[media-info-examples|examples]]
* meeting minutes [[meeting-minutes-examples|examples]], [[meeting-minutes-formats|formats]], and [[meeting-minutes-brainstorming|brainstorming]]
* metalink [[metalink-examples|examples]] {{NewMarker}}
* [[mfo-examples|MFO examples]]
* music [[music-examples|examples]]
* photo note [[photo-note-examples|examples]]
* recipe [[recipe-examples|examples]]
* rel-product [[rel-product-brainstorming|brainstorming]]
* requirements testing [[requirements-testing|overview]], and [[requirements-testing-examples|examples]]
* [[rest-examples|REST examples]]
* resume [[resume-brainstorming|brainstorming]], and [[resume-formats|formats]]
* review [[review-examples|examples]], and [[review-formats|formats]] (yielded the [[hreview|hReview]] draft)
* search results [[search-results-example|example]]
* show [[show-brainstorming|brainstorming]]
* showroll [[showroll-brainstorming|brainstorming]]
* table [[table-examples|examples]]
* tagspeak [[tagspeak-examples|examples]]
* transit table [[transit-table-examples|examples]]
* [[uid]]
* widget [[widget-examples|examples]], and [[widget-brainstorming|brainstorming]]
* [[wiki-formats|wiki formats]]
* work of art [[work-of-art|overview]], [[workofart-examples|examples]], [[workofart-formats|formats]], and [[workofart-brainstorming|brainstorming]] {{NewMarker}}
*[[xmdp-brainstorming|XMDP brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]]

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[accessibility]]
*[[faqs-for-rdf]]
*[[icalendar-implementations]]
*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[http://hg.microformats.org/ Source code repository]
*[[vcard-implementations]], [[vcard-errata]]
*[[why-are-content-standards-hard]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[events]] {{NewMarker}}
* [[to-do]]
* [[user-interface]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in many other languages:

* languages with over 50 articles
** [[Main_Page-fr|Français (French)]] {{NewMarker-fr}}
* languages with over 2 articles
** [[Main_Page-ja|日本語 (Japanese)]]
** [[Main_Page-es|Español (Spanish)]]
* languages with 2 articles
** [[Main_Page-de|Deutsch (German)]]

==== microformats translations elsewhere ====
These are offsite pages/sites with translations about microformats. If you are working on one of these, please consider translating the main microformats website!
* [http://mikroformate.pbwiki.com/ Deutsch (German) mikroformate.pbwiki.com] {{NewMarker}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微格式 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])

user-interface

2006-08-02T14:09:01Z

ChrisCasciano:

<h1> User Interface </h1>

Recently there have been many really good user interface ideas and suggestions for working with microformats. This page serves to collect and document them so that we may be inspired by and iterate on each others' works.

__TOC__

== Implementations ==

See [[implementations]], and document examples of good UI from there, here.
* [[Miffy]] inserts a green square into the document to represent the presence of microformat
* Some [[Greasemonkey]] scripts use a separate iFrame for microformat content
* Other [[Greasemonkey]] scripts insert an icon inline into the page
* [https://addons.mozilla.org/firefox/2240/ Tails Export] (Firefox extension) can display and export some microformats.

== Challenges ==

* Chris Messina: "What kind of solutions can we come up with that are single click only?"

== Browser Integration ==

From screenshot brainstorms to working plugins, there is a lot going on with browser integration of microformats support.

=== Screen Shots ===
* http://www.hicksdesign.co.uk/journal/a-proposal-for-a-safari-microformats-plugin
* http://ben-ward.co.uk/journal/microformats-ui/
* http://blog.wilsonet.com/archives/2006/04/30/microformats-in-flock/

=== Plugins ===

* The microformat [[implementations]] page has some Greasemonkey scripts.
* http://greasemonkey.makedatamakesense.com/callto_tel/ by Scott Reynen
* [https://addons.mozilla.org/firefox/2240/ Tails Export] (Firefox extension) by Robert de Bruin.

=== Planning and Discussion ===

* The [http://wiki.caminobrowser.org/Development:Planning:Microformats Camino Wiki has a page] where future microformats support is being discussed and organized

user-interface

2006-08-02T14:07:41Z

ChrisCasciano: added planning/discssion section + camino

<h1> User Interface </h1>

Recently there have been many really good user interface ideas and suggestions for working with microformats. This page serves to collect and document them so that we may be inspired by and iterate on each others' works.

__TOC__

== Implementations ==

See [[implementations]], and document examples of good UI from there, here.
* [[Miffy]] inserts a green square into the document to represent the presence of microformat
* Some [[Greasemonkey]] scripts use a separate iFrame for microformat content
* Other [[Greasemonkey]] scripts insert an icon inline into the page
* [https://addons.mozilla.org/firefox/2240/ Tails Export] (Firefox extension) can display and export some microformats.

== Challenges ==

* Chris Messina: "What kind of solutions can we come up with that are single click only?"

== Browser Integration ==

From screenshot brainstorms to working plugins, there is a lot going on with browser integration of microformats support.

=== Screen Shots ===
* http://www.hicksdesign.co.uk/journal/a-proposal-for-a-safari-microformats-plugin
* http://ben-ward.co.uk/journal/microformats-ui/
* http://blog.wilsonet.com/archives/2006/04/30/microformats-in-flock/

=== Plugins ===

* The microformat [[implementations]] page has some Greasemonkey scripts.
* http://greasemonkey.makedatamakesense.com/callto_tel/ by Scott Reynen
* [https://addons.mozilla.org/firefox/2240/ Tails Export] (Firefox extension) by Robert de Bruin.

=== Planning & Discussion ===

* The [http://wiki.caminobrowser.org/Development:Planning:Microformats Camino Wiki has a page] where future microformats support is being discussed and organized

hatom-issues

2006-07-24T13:26:24Z

ChrisCasciano: /* 'MAY have multiple Feed elements' -- details and viability of multiple feeds */

__TOC__

= hAtom 0.2 =

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

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

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

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

to-do

2006-07-17T14:01:59Z

ChrisCasciano: /* Chris Casciano */

<h1>To Do</h1>

This page is for posting [[microformats]] related shared to do items. If you want to use this page for your microformats related to-do items, create a section with your name on it. The reason we are keeping these all on the same page is to make it easier to tell when people are working on similar things, and to make it more obvious when people help out with other people's tasks. In theory this probably won't scale, but let's first see how it does in practice. :) - [http://tantek.com Tantek]

__TOC__

== Lazyweb ==

Just some nice things, feel free to do any of these.

=== for all microformats ===
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.
* write up [http://microformats.org/discuss/ mailing-list] questions and answers in the appropriate [[faq]] pages.
* validators. See the hReview section below as there has been a request for an hReview validator in particular. See [http://norman.walsh.name/2006/04/13/validatingMicroformats Norman Walsh's blog post "Validating microformats"] for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.

=== hReview ===
* [[hreview|hReview]] support in Ecto (hey Adriaan!), requested by Andy Smith
* an [[hreview|hReview]] validator.
* a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)
** both [http://komodomedia.com/blog/index.php/2005/08/24/creating-a-star-rater-using-css/ this] and [http://factorycity.net/demos/drupal/rating/default.html this] have some flaws. Ask [[User:RyanKing|Ryan King]] for an explanation.

=== hCard ===
* microformatted versions of conference pages
** Do a revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].
* vcard to hcard converter
** would be nice to have a web upload UI that would take one or more vCards from apple's address book and give them back to you as hCards
** [[User:RobertBachmann | RobertBachmann]] suggests starting points:
*** For Ruby: http://vpim.rubyforge.org/
*** For C: http://freshmeat.net/projects/libvc/
*** For Python: http://www.nongnu.org/python-pdi/
*** For PHP: http://pear.php.net/package/Contact_Vcard_Parse/
* add export support for microformats to [http://www.turingart.com/abForWeb_lan__en.htm AB to Web]
* A mash-up with google maps that will take any url with a hcard (or hcard's) and map the location(s) on a map (similar to [http://austin.adactio.com/ austin.adactio.com])

=== hCalendar/hCard/hReview editor ===
* onblur in the URL field (e.g. on hCalendar), goes out and tries to retrieve an object of same time (e.g. an hCalendar vevent) from that URL and uses it to autofill the form, same thing if the creator is loaded with that URL prefilled (e.g. due to a ?url=http://example.com/ in the URL that loads the creator).

=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvement
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]

=== Yahoo Open Source Library Patches ===

Several of these could very much be improved with a little microformats markup. Do we just make patches and submit them? Contact Nate Koechley at Yahoo (see Tantek for contact info) to follow-up.

* [http://developer.yahoo.net/yui/ Yahoo! User Interface Library]
* [http://developer.yahoo.net/ypatterns/ Yahoo! Design Patterns Library]
* [http://www.yuiblog.com Yahoo! User Interface Blog]

=== Drupal patches for microformats ===
* submit patches for Drupal code/templates for microformats improvement
* Drupal modules for microformats, specifically hReview and hCalendar

=== Adding Markup to Existing Pages (W3C track at WWW2006) ===

* DanC offers a 150 point bounty to anybody who takes [http://www.w3.org/2006/05/w3c-track the W3C track at WWW2006] and adds hCalendar markup and sends it to connolly@w3.org,www-archive@w3.org

== Tantek ==

I'm keeping a few microformats related to-do items here both for my own convenience, and for folks looking to help out with small tasks. If so, just create a new section with your name, and and maybe copy the item there, and put your name next to the item in my list. We'll figure this out as we go along. Thanks, [http://tantek.com Tantek].

=== for all microformat specs ===
* modularize any specs which are > 30K in order to avoid loss/corruption like [http://microformats.org/wiki?title=Special:Contributions&target=Evan Evan's 14 June edits] to [[hcard|hCard]], [[rel-tag]], and [[xoxo|XOXO]].
** [[hcard|hCard]] - need to create new pages for [[hcard-examples-in-the-wild]] (perhaps grouped/ sorted by individuals, organizations, and hosting sites?), [[hcard-implementations]] at a minimum to separate out that content, and leave short summaries in their existing place inline in the [[hcard|hCard]] spec.
** [[rel-tag]]
** [[xoxo]]

* sort implementations by authoring/creating/publishing, browsing/viewing, converting/importing, indexing/searching.

Hmmm... I like: '''A'''uthoring, '''B'''rowsing, '''C'''onverting, '''I'''ndexing, '''L'''ibraries (for developers), and '''P'''otential (for open source projects we want to add support to). Anybody have alternative suggestions for this vocabulary? I don't have a particularly strong preference so I'm going to go with these four until I find examples that don't fit, or someone suggests something better.

See: [http://microformats.org/wiki/hcalendar#Implementations hCalendar Implementations] for a first attempt at this. Assuming folks like that, we can go ahead with categorizing the implementations sections of other microformats specifications.

=== iterate on current microformats ===
==== [[hreview|hReview]] ====
* Write hReview 0.3 XMDP profile, and reconcile with [[hcalendar-profile]] and [[hcard-profile]]. Makes sense to have a combined profile of all three for hReview, since hReview normatively depends on hCard and hCalendar.

==== [[hcalendar|hCalendar]] ====
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need to resolve all outstanding [[hcalendar-issues]] to-do items.
* create [[hcalendar-profile]] and have folks verify it. note that it will likely need reconciliation with the [[hcard-profile]], especially since [[hcalendar|hCalendar]] normatively depends on [[hcard|hCard]]. Probably makes sense to have a combined profile which hCalendar would use.

==== [[hcard|hCard]] ====
* [[hcard-examples]]
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].
** add example of organization-name and organization-unit usage.
* Examples in the wild - need to create a new page for them!
** Group examples in the wild according to:
*** Individuals - one card per person, perhaps sort alphabetically
*** Organizations - one card per organization, alphabetical again
*** Institutions (which list more than one person), with a count estimating the # of hCards, e.g. 40k for Avon
*** Online Profiles (which host profiles for more than one person) with a count estimating the # of hCards, e.g. 3.5m for Flickr.com
*** Online Venues (which provide listings for businesses or organizations) with a count estimating the # of venues, e.g. ~10k for Upcoming.org
*** Speakers Listings (lists of speakers on conference sites) with a count estimating the # of speakers, e.g. ~300 for SXSW 2006.
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== introduction / community ===
* microformats-discuss
** introductory email sent to new subscribers needs to direct people to [[process]] and [[how-to-play]]
* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.

=== profiles ===

* update XMDP with new required features:
** ability for one profile to include/import another (rel="import" ?)
** ability to reference an XMDP via rel="profile" (similar to XHTML2 rel value by same name)
** ability/suggestion to reference an XMDP using <a href> in addition to <link>

=== microformat parsing documentation ===
* Add XPath equivalents where appropriate in [[hcard-parsing]]

=== create microformats wiki pages for ===
* *-authoring for all microformats
* *-parsing for all microformats

=== improve usability and automation on the site ===
* figure out how to get wordpress to autopost blog posts to the microformats-announce list
** ideally use the from address of the author of the blog post
** maybe photomatt knows how to do this.

=== help with microformat implementations ===
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** look for hcards and parse them
* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.
* Conference Schedule Creator
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

=== help with microformat examples in the wild ===
Go over all "common" pages (both logged out and logged in states) of the following sites which have some microformats already, and verify each page is as microformatted as it can be with high fidelity [[hcalendar|hCalendar]] and [[hcard|hCard]] etc. Document full support of each implementation's microformats on the implementations page (perhaps create a separate page for each implementation, e.g. [[flickr]], [[upcoming]], [[eventful]] etc.) Document any exceptions as needed. In no particular order:
* Flickr.com (3.5m hCards)
* Upcoming.org (100k hCalendar events, 100k hCard venues)
** home page
* Eventful.com (100k hCalendar events, 100k hCard venues)
* Yahoo! Tech (300k products with hReviews)
* JudysBook.com (???k hReviews)
* ... lots more, get from "Implementations" and "Examples in the Wild" sections of specs.

=== help with new microformat requests ===
* expense reports (really just a list of "expense" items), [http://flickr.com/photos/edyson/56774178/ requested by ED], should look at UBL as a pre-existing format
* photo-notes microformat
** clean up Subethaedit notes from working session with Greg Elin, Ryan King, Kevin Marks, Suw Charman and email to folks and figure out next steps
** iterate on [[photo-note-examples]] and start [[photo-note-formats]] and [[photo-note-brainstorming]].

* Can we make "microformat" and "microformats" into [http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ Community Marks]?

==Ryan==
=== hCalendar/hCard/hReview creator improvements ===
* get all creators working in IE/Win, IE/Mac, Safari/OSX.3

=== *-authoring microformats wiki pages ===
* Add some tips to [[hcard-authoring]] - a tutorial on creating an hCard for your site, blog (common platforms), etc.
* [[hcalendar-authoring]] - a tutorial on how to blog events so your friends can subscribe to them
* [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.

=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15) -> verify http://svn.lifelint.com/hcalendar_tests/calendar-todo-multiple-attendees-and-alarm.xml

=== rel-payment ===
* update rel-payment to reference the IANA registry [http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02055.html]

=== hcalendar ===
* make sure we explicitly disallow 'vjournal'

== Dimitri Glazkov ==

* Figure out REST/Microformats thing
* Work on result set idea
* Implement h-creators using Web Forms 2.0

== Chris Messina ==

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item (take a look at [[media-info-examples]])
* Work on microformats tutorial for designers

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts" (see [http://factoryjoe.com/blog/2006/03/20/flocktails-for-flock/ Flocktails])
* Better hCal support -- support many views of same hCal data on one page using XSLT
* We need something that a designer/web programmer can come to and leave w/ 2 examples of each microformat that they can apply right away... a "microformats styleguide for designers", if you will.
* invoicing microformat
* better microformats wiki theme

== Robert Bachmann ==

=== hCard Creator ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** aim / instant messaging contact info, using the techniques documented in [[hcard-examples#New_Types_of_Contact_Info|hCard Examples: New Types of Contact Info]]
*** consider a popup menu for the IM service (AIM|Yahoo|...), and a field next to it for the IM id.

=== hAtom2Atom ===

Some ideas for features which could be implemented :

(If you are interested in one of this features, add "<i>+1 Your Name</i>")

<ul>
<li>
Join all hfeed's inside a page (or a fragment thereof) into one feed using [http://greenbytes.de/tech/webdav/rfc4287.html#element.source atom:source] semantics.
</li>
<li>
Extraction of <code>atom:content</code>, <code>atom:summary</code> and <code>atom:title</code>:
* <code>atom:content</code> and <code>atom:summary</code> as HTML
* <code>atom:content</code> and <code>atom:summary</code> as plain-text
* <code>atom:title</code> as XHTML
* <code>atom:title</code> as HTML
</li>
<li>Support for other XSLT engines:
* MSXML
* .Net System.Xml
* Sablotron
* Oracle XSLT
* XT
</li>
<li>Support for other output formats: (hAtom2<i>xyz</i>.xsl)
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl])
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt])
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])
* JSON?
</li>
</ul>

([[User:Singpolyma|singpolyma]] 01:02, 9 May 2006 (PDT) -- Not XSLT, but see http://xoxotools.ning.com/hatom2rss.php for hatom to RSS2.0 conversion)

== Brian Suda ==
=== Citation Microformats ===
* Add all my notes to the Wiki
* Start the process of naming the properties using existing names

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working
==== WARNINGS and ERROR ====
work on the warnings and error output for the pre-check in X2V

=== FAQ ===
* clean-up the MF FAQs
* clean-up FAQs from the major microformats
* pull Questions from the mailing list and document them to the FAQs and example

== Mark Rickerby ==

=== Current Tasks ===

* Follow up on usability review
** Edits to homepage feature box text
** Draft of [[getting-started]] page
* Review content for new pages - [[start-simple]], [[modularity]], [[reuse]], [[humans-first]]
* xoxo datatype examples
** test case lists
** transmitting key/value lists
* practical feedback on hresume

=== Wishlist ===

* hmmm

== Ernest Prabhakar ==
=== Wiki-Thon Proposal ===
Set aside several hours (probably a Friday night US PST) for focused work on the Wiki, including both physical (e.g., a room in the Bay Area) and virtual (IRC/iChat) participants.

==== Goals ====
# Improve understanding of what needs to be done for Wiki
#* IMHO - this should be done here, in [[to-do]] incrementally. -Tantek
# Tackle larger projects (~1-2 hours) than people usually have time for
#* I'd like to see these projects *documented* first on [[to-do]] before we spend 1-2 hours of a bunch of folk's collective time to go through them. -Tantek
# Motivate community to have fun with otherwise tedious "housecleaning" chores

==== Agenda (Wishlist) ====
In parallel:
* Coalesce/prioritize existing To-Do items (above)
* Review/revise desired pathways for:
** New users learning about microformats
*** e.g., intro, about, explore, tutorials, etc.
*** cf. [http://www.rubyonrails.com/ Rails] front page
****Get Excited (Why, background, motivation)
****Get Started (What, downloads, getting started)
****Get Better (How, tutorials, )
****Get Involved (Who)
** Microformat lifecycle
*** e.g., research->brainstorm->proposal->spec->maintain
*** see http://theryanking.com/microformats/method.txt --[[User:RyanKing|RyanKing]] 15:35, 22 Feb 2006 (PST)
*** ensure information easy to find, follow, and up-to-date
* Review existing specs for completeness and consistency
* Identify areas of 'bitrot' or 'hole-filling'
* Do it!

== Dan Connolly ==

[[User:DanC|DanC]] hopes to sync up on these tasks in [[irc]] roughly
weekly, during Wednesday afternoon (Chicago time) "office hours". See also my [http://esw.w3.org/topic/DanConnolly esw todo list and someday pile].

* from SxSW in Austin
** build a combined hcalendar/hcard profile; resolve issues in [[profile-uris]].
*** with XSLT transformation to RDF
** finish [[hcard-tests]]
*** figure out [[include-pattern]] boundaries

* Medium term
** sync [[hcalendar-tests]] and [http://www.w3.org/2002/12/cal/ RDF calendar] tests and CALSIFY
*** reconsider RDF calendar naming conventions
*** get an answer from the CALSIFY WG re [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0006.html dtstart and date vs datetime ] 21 Apr 2006
*** refine [[hatom]] so that it's suitable for the workflow around the W3C homepage.

* from WWW2006
** follow up on GRDDL as escape valve for microformats proposals, much like CSS was an escape valve for HTML tag proposals.

* Someday pile
** set up a timezone registry based on wikipedia and semantic mediawiki. As discussed in [[datetime-design-pattern]], iCalendar's by-value timezone passing is broken. see [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0002.html reconsidering timezones in light of hCalendar and CALSIFY] and [http://dig.csail.mit.edu/breadcrumbs/node/91 Toward Semantic Web data from Wikipedia]
** update my CV/resume using [[hResume]] and [[citation-formats]]
** noodle on a playlist format and some of the media RSS stuff like [[media-info-brainstorming]]
** check out that hReview bug stuff...
** noodle on [[meeting-minutes-brainstorming]] and [http://esw.w3.org/topic/MeetingRecords MeetingRecords in the esw wiki].
** noodle on clipboard scenarios, esp how RDFa works in the general case but isn't as author-friendly as domain-specific syntaxes.

[[User:DanC|DanC]] 15:39, 31 May 2006 (PDT)

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

* get around to updating [[hatom-issues]] with some multi feed rules/exceptions.
* <del>Update textpattern plugin with simple hreview support and get a new release out</del>
* Redesign placenamehere.com and include hatom
* Follow up with technorati folks on pingerati reviews getting lost (note: this will require publishing more reviews and theen watching them through the update process)
* <del>prototype a NetNewsWire microformat extractor (CSS+AppleScript)</del>

== New Person 2 ==

etc.

User:ChrisCasciano

2006-07-14T03:58:12Z

ChrisCasciano: /* Projects */

== Chris Casciano ==

Freelance web developer... often on irc as pnhChris

=== Projects ===

* Textpattern Microformat Plugin - [http://placenamehere.com/TXP/pnh_mf/ pnh_mf].
* [http://placenamehere.com/mf/nnwextract/ Extract Microformats] script for NetNewsWire
* [http://placenamehere.com/mf/netnewswire/ Subscibe To hAtom] script for NetNewsWire
* [http://placenamehere.com/mf/ other random mf stuff]

=== Sites ===

* [http://placenamehere.com placenamehere.com]
* [http://chunkysoup.net ChunkySoup.net]

hcalendar

2006-07-14T03:57:15Z

ChrisCasciano: /* Aggregators */

<h1> hCalendar </h1>

hCalendar is a simple, open, distributed calendaring and events format, based on the iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]), suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. hCalendar is one of several open [[microformats|microformat]] standards.

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.

__TOC__

== Specification ==

; Editor : [http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati, Inc])
; Authors : [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc]
: [http://suda.co.uk/ Brian Suda]

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

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

=== Inspiration and Acknowledgments ===
Thanks to:
* Adam Bosworth for leading the [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars FOO Camp 2004 HTML For Calendars presentation] which brought together a critical mass of interested parties.

== Introduction ==
The iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]), has been broadly interoperably implemented (e.g. Apple's "iCal" application built into MacOSX).

In addition, bloggers often discuss events on their blogs -- upcoming events, writeups of past events, etc. With just a tad bit of structure, bloggers can discuss events in their blog(s) in such a way that spiders and other aggregators can retrieve such events, automatically convert them to iCalendar, and use them in any iCalendar application or service.

This specification introduces the '''hCalendar''' format, which is a 1:1 representation of the aforementioned iCalendar standard, in semantic XHTML. Bloggers can both embed hCalendar events directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCalendar enables applications to retrieve information about such events directly from web pages without having to reference a separate file.

== Semantic XHTML Design Principles ==

{{semantic-xhtml-design-principles}}

== Format ==

=== In General ===

The iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]) forms the basis of hCalendar.

Note: the editor and authors of this specification are tracking the [http://lists.osafoundation.org/pipermail/ietf-calsify/ "iCal-Basic" effort] and intend to base the core hCalendar profile on iCal-Basic. See references for a link to the current draft.

The basic format of hCalendar is to use iCalendar object/property names in lower-case for class names, and to map the nesting of iCalendar objects directly into nested XHTML.

=== More Semantic Equivalents ===

However, for some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:
* <code>URL</code> in iCalendar becomes <code><a class="url" href="...">...</a></code> inside the element with <code>class="vevent"</code> in hCalendar.
* <code>ATTENDEE</code>, <code>CONTACT</code>, and <code>ORGANIZER</code> in iCalendar may be represented by an [[hcard|hCard]] in hCalendar .
* A named <code>LOCATION</code> (potentially with an address and/or geo) in iCalendar may be represented by a nested [[hcard|hCard]] in hCalendar. Similarly, an address <code>LOCATION</code> may be represented by an [[adr]], and a geo (latitude and longitude) <code>LOCATION</code> may be represented by a [[geo]].
* <code>UID</code> in iCalendar simply becomes another semantic applied to a specific URL for an hCalendar event.

=== Singular vs. Plural Properties ===

For properties which are singular (e.g. "N" and "FN" from vCard), the first descendant element with that class should take effect, any others being ignored.

For properties which can be plural (e.g. "TEL" from vCard), each class instance should create a instance of that property. Plural properties with subtypes (e.g. TEL with WORK, HOME, CELL from vCard) can be optimized to share a common element for the property itself, with each instance of subtype being an appropriately classed descendant of the property element.

==== Plural Properties Singularized ====

Since plural property names become their singular equivalents, even if the original plural property permitted only a single value with multiple components, those multiple components are represented each with their own singularly named property and the the property is effectively multivalued and subject to the above treatment of multivalued properties.

=== Human vs. Machine readable ===
If an <code><nowiki><abbr></nowiki></code> element is used for a property, then the '<code>title</code>' attribute of the <code><nowiki><abbr></nowiki></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. This specification recommends that such <code><nowiki><abbr></nowiki></code> elements be used for the following iCalendar properties:
* DTSTART, DTEND, DURATION, RDATE, RRULE

== Example ==

Here is a sample event in an iCalendar:
<pre><nowiki>
BEGIN:VCALENDAR
PRODID:-//XYZproduct//EN
VERSION:2.0
BEGIN:VEVENT
URL:http://www.web2con.com/
DTSTART:20051005
DTEND:20051008
SUMMARY:Web 2.0 Conference
LOCATION:Argent Hotel\, San Francisco\, CA
END:VEVENT
END:VCALENDAR
</nowiki></pre>
and an equivalent event in hCalendar format with various elements optimized appropriately. See [[hcalendar-example1-steps]] for the derivation.

<pre><nowiki>
<span class="vevent">
<a class="url" href="http://www.web2con.com/">
<span class="summary">Web 2.0 Conference</span>:
<abbr class="dtstart" title="2005-10-05">October 5</abbr>-
<abbr class="dtend" title="2005-10-08">7</abbr>,
at the <span class="location">Argent Hotel, San Francisco, CA</span>
</a>
</span>
</nowiki></pre>
which could be displayed as:

[http://www.web2con.com/ Web 2.0 Conference: October 5-7, at the Argent Hotel, San Francisco, CA]

Note 1: The product information is not necessary since hCalendar is an interchange format. When transforming hCalendar back into iCalendar, the transforming engine should add its own product ID.

Note 2: A surrounding <code><nowiki><span class="vcalendar"></nowiki></code> element is optional, and is left out as such. It is optional since the context of a vcalendar is implied when a vevent is encountered. The implied context/scope is that of the document. Authors may explicitly use elements with class="vcalendar" to wrap sets of vevents that all belong to the same calendar, e.g. when publishing multiple calendars on the same page.

Note 3: The version information is unnecessary in hCalendar markup directly since the version will be defined by the profile of hCalendar that is used/referred to in the 'profile' attribute of the <head> element.

Note 4: ISO8601 dates (required by iCalendar) are not very human friendly. In addition, the year is often understood implicitly by humans from the context. Thus <code><nowiki><abbr></nowiki></code> elements are used to simultaneously provide a human friendly date and/or time in the visible contents of the element, while placing the respective machine parsable comprehensive ISO8601 datetime in the 'title' attribute.
The notation YYYY-MM-DD should be used for better readability.

Note 5: The difference between the DTEND ISO8601 date (2005-10-08) and the human readable date (7) is NOT a mistake. [http://lists.osafoundation.org/pipermail/ietf-calsify/2005-September/000769.html DTEND is exclusive], meaning, that the event ends just before the DTEND. Thus for events which start on one day and end on another day, the DTEND date must be specified as the day after the day that a human would say is the last day of the event.

Note 6: The location in this example contains implicit structure (venue name, city, state) which could be marked up explicitly as an [[hcard|hCard]]. See [http://microformats.org/wiki/hcalendar-brainstorming#hCard_locations hCalendar brainstorming: hCard locations] for a informative explanation of how to do this.

See [[hcalendar-examples]] for more hCalendar examples

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

The following sites have implemented 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 pages are marked up with hCalendar, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

=== New Examples ===
Please add new examples to this section.
* [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 two issues arose: the '''Firefox tails extension''' doesn't get a summary when it's an alt-text in an image. Also the '''default charset''' when creating an iCal file through the [http://feeds.technorati.com/events/http://www.fuckparade.org/flyer/2006/ Technorati feed] is UTF-8, but our website is ISO-8859-15. Is there a way to define a different charset, or why doesn’t the API respect the charset given by the website in the first place (in our case it’s in the HTPP header, in the XML declaration, ''and'' the meta tag)?
* [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://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:

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!
ADVERTISEMENT

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

* [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 [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

=== Examples with some problems ===
* [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 !
** dtstart/dtend are implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006
* [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
* The [http://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm.htm program] marked up with hCalendar.
** dtstart/dtend implemented on dt element [[User:TomArmitage|Tom Armitage]] June 23, 2006

- whilst Tails parses dtstart/dtend on <em>any</em> element, technically it really needs to be on abbr. Technorati Microformats Search only looks for the title element on <code><nowiki><abbr></nowiki></code> tags, for instance.

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

The following implementations have been developed which either generate or parse hCalendars. If you have an hCalendar 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.

=== Authoring ===
Implementations you can use to author, create, and publish hCalendar events.

==== Blogging and CMS tools ====
;Midgard CMS : [http://www.midgard-project.org/documentation/net-nemein-calendar/ Midgard CMS - net.nemein.calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius]

;Drupal module : [http://hybernaut.com/upcoming-hcal Drupal Upcoming.org syndication module emits hCalendar]
;MovableType and WordPress plug-ins : [http://structuredblogging.org/formats.php StructuredBlogging] is a set of plugins [http://structuredblogging.org/structuredblogging-wp-latest.zip for WordPress] and [http://structuredblogging.org/structuredblogging-wp-latest.zip for MovableType] that supports embedding hCalendar and other microformats in templates and blog posts.
;Textpattern plug-in : [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding hCalendar and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].

==== Browser scripts and plug-ins ====
Browser plugins that work with existing authoring tools:
; Any browser with javascript and a little bit of CSS : [http://microformats.org/code/hcalendar/creator microformats.org hCalendar creator] (see also original: [http://theryanking.com/ Ryan King] has an [http://theryanking.com/microformats/hcalendar-creator.html hCalendar creator]).
; Firefox Greasemonkey user script hCalendar creator : [http://www.decafbad.com/blog/2005/06/08/greasemonkey_magic magic_hcalendar Greasemonkey user script by Les Orchard] - allows easy form entry of an event into any textarea, e.g. into a blog post text area.
; Firefox Greasemonkey user script hCalendar to Google Calendar: [http://torrez.us Elias Torres] has created a [http://torrez.us/archives/2006/04/13/431/ simple script] that will parse hCalendar entries and create a link to add event to [http://www.google.com/calendar/ Google Calendar's] service. Based on [http://virtuelvis.com/archives/2005/11/learn-to-love-microformats George's] and [http://virtuelvis.com/archives/2005/11/learn-to-love-microformats Arve's] work.

==== Desktop Authoring Tools ====
;Dreamweaver Extension : [http://www.webstandards.org/action/dwtf/microformats/ Extension suite] for Dreamweaver 8 from the [http://webstandards.org/ Web Standards Project].
;xfy :
In [https://www.xfytec.com/community/ xfy Community], there are some hCalendar implementations.

* [https://www.xfytec.com/community/modules/mydownloads/singlefile.php?cid=15&lid=25 hCalendar via RSS] parses an RSS feed, retrieves XHTML documents linked from that feed, and syndicates hCalendars into a calendar view.
* [https://www.xfytec.com/community/modules/mydownloads/singlefile.php?cid=19&lid=23 hCalendar Marker XVCD] helps to mark up an event information in XHTML document with hCalendar.
* [https://www.xfytec.com/community/modules/mydownloads/singlefile.php?cid=15&lid=17 Simple RDF Calendar XVCD] is a schedule tool which uses RDF Calendar format. It also converts RDF Calendar format to iCalendar and hCalendar format.

=== Search and Discovery ===

* [http://kitchen.technorati.com/search Technorati Microformats Search] indexes [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] as [http://tantek.com/log/2006/05.html#d31t1802 announced by Tantek].

=== Conversion and Import ===
Implementations you can use to importing into a Calendar Application, typically by converting hCalendar to iCalendar/vCalendar.

==== Web Services ====
These return iCalendar (.ics) and other calendar formats for easy importing into typical calendar programs or other processing.
* [http://feeds.technorati.com/events Technorati Events Feed service] uses X2V library to parse hCalendar and return iCalendar (.ics). Note friendly URL, e.g. http://feeds.technorati.com/events/http%3A//microformats.org
* [http://suda.co.uk/projects/X2V/ X2V] parses hCalendar and produces a .ics (iCalendar) stream. Note: needs to be updated to track changes in the specification as they occur.
* [http://lifelint.net/ Life Lint Parser] parses hCalendar and produces .ics, .rdf and debugging information and attempts to be more fully compliant to the iCal standard than previous implementations. It can be used in the same manner as X2V. Can output iCal (w optional Outlook 2002 compat), and RDF.
* [http://spanningsalesforce.com/ Spanning Salesforce] produces hCalendar-enabled RSS feeds and .ics calendars from Salesforce.com.

==== Firefox Greasemonkey Plugins ====
* [http://george.hotelling.net/90percent/ George] has built a [http://george.hotelling.net/90percent/geekery/greasemonkey_and_microformats.php Greasemonkey user script that detects hCalendar events and allows users to easily add them to their calendar application(s)].
* [http://inside.glnetworks.de/ Martin Rehfeld] has updated the work of [http://blogmatrix.blogmatrix.com/ David Janes] and produced a [[Greasemonkey]] [http://inside.glnetworks.de/2006/06/05/microformats-have-arrived-in-firefox-15-greasemonkey-06/ script] that finds many microformat elements, including hCalendar events, and [http://blog.davidjanes.com/mtarchives/2005_08.html#003379 provides a popup menu of actions]. The hCalendar to vCalendar conversion is done internally within the script. ''This will work with FireFox 1.5+/GreaseMonkey 0.6.4+ now.''

==== Aggregators ====
* [http://placenamehere.com/mf/nnwextract/ Extract Microformats] is a script for NetNewsWire that supports extracting hCard and hCalendar data in blog posts (via technorati service). Written by [[User:ChrisCasciano|Chris Casciano]]
* [http://kula.jp/software/endo/screenshots/ Endo], an OS X aggregator, supports discovering hCal and adding those events to iCal. Look at the last screenshot at the bottom of the page.

=== Browsing ===
Implementations that detect, display and otherwise highlight hCalendar events in pages.

* In [http://www.xfytec.com/community/ xfy Community], there are some hCalendar implementations. "hCalendar via RSS" parses an RSS feed, retrieves XHTML documents linked from that feed, and syndicates hCalendars into a calendar view.
* [http://web.mit.edu/glasser/www/JSCalendar/ JSCalendar] parses hCalendar and produces a displayable HTML table/CSS-based calendar.

==== Firefox extension ====
[http://blog.codeeg.com/tails-firefox-extension/ Tails is a Firefox Extension] that will display the presence of microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]) on a webpage.

==== Flock extension ====
[http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - port of Tails extension for Flock 0.5.12 that looks for hCards, hCalendar, xFolk and hReview and tosses them into a handy topbar

=== Libraries ===
Open source libraries of hCalendar parsers and other related code for building hCalendar implementations.
; Javascript : [http://virtuelvis.com/archives/2005/11/learn-to-love-microformats simple hCalendar parser] by [http://virtuelvis.com/ Arve Bersvendsen]
; PHP : [http://randomchaos.com/microformats/base/ Microformat Base] is an open-source PHP microformat aggregation crawler, currently recognizing hreview, hcalendar, and hcard.
; Ruby : [http://opensource.reevoo.com/2006/03/08/release-uformats-12/ uformats] is a ruby library that can parse [[hCalendar]], [[hCard]], [[hReview]] and [[rel-tag]]
; XSLT :
* X2V is available as an XSLT library
* [http://dev.w3.org/cvsweb/2001/palmagent/ palmagent] by [[User:DanC]] includes toICal.xsl and test materials; it works much like xhtml2vcal.xsl in X2V. See also: [http://www.w3.org/2002/12/cal/ RDF Calendar workspace] with icalendar test materials.

=== Potential implementations ===

These are open source projects that could be potentially enhanced to support hCalendar.

* [http://www.k5n.us/webcalendar.php?topic=About WebCalendar]
* [http://phpicalendar.net/documentation/index.php?title=Main_Page PHP iCalendar]
* [http://www.vcalendar.org VCalendar]
* Investigation: [http://wiki.mozilla.org/Calendar_Talk:Lightning#hCalendar_publish_and_subscribe_support Mozilla Calendar / Lightning / Sunbird hCalendar support discussion]

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[hcard|hCard]]
* [http://www.ietf.org/rfc/rfc2445.txt iCalendar RFC2445]

=== Informative References ===
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://tantek.com/log/2004/09.html#hcalendar hCalendar term introduced and defined on the Web, 20040930]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars FOO Camp 2004 HTML For Calendars presentation, 20040911]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 20040910]
* [http://www.ietf.org/internet-drafts/draft-royer-ical-basic-04.txt iCal-Basic draft 04]
* Contributed from http://developers.technorati.com/wiki/hCalendar
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]

==== Related ====
* [[icalendar-implementations|iCalendar implementations]]
* [[hcalendar-tests]]
* [http://lists.osafoundation.org/pipermail/ietf-calsify/ IETF-calsify archives]
* [http://www.livejournal.com/users/jwz/444651.html jwz - Hula] (required reading)
* [http://www.jwz.org/doc/groupware.html Groupware Bad by Jamie Zawinski] crystalizes the reason for hCalendar ('''emphasis''' added):
<blockquote>"Right now people can do that by publishing .ics files, but it's not trivial to do so, and it's work on the part of other people to look at them. '''If it's not HTML hanging off our friend's home page that can be viewed in any browser on a public terminal in a library, the bar to entry is too high and it's useless.'''"</blockquote>

* [http://muddybranch.thejkgroup.com/ Jason Klemow's blog]
* [http://www.softwarestudio.org/iCal/2445Issues.html RFC2445 Issues List]
* [http://ietf.webdav.org/calsify/ CALSIFY WG Links And Resources]

=== Similar Work ===
* [[XOXO]]

== Discussions ==

This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hCalendar:

* [[hcalendar-brainstorming]]

* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].
** [http://weblog.infoworld.com/udell/2006/01/11.html#a1368 Moving forward with microformats] by [http://weblog.infoworld.com/udell Jon Udell] provides an hCalendar example and some discussion.

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

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

hcard

2006-07-14T03:56:04Z

ChrisCasciano: /* Implementations */

<h1>hCard</h1>

hCard is a simple, open, distributed contact information format for people, companies, and organizations, which is suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. hCard is a 1:1 representation of the vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) in XHTML, one of several open [[microformats|microformat]] standards.

Want to get started with writing an [[hcard|hCard]]? Use the [http://microformats.org/code/hcard/creator hCard creator] to write up some contact information and publish it, or follow the [[hcard-authoring|hCard authoring tips]] to add hCard markup to your current contact page.

__TOC__

== Specification ==

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

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

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

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

=== Inspiration and Acknowledgments ===
Thanks to: my good friend [http://vadim.com/ Vadim] who introduced me to vCard ''many'' years ago, and if I'd only paid more attention then, perhaps I could have helped a lot of people avoid wasting a lot of time reinventing various standards wheels.

== Introduction ==
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]), has been broadly interoperably implemented (e.g. Apple's "Address Book" application built into MacOSX).

In addition, many bloggers identify themselves by name and discuss their friends and family. With just a tad bit of structure, bloggers can discuss people in their blog(s) in such a way that spiders and other aggregators can retrieve this information, automatically convert them to vCards, and use them in any vCard application or service.

This specification introduces the '''hCard''' format, which is a 1:1 representation of the aforementioned vCard standard, in semantic XHTML. Bloggers can both embed vCards directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCard enables applications to retrieve information about such vCards directly from web pages without having to reference a separate file.

Use the [http://microformats.org/code/hcard/creator hCard creator], copy the HTML code it generates to your blog or website to publish your contact info.

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

== Format ==
=== In General ===
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) forms the basis of hCard.

The basic format of hCard is to use vCard object/property names in lower-case for class names, and to map the nesting of vCard objects directly into nested XHTML elements.

=== More Semantic Equivalents ===
However, for some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:
* <code>URL</code> in vCard becomes <code><a class="url" href="...">...</a></code> inside the element with <code>class="vcard"</code> in hCard.
* Similarly, <code>EMAIL</code> in vCard becomes <code><nowiki><a class="email" href="mailto:...">...</a></nowiki></code>
* <code>PHOTO</code> in vCard becomes <code><img class="photo" src="..." alt="Photo of ..." /></code> or <code><object class="photo" data="..." type="...">Photo of ...</object></code>
* <code>UID</code> in vCard simply becomes another semantic applied to a specific URL (or EMAIL) for an hCard.

=== Singular vs. Plural Properties ===

For properties which are singular (e.g. "N" and "FN"), the first descendant element with that class should take effect, any others being ignored.

For properties which can be plural (e.g. "TEL"), each class instance should create a instance of that property. Plural properties with subtypes (e.g. TEL with WORK, HOME, CELL) can be optimized to share a common element for the property itself, with each instance of subtype being an appropriately classed descendant of the property element.

Singular properties: fn, n, bday, tz, geo, sort-string, uid, class. All other properties are plural. This list has been derived by analyzing the semantics of the individual properties in vCard RFC2426 and determining logically that they MUST be singular per their semantics. See [[hcard-singular-properties]] for explanations.

==== Plural Properties Singularized ====

Since plural property names become their singular equivalents, even if the original plural property permitted only a single value with multiple components, those multiple components are represented each with their own singularly named property and the the property is effectively multivalued and subject to the above treatment of multivalued properties.

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

If an <code><a></code> element is used for one or more properties, it must be treated as follows:
# For the "PHOTO" property and any other property that takes a URL as its value, the <code>href="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

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

If an <code><object></code> element is used for one or more properties, it must be treated as follows:
# For the "PHOTO" property and any other property that takes a URL as its value, the <code>data="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

=== Value excerpting ===

Sometimes only part of an element which is the equivalent for a property should be used for the value of the property. This typically occurs when a property has a subtype, like TEL. For this purpose, the special class name "<code>value</code>" is introduced to excerpt out the subset of the element that is the value of the property. E.g. here is an hCard fragment for marking up a home phone number:

<pre><nowiki>
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>

This hCard fragment could be displayed as:

home: +1.415.555.1212

=== Property Exceptions ===

vCard has several properties which either do not make sense on, or are already implied within the context of a web page. This section explains what to (not) do with them.

# '''NAME''', '''PROFILE''', '''SOURCE''', '''PRODID''', '''VERSION''' properties as defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of RFC 2426. Content publishers MUST NOT use these properties in their hCards, and as such, hCard consumers/parsers MUST IGNORE these properties if they are found within an hCard. Instead. hCard to vCard converters SHOULD use the title of the page where the hCard is found (e.g. the <code><title></code> element in (X)HTML documents) to construct the NAME property, MAY output a PROFILE value of "<code>VCARD</code>" per RFC 2426, SHOULD use the URL of the page where the hCard is found to construct the SOURCE property (e.g. perhaps as a parameter to a URL/service that converts hCards to vCards), for an output vCard stream (e.g. a .vcf file). Only services/applications that output actual vCards should write the PRODID property, with the product identifier for said service/application. Similarly only such services/applications should write the VERSION property, with the value "3.0" (without quotes) per RFC2426 Section 3.6.9.

=== Organization Contact Info ===

If the "FN" and "ORG" properties have the exact same value (typically because they are set on the same element, e.g. class="fn org"), then the hCard represents contact information for a company or organization and should be treated as such. In this case the author MUST also NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "". Thus parsers should handle the missing "N" property in this case by implying empty values for all the "N" sub-properties.

=== Implied "n" Optimization ===

Although vCard requires that the "N" property be present, the authors of the vCard specification (RFC 2426) themselves do not include "N" properties in their vCards near the end of the spec (p.38). This apparent contradiction can be resolved by simply allowing the "FN" property to imply "N" property values in typical cases provided in the spec. We do so explicitly in hCard.

If "FN" and "ORG" are not the same (see previous section), and the value of the "FN" property is exactly two words (separated by whitespace), and there is no explicit "N" property, then the "N" property is inferred from the "FN" property. For "FN"s with either one word see below, and for three or more, the author MUST explicitly markup the "N", except for the organization contact info case, [http://microformats.org/wiki/hcard#Organization_Contact_Info see above] for that.

# The content of "FN" is broken into two "words" separated by whitespace.
# The ''first'' word of the "FN" is interpreted as the "given-name" for the "N" property.
# The ''second/last'' word of the "FN" is interpreted as the "family-name" for the "N" property.
# Exception: If the first word ends in a "," comma OR if the second word is a single character (optionally followed by a period "."), then the first word (minus the comma at the end if any) is interpreted as the "family-name" and the second word is interpreted as the "given-name".

This allows simplification in the typical case of people stating:
* given-name (space) family-name
* family-name (comma) given-name
* family-name (comma) given-name-first-initial
* family-name (space) given-name-first-initial (optional period)

=== Implied "nickname" Optimization ===

Due to the prevalence of the use of nicknames/handles/usernames on the Web in actual content published on the Web (e.g. authors of [[hReview|reviews]]), hCard also has an implied "nickname" optimization to handle this.

Similar to the implied "n" optimization, if "FN" and "ORG" are not the same, and the value of the "FN" property is exactly one word, and there is no explicit "N" property, then:

# The content of the "FN" is treated as a "nickname" property value.
# Parsers should handle the missing "N" property by implying empty values for all the "N" sub-properties.

Note: the hCard may have additional explicit "nickname" property values in addition to the implied nickname.

=== Implied "organization-name" Optimization ===

The "ORG" property has two subproperties, organization-name and organization-unit. Very often authors only publish the organization-name. Thus if an "ORG" property has no "organization-name" inside it, then its entire contents MUST be treated as the "organization-name".

=== Tags as Categories ===

Categories in hCard can optionally be represented by tags with rel-tag. When a category property is a rel-tag, the tag (as defined by rel-tag) is used for that category.

=== Root Class Name ===

The root class name for an hCard is "vcard".

=== Property List ===

This is the list of properties (and subproperties, in parentheses, like this) in hCard, taken from vCard:

* fn, n (family-name, given-name, additional-name, honorific-prefix, honorific-suffix), nickname, sort-string
* url, email (type, value), tel (type, value)
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
* geo (latitude, longitude), tz
* photo, logo, sound, bday
* title, role, org (organization-name, organization-unit)
* category, note
* class, key, mailer, uid, rev
==== type subproperty values ====

The 'type' subproperty in particular takes different values depending on which property it is a subproperty of. These 'type' subproperty values are case-INSENSITIVE, meaning "Home" is the same as "home", as well as multivalued, e.g. a tel can be home and preferred:
<pre><nowiki>
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>

The following lists are ''informative''. See RFC2426 sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values. They are repeated here for convenience. Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, car, isdn, pcs
* email type: INTERNET, x400, pref, "other IANA registered address types"

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

== Examples ==

This section is informative.

=== Sample vCard ===

Here is a sample vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
ORG:Technorati
END:VCARD
</nowiki></pre>

and an equivalent in hCard with various elements optimized appropriately. See [[hcard-example1-steps| hCard Example 1]] for the derivation.

<pre><nowiki>
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
<div class="org">Technorati</div>
</div>
</nowiki></pre>

This hCard might be displayed as:

[http://tantek.com/ Tantek Çelik]<br />
Technorati

Note: The version information is unnecessary in hCard markup directly since the version will be defined by the profile of hCard that is used/referred to in the 'profile' attribute of the <head> element.

=== More Examples ===

See [[hcard-examples]] for more examples, including all examples from vCard RFC 2426 converted into hCard.

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

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

=== New Examples ===
Please add new examples to this section.
* [http://local.yahoo.com Yahoo Local] now supports hCards for business and places in the search results
* [http://learningtheworld.eu/imprint/ Learning the World] has hcard information on the imprint, alas we didn't succeed to mark-up the work phone and fax numbers properly.
* The [http://www.fuckparade.org F’parade] website uses hcard, though I didn't find a type to distinguish mobile and landline phone numbers.
* [http://www.miranet.nl/contact.htm Miranet Webdesign] have added a hcard to their [http://www.miranet.nl/contact.htm 'contact' page]
* [http://weblog.200ok.com.au/ Ben Buchanan] has added a vCard to the [http://weblog.200ok.com.au/about/ 'About' page on The 200ok Weblog]
* [http://www.radiantcore.com Radiant Core] has their contact information [http://www.radiantcore.com/contact/ available in hCard].
* [http://www.mikerumble.co.uk/ Mike Rumble] has [http://www.mikerumble.co.uk/contact.html uploaded his hCard].
* [http://www.saumag.edu/ Southern Arkansas University] has its contact footer encoded as hCard
* [http://main.uab.edu/ University of Alabama at Birmingham] has its contact footer encoded as hCard
* [http://www.capital.edu Capital University] has contact footer and bloggers' names encoded as hCard. Also, all page-specific contact information is encoded as hCards (see [http://www.capital.edu/Internet/Default.aspx?pid=67 Admissions] page for an example)
* [http://main.uab.edu/shrp/ UAB School of Health Professions] uses hCard in its contact footer
* [http://green.carisenda.com/ Stephen Stewart] has his hCard on the front page of his weblog ('You are here' section)
* [http://www.fberriman.com/ Frances Berriman] has a hidden vCard in the footers of her website.
* [http://www.candlescience.com/ CandleScience Candle Supply] added a hidden hcard sitewide.
* [http://www.direction.es/ Direction] uses hCard for contact information.
* [http://audiobank.tryphon.org AudioBank] uses hCard to display member informations.
* [http://www.vivabit.com/atmedia2006/speakers/ @media speakers] are marked up with hCard (photos depend on BASE tag support which makes this a good test case)
* [http://www.dougransom.com Doug Ransom] uses hCard for his financial advisory practice.
* [http://rubyandrails.org/usergroups/newcastle/members.html ncl.rb] uses hCard for contact information.
* [http://www.snowinteractive.com/ Snow Interactive] uses hCard for contact information.
* [http://flickr.com Flickr] now supports [[hcard|hCard]] and [http://gmpg.org/xfn XFN] on profile pages. See [http://flickr.com/photos/factoryjoe/113866484/ screenshot of Flickr UI in Flock browser using Flocktails extension - March 17th 2006].
* [http://www.ndiyo.org/contact Contact information for the Ndiyo project]
* [http://www.pixelenvy.co.uk/ Pixel Envy] uses hCard for contact information on every page
* [http://stilbuero.de/contact/ Klaus Hartl] uses hCard in the sidebar for contact information (maybe easier to parse through delivering xhtml as xml).
* [http://charlvn.virafrikaans.com/contact Charl van Niekerk's hCard]
* [http://billy-girlardo.com/WP/ BillyBLOGirlardo] uses hCard for contact information.
* [http://www.hicksdesign.co.uk/ Hicksdesign] uses hCard for contact information.
* http://www.gr0w.com/articles/press/growsearch_launched_press_release/ - hCard in a press release for the press contact info
* http://www.redmonk.com/cote/archives/2006/03/testing_out_mic.html - hCard with explanation
* [http://andy.ciordia.info/ it's my island], personal blog, hcard on the ''[http://andy.ciordia.info/pages/about_me About the Writer]'' page. [[User:Ciordia9|Andy Ciordia]]
* [http://www.windowonwoking.org.uk/ Window on Woking], a local community site in the UK, uses hCard in the homepage of each member organisation and local Councillor.
* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site -- by [[User:ChrisCasciano|Chris Casciano]]
* [http://www.30boxes.com/ 30 Boxes],a social calendar application and digital lifestyle aggregator, automatically creates an hcard for you with your account. It is found under Settings > Syndication.
* [http://www.nearwhere.com/ Nearwhere.com] allow you to put an hcard on an interactive map.
* [http://www.brentozar.com/ Brent Ozar] added a [http://www.brentozar.com/contact.php contact] page hCard.
* [http://www.kerihenare.com/ Keri Henare] has rewritten his [http://www.kerihenare.com/contact/ contact] page hCard. Now using <code><object></code> instead of <code><img></code> for photo. (Thanks Brian Suda for updating the vCard converter)
* [http://michaelraichelson.com/contact/ Michael Raichelson] had an hCard on his contact page before SXSW, but never thought to add it here until Tantek requested it.
* [http://www.commoner.com/~lsimon/lindsey_simon_hcard.html Lindsey Simon] has added an hCard to his website as per Tantek's SXSW request for folks to try it
* [http://www.davidgagne.net/ David Gagne] has an hCard in his sidebar.
* [http://www.churchzip.com/map/ Churchzip.com/map] and [http://www.skiwhere.com/map/ Skiwhere.com/map], provide churches, hotels, and ski resorts on the same maps. Locations are formatted as hcards.
* All [http://www.iqdir.com/ IQ Directory Solutions] Yellow Pages web portals use [[hcard|hCard]] markup on listings. For example [http://www.yellowpages-cambodia.com/ Cambodia Yellow Pages] and [http://www.superpages.com.my/ Malaysia Super Pages]
* Ning's cloneable Group app uses fuzzy matching to map custom fields to [[hcard|hCard]] markup on its [http://group.ning.com/index.php?controller=person&action=view&content=JonathanAquino profile] pages.
* [http://claimid.com/factoryjoe Chris Messina' ClaimID hCard]
* [http://factoryjoe.com/blog/hcard Chris Messina' hCard]
* [http://flock.com/about Flock About]
* [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]).
* [http://www.gr0w.com/articles/press/growsearch_launched_press_release/ GrowSearch Launched (Press Release)] uses an hCard to provide Press Contact Point.
* The [http://www.arborday.org/ National Arbor Day Foundation] has started using hCards for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].
* [http://www.multipack.co.uk The Multipack] has numerous hCards, especially on the [http://www.multipack.co.uk/members/ members page], as well as the next meeting information.
* [http://deadringrancor.livejournal.com/ Justin McDowell] used an hCard when [http://deadringrancor.livejournal.com/221332.html referring to a person in his blog post]
* [http://davecardwell.co.uk/cv/ Dave Cardwell] has included his hCard in his Curriculum Vitae.
* [http://blog.usweb.com/ Shaun Shull] has written a great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect SEO], and has included his [[hcard|hCard]] as one of the examples.
* [http://www.thefutureoftheweb.com/ Jesse Skinner] has written a simple [http://www.thefutureoftheweb.com/blog/2006/1/hcard tutorial with examples]
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the venue, contacts, and program committee members all with hCard.
* [http://www.avf-nexus.co.uk AVF-Nexus] have a hCard on their [http://www.avf-nexus.co.uk/contact/ contact page] - (by [http://creation.uk.com Creation"])
* [http://www.thefantasticos.com/andrew/ Andrew White] posted [http://www.thefantasticos.com/andrew/index.php/my-hcard/ his hCard] and [http://www.thefantasticos.com/andrew/index.php/62/microformats-the-should-have-been-obvious-web-dev-tool/ blogged about it].
* [http://www.2sheds.ru Oleg "2sheds" Kourapov] in his [http://www.2sheds.ru/blog/ blog] ([http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://www.2sheds.ru/blog X2V]) has turned personal profile into hCard ([http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://www.2sheds.ru/blog/hcard.html X2V]) and his blogroll - into combination XFN/hCards ([http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://www.2sheds.ru/blog/friends.html X2V])
* [http://www.approveddesign.co.uk Approved Design Consultancy] have a hCard on their [http://www.approveddesign.co.uk/about/contact/ contact page] as well as on their [http://www.approveddesign.co.uk/about/people/ people section] - (by [http://creation.uk.com Creation"])
* [http://weblog.200ok.com.au/ Ben Buchanan] and [http://www.griffith.edu.au/cgi-bin/phone_search.pl?string=colin+morris&format=search Colin Morris] have [http://weblog.200ok.com.au/2006/01/griffith-phonebook-adds-hcard-and.html implemented hCards and vCards] for the [http://www.griffith.edu.au Griffith University] [http://www.griffith.edu.au/find/content_phonebook.html online phone book]. Eg. [http://www.griffith.edu.au/cgi-bin/phone_search.pl?string=ben+buchanan&format=search Ben's vCard] and [http://www.griffith.edu.au/cgi-bin/phone_search.pl?string=colin+morris&format=search Colin's vCard]
* WWF-Australia [http://wwf.org.au/about/contactdetails/ contact details page]
* [http://rasterweb.net/raster/ Pete Prodoehl] used the hCard format on his [http://rasterweb.net/raster/contact.html Contact page]
* [http://alexander-mette.de amette] uses the hCard format in a module of his TikiWiki powered blog
* [http://staff.washington.edu/oren/weblog2/ Oren Sreebny] has an hcard on his blog main index template
* [http://www.cs.brandeis.edu/~zippy/ Patrick Tufts] has an hCard on his homepage.
* [http://ascii20.blogspot.com/ Mathias Kolehmainen and Jamie Taylor] have hCards on their weblog.
* [http://www.hoppsan.org/jamesb/blogger/ Barnaby James] has a hCard on his weblog.
* [http://esa-education.com/schools/map ESA Education] Uses hCards for their 100+ schools and each of the individual school sites.
* [http://www.thereisnocat.com/#vcard Ralph Brandi] has added an hCard to the sidebar of his weblog as a result of Tantek Çelik's portion of the Microformats presentation at SXSW 2006.
* [http://www.pierce.ctc.edu/ephone/ Pierce College] -- community college directory uses hCard on all individual directory entries.
* [http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/ the Institutional Web Management Workshop 2006] have marked up all their [http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/committee/ speakers with hCard].
* http://wikitravel.org/en/Singapore/Sentosa. Wikitravel is experimenting with hcard on its travel guides. This guide uses hcard for all its business listings. More info on http://wikitravel.org/en/Wikitravel_talk:Listings.
* [http://www.musik-erber.de/ Musik-Erber] uses to present contact information at the sidebar
* [http://cdevroe.com/about/#contact Colin D. Devroe] uses hCard to display his contact information on his about page
* The ECS (Scool of Electronics and Computer Science at the University of Southampton) [http://www.ecs.soton.ac.uk/people People Pages] use vCard. Contact cjg@ecs.soton.ac.uk if there's any bugs.
* [http://www.southwestern.edu/~ramseyp Pat Ramsey] has his contact information on his blog marked up with hCard. Contact [mailto:ramsey.pat@gmail.com ramsey.pat@gmail.com] if there are any bugs there.
* [http://www.meryl.net/ Meryl K. Evans] has a hidden hCard on her homepage.

=== Examples ===
* [http://thoughtport.blogspot.com/ Aiden Kenny] hasn't published his hCard yet, but he has [http://thoughtport.blogspot.com/2005/07/elemental-particles-of-web.html published his hCard icon]: http://photos1.blogger.com/blogger/4224/444/320/AK-Hcard-icon.gif
* [http://thedredge.org Andy Hume] uses hCards to mark-up the names and URLs of commentors on his blog, e.g. his [http://thedredge.org/2005/06/using-hcards-in-your-blog/ blog post on "Using hCards in your blog"].
* [http://www.bidclix.com/ BidClix]'s [http://www.bidclix.com/AboutContact.html Contact BidClix] page has it's ''contact info'' marked up with an hCard.
* [http://suda.co.uk/ Brian Suda] has managed to embed a photo in [http://suda.co.uk/contact/ his hCard] through the [http://www.ietf.org/rfc/rfc2397.txt data uri scheme] by converting the image to BASE64 code. View the Source to see how this is accomplished. [http://suda.co.uk/projects/X2V/get-vcard.php?uri=http%3A//suda.co.uk/contact/ The X2V link] will extract the image and encode it for a vCard which will be displayed in some address book applications.
* [http://cinematreasures.org Cinema Treasures] uses hCard to markup venue information for 10,000+ movie theaters.
* [http://www.w3.org/People/Connolly/events/ Dan Connolly's index of events and talks] has hCards for many of the people he has met at those events. In Mar 2006, he moved a bunch of hotel contact info from his PDA to this page; it's now up to 32 hCards.
* [http://doncrowley.blogspot.com/ Don Crowley] has published [http://www.crowley.nl/hcard.html his hCard] as well as a nifty hCard button: http://www.crowley.nl/images/hcard.png
* [http://loadaveragezero.com/hnav/contact.php Douglas W. Clifton] added all types of contact information
* [http://eventful.com Eventful] publishes all of its venue information pages with embedded hCards.
* [http://www.iowamilitaryveteransband.com/members/ Iowa Military Veterans Band Contacts] - 95 hCards [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ marked up by Scott Reynen]
* [http://JackWolfgang.blogspot.com Jack L. Wolfgang II] has [http://jack.randomata.com/resume/ converted the addresses in his resume to hCards].
* [http://www.efas.fupl.asso.fr/efas/_Mathieu-Drouet_.html Mathieu Drouet] and [http://www.efas.fupl.asso.fr/efas/_Annie-Leger_.html Annie Leger] both have hCards
* [http://www.ndunn.com Neil Dunn] has published his rather [http://www.ndunn.com/2005/10/7/hCard good looking hCard]
* [http://www.oliverbrown.me.uk/ Oliver Brown] has published his hCard.
* [http://www.paradigmproductions.org/contact/ Paradigm Productions] published a vcard as a ul (marked up by [http://www.linkingarts.com/ Peter Jacobson])
* [http://www.splintered.co.uk/ Patrick H. Lauke] has marked up [http://www.splintered.co.uk/about/ his contact info with hCard].
* [http://blah Paul Schreiber has published his hCard on [http://paulschreiber.com/about/?contact his about page].
* [http://paulschreiber.com/blog/ Paul Schreiber]'s [http://concerts.shrub.ca/ Sunnyvale House Concerts] site publishes hCards for upcoming artists, as well as an hCard for the page itself. In addition the [http://concerts.shrub.ca/shows Past Shows] page contains hCards for all past artists.
* [http://www.paulmichaelsmith.com/blog/hcard.htm Paul Smith] has created an hCard page which is Human Readable, and a link to X2V passing the same hCard page to generate a vCard.
* [http://www.windley.com/archives/2005/07/hcards_trying_o.shtml Phil Windley has published] [http://phil.windley.org/hcard.html his hCard].
* [http://www.go-curiosity.com/about.htm Piercarlo Slavazza] has published an hCard.
* [http://zooibaai.nl/ Rob Mientjes] has published his hCard on [http://zooibaai.nl/about/ his about page].
* [http://rbach.priv.at/Contact Robert Bachmann] has published his hCard and [http://rbach.priv.at/Images/hcard a button].
* [http://blah Scott Reynen has published his hCard on [http://www.randomchaos.com/document.php?source=scott_reynen his profile page].
* [http://www.stackframe.com/ StackFrame, LLC] has published [http://www.stackframe.com/people/ employee] and [http://www.stackframe.com/contact/ general] contact information as hCards.
* [http://www.wolfsreign.com Steven Ametjan] has published his hCard on [http://www.wolfsreign.com/about/ his about page].
* [http://tantek.com/microformats/2005/syndicate/speakers-list.html Syndicate - Speaker List] as a set of hCards
* [http://tagcamp.org/index.cgi?ContactList TagCamp contact list]
* [http://tantek.com/log Tantek's Thoughts] includes an inline author hCard at the bottom of the page.
* [http://technorati.com/ Technorati]'s [http://www.technorati.com/about/ About page] lists their '''Media Contact'''
* [http://www.deadringerart.com/ The Brothers McDowell] have hCards at their Contact page.
* [http://twinsparc.com/ Twinsparc] put an hCard in the header and footer of all their pages.
* [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 Conference speakers page marked up with hCard]
* [http://we05.com/ Web Essentials 05] marked up all their [http://we05.com/presenters.cfm presenters with hCard].

=== Examples with some problems ===

* [http://gbraad.nl/ Gerard Braad] has published an example on his [http://gbraad.nl/site/?p=profile profile] page that is almost consistent with his original [http://gbraad.nl/files/gbraad.vcf vCard] file. Also progress is made for transforming his [http://files.gbraad.nl/foaf.rdf FoaF] file to a hCard encoded representation. (also done for my spouse:[http://spouse.gbraad.nl/site/?p=profile Yong Yuan])
** (2005-09-27) PASSED, PASSED
** WARNINGS
*** uses 'n given-name' and 'n family-name' instead of nesting the given- and family- names inside the 'n'
*** has one 'tel' value with a bunch of values stuffed in
*** probably more problems --[[User:RyanKing|RyanKing]] 17:19, 5 Jan 2006 (PST)
* [http://kinrowan.net/ Cori Schlegel] [http://kinrowan.net/blog/wp/archives/2005/07/08/a-problem-with-the-structured-blogging-plug-in-for-wordpress/ discusses how he has updated] [http://kinrowan.net/blog/contact his contact page with hCard]
** INVALID - using 'prefix' instead of 'honorific-prefix' and type's in classnames (in both adr and tel) and has two photo's (the second could be 'logo') --[[User:RyanKing|RyanKing]] 15:15, 5 Jan 2006 (PST)
* The good ship [http://styrheim.com/test/leonid.html Leonid Miloslavskiy] spotted in the North Atlantic
** INVALID --[[User:RyanKing|RyanKing]] 00:50, 27 Oct 2005 (PDT)
*** class="family" should probably be family-name
*** the "n" property is missing and the "n" optimization can't be applied
*** the first geo propery is empty, the second one is invalid (ie, it doesn't contain lat/long)
* [http://landsbank.fo/#hCard Landsbanki Føroya]
** INVALID - using embedded rdf/xml invalidly
* [http://chrischerry.name/blog/contact/ Chris Cherry's contact page with his hCard]
** WARNING - uses class="cell" instead of <span class="type">cell</span>
* [http://www.bath.ac.uk/contact/ University of Bath] Person Finder results are encoded with hCards so you can easily create a vCard from any result.
** ERROR - attempt to use Implied-N optimization where that's not possible. --[[User:RyanKing|RyanKing]] 14:29, 5 Jan 2006 (PST)
** Error appears for external users only. Won't be fixed any time soon. -- [[User:PhilWilson|PhilWilson]] 00:03, 28 Jan 2006 (GMT)
* [http://richi.co.uk/blog/2005/12/structured-blogging.html Richi Jennings] has put up his attempt
** INVALID, missing FN --[[User:RyanKing|RyanKing]] 12:47, 5 Jan 2006 (PST)
* [http://www.shiftingpixel.com/about/ shifting pixel photoblog] has published an hCard.
** "organization_name" should be "organization-name" (s/_/-/), otherwise good --[[User:RyanKing|RyanKing]] 14:01, 5 Jan 2006 (PST)
* [http://www.yellowpencil.com/contact/ Yellow Pencil] Using microformats to present company contact information
** First hcard has empty "fn" and no "n". "fn" should be with "org" -- [[User: ScottReynen |ScottReynen]] 21:29, 19 Jun 2006 (CST)

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

The following implementations have been developed which either generate or parse hCards. If you have an hCard 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://placenamehere.com/mf/nnwextract/ Extract Microformats] is a script for NetNewsWire that supports extracting hCard and hCalendar data in blog posts (via technorati service). Written by [[User:ChrisCasciano|Chris Casciano]]
* [http://allinthehead.com/hkit/ hKit] is an open source PHP 5 parsing library with support for hCard.
* [http://kitchen.technorati.com/search Technorati Microformats Search] indexes [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] as [http://tantek.com/log/2006/05.html#d31t1802 announced by Tantek].
** list of pages with indexing Issues so they can be looked into as to why data is not being extracted
** suda.co.uk/contact
** multipack.co.uk

* [http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver Extension suite] from the [http://webstandards.org/ Web Standards Project] enables the authoring of hCards from within Dreamweaver 8.
* [http://scooch.gr0w.com/ Scooch] is a slide show and presentation creator that generates a [[hCard]] for individual slide show authors and comment authors with a CSS button to parse and download via [http://suda.co.uk/projects/X2V/ X2V]. Also uses [[hReview]] for slide ratings and [[rel-tag]] for categories.
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - port of Tails extension for Flock 0.5.12 that looks for hCards, hCalendar, xFolk and hReview and tosses them into a handy topbar
*[http://opensource.reevoo.com/2006/03/08/release-uformats-12/ uformats] is a ruby library that can parse [[hCalendar]], [[hCard]], [[hReview]] and [[rel-tag]]
* [http://blog.codeeg.com/tails-firefox-extension/ Tails] is a Firefox Extension that will display the presence and details of microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]) on a webpage. [https://addons.mozilla.org/firefox/2240/ Tails Export] is an extended version.
* [http://www.stripytshirt.co.uk/features/firefox/smartzilla Smartzilla is a Firefox Extension] that finds hCards on web pages and lets you add them to your addressbook.
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding hCard and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* There is [http://flickr.com/photos/factoryjoe/68755089/ evidence of built-in hCard support in the Konqueror browser]. Specifically, Konqueror 3.5, in KDE 3.5 (kubuntu Breezy w/ update).
* There is [http://tagcamp.org/index.cgi?ContactList evidence of a kwiki plugin for hCards]. Update: the [http://svn.kwiki.org/cwest/Kwiki-hCard/ hCard kwiki plugin svn repository]. See the [http://microwiki.caseywest.com/index.cgi?hCard documentation of the hCard kwiki plugin].
* [http://suda.co.uk/projects/X2V/ X2V] is a bookmarklet that parses hCard and produces a .vcf (vCard) stream. Note: needs to be updated as the spec is refined
* [http://www.stripytshirt.co.uk Duncan Walker] has built [http://www.stripytshirt.co.uk/features/firefox/smartzilla a Firefox extension] that gets hCard data from a webpage, uses Brian Suda's XSL (locally) to transform it to vcard format and opens the resulting .vcf file.
* [http://george.hotelling.net/90percent/ George] has written a [http://george.hotelling.net/90percent/geekery/greasemonkey_and_microformats.php Greasemonkey user script] that detects hCards and allows users to easily add them to their address book application. Relies on the X2V web service to do the conversion.
* [http://inside.glnetworks.de/ Martin Rehfeld] has updated the work of [http://blogmatrix.blogmatrix.com/ David Janes] and produced a [[Greasemonkey]] [http://inside.glnetworks.de/2006/06/05/microformats-have-arrived-in-firefox-15-greasemonkey-06/ script] that finds many microformat elements, including hCards, and [http://blog.davidjanes.com/mtarchives/2005_08.html#003379 provides a popup menu of actions]. The hCard to vCard conversion is done internally within the script. ''This will work with FireFox 1.5+/GreaseMonkey 0.6.4+ now.''
* [http://diveintomark.org/ Mark Pilgrim] has also written an [http://diveintomark.org/projects/greasemonkey/hcard/ hCard parser Greasemonkey user script]. It is self-contained and does not rely on the X2V web service.
* [http://www.oliverbrown.me.uk/2005/09/03/a-working-microformats-extension-to-simplexml/ Oliver Brown] has written an "extension" to [http://www.php.net/simplexml SimpleXML] that gives simple access to hCard information in PHP 5.
* [http://thedredge.org/ Andrew D. Hume] has built a system (Wordpress plugin?) for [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hcards in your blog] to represent people leaving comments on blog posts.
* The [http://tantek.com/microformats/hcard-creator.html hCard creator] is a very simple, yet illustrative, open source user interface / form / script which creates an hCard in real-time as you type in a set of contact information.
* [http://greenbytes.de/tech/webdav/rfc2629.xslt rfc2629.xslt] now attempts to generate hCard information ([http://ietf.org/rfc/rfc2629 RFC2629] is an XML format for authoring RFCs and Internet Drafts, see [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html example document])
* [http://tantek.com/microformats/buddylist2hcards.html iChat buddy list to hCards] - Open source AppleScript to automatically convert one's buddy list in the MacOSX iChat AIM client into a valid XHTML 1.0 Strict list of hCards.
* [http://dev.w3.org/cvsweb/2001/palmagent/ palmagent] is a collection of palmpilot and sidekick tools. It includes X2V derivatives xhtml2hcard.xsl and toICal.xsl plus some [http://dev.w3.org/cvsweb/2001/palmagent/hcardTest.html hcardTest] materials
* [http://www.openpsa.org/ OpenPsa 2.x] CRM application uses hCard for all person listings. The widget is [http://www.midgard-project.org/midcom-permalink-922834501b71daad856f35ec593c7a6d reusable across Midgard CMS]
* [http://www.metonymie.com Emiliano Martínez Luque] has written an experimental [http://www.metonymie.com/hCard_extract/app.html hCard finder and structured search application] that finds hCards within a given set of URLs and returns the ones that match the specified search criteria.
* [http://randomchaos.com/microformats/base/ Microformat Base] is an open-source PHP microformat aggregation crawler, currently recognizing hreview, hcalendar, and hcard.

== Additional Applications ==
This section is '''informative'''.

There are numerous potential additional uses and applications for hCards on the Web. The following are merely a few thoughts and possibilities that folks have come up with:

* As an open standard/format for [http://www.gravatar.com/ Gravatars].
* Marking up individual authors of blog posts on a group blog
* Marking up people's names and URLs in a blogroll
* Any reference to people in blog posts (e.g. when citing them, or referencing them, or describing them, by name).
* ...

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]

=== Informative References ===
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 20040930]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 20040910]
* Contributed from http://developers.technorati.com/wiki/hCard.
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]

==== Specifications That Use hCard ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== Similar Work ====
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== Related Pages ==
* [[hcard-faq|hCard FAQ]] - If you have any questions about hCard, check here, and if you don't find answers, add your questions!
* [[hcard-parsing|hCard parsing]] - Normatively details of how to parse hCards.
* [[hcard-issues|hCard issues]] - Please add any issues with the specification to the issues page.
* [[hcard-profile|hCard profile]] - The XMDP profile for hCard

This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

* [[hcard-brainstorming|hCard Brainstorming]] - where we are keeping our brainstorms and other explorations relating to hCard
* [[hcard-tests|hCard tests]] - a wiki page with actual embedded hCards to try parsing.

== Further Reading ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon has a good intro to hCard
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://thedredge.org/ Andrew D. Hume] has written a blog post on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats] which discusses hCard
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect SEO], including his [[hcard|hCard]] as an example.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page] and the [http://technorati.com/tags/hcard hCard tag]

to-do

2006-07-06T21:53:02Z

ChrisCasciano: /* Chris Casciano */

<h1>To Do</h1>

This page is for posting [[microformats]] related shared to do items. If you want to use this page for your microformats related to-do items, create a section with your name on it. The reason we are keeping these all on the same page is to make it easier to tell when people are working on similar things, and to make it more obvious when people help out with other people's tasks. In theory this probably won't scale, but let's first see how it does in practice. :) - [http://tantek.com Tantek]

__TOC__

== Lazyweb ==

Just some nice things, feel free to do any of these.

=== for all microformats ===
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.
* write up [http://microformats.org/discuss/ mailing-list] questions and answers in the appropriate [[faq]] pages.
* validators. See the hReview section below as there has been a request for an hReview validator in particular. See [http://norman.walsh.name/2006/04/13/validatingMicroformats Norman Walsh's blog post "Validating microformats"] for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.

=== hReview ===
* [[hreview|hReview]] support in Ecto (hey Adriaan!), requested by Andy Smith
* an [[hreview|hReview]] validator.
* a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)
** both [http://komodomedia.com/blog/index.php/2005/08/24/creating-a-star-rater-using-css/ this] and [http://factorycity.net/demos/drupal/rating/default.html this] have some flaws. Ask [[User:RyanKing|Ryan King]] for an explanation.

=== hCard ===
* microformatted versions of conference pages
** Do a revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].
* vcard to hcard converter
** would be nice to have a web upload UI that would take one or more vCards from apple's address book and give them back to you as hCards
** [[User:RobertBachmann | RobertBachmann]] suggests starting points:
*** For Ruby: http://vpim.rubyforge.org/
*** For C: http://freshmeat.net/projects/libvc/
*** For Python: http://www.nongnu.org/python-pdi/
*** For PHP: http://pear.php.net/package/Contact_Vcard_Parse/
* add export support for microformats to [http://www.turingart.com/abForWeb_lan__en.htm AB to Web]
* A mash-up with google maps that will take any url with a hcard (or hcard's) and map the location(s) on a map (similar to [http://austin.adactio.com/ austin.adactio.com])

=== hCalendar/hCard/hReview editor ===
* onblur in the URL field (e.g. on hCalendar), goes out and tries to retrieve an object of same time (e.g. an hCalendar vevent) from that URL and uses it to autofill the form, same thing if the creator is loaded with that URL prefilled (e.g. due to a ?url=http://example.com/ in the URL that loads the creator).

=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvement
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]

=== Yahoo Open Source Library Patches ===

Several of these could very much be improved with a little microformats markup. Do we just make patches and submit them? Contact Nate Koechley at Yahoo (see Tantek for contact info) to follow-up.

* [http://developer.yahoo.net/yui/ Yahoo! User Interface Library]
* [http://developer.yahoo.net/ypatterns/ Yahoo! Design Patterns Library]
* [http://www.yuiblog.com Yahoo! User Interface Blog]

=== Drupal patches for microformats ===
* submit patches for Drupal code/templates for microformats improvement
* Drupal modules for microformats, specifically hReview and hCalendar

=== Adding Markup to Existing Pages (W3C track at WWW2006) ===

* DanC offers a 150 point bounty to anybody who takes [http://www.w3.org/2006/05/w3c-track the W3C track at WWW2006] and adds hCalendar markup and sends it to connolly@w3.org,www-archive@w3.org

== Tantek ==

I'm keeping a few microformats related to-do items here both for my own convenience, and for folks looking to help out with small tasks. If so, just create a new section with your name, and and maybe copy the item there, and put your name next to the item in my list. We'll figure this out as we go along. Thanks, [http://tantek.com Tantek].

=== for all microformat specs ===
* modularize any specs which are > 30K in order to avoid loss/corruption like [http://microformats.org/wiki?title=Special:Contributions&target=Evan Evan's 14 June edits] to [[hcard|hCard]], [[rel-tag]], and [[xoxo|XOXO]].
** [[hcard|hCard]] - need to create new pages for [[hcard-examples-in-the-wild]] (perhaps grouped/ sorted by individuals, organizations, and hosting sites?), [[hcard-implementations]] at a minimum to separate out that content, and leave short summaries in their existing place inline in the [[hcard|hCard]] spec.
** [[rel-tag]]
** [[xoxo]]

* sort implementations by authoring/creating/publishing, browsing/viewing, converting/importing, indexing/searching.

Hmmm... I like: '''A'''uthoring, '''B'''rowsing, '''C'''onverting, '''I'''ndexing, '''L'''ibraries (for developers), and '''P'''otential (for open source projects we want to add support to). Anybody have alternative suggestions for this vocabulary? I don't have a particularly strong preference so I'm going to go with these four until I find examples that don't fit, or someone suggests something better.

See: [http://microformats.org/wiki/hcalendar#Implementations hCalendar Implementations] for a first attempt at this. Assuming folks like that, we can go ahead with categorizing the implementations sections of other microformats specifications.

=== iterate on current microformats ===
==== [[hreview|hReview]] ====
* Write hReview 0.3 XMDP profile, and reconcile with [[hcalendar-profile]] and [[hcard-profile]]. Makes sense to have a combined profile of all three for hReview, since hReview normatively depends on hCard and hCalendar.

==== [[hcalendar|hCalendar]] ====
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need to resolve all outstanding [[hcalendar-issues]] to-do items.
* create [[hcalendar-profile]] and have folks verify it. note that it will likely need reconciliation with the [[hcard-profile]], especially since [[hcalendar|hCalendar]] normatively depends on [[hcard|hCard]]. Probably makes sense to have a combined profile which hCalendar would use.

==== [[hcard|hCard]] ====
* [[hcard-examples]]
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].
** add example of organization-name and organization-unit usage.
* Examples in the wild - need to create a new page for them!
** Group examples in the wild according to:
*** Individuals - one card per person, perhaps sort alphabetically
*** Organizations - one card per organization, alphabetical again
*** Institutions (which list more than one person), with a count estimating the # of hCards, e.g. 40k for Avon
*** Online Profiles (which host profiles for more than one person) with a count estimating the # of hCards, e.g. 3.5m for Flickr.com
*** Online Venues (which provide listings for businesses or organizations) with a count estimating the # of venues, e.g. ~10k for Upcoming.org
*** Speakers Listings (lists of speakers on conference sites) with a count estimating the # of speakers, e.g. ~300 for SXSW 2006.
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== introduction / community ===
* microformats-discuss
** introductory email sent to new subscribers needs to direct people to [[process]] and [[how-to-play]]
* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.

=== profiles ===

* update XMDP with new required features:
** ability for one profile to include/import another (rel="import" ?)
** ability to reference an XMDP via rel="profile" (similar to XHTML2 rel value by same name)
** ability/suggestion to reference an XMDP using <a href> in addition to <link>

=== microformat parsing documentation ===
* Add XPath equivalents where appropriate in [[hcard-parsing]]

=== create microformats wiki pages for ===
* *-authoring for all microformats
* *-parsing for all microformats

=== improve usability and automation on the site ===
* figure out how to get wordpress to autopost blog posts to the microformats-announce list
** ideally use the from address of the author of the blog post
** maybe photomatt knows how to do this.

=== help with microformat implementations ===
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** look for hcards and parse them
* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.
* Conference Schedule Creator
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

=== help with microformat examples in the wild ===
Go over all "common" pages (both logged out and logged in states) of the following sites which have some microformats already, and verify each page is as microformatted as it can be with high fidelity [[hcalendar|hCalendar]] and [[hcard|hCard]] etc. Document full support of each implementation's microformats on the implementations page (perhaps create a separate page for each implementation, e.g. [[flickr]], [[upcoming]], [[eventful]] etc.) Document any exceptions as needed. In no particular order:
* Flickr.com (3.5m hCards)
* Upcoming.org (100k hCalendar events, 100k hCard venues)
** home page
* Eventful.com (100k hCalendar events, 100k hCard venues)
* Yahoo! Tech (300k products with hReviews)
* JudysBook.com (???k hReviews)
* ... lots more, get from "Implementations" and "Examples in the Wild" sections of specs.

=== help with new microformat requests ===
* expense reports (really just a list of "expense" items), [http://flickr.com/photos/edyson/56774178/ requested by ED], should look at UBL as a pre-existing format
* photo-notes microformat
** clean up Subethaedit notes from working session with Greg Elin, Ryan King, Kevin Marks, Suw Charman and email to folks and figure out next steps
** iterate on [[photo-note-examples]] and start [[photo-note-formats]] and [[photo-note-brainstorming]].

* Can we make "microformat" and "microformats" into [http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ Community Marks]?

==Ryan==
=== hCalendar/hCard/hReview creator improvements ===
* get all creators working in IE/Win, IE/Mac, Safari/OSX.3

=== *-authoring microformats wiki pages ===
* Add some tips to [[hcard-authoring]] - a tutorial on creating an hCard for your site, blog (common platforms), etc.
* [[hcalendar-authoring]] - a tutorial on how to blog events so your friends can subscribe to them
* [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.

=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15) -> verify http://svn.lifelint.com/hcalendar_tests/calendar-todo-multiple-attendees-and-alarm.xml

=== rel-payment ===
* update rel-payment to reference the IANA registry [http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02055.html]

=== hcalendar ===
* make sure we explicitly disallow 'vjournal'

== Dimitri Glazkov ==

* Figure out REST/Microformats thing
* Work on result set idea
* Implement h-creators using Web Forms 2.0

== Chris Messina ==

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item (take a look at [[media-info-examples]])
* Work on microformats tutorial for designers

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts" (see [http://factoryjoe.com/blog/2006/03/20/flocktails-for-flock/ Flocktails])
* Better hCal support -- support many views of same hCal data on one page using XSLT
* We need something that a designer/web programmer can come to and leave w/ 2 examples of each microformat that they can apply right away... a "microformats styleguide for designers", if you will.
* invoicing microformat
* better microformats wiki theme

== Robert Bachmann ==

=== hCard Creator ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** aim / instant messaging contact info, using the techniques documented in [[hcard-examples#New_Types_of_Contact_Info|hCard Examples: New Types of Contact Info]]
*** consider a popup menu for the IM service (AIM|Yahoo|...), and a field next to it for the IM id.

=== hAtom2Atom ===

Some ideas for features which could be implemented :

(If you are interested in one of this features, add "<i>+1 Your Name</i>")

<ul>
<li>
Join all hfeed's inside a page (or a fragment thereof) into one feed using [http://greenbytes.de/tech/webdav/rfc4287.html#element.source atom:source] semantics.
</li>
<li>
Extraction of <code>atom:content</code>, <code>atom:summary</code> and <code>atom:title</code>:
* <code>atom:content</code> and <code>atom:summary</code> as HTML
* <code>atom:content</code> and <code>atom:summary</code> as plain-text
* <code>atom:title</code> as XHTML
* <code>atom:title</code> as HTML
</li>
<li>Support for other XSLT engines:
* MSXML
* .Net System.Xml
* Sablotron
* Oracle XSLT
* XT
</li>
<li>Support for other output formats: (hAtom2<i>xyz</i>.xsl)
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl])
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt])
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])
* JSON?
</li>
</ul>

([[User:Singpolyma|singpolyma]] 01:02, 9 May 2006 (PDT) -- Not XSLT, but see http://xoxotools.ning.com/hatom2rss.php for hatom to RSS2.0 conversion)

== Brian Suda ==
=== Citation Microformats ===
* Add all my notes to the Wiki
* Start the process of naming the properties using existing names

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working
==== WARNINGS and ERROR ====
work on the warnings and error output for the pre-check in X2V

=== FAQ ===
* clean-up the MF FAQs
* clean-up FAQs from the major microformats
* pull Questions from the mailing list and document them to the FAQs and example

== Mark Rickerby ==

=== Current Tasks ===

* Follow up on usability review
** Edits to homepage feature box text
** Draft of [[getting-started]] page
* Review content for new pages - [[start-simple]], [[modularity]], [[reuse]], [[humans-first]]
* xoxo datatype examples
** test case lists
** transmitting key/value lists
* practical feedback on hresume

=== Wishlist ===

* hmmm

== Ernest Prabhakar ==
=== Wiki-Thon Proposal ===
Set aside several hours (probably a Friday night US PST) for focused work on the Wiki, including both physical (e.g., a room in the Bay Area) and virtual (IRC/iChat) participants.

==== Goals ====
# Improve understanding of what needs to be done for Wiki
#* IMHO - this should be done here, in [[to-do]] incrementally. -Tantek
# Tackle larger projects (~1-2 hours) than people usually have time for
#* I'd like to see these projects *documented* first on [[to-do]] before we spend 1-2 hours of a bunch of folk's collective time to go through them. -Tantek
# Motivate community to have fun with otherwise tedious "housecleaning" chores

==== Agenda (Wishlist) ====
In parallel:
* Coalesce/prioritize existing To-Do items (above)
* Review/revise desired pathways for:
** New users learning about microformats
*** e.g., intro, about, explore, tutorials, etc.
*** cf. [http://www.rubyonrails.com/ Rails] front page
****Get Excited (Why, background, motivation)
****Get Started (What, downloads, getting started)
****Get Better (How, tutorials, )
****Get Involved (Who)
** Microformat lifecycle
*** e.g., research->brainstorm->proposal->spec->maintain
*** see http://theryanking.com/microformats/method.txt --[[User:RyanKing|RyanKing]] 15:35, 22 Feb 2006 (PST)
*** ensure information easy to find, follow, and up-to-date
* Review existing specs for completeness and consistency
* Identify areas of 'bitrot' or 'hole-filling'
* Do it!

== Dan Connolly ==

[[User:DanC|DanC]] hopes to sync up on these tasks in [[irc]] roughly
weekly, during Wednesday afternoon (Chicago time) "office hours". See also my [http://esw.w3.org/topic/DanConnolly esw todo list and someday pile].

* from SxSW in Austin
** build a combined hcalendar/hcard profile; resolve issues in [[profile-uris]].
*** with XSLT transformation to RDF
** finish [[hcard-tests]]
*** figure out [[include-pattern]] boundaries

* Medium term
** sync [[hcalendar-tests]] and [http://www.w3.org/2002/12/cal/ RDF calendar] tests and CALSIFY
*** reconsider RDF calendar naming conventions
*** get an answer from the CALSIFY WG re [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0006.html dtstart and date vs datetime ] 21 Apr 2006
*** refine [[hatom]] so that it's suitable for the workflow around the W3C homepage.

* from WWW2006
** follow up on GRDDL as escape valve for microformats proposals, much like CSS was an escape valve for HTML tag proposals.

* Someday pile
** set up a timezone registry based on wikipedia and semantic mediawiki. As discussed in [[datetime-design-pattern]], iCalendar's by-value timezone passing is broken. see [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0002.html reconsidering timezones in light of hCalendar and CALSIFY] and [http://dig.csail.mit.edu/breadcrumbs/node/91 Toward Semantic Web data from Wikipedia]
** update my CV/resume using [[hResume]] and [[citation-formats]]
** noodle on a playlist format and some of the media RSS stuff like [[media-info-brainstorming]]
** check out that hReview bug stuff...
** noodle on [[meeting-minutes-brainstorming]] and [http://esw.w3.org/topic/MeetingRecords MeetingRecords in the esw wiki].
** noodle on clipboard scenarios, esp how RDFa works in the general case but isn't as author-friendly as domain-specific syntaxes.

[[User:DanC|DanC]] 15:39, 31 May 2006 (PDT)

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

* get around to updating [[hatom-issues]] with some multi feed rules/exceptions.
* <del>Update textpattern plugin with simple hreview support and get a new release out</del>
* Redesign placenamehere.com and include hatom
* Follow up with technorati folks on pingerati reviews getting lost
* prototype a NetNewsWire microformat extractor (CSS+AppleScript)

== New Person 2 ==

etc.

hreview

2006-06-26T00:15:55Z

ChrisCasciano: /* Implementations - textpattern plugin */

<h1> hReview 0.3 </h1>

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

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

== Microformats Draft Specification 2006-02-22 ==

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

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

__TOC__

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

In order to enable and encourage the sharing, distribution, syndication, and aggregation, of reviews, the authors propose the hReview microformat, an open standard for distributed reviews. The authors have researched both numerous [[review-examples]] in the wild and earlier attempts at [[review-formats]], and have designed hReview around a simple minimal schema for reviews. Feedback is encouraged on the [[hreview-feedback|hReview feedback]] page.

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

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

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

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

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

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

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

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

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

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

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

'''item type''':: This optional field "type" provides the type of the item being reviewed, one of the following: product, business, event, person, place, website, url. If omitted, then in some cases the item type may be inferred. If the item is also an [[hcard|hCard]], then the item type is a "business" or a "person" based upon which of those the hCard represents. If the item is also an [[hcalendar|hCalendar]] event, then the item type is an "event".

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

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

'''dtreviewed''':: This optional field when present MUST provide an ISO8601 absolute date time of when the review was written or otherwise authored. This field SHOULD use UTC, but MAY use the time zone offset syntax. If dtreviewed is absent from the hReview, then look outside the hReview, in the surrounding context. If the context is an [[hatom|hAtom]] entry, use its "published" (or "updated" if that is missing) datetime as the dtreviewed, if not present on the entry, use the "published" (or "updated" if that is missing) of the feed. Otherwise use the creation date (or modified date if that is missing) information according to the containing document language (e.g. "published"/"updated" similarly for Atom feeds), then protocol (e.g. HTTP Last-Modified, or file system last modified datetime) as the dtreviewed.

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

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

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the reviewer associates with the item. The reviewer MAY optionally provide a tag-specific rating inside each [[rel-tag]], e.g. ambience:5. Tag-specific ratings by default use the same range as an overall rating for the item if present, and MAY also have a custom worst...best range specified. Authors MAY also invert this structure for the same semantic if it is more convenient for their markup, that is, place the [[rel-tag]] inside a rating to indicate a rated tag. Note: rated tags should ideally use a tag space that explains what the ratings for that tag mean. E.g. Food:18/30 should link to a tags space for Food that explains what an 18 out of 30 means for the Food tag.

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

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

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

=== More Semantic Equivalents ===

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

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

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

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

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

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

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

=== Object Includes ===

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

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

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

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

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

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

=== Restaurant reviews ===

Here is an example of a simple online restaurant review:

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

Adding hReview to this review is quite simple:

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

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

This sample hReview could be rendered like this:

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

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

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

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

Here is one such review in text format:

Cafe Borrone

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

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

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

As an hReview:

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

With an accompanying CSS style sheet like:

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

This hReview could be presented similar to the original text:

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

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

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

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

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

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

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

And this hReview might be presented like this:

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

The Postal Service: Give Up

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

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

(*****)

Review by Adam Rifkin, February 2005.

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

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

With hReview:

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

Which could be presented like this:

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

This movie has great music and visuals.

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

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

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.

*[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]
*[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.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].

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

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

* Textpattern plug-in : [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding hReview and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* [http://kitchen.technorati.com/search Technorati Microformats Search] indexes [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] as [http://tantek.com/log/2006/05.html#d31t1802 announced by Tantek].
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - port of Tails extension for Flock 0.5.12 that looks for hCards, hCalendar, xFolk and hReview and tosses them into a handy topbar
* [http://www.reevoo.com/blogs/bengriffiths/ Revieworld CTO Ben Griffiths] has announced that they have built support into [http://www.reevoo.com/ Reevoo] to [http://www.reevoo.com/blogs/bengriffiths/2006/02/01/join-the-reevolution/ aggregate reviews of products that are published on blogs using hReview] ([http://opensource.reevoo.com/2006/03/08/release-uformats-12/ open source parser for Ruby])
* [http://brain.lionsden.com/ Leo Cerebellum Annotare] notes that [http://brain.lionsden.com/?p=229 ReviewZilla Alpha 2 includes MicroFormat hReview markup]
* [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://blog.codeeg.com/tails-firefox-extension/ Tails is a Firefox Extension] that will display the presence of microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]) on a webpage.
* [http://kritx.com Kritx] is a site that indexes hReviews and other reviews on the Web.
* [http://www.goodpic.com/mt/aws/index_us.html Goodpic] has written:
** [http://www.goodpic.com/mt/aws/index_us.html hReview creator for Amazon.com products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.uk products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.jp products]
** be sure to choose the "hRview" tab from among the choices on the page that says "You can choose from more than 30 designs, please click the tab to select categories."
* See the microformats.org [http://microformats.org/code/hreview/creator hReview creator]
* [http://www.eigaseikatu.com/ Eigaseikatu], one of the largest movie community sites in Japan, provides [http://www.eigaseikatu.com/hreview/ hReview creator] for movie review.
* [http://sungnyemun.org/wordpress/?p=22 hReview plugin for WordPress]
* [http://paulgoscicki.com/projects/wp-movie-ratings/ WP Movie Ratings] is a [http://wordpress.org WordPress] plugin made by [http://paulgoscicki.com Paul Goscicki] which lets you rate (and review) movies and publish those ratings as hReviews.
* [http://theryanking.com/ Ryan King] has an [http://theryanking.com/microformats/hreview-creator.html hReview Creator].
* [http://rvu.ning.com/ Rvu] is a [http://ning.com Ning] app that lets you write reviews of reviews and publishes them in hReview
* [http://randomchaos.com/microformats/base/ Microformat Base] is an open-source PHP microformat aggregation crawler, currently recognizing hreview, hcalendar, and hcard.

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[rel-tag]]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc3986.txt RFC3986]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

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

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

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

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

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

=== Changes from v0.2 ===
The following changes have been made in hReview v0.3 over [[hreview-v0.2|hReview v0.2]]:

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

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

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

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

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

hreview

2006-06-05T06:42:56Z

ChrisCasciano: /* Examples in the wild */

<h1> hReview 0.3 </h1>

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

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

== Microformats Draft Specification 2006-02-22 ==

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

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

__TOC__

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

In order to enable and encourage the sharing, distribution, syndication, and aggregation, of reviews, the authors propose the hReview microformat, an open standard for distributed reviews. The authors have researched both numerous [[review-examples]] in the wild and earlier attempts at [[review-formats]], and have designed hReview around a simple minimal schema for reviews. Feedback is encouraged on the [[hreview-feedback|hReview feedback]] page.

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

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

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

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

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

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

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

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

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

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

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

'''item type''':: This optional field "type" provides the type of the item being reviewed, one of the following: product, business, event, person, place, website, url. If omitted, then in some cases the item type may be inferred. If the item is also an [[hcard|hCard]], then the item type is a "business" or a "person" based upon which of those the hCard represents. If the item is also an [[hcalendar|hCalendar]] event, then the item type is an "event".

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

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

'''dtreviewed''':: This optional field when present MUST provide an ISO8601 absolute date time of when the review was written or otherwise authored. This field SHOULD use UTC, but MAY use the time zone offset syntax. If dtreviewed is absent from the hReview, then look outside the hReview, in the surrounding context. If the context is an [[hatom|hAtom]] entry, use its "published" (or "updated" if that is missing) datetime as the dtreviewed, if not present on the entry, use the "published" (or "updated" if that is missing) of the feed. Otherwise use the creation date (or modified date if that is missing) information according to the containing document language (e.g. "published"/"updated" similarly for Atom feeds), then protocol (e.g. HTTP Last-Modified, or file system last modified datetime) as the dtreviewed.

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

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

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the reviewer associates with the item. The reviewer MAY optionally provide a tag-specific rating inside each [[rel-tag]], e.g. ambience:5. Tag-specific ratings by default use the same range as an overall rating for the item if present, and MAY also have a custom worst...best range specified. Authors MAY also invert this structure for the same semantic if it is more convenient for their markup, that is, place the [[rel-tag]] inside a rating to indicate a rated tag. Note: rated tags should ideally use a tag space that explains what the ratings for that tag mean. E.g. Food:18/30 should link to a tags space for Food that explains what an 18 out of 30 means for the Food tag.

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

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

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

=== More Semantic Equivalents ===

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

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

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

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

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

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

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

=== Object Includes ===

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

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

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

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

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

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

=== Restaurant reviews ===

Here is an example of a simple online restaurant review:

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

Adding hReview to this review is quite simple:

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

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

This sample hReview could be rendered like this:

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

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

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

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

Here is one such review in text format:

Cafe Borrone

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

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

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

As an hReview:

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

With an accompanying CSS style sheet like:

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

This hReview could be presented similar to the original text:

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

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

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

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

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

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

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

And this hReview might be presented like this:

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

The Postal Service: Give Up

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

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

(*****)

Review by Adam Rifkin, February 2005.

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

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

With hReview:

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

Which could be presented like this:

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

This movie has great music and visuals.

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

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

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.

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

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

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

* [http://kitchen.technorati.com/search Technorati Microformats Search] indexes [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] as [http://tantek.com/log/2006/05.html#d31t1802 announced by Tantek].
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - port of Tails extension for Flock 0.5.12 that looks for hCards, hCalendar, xFolk and hReview and tosses them into a handy topbar
* [http://www.reevoo.com/blogs/bengriffiths/ Revieworld CTO Ben Griffiths] has announced that they have built support into [http://www.reevoo.com/ Reevoo] to [http://www.reevoo.com/blogs/bengriffiths/2006/02/01/join-the-reevolution/ aggregate reviews of products that are published on blogs using hReview] ([http://opensource.reevoo.com/2006/03/08/release-uformats-12/ open source parser for Ruby])
* [http://brain.lionsden.com/ Leo Cerebellum Annotare] notes that [http://brain.lionsden.com/?p=229 ReviewZilla Alpha 2 includes MicroFormat hReview markup]
* [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://blog.codeeg.com/tails-firefox-extension/ Tails is a Firefox Extension] that will display the presence of microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]) on a webpage.
* [http://kritx.com Kritx] is a site that indexes hReviews and other reviews on the Web.
* [http://www.goodpic.com/mt/aws/index_us.html Goodpic] has written:
** [http://www.goodpic.com/mt/aws/index_us.html hReview creator for Amazon.com products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.uk products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.jp products]
** be sure to choose the "hRview" tab from among the choices on the page that says "You can choose from more than 30 designs, please click the tab to select categories."
* See the microformats.org [http://microformats.org/code/hreview/creator hReview creator]
* [http://www.eigaseikatu.com/ Eigaseikatu], one of the largest movie community sites in Japan, provides [http://www.eigaseikatu.com/hreview/ hReview creator] for movie review.
* [http://sungnyemun.org/wordpress/?p=22 hReview plugin for WordPress]
* [http://theryanking.com/ Ryan King] has an [http://theryanking.com/microformats/hreview-creator.html hReview Creator].
* [http://rvu.ning.com/ Rvu] is a [http://ning.com Ning] app that lets you write reviews of reviews and publishes them in hReview
* [http://randomchaos.com/microformats/base/ Microformat Base] is an open-source PHP microformat aggregation crawler, currently recognizing hreview, hcalendar, and hcard.

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[rel-tag]]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc3986.txt RFC3986]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

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

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

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

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

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

=== Changes from v0.2 ===
The following changes have been made in hReview v0.3 over [[hreview-v0.2|hReview v0.2]]:

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

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

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

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

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

to-do

2006-06-05T06:36:48Z

ChrisCasciano: added new person - me

<h1>To Do</h1>

This page is for posting [[microformats]] related shared to do items. If you want to use this page for your microformats related to-do items, create a section with your name on it. The reason we are keeping these all on the same page is to make it easier to tell when people are working on similar things, and to make it more obvious when people help out with other people's tasks. In theory this probably won't scale, but let's first see how it does in practice. :) - [http://tantek.com Tantek]

__TOC__

== Lazyweb ==

Just some nice things, feel free to do any of these.

=== for all microformats ===
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.
* write up [http://microformats.org/discuss/ mailing-list] questions and answers in the appropriate [[faq]] pages.
* validators. See the hReview section below as there has been a request for an hReview validator in particular. See [http://norman.walsh.name/2006/04/13/validatingMicroformats Norman Walsh's blog post "Validating microformats"] for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.

=== hReview ===
* [[hreview|hReview]] support in Ecto (hey Adriaan!), requested by Andy Smith
* an [[hreview|hReview]] validator.
* a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)
** both [http://komodomedia.com/blog/index.php/2005/08/24/creating-a-star-rater-using-css/ this] and [http://factorycity.net/demos/drupal/rating/default.html this] have some flaws. Ask [[User:RyanKing|Ryan King]] for an explanation.

=== hCard ===
* microformatted versions of conference pages
** Do a revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].
* vcard to hcard converter
** would be nice to have a web upload UI that would take one or more vCards from apple's address book and give them back to you as hCards
** [[User:RobertBachmann | RobertBachmann]] suggests starting points:
*** For Ruby: http://vpim.rubyforge.org/
*** For C: http://freshmeat.net/projects/libvc/
*** For Python: http://www.nongnu.org/python-pdi/
*** For PHP: http://pear.php.net/package/Contact_Vcard_Parse/
* add export support for microformats to [http://www.turingart.com/abForWeb_lan__en.htm AB to Web]
* A mash-up with google maps that will take any url with a hcard (or hcard's) and map the location(s) on a map (similar to [http://austin.adactio.com/ austin.adactio.com])

=== hCalendar/hCard/hReview editor ===
* onblur in the URL field (e.g. on hCalendar), goes out and tries to retrieve an object of same time (e.g. an hCalendar vevent) from that URL and uses it to autofill the form, same thing if the creator is loaded with that URL prefilled (e.g. due to a ?url=http://example.com/ in the URL that loads the creator).

=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvement
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]

=== Yahoo Open Source Library Patches ===

Several of these could very much be improved with a little microformats markup. Do we just make patches and submit them? Contact Nate Koechley at Yahoo (see Tantek for contact info) to follow-up.

* [http://developer.yahoo.net/yui/ Yahoo! User Interface Library]
* [http://developer.yahoo.net/ypatterns/ Yahoo! Design Patterns Library]
* [http://www.yuiblog.com Yahoo! User Interface Blog]

=== Drupal patches for microformats ===
* submit patches for Drupal code/templates for microformats improvement
* Drupal modules for microformats, specifically hReview and hCalendar

=== Adding Markup to Existing Pages (W3C track at WWW2006) ===

* DanC offers a 150 point bounty to anybody who takes [http://www.w3.org/2006/05/w3c-track the W3C track at WWW2006] and adds hCalendar markup and sends it to connolly@w3.org,www-archive@w3.org

== Tantek ==

I'm keeping a few microformats related to-do items here both for my own convenience, and for folks looking to help out with small tasks. If so, just create a new section with your name, and and maybe copy the item there, and put your name next to the item in my list. We'll figure this out as we go along. Thanks, [http://tantek.com Tantek].

=== for all microformat specs ===
* sort implementations by authoring/creating/publishing, browsing/viewing, converting/importing, indexing/searching.

Hmmm... I like: '''A'''uthoring, '''B'''rowsing, '''C'''onverting, '''I'''ndexing, '''L'''ibraries (for developers), and '''P'''otential (for open source projects we want to add support to). Anybody have alternative suggestions for this vocabulary? I don't have a particularly strong preference so I'm going to go with these four until I find examples that don't fit, or someone suggests something better.

See: [http://microformats.org/wiki/hcalendar#Implementations hCalendar Implementations] for a first attempt at this. Assuming folks like that, we can go ahead with categorizing the implementations sections of other microformats specifications.

=== iterate on current microformats ===
==== [[hreview|hReview]] ====
* Write hReview 0.3 XMDP profile, and reconcile with [[hcalendar-profile]] and [[hcard-profile]]. Makes sense to have a combined profile of all three for hReview, since hReview normatively depends on hCard and hCalendar.

==== [[hcalendar|hCalendar]] ====
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need to resolve all outstanding [[hcalendar-issues]] to-do items.
* create [[hcalendar-profile]] and have folks verify it. note that it will likely need reconciliation with the [[hcard-profile]], especially since [[hcalendar|hCalendar]] normatively depends on [[hcard|hCard]]. Probably makes sense to have a combined profile which hCalendar would use.

==== [[hcard|hCard]] ====
* [[hcard-examples]]
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].
** add example of organization-name and organization-unit usage.
* Examples in the wild - need to create a new page for them!
** Group examples in the wild according to:
*** Individuals - one card per person, perhaps sort alphabetically
*** Organizations - one card per organization, alphabetical again
*** Institutions (which list more than one person), with a count estimating the # of hCards, e.g. 40k for Avon
*** Online Profiles (which host profiles for more than one person) with a count estimating the # of hCards, e.g. 3.5m for Flickr.com
*** Online Venues (which provide listings for businesses or organizations) with a count estimating the # of venues, e.g. ~10k for Upcoming.org
*** Speakers Listings (lists of speakers on conference sites) with a count estimating the # of speakers, e.g. ~300 for SXSW 2006.
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== introduction / community ===
* microformats-discuss
** introductory email sent to new subscribers needs to direct people to [[process]] and [[how-to-play]]
* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.

=== profiles ===

* update XMDP with new required features:
** ability for one profile to include/import another (rel="import" ?)
** ability to reference an XMDP via rel="profile" (similar to XHTML2 rel value by same name)
** ability/suggestion to reference an XMDP using <a href> in addition to <link>

=== microformat parsing documentation ===
* Add XPath equivalents where appropriate in [[hcard-parsing]]

=== create microformats wiki pages for ===
* *-authoring for all microformats
* *-parsing for all microformats

=== improve usability and automation on the site ===
* figure out how to get wordpress to autopost blog posts to the microformats-announce list
** ideally use the from address of the author of the blog post
** maybe photomatt knows how to do this.

=== help with microformat implementations ===
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** look for hcards and parse them
* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.
* Conference Schedule Creator
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

=== help with microformat examples in the wild ===
Go over all "common" pages (both logged out and logged in states) of the following sites which have some microformats already, and verify each page is as microformatted as it can be with high fidelity [[hcalendar|hCalendar]] and [[hcard|hCard]] etc. Document full support of each implementation's microformats on the implementations page (perhaps create a separate page for each implementation, e.g. [[flickr]], [[upcoming]], [[eventful]] etc.) Document any exceptions as needed. In no particular order:
* Flickr.com (3.5m hCards)
* Upcoming.org (100k hCalendar events, 100k hCard venues)
** home page
* Eventful.com (100k hCalendar events, 100k hCard venues)
* Yahoo! Tech (300k products with hReviews)
* JudysBook.com (???k hReviews)
* ... lots more, get from "Implementations" and "Examples in the Wild" sections of specs.

=== help with new microformat requests ===
* expense reports (really just a list of "expense" items), [http://flickr.com/photos/edyson/56774178/ requested by ED], should look at UBL as a pre-existing format
* photo-notes microformat
** clean up Subethaedit notes from working session with Greg Elin, Ryan King, Kevin Marks, Suw Charman and email to folks and figure out next steps
** iterate on [[photo-note-examples]] and start [[photo-note-formats]] and [[photo-note-brainstorming]].

* Can we make "microformat" and "microformats" into [http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ Community Marks]?

==Ryan==
=== hCalendar/hCard/hReview creator improvements ===
* get all creators working in IE/Win, IE/Mac, Safari/OSX.3

=== *-authoring microformats wiki pages ===
* Add some tips to [[hcard-authoring]] - a tutorial on creating an hCard for your site, blog (common platforms), etc.
* [[hcalendar-authoring]] - a tutorial on how to blog events so your friends can subscribe to them
* [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.

=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15) -> verify http://svn.lifelint.com/hcalendar_tests/calendar-todo-multiple-attendees-and-alarm.xml

=== rel-payment ===
* update rel-payment to reference the IANA registry [http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02055.html]

=== hcalendar ===
* move tests from http://svn.lifelint.com/hcalendar_tests/ to subversion on microformats.org
* make sure we explicitly disallow 'vjournal'

== Dimitri Glazkov ==

* Figure out REST/Microformats thing
* Work on result set idea
* Implement h-creators using Web Forms 2.0

== Chris Messina ==

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item (take a look at [[media-info-examples]])
* Work on microformats tutorial for designers

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts" (see [http://factoryjoe.com/blog/2006/03/20/flocktails-for-flock/ Flocktails])
* Better hCal support -- support many views of same hCal data on one page using XSLT
* We need something that a designer/web programmer can come to and leave w/ 2 examples of each microformat that they can apply right away... a "microformats styleguide for designers", if you will.
* invoicing microformat
* better microformats wiki theme

== Robert Bachmann ==

=== hCard Creator ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** aim / instant messaging contact info, using the techniques documented in [[hcard-examples#New_Types_of_Contact_Info|hCard Examples: New Types of Contact Info]]
*** consider a popup menu for the IM service (AIM|Yahoo|...), and a field next to it for the IM id.

=== hAtom2Atom ===

Some ideas for features which could be implemented :

(If you are interested in one of this features, add "<i>+1 Your Name</i>")

<ul>
<li>
Join all hfeed's inside a page (or a fragment thereof) into one feed using [http://greenbytes.de/tech/webdav/rfc4287.html#element.source atom:source] semantics.
</li>
<li>
Extraction of <code>atom:content</code>, <code>atom:summary</code> and <code>atom:title</code>:
* <code>atom:content</code> and <code>atom:summary</code> as HTML
* <code>atom:content</code> and <code>atom:summary</code> as plain-text
* <code>atom:title</code> as XHTML
* <code>atom:title</code> as HTML
</li>
<li>Support for other XSLT engines:
* MSXML
* .Net System.Xml
* Sablotron
* Oracle XSLT
* XT
</li>
<li>Support for other output formats: (hAtom2<i>xyz</i>.xsl)
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl])
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt])
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])
* JSON?
</li>
</ul>

([[User:Singpolyma|singpolyma]] 01:02, 9 May 2006 (PDT) -- Not XSLT, but see http://xoxotools.ning.com/hatom2rss.php for hatom to RSS2.0 conversion)

== Brian Suda ==
=== Citation Microformats ===
* Add all my notes to the Wiki
* Start the process of naming the properties using existing names

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working
==== WARNINGS and ERROR ====
work on the warnings and error output for the pre-check in X2V

=== FAQ ===
* clean-up the MF FAQs
* clean-up FAQs from the major microformats
* pull Questions from the mailing list and document them to the FAQs and example

== Mark Rickerby ==

=== Current Tasks ===

* Follow up on usability review
** Edits to homepage feature box text
** Draft of [[getting-started]] page
* Review content for new pages - [[start-simple]], [[modularity]], [[reuse]], [[humans-first]]
* xoxo datatype examples
** test case lists
** transmitting key/value lists
* practical feedback on hresume

=== Wishlist ===

* hmmm

== Ernest Prabhakar ==
=== Wiki-Thon Proposal ===
Set aside several hours (probably a Friday night US PST) for focused work on the Wiki, including both physical (e.g., a room in the Bay Area) and virtual (IRC/iChat) participants.

==== Goals ====
# Improve understanding of what needs to be done for Wiki
#* IMHO - this should be done here, in [[to-do]] incrementally. -Tantek
# Tackle larger projects (~1-2 hours) than people usually have time for
#* I'd like to see these projects *documented* first on [[to-do]] before we spend 1-2 hours of a bunch of folk's collective time to go through them. -Tantek
# Motivate community to have fun with otherwise tedious "housecleaning" chores

==== Agenda (Wishlist) ====
In parallel:
* Coalesce/prioritize existing To-Do items (above)
* Review/revise desired pathways for:
** New users learning about microformats
*** e.g., intro, about, explore, tutorials, etc.
*** cf. [http://www.rubyonrails.com/ Rails] front page
****Get Excited (Why, background, motivation)
****Get Started (What, downloads, getting started)
****Get Better (How, tutorials, )
****Get Involved (Who)
** Microformat lifecycle
*** e.g., research->brainstorm->proposal->spec->maintain
*** see http://theryanking.com/microformats/method.txt --[[User:RyanKing|RyanKing]] 15:35, 22 Feb 2006 (PST)
*** ensure information easy to find, follow, and up-to-date
* Review existing specs for completeness and consistency
* Identify areas of 'bitrot' or 'hole-filling'
* Do it!

== Dan Connolly ==

[[User:DanC|DanC]] hopes to sync up on these tasks in [[irc]] roughly
weekly, during Wednesday afternoon (Chicago time) "office hours". See also my [http://esw.w3.org/topic/DanConnolly esw todo list and someday pile].

* from SxSW in Austin
** build a combined hcalendar/hcard profile; resolve issues in [[profile-uris]].
*** with XSLT transformation to RDF
** finish [[hcard-tests]]
*** figure out [[include-pattern]] boundaries

* Medium term
** sync [[hcalendar-tests]] and [http://www.w3.org/2002/12/cal/ RDF calendar] tests and CALSIFY
*** reconsider RDF calendar naming conventions
*** get an answer from the CALSIFY WG re [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0006.html dtstart and date vs datetime ] 21 Apr 2006
*** refine [[hatom]] so that it's suitable for the workflow around the W3C homepage.

* from WWW2006
** follow up on GRDDL as escape valve for microformats proposals, much like CSS was an escape valve for HTML tag proposals.

* Someday pile
** set up a timezone registry based on wikipedia and semantic mediawiki. As discussed in [[datetime-design-pattern]], iCalendar's by-value timezone passing is broken. see [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0002.html reconsidering timezones in light of hCalendar and CALSIFY] and [http://dig.csail.mit.edu/breadcrumbs/node/91 Toward Semantic Web data from Wikipedia]
** update my CV/resume using [[hResume]] and [[citation-formats]]
** noodle on a playlist format and some of the media RSS stuff like [[media-info-brainstorming]]
** check out that hReview bug stuff...
** noodle on [[meeting-minutes-brainstorming]] and [http://esw.w3.org/topic/MeetingRecords MeetingRecords in the esw wiki].
** noodle on clipboard scenarios, esp how RDFa works in the general case but isn't as author-friendly as domain-specific syntaxes.

[[User:DanC|DanC]] 15:39, 31 May 2006 (PDT)

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

* get around to updating [[hatom-issues]] with some multi feed rules/exceptions.
* Update textpattern plugin with simple hreview support and get a new release out
* Redesign placenamehere.com and include hatom
* Follow up with technorati folks on pingerati reviews getting lost

== New Person 2 ==

etc.

hreview

2006-06-03T05:03:58Z

ChrisCasciano: this spec is really 0.3

<h1> hReview 0.3 </h1>

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

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

== Microformats Draft Specification 2006-02-22 ==

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

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

__TOC__

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

In order to enable and encourage the sharing, distribution, syndication, and aggregation, of reviews, the authors propose the hReview microformat, an open standard for distributed reviews. The authors have researched both numerous [[review-examples]] in the wild and earlier attempts at [[review-formats]], and have designed hReview around a simple minimal schema for reviews. Feedback is encouraged on the [[hreview-feedback|hReview feedback]] page.

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

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

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

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

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

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

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

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

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

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

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

'''item type''':: This optional field "type" provides the type of the item being reviewed, one of the following: product, business, event, person, place, website, url. If omitted, then in some cases the item type may be inferred. If the item is also an [[hcard|hCard]], then the item type is a "business" or a "person" based upon which of those the hCard represents. If the item is also an [[hcalendar|hCalendar]] event, then the item type is an "event".

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

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

'''dtreviewed''':: This optional field when present MUST provide an ISO8601 absolute date time of when the review was written or otherwise authored. This field SHOULD use UTC, but MAY use the time zone offset syntax. If dtreviewed is absent from the hReview, then look outside the hReview, in the surrounding context. If the context is an [[hatom|hAtom]] entry, use its "published" (or "updated" if that is missing) datetime as the dtreviewed, if not present on the entry, use the "published" (or "updated" if that is missing) of the feed. Otherwise use the creation date (or modified date if that is missing) information according to the containing document language (e.g. "published"/"updated" similarly for Atom feeds), then protocol (e.g. HTTP Last-Modified, or file system last modified datetime) as the dtreviewed.

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

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

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the reviewer associates with the item. The reviewer MAY optionally provide a tag-specific rating inside each [[rel-tag]], e.g. ambience:5. Tag-specific ratings by default use the same range as an overall rating for the item if present, and MAY also have a custom worst...best range specified. Authors MAY also invert this structure for the same semantic if it is more convenient for their markup, that is, place the [[rel-tag]] inside a rating to indicate a rated tag. Note: rated tags should ideally use a tag space that explains what the ratings for that tag mean. E.g. Food:18/30 should link to a tags space for Food that explains what an 18 out of 30 means for the Food tag.

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

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

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

=== More Semantic Equivalents ===

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

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

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

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

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

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

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

=== Object Includes ===

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

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

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

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

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

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

=== Restaurant reviews ===

Here is an example of a simple online restaurant review:

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

Adding hReview to this review is quite simple:

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

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

This sample hReview could be rendered like this:

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

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

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

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

Here is one such review in text format:

Cafe Borrone

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

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

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

As an hReview:

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

With an accompanying CSS style sheet like:

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

This hReview could be presented similar to the original text:

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

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

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

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

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

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

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

And this hReview might be presented like this:

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

The Postal Service: Give Up

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

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

(*****)

Review by Adam Rifkin, February 2005.

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

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

With hReview:

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

Which could be presented like this:

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

This movie has great music and visuals.

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

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

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.

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

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

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

* [http://kitchen.technorati.com/search Technorati Microformats Search] indexes [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] as [http://tantek.com/log/2006/05.html#d31t1802 announced by Tantek].
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - port of Tails extension for Flock 0.5.12 that looks for hCards, hCalendar, xFolk and hReview and tosses them into a handy topbar
* [http://www.reevoo.com/blogs/bengriffiths/ Revieworld CTO Ben Griffiths] has announced that they have built support into [http://www.reevoo.com/ Reevoo] to [http://www.reevoo.com/blogs/bengriffiths/2006/02/01/join-the-reevolution/ aggregate reviews of products that are published on blogs using hReview] ([http://opensource.reevoo.com/2006/03/08/release-uformats-12/ open source parser for Ruby])
* [http://brain.lionsden.com/ Leo Cerebellum Annotare] notes that [http://brain.lionsden.com/?p=229 ReviewZilla Alpha 2 includes MicroFormat hReview markup]
* [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://blog.codeeg.com/tails-firefox-extension/ Tails is a Firefox Extension] that will display the presence of microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]) on a webpage.
* [http://kritx.com Kritx] is a site that indexes hReviews and other reviews on the Web.
* [http://www.goodpic.com/mt/aws/index_us.html Goodpic] has written:
** [http://www.goodpic.com/mt/aws/index_us.html hReview creator for Amazon.com products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.uk products]
** [http://www.goodpic.com/mt/aws/index_uk.html hReview creator for Amazon.co.jp products]
** be sure to choose the "hRview" tab from among the choices on the page that says "You can choose from more than 30 designs, please click the tab to select categories."
* See the microformats.org [http://microformats.org/code/hreview/creator hReview creator]
* [http://www.eigaseikatu.com/ Eigaseikatu], one of the largest movie community sites in Japan, provides [http://www.eigaseikatu.com/hreview/ hReview creator] for movie review.
* [http://sungnyemun.org/wordpress/?p=22 hReview plugin for WordPress]
* [http://theryanking.com/ Ryan King] has an [http://theryanking.com/microformats/hreview-creator.html hReview Creator].
* [http://rvu.ning.com/ Rvu] is a [http://ning.com Ning] app that lets you write reviews of reviews and publishes them in hReview
* [http://randomchaos.com/microformats/base/ Microformat Base] is an open-source PHP microformat aggregation crawler, currently recognizing hreview, hcalendar, and hcard.

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[rel-tag]]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc3986.txt RFC3986]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

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

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

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

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

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

=== Changes from v0.2 ===
The following changes have been made in hReview v0.3 over [[hreview-v0.2|hReview v0.2]]:

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

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

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

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

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

Main Page

2006-05-25T12:28:37Z

ChrisCasciano: reverting to remove spam

__NOTOC__
__NOTOC__
= Microformats Wiki =

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

[[what-are-microformats|What are microformats]]? And [[what-can-you-do-with-microformats|what can you do with them]]? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]], [[presentations]], [[podcasts]], and [[screencasts]] are also a good place for some background reading/listening. Frequently asked questions are answered in the [[faq]]. Want something or want to contribute? Help with things [[to-do]]. Want to learn more in person? Check out microformats [[events]].

One popular definition from our [http://microformats.org/discuss/ mailing list] (see also: [[mailing-lists]]) is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]]
* [[geo|geo]]
* [[hatom|hAtom]] {{NewMarker}}
* [[hresume|hResume]] {{NewMarker}}
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[rel-home]] {{NewMarker}}
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk|xFolk]]

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[abbr-design-pattern]]
* [[class-design-pattern]]
* [[datetime-design-pattern]]
* [[existing-classes|class names defined across all microformats]]
* [[include-pattern]] {{NewMarker}}
* [[rel-design-pattern]]

== Exploratory discussions ==
Research and analysis of real-world [[examples]], existing formats, and brainstorming to motivate the microformat.
*[[attention]]
*[[blog-description-examples]]
*[[blog-info-examples]]
*[[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]] (yields [[hatom|hAtom]])
*[[book-examples]], [[book-formats]], [[book-brainstorming]]
*[[chat-examples]], [[chat-formats]]
*[[citation|citation microformat overview]], [[citation-examples]], [[citation-formats]], [[citation-brainstorming]]
*[[comment-problem]], [[comment-examples]], (need to extract from [[comments-formats]])
*[[directions-examples]] {{NewMarker}}
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[distributed-conversation]], [[distributed-conversation-brainstorming]], [[distributed-conversation-examples]], [[distributed-conversation-formats]]
*[[forms-examples]]
*[[genealogy-formats]]
*[[hash-examples]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[hlisting-proposal]], [[hlisting-feedback]] {{NewMarker}}
**[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-info-examples]]
*[[meeting-minutes-examples]], [[meeting-minutes-formats]], [[meeting-minutes-brainstorming]]
*[[mfo-examples]]
*[[music-examples]]
*[[other-formats]]
*[[photo-note-examples]]
*[[recipe-examples]]
*[[requirements-testing]], [[requirements-testing-examples]]
*[[rest-examples]]
*[[resume-brainstorming]], [[resume-formats]]
*[[review-examples]], [[review-formats]] (yielded the [[hreview|hReview]] draft)
*[[search-results-example]]
*[[show-brainstorming]]
*[[showroll-brainstorming]]
*[[table-examples]]
*[[tagspeak-examples]]
*[[transit-table-examples]]
*[[uid]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[work-of-art]] {{NewMarker}}
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[http://hg.microformats.org/ Source code repository]
*[[vcard-implementations]], [[vcard-errata]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]
*[[why-are-content-standards-hard]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[events]] {{NewMarker}}
* [[to-do]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different</del> other languages

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]]
* [[Main_Page-jp|日本語 (Japanese)]] {{NewMarker}}
* [[Main_Page-sp|Español (Spanish)]] {{NewMarker}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微格式 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])

hatom-issues

2006-05-20T19:55:06Z

ChrisCasciano: /* Other Questions and Issues - multiple feeds */

__TOC__

= hAtom 0.2 =

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

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

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

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

== 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: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?
# What changes need to be made to the spec to make the publishing of multiple feeds in a document less ambiguous?
# 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)

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

transit-table-examples

2006-05-09T04:17:41Z

ChrisCasciano: /* Examples */

= Transit Table Examples =

== Authors ==

* Tantek Çelik

== Acknowledgment ==

Thanks to Kevin Marks for suggesting this need for a microformat on the microformats-discuss list (needslink) and providing the Caltrain example.

== Problem Statement ==

Problem: how to markup transit tables for trains / light-rail etc. in such a way that aggregation and navigation of schedules across varying transit systems becomes possible.

== Examples ==

=== Caltrain ===

http://caltrain.com/timetable_effective_10_10_05.html

=== TTC (Subways, Buses, Light and Electric Rail) ===

Interface:
http://www.toronto.ca/ttc/schedules/index.htm

Note the horrifying frame and pulldown based interface.

Schedule page:
http://www.toronto.ca/ttc/schedules/61S.htm#AVENUE%20RD.%20at%20WILSON

=== Air Canada (Airline) ===

http://www.aircanada.com/aco/flights.do

This is fairly typical of many airlines -- a form-based query is needed to get to the interesting stuff.

=== Go Transit (Trains and Buses) ===

Interface:
http://www.gotransit.com/PUBLICROOT/NewVersion/lstNser.asp

Schedule page:
http://www.gotransit.com/PUBLICROOT/NewVersion/pubnsch.asp?table=01&direction=0&day=1&page=1

=== New Jersey Transit ===

Rail Schedule Interface (results include transfer info + rates):
http://www.njtransit.com/sf_tr_schedules.shtml

Bus Schedules:
http://www.njtransit.com/sf_bu_town2town.jsp?Center=Town

=== MTA (NYC) subways, trains, buses ===
http://www.mta.nyc.ny.us/

LIRR Train Interface:
http://lirr42.mta.info/index.asp

Metro North Train Interface (includes peak/offpeak info, travel durations)
http://as0.mta.info/mnr/schedules/sched_form.cfm

== Future Thoughts ==

This probably belongs more in a transit-table-brainstorming page, but until more examples are fleshed out and previous formats are researched, we're sticking future thoughts here.

=== Tufte Transit Graph ===

An application that read a standard transit-table microformat and produced a Tuftesque timeline grid would be very nice for transit users.

Main Page

2006-04-26T13:07:25Z

ChrisCasciano: resaving to last good version to clean up spam

__NOTOC__
__NOTOC__
= Microformats Wiki =

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]], [[presentations]], and [[podcasts]] are also a good place for some background reading as well. Frequently asked questions are answered in the [[faq]]. Want something or want to contribute? Help with things [[to-do]].

One popular definition from our [http://microformats.org/discuss/ mailing list] is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]]
* [[geo|geo]]
* [[hatom|hAtom]] {{NewMarker}}
* [[hresume|hResume]] {{NewMarker}}
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk|xFolk]]
* [[rel-home]] {{NewMarker}}

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[abbr-design-pattern]]
* [[class-design-pattern]]
* [[datetime-design-pattern]]
* [[existing-classes|class names defined across all microformats]]
* [[include-pattern]] {{NewMarker}}
* [[rel-design-pattern]]

== Exploratory discussions ==
Research and analysis of real-world [[examples]], existing formats, and brainstorming to motivate the microformat.
*[[attention]]
*[[blog-description-examples]]
*[[blog-info-examples]]
*[[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]] (yields [[hatom|hAtom]])
*[[book-examples]], [[book-formats]], [[book-brainstorming]]
*[[chat-examples]], [[chat-formats]]
*[[citation|citation microformat overview]], [[citation-examples]], [[citation-formats]], [[citation-brainstorming]]
*[[comment-problem]], [[comment-examples]], (need to extract from [[comments-formats]])
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[distributed-conversation]], [[distributed-conversation-brainstorming]], [[distributed-conversation-examples]], [[distributed-conversation-formats]]
*[[forms-examples]]
*[[genealogy-formats]]
*[[hash-examples]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[hlisting-proposal]], [[hlisting-feedback]] {{NewMarker}}
**[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-info-examples]]
*[[mfo-examples]]
*[[music-examples]]
*[[other-formats]]
*[[photo-note-examples]]
*[[recipe-examples]]
*[[requirements-testing]], [[requirements-testing-examples]]
*[[rest-examples]]
*[[resume-brainstorming]], [[resume-formats]]
*[[review-examples]], [[review-formats]] (yielded the [[hreview|hReview]] draft)
*[[search-results-example]]
*[[show-brainstorming]]
*[[showroll-brainstorming]]
*[[table-examples]]
*[[tagspeak-examples]]
*[[transit-table-examples]]
*[[uid]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[work-of-art]] {{NewMarker}}
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[[vcard-implementations]], [[vcard-errata]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]
*[[why-are-content-standards-hard]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[events]] {{NewMarker}}
* [[to-do]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different</del> other languages

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]]
* [[Main_Page-jp|日本語 (Japanese)]] {{NewMarker}}
* [[Main_Page-sp|Español (Spanish)]] {{NewMarker}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微格式 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])

User:ChrisCasciano

2006-04-03T15:30:29Z

ChrisCasciano: /* Chris Casciano - updated links */

== Chris Casciano ==

Freelance web developer... often on irc as pnhChris

=== Projects ===

* Textpattern Microformat Plugin - [http://placenamehere.com/TXP/pnh_mf/ pnh_mf].
* [http://placenamehere.com/mf/netnewswire/ Subscibe To hAtom] script for NetNewsWire
* [http://placenamehere.com/mf/ other random mf stuff]

=== Sites ===

* [http://placenamehere.com placenamehere.com]
* [http://chunkysoup.net ChunkySoup.net]

hatom-issues

2006-04-03T14:19:41Z

ChrisCasciano: /* Feed <i>permalink</i> (atom:<i>permalink</i>) */

__TOC__

= hAtom 0.2 =

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

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

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

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

== 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>entry-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
** the first <code><h#></code> element in the Feed, or
** 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.

== 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 the Feed is invalid hAtom

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
* if a Feed has no Feed author each Entry MUST have at least one Entry Author element
* an Entry MAY have more than one Entry Author elements

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

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

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

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

hatom-issues

2006-04-01T13:59:38Z

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

__TOC__

= hAtom 0.2 =

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

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

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

== 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>entry-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
** the first <code><h#></code> element in the Feed, or
** 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.

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

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

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

hatom

2006-03-28T13:35:58Z

ChrisCasciano: /* Implementations - netnewswire script */

<h1> hAtom 0.1 </h1>

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the [http://www.atomenabled.org/ Atom] syndication format. hAtom is one of several [[microformats]] open standards.

__TOC__
== Draft Specification ==

=== Editor/Author ===
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc.]

=== Contributors ===
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]

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

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

== Introduction ==

hAtom is a [[microformat]] for identifying semantic information in weblog posts and practically any other place [http://www.atomenabled.org/ Atom] may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions.

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

== Format ==
=== In General ===
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:

* Atom provides a lot more functionality that we need for a "blog post" microformat, so we've taken the minimal number of elements needed.
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "bridging the gap"

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, '<code>h</code>') on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]].

The hAtom schema consists of the following:

* hfeed ('''<code>hfeed</code>'''). optional.
* hentry ('''<code>hentry</code>''').
** '''<code>entry-title</code>'''. required. text.
** '''<code>entry-content</code>'''. required. text.
** '''<code>entry-summary</code>'''. optional. text.
** '''<code>updated</code>'''. required using [[datetime-design-pattern]].
** '''<code>published</code>'''. optional using [[datetime-design-pattern]].
** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''.
** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.
** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.

Some required elements have defaults if missing, see below.

=== Field and Element Details ===

===== Feed =====
* a Feed element is identified by the class name <code>hfeed</code>
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 Atom feed]
* the Feed element is optional and, if missing, is assumed to be the page
* hAtom documents MAY have multiple Feed elements

===== Feed Category =====
* a Feed Category element is identified by [[rel-tag]]
* a Feed MAY have a Feed Category
* a Feed Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside a [http://www.atomenabled.org/developers/syndication/#optionalFeedElements feed]
* Feed Category elements MUST appear inside a Feed element but not inside an Entry element
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry =====
* an Entry element is identified by class name <code>hentry</code>
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom entry]
* any microformat content inside a <code><blockquote></code> or <code><q></code> element within the Entry is should not be considered part of the Entry.
: ''This allows quoting other microformated data without worry of corrupting the model''

===== Entry Category =====
* an Entry Category element is identified by [[rel-tag]]
* an Entry MAY have an Entry Category
* an Entry Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside an [http://www.atomenabled.org/developers/syndication/#optionalEntryElements entry]
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry Title =====
* an Entry Title element is identified by the class name <code>entry-title</code>
* an Entry SHOULD have an Entry Title
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 Atom entry title]
* if the Entry Title is missing, use
** the first <code><h#></code> element in the Entry, or
** the <code><title></code> of the page, if there is no enclosing Feed element, or
** assume it is the empty string

===== Entry Content =====
* an Entry Content element is identified by class name <code>entry-content</code>
* an Entry SHOULD have Entry Content
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]
* an Entry MAY have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
: ''Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.''
* if the Entry Content is missing, assume it is the empty string

===== Entry Summary =====
* an Entry Summary element is identified by class name <code>entry-summary</code>
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 Atom summary]
* an Entry MAY have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry

===== Entry Permalink =====
* an Entry Permalink element is identified by [[rel-bookmark]]
* an Entry SHOULD have an Entry Permalink
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 Atom link in an entry]
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries

===== Entry Updated =====
* an Entry Updated element is identified by class name <code>updated</code>
* an Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 Atom updated]
* an Entry SHOULD have an Entry Updated element
* use the [[datetime-design-pattern]] to encode the updated datetime
* if there is no Entry Updated element,
** use the Entry Published element, if present
** otherwise the page is invalid hAtom

===== Entry Published =====
* an Entry Published element is identified by the class name <code>published</code>
* an Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 Atom published]
* use the [[datetime-design-pattern]] to encode the published datetime

===== Entry Author =====
* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 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
* an Entry SHOULD have at least one Entry Author element
* an Entry MAY have more than one Entry Author elements
* if the Entry 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 the entry is invalid hAtom

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>
<dt>hfeed</dt>
<dd>
The concept of atom:feed from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>hentry</dt>
<dd>
The concept of atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-title</dt>
<dd>
The concept of atom:title inside of an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-content</dt>
<dd>
The concept of atom:content from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-summary</dt>
<dd>
The concept of atom:summary from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>bookmark</dt>
<dd>
The concept of atom:link (without any "rel") with an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>published</dt>
<dd>
The concept of atom:published from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>updated</dt>
<dd>
The concept of atom:updatedfrom
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>author</dt>
<dd>
The concept of atom:author from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
</dl>
</dd>
</dl>
</pre>

== Examples ==

See [[hatom-examples]].

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

=== 0.1 hAtom implementations ===

* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site -- by [[User:ChrisCasciano|Chris Casciano]]
* [http://sedna.spip.org/sedna/ Sedna RSS] (a feed aggregator based on SPIP, by Fil, IZO and others; GPLd sources are available at [http://zone.spip.org/trac/spip-zone/browser/_squelettes_/sedna SPIP-Zone])

=== Pre 0.1 hAtom implementations ===
These pages conform to an older draft standard and need to be updated.

* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)
* [http://rbach.priv.at/hAtom2Atom/Changelog/ hAtom2Atom.xsl’s Changelog] is published as hAtom and Atom.

== Implementations ==

This section is '''informative'''.

* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)
* There is now an [http://www.lukearno.com/projects/hatom2atom/ hatom2atom proxy] that uses hAtom2Atom.xsl.
* [http://placenamehere.com/article/185/SubscribingTohAtomFeedsWithNetNewsWire Subscribe To hAtom] is a script that provides [http://ranchero.com/netnewswire/ NetNewsWire 2.x] users with the ability to subscribe to hAtom documents as they would any other feed. by [[User:ChrisCasciano|Chris Casciano]].

These pages are awaiting updating to 0.1:

* the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser]
* the [http://www.blogmatrix.com/tools/rewrite/ hAtom Template Rewriter] converts Blogger, MovableType and Wordpress templates into hAtom compatible ones -- (hopefully) without presentation impact

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.atomenabled.org/ Atom]
* [[hcard-parsing]]

=== Informative References ===

==== Specifications That Use hAtom ====

==== Similar Work ====

* [http://rdfs.org/sioc/ Semantically-Interlinked Online Communities (SIOC) RDF Ontology]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:

* [[blog-post-brainstorming|blog-post Brainstorming]]

=== Version 0.1 ===

Version 0.1 was released 28 February 2006.

== Discussions ==

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

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

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

==See Also==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-hints|hAtom Hints]] - help for implementors
* [[hatom-issues]] - problems? complaints? ideas? Put them here
* [[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)

hatom-issues

2006-03-24T17:21:28Z

ChrisCasciano: /* author as an hcard is too much to require */

= hAtom 0.2 =

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

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

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

== 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]

* [[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 Mouédine beatrice.mouedine@@tvagri.com"

* [[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

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

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

hcard

2006-03-23T23:09:20Z

ChrisCasciano: /* Examples in the wild */

<h1>hCard</h1>

hCard is a simple, open, distributed contact information format for people, companies, and organizations, which is suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. hCard is a 1:1 representation of the vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) in XHTML, one of several open [[microformats|microformat]] standards.

Want to get started with writing an [[hcard|hCard]]? Use the [http://microformats.org/code/hcard/creator hCard creator] to write up some contact information and publish it.

__TOC__

== Draft Specification ==

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

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

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

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

=== Inspiration and Acknowledgments ===
Thanks to: my good friend [http://vadim.com/ Vadim] who introduced me to vCard ''many'' years ago, and if I'd only paid more attention then, perhaps I could have helped a lot of people avoid wasting a lot of time reinventing various standards wheels.

== Introduction ==
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]), has been broadly interoperably implemented (e.g. Apple's "Address Book" application built into MacOSX).

In addition, many bloggers identify themselves by name and discuss their friends and family. With just a tad bit of structure, bloggers can discuss people in their blog(s) in such a way that spiders and other aggregators can retrieve this information, automatically convert them to vCards, and use them in any vCard application or service.

This specification introduces the '''hCard''' format, which is a 1:1 representation of the aforementioned vCard standard, in semantic XHTML. Bloggers can both embed vCards directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCard enables applications to retrieve information about such vCards directly from web pages without having to reference a separate file.

Use the [http://microformats.org/code/hcard/creator hCard creator], copy the HTML code it generates to your blog or website to publish your contact info.

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

== Format ==
=== In General ===
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) forms the basis of hCard.

The basic format of hCard is to use vCard object/property names in lower-case for class names, and to map the nesting of vCard objects directly into nested XHTML elements.

=== More Semantic Equivalents ===
However, for some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:
* <code>URL</code> in vCard becomes <code><a class="url" href="...">...</a></code> inside the element with <code>class="vcard"</code> in hCard.
* Similarly, <code>EMAIL</code> in vCard becomes <code><nowiki><a class="email" href="mailto:...">...</a></nowiki></code>
* <code>PHOTO</code> in vCard becomes <code><img class="photo" src="..." alt="Photo of ..." /></code>

=== Singular vs. Multivalued Properties ===

For properties which are singular (e.g. "N" and "FN"), the first descendant element with that class should take effect, any others being ignored.

For properties which can be plural (e.g. "TEL"), each class instance should create a instance of that property.

==== Plural Properties Singularized ====

Since plural property names become their singular equivalents, even if the original plural property permitted only a single value with multiple components, those multiple components are represented each with their own singularly named property and the the property is effectively multivalued and subject to the above treatment of multivalued properties.

=== Human vs. Machine readable ===

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

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

=== Value excerpting ===

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 "<code>value</code>" is introduced to excerpt out the subset of the element that is the value of the property. E.g. here is an hCard fragment for marking up a home phone number:

<pre><nowiki>
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>

This hCard fragment could be displayed as:

home: +1.415.555.1212

=== Property Exceptions ===

vCard has several properties which either do not make sense on, or are already implied within the context of a web page. This section explains what to (not) do with them.

# '''NAME''', '''PROFILE''', '''SOURCE''', '''PRODID''', '''VERSION''' properties as defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of RFC 2426. Content publishers MUST NOT use these properties in their hCards, and as such, hCard consumers/parsers MUST IGNORE these properties if they are found within an hCard. Instead. hCard to vCard converters SHOULD use the title of the page where the hCard is found (e.g. the <code><title></code> element in (X)HTML documents) to construct the NAME property, MAY output a PROFILE value of "<code>VCARD</code>" per RFC 2426, SHOULD use the URL of the page where the hCard is found to construct the SOURCE property (e.g. perhaps as a parameter to a URL/service that converts hCards to vCards), for an output vCard stream (e.g. a .vcf file). Only services/applications that output actual vCards should write the PRODID property, with the product identifier for said service/application. Similarly only such services/applications should write the VERSION property, with the value "3.0" (without quotes) per RFC2426 Section 3.6.9.

=== Organization Contact Info ===

If the "FN" and "ORG" properties have the exact same value (typically because they are set on the same element, e.g. class="fn org"), then the hCard represents contact information for a company or organization and should be treated as such. In this case the author MUST also NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "". Thus parsers should handle the missing "N" property in this case by implying empty values for all the "N" sub-properties.

=== Implied "n" Optimization ===

Although vCard requires that the "N" property be present, the authors of the vCard specification (RFC 2426) themselves do not include "N" properties in their vCards near the end of the spec (p.38). This apparent contradiction can be resolved by simply allowing the "FN" property to imply "N" property values in typical cases provided in the spec. We do so explicitly in hCard.

If "FN" and "ORG" are not the same (see previous section), and the value of the "FN" property is exactly two words (separated by whitespace), and there is no explicit "N" property, then the "N" property is inferred from the "FN" property. For "FN"s with either one word see below, and for three or more, the author MUST explicitly markup the "N", except for the organization contact info case, [http://microformats.org/wiki/hcard#Organization_Contact_Info see above] for that.

# The content of "FN" is broken into two "words" separated by whitespace.
# The ''first'' word of the "FN" is interpreted as the "given-name" for the "N" property.
# The ''second/last'' word of the "FN" is interpreted as the "family-name" for the "N" property.
# Exception: If the first word ends in a "," comma OR if the second word is a single character (optionally followed by a period "."), then the first word (minus the comma at the end if any) is interpreted as the "family-name" and the second word is interpreted as the "given-name".

This allows simplification in the typical case of people stating:
* given-name (space) family-name
* family-name (comma) given-name
* family-name (comma) given-name-first-initial
* family-name (space) given-name-first-initial (optional period)

=== Implied "nickname" Optimization ===

Due to the prevalence of the use of nicknames/handles/usernames on the Web in actual content published on the Web (e.g. authors of [[hReview|reviews]]), hCard also has an implied "nickname" optimization to handle this.

Similar to the implied "n" optimization, if "FN" and "ORG" are not the same, and the value of the "FN" property is exactly one word, and there is no explicit "N" property, then:

# The content of the "FN" is treated as a "nickname" property value.
# Parsers should handle the missing "N" property by implying empty values for all the "N" sub-properties.

Note: the hCard may have additional explicit "nickname" property values in addition to the implied nickname.

=== Implied "organization-name" Optimization ===

The "ORG" property has two subproperties, organization-name and organization-unit. Very often authors only publish the organization-name. Thus if an "ORG" property has no "organization-name" inside it, then its entire contents MUST be treated as the "organization-name".

=== Root Class Name ===

The root class name for an hCard is "vcard".

=== Property List ===

This is the list of properties (and subproperties, in parantheses, like this) in hCard, taken from vCard:

* fn, n (family-name, given-name, additional-name, honorific-prefix, honorific-suffix), nickname, sort-string
* url, email (type, value), tel (type, value)
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
* geo (latitude, longitude), tz
* photo, logo, sound, bday
* title, role, org (organization-name, organization-unit)
* category, note
* class, key, mailer, uid, rev
==== type subproperty values ====

The 'type' subproperty in particular takes different values depending on which property it is a subproperty of. These 'type' subproperty values are case-INSENSITIVE, meaning "Home" is the same as "home", as well as multivalued, e.g. a tel can be home and preferred:
<pre><nowiki>
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>

The following lists are ''informative''. See RFC2426 sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values. They are repeated here for convenience. Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, car, isdn, pcs
* email type: INTERNET, x400, pref, "other IANA registered address types"

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

== Examples ==

This section is informative.

=== Sample vCard ===

Here is a sample vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com
ORG:Technorati
END:VCARD
</nowiki></pre>

and an equivalent in hCard with various elements optimized appropriately. See [[hcard-example1-steps| hCard Example 1]] for the derivation.

<pre><nowiki>
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
<div class="org">Technorati</div>
</div>
</nowiki></pre>

This hCard might be displayed as:

[http://tantek.com/ Tantek Çelik]<br />
Technorati

Note: The version information is unnecessary in hCard markup directly since the version will be defined by the profile of hCard that is used/referred to in the 'profile' attribute of the <head> element.

=== More Examples ===

See [[hcard-examples]] for more examples, including all examples from vCard RFC 2426 converted into hCard.

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

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

=== New Examples ===
Please add new examples to this section.

* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site -- by [[User:ChrisCasciano|Chris Casciano]]
* [http://www.30boxes.com/ 30 Boxes],a social calendar application and digital lifestyle aggregator, automatically creates an hcard for you with your account. It is found under Settings > Syndication.
* [http://www.nearwhere.com/ Nearwhere.com] allow you to put an hcard on an interactive map.
* [http://www.brentozar.com/ Brent Ozar] added a [http://www.brentozar.com/contact.php contact] page hCard.
* [http://www.kerihenare.com/ Keri Henare] has rewritten his [http://www.kerihenare.com/contact/ contact] page hCard.
* [http://michaelraichelson.com/contact/ Michael Raichelson] had an hCard on his contact page before SXSW, but never thought to add it here until Tantek requested it.
* [http://www.commoner.com/~lsimon/lindsey_simon_hcard.html Lindsey Simon] has added an hCard to his website as per Tantek's SXSW request for folks to try it
* [http://www.davidgagne.net/ David Gagne] has an hCard in his sidebar.
* [http://www.churchzip.com/map/ Churchzip.com/map] and [http://www.skiwhere.com/map/ Skiwhere.com/map], provide churches, hotels, and ski resorts on the same maps. Locations are formatted as hcards.
* All [http://www.iqdir.com/ IQ Directory Solutions] Yellow Pages web portals use [[hcard|hCard]] markup on listings. For example [http://www.yellowpages-cambodia.com/ Cambodia Yellow Pages] and [http://www.superpages.com.my/ Malaysia Super Pages]
* Ning's cloneable Group app uses fuzzy matching to map custom fields to [[hcard|hCard]] markup on its [http://group.ning.com/index.php?controller=person&action=view&content=JonathanAquino profile] pages.
* [http://claimid.com/factoryjoe Chris Messina' ClaimID hCard]
* [http://factoryjoe.com/blog/hcard Chris Messina' hCard]
* [http://flock.com/about Flock About]
* [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]).
* [http://www.gr0w.com/articles/press/growsearch_launched_press_release/ GrowSearch Launched (Press Release)] uses an hCard to provide Press Contact Point.
* The [http://www.arborday.org/ National Arbor Day Foundation] has started using hCards for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].
* [http://www.multipack.co.uk The Multipack] has numerous hCards, especially on the [http://www.multipack.co.uk/members/ members page], as well as the next meeting information.
* [http://deadringrancor.livejournal.com/ Justin McDowell] used an hCard when [http://deadringrancor.livejournal.com/221332.html referring to a person in his blog post]
* [http://davecardwell.co.uk/cv/ Dave Cardwell] has included his hCard in his Curriculum Vitae.
* [http://blog.usweb.com/ Shaun Shull] has written a great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect SEO], and has included his [[hcard|hCard]] as one of the examples.
* [http://www.thefutureoftheweb.com/ Jesse Skinner] has written a simple [http://www.thefutureoftheweb.com/blog/2006/1/hcard tutorial with examples]
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the venue, contacts, and program committee members all with hCard.
* [http://www.avf-nexus.co.uk AVF-Nexus] have a hCard on their [http://www.avf-nexus.co.uk/contact/ contact page] - (by [http://creation.uk.com Creation"])
* [http://www.thefantasticos.com/andrew/ Andrew White] posted [http://www.thefantasticos.com/andrew/index.php/my-hcard/ his hCard] and [http://www.thefantasticos.com/andrew/index.php/62/microformats-the-should-have-been-obvious-web-dev-tool/ blogged about it].
* [http://www.2sheds.ru Oleg "2sheds" Kourapov] in his [http://www.2sheds.ru/blog/ blog] ([http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://www.2sheds.ru/blog X2V]) has turned personal profile into hCard ([http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://www.2sheds.ru/blog/hcard.html X2V]) and his blogroll - into combination XFN/hCards ([http://suda.co.uk/projects/X2V/get-vcard.php?uri=http://www.2sheds.ru/blog/friends.html X2V])
* [http://www.approveddesign.co.uk Approved Design Consultancy] have a hCard on their [http://www.approveddesign.co.uk/about/contact/ contact page] as well as on their [http://www.approveddesign.co.uk/about/people/ people section] - (by [http://creation.uk.com Creation"])
* [http://weblog.200ok.com.au/ Ben Buchanan] and [http://www.griffith.edu.au/cgi-bin/phone_search.pl?string=colin+morris&format=search Colin Morris] have [http://weblog.200ok.com.au/2006/01/griffith-phonebook-adds-hcard-and.html implemented hCards and vCards] for the [http://www.griffith.edu.au Griffith University] [http://www.griffith.edu.au/find/content_phonebook.html online phone book]. Eg. [http://www.griffith.edu.au/cgi-bin/phone_search.pl?string=ben+buchanan&format=search Ben's vCard] and [http://www.griffith.edu.au/cgi-bin/phone_search.pl?string=colin+morris&format=search Colin's vCard]
* WWF-Australia [http://wwf.org.au/about/contactdetails/ contact details page]
* [http://rasterweb.net/raster/ Pete Prodoehl] used the hCard format on his [http://rasterweb.net/raster/contact.html Contact page]
* [http://alexander-mette.de amette] uses the hCard format in a module of his TikiWiki powered blog
* [http://staff.washington.edu/oren/weblog2/ Oren Sreebny] has an hcard on his blog main index template
* [http://www.cs.brandeis.edu/~zippy/ Patrick Tufts] has an hCard on his homepage.
* [http://ascii20.blogspot.com/ Mathias Kolehmainen and Jamie Taylor] have hCards on their weblog.
* [http://www.hoppsan.org/jamesb/blogger/ Barnaby James] has a hCard on his weblog.
* [http://esa-education.com/schools/map ESA Education] Uses hCards for their 100+ schools and each of the individual school sites.
* [http://www.thereisnocat.com/#vcard Ralph Brandi] has added an hCard to the sidebar of his weblog as a result of Tantek Çelik's portion of the Microformats presentation at SXSW 2006.
* [http://www.yellowpencil.com/contact/ Yellow Pencil] Using microformats to present company contact information

=== Examples ===
* [http://thoughtport.blogspot.com/ Aiden Kenny] hasn't published his hCard yet, but he has [http://thoughtport.blogspot.com/2005/07/elemental-particles-of-web.html published his hCard icon]: http://photos1.blogger.com/blogger/4224/444/320/AK-Hcard-icon.gif
* [http://thedredge.org Andy Hume] uses the hcard format to mark-up the names and URLs of commentors on his blog.
* [http://www.bidclix.com/ BidClix]'s [http://www.bidclix.com/AboutContact.html Contact BidClix] page has it's ''contact info'' marked up with an hCard.
* [http://suda.co.uk/ Brian Suda] has managed to embed a photo in [http://suda.co.uk/contact/ his hCard] through the [http://www.ietf.org/rfc/rfc2397.txt data uri scheme] by converting the image to BASE64 code. View the Source to see how this is accomplished. [http://suda.co.uk/projects/X2V/get-vcard.php?uri=http%3A//suda.co.uk/contact/ The X2V link] will extract the image and encode it for a vCard which will be displayed in some address book applications.
* [http://cinematreasures.org Cinema Treasures] uses hCard to markup venue information for 10,000+ movie theaters.
* [http://www.w3.org/People/Connolly/events/ Dan Connolly's index of events and talks] has hCards for many of the people he has met at those events. In Mar 2006, he moved a bunch of hotel contact info from his PDA to this page; it's now up to 32 hCards.
* [http://doncrowley.blogspot.com/ Don Crowley] has published [http://www.crowley.nl/hcard.html his hCard] as well as a nifty hCard button: http://www.crowley.nl/images/hcard.png
* [http://loadaveragezero.com/hnav/contact.php Douglas W. Clifton] added all types of contact information
* [http://eventful.com Eventful] publishes all of its venue information pages with embedded hCards.
* [http://www.iowamilitaryveteransband.com/members/ Iowa Military Veterans Band Contacts] - 95 hCards [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ marked up by Scott Reynen]
* [http://JackWolfgang.blogspot.com Jack L. Wolfgang II] has [http://jack.randomata.com/resume/ converted the addresses in his resume to hCards].
* [http://www.efas.fupl.asso.fr/efas/_Mathieu-Drouet_.html Mathieu Drouet] and [http://www.efas.fupl.asso.fr/efas/_Annie-Leger_.html Annie Leger] both have hCards
* [http://www.ndunn.com Neil Dunn] has published his rather [http://www.ndunn.com/2005/10/7/hCard good looking hCard]
* [http://www.oliverbrown.me.uk/ Oliver Brown] has published his hCard.
* [http://www.paradigmproductions.org/contact/ Paradigm Productions] published a vcard as a ul (marked up by [http://www.linkingarts.com/ Peter Jacobson])
* [http://www.splintered.co.uk/ Patrick H. Lauke] has marked up [http://www.splintered.co.uk/about/ his contact info with hCard].
* [http://blah Paul Schreiber has published his hCard on [http://paulschreiber.com/about/?contact his about page].
* [http://paulschreiber.com/blog/ Paul Schreiber]'s [http://concerts.shrub.ca/ Sunnyvale House Concerts] site publishes hCards for upcoming artists, as well as an hCard for the page itself. In addition the [http://concerts.shrub.ca/shows Past Shows] page contains hCards for all past artists.
* [http://www.paulmichaelsmith.com/blog/hcard.htm Paul Smith] has created an hCard page which is Human Readable, and a link to X2V passing the same hCard page to generate a vCard.
* [http://www.windley.com/archives/2005/07/hcards_trying_o.shtml Phil Windley has published] [http://phil.windley.org/hcard.html his hCard].
* [http://www.go-curiosity.com/about.htm Piercarlo Slavazza] has published an hCard.
* [http://zooibaai.nl/ Rob Mientjes] has published his hCard on [http://zooibaai.nl/about/ his about page].
* [http://rbach.priv.at/Contact Robert Bachmann] has published his hCard and [http://rbach.priv.at/Images/hcard a button].
* [http://blah Scott Reynen has published his hCard on [http://www.randomchaos.com/document.php?source=scott_reynen his profile page].
* [http://www.stackframe.com/ StackFrame, LLC] has published [http://www.stackframe.com/people/ employee] and [http://www.stackframe.com/contact/ general] contact information as hCards.
* [http://www.wolfsreign.com Steven Ametjan] has published his hCard on [http://www.wolfsreign.com/about/ his about page].
* [http://tantek.com/microformats/2005/syndicate/speakers-list.html Syndicate - Speaker List] as a set of hCards
* [http://tagcamp.org/index.cgi?ContactList TagCamp contact list]
* [http://tantek.com/log Tantek's Thoughts] includes an inline author hCard at the bottom of the page.
* [http://technorati.com/ Technorati]'s [http://www.technorati.com/about/ About page] lists their '''Media Contact'''
* [http://www.deadringerart.com/ The Brothers McDowell] have hCards at their Contact page.
* [http://twinsparc.com/ Twinsparc] put an hCard in the header and footer of all their pages.
* [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 Conference speakers page marked up with hCard]
* [http://we05.com/ Web Essentials 05] marked up all their [http://we05.com/presenters.cfm presenters with hCard].

=== Examples with some problems ===
* [http://gbraad.nl/ Gerard Braad] has published an example on his [http://gbraad.nl/site/?p=profile profile] page that is almost consistent with his original [http://gbraad.nl/files/gbraad.vcf vCard] file. Also progress is made for transforming his [http://files.gbraad.nl/foaf.rdf FoaF] file to a hCard encoded representation. (also done for my spouse:[http://spouse.gbraad.nl/site/?p=profile Yong Yuan])
** (2005-09-27) PASSED, PASSED
** WARNINGS
*** uses 'n given-name' and 'n family-name' instead of nesting the given- and family- names inside the 'n'
*** has one 'tel' value with a bunch of values stuffed in
*** probably more problems --[[User:RyanKing|RyanKing]] 17:19, 5 Jan 2006 (PST)
* [http://kinrowan.net/ Cori Schlegel] [http://kinrowan.net/blog/wp/archives/2005/07/08/a-problem-with-the-structured-blogging-plug-in-for-wordpress/ discusses how he has updated] [http://kinrowan.net/blog/contact his contact page with hCard]
** INVALID - using 'prefix' instead of 'honorific-prefix' and type's in classnames (in both adr and tel) and has two photo's (the second could be 'logo') --[[User:RyanKing|RyanKing]] 15:15, 5 Jan 2006 (PST)
* The good ship [http://styrheim.com/test/leonid.html Leonid Miloslavskiy] spotted in the North Atlantic
** INVALID --[[User:RyanKing|RyanKing]] 00:50, 27 Oct 2005 (PDT)
*** class="family" should probably be family-name
*** the "n" property is missing and the "n" optimization can't be applied
*** the first geo propery is empty, the second one is invalid (ie, it doesn't contain lat/long)
* [http://landsbank.fo/#hCard Landsbanki Føroya]
** INVALID - using embedded rdf/xml invalidly
* [http://chrischerry.name/blog/contact/ Chris Cherry's contact page with his hCard]
** WARNING - uses class="cell" instead of <span class="type">cell</span>
* [http://www.bath.ac.uk/contact/ University of Bath] Person Finder results are encoded with hCards so you can easily create a vCard from any result.
** ERROR - attempt to use Implied-N optimization where that's not possible. --[[User:RyanKing|RyanKing]] 14:29, 5 Jan 2006 (PST)
** Error appears for external users only. Won't be fixed any time soon. -- [[User:PhilWilson|PhilWilson]] 00:03, 28 Jan 2006 (GMT)
* [http://richi.co.uk/blog/2005/12/structured-blogging.html Richi Jennings] has put up his attempt
** INVALID, missing FN --[[User:RyanKing|RyanKing]] 12:47, 5 Jan 2006 (PST)
* [http://www.shiftingpixel.com/about/ shifting pixel photoblog] has published an hCard.
** "organization_name" should be "organization-name" (s/_/-/), otherwise good --[[User:RyanKing|RyanKing]] 14:01, 5 Jan 2006 (PST)

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

The following implementations have been developed which either generate or parse hCards. If you have an hCard 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://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - port of Tails extension for Flock 0.5.12 that looks for hCards, hCalendar, xFolk and hReview and tosses them into a handy topbar
*[http://opensource.reevoo.com/2006/03/08/release-uformats-12/ uformats] is a ruby library that can parse [[hCalendar]], [[hCard]], [[hReview]] and [[rel-tag]]
* [http://blog.codeeg.com/tails-firefox-extension/ Tails is a Firefox Extension] that will display the presence and details of microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]) on a webpage.
* [http://www.stripytshirt.co.uk/features/firefox/smartzilla Smartzilla is a Firefox Extension] that finds hCards on web pages and lets you add them to your addressbook.
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding hCard and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* There is [http://flickr.com/photos/factoryjoe/68755089/ evidence of built-in hCard support in the Konqueror browser]. Specifically, Konqueror 3.5, in KDE 3.5 (kubuntu Breezy w/ update).
* There is [http://tagcamp.org/index.cgi?ContactList evidence of a kwiki plugin for hCards]. Update: the [http://svn.kwiki.org/cwest/Kwiki-hCard/ hCard kwiki plugin svn repository]. See the [http://microwiki.caseywest.com/index.cgi?hCard documentation of the hCard kwiki plugin].
* [http://suda.co.uk/projects/X2V/ X2V] is a bookmarklet that parses hCard and produces a .vcf (vCard) stream. Note: needs to be updated as the spec is refined
* [http://www.stripytshirt.co.uk Duncan Walker] has built [http://www.stripytshirt.co.uk/features/firefox/smartzilla a Firefox extension] that gets hCard data from a webpage, uses Brian Suda's XSL (locally) to transform it to vcard format and opens the resulting .vcf file.
* [http://george.hotelling.net/90percent/ George] has written a [http://george.hotelling.net/90percent/geekery/greasemonkey_and_microformats.php Greasemonkey user script] that detects hCards and allows users to easily add them to their address book application. Relies on the X2V web service to do the conversion.
* [http://blogmatrix.blogmatrix.com/ David Janes] has written a [[Greasemonkey]] [http://www.blogmatrix.com/include/microformat-find.user.js script] that finds many microformat elements, including hCards, and [http://blog.davidjanes.com/mtarchives/2005_08.html#003376 provides a popup menu of actions]. The hCard to vCard conversion is done internally within the script. ''This does not work with FireFox 1.5+/GreaseMonkey 0.6.4+.''
* [http://diveintomark.org/ Mark Pilgrim] has also written an [http://diveintomark.org/projects/greasemonkey/hcard/ hCard parser Greasemonkey user script]. It is self-contained and does not rely on the X2V web service.
* [http://www.oliverbrown.me.uk/2005/09/03/a-working-microformats-extension-to-simplexml/ Oliver Brown] has written an "extension" to [http://www.php.net/simplexml SimpleXML] that gives simple access to hCard information in PHP 5.
* [http://thedredge.org/ Andrew D. Hume] has built a system (Wordpress plugin?) for [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hcards in your blog] to represent people leaving comments on blog posts.
* The [http://tantek.com/microformats/hcard-creator.html hCard creator] is a very simple, yet illustrative, open source user interface / form / script which creates an hCard in real-time as you type in a set of contact information.
* [http://greenbytes.de/tech/webdav/rfc2629.xslt rfc2629.xslt] now attempts to generate hCard information ([http://ietf.org/rfc/rfc2629 RFC2629] is an XML format for authoring RFCs and Internet Drafts, see [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html example document])
* [http://tantek.com/microformats/buddylist2hcards.html iChat buddy list to hCards] - Open source AppleScript to automatically convert one's buddy list in the MacOSX iChat AIM client into a valid XHTML 1.0 Strict list of hCards.
* [http://dev.w3.org/cvsweb/2001/palmagent/ palmagent] is a collection of palmpilot and sidekick tools. It includes X2V derivatives xhtml2hcard.xsl and toICal.xsl plus some [http://dev.w3.org/cvsweb/2001/palmagent/hcardTest.html hcardTest] materials
* [http://www.openpsa.org/ OpenPsa 2.x] CRM application uses hCard for all person listings. The widget is [http://www.midgard-project.org/midcom-permalink-922834501b71daad856f35ec593c7a6d reusable across Midgard CMS]
* [http://www.metonymie.com Emiliano Martínez Luque] has written an experimental [http://www.metonymie.com/hCard_extract/app.html hCard finder and structured search application] that finds hCards within a given set of URLs and returns the ones that match the specified search criteria.
* [http://randomchaos.com/microformats/base/ Microformat Base] is an open-source PHP microformat aggregation crawler, currently recognizing hreview, hcalendar, and hcard.

== Additional Applications ==
This section is '''informative'''.

There are numerous potential additional uses and applications for hCards on the Web. The following are merely a few thoughts and possibilities that folks have come up with:

* As an open standard/format for [http://www.gravatar.com/ Gravatars].
* Marking up individual authors of blog posts on a group blog
* Marking up people's names and URLs in a blogroll
* Any reference to people in blog posts (e.g. when citing them, or referencing them, or describing them, by name).
* ...

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]

=== Informative References ===
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 20040930]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 20040910]
* Contributed from http://developers.technorati.com/wiki/hCard.
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]

==== Specifications That Use hCard ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== Similar Work ====
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== Related Pages ==
* [[hcard-faq|hCard FAQ]] - If you have any questions about hCard, check here, and if you don't find answers, add your questions!
* [[hcard-parsing|hCard parsing]] - Normatively details of how to parse hCards.
* [[hcard-issues|hCard issues]] - Please add any issues with the specification to the issues page.
* [[hcard-profile|hCard profile]] - The XMDP profile for hCard

This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

* [[hcard-brainstorming|hCard Brainstorming]] - where we are keeping our brainstorms and other explorations relating to hCard
* [[hcard-tests|hCard tests]] - a wiki page with actual embedded hCards to try parsing.

== Further Reading ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon has a good intro to hCard
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://thedredge.org/ Andrew D. Hume] has written a blog post on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats] which discusses hCard
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect SEO], including his [[hcard|hCard]] as an example.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page] and the [http://technorati.com/tags/hcard hCard tag]

hatom

2006-03-23T23:07:38Z

ChrisCasciano: /* Examples in the wild */

<h1> hAtom 0.1 </h1>

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the [http://www.atomenabled.org/ Atom] syndication format. hAtom is one of several [[microformats]] open standards.

__TOC__
== Draft Specification ==

=== Editor/Author ===
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc.]

=== Contributors ===
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]

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

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

== Introduction ==

hAtom is a [[microformat]] for identifying semantic information in weblog posts and practically any other place [http://www.atomenabled.org/ Atom] may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions.

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

== Format ==
=== In General ===
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:

* Atom provides a lot more functionality that we need for a "blog post" microformat, so we've taken the minimal number of elements needed.
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "bridging the gap"

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, '<code>h</code>') on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]].

The hAtom schema consists of the following:

* hfeed ('''<code>hfeed</code>'''). optional.
* hentry ('''<code>hentry</code>''').
** '''<code>entry-title</code>'''. required. text.
** '''<code>entry-content</code>'''. required. text.
** '''<code>entry-summary</code>'''. optional. text.
** '''<code>updated</code>'''. required using [[datetime-design-pattern]].
** '''<code>published</code>'''. optional using [[datetime-design-pattern]].
** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''.
** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.
** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.

Some required elements have defaults if missing, see below.

=== Field and Element Details ===

===== Feed =====
* a Feed element is identified by the class name <code>hfeed</code>
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 Atom feed]
* the Feed element is optional and, if missing, is assumed to be the page
* hAtom documents MAY have multiple Feed elements

===== Feed Category =====
* a Feed Category element is identified by [[rel-tag]]
* a Feed MAY have a Feed Category
* a Feed Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside a [http://www.atomenabled.org/developers/syndication/#optionalFeedElements feed]
* Feed Category elements MUST appear inside a Feed element but not inside an Entry element
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry =====
* an Entry element is identified by class name <code>hentry</code>
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom entry]
* any microformat content inside a <code><blockquote></code> or <code><q></code> element within the Entry is should not be considered part of the Entry.
: ''This allows quoting other microformated data without worry of corrupting the model''

===== Entry Category =====
* an Entry Category element is identified by [[rel-tag]]
* an Entry MAY have an Entry Category
* an Entry Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside an [http://www.atomenabled.org/developers/syndication/#optionalEntryElements entry]
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry Title =====
* an Entry Title element is identified by the class name <code>entry-title</code>
* an Entry SHOULD have an Entry Title
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 Atom entry title]
* if the Entry Title is missing, use
** the first <code><h#></code> element in the Entry, or
** the <code><title></code> of the page, if there is no enclosing Feed element, or
** assume it is the empty string

===== Entry Content =====
* an Entry Content element is identified by class name <code>entry-content</code>
* an Entry SHOULD have Entry Content
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]
* an Entry MAY have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
: ''Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.''
* if the Entry Content is missing, assume it is the empty string

===== Entry Summary =====
* an Entry Summary element is identified by class name <code>entry-summary</code>
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 Atom summary]
* an Entry MAY have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry

===== Entry Permalink =====
* an Entry Permalink element is identified by [[rel-bookmark]]
* an Entry SHOULD have an Entry Permalink
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 Atom link in an entry]
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries

===== Entry Updated =====
* an Entry Updated element is identified by class name <code>updated</code>
* an Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 Atom updated]
* an Entry SHOULD have an Entry Updated element
* use the [[datetime-design-pattern]] to encode the updated datetime
* if there is no Entry Updated element,
** use the Entry Published element, if present
** otherwise the page is invalid hAtom

===== Entry Published =====
* an Entry Published element is identified by the class name <code>published</code>
* an Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 Atom published]
* use the [[datetime-design-pattern]] to encode the published datetime

===== Entry Author =====
* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 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
* an Entry SHOULD have at least one Entry Author element
* an Entry MAY have more than one Entry Author elements
* if the Entry 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 the entry is invalid hAtom

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>
<dt>hfeed</dt>
<dd>
The concept of atom:feed from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>hentry</dt>
<dd>
The concept of atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-title</dt>
<dd>
The concept of atom:title inside of an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-content</dt>
<dd>
The concept of atom:content from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-summary</dt>
<dd>
The concept of atom:summary from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>bookmark</dt>
<dd>
The concept of atom:link (without any "rel") with an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>published</dt>
<dd>
The concept of atom:published from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>updated</dt>
<dd>
The concept of atom:updatedfrom
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>author</dt>
<dd>
The concept of atom:author from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
</dl>
</dd>
</dl>
</pre>

== Examples ==

See [[hatom-examples]].

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

=== 0.1 hAtom implementations ===

* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site -- by [[User:ChrisCasciano|Chris Casciano]]

=== Pre 0.1 hAtom implementations ===
These pages conform to an older draft standard and need to be updated.

* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)
* [http://sedna.spip.org/sedna/ Sedna RSS] (a feed aggregator based on SPIP, by Fil, IZO and others; GPLd sources are available at [http://zone.spip.org/trac/spip-zone/browser/_squelettes_/sedna SPIP-Zone])
* [http://rbach.priv.at/hAtom2Atom/Changelog/ hAtom2Atom.xsl’s Changelog] is published as hAtom and Atom.

== Implementations ==

This section is '''informative'''.

* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)
* There is now an [http://www.lukearno.com/projects/hatom2atom/ hatom2atom proxy] that uses hAtom2Atom.xsl.

These pages are awaiting updating to 0.1:

* the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser]
* the [http://www.blogmatrix.com/tools/rewrite/ hAtom Template Rewriter] converts Blogger, MovableType and Wordpress templates into hAtom compatible ones -- (hopefully) without presentation impact

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.atomenabled.org/ Atom]
* [[hcard-parsing]]

=== Informative References ===

==== Specifications That Use hAtom ====

==== Similar Work ====

* [http://rdfs.org/sioc/ Semantically-Interlinked Online Communities (SIOC) RDF Ontology]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:

* [[blog-post-brainstorming|blog-post Brainstorming]]

=== Version 0.1 ===

Version 0.1 was released 28 February 2006.

== Discussions ==

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

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

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

==See Also==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-hints|hAtom Hints]] - help for implementors
* [[hatom-issues]] - problems? complaints? ideas? Put them here
* [[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)

hatom-issues

2006-02-16T02:47:10Z

ChrisCasciano: /* Entry Content (atom:content) */

<h1> hAtom issues </h1>

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

=== 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 'headline' '''

=== 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) ==
* <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) ==
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) ==
* <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) ==
* <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?

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</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.

* [[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 is going to make 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.''

hatom-issues

2006-02-15T16:04:23Z

ChrisCasciano: /* Entry Content (atom:content) */

<h1> hAtom issues </h1>

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

=== 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 'headline' '''

=== 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) ==
* <code>content</code> (Atom consistency)
** -1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
* <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
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[Tantek]]
* <code>atom-content</code>
** +0.5 [[Tantek]]
* <code>hcontent</code>

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

== Entry Summary (atom: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)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with "dt" unofficial pattern)
* <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.

== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +½ Paul Bryson, Not as human readable
* <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

== Entry Author (atom:author) ==
* <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?

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</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.

* [[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 is going to make 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.''

hatom-issues

2006-02-13T16:38:21Z

ChrisCasciano: /* Designating the page author */

<h1> hAtom issues </h1>

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

=== 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 'headline' '''

=== 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) ==
* <code>content</code> (Atom consistency)
** -1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion
** -1 Tantek - agreed with Ryan

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

== Entry Summary (atom: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)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with "dt" unofficial pattern)
* <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.

== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +½ Paul Bryson, Not as human readable
* <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

== Entry Author (atom:author) ==
* <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?

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</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.

* [[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 is going to make 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.''

hatom-issues

2006-02-07T22:07:57Z

ChrisCasciano: /* Entry Content (atom:content) */

= hAtom issues =

__TOC__

== Feed (atom:feed)==

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

=== 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 'headline' '''

=== 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) ==
* <code>content</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion

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

== Entry Summary (atom: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)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with "dt" unofficial pattern)
* <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.

== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +½ Paul Bryson, Not as human readable
* <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

== Entry Author (atom:author) ==
* <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?

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</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.

* [[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 is going to make 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)?

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

hatom-issues

2006-02-07T21:57:21Z

ChrisCasciano: /* Entry Summary (atom:summary) */

= hAtom issues =

__TOC__

== Feed (atom:feed)==

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

=== 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 'headline' '''

=== 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) ==
* <code>content</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion

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

== Entry Summary (atom: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)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with "dt" unofficial pattern)
* <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.

== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +½ Paul Bryson, Not as human readable
* <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

== Entry Author (atom:author) ==
* <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?

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</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.

* [[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 is going to make 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)?

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

blog-post-examples

2006-02-07T19:10:41Z

ChrisCasciano: /* Other Stock Examples */

= Blog Post Examples =

This page is for documenting real world examples of what people publish in blog posts, what markup they use, and what implied schemas can be inferred from their behaviors. See also: [[blog-post-formats]], [[blog-post-brainstorming]], [[hatom|hAtom]].

__TOC__

= Introduction =
== Discussion Participants ==

=== Editor ===
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix BlogMatrix, Inc.]

=== Authors ===
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix BlogMatrix, Inc.]
* [[MichalMigurski]]

=== Contributors ===
* [http://rbach.priv.at/ Robert Bachmann]
* [http://tantek.com/ Tantek Çelik]
* [http://maetl.coretxt.net.nz Mark Rickerby]
* [http://bs-markup.de Björn Seibert]

=== Interested Folks ===

= Specific Examples from the Wild =

== EntryGroup ==

=== Entries are within an EntryGroup block ===
All entries are within an enclosing 'div' -- the EntryGroup. This is common with weblog home pages ([http://microformats.org/ example]) or archive with multiple entries.

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

<div class="entry">
<h3 id="post-59">
<a href="http://www.microformats.org/blog/2005/...">Web Essentials Audio</a>
</h3>
...
</div>

<div class="entry">
<h3 id="post-57">
<a href="http://www.microformats.org/blog/2005/...">WebZine FollowUp</a>
</h3>
...
</div>
</div>
</nowiki></pre>

Note also the header at the top explaining what this feed is. We may want to exploit this also.

=== Entries are within an explicit EntryGroup ===
There are multiple entries on a single page but there is no explicit block element for the entries themselves -- though of course, there is at least one block that has the entries: <code><body></code>. This is also a common use case for weblogs and archives also.

=== Multiple EntryGroups on a page ===
There may be multiple groups of entries on a single page that are tenously connected ([http://news.google.ca/nwshp?hl=en&tab=wn&q= example-2]). Also, many weblogs have 'miniblogs' on the side that act much inthe same way.

* [http://www.truthlaidbear.com/topics.php example]

<pre><nowiki>
<div id="fullcol">
<div id="sumcol">

<b>
<a href="http://www.truthlaidbear.com/topicpage.php?topic=harrietmiers" class="linktitle">Harriet Miers</a>
</b>
</div>
<div id="commcol">
<img src="http://www.truthlaidbear.com/topics/topic_harrietmiers_sm.png" >
</div>
<div id="commcol">

<b>
<a href="http://polipundit.com/index.php?p=10420" class="linktitle">Harriet Miers Must...</a>
</b>
<br>
...
</div>
<div id="commcol">

<b>
<a href="http://instapundit.com/archives/026104.php" class="linktitle">A MIERS MELTDOWN? </a>
</b>
<br>
...
</div>
</div>

<div id="fullcol">
<div id="sumcol">

<b>
<a href="http://www.truthlaidbear.com/topicpage.php?topic=iraq" class="linktitle">Iraq</a>
</b>
</div>
<div id="commcol">
<img src="http://www.truthlaidbear.com/topics/topic_iraq_sm.png" >
</div>
<div id="commcol">

...
</div>
<div id="commcol">

...
</div>
</div>
</nowiki></pre>

=== Single entry on a page ===
This is common with weblogs that archive on a per entry basis ([http://www.microformats.org/blog/2005/09/30/web-essentials-audio/ example]).

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>
</div>
</nowiki></pre>

Note that's no guarentee that a block (as shown above as the <code>id=content</code> div) will be around the singleton entry.

== EntryGroup Title ==
== EntryGroup Permalink ==
== Individual Entry ==

=== Individual entries are within a container ===
Common.

* [http://microformats.org/ example]

<pre><nowiki>
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>
</nowiki></pre>

=== Individual entries are not within a container ===
Common.

* [http://nataliesolent.blogspot.com/ example]

<pre>
<a name="112877372228959075"> </a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</pre>

=== Disjointed entries ===
That is, not all sub-elements of an individual entry are in the container (for example, the author and date may follow in a separate block)

== Entry Titles ==
=== Entry Title enclosed in <code><h#></code> block element ===
* [http://www.microformats.org/blog/2005/09/30/web-essentials-audio/ example]

<pre>
<div class="entry single">
<h2 id="post-59">Web Essentials Audio</h2>
...
</div>
</pre>

=== Entry Title enclosed in a <code><div></code> block element ===
''I've seen this but I can't find an example, hopefully implying this is somewhat rare''.

=== Entry Title enclosed in an inline presentation element, such as <code><b></code> ===
* [http://nataliesolent.blogspot.com/ example]

<pre>
<a name="112877372228959075"> </a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</pre>

=== Entry Title enclosed in a <code><span></code> (inline element) ===
* [http://www.andrewsullivan.com/ example]

<pre>
<a name="112897777851715476"> </a>
<br>
<SPAN CLASS="inc_subtitle">EMAIL OF THE DAY II: </SPAN>"After years ...
</pre>

=== No Entry Title ===
* [http://www.instapundit.com/ example]

== Entry Content ==

=== Entry without content ===
That is, the entry has just a link and the title pointing to a different URI (which may actually have content). This is something frequently seen on news sites (which after all, can generate feeds)

* [http://www.cbc.ca/news/ example]

<pre><nowiki>
<ul>
<li>
<a href="/story/.../ndp-libs051016.html">NDP sets conditions for backing Liberals</a>
</li>
<li>
<a href="/story/.../teachers-bc051016.html">Go back to work, B.C. ...</a>
</li>
<li>
<a href="/story/.../alberta-strike2_051015.html">Plant managers charged ...</a>
</li>
<li>
<a href="/story/.../bc-mystery-illness051015.html">B.C. seniors' home reports...</a>
</li>
</ul>
</nowiki></pre>

=== Entry contains summary content only ===
This is common on media sites. MovableType also provides this as a default option, so it's often seen on MT blogs,

* [http://thecommunityengine.com/home/ example]

<pre><nowiki>
<div class="inlineBlog">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
<p class="categorylist">
Sections:
<a href="http://thecommunityengine.com/home/archives/tools_and_analytics" rel="tag">Tools and Analytics</a>
</p>
<p class="taglist">Topics:
<a href="http://thecommunityengine.com/home/archives/tags/greasemonkey" rel="tag">greasemonkey</a>
<a href="http://thecommunityengine.com/home/archives/tags/microformats" rel="tag">microformats</a>
<a href="http://thecommunityengine.com/home/archives/tags/xfolk" rel="tag">xFolk</a>
</p>
<p>
The folks at ... the rest of the content
</p>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Notes:
* there's a lot of things going on in this example
* there's an "abstract" at the top
* there's sections for "categories" and "tags"
* there's a summary section "The folks at ... the rest of the content"
* there's a link to the full content at the bottom

=== Entry contains complete content ===

* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ example]

<pre><nowiki>
<div class="entry single">
<h2 id="post-61">Class attributes are about more than styling</h2>

<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

=== Entry breaks content into multiple sections ===
* [http://www.samizdata.net/blog/ example]
* we also identify this as 'Split Content'

<pre><nowiki>
<div class="blogbody">
<a name="008148"></a>

<div class="title">
Face to face: why places will continue to exist
</div>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

== Entry Datetimes ==
Datetimes are rarely expressed in consistent formats on weblogs. Weblogs generally express the creation date of the posting, not the modified time.

=== Dates between weblog entries ===
This is a common pattern but by no means universal pattern seen on weblogs -- a header or div inserted between weblog entries indicating that the date has changed. I cannot find an example where this header is systematically linked to the entries using that data (i.e. a common enclosing div)

* [http://dannyayers.com/ example]

<pre><nowiki>
<div class="post">
<h3 class="storytitle" id="post-3151"><a href="http://dannyayers.com/...">...</a></h3>
...
</div>

<div class="date">2005-10-07</div>

<div class="post">
<h3 class="storytitle" id="post-3150"><a href="http://dannyayers.com/...">...</a></h3>
...
</div>
</nowiki></pre>

=== Entry Date or Datetime in entry footer ===
Most weblogs follow this pattern. Dates or datetimes are in human readable format in varying fashions. Often only the time is indicated, as the date is implied. The date or datetime is sometimes also used an indication of the 'permalink' for a post.

* [http://www.microformats.org/blog/2005/09/30/web-essentials-audio/ example]

<pre><nowiki>
<div class="entry single">
<h2 id="post-59">Web Essentials Audio</h2>

<p>...</p>
<ul class="post-info">
<li><a href="...">Friday, September 30th, 2005 at 12:31 pm</a></li>
</ul>
</div>
</nowiki></pre>

== Entry Permalinks ==
Note that not only do some examples fit multiple categories, sometimes weblog posts place the multiple links to the permalink within a single post (for example, in the header and footer).

=== Entry Permalink is around or inside title ===
see immediate following example
=== Entry Permalink is in header of post ===
see immediate following example
=== Entry Permalink uses absolute URI ===
* [http://microformats.org/ example]

<pre><nowiki>
<div class="entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

=== Entry Permalink is in footer of post ===
* [http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html example]

<pre><nowiki>
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

=== Entry Permalink uses relative URI ===
see immediate following example
=== Entry Permalink includes fragment ===
This is used when a weblog archives posts as a group (say, by month or week) rather than as individual posts. This is very common on older blogspot weblogs.

* [http://nataliesolent.blogspot.com/2005_10_02_nataliesolent_archive.html#112876103554732697 example]

<pre><nowiki>
<a name="112876103554732697"> </a><br>
<strong>The ceremony of Explaining the Joke</strong>
<br>
<span class="byline">posted by Natalie at
<a href="2005_10_02_nataliesolent_archive.html#112876103554732697">8:18 AM</a></span>
<br>
</nowiki></pre>

=== No Entry Permalink ===
This is common on single article archive pages, some social weblogs ([http://raymitheminx.blogspot.com/ example]) and most big media webpages (i.e. non-blogs)
* [http://instapundit.com/archives/026056.php example]

<pre><nowiki>
<a name="026056"></a>
<p>ACCORDING TO THE WHITE HOUSE, ... hadn't we?</p>
<div class="footer">posted at 11:35 PM by <b>Glenn Reynolds</b></div>
</nowiki></pre>

== Entry Author ==

= Other Stock Examples =
Example of blog posts in unmodified weblog software installations.

=== Stock Wordpress 1.5 Installation ===
<pre><nowiki>
<div class="post">
<h2 id="post-237">
<a href="http://192.168.1.113/~migurski/wordpress/?p=237"
rel="bookmark" title="Permanent Link to More election maps">More
election maps</a>
</h2>
<small>November 9th, 2004 </small>

<div class="entry">
<p>via <a href="http://www.markme.com/jd/archives/006288.cfm">John Dowdell of JD on MX:</a></p>
<blockquote>
<p>More election maps: Ben Metcalfe, a software engineer at
the BBC, has his own list here… includes some not in
that “Flash the only winner” item from The
Inquirer, which Kevin also elaborated upon. Additionally,
Andrew Lucking pointed to the…</p>
</blockquote>
</div>

<p class="postmetadata">
Posted in <a
href="http://192.168.1.113/~migurski/wordpress/index.php?cat=1"
title="View all posts in General" rel="category tag">General</a>
<strong>|</strong> <a
href="http://192.168.1.113/~migurski/wordpress/?p=237#comments">
No Comments »</a>
</p>


</div>
</nowiki></pre>

=== Stock MoveableType 3.15 Installation ===
<pre><nowiki>
<h3 id="a000002">Example Entry</h3>
<p>This is the entry body.</p>
<p class="extended"><a href="http://localhost/archives/2005/08/example_entry_1.html#more">Continue reading "Example Entry"</a></p>
<p class="posted">Posted by migurski at <a href="http://localhost/archives/2005/08/example_entry_1.html">03:49 </a> | <a href="http://localhost/archives/2005/08/example_entry_1.html#comments">Comments (0)</a></p>
</nowiki></pre>

=== Stock Blosxom Installation, with [http://blosxom.com/downloads.html "Blosxom Flavour Sampler"] ===
<pre><nowiki>
<p>
<a name="post-identifier"><b>Post Title</b></a>
<br />
Post body text.
</p>
<p align="right">
<i>[<a href="/permalink/post-identifier">post-identifier</a>]
<a href="/permalink/2005/08/15#post-identifier">permanent link</a></i>
</p>
</nowiki></pre>

=== Stock Textpattern 4.0.3 Installation ===
<pre><nowiki>
<div id="content">

<h3><a href="http://txpdefault/article/2/second-post" title="Permanent link to this article">Second Post</a> · a few seconds ago by chris</h3>
<p>This is a short second post for illistration.</p>

<p class="comments_invite"><a href="http://txpdefault/article/2/second-post#comment" class="comments_invite">Comment</a></p>
<div align="center"><img src="http://txpdefault/images/1.gif" style="height:1px;width:400px" class="divider" alt="" /></div><h3><a href="http://txpdefault/article/1/first-post" title="Permanent link to this article">First Post</a> · 4 minutes ago by textpattern</h3>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec rutrum est eu mauris. In volutpat blandit felis. Suspendisse eget pede. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Quisque sed arcu. Aenean purus nulla, condimentum ac, pretium at, commodo sit amet, turpis. Aenean lacus. Ut in justo. Ut viverra dui vel ante. Duis imperdiet porttitor mi. Maecenas at lectus eu justo porta tempus. Cras fermentum ligula non purus. Duis id orci non magna rutrum bibendum. Mauris tincidunt, massa in rhoncus consectetuer, lectus dui ornare enim, ut egestas ipsum purus id urna. Vestibulum volutpat porttitor metus. Donec congue vehicula ante.</p>

<p class="comments_invite"><a href="http://txpdefault/article/1/first-post#comment" class="comments_invite">Comment</a> [1]</p>

<div align="center"><img src="http://txpdefault/images/1.gif" style="height:1px;width:400px" class="divider" alt="" /></div>

</div>
</nowiki></pre>

= Rough Examples =

Moved here from [[blog-description-format]] for documentation purposes.

== Existing practice ==

=== Entry Wrappers ===

<pre><nowiki><div class="entry"></div></nowiki></pre>

The entry wrapper format has widespread usage, but seems to show up in slightly different contexts.

Some blogs (ala Wordpress) use the entry div as a wrapper to the actual post body, and wrap the whole thing in an additional div:

<pre><nowiki><div class="post">
<div class="entry">
</div>
</div></nowiki></pre>

A vast number of sites, including many blogs contain the main page content within a id="content" div:

<pre><nowiki><div id="content"></div></nowiki></pre>

=== Metadata ===

Wordpress uses class="postmetadata" to contain meta information, date, others use their own syntax - class="topics", class="description".

=== Basic Elements ===

Titles are usually denoted with an H2 or H3 heading. Use of class="title" seems rare, but some sites do use this explicit markup.

class="summary" is used to denote an item summary, usually in a paragraph element.

=== Permalinks ===

rel="bookmark" and rel="permalink" are both used in various places to denote a permalink to the specified entry.

=See Also=
* [[blog-post-examples]]
* [[blog-post-formats]]
* [[blog-post-brainstorming]]
* [[hatom|hAtom]] - the draft proposal based on this information
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)

irc

2006-01-21T23:24:27Z

ChrisCasciano: /* People on irc */

__NOTOC__
= Microformats IRC =

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

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

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

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

=== bots ===

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

== Logs ==

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

== IRC meetups ==

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

rel-license

2006-01-21T23:22:03Z

ChrisCasciano: /* Implementations - txp plugin */

= rel="license" =

Rel-License is a simple, open, format for indicating content licenses which is embedable in (X)HTML, Atom, RSS, and arbitrary XML. Rel-License is one of several [[microformats|microformat]] open standards.

__TOC__

== Draft Specification 2005-02-06 ==
=== Author ===
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.] (formerly of [http://microsoft.com/ Microsoft Corporation])

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

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

== Abstract ==

Rel-License is one of several MicroFormats. By adding <code>rel="license"</code> to a hyperlink, a page indicates that the destination of that hyperlink is license for the current page. E.g. with the following hyperlink:

<pre><nowiki>
<a href="http://creativecommons.org/licenses/by/2.0/" rel="license">cc by 2.0</a>
</nowiki></pre>

the author indicates that the page is licensed under a Creative Commons 2.0 Attribution Required license.

== Multiple Licenses ==
Multiple such rel="license" hyperlinks indicate that the page is available under any of the referred licenses. E.g. the following hyperlinks could be used to declare that a page is available under either a Creative Commons 2.0 Attribution Required license or the Apache 2.0 license:

<pre><nowiki><a href="http://creativecommons.org/licenses/by/2.0/" rel="license">cc by 2.0</a>
<a href="http://www.apache.org/licenses/LICENSE-2.0" rel="license">Apache 2.0</a></nowiki></pre>

== 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="license">license</dt>
<dd>Indicates that the referred resource is a license for the referring page.</dd>
</dl>
</dd>
</dl>
</nowiki></pre>

== Implementations ==
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding rel license and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* [http://creativecommons.org/license/ Creative Commons (cc) license chooser]
* [http://search.yahoo.com/cc Yahoo! (cc) search]
* [http://www.google.com/support/bin/answer.py?answer=29508 Google "Usage Rights" search]

== References ==
=== Normative References ===
* [http://gmpg.org/xmdp/ XMDP]

=== Informative References ===
* 20040211 rel="license" first proposed in presentation [http://tantek.com/presentations/2004etech/realworldsemanticspres.html real world semantics] at 2004 O'Reilly Emerging Technologies Conference, San Diego, CA, USA.
* 20040225 [http://tantek.com/log/2004/02.html#d25t1805 Thorough discussion of rel="license"] including advantages and presentation possibilities.
* [http://creativecommons.org/licenses/by/2.0/ Creative Commons 2.0 By (Attribution Required) license]
* [http://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license]
* Contributed from http://developers.technorati.com/wiki/RelLicense

== see also ==
* See [[rellicense-issues]] for issues which have been raised with this [[microformat]].

adr

2006-01-20T16:49:28Z

ChrisCasciano: /* Implementations - txp plugin */

= adr =

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Human vs. Machine readable ===

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

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

=== Value excerpting ===

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

=== Root Class Name ===

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

=== Property List ===

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

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

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

=== XMDP Profile ===

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

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

== Examples ==
This section is informative.

=== Sample adr ===

Here is a sample adr:

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

This adr might be displayed as:

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

=== More Examples ===

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

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

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

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

* ...
* ...

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

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

* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding adrs and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].

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

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

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

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

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

== Discussions ==

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

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

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

geo

2006-01-20T16:48:32Z

ChrisCasciano: /* Implementations - txp plugin */

= geo =

'''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 addresses in the context of the rest of the information in their web pages and feeds.

If the publisher knows and is publishing the ''name'' of the location in addition to its 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 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.

=== Sample geo ===

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>

=== More Examples ===

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

== 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 [[hcard|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.

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

== 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://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].

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

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

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

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

== Discussions ==

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

=== Q&A ===
* If you have any questions about hCard, check the [[hcard-faq|hCard FAQ]] first, and if you don't find answers, add your questions! (Odds are that any geo question will apply to hCard as well).

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

rel-tag

2006-01-20T16:47:50Z

ChrisCasciano: /* Implementations - txp plugin */

= rel="tag" =
__TOC__

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

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

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

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

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

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

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

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

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

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

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

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

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

== Tag Spaces ==

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

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

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

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

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

is a URL for the tag "tech".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Discussions ==

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

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

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

xfn-implementations

2006-01-20T16:46:31Z

ChrisCasciano: /* XFN Implementations - txp plugin */

= XFN Implementations =

In addition to the [http://gmpg.org/xfn/tools XFN Tools] page, here are a few more more recent implementations:

The following implementations have been developed which either generate or parse [http://gmpg.org/xfn XFN relationship links]. If you have an XFN implementation, feel free to add it to the top of this list.

* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding XFN and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].

* [http://wiki.www.videntity.org/wiki/Social_Networking_Unlimited Videntity supports XFN].

* [http://odeo.com ODEO] [http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html publishes] <code>rel="contact"</code> for a user's contacts on their profile page.

* [http://icite.net/develop/software.html#ll4blojsom LL4blojsom] is the LinkList plugin for the [http://blojsom.sf.net blojsom] blog engine. blojsom, written in Java, is the open source application behind the Tiger Weblog Server that is part of OS X server. The LL4blojsom plugin is used for creating XFN blogrolls.

* [http://tagalag.com Tagalag] Tagalag [http://tagalag.com/tools.html#xfn supports] a partial XFN vocabulary.

== See Also ==

* [http://www.centralityjournal.com/archives/xfn_bottomup_social_networks.html XFN:bottom-up Social Networks by Stowe Boyd]
* [[xfn-wants]]

User:ChrisCasciano

2006-01-20T16:41:31Z

ChrisCasciano: created my page

== Chris Casciano ==

Author of the Textpattern Microformat Plugin - [http://placenamehere.com/TXP/pnh_mf/ pnh_mf].

* [http://placenamehere.com placenamehere.com]
* [http://chunkysoup.net ChunkySoup.net]

hcalendar

2006-01-16T17:23:45Z

ChrisCasciano: /* hCalendar */

= hCalendar =

hCalendar is a simple open, distributed calendaring and events format, based on the iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]), suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. hCalendar is one of several open [[microformats|microformat]] standards.

__TOC__

== Draft Specification ==

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

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

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

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

=== Inspiration and Acknowledgments ===
Thanks to:
* Adam Bosworth for leading the [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars FOO Camp 2004 HTML For Calendars presentation] which brought together a critical mass of interested parties.

== Introduction ==
The iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]), has been broadly interoperably implemented (e.g. Apple's "iCal" application built into MacOSX).

In addition, bloggers often discuss events on their blogs -- upcoming events, writeups of past events, etc. With just a tad bit of structure, bloggers can discuss events in their blog(s) in such a way that spiders and other aggregators can retrieve such events, automatically convert them to iCalendar, and use them in any iCalendar application or service.

This specification introduces the '''hCalendar''' format, which is a 1:1 representation of the aforementioned iCalendar standard, in semantic XHTML. Bloggers can both embed hCalendar events directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCalendar enables applications to retrieve information about such events directly from web pages without having to reference a separate file.

== Semantic XHTML Design Principles ==

{{semantic-xhtml-design-principles}}

== Format ==

=== In General ===

The iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]) forms the basis of hCalendar.

Note: the editor and authors of this specification are tracking the [http://lists.osafoundation.org/pipermail/ietf-calsify/ "iCal-Basic" effort] and intend to base the core hCalendar profile on iCal-Basic. See references for a link to the current draft.

The basic format of hCalendar is to use iCalendar object/property names in lower-case for class names, and to map the nesting of iCalendar objects directly into nested XHTML.

=== More Semantic Equivalents ===

However, for some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:
* <code>URL</code> in iCalendar becomes <code><a class="url" href="...">...</a></code> inside the element with <code>class="vevent"</code> in hCalendar.
* <code>ATTENDEE</code> in iCalendar may in hCalendar be represented by an [[hcard]].

=== Singular vs. Plural Properties ===

For properties which are singular (e.g. "N" and "FN" from vCard), the first descendant element with that class should take effect, any others being ignored.

For properties which can be plural (e.g. "TEL" from vCard), each class instance should create a instance of that property. Plural properties with subtypes (e.g. TEL with WORK, HOME, CELL from vCard) can be optimized to share a common element for the property itself, with each instance of subtype being an appropriately classed descendant of the property element.

=== 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. This specification recommends that such <code><abbr></code> elements be used for the following iCalendar properties:
* DTSTART, DTEND, DURATION, RDATE, RRULE

== Example ==

Here is a sample event in an iCalendar:
<pre><nowiki>
BEGIN:VCALENDAR
PRODID:-//XYZproduct//EN
VERSION:2.0
BEGIN:VEVENT
URL:http://www.web2con.com/
DTSTART:20051005
DTEND:20051008
SUMMARY:Web 2.0 Conference
LOCATION:Argent Hotel\, San Francisco\, CA
END:VEVENT
END:VCALENDAR
</nowiki></pre>
and an equivalent event in hCalendar format with various elements optimized appropriately. See [[hcalendar-example1-steps]] for the derivation.

<pre><nowiki>
<span class="vevent">
<a class="url" href="http://www.web2con.com/">
<span class="summary">Web 2.0 Conference</span>:
<abbr class="dtstart" title="2005-10-05">October 5</abbr>-
<abbr class="dtend" title="2005-10-08">7</abbr>,
at the <span class="location">Argent Hotel, San Francisco, CA</span>
</a>
</span>
</nowiki></pre>
which could be displayed as:

[http://www.web2con.com/ Web 2.0 Conference: October 5-7, at the Argent Hotel, San Francisco, CA]

Note 1: The product information is not necessary since hCalendar is an interchange format. When transforming hCalendar back into iCalendar, the transforming engine should add its own product ID.

Note 2: A surrounding <span class="vcalendar"> element is optional, and is left out as such. It is optional since the context of a vcalendar is implied when a vevent is encountered. The implied context/scope is that of the document. Authors may explicitly use elements with class="vcalendar" to wrap sets of vevents that all belong to the same calendar, e.g. when publishing multiple calendars on the same page.

Note 3: The version information is unnecessary in hCalendar markup directly since the version will be defined by the profile of hCalendar that is used/referred to in the 'profile' attribute of the <head> element.

Note 4: ISO8601 dates (required by iCalendar) are not very human friendly. In addition, the year is often understood implicitly by humans from the context. Thus <code><abbr></code> elements are used to simultaneously provide a human friendly date and/or time in the visible contents of the element, while placing the respective machine parsable comprehensive ISO8601 datetime in the 'title' attribute.
The notation YYYY-MM-DD should be used for better readability.

Note 5: The difference between the DTEND ISO8601 date (2005-10-08) and the human readable date (7) is NOT a mistake. [http://lists.osafoundation.org/pipermail/ietf-calsify/2005-September/000769.html DTEND is exclusive], meaning, that the event ends just before the DTEND. Thus for events which start on one day and end on another day, the DTEND date must be specified as the day after the day that a human would say is the last day of the event.

See [[hcalendar-examples]] for more hCalendar examples

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

The following sites have implemented 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 pages are marked up with hCalendar, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

=== New Examples ===
Please add new examples to this section.
* ...

* [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/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://evdb.com EVDB], the Events and Venues database, publishes all events with hCalendar and venues with [[hcard|hCard]]. Took them only 15 minutes to implement both!
* [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 [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://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]
* [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://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm.htm program] marked up with hCalendar.
* 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.

=== Examples with some problems ===
* [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.
** WARNINGS
*** has only dates where there should be datetime's
*** has abbr's with no title
*** should probably markup the description --[[User:RyanKing|RyanKing]] 16:04, 6 Jan 2006 (PST)
* [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)

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

The following implementations have been developed which either generate or parse hCalendars. If you have an hCalendar 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.

=== Generation ===
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding hCalendar and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* [http://www.midgard-project.org/documentation/net-nemein-calendar/ Midgard CMS - net.nemein.calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius]
* [http://www.decafbad.com/blog/2005/06/08/greasemonkey_magic magic_hcalendar Greasemonkey user script by Les Orchard] - allows easy form entry of an event into any textarea, e.g. into a blog post text area.
* [http://microformats.org/code/hcalendar/creator microformats.org hCalendar creator]
* [http://hybernaut.com/upcoming-hcal Drupal Upcoming.org syndication module emits hCalendar]
* [http://theryanking.com/ Ryan King] has an [http://theryanking.com/microformats/hcalendar-creator.html hCalendar creator].

=== Conversion and consumption ===
* [http://virtuelvis.com/archives/2005/11/learn-to-love-microformats simple hCalendar parser] by [http://virtuelvis.com/ Arve Bersvendsen]
* [http://george.hotelling.net/90percent/ George] has built a [http://george.hotelling.net/90percent/geekery/greasemonkey_and_microformats.php Greasemonkey user script that detects hCalendar events and allows users to easily add them to their calendar application(s)].
* [http://blogmatrix.blogmatrix.com/ David Janes] has produced a [[Greasemonkey]] [http://www.blogmatrix.com/include/microformat-find.user.js script] that finds many microformat elements, including hCalendar events, and [http://blog.davidjanes.com/mtarchives/2005_08.html#003379 provides a popup menu of actions]. The hCalendar to vCalendar conversion is done internally within the script. ''This does not work with FireFox 1.5+/GreaseMonkey 0.6.4+.''
* [http://suda.co.uk/projects/X2V/ X2V] parses hCalendar and produces a .ics (iCalendar) stream. Note: needs to be updated to track changes in the specification as they occur.
* [http://dev.w3.org/cvsweb/2001/palmagent/ palmagent] by [[User:DanC]] includes toICal.xsl and test materials; it works much like xhtml2vcal.xsl in X2V. See also: [http://www.w3.org/2002/12/cal/ RDF Calendar workspace] with icalendar test materials.
* [http://web.mit.edu/glasser/www/JSCalendar/ JSCalendar] parses hCalendar and produces a displayable HTML table/CSS-based calendar.

Investigation:
* [http://wiki.mozilla.org/Calendar_Talk:Lightning#hCalendar_publish_and_subscribe_support Mozilla Calendar / Lightning / Sunbird hCalendar support discussion]

=== Potential implementations ===

These are open source projects that could be potentially enhanced to support hCalendar.

* [http://www.k5n.us/webcalendar.php?topic=About WebCalendar]
* [http://phpicalendar.net/documentation/index.php?title=Main_Page PHP iCalendar]

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[hcard|hCard]]
* [http://www.ietf.org/rfc/rfc2445.txt iCalendar RFC2445]

=== Informative References ===
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://tantek.com/log/2004/09.html#hcalendar hCalendar term introduced and defined on the Web, 20040930]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars FOO Camp 2004 HTML For Calendars presentation, 20040911]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 20040910]
* [http://www.ietf.org/internet-drafts/draft-royer-ical-basic-02.txt iCal-Basic draft 02]
* Contributed from http://developers.technorati.com/wiki/hCalendar
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]

==== Related ====
* [[icalendar-implementations|iCalendar implementations]]
* [http://lists.osafoundation.org/pipermail/ietf-calsify/ IETF-calsify archives]
* [http://www.livejournal.com/users/jwz/444651.html jwz - Hula] (required reading)
* [http://www.jwz.org/doc/groupware.html Groupware Bad by Jamie Zawinski] crystalizes the reason for hCalendar ('''emphasis''' added):
<blockquote>"Right now people can do that by publishing .ics files, but it's not trivial to do so, and it's work on the part of other people to look at them. '''If it's not HTML hanging off our friend's home page that can be viewed in any browser on a public terminal in a library, the bar to entry is too high and it's useless.'''"</blockquote>

* [http://muddybranch.thejkgroup.com/ Jason Klemow's blog]
* [http://www.softwarestudio.org/iCal/2445Issues.html RFC2445 Issues List]
* [http://ietf.webdav.org/calsify/ CALSIFY WG Links And Resources]

=== Similar Work ===
* [[XOXO]]

== Discussions ==

This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hCalendar:

* [[hcalendar-brainstorming]]

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

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

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