Microformats Wiki - User contributions [en]

User:DimitriGlazkov

2007-12-30T23:08:17Z

DimitriGlazkov: Update Public Domain Release

http://glazkov.com/

{{cc-public-domain-release}}

presentational-html

2007-12-12T03:36:30Z

DimitriGlazkov: Reverting Spam

<h1> Presentational (X)HTML </h1>
{{TOC-right}}
Presentational (X)HTML refers to:
# The presentational elements and attributes of (X)HTML (as opposed to the [[semantic-html|semantic HTML]] elements and attributes)
# (X)HTML documents that are written using presentational (X)HTML.
# The practice of writing presentational (X)HTML

== Contributors ==
* [http://tantek.com/ Tantek]

== Presentational Elements ==

Presentational elements sensu lato can be divided into two groups. "Deliberate" presentational elements (b, i, small, …) have no semantic meaning and were deliberately designed/created for presentational purposes. "Abused" presentational elements (table, blockquote, …) have a semantic meaning, but are abused because of their default appearance in browsers (the blockquote element could be used for indenting text, for example).

=== Deliberate ===
Deprecated:
* basefont
* center
* font
* hr
* s
* strike
* tt
* u

Frames:
* frame
* frameset
* iframe

Strict but mostly presentational:
* b
* br (when used for spacing, or when used inappropriately where a div or p would have been semantically correct)
* big
* i
* small
* sub
* sup

=== Abused ===

* blockquote (when used for indenting text)
* table (when used for layout)

== Presentational Attributes ==
(This list is incomplete, please add!)
* align
* alink
* bgcolor
* color
* face
* height
* link (on body)
* size (on font element)
* valign
* vlink
* width

== See also ==
* [[POSH]]
* [[semantic-html]]

== References ==
* [http://w3.org/TR/xhtml1 XHTML 1.0]
* [http://w3.org/TR/html401 HTML 4.01]

reltag

2007-11-23T14:34:26Z

DimitriGlazkov: /* Reverting Spam Edits */

#REDIRECT [[rel-tag]]

review-formats-fr

2007-10-08T13:44:08Z

DimitriGlazkov: /* Spam */

= Formats Actuels de Critiques =

Il y a eu plusieurs efforts pour définir les formats de données pour poster des "critiques" de produits, services, etc. sur le web.

Cette page sert à documenter la liste actuelle des schémas de critiques, formats et efforts tout comme l'historique pour la conception d'un [[microformat-fr|microformat]] simple pour les critiques. - [http://tantek.com/log/ Tantek]

__TOC__

== Contributeurs ==

Copié à partir de [[reviews-formats-fr]] qui lui même a été contribué sur [http://developers.technorati.com/wiki/ReviewsFormats Technorati Developer's Wiki: ReviewsFormats])

* Tantek Çelik
* Niall Kennedy

== Voir aussi ==
* [[review-examples-fr|exemples review]]
* [[review-brainstorming-fr|brainstorming review]]
* [[hreview-fr|hReview]]

== Notes ==

Notez que '''auteur''' apparaît plusieurs fois dans les listes ci-dessous,
et que cela fait référence quelques fois à l'auteur de la critique, et d'autres fois
à l'auteur du livre en train d'être critiqué.
Une parenthèse sera désormais utilisée pour les distinguer.

== Schémas et Formats Précédents ==
=== Générique pour n'importe quel type de critique ===
==== RVW ====
* http://www.pmbrowser.info/rvw/0.2/
** http://hublog.hubmed.org/archives/000307.html <- c'est vraiment une version vieille et démodée
** http://www.pmbrowser.info/wiki.pl?RVW
* variantes pour embarquement dans Atom, RSS2, RSS1, RDF
* schéma apparent
** auteur de la critique
** contenu de la critique
** créateur du travail
*** exemple : auteur du livre, réalisateur du film
** notation score en pourcentage
** identifiants multiples
*** exemple : ISBN, ASIN, UPC, LOC
** lien pour acheter
* semble être vaguement connecté avec le terme "!OpenReviews" (a aussi fait référence à d'autres efforts) qui apparaissent eux-mêmes pour être encore
un autre buzzword OpenBlahBlah sans substance derrière (comme un terme pour tenir une place).
==== Vocabulaire Review RDF ====
* RDF Review Vocabulary: http://www.purl.org/stuff/rev
** Déployé dans [http://trust.mindswap.org/FilmTrust/ FilmTrust], voir par ex. [http://trust.mindswap.org/cgi-bin/FilmTrust/foaf.cgi?user=thejrnf user profile]
** Version étendue utilisée pour transformation StructuredBlogging/RDF (voir par ex. [http://incredibooks.com/index.php/2005/12/17/the-muffin-fiend/ sample review] il y a une référence vers [http://structuredblogging.org/subnode-to-rdf-interpreter.xsl subnode-to-rdf-interpreter.xsl] dans le source).
** Utilisé dans [http://www.ldodds.com/blog/archives/000126.html AllConsuming Reading Lists in RDF]
** Utilisé dans [http://www.ldodds.com/blog/archives/000087.html FOAF-a-matic Mark 2]

==== Simple-Review XML ====
* Embarque XML dans <script type="application/x-subnode">
* [http://structuredblogging.org/xmlns/simple-review.xsd XSD]
* schéma apparent
** review-title
** item
*** name/title
*** type
*** URL
*** image URL
** rating (user visible, max, normalized to 0..1 value)
** comments/description

=== Pour des domaines spécifiques ===
==== Films ====
* [http://www.millikin.edu/mr/Entertainment/howto2.html How to Write a Movie Review]
==== Livres ====
* schéma RDF pour critiques de livres : http://www.amk.ca/xml/reviews.html

* voir aussi [[book-info-examples-fr|exemples information de livres]]

== Voir aussi ==
* [[review-examples-fr|exemples critiques]]
* [[review-brainstorming-fr|rewiew-brainstorming]]
* [[hreview-fr|hReview]]

Voir [[hreview-fr|hReview]] pour le résultat et une évolution de ces pensées sur un microformat.

old-json-serializations

2007-10-04T19:43:02Z

DimitriGlazkov: /* stub created */

== JSON Serialization of Microformats ==

Placeholder page to document the methods of expressing microformatted content in JSON.

user-interface

2007-09-05T13:05:08Z

DimitriGlazkov: Added Margin Marks

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

== Design Guidelines ==
These are some suggested design guidelines for Web designers and developers by [http://blog.mozilla.com/faaborg/ Alex Faaborg], a user experience designer at Mozilla:
*Design based on actions, not data. A button that says "Send to Calendar" is considerably more useable than a green button that simply says "hCalendar"
*Use iconic images instead of acronyms. In addition to being more descriptive, they localize better. Here are some I've been showing in various talks: [http://people.mozilla.com/~faaborg/files/20061213-fundamentalTypes/fundamentalTypesStatic.jpg_large.jpg microformat icons]. These are still very preliminary. Mozilla will likely release all of the source artwork for our microformat icons under a creative commons license around the launch of Firefox 3. This will enable Web designers to integrate the icons into their sites, and other Web browsers can consider using a similar set of icons.

== Challenges ==
* Chris Messina: "What kind of solutions can we come up with that are single click only?"
* Andy Mabbett - How can we make them [[accessibility|accessible]] to people with (for instance) visual disabilities?
* Alex Faaborg: Mozilla has had inquiries from reporters in the mainstream media (Wired and Business Week) who wanted to cover microformats in stories about the future of the Web browser, but they then later backed out because they felt the term "microformats" would only appeal to developers, and not the average reader. These types of mainstream stories need to focus on the user experience, and not the underlying technology, but what term should reporters use to describe the overall feature?

== Social Network Portability ==
See the separate [[social-network-portability]] page.

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

=== Screen Shots ===
* [http://blog.mozilla.com/faaborg/2007/02/04/microformats-part-4-the-user-interface-of-microformat-detection/ Conceptual Mockups of Microformat Detection in Firefox 3]
* [http://www.hicksdesign.co.uk/journal/a-proposal-for-a-safari-microformats-plugin Jon Hicks: Proposal for a Safari Microformats plugin] <br /> [http://www.hicksdesign.co.uk/journal/a-proposal-for-a-safari-microformats-plugin http://www.hicksdesign.co.uk/images/txp/197t.png]
* [http://ben-ward.co.uk/journal/microformats-ui/ Ben Ward: Microformats in Web Browsers] <br /> [http://ben-ward.co.uk/journal/microformats-ui/ http://ben-ward.co.uk/res/posts/uf-web-browser/autodiscovery.png]
* [http://blog.wilsonet.com/archives/2006/04/30/microformats-in-flock/ Microformats in Flock] <br /> [http://blog.wilsonet.com/archives/2006/04/30/microformats-in-flock/ http://blog.wilsonet.com/mockups/Flock/Flock-PickContacts_thumbnail.png]
* [http://glazkov.com/blog/margin-marks/ Margin Marks UI Concept], [http://flickr.com/photos/dglazkov/sets/72157601860335196/ Margin Marks Comps on Flickr]

=== 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.
* Jon Hicks has written [http://www.hicksdesign.co.uk/journal/highlight-microformats-with-css a user stylesheet for Mac browsers] that highlights hCard and hCalendar data.

=== Planning and Discussion ===
*[http://wiki.mozilla.org/Microformats Discussion of microformat detection in Firefox 3]
*[http://wiki.mozilla.org/Microformats/UE/ideas UI brainstorming on the Mozilla Wiki]
* The [http://wiki.caminobrowser.org/Development:Planning:Microformats Camino Wiki has a page] where future microformats support is being discussed and organized

== Simpler Markup Languages ==
There are plenty of [[wiki-formats]] that attempt to make it easier for more people author semantic markup, often with textually decorative punctuation.

As these simpler markup languages are something that *users* are expected to type, they are user interface.

=== Markdown extension for hCalendar ===
See [http://article.gmane.org/gmane.text.markdown.general/2027 Markdown and the hCal microformat] which proposes an extension to the Markdown text markup language to capture and represent hCalendar event semantics in a human editable form.

== See Also ==
* [[hcard-user-interface]]
* [[data-portability]]
* [[social-network-portability]]

audio-info

2007-08-23T17:23:10Z

DimitriGlazkov: oy.

see
*[[audio-info-brainstorming]]
*[[audio-info-examples]]
*[[audio-info-issues]]

audio-info

2007-08-23T17:22:55Z

DimitriGlazkov: Reverting Spam

see
*[[audio-info-brainstorming]]
*[[audio-info-examples]]
*[[audio-info-issues]]

xoxo-brainstorming

2007-08-08T16:35:32Z

DimitriGlazkov: /* Parsing Properties */

= XOXO brainstorming =

== Authors ==

* [http://tantek.com/log Tantek Çelik]
* [[DimitriGlazkov]]

== Example Uses ==

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

=== Blogrolls ===

Background: See L.M. Orchard's post "[http://decafbad.com/blog/2005/11/27/subscriptions-are-attention-but-what-about-blogrolls Subscriptions Are Attention But What About Blogrolls]".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see [[xoxo-profile]]) the class name "blogroll" for blogroll lists. E.g.
<pre><nowiki>
<ul class="xoxo blogroll">
<li><a href="...">...</a></li>
<li><a href="...">...</a></li>
</ul>
</nowiki></pre>

Note that a blogroll is a superset of a subscription list.

==== Subscription information ====
Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

* An [http://www.opmlmanager.com/outliner/neuraxon77 example] of OPML to a XOXO list w/ expand/collapse folders

===== Possible XOXO blogs+feeds markup =====

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<pre><nowiki>
<ul class="xoxo blogroll">
<li>
<a href="blogURL1">Blog Name 1</a>
<a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
</li>
<li>
<a href="blogURL2">Blog Name 2</a>
<a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
<a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
</li>
</ul>
</nowiki></pre>

CSS styling could make this as pretty or not as desired.

See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]

=== Wishlists ===

Background: See L.M. Orchard's post: "[http://decafbad.com/blog/2005/11/27/i-wish-it-were-in-xoxo I wish it were in XOXO]"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item?
See: [[listing-examples]], [[listing-formats]], [[listing-brainstorming]]

=== Tagged Links ===

This one seems easier, because you could simply use a list of [[xfolk|xFolk]] items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue working?

=== Applying "compact", Presentation Caveats ===

Currently, setting DOM property <code>compact</code> to <var>true</var> in Gecko produces an empty-value <code>compact=""</code> attribute, rather than the valid <code>compact="compact"</code>. In order to account for this quirk/bug, the CSS2 selector should be:

<pre>

ol[compact] { display: none; }

</pre>

If the XOXO item (represented by <code>li</code> element) contains properties, the application of <code>compact</code> may require more work to provide desired presentation. Since <code>compact</code> applies to the list, not the item, the properties of the item remain unaffected by changing the value of the attribute on the list (which is a peer of the property bag, represented by <code>dl</code> element). For example, consider this XOXO fragment:

<pre><nowiki>

<ul>
<li>select
<dl>
<dt>show-title</dt>
<dd>false</dd>
</dl>
<ol compact>
<li>title</li>
<li>abstract</li>
</ol>
</li>
</ul>

</nowiki></pre>

If the desired presentation effect is to only show <var>select</var> when the nested list is collapsed, additional information (like a class name, assigned to <code>li</code> element) is necessary to hide <code>dl</code> element. In [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/ CSS3], there is a way to somewhat address it using [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#general-sibling-combinators general sibling selectors]:

<pre>

ol[compact],
ol[compact] ~ dl {
display: none;
}

</pre>

=== Parsing Properties ===

* From HTML spec, the content of both [http://www.w3.org/TR/html4/struct/lists.html#h-10.3 dl], and [http://www.w3.org/TR/html4/struct/lists.html#h-10.2 li] can contain block or inline elements.
** this implies that special properties can include markup.
** naturally, <var>url</var>, <var>type</var>, and <var>rel</var> properties don't fit into this rule logically, but that's a reasonable exception.
* First <code>a</code> element specifies <var>text</var>, <var>url</var>, <var>title</var>, <var>type</var> and <var>rel</var> properties
** If these properties are also defined using <code>dl</code>, they:
*** a. override values, specified in hyperlink
*** b. are ignored -- I ([[DimitriGlazkov]]) am leaning toward this choice
* First <code>dl</code> is treated as a special property set
** how to escape in case <code>dl</code> is content, not property set?
*** possibly like this:

<pre><nowiki>

<ul class="xoxo">
<li>
<dl>
<dt>text</dt>
<dd>

<dl class="dictionary">
<dt>term</dt>
<dd>definition</dd>
</dl>
</dd>
</dl>
</li>
</ul>

</nowiki></pre>

Based on preliminary research, all parsers mentioned in [[xoxo-sample-code]] use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:

<pre><nowiki>

<ul class="xoxo">
<li>
<a href="http://microformats.org">Microformats</a>
<dl>
<dt>text</dt>
<dd>XOXO</dd>
</dl>
</li>
</ul>

</nowiki></pre>

Will parse the value of <var>text</var> property as <code>XOXO</code>, not <code>Microformats</code>. Not sure yet whether this this the right thing.

xoxo-brainstorming

2007-08-07T18:41:30Z

DimitriGlazkov: Added Gecko DOM attribute quirk/bug note

= XOXO brainstorming =

== Authors ==

* [http://tantek.com/log Tantek Çelik]
* [[DimitriGlazkov]]

== Example Uses ==

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

=== Blogrolls ===

Background: See L.M. Orchard's post "[http://decafbad.com/blog/2005/11/27/subscriptions-are-attention-but-what-about-blogrolls Subscriptions Are Attention But What About Blogrolls]".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see [[xoxo-profile]]) the class name "blogroll" for blogroll lists. E.g.
<pre><nowiki>
<ul class="xoxo blogroll">
<li><a href="...">...</a></li>
<li><a href="...">...</a></li>
</ul>
</nowiki></pre>

Note that a blogroll is a superset of a subscription list.

==== Subscription information ====
Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

* An [http://www.opmlmanager.com/outliner/neuraxon77 example] of OPML to a XOXO list w/ expand/collapse folders

===== Possible XOXO blogs+feeds markup =====

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<pre><nowiki>
<ul class="xoxo blogroll">
<li>
<a href="blogURL1">Blog Name 1</a>
<a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
</li>
<li>
<a href="blogURL2">Blog Name 2</a>
<a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
<a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
</li>
</ul>
</nowiki></pre>

CSS styling could make this as pretty or not as desired.

See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]

=== Wishlists ===

Background: See L.M. Orchard's post: "[http://decafbad.com/blog/2005/11/27/i-wish-it-were-in-xoxo I wish it were in XOXO]"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item?
See: [[listing-examples]], [[listing-formats]], [[listing-brainstorming]]

=== Tagged Links ===

This one seems easier, because you could simply use a list of [[xfolk|xFolk]] items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue working?

=== Applying "compact", Presentation Caveats ===

Currently, setting DOM property <code>compact</code> to <var>true</var> in Gecko produces an empty-value <code>compact=""</code> attribute, rather than the valid <code>compact="compact"</code>. In order to account for this quirk/bug, the CSS2 selector should be:

<pre>

ol[compact] { display: none; }

</pre>

If the XOXO item (represented by <code>li</code> element) contains properties, the application of <code>compact</code> may require more work to provide desired presentation. Since <code>compact</code> applies to the list, not the item, the properties of the item remain unaffected by changing the value of the attribute on the list (which is a peer of the property bag, represented by <code>dl</code> element). For example, consider this XOXO fragment:

<pre><nowiki>

<ul>
<li>select
<dl>
<dt>show-title</dt>
<dd>false</dd>
</dl>
<ol compact>
<li>title</li>
<li>abstract</li>
</ol>
</li>
</ul>

</nowiki></pre>

If the desired presentation effect is to only show <var>select</var> when the nested list is collapsed, additional information (like a class name, assigned to <code>li</code> element) is necessary to hide <code>dl</code> element. In [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/ CSS3], there is a way to somewhat address it using [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#general-sibling-combinators general sibling selectors]:

<pre>

ol[compact],
ol[compact] ~ dl {
display: none;
}

</pre>

=== Parsing Properties ===

* From HTML spec, the content of both [http://www.w3.org/TR/html4/struct/lists.html#h-10.3 dl], and [http://www.w3.org/TR/html4/struct/lists.html#h-10.2 li] can contain block or inline elements.
** this implies that special properties can include markup.
** naturally, <var>url</var>, <var>type</var>, and <var>rel</var> properties don't fit into this rule logically, but that's a reasonable exception.
* First <code>a</code> element specifies <var>text</var>, <var>url</var>, <var>title</var>, <var>type</var> and <var>rel</var> properties
** If these properties are also defined using <code>dl</code>, they:
*** a. override values, specified in hyperlink
*** b. are ignored -- I ([[DimitriGlazkov]]) am leaning toward this choice
* First <code>dl</code> is treated as a special property set
** how to escape in case <code>dl</code> is content, not property set?
*** possibly like this:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</dl>
</li>
</ul>
</nowiki></pre>

Based on preliminary research, all parsers mentioned in [[xoxo-sample-code]] use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</li>
</ul>

</nowiki></pre>

Will parse the value of <var>text</var> property as <code>XOXO</code>, not <code>Microformats</code>. Not sure yet whether this this the right thing.

xoxo-brainstorming

2007-08-07T18:36:14Z

DimitriGlazkov: added CSS3 selector example

= XOXO brainstorming =

== Authors ==

* [http://tantek.com/log Tantek Çelik]
* [[DimitriGlazkov]]

== Example Uses ==

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

=== Blogrolls ===

Background: See L.M. Orchard's post "[http://decafbad.com/blog/2005/11/27/subscriptions-are-attention-but-what-about-blogrolls Subscriptions Are Attention But What About Blogrolls]".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see [[xoxo-profile]]) the class name "blogroll" for blogroll lists. E.g.
<pre><nowiki>
<ul class="xoxo blogroll">
<li><a href="...">...</a></li>
<li><a href="...">...</a></li>
</ul>
</nowiki></pre>

Note that a blogroll is a superset of a subscription list.

==== Subscription information ====
Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

* An [http://www.opmlmanager.com/outliner/neuraxon77 example] of OPML to a XOXO list w/ expand/collapse folders

===== Possible XOXO blogs+feeds markup =====

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<pre><nowiki>
<ul class="xoxo blogroll">
<li>
<a href="blogURL1">Blog Name 1</a>
<a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
</li>
<li>
<a href="blogURL2">Blog Name 2</a>
<a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
<a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
</li>
</ul>
</nowiki></pre>

CSS styling could make this as pretty or not as desired.

See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]

=== Wishlists ===

Background: See L.M. Orchard's post: "[http://decafbad.com/blog/2005/11/27/i-wish-it-were-in-xoxo I wish it were in XOXO]"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item?
See: [[listing-examples]], [[listing-formats]], [[listing-brainstorming]]

=== Tagged Links ===

This one seems easier, because you could simply use a list of [[xfolk|xFolk]] items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue working?

=== Applying "compact" ===

If the XOXO item (represented by <code>li</code> element) contains properties, the application of <code>compact</code> may require more work to provide desired presentation. Since <code>compact</code> applies to the list, not the item, the properties of the item remain unaffected by changing the value of the attribute on the list (which is a peer of the property bag, represented by <code>dl</code> element). For example, consider this XOXO fragment:

<pre><nowiki>

<ul>
<li>select
<dl>
<dt>show-title</dt>
<dd>false</dd>
</dl>
<ol compact>
<li>title</li>
<li>abstract</li>
</ol>
</li>
</ul>

</nowiki></pre>

If the desired presentation effect is to only show <var>select</var> when the nested list is collapsed, additional information (like a class name, assigned to <code>li</code> element) is necessary to hide <code>dl</code> element. In [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/ CSS3], there is a way to somewhat address it using [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#general-sibling-combinators general sibling selectors]:

<pre>

ol[compact=""],
ol[compact="compact"],
ol[compact=""] ~ dl,
ol[compact="compact"] ~ dl {
display: none;
}

</pre>

=== Parsing Properties ===

* From HTML spec, the content of both [http://www.w3.org/TR/html4/struct/lists.html#h-10.3 dl], and [http://www.w3.org/TR/html4/struct/lists.html#h-10.2 li] can contain block or inline elements.
** this implies that special properties can include markup.
** naturally, <var>url</var>, <var>type</var>, and <var>rel</var> properties don't fit into this rule logically, but that's a reasonable exception.
* First <code>a</code> element specifies <var>text</var>, <var>url</var>, <var>title</var>, <var>type</var> and <var>rel</var> properties
** If these properties are also defined using <code>dl</code>, they:
*** a. override values, specified in hyperlink
*** b. are ignored -- I ([[DimitriGlazkov]]) am leaning toward this choice
* First <code>dl</code> is treated as a special property set
** how to escape in case <code>dl</code> is content, not property set?
*** possibly like this:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</dl>
</li>
</ul>
</nowiki></pre>

Based on preliminary research, all parsers mentioned in [[xoxo-sample-code]] use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</li>
</ul>

</nowiki></pre>

Will parse the value of <var>text</var> property as <code>XOXO</code>, not <code>Microformats</code>. Not sure yet whether this this the right thing.

xoxo-brainstorming

2007-08-07T17:09:12Z

DimitriGlazkov: Applying compact and its use in presentation

= XOXO brainstorming =

== Authors ==

* [http://tantek.com/log Tantek Çelik]
* [[DimitriGlazkov]]

== Example Uses ==

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

=== Blogrolls ===

Background: See L.M. Orchard's post "[http://decafbad.com/blog/2005/11/27/subscriptions-are-attention-but-what-about-blogrolls Subscriptions Are Attention But What About Blogrolls]".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see [[xoxo-profile]]) the class name "blogroll" for blogroll lists. E.g.
<pre><nowiki>
<ul class="xoxo blogroll">
<li><a href="...">...</a></li>
<li><a href="...">...</a></li>
</ul>
</nowiki></pre>

Note that a blogroll is a superset of a subscription list.

==== Subscription information ====
Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

* An [http://www.opmlmanager.com/outliner/neuraxon77 example] of OPML to a XOXO list w/ expand/collapse folders

===== Possible XOXO blogs+feeds markup =====

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<pre><nowiki>
<ul class="xoxo blogroll">
<li>
<a href="blogURL1">Blog Name 1</a>
<a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
</li>
<li>
<a href="blogURL2">Blog Name 2</a>
<a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
<a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
</li>
</ul>
</nowiki></pre>

CSS styling could make this as pretty or not as desired.

See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]

=== Wishlists ===

Background: See L.M. Orchard's post: "[http://decafbad.com/blog/2005/11/27/i-wish-it-were-in-xoxo I wish it were in XOXO]"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item?
See: [[listing-examples]], [[listing-formats]], [[listing-brainstorming]]

=== Tagged Links ===

This one seems easier, because you could simply use a list of [[xfolk|xFolk]] items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue working?

=== Applying "compact" ===

If the XOXO item (represented by <code>li</code> element) contains properties, the application of <code>compact</code> may require more work to provide desired presentation. Since <code>compact</code> applies to the list, not the item, the properties of the item remain unaffected by changing the value of the attribute on the list (which is a peer of the property bag, represented by <code>dl</code> element). For example, consider this XOXO fragment:

<pre><nowiki>

<ul>
<li>select
<dl>
<dt>show-title</dt>
<dd>false</dd>
</dl>
<ol compact>
<li>title</li>
<li>abstract</li>
</ol>
</li>
</ul>

</nowiki></pre>

If the desired presentation effect is to only show <var>select</var> when the nested list is collapsed, additional information (like a class name, assigned to <code>li</code> element) is necessary to hide <code>dl</code> element. In [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/ CSS3], there is a way to somewhat address it using [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#general-sibling-combinators general sibling selectors].

=== Parsing Properties ===

* From HTML spec, the content of both [http://www.w3.org/TR/html4/struct/lists.html#h-10.3 dl], and [http://www.w3.org/TR/html4/struct/lists.html#h-10.2 li] can contain block or inline elements.
** this implies that special properties can include markup.
** naturally, <var>url</var>, <var>type</var>, and <var>rel</var> properties don't fit into this rule logically, but that's a reasonable exception.
* First <code>a</code> element specifies <var>text</var>, <var>url</var>, <var>title</var>, <var>type</var> and <var>rel</var> properties
** If these properties are also defined using <code>dl</code>, they:
*** a. override values, specified in hyperlink
*** b. are ignored -- I ([[DimitriGlazkov]]) am leaning toward this choice
* First <code>dl</code> is treated as a special property set
** how to escape in case <code>dl</code> is content, not property set?
*** possibly like this:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</dl>
</li>
</ul>
</nowiki></pre>

Based on preliminary research, all parsers mentioned in [[xoxo-sample-code]] use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</li>
</ul>

</nowiki></pre>

Will parse the value of <var>text</var> property as <code>XOXO</code>, not <code>Microformats</code>. Not sure yet whether this this the right thing.

xoxo-brainstorming

2007-08-06T16:27:34Z

DimitriGlazkov:

= XOXO brainstorming =

== Authors ==

* [http://tantek.com/log Tantek Çelik]
* [[DimitriGlazkov]]

== Example Uses ==

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

=== Blogrolls ===

Background: See L.M. Orchard's post "[http://decafbad.com/blog/2005/11/27/subscriptions-are-attention-but-what-about-blogrolls Subscriptions Are Attention But What About Blogrolls]".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see [[xoxo-profile]]) the class name "blogroll" for blogroll lists. E.g.
<pre><nowiki>
<ul class="xoxo blogroll">
<li><a href="...">...</a></li>
<li><a href="...">...</a></li>
</ul>
</nowiki></pre>

Note that a blogroll is a superset of a subscription list.

==== Subscription information ====
Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

* An [http://www.opmlmanager.com/outliner/neuraxon77 example] of OPML to a XOXO list w/ expand/collapse folders

===== Possible XOXO blogs+feeds markup =====

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<pre><nowiki>
<ul class="xoxo blogroll">
<li>
<a href="blogURL1">Blog Name 1</a>
<a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
</li>
<li>
<a href="blogURL2">Blog Name 2</a>
<a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
<a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
</li>
</ul>
</nowiki></pre>

CSS styling could make this as pretty or not as desired.

See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]

=== Wishlists ===

Background: See L.M. Orchard's post: "[http://decafbad.com/blog/2005/11/27/i-wish-it-were-in-xoxo I wish it were in XOXO]"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item?
See: [[listing-examples]], [[listing-formats]], [[listing-brainstorming]]

=== Tagged Links ===

This one seems easier, because you could simply use a list of [[xfolk|xFolk]] items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue workng?

=== Parsing Properties ===

* From HTML spec, the content of both [http://www.w3.org/TR/html4/struct/lists.html#h-10.3 dl], and [http://www.w3.org/TR/html4/struct/lists.html#h-10.2 li] can contain block or inline elements.
** this implies that special properties can include markup.
** naturally, <var>url</var>, <var>type</var>, and <var>rel</var> properties don't fit into this rule logically, but that's a reasonable exception.
* First <code>a</code> element specifies <var>text</var>, <var>url</var>, <var>title</var>, <var>type</var> and <var>rel</var> properties
** If these properties are also defined using <code>dl</code>, they:
*** a. override values, specified in hyperlink
*** b. are ignored -- I ([[DimitriGlazkov]]) am leaning toward this choice
* First <code>dl</code> is treated as a special property set
** how to escape in case <code>dl</code> is content, not property set?
*** possibly like this:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</dl>
</li>
</ul>
</nowiki></pre>

Based on preliminary research, all parsers mentioned in [[xoxo-sample-code]] use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</li>
</ul>

</nowiki></pre>

Will parse the value of <var>text</var> property as <code>XOXO</code>, not <code>Microformats</code>. Not sure yet whether this this the right thing.

xoxo-brainstorming

2007-08-06T16:26:47Z

DimitriGlazkov: spelling is not my forte

= XOXO brainstorming =

== Authors ==

* [http://tantek.com/log Tantek Çelik]
* [[DimitriGlazkov]]

== Example Uses ==

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

=== Blogrolls ===

Background: See L.M. Orchard's post "[http://decafbad.com/blog/2005/11/27/subscriptions-are-attention-but-what-about-blogrolls Subscriptions Are Attention But What About Blogrolls]".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see [[xoxo-profile]]) the class name "blogroll" for blogroll lists. E.g.
<pre><nowiki>
<ul class="xoxo blogroll">
<li><a href="...">...</a></li>
<li><a href="...">...</a></li>
</ul>
</nowiki></pre>

Note that a blogroll is a superset of a subscription list.

==== Subscription information ====
Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

* An [http://www.opmlmanager.com/outliner/neuraxon77 example] of OPML to a XOXO list w/ expand/collapse folders

===== Possible XOXO blogs+feeds markup =====

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<pre><nowiki>
<ul class="xoxo blogroll">
<li>
<a href="blogURL1">Blog Name 1</a>
<a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
</li>
<li>
<a href="blogURL2">Blog Name 2</a>
<a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
<a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
</li>
</ul>
</nowiki></pre>

CSS styling could make this as pretty or not as desired.

See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]

=== Wishlists ===

Background: See L.M. Orchard's post: "[http://decafbad.com/blog/2005/11/27/i-wish-it-were-in-xoxo I wish it were in XOXO]"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item?
See: [[listing-examples]], [[listing-formats]], [[listing-brainstorming]]

=== Tagged Links ===

This one seems easier, because you could simply use a list of [[xfolk|xFolk]] items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue workng?

=== Parsing Properties ===

* From HTML spec, the content of both [http://www.w3.org/TR/html4/struct/lists.html#h-10.3 dl], and [http://www.w3.org/TR/html4/struct/lists.html#h-10.2 li] can contain block or inline elements.
** this implies that special properties can include markup.
** naturally, <var>url</var>, <var>type</var>, and <var>rel</var> properties don't fit into this rule logically, but that's a reasonable exception.
* First <code>a</code> element specifies <var>text</var>, <var>url</var>, <var>title</var>, <var>type</var> and <var>rel</var> properties
** If these properties are also defined using <code>dl</code>, they:
*** a. override values, specified in hyperlink
*** b. are ignored -- I ([[DimitriGlazkov]]) am leaning toward this choice
* First <code>dl</code> is treated as a special property set
** how to escape in case <code>dl</code> is content, not property set?
*** possibly like this:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</dl>
</li>
</ul>
</nowiki></pre>

Based on preliminary research, all parsers mentioned in [[xoxo-sample-code]] use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</li>
</ul>

</nowiki></pre>

Will parse the value of <var>text</var> property as <code>XOXO</code>, not <code>Microformats</code>. Not sure yet whether this this th _right thing_.

xoxo-brainstorming

2007-08-06T16:24:49Z

DimitriGlazkov: Code-reading results

= XOXO brainstorming =

== Authors ==

* [http://tantek.com/log Tantek Çelik]
* [[DimitriGlazkov]]

== Example Uses ==

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

=== Blogrolls ===

Background: See L.M. Orchard's post "[http://decafbad.com/blog/2005/11/27/subscriptions-are-attention-but-what-about-blogrolls Subscriptions Are Attention But What About Blogrolls]".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see [[xoxo-profile]]) the class name "blogroll" for blogroll lists. E.g.
<pre><nowiki>
<ul class="xoxo blogroll">
<li><a href="...">...</a></li>
<li><a href="...">...</a></li>
</ul>
</nowiki></pre>

Note that a blogroll is a superset of a subscription list.

==== Subscription information ====
Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

* An [http://www.opmlmanager.com/outliner/neuraxon77 example] of OPML to a XOXO list w/ expand/collapse folders

===== Possible XOXO blogs+feeds markup =====

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<pre><nowiki>
<ul class="xoxo blogroll">
<li>
<a href="blogURL1">Blog Name 1</a>
<a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
</li>
<li>
<a href="blogURL2">Blog Name 2</a>
<a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
<a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
</li>
</ul>
</nowiki></pre>

CSS styling could make this as pretty or not as desired.

See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]

=== Wishlists ===

Background: See L.M. Orchard's post: "[http://decafbad.com/blog/2005/11/27/i-wish-it-were-in-xoxo I wish it were in XOXO]"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item?
See: [[listing-examples]], [[listing-formats]], [[listing-brainstorming]]

=== Tagged Links ===

This one seems easier, because you could simply use a list of [[xfolk|xFolk]] items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue workng?

=== Parsing Properties ===

* From HTML spec, the content of both [http://www.w3.org/TR/html4/struct/lists.html#h-10.3 dl], and [http://www.w3.org/TR/html4/struct/lists.html#h-10.2 li] can contain block or inline elements.
** this implies that special properties can include markup.
** naturally, <var>url</var>, <var>type</var>, and <var>rel</var> properties don't fit into this rule logically, but that's a reasonable exception.
* First <code>a</code> element specifies <var>text</var>, <var>url</var>, <var>title</var>, <var>type</var> and <var>rel</var> properties
** If these properties are also defined using <code>dl</code>, they:
*** a. override values, specified in hyperlink
*** b. are ignored -- I ([[DimitriGlazkov]]) am leaning toward this choice
* First <code>dl</code> is treated as a special property set
** how to escape in case <code>dl</code> is content, not property set?
*** possibly like this:

<pre><nowiki>

<ul>
<li>
<dl>
<dt>text</dt>
<dd>
<dl>
<dt>escaped</dt>
<dd>not a property set</dd>
</dl>
</dd>
</li>
</ul>
</nowiki></pre>

Based on preliminary research, all parser mentioned in [[xoxo-sample-code]] use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:

<pre><nowiki>

<ul>
<li>
<dl>
<a href="http://microformats.org">Microformats</a>
<dt>text</dt>
<dd>XOXO</dd>
</li>
</ul>

</nowiki></pre>

Will parse the value of <var>text</var> property as <code>XOXO</code>.

xoxo

2007-08-06T16:16:26Z

DimitriGlazkov: Added multi-value properties

<h1> XOXO 1.0: Extensible Open XHTML Outlines </h1>

XOXO is a simple, open outline format written in standard XHTML and suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. XOXO is one of several [[microformats|microformat]] open standards.

__TOC__

== Draft Specification 2004-10-01 ==

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

=== Authors ===
* [http://epeus.blogspot.com/ Kevin Marks] ([http://technorati.com Technorati, Inc])
* [http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati, Inc], formerly of [http://microsoft.com/ Microsoft Corporation])
* [http://diveintomark.org/ Mark Pilgrim] ([http://ibm.com IBM])
* [http://www.blogologue.com/ Morten W. Petersen]

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

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

== Preamble ==
When we were discussing [http://developers.technorati.com/wiki/attentionxml Attention.xml], Tantek pointed out that XHTML has everything necessary for semantically expressing outlines and blogroll-like subscriptions in an XML format that is both interactively renderable by browsers and parsable by strict XML engines. This page is here to discuss this idea.

=== Name ===
XOXO stands for eXtensible Open XHTML Outlines, and is pronounced variously as 'ecks oh ecks oh', 'zho-zho', or 'sho-sho'.

== Abstract ==
XOXO is one of several [[microformats]]. This specification defines a new XHTML document type that is based upon the module framework and modules defined in Modularization of XHTML ([http://www.w3.org/TR/xhtml-modularization XHTMLMOD]). The purpose of the XOXO document type is to serve as the basis for XHTML friendly outlines for processing by XML engines and for easy interactive rendering by browsers.

== The XOXO Document Type ==
The XOXO document type is made up of the following XHTML modules. The elements, attributes, and minimal content models associated with these modules are defined in "Modularization of XHTML" ([http://www.w3.org/TR/xhtml-modularization XHTMLMOD]). The elements are listed here for information purposes, but the definitions in "Modularization of XHTML" should be considered definitive. In the on-line version of this document, the module names in the list below link into the definitions of the modules within the current version of "Modularization of XHTML".

[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_structuremodule Structure Module]
body, head, html, title
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_hypertextmodule Hypertext Module]
a
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_listmodule List Module]
dl, dt, dd, ol, ul, li
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_metamodule Metainformation Module]
meta
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_stylemodule Stylesheet Module]
style element
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_styleattributemodule Style Attribute Module]
style attribute
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_linkmodule Link Module]
link
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_legacymodule Legacy Module]
Attribute compact on ol and ul

=== The XOXO Profile ===

See [[xoxo-profile]] for the [http://gmpg.org/xmdp XMDP] profile of XOXO which defines the XOXO values for the class attribute.

== Simple XOXO Fragment ==

=== Markup ===

<pre><nowiki><ol class='xoxo'>
<li>Subject 1
<ol>
<li>subpoint a</li>
<li>subpoint b</li>
</ol>
</li>
<li>Subject 2
<ol compact="compact">
<li>subpoint c</li>
<li>subpoint d</li>
</ol>
</li>
<li>Subject 3
<ol>
<li>subpoint e</li>
</ol>
</li>
</ol>
</nowiki></pre>

=== Sample Rendering ===
<pre><nowiki>
1. Subject 1
a. subpoint a
b. subpoint b
2. Subject 2
3. Subject 3
a. subpoint e
</nowiki></pre>
=== Usage of 'compact' attribute ===

Note the use of the 'compact' attribute to indicate that the subpoints of the headline "Subject 2" are not in an expanded state. The absence of the 'compact' attribute elsewhere indicates that the other headlines are in an expanded state.

=== Possible Default Style Rules for Sample Rendering ===

<pre><nowiki>
ol.xoxo { list-style:decimal; }
ol.xoxo ol { list-style:lower-latin; }
ol[compact="compact"] { display:none; }
</nowiki></pre>

== More Simple Examples ==

MarkP has a set of examples that demonstrates both the simplicity of the markup and the presentational richness that is possible:

* [http://diveintomark.org/public/2004/01/xo-flat.xo simple XO file that can be embedded directly into an XHTML page]
* [http://diveintomark.org/public/2004/01/xo-embeddable.xo XO with nested groups, also directly embeddedable in XHTML]
* [http://diveintomark.org/public/2004/01/xo-standalone.xo XO as a standalone XHTML page] ([http://validator.w3.org/check?uri=http%3A%2F%2Fdiveintomark.org%2Fpublic%2F2004%2F01%2Fxo-standalone.xo valid XHTML])
* [http://diveintomark.org/public/2004/01/xo-with-style.xo XO as a standalone XHTML page, styled with CSS] ([http://validator.w3.org/check?uri=http%3A%2F%2Fdiveintomark.org%2Fpublic%2F2004%2F01%2Fxo-with-style.xo also valid XHTML])
* [http://homepage.mac.com/ctholland/thelab/outlines/ Chris Holland Outline Helper]: tweaked one of above samples, yanked CSS for simplicity, added reference to [http://homepage.mac.com/ctholland/thelab/outlines/outlines.css outlines.css] and [http://homepage.mac.com/ctholland/thelab/outlines/outlines.js outlines.js], pasted a few different combinations of ul/ol/li with the compact attribute.
** in trying to comply with semantic principles the "compact" attribute to ol and ul elements is what drives the display state. Via scripting, i'm setting classes on containing li element for added styling flexibility, though CSS Gurus might be able to replace "li.expanded" in outlines.css with some other CSS selector that says "select an li node that contains an ol node with a 'compact' attribute set".
*** The CSS selector for "an li node that contains an ol node with a 'compact' attribute set" would be 'li ol[compact="compact"]'.

== Properties of Outline Items ==
Outlines typically consist of a hierarchy of points and subpoints. Each of those points (outline items) itself may have some properties (AKA attributes or metadata) that need to be represented. Perhaps the most common additional property on outline items in practice is the URL as demonstrated in Mark Pilgrim's examples above. Even the text label/title of an outline item could be considered a common property. A few such common properties:
* text
* description
* url (often called xmlurl or htmlurl; sometimes called permalink)
* title
* type (hint of the MIME type of the resource indicated by the URL)

In general, properties on an outline item <code><nowiki><li></nowiki></code> are represented by a nested definition list <code><nowiki><dl></nowiki></code>. Strictly speaking, it is the first <code><nowiki><dl></nowiki></code> inside the <code><nowiki><li></nowiki></code> and before any following <code><nowiki><ol></nowiki></code>, <code><nowiki><ul></nowiki></code>, or <code><li></code>, e.g. here is an item "item 1" with a description property (the subpoints are there purely as a point of reference to an earlier example).

<pre><nowiki>
<ol class='xoxo'>
<li>item 1
<dl>
<dt>description</dt>
<dd>This item represents the main point we're trying to make.</dd>
</dl>
<ol>
<li>subpoint a</li>
<li>subpoint b</li>
</ol>
</li>
</nowiki></pre>

=== Special Properties ===
There are a handful of special properties which we are able to represent more directly and conveniently with the semantic XHTML building blocks that we have included, instead of terms in a definition list. Mostly taken from the above list of common properties, these are:
* text, url, title, type, and rel (short for relationship)

If we were to represent them simply as definition terms (including the "description" property from the previous example), they might look something like this:

Example for the sake of discussion only / not a canonical XOXO example:

<pre><nowiki>
<ol class='xoxo'>
<li>
<dl>
<dt>text</dt>
<dd>item 1</dd>
<dt>description</dt>
<dd> This item represents the main point we're trying to make.</dd>
<dt>url</dt>
<dd>http://example.com/more.xoxo</dd>
<dt>title</dt>
<dd>title of item 1</dd>
<dt>type</dt>
<dd>text/xml</dd>
<dt>rel</dt>
<dd>help</dd>
</dl>
</li>
</nowiki></pre>

However, by taking advantage of the semantic <code><a href></code> element, we are able to dramatically simplify the common cases that utilize these properties. From a parser's perspective, this applies to the first <code><a href></code> element directly inside the <code><nowiki><li></nowiki></code>.

Actual XOXO Example:

<pre><nowiki>
<ol class='xoxo'>
<li><a href="http://example.com/more.xoxo"
title="title of item 1"
type="text/xml"
rel="help">item 1</a>

<dl>
<dt>description</dt>
<dd>This item represents the main point we're trying to make.</dd>
</dl>
</li>
</nowiki></pre>

Any other properties are simply added to the definition list in the same way as the "description" property.

=== Multi-value Properties ===

Properties that have multiple values are added using a list, nested inside of the corresponding <code>dl</code> element:

<pre><nowiki>
<ol class='xoxo'>
<li>item 1
<dl>
<dt>multivalproperty1</dt>
<dd><ul>
<li>value-a</li>
<li>value-b</li>
</ul></dd>
</dl>
</li>
</ol>
</nowiki></pre>

== Publishing XOXO ==

XOXO may be published in two forms, valid XHTML, and simple well-formed XML.

=== Valid XHTML XOXO ===

A valid XHTML XOXO page is a complete XHTML document.

<pre><nowiki>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>XOXO page</title>
</head>
<body>
<ol class="xoxo">
<li><a href="URL-one">TEXT-one</a></li>
<li><a href="URL-two">TEXT-two</a></li>
...
</ol>
</body>
</html>
</nowiki></pre>

==== Content-Type ====

Valid XHTML XOXO SHOULD be served with this Content-Type header for maximum browser compatibility.

<pre><nowiki>
Content-Type: text/html; charset=utf-8
</nowiki></pre>

It MUST be served with one of these Content-Type headers:

<pre><nowiki>
Content-Type: text/html; charset=utf-8
Content-Type: application/xhtml+xml
</nowiki></pre>

=== Simple well-formed XML XOXO ===

The root element of a simple well-formed XML XOXO page is either an <code>ol</code> or <code>ul</code> with class name of "xoxo". This variant is ideal for syndication and transclusion into (X)HTML pages with [[rest/ahah|AHAH]].

<pre><nowiki>
<ol class="xoxo">
<li><a href="URL-one">TEXT-one</a></li>
<li><a href="URL-two">TEXT-two</a></li>
...
</ol>
</nowiki></pre>

==== Content-Type ====

Simple well-formed XML XOXO SHOULD be served with this Content-Type header:
<pre><nowiki>
Content-Type: text/xml; charset=utf-8
</nowiki></pre>

It MUST be served with one of these Content-Type headers:

<pre><nowiki>
Content-Type: text/xml; charset=utf-8
Content-Type: application/xml
Content-Type: application/xml; charset=utf-8
</nowiki></pre>

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

There are many wild examples. Nearly every blogroll on the Web can be parsed as XOXO, since they are typically an unordered list of list items of hyperlinks, which is within the XOXO profile. List examples here, when the list becomes too long we can move to a dedicated page.

* [http://api.talis.com/bf/stores/ukbib/services/facet?query=feynman&fields=title%2Csubject&top=10&output=html HTML output from a faceting service for book data]

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

* [http://chneukirchen.org/blog/ Christian Neukirchen] has [http://chneukirchen.org/blog/archive/2006/01/xoxo-rb-0-1-released.html written a xoxo.rb, a XOXO parser and generator for Ruby]
* [http://odeo.com Odeo] publishes users' subscription lists in XOXO. See Ryan King's list [http://odeo.com/profile/RyanKing/xoxo here].
* [http://www.decafbad.com/blog/ Les Orchard] has [http://www.decafbad.com/blog/2005/07/12/xoxo_outliner_experiment written] a [http://www.decafbad.com/2005/07/map-test/tree2.html nice XOXO outline editor in javascript].
* http://homepage.mac.com/ctholland/thelab/outlines/ is a great demonstration of dynamic interactive XOXO with use of "compact" and DHTML to collapse/expand.
* http://tool-man.org/examples/sorting.html is a great demonstration of drag and drop sortable XOXO lists with javascript and CSS.
* http://www.opendarwin.org/~drernie/xoxo-datatypes.html Mapping XOXO to [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html Mac OS X property lists]
* [http://weblog.techno-weenie.net/2005/9/30/if_i_had_a_tumblelog single line of rails to convert XOXO to HTML]

=== Sample Code ===

* See the [[xoxo-sample-code]] page for open source sample code to read and write XOXO files.
* See also the [[xoxo-compact-sample]] page with source for CSS and JS that alters the look and feel of some very plain XOXO to have twiddlable triangles for nested lists that respect the compact attribute as well.

== XOXO Schemas ==
This section is informative.

Note: these may be out of date and require updating to reflect the use of <dl> for annotating XOXO items with arbitrary properties.
* [[DTDs]]
* [http://www.nidelven-it.no/projects/XOXO/xoxo-0.1.tgz Schemas (Relax NG and DTDs)]

== References ==
=== Normative References ===
* [http://www.w3.org/TR/xhtml1 XHTML 1.0]
* [http://www.w3.org/TR/xhtml-modularization XHTMLMOD]
* [http://gmpg.org/xmdp/ XMDP]
* [http://gmpg.org/xfn/ XFN]

=== Informative References ===
This section is '''informative'''.
* [http://developers.technorati.com/wiki/attentionxml Attention.xml]
* [[VoteLinks]]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://opml.scripting.com/spec OPML 1.0]
* Contributed from http://developers.technorati.com/wiki/XOXO

=== Similar Work ===
* [http://dannyayers.com/archives/001961.html XHTML Outlines] - DannyAyers independently came up with idea in 2003 October (just a month or two before Kevin and Tantek independently came up with XOXO) to use a simple profile of XHTML to semantically represent outlines using existing building blocks from XHTML.
* [http://semtext.org/2004-02/ XOW] - making them editable, producing RDF and bookmark lists from them (DannyAyers)

=== Related Reading ===
* [http://patricklogan.blogspot.com/2005/08/lists-really-can-we-expect-better.html Patrick Logan on why OPML and a Microsoft Lists extension are both unnecessary].
* [http://raybenchen.blogspot.com/2005/11/is-crappy-format-worth-saving.html Dr. Tao Chen on why it is better to use XOXO than OPML going forward]

=== Unrelated Reading ===
* [http://www.questionablecontent.net/view.php?comic=493 Questionable Content comic #493] - apparently the Faye character is a fan of XOXO.

=== Promotional Materials / Schwag ===
* There is an entire XOXO clothing and accessories line. [http://www.xoxo.com/home.php Buy XOXO stuff online].

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

* See [[xoxo-brainstorming]] for additional thoughts on how to use XOXO for specific uses.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].
** [http://blogxoxo.blogspot.com/ XOXO Blog]

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

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

xoxo-brainstorming

2007-08-02T19:45:09Z

DimitriGlazkov: tweaking language

xoxo-brainstorming

2007-08-02T19:05:20Z

DimitriGlazkov: bleh, fixing phraseology

xoxo-brainstorming

2007-08-02T19:04:44Z

DimitriGlazkov: Added thoughts on parsing special properties

User:DimitriGlazkov

2007-07-17T21:29:14Z

DimitriGlazkov:

http://glazkov.com/

{{public-domain-release}}

icalendar-implementations

2006-07-03T18:17:13Z

DimitriGlazkov: Minimal importable iCal events for MS Outlook 2003

= iCalendar implementations =

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

This page is here for keeping track of them.

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

== Products ==

=== iCal.app ===

platform: OSX

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Evolution ===

platform: Fedora Core 3

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Sunbird ===

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

platform: XP, others?

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Microsoft Outlook ===

platform: 2003

==== Importing of VEvents ====

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

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

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

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

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

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

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

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

icalendar-implementations

2006-07-03T18:08:01Z

DimitriGlazkov: Added self to contributors

icalendar-implementations

2006-07-03T18:06:35Z

DimitriGlazkov: Detailed documentation of MS Outlook 2003 behavior

= iCalendar implementations =

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

This page is here for keeping track of them.

== Contributors==
* Tantek Çelik

== Products ==

=== iCal.app ===

platform: OSX

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Evolution ===

platform: Fedora Core 3

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Sunbird ===

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

platform: XP, others?

==== subscription handling ====

supports the non-standard "webcal:" protocol

=== Microsoft Outlook ===

platform: 2003

==== Importing of VEvents ====

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

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

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

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

No such restriction is placed on [http://www.imc.org/pdi/vcal-10.txt iCal 1.0] events. So, if <code>VERSION:1.0</code> is output instead of <code>VERSION:2.0</code>, the only required field is <code>DTSTART</code>.

hcalendar-issues

2006-07-03T17:48:53Z

DimitriGlazkov:

= hCalendar Issues =

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

See related [[hcard-issues]].

== Issues ==

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

And add new issues to the top of the list:

* {{OpenIssue}} 2006-03-07 raised by [[User:Ragdoll|Justin McDowell]]
*# ''Issue 1: I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting aquainted with the possibilities of vCalendar.''

* 2006-02-17 raised by [[User:Mark Mansour|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225|here]]
*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
*#* ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar|hCalendar]] spec should say *precisely* how to generate VCALENDAR properties in their absence.
*# How are axis and headers going to be handled?
*#* ACCEPTED. This is documented in [[hcalendar-brainstorming]] but MUST be moved to [[hcalendar|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). Add this as a [[to-do]] for Tantek.
*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
*#* REJECTED. Please RTFM. Searching the [[hcalendar|hCalendar]] spec for *either* "axis" or "headers" would have found the following example in the wild: [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.
*# Should embeded components be allowed? [[RyanKing]] has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
*#* ACCEPTED SPECUPDATE/FAQ. Another [[to-do]] for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted in hCalendar. Current additional candidates: VTODO (many examples of this info on the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by [[hatom|hAtom]]).
*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
*#* ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.
*# The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
<pre>
<a name="myfrag">heading</a>
<div class="vevent">
<div class="description">A nice event</div>
<abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>
</pre>
*#* ACCEPTED. We should clarify to converters how to interpret a fragement id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.
* 2006-02-01 raised by [[RyanKing]]
*# ''Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?''
*#* ACCEPTED. Yes, we should expliclty DROP "vjournal" from [[hcalendar|hCalendar]].
* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
*#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.
*# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
*#* ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
* 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
*# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''.
*#* ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
*# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.'' [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- [[DimitriGlazkov]]
*#* ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
*# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
*#* For more discussion of this, please see [http://microformats.org/wiki/hcalendar-brainstorming#UID_handling hCalendar brainstorming: UID handling]
<pre><nowiki>
<li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
<abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
<abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
<a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
<span class="summary">From the other cal</span>
</a>
<abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
</li></nowiki></pre>
* 2005-09-29 raised by RyanKing
*# ''How does one use ATTENDEE?''
*#* ACCEPTED. Another [[to-do]] for Tantek - document how to use ATTENDEE with [[hcard|hCard]].
* 2005-07-27 raised by Paolo Massa
*# ''I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<span class="vevent">

<a class="url" href="http://www.web2con.com/">

<span class="summary">Web 2.0 Conference</span>:

...

I hope to have been clear but I'm not so sure ;-)''

* 2005-07-21 raised by Neil Jensen
*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''

* 2005-07-11 raised by Kragen
*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk|xFolk]].''
*#* REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#* ACCEPTED. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing]] that documents precisely how user agents are to parse [[hcalendar|hCalendar]] markup.
* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
*# ''There is no copyright statement and no patent statement.''
*#* ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other MicroFormats) with a standard copyright statement and patent statement.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
*#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
*#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
*#* REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
*#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
*# ''There are styling and tooltip issues that are unresolved.''
*#* REJECTED (empty statements). See the [[hcalendar-faq|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
*#* REJECTED (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
*#* ACCEPT-PARTIAL. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
*#* ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats]] specifications in general? (If not, why not?)''
*#** ACCEPTED. Yes, all [[microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
*#*** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
*#**** ACCEPTED. See [[profile-uris]]; this is moving from Tantek's [[to-do]] list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.
* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcalendar]] pages, one sees no collection of real-world publishing of event data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''
* {{OpenIssue}} 2006-04-13 raised by Tantek
*# ''Need to add a section on "Property Exceptions" like that in [[hcard|hCard]] to document how to publish / handle the '''METHOD''' property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert [[hcalendar|hCalendar]] to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default '''METHOD:PUBLISH''' on the '''VCALENDAR''' object in the resultant .ics stream.''

hcalendar-issues

2006-07-03T17:47:51Z

DimitriGlazkov: Suggestion to infer DTSTAMP

= hCalendar Issues =

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

See related [[hcard-issues]].

== Issues ==

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

And add new issues to the top of the list:

* {{OpenIssue}} 2006-03-07 raised by [[User:Ragdoll|Justin McDowell]]
*# ''Issue 1: I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting aquainted with the possibilities of vCalendar.''

* 2006-02-17 raised by [[User:Mark Mansour|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225|here]]
*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
*#* ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar|hCalendar]] spec should say *precisely* how to generate VCALENDAR properties in their absence.
*# How are axis and headers going to be handled?
*#* ACCEPTED. This is documented in [[hcalendar-brainstorming]] but MUST be moved to [[hcalendar|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). Add this as a [[to-do]] for Tantek.
*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
*#* REJECTED. Please RTFM. Searching the [[hcalendar|hCalendar]] spec for *either* "axis" or "headers" would have found the following example in the wild: [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.
*# Should embeded components be allowed? [[RyanKing]] has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
*#* ACCEPTED SPECUPDATE/FAQ. Another [[to-do]] for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted in hCalendar. Current additional candidates: VTODO (many examples of this info on the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by [[hatom|hAtom]]).
*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
*#* ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.
*# The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
<pre>
<a name="myfrag">heading</a>
<div class="vevent">
<div class="description">A nice event</div>
<abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>
</pre>
*#* ACCEPTED. We should clarify to converters how to interpret a fragement id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.
* 2006-02-01 raised by [[RyanKing]]
*# ''Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?''
*#* ACCEPTED. Yes, we should expliclty DROP "vjournal" from [[hcalendar|hCalendar]].
* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
*#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.
*# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
*#* ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
* 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
*# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''.
*#* ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
*# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.'' [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- DimitriGlazkov
*#* ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
*# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
*#* For more discussion of this, please see [http://microformats.org/wiki/hcalendar-brainstorming#UID_handling hCalendar brainstorming: UID handling]
<pre><nowiki>
<li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
<abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
<abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
<a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
<span class="summary">From the other cal</span>
</a>
<abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
</li></nowiki></pre>
* 2005-09-29 raised by RyanKing
*# ''How does one use ATTENDEE?''
*#* ACCEPTED. Another [[to-do]] for Tantek - document how to use ATTENDEE with [[hcard|hCard]].
* 2005-07-27 raised by Paolo Massa
*# ''I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<span class="vevent">

<a class="url" href="http://www.web2con.com/">

<span class="summary">Web 2.0 Conference</span>:

...

I hope to have been clear but I'm not so sure ;-)''

* 2005-07-21 raised by Neil Jensen
*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''

* 2005-07-11 raised by Kragen
*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk|xFolk]].''
*#* REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#* ACCEPTED. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing]] that documents precisely how user agents are to parse [[hcalendar|hCalendar]] markup.
* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
*# ''There is no copyright statement and no patent statement.''
*#* ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other MicroFormats) with a standard copyright statement and patent statement.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
*#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
*#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
*#* REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
*#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
*# ''There are styling and tooltip issues that are unresolved.''
*#* REJECTED (empty statements). See the [[hcalendar-faq|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
*#* REJECTED (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
*#* ACCEPT-PARTIAL. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
*#* ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats]] specifications in general? (If not, why not?)''
*#** ACCEPTED. Yes, all [[microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
*#*** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
*#**** ACCEPTED. See [[profile-uris]]; this is moving from Tantek's [[to-do]] list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.
* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcalendar]] pages, one sees no collection of real-world publishing of event data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''
* {{OpenIssue}} 2006-04-13 raised by Tantek
*# ''Need to add a section on "Property Exceptions" like that in [[hcard|hCard]] to document how to publish / handle the '''METHOD''' property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert [[hcalendar|hCalendar]] to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default '''METHOD:PUBLISH''' on the '''VCALENDAR''' object in the resultant .ics stream.''

hatom

2006-06-20T15:00:30Z

DimitriGlazkov: Added Capital University feed

<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:updated 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>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://www.capital.edu Capital University] uses hAtom 0.1 to mark up the feed of latest posts by student bloggers on its home page.
* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [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])
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)
* [http://quotedprintable.com/pages/scribbish Scribbish] is a Typo theme which uses hAtom.
* [http://rbach.priv.at/hAtom2Atom/Changelog/ hAtom2Atom.xsl’s Changelog] is published as hAtom and Atom.
* [http://federali.st/ federali.st]'s webbed Federalist Papers are each marked up in hAtom.

=== Pre 0.1 hAtom implementations ===
These pages conform to an older draft standard and need to be updated.

* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)

== Implementations ==

This section is '''informative'''.

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

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

hcalendar

2006-06-20T14:58:14Z

DimitriGlazkov: Capital University event feeds example added

<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://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.socaltech.com socalTECH] is a news and information site. Their front page event listing is marked up with hCalendar.
* [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.multipack.co.uk The Multipack] features a vevent for the next meeting information.
* [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://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.
* 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)

== 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://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-06-20T14:47:31Z

DimitriGlazkov: /* 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, 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.

==== 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://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.direction.es/ Direction] uses hCard for contact information.
* [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://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.
* [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,

hcard

2006-06-20T14:47:16Z

DimitriGlazkov: Some examples from academia added

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

==== 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://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/ 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.direction.es/ Direction] uses hCard for contact information.
* [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://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.
* [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,

events

2006-06-09T03:08:46Z

DimitriGlazkov: oops... correcting wiki markup

<h1> Microformats related events </h1>

Please add any microformats related events (specifically, events where there will be talks on microformats) you find here, and we'll add them to the [[hcalendar|hCalendar]] on the [http://microformats.org home page]. Please also create a page for each specific event, where you can list URLs for the event, event details, create an "Attending" section, link to photos afterwards etc. (See [[events/2006-03-01-w3c-plenary-microformats|Microformats panel at W3C Plenary Day]] for a decent example to mimic). Thanks! -[http://tantek.com/ Tantek]

For presenations in particular, there's [[presentations|a seperate wiki page]].

Patterns:
* YYYY-MM-DD: <nowiki>[[events/YYYY-MM-DD-event-session-title Event Session Title]]</nowiki>
* YYYY-MM-DD - YYYY-MM-DD: <nowiki>[[events/YYYY-MM-DD-event-session-title Event Session Title]]</nowiki>

== Upcoming ==
* 2006-06-13: [[events/2006-06-13-where-2-bof|Where 2.0 Microformats BOF II]] - developing a [[directions-examples|directions]] microformat.
* 2006-06-15 - 2006-06-16: @media conference - microformats session
* 2006-06-20: Microformats.org [[events/anniversary/1|one year anniversary!]]
* 2006-06-21: Supernova 2006 Decentralized Data workshop
* 2006-07-11: An Event Apart, NYC. [http://www.aneventapart.com/news/2006/05/tantek_joins.php microformats session]
* ...

== Recent ==
* 2006-03-01: [[events/2006-03-01-w3c-plenary-microformats|Microformats panel at W3C Plenary Day]]
* 2006-03-02: [http://esw.w3.org/topic/SwigAtTp2006 Semantic Web Interest Group meeting at W3C Technical Plenary], specifically, 1.30-3.30pm Dan Connolly on using "GRDDL" to parse microformats
* 2006-03-07: [[events/2006-03-07-etech-microformats|Microformats at O'Reilly ETech]]
* 2006-03-13: [[events/2006-03-13-sxsw-microformats|Microformats at SXSW Interactive]]
* 2006-03-14: [[events/2006-03-14-sxsw-modulet|Convincing Your Company to Embrace Web Standards at SxSW Interactive]]
* 2006-03-20: [[events/2006-03-20-mix06-microformats|Mix06 Keynote with Tim O'Reilly and Bill Gates discussing microformats]]
* 2006-03-21: [[events/2006-03-21-mix06-microformats|Mix06 Microformats session discussions]]
* 2006-03-22: [[events/2006-03-22-mix06-microformats|Mix06 Microformats session discussions]]
* 2006-04-23 - 2006-04-24 [http://cmprofessionals.org/events/summit/#06spring CM Pros Summit] [http://www.nateaune.com Nate Aune] will be presenting a talk "Microformats and the Future of Syndication" from 16:30-17:30 at the Sheraton Palace Hotel in San Francisco.
* 2006-05-16 - 2006-05-19: [http://xtech.org/ XTech 2006 Conference]
** 2006-05-16 09:00-12:30: Half-day tutorial: [http://xtech06.usefulinc.com/content/tutorials#microformats Microformats from the Ground Up] at Volmer 3. [http://theryanking.com/presentations/2006/xtech/tutorial/ presentation slides].
** 2006-05-18 [http://xtech06.usefulinc.com/schedule#s2006-05-18-14:00 14:00-14:45]: [http://xtech06.usefulinc.com/schedule/detail/148 The Intelligent Design of Microformats]
* 2006-05-22: [http://refreshedinburgh.org/talks/introducing-microformats-your-web-site/ Refresh Edinburgh] Introducing microformats into your website, May 22nd 8pm-9pm.
* 2006-05-23 - 2006-05-26: [http://www2006.org/ www2006]
** 2006-05-23: [http://www.blogpulse.com/www2006-workshop/ WWE 2006 | 3rd Annual Workshop on the Weblogging Ecosystem] - call for papers is now open, and explicitly includes "microformats".
** 2006-05-24:
*** All day: "Microformats: a Pragmatic Path to the Semantic Web" poster (Poster ID 116, by Rohit Khare and Tantek Çelik) presentation at Strathblane Hall on Level 0 opposite the main entrance.
*** 14:00-15:30: Brian Suda will be presenting a microformats demo ([http://www2006.org/programme/item.php?id=d7 Microformats, converting XHTML to vCards and vCalendars]) in the NextWave developer track session. More information about the presentation is available at [[events/www2006]].
** 2006-05-25 10:30-13:30: Molly E. Holzschlag will be presenting a half-day "Practical Microformats" developer tutorial.
* 2006-05-30 - 2006-05-31: [http://netsquared.org NetSquared] [http://netsquared.org/conference/ Conference]
** 2006-05-30 4:15pm-5:10pm: : [http://netsquared.org/conference/conference-sessions/Mashups A web more woven - the alchemy and practicalities of Mashups]. Tantek Çelik, Taylor McKnight and Chris Messina will discuss the core utility of microformats to publish and share data for/with mashups and other applications. Location: Jordan room, Cisco Systems' Vineyard Conference Center, 260 E. Tasman Drive, San Jose, CA.
** Ryan King has been asked to present on microformats.
* 2006-06-08 [http://glazkov.com/resources/presentations/2006-06-08-microformats/ Microformats]. [[DimitriGlazkov|Dimitri Glazkov]] talks about microformats at [http://ipsaonline.com/ IPSA] monthly meeting.

== Quicktime Broadcaster Notes ==

For setting up a mac laptop with an iSight and QT Broadcaster in order to publish live audio/video from events.

# Make sure you have the necessary equipment and software installed
#* A Macintosh running OSX 10.3.9 or later
#* Quicktime 7 - get it from http://www.apple.com/quicktime/
#* Quicktime Broadcaster - get it from http://www.apple.com/quicktime/broadcaster/
#* An iSight or digital video camera with firewire connection
# Get a broadcast template document from someone (see KevinMarks for example)
# Open that, then change the info in the 'Network' pane that has his name etc in it.
# Check the video and audio panes are using your iSight
# Another tip is that the standalone thingy for the iSight can be more useful than the screen-top one if you have a desk, as that way it picks up less typing noise and wobbles
# I find plugging in headphones is a good idea, as you can then monitor and not get howlround

http://microformats.org/media/broadcast.mov

events

2006-06-09T03:05:35Z

DimitriGlazkov:

<h1> Microformats related events </h1>

Please add any microformats related events (specifically, events where there will be talks on microformats) you find here, and we'll add them to the [[hcalendar|hCalendar]] on the [http://microformats.org home page]. Please also create a page for each specific event, where you can list URLs for the event, event details, create an "Attending" section, link to photos afterwards etc. (See [[events/2006-03-01-w3c-plenary-microformats|Microformats panel at W3C Plenary Day]] for a decent example to mimic). Thanks! -[http://tantek.com/ Tantek]

For presenations in particular, there's [[presentations|a seperate wiki page]].

Patterns:
* YYYY-MM-DD: <nowiki>[[events/YYYY-MM-DD-event-session-title Event Session Title]]</nowiki>
* YYYY-MM-DD - YYYY-MM-DD: <nowiki>[[events/YYYY-MM-DD-event-session-title Event Session Title]]</nowiki>

== Upcoming ==
* 2006-06-13: [[events/2006-06-13-where-2-bof|Where 2.0 Microformats BOF II]] - developing a [[directions-examples|directions]] microformat.
* 2006-06-15 - 2006-06-16: @media conference - microformats session
* 2006-06-20: Microformats.org [[events/anniversary/1|one year anniversary!]]
* 2006-06-21: Supernova 2006 Decentralized Data workshop
* 2006-07-11: An Event Apart, NYC. [http://www.aneventapart.com/news/2006/05/tantek_joins.php microformats session]
* ...

== Recent ==
* 2006-03-01: [[events/2006-03-01-w3c-plenary-microformats|Microformats panel at W3C Plenary Day]]
* 2006-03-02: [http://esw.w3.org/topic/SwigAtTp2006 Semantic Web Interest Group meeting at W3C Technical Plenary], specifically, 1.30-3.30pm Dan Connolly on using "GRDDL" to parse microformats
* 2006-03-07: [[events/2006-03-07-etech-microformats|Microformats at O'Reilly ETech]]
* 2006-03-13: [[events/2006-03-13-sxsw-microformats|Microformats at SXSW Interactive]]
* 2006-03-14: [[events/2006-03-14-sxsw-modulet|Convincing Your Company to Embrace Web Standards at SxSW Interactive]]
* 2006-03-20: [[events/2006-03-20-mix06-microformats|Mix06 Keynote with Tim O'Reilly and Bill Gates discussing microformats]]
* 2006-03-21: [[events/2006-03-21-mix06-microformats|Mix06 Microformats session discussions]]
* 2006-03-22: [[events/2006-03-22-mix06-microformats|Mix06 Microformats session discussions]]
* 2006-04-23 - 2006-04-24 [http://cmprofessionals.org/events/summit/#06spring CM Pros Summit] [http://www.nateaune.com Nate Aune] will be presenting a talk "Microformats and the Future of Syndication" from 16:30-17:30 at the Sheraton Palace Hotel in San Francisco.
* 2006-05-16 - 2006-05-19: [http://xtech.org/ XTech 2006 Conference]
** 2006-05-16 09:00-12:30: Half-day tutorial: [http://xtech06.usefulinc.com/content/tutorials#microformats Microformats from the Ground Up] at Volmer 3. [http://theryanking.com/presentations/2006/xtech/tutorial/ presentation slides].
** 2006-05-18 [http://xtech06.usefulinc.com/schedule#s2006-05-18-14:00 14:00-14:45]: [http://xtech06.usefulinc.com/schedule/detail/148 The Intelligent Design of Microformats]
* 2006-05-22: [http://refreshedinburgh.org/talks/introducing-microformats-your-web-site/ Refresh Edinburgh] Introducing microformats into your website, May 22nd 8pm-9pm.
* 2006-05-23 - 2006-05-26: [http://www2006.org/ www2006]
** 2006-05-23: [http://www.blogpulse.com/www2006-workshop/ WWE 2006 | 3rd Annual Workshop on the Weblogging Ecosystem] - call for papers is now open, and explicitly includes "microformats".
** 2006-05-24:
*** All day: "Microformats: a Pragmatic Path to the Semantic Web" poster (Poster ID 116, by Rohit Khare and Tantek Çelik) presentation at Strathblane Hall on Level 0 opposite the main entrance.
*** 14:00-15:30: Brian Suda will be presenting a microformats demo ([http://www2006.org/programme/item.php?id=d7 Microformats, converting XHTML to vCards and vCalendars]) in the NextWave developer track session. More information about the presentation is available at [[events/www2006]].
** 2006-05-25 10:30-13:30: Molly E. Holzschlag will be presenting a half-day "Practical Microformats" developer tutorial.
* 2006-05-30 - 2006-05-31: [http://netsquared.org NetSquared] [http://netsquared.org/conference/ Conference]
** 2006-05-30 4:15pm-5:10pm: : [http://netsquared.org/conference/conference-sessions/Mashups A web more woven - the alchemy and practicalities of Mashups]. Tantek Çelik, Taylor McKnight and Chris Messina will discuss the core utility of microformats to publish and share data for/with mashups and other applications. Location: Jordan room, Cisco Systems' Vineyard Conference Center, 260 E. Tasman Drive, San Jose, CA.
** Ryan King has been asked to present on microformats.
* 2006-06-08 [[http://glazkov.com/resources/presentations/2006-06-08-microformats/|Microformats]. Dimitri Glazkov talks about Microformats at [[http://ipsaonline.com/|IPSA]] monthly meeting.

== Quicktime Broadcaster Notes ==

For setting up a mac laptop with an iSight and QT Broadcaster in order to publish live audio/video from events.

# Make sure you have the necessary equipment and software installed
#* A Macintosh running OSX 10.3.9 or later
#* Quicktime 7 - get it from http://www.apple.com/quicktime/
#* Quicktime Broadcaster - get it from http://www.apple.com/quicktime/broadcaster/
#* An iSight or digital video camera with firewire connection
# Get a broadcast template document from someone (see KevinMarks for example)
# Open that, then change the info in the 'Network' pane that has his name etc in it.
# Check the video and audio panes are using your iSight
# Another tip is that the standalone thingy for the iSight can be more useful than the screen-top one if you have a desk, as that way it picks up less typing noise and wobbles
# I find plugging in headphones is a good idea, as you can then monitor and not get howlround

http://microformats.org/media/broadcast.mov

DimitriGlazkov

2006-03-22T21:48:45Z

DimitriGlazkov:

#REDIRECT [[User:DimitriGlazkov]]

DimitriGlazkov

2006-03-22T21:48:05Z

DimitriGlazkov:

[http://glazkov.com/ Dimitri Glazkov]

hatom-issues

2006-03-22T21:46:27Z

DimitriGlazkov: /* Entry Author (atom: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' 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...

== hAtom 0.2 ==

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

events/2006-03-21-mix06-microformats

2006-03-22T12:49:41Z

DimitriGlazkov: /* Lessons from the Trenches */

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

"Lessons from the Trenches: Engineering Great AJAX Experiences"

11am-12:15pm

Presenter: [http://spaces.msn.com/siteexperts/ Scott Isaacs]

Slides: [http://www.weblogging.com/decks/lessons.ppt PowerPoint Document]

Notes/Quotes:
* taken by Tantek Çelik live at the event into #mix06 on irc.freenode.net
* cleaned up and archived here by Dimitri Glazkov

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* '''"microformats are another key aspect of Web 2.0"*'''
* '''hCard for contacts, start with class="vcard"'''
* '''similarly use hCalendar for events'''
* '''what Live Clipboard is a use of microformats for integrating your data'''
* (starts demo)
* '''starting with just the microformat -- "key part of the ecosystem for remixing the Web"'''
* '''"I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"'''
* '''"then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"'''
* '''dynamic recognition of microformats on the page'''
* '''"any microformat on the page, I want to make copyable"'''
** "I wanted to copy the hCalendar"
** "I copied it from IE"
** "I went to Firefox"
** "and I pasted"
** "and the event item shows up on a page viewed in Firefox"
** "I can copy and paste this whereever I want"
** "I can copy and paste from Eventful"
** '''"I can do the same thing with other microformats on the page"'''
** "I can copy a contact from the IE page ?and paste into that same page that I pasted the event"
* '''"all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"'''
* '''if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets'''
* '''start exploring using microformats in your web pages'''
* '''we can start establishing an ecosystem of relevant data'''
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

=== X-Browser Development ===
* Minimize browser specific code in the business logic
* Abstract and centralize API differences
* We extend Firefox and Opera DOM to be compatible with IE
* CSS Differences - Avoid Hacks
* We classify and override via standard selectors
* HTML class="Mozilla M1 D5 Windows"
* Body {margin:10px}
* .Mozilla Body {margin:5px} /* Override Mozilla */
* (hmm... this is quite clever and much more readable)
* ... missed slide ...
* demo of Scott's blog
=== Back Button And Addressability ===
* Users expect the web to work (I love that line)
* Demo: MSN Spaces, Windows Live
* Travelog (History stack) is hard
* Windows Live beta
* back button works
* you can change the hash of the URL [fragment identifier] without reloading the URL
* and thus keep back button working
=== Accessibiliy ===
* Web Accessibility is challenging
* "Use HTML semantics appropriately"
* (wow how far semantic HTML awareness has come in the past four years)
* HTML Accessibility
* Always use structural semantics to establish "role"
* E.g., Hn, Label, TH (table headers), lists, etc.
* (rather than nested DIVs)

=== Building Web Applications ===
...

=== Q&A ===

* Q: What kills JavaScript perf is memory leaks in the browser
* IE6 has some leaks
* if you create a circular reference between a document object and a javascript object then it won't go away

* Q: mashups with SSL
* A: interesting challenge. the real question is how do we securely integrate in a way that is trusted by partners and customers? you have to go entirely HTTPS across the board

* Q: are you familiar with the DOJO toolkit? it solves a lot of the problems memory leaks, back button
* A: haven't looked too deeply at DOJO. we have a system where objects get created and destroyed all the time. not sure if they do document level garbage collection or what.

* Q: about Atlas
* A: ...

* Q: about using AJAX to build a 24fps videogame
* A: (heh)

* Q: is there someway we could have a simple lean AJAX request?
* A: ...

* Q: what is wrong with using iframes?
* A: 1. themes won't work with the iframe ''this is ASP.NET-specific reference'' --[[DimitriGlazkov]]
* A: 2. iframes consume a lot of memory (read: Trident instance) on the order of 20 megabytes of memory (YIKES!)
* A: 3. security

events/2006-03-21-mix06-microformats

2006-03-22T12:48:41Z

DimitriGlazkov: /* Lessons from the Trenches */

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

"Lessons from the Trenches: Engineering Great AJAX Experiences"

11am-12:15pm

Presenter: [http://spaces.msn.com/siteexperts/ Scott Isaacs]
Slides: [http://www.weblogging.com/decks/lessons.ppt PowerPoint Document]

Notes/Quotes:
* taken by Tantek Çelik live at the event into #mix06 on irc.freenode.net
* cleaned up and archived here by Dimitri Glazkov

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* '''"microformats are another key aspect of Web 2.0"*'''
* '''hCard for contacts, start with class="vcard"'''
* '''similarly use hCalendar for events'''
* '''what Live Clipboard is a use of microformats for integrating your data'''
* (starts demo)
* '''starting with just the microformat -- "key part of the ecosystem for remixing the Web"'''
* '''"I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"'''
* '''"then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"'''
* '''dynamic recognition of microformats on the page'''
* '''"any microformat on the page, I want to make copyable"'''
** "I wanted to copy the hCalendar"
** "I copied it from IE"
** "I went to Firefox"
** "and I pasted"
** "and the event item shows up on a page viewed in Firefox"
** "I can copy and paste this whereever I want"
** "I can copy and paste from Eventful"
** '''"I can do the same thing with other microformats on the page"'''
** "I can copy a contact from the IE page ?and paste into that same page that I pasted the event"
* '''"all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"'''
* '''if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets'''
* '''start exploring using microformats in your web pages'''
* '''we can start establishing an ecosystem of relevant data'''
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

=== X-Browser Development ===
* Minimize browser specific code in the business logic
* Abstract and centralize API differences
* We extend Firefox and Opera DOM to be compatible with IE
* CSS Differences - Avoid Hacks
* We classify and override via standard selectors
* HTML class="Mozilla M1 D5 Windows"
* Body {margin:10px}
* .Mozilla Body {margin:5px} /* Override Mozilla */
* (hmm... this is quite clever and much more readable)
* ... missed slide ...
* demo of Scott's blog
=== Back Button And Addressability ===
* Users expect the web to work (I love that line)
* Demo: MSN Spaces, Windows Live
* Travelog (History stack) is hard
* Windows Live beta
* back button works
* you can change the hash of the URL [fragment identifier] without reloading the URL
* and thus keep back button working
=== Accessibiliy ===
* Web Accessibility is challenging
* "Use HTML semantics appropriately"
* (wow how far semantic HTML awareness has come in the past four years)
* HTML Accessibility
* Always use structural semantics to establish "role"
* E.g., Hn, Label, TH (table headers), lists, etc.
* (rather than nested DIVs)

=== Building Web Applications ===
...

=== Q&A ===

* Q: What kills JavaScript perf is memory leaks in the browser
* IE6 has some leaks
* if you create a circular reference between a document object and a javascript object then it won't go away

* Q: mashups with SSL
* A: interesting challenge. the real question is how do we securely integrate in a way that is trusted by partners and customers? you have to go entirely HTTPS across the board

* Q: are you familiar with the DOJO toolkit? it solves a lot of the problems memory leaks, back button
* A: haven't looked too deeply at DOJO. we have a system where objects get created and destroyed all the time. not sure if they do document level garbage collection or what.

* Q: about Atlas
* A: ...

* Q: about using AJAX to build a 24fps videogame
* A: (heh)

* Q: is there someway we could have a simple lean AJAX request?
* A: ...

* Q: what is wrong with using iframes?
* A: 1. themes won't work with the iframe ''this is ASP.NET-specific reference'' --[[DimitriGlazkov]]
* A: 2. iframes consume a lot of memory (read: Trident instance) on the order of 20 megabytes of memory (YIKES!)
* A: 3. security

events/2006-03-21-mix06-microformats

2006-03-21T20:30:29Z

DimitriGlazkov: /* Q&A */

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

11am-12:15pm

[http://spaces.msn.com/siteexperts/ Scott Isaacs]

Notes/Quotes:

=== Lessons from the Trenches: Engineering Great AJAX Experiences ===

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* '''"microformats are another key aspect of Web 2.0"*'''
* '''hCard for contacts, start with class="vcard"'''
* '''similarly use hCalendar for events'''
* '''what Live Clipboard is a use of microformats for integrating your data'''
* (starts demo)
* '''starting with just the microformat -- "key part of the ecosystem for remixing the Web"'''
* '''"I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"'''
* '''"then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"'''
* '''dynamic recognition of microformats on the page'''
* '''"any microformat on the page, I want to make copyable"'''
** "I wanted to copy the hCalendar"
** "I copied it from IE"
** "I went to Firefox"
** "and I pasted"
** "and the event item shows up on a page viewed in Firefox"
** "I can copy and paste this whereever I want"
** "I can copy and paste from Eventful"
** '''"I can do the same thing with other microformats on the page"'''
** "I can copy a contact from the IE page ?and paste into that same page that I pasted the event"
* '''"all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"'''
* '''if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets'''
* '''start exploring using microformats in your web pages'''
* '''we can start establishing an ecosystem of relevant data'''
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

=== X-Browser Development ===
* Minimize browser specific code in the business logic
* Abstract and centralize API differences
* We extend Firefox and Opera DOM to be compatible with IE
* CSS Differences - Avoid Hacks
* We classify and override via standard selectors
* HTML class="Mozilla M1 D5 Windows"
* Body {margin:10px}
* .Mozilla Body {margin:5px} /* Override Mozilla */
* (hmm... this is quite clever and much more readable)
* ... missed slide ...
* demo of Scott's blog
=== Back Button And Addressability ===
* Users expect the web to work (I love that line)
* Demo: MSN Spaces, Windows Live
* Travelog (History stack) is hard
* Windows Live beta
* back button works
* you can change the hash of the URL [fragment identifier] without reloading the URL
* and thus keep back button working
=== Accessibiliy ===
* Web Accessibility is challenging
* "Use HTML semantics appropriately"
* (wow how far semantic HTML awareness has come in the past four years)
* HTML Accessibility
* Always use structural semantics to establish "role"
* E.g., Hn, Label, TH (table headers), lists, etc.
* (rather than nested DIVs)

=== Building Web Applications ===
...

=== Q&A ===

* Q: What kills JavaScript perf is memory leaks in the browser
* IE6 has some leaks
* if you create a circular reference between a document object and a javascript object then it won't go away

* Q: mashups with SSL
* A: interesting challenge. the real question is how do we securely integrate in a way that is trusted by partners and customers? you have to go entirely HTTPS across the board

* Q: are you familiar with the DOJO toolkit? it solves a lot of the problems memory leaks, back button
* A: haven't looked too deeply at DOJO. we have a system where objects get created and destroyed all the time. not sure if they do document level garbage collection or what.

* Q: about Atlas
* A: ...

* Q: about using AJAX to build a 24fps videogame
* A: (heh)

* Q: is there someway we could have a simple lean AJAX request?
* A: ...

* Q: what is wrong with using iframes?
* A: 1. themes won't work with the iframe ''this is ASP.NET-specific reference'' --[[DimitriGlazkov]]
* A: 2. iframes consume a lot of memory (read: Trident instance) on the order of 20 megabytes of memory (YIKES!)
* A: 3. security

events/2006-03-21-mix06-microformats

2006-03-21T20:29:56Z

DimitriGlazkov:

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

11am-12:15pm

[http://spaces.msn.com/siteexperts/ Scott Isaacs]

Notes/Quotes:

=== Lessons from the Trenches: Engineering Great AJAX Experiences ===

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* '''"microformats are another key aspect of Web 2.0"*'''
* '''hCard for contacts, start with class="vcard"'''
* '''similarly use hCalendar for events'''
* '''what Live Clipboard is a use of microformats for integrating your data'''
* (starts demo)
* '''starting with just the microformat -- "key part of the ecosystem for remixing the Web"'''
* '''"I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"'''
* '''"then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"'''
* '''dynamic recognition of microformats on the page'''
* '''"any microformat on the page, I want to make copyable"'''
** "I wanted to copy the hCalendar"
** "I copied it from IE"
** "I went to Firefox"
** "and I pasted"
** "and the event item shows up on a page viewed in Firefox"
** "I can copy and paste this whereever I want"
** "I can copy and paste from Eventful"
** '''"I can do the same thing with other microformats on the page"'''
** "I can copy a contact from the IE page ?and paste into that same page that I pasted the event"
* '''"all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"'''
* '''if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets'''
* '''start exploring using microformats in your web pages'''
* '''we can start establishing an ecosystem of relevant data'''
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

=== X-Browser Development ===
* Minimize browser specific code in the business logic
* Abstract and centralize API differences
* We extend Firefox and Opera DOM to be compatible with IE
* CSS Differences - Avoid Hacks
* We classify and override via standard selectors
* HTML class="Mozilla M1 D5 Windows"
* Body {margin:10px}
* .Mozilla Body {margin:5px} /* Override Mozilla */
* (hmm... this is quite clever and much more readable)
* ... missed slide ...
* demo of Scott's blog
=== Back Button And Addressability ===
* Users expect the web to work (I love that line)
* Demo: MSN Spaces, Windows Live
* Travelog (History stack) is hard
* Windows Live beta
* back button works
* you can change the hash of the URL [fragment identifier] without reloading the URL
* and thus keep back button working
=== Accessibiliy ===
* Web Accessibility is challenging
* "Use HTML semantics appropriately"
* (wow how far semantic HTML awareness has come in the past four years)
* HTML Accessibility
* Always use structural semantics to establish "role"
* E.g., Hn, Label, TH (table headers), lists, etc.
* (rather than nested DIVs)

=== Building Web Applications ===
...

=== Q&A ===

* Q: What kills JavaScript perf is memory leaks in the browser
* IE6 has some leaks
* if you create a circular reference between a document object and a javascript object then it won't go away

* Q: mashups with SSL
* A: interesting challenge. the real question is how do we securely integrate in a way that is trusted by partners and customers? you have to go entirely HTTPS across the board

* Q: are you familiar with the DOJO toolkit? it solves a lot of the problems memory leaks, back button
* A: haven't looked too deeply at DOJO. we have a system where objects get created and destroyed all the time. not sure if they do document level garbage collection or what.

* Q: about Atlas
* A: ...

* Q: about using AJAX to build a 24fps videogame
* A: (heh)

* Q: is there someway we could have a simple lean AJAX request?
* ...

* Q: what is wrong with using iframes?
* A: 1. themes won't work with the iframe ''this is ASP.NET-specific reference'' --[[DimitriGlazkov]]
* A: 2. iframes consume a lot of memory (read: Trident instance) on the order of 20 megabytes of memory (YIKES!)
* A: 3. security

events/2006-03-21-mix06-microformats

2006-03-21T20:16:47Z

DimitriGlazkov: formatting changes

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

11am-12:15pm

[[http://spaces.msn.com/siteexperts/}Scott Isaa]]

Notes/Quotes:

=== Lessons from the Trenches: Engineering Great AJAX Experiences ===

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* '''"microformats are another key aspect of Web 2.0"*'''
* '''hCard for contacts, start with class="vcard"'''
* '''similarly use hCalendar for events'''
* '''what Live Clipboard is a use of microformats for integrating your data'''
* (starts demo)
* '''starting with just the microformat -- "key part of the ecosystem for remixing the Web"'''
* '''"I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"'''
* '''"then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"'''
* '''dynamic recognition of microformats on the page'''
* '''"any microformat on the page, I want to make copyable"'''
** "I wanted to copy the hCalendar"
** "I copied it from IE"
** "I went to Firefox"
** "and I pasted"
** "and the event item shows up on a page viewed in Firefox"
** "I can copy and paste this whereever I want"
** "I can copy and paste from Eventful"
** '''"I can do the same thing with other microformats on the page"'''
** "I can copy a contact from the IE page ?and paste into that same page that I pasted the event"
* '''"all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"'''
* '''if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets'''
* '''start exploring using microformats in your web pages'''
* '''we can start establishing an ecosystem of relevant data'''
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

events/2006-03-21-mix06-microformats

2006-03-21T20:13:36Z

DimitriGlazkov:

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

11am-12:15pm

[[http://spaces.msn.com/siteexperts/}Scott Isaa]]

Notes/Quotes:

=== Lessons from the Trenches: Engineering Great AJAX Experiences ===

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* *"microformats are another key aspect of Web 2.0"*
* *hCard for contacts, start with class="vcard"*
* *similarly use hCalendar for events*
* *what Live Clipboard is a use of microformats for integrating your data*
* (starts demo)
* *starting with just the microformat -- "key part of the ecosystem for remixing the Web"*
* *"I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"*
* *"then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"*
* *dynamic recognition of microformats on the page*
* *"any microformat on the page, I want to make copyable"*
** *"I wanted to copy the hCalendar"*
** *"I copied it from IE"*
** *"I went to Firefox"*
** *"and I pasted"*
** *"and the event item shows up on a page viewed in Firefox"*
** *"I can copy and paste this whereever I want"*
** *"I can copy and paste from Eventful"*
** *"I can do the same thing with other microformats on the page"*
** *"I can copy a contact from the IE page ?and paste into that same page that I pasted the event"*
* *"all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"*
* *if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets*
* *start exploring using microformats in your web pages*
* *we can start establishing an ecosystem of relevant data*
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

events/2006-03-21-mix06-microformats

2006-03-21T20:06:14Z

DimitriGlazkov:

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

11am-12:15pm

Scott Isaacs

Notes/Quotes:

=== Lessons from the Trenches: Engineering Great AJAX Experiences ===

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* "microformats are another key aspect of Web 2.0"
* hCard for contacts, start with class="vcard"
* similarly use hCalendar for events
* what Live Clipboard is a use of microformats for integrating your data
* (starts demo)
* starting with just the microformat -- "key part of the ecosystem for remixing the Web"
* "I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"
* "then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"
* dynamic recognition of microformats on the page
* "any microformat on the page, I want to make copyable"
** "I wanted to copy the hCalendar"
** "I copied it from IE"
** "I went to Firefox"
** "and I pasted"
** "and the event item shows up on a page viewed in Firefox"
** "I can copy and paste this whereever I want"
** "I can copy and paste from Eventful"
** "I can do the same thing with other microformats on the page"
** "I can copy a contact from the IE page ?and paste into that same page that I pasted the event"
* "all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"
* if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets
* start exploring using microformats in your web pages
* we can start establishing an ecosystem of relevant data
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

events/2006-03-21-mix06-microformats

2006-03-21T20:04:31Z

DimitriGlazkov:

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

11am-12:15pm

Scott Isaacs

"Lessons from the Trenches: Engineering Great AJAX Experiences"

Notes/Quotes:

=== Modern Development Patterns ===
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior

=== Live Clipboard Demo ===
* "microformats are another key aspect of Web 2.0"
* hCard for contacts, start with class="vcard"
* similarly use hCalendar for events
* what Live Clipboard is a use of microformats for integrating your data
* (starts demo)
* starting with just the microformat -- "key part of the ecosystem for remixing the Web"
* "I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"
* "then I'm going to specify the resources to bind to it, ex: clipControl.js and .css"
* dynamic recognition of microformats on the page
* "any microformat on the page, I want to make copyable"
** "I wanted to copy the hCalendar"
** "I copied it from IE"
** "I went to Firefox"
** "and I pasted"
** "and the event item shows up on a page viewed in Firefox"
** "I can copy and paste this whereever I want"
** "I can copy and paste from Eventful"
** "I can do the same thing with other microformats on the page"
** "I can copy a contact from the IE page ?and paste into that same page that I pasted the event"
* "all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"
* if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets
* start exploring using microformats in your web pages
* we can start establishing an ecosystem of relevant data
=== XML Proxying And Scalability ===
=== Web Service Integration ===
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
* but parsing a several 100k document will take upwards of 400ms
* and that is too long
* user thinks browser has locked up
* explore other approaches such as JSON to gain the most efficiences
efficiency
=== Optimizing the Network ===
* AJAX-style applications can become very chatty
...
=== Be Wary Of Security ===
* "could probably spend an hour on this one slide, but will try not to"
* XSS is an industry challenge we all need to address more
*as you start exposing services at the edge, XSS becomes a much bigger deal
* e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store
* Define a standard UI feedback metaphor and stick to it
* (missed slide)
=== Prioritizing Network Requests ===
* AJAX Scenario
* Your page is preloading images
* User clicks "Buy It" from ...

=== Code/Resource Deveployment ===
* More Interactivity = More Code = Slower Site (script are executed synchronously serially)
* How do you build sites with lots of componenets
* How do you build a "portal" where the user controls the scope of the application
* How do you efficiently deploy the necessary code and resources?
* Understand how the browser works
* Scripts included on the page block and load one at a time
* Large number of script blocks can greatly stall loading
* System for deploying code
* Patterns allow component resources to load in any order
* Deployed code asynchronously leveraging all available connections
* Prioritize the loading of components
* Never expire static content (change the URL to break the cache)

events/2006-03-21-mix06-microformats

2006-03-21T19:51:14Z

DimitriGlazkov: first dump

= Microformats discussions at Mix06 =

March 21st, 2006

== Lessons from the Trenches ==

11am-12:15pm

Scott Isaacs

"Lessons from the Trenches: Engineering Great AJAX Experiences"

Notes/Quotes:

"Modern Development Patterns"*
* Apply OO principles to web development
* Shared methodology with Atlas
* Namespaces, Encapsulation, Inheritance, Object Lifecycle
* Separate semantics, presentation, and behavior
"Live Clipboard Demo"
* microformats are another key aspect of Web 2.0
* hCard for contacts, start with class="vcard"
* similarly use hCalendar for events
* what Live Clipboard is a use of microformats for integrating your data
* (starts demo)
* "Live Clipboard Demo"
* starting with just the microformat
* "key part of the ecosystem for remixing the Web
* "I can basically say anything on the page that has class name vcard, I'm going to bind one of those Live Clipboard container objects to it"
* "then I'm going to specify the resources to bind to it, ex: clipControl.js and .css
* dynamic recognition of microformats on the page
* any microformat on the page, I want to make copyable
* I wanted to copy the hCalendar
* I copied it from IE
* I went to Firefox
* and I pasted
* and the event item shows up on a page viewed in Firefox
* I can copy and paste this whereever I want
* I can copy and paste from Eventful
* I can do the same thing with other microformats on the page
* I can copy a contact from the IE page and paste into that same page that I pasted the event
* "all the contacts in Hotmail will be hCard automatically remixable into the rest of the Web"
* if you start building gadgets with microformats, we'll make them automatically remixable with other gadgets
* start exploring using microformats in your web pages
* we can start establishing an ecosystem of relevant data
"XML Proxying And Scalability"
"Web Service Integration"
* Do not want to continually parse XML
* we don't want to deal with SOAP envelopes on the client
* instead, we build javascript proxies
* Desire a more natural and efficient approach
* Web Services generate JavaScript proxies: WeatherService.requestWeatherReport(strLocation,onReceipt)
* Use generic format for transport (e.g., JSON)
* Incoming requests marshaled to native server format and outgoing responses to client format
* Use xmlHttpRequest to access the network, but the wire format is transparent to the application
* Use raw XML for "documents" (e.g. RSS)
but parsing a several 100k document will take upwards of 400ms
and that is too long
user thinks browser has locked up
explore other approaches such as JSON to gain the most efficiences
efficiency
"Optimizing the Network"
* AJAX-style applications can become very chatty
...
"Be Wary Of Security"
could probably spend an hour on this one slide, but will try not to
XSS is an industry challenge we all need to address more
as you start exposing services at the edge, XSS becomes a much bigger deal
e.g. Gmail, within 3 days, coders developed an API to use Gmail as a disk store

hcard-brainstorming

2006-02-22T19:05:57Z

DimitriGlazkov: /* Implied "FN and N" Optimization (proposal) */

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

== Examples ==

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

=== Using RFC2806 with hCard ===

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

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

It is practical to write your tel number like this.

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

or even

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

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

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

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

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

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

== Encoding "modern" attributes ==

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

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

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

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><a class="email" href="mailto:steve@mac.com">...</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.

== Encoding Company data as a Business Card (proposal) ==
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]]

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

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

== Auto-Discovery ==
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/vcard" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

[[User:EtanWexler|EtanWexler]] disagrees with the value of the “type” attribute. The [http://www.iana.org/ Internet Assigned Numbers Authority] has no registration for a “text/vcard” type. 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. So a different rel type must be established to decribe that relationship. The ideas vary from specific to vague. The list and categories follow:
<pre><nowiki>
rel="contactinfo"
rel="profile"
rel="author"
rel='PIM'
rel='person'
rel='about'
rel='contact'
rel='hcard'
rel='microformat'
</nowiki></pre>
Example of mixing two rel types to a single page.
rel="hcard xfn"

Note: using rel="vcard" indicates a link directly to a vCard. If the document links to an hCard instead, the indication is untrue and inappropriate.

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

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

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:

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:
<pre><nowiki>
<a class="e&#109;ail" 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)

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page.

== Post vCard additions ==

Some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information.

This section is for documentation of such suggested additions. Note, we will require empirical evidence of actual *real world* examples on the Web of people publishing this information as part of contact information, before considering such additions/extensions.

* altitude. From [[hcard-issues]].
** No evidence provided that contact information on the Web publishes this information.

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.

== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]

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

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

irc

2006-01-04T21:41:09Z

DimitriGlazkov: /* 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]]
* [[User:Tantek|Tantek]] (-0800)
* [http://epeus.blogspot.com/ KevinMarks] (-0800)
* [[User:DimitriGlazkov|dglazkov]] (-0600)
* [[User:ChrisMessina|factoryjoe]] (-0800)
* [[User:IanHickson|Hixie]] (-0800)
* [[User:neuro]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Cgriego|cgriego]]

=== bots ===

* [[mfbot]]
* [[mflogbot]]

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

rest/brainstorming

2005-10-20T02:14:03Z

DimitriGlazkov: /* Verbs */

= XHTML-REST Brainstorming =

This page collects ideas from [[rest-examples]] how to best encode [[REST]] data in an XHTML microformat.

== Constraints ==

The underlying premise of this investigation is that REST is less useful that it could be due to concerns about a) interoperability, and b) discoverability. To address this, we propose adopting microformat-style conventions to further constrain the ways REST already constrains web services.

In particular, we constrain REST to work with existing web browser clients -- yet also be machine-parseable. This means:
* All inputs must be url-encoded (or maybe mime/multipart)
* All output must be XHTML, either:
** XOXO: [[xoxo]] (dl, ul, ol)
** XOXT: [[table-brainstorms]] (table-th-tr-td)
* All URI links must be encoded as either:
** Anchors (<a&rt;) (via 'href')
** Forms (<a&rt;) (via 'action')
* Only GET and POST actions are supported

This may seem very strict, but that's the point: by adding more constraints, we reduce gratuitous degrees of freedom and enable greater consistency.

This may not solve every conceivable problem, but it should handle the 50% case pretty well:
* REST: 80% of web services
* XHTML: 80% of XML expressiveness
* GET/POST + urlencoding: 80% of queries
or, put another way:
* 80% x 80% x 80% = 51.2% of the benefit for
* 20% x 20% x 20% = 0.8% of the effort

== Conventions ==

To make parsing and auto-discovery easier -- and also simplify the design process -- we propose the following additional conventions.

=== Nouns ===

As usual in REST, every ''noun'' must be a URI. However, we explicitly define three types of URIs:
;base:The base URI for the web service, e.g.: <code>http://example.com/site/</code>.
;records:URIs representing individual entities, e.g.: <code>http://example.com/webservice/users/me%40drernie.com</code>.
;tables:The URIs used to create or search for those instances, e.g.: <code>http://example.com/webservice/users</code>.

Note that each record is defined by a set of key-value pairs living under that table.

There can also be 'singletons' - a class which only has a single instance.

=== Verbs ===

REST depends on using verbs properly. Your typical verbs are POST (create), GET (retrieve), PUT (update), and DELETE (delete). More verbs can be defined and used, but the listed above are most commonly used and supported.

As we know, HTML forms spec (and therefore commonly used UAs) only provides support for POST and GET verbs. This limitation has been the biggest argument against mixing HTML and REST: tunnelling of PUT and DELETE verbs through POST (or even worse, GET) creates architectural unREST.

However, some architectures simply do not need deletion and update operations. Using HTML with REST requires employing such architectures.

While that may seem overly restrictive, as a practical matter those cover the "80%" of public web services we are trying to solve (after all, you are welcome to use your own private methods if you need to).

Even better, we can define very precise semantics for what GET & POST mean for each of the different nouns:

GET base
GET base?view=api # Return hyperlinks and forms
GET base?query # search for records across multiple table

GET table
GET table?view=api
GET table?query # search for records in that table
POST table?create # create record

GET record # encode as xoxo
GET record?view=edit # encode as hyperlinks/anchors
GET record?view=api # encode as hyperlinks/anchors + descriptions
POST record?update # update record -- this is tunnelling, a no-no

For simplicity, we assume:
* users can not delete anything
* users can not create tables (or singletons)

To be sure, there are natural ways to extend this protocol to provide that functionality. However, as that is primarly for admin usage, and thus a private API, we're glossing over it here. From a user's point of view, we provide analogous capabilities using POST:
* "DELETE" is replaced by "mark for deletion"
* "PUT" is replaced by "ask table to create record"

=== Format ===

Results should be returned in a xoxo-compatible format. In particular, query results should leverage
[http://opensearch.a9.com/spec/opensearchresponse/1.1/ OpenSearch 1.1].

[''Do HTML bindings for this already exist?'']

== Questions for further research ==

== Patterns ==

=== Anchor Design Pattern ===

<a class="rest" href="http//somesite.com/prog/adduser">label</a>

=== Forms Design Pattern ===

== See Also ==

* [http://www.opendarwin.org/~drernie/rest-api.html REST self-describing API proposal]
* [http://opensearch.a9.com/ OpenSearch search results standard (REST-like)]
* [[rest-proposal-preso]]
* [[duhper-proposal-preso]]

[http://www.opendarwin.org/~drernie/rest-api.html Proposed REST API]

rest/brainstorming

2005-10-20T02:11:24Z

DimitriGlazkov: /* Verbs */

= XHTML-REST Brainstorming =

This page collects ideas from [[rest-examples]] how to best encode [[REST]] data in an XHTML microformat.

== Constraints ==

The underlying premise of this investigation is that REST is less useful that it could be due to concerns about a) interoperability, and b) discoverability. To address this, we propose adopting microformat-style conventions to further constrain the ways REST already constrains web services.

In particular, we constrain REST to work with existing web browser clients -- yet also be machine-parseable. This means:
* All inputs must be url-encoded (or maybe mime/multipart)
* All output must be XHTML, either:
** XOXO: [[xoxo]] (dl, ul, ol)
** XOXT: [[table-brainstorms]] (table-th-tr-td)
* All URI links must be encoded as either:
** Anchors (<a&rt;) (via 'href')
** Forms (<a&rt;) (via 'action')
* Only GET and POST actions are supported

This may seem very strict, but that's the point: by adding more constraints, we reduce gratuitous degrees of freedom and enable greater consistency.

This may not solve every conceivable problem, but it should handle the 50% case pretty well:
* REST: 80% of web services
* XHTML: 80% of XML expressiveness
* GET/POST + urlencoding: 80% of queries
or, put another way:
* 80% x 80% x 80% = 51.2% of the benefit for
* 20% x 20% x 20% = 0.8% of the effort

== Conventions ==

To make parsing and auto-discovery easier -- and also simplify the design process -- we propose the following additional conventions.

=== Nouns ===

As usual in REST, every ''noun'' must be a URI. However, we explicitly define three types of URIs:
;base:The base URI for the web service, e.g.: <code>http://example.com/site/</code>.
;records:URIs representing individual entities, e.g.: <code>http://example.com/webservice/users/me%40drernie.com</code>.
;tables:The URIs used to create or search for those instances, e.g.: <code>http://example.com/webservice/users</code>.

Note that each record is defined by a set of key-value pairs living under that table.

There can also be 'singletons' - a class which only has a single instance.

=== Verbs ===

REST depends on using verbs properly. Your typical verbs are POST (create), GET (retrieve), PUT (update), and DELETE (delete). More verbs can be defined and used, but the listed above are most commonly used and supported.

As we know, HTML forms spec (and therefore commonly used UAs) only provides support for POST and GET verbs. This limitation has been the biggest argument against mixing HTML and REST: tunnelling of PUT and DELETE verbs through POST (or even worse, GET) creates architectural unREST.

However, some architectures simply do not need deletion and update operations. Using HTML with REST requires employing such architectures.

While that may seem overly restrictive, as a practical matter those cover the "80%" of public web services we are trying to solve (after all, you are welcome to use your own private methods if you need to).

Even better, we can define very precise semantics for what GET & POST mean for each of the different nouns:

GET base
GET base?view=api # Return hyperlinks and forms
GET base?query # search for records across multiple table

GET table
GET table?view=api
GET table?query # search for records in that table
POST table?create # create record

GET record # encode as xoxo
GET record?view=edit # encode as hyperlinks/anchors
GET record?view=api # encode as hyperlinks/anchors + descriptions
POST record?update # update record

For simplicity, we assume:
* users can not delete anything
* users can not create tables (or singletons)

To be sure, there are natural ways to extend this protocol to provide that functionality. However, as that is primarly for admin usage, and thus a private API, we're glossing over it here. From a user's point of view, we provide analogous capabilities using POST:
* "DELETE" is replaced by "mark for deletion"
* "PUT" is replaced by "ask table to create record"

=== Format ===

Results should be returned in a xoxo-compatible format. In particular, query results should leverage
[http://opensearch.a9.com/spec/opensearchresponse/1.1/ OpenSearch 1.1].

[''Do HTML bindings for this already exist?'']

== Questions for further research ==

== Patterns ==

=== Anchor Design Pattern ===

<a class="rest" href="http//somesite.com/prog/adduser">label</a>

=== Forms Design Pattern ===

== See Also ==

* [http://www.opendarwin.org/~drernie/rest-api.html REST self-describing API proposal]
* [http://opensearch.a9.com/ OpenSearch search results standard (REST-like)]
* [[rest-proposal-preso]]
* [[duhper-proposal-preso]]

[http://www.opendarwin.org/~drernie/rest-api.html Proposed REST API]

rest/brainstorming

2005-10-20T02:10:48Z

DimitriGlazkov: /* Verbs */

= XHTML-REST Brainstorming =

This page collects ideas from [[rest-examples]] how to best encode [[REST]] data in an XHTML microformat.

== Constraints ==

The underlying premise of this investigation is that REST is less useful that it could be due to concerns about a) interoperability, and b) discoverability. To address this, we propose adopting microformat-style conventions to further constrain the ways REST already constrains web services.

In particular, we constrain REST to work with existing web browser clients -- yet also be machine-parseable. This means:
* All inputs must be url-encoded (or maybe mime/multipart)
* All output must be XHTML, either:
** XOXO: [[xoxo]] (dl, ul, ol)
** XOXT: [[table-brainstorms]] (table-th-tr-td)
* All URI links must be encoded as either:
** Anchors (<a&rt;) (via 'href')
** Forms (<a&rt;) (via 'action')
* Only GET and POST actions are supported

This may seem very strict, but that's the point: by adding more constraints, we reduce gratuitous degrees of freedom and enable greater consistency.

This may not solve every conceivable problem, but it should handle the 50% case pretty well:
* REST: 80% of web services
* XHTML: 80% of XML expressiveness
* GET/POST + urlencoding: 80% of queries
or, put another way:
* 80% x 80% x 80% = 51.2% of the benefit for
* 20% x 20% x 20% = 0.8% of the effort

== Conventions ==

To make parsing and auto-discovery easier -- and also simplify the design process -- we propose the following additional conventions.

=== Nouns ===

As usual in REST, every ''noun'' must be a URI. However, we explicitly define three types of URIs:
;base:The base URI for the web service, e.g.: <code>http://example.com/site/</code>.
;records:URIs representing individual entities, e.g.: <code>http://example.com/webservice/users/me%40drernie.com</code>.
;tables:The URIs used to create or search for those instances, e.g.: <code>http://example.com/webservice/users</code>.

Note that each record is defined by a set of key-value pairs living under that table.

There can also be 'singletons' - a class which only has a single instance.

=== Verbs ===

REST depends on using verbs properly. Your typical verbs are POST (create), GET (retrieve), PUT (update), and DELETE (delete). More verbs can be defined and used, but the listed above are most commonly used and supported.

As we know, HTML forms spec (and therefore commonly used UAs) only provides support POST and GET verbs. This limitation has been the biggest argument against mixing HTML and REST: tunnelling of PUT and DELETE verbs through POST (or even worse, GET) creates architectural unREST.

However, some architectures simply do not need deletion and update operations. Using HTML with REST requires employing such architectures.

While that may seem overly restrictive, as a practical matter those cover the "80%" of public web services we are trying to solve (after all, you are welcome to use your own private methods if you need to).

Even better, we can define very precise semantics for what GET & POST mean for each of the different nouns:

GET base
GET base?view=api # Return hyperlinks and forms
GET base?query # search for records across multiple table

GET table
GET table?view=api
GET table?query # search for records in that table
POST table?create # create record

GET record # encode as xoxo
GET record?view=edit # encode as hyperlinks/anchors
GET record?view=api # encode as hyperlinks/anchors + descriptions
POST record?update # update record

For simplicity, we assume:
* users can not delete anything
* users can not create tables (or singletons)

To be sure, there are natural ways to extend this protocol to provide that functionality. However, as that is primarly for admin usage, and thus a private API, we're glossing over it here. From a user's point of view, we provide analogous capabilities using POST:
* "DELETE" is replaced by "mark for deletion"
* "PUT" is replaced by "ask table to create record"

=== Format ===

Results should be returned in a xoxo-compatible format. In particular, query results should leverage
[http://opensearch.a9.com/spec/opensearchresponse/1.1/ OpenSearch 1.1].

[''Do HTML bindings for this already exist?'']

== Questions for further research ==

== Patterns ==

=== Anchor Design Pattern ===

<a class="rest" href="http//somesite.com/prog/adduser">label</a>

=== Forms Design Pattern ===

== See Also ==

* [http://www.opendarwin.org/~drernie/rest-api.html REST self-describing API proposal]
* [http://opensearch.a9.com/ OpenSearch search results standard (REST-like)]
* [[rest-proposal-preso]]
* [[duhper-proposal-preso]]

[http://www.opendarwin.org/~drernie/rest-api.html Proposed REST API]

rest/rex-proposal

2005-10-18T14:54:04Z

DimitriGlazkov: /* DUHPER: A Dual-Use HTML Profile Expressing REST */

= DUHPER: A Dual-Use HTML Profile Expressing REST =
== The 0.8% Solution for Web Services ==
==== October 18th, 2005 ====
"Something better than a diaper-soundex" naming content: XOX-REST = XOXR (SHOCKER)

= Web Services: The Opportunity =
* "The Next Big Thing"
* Rewriting the web as a platform
* Foundation of [Web 2.0] businesses
** Architecture of participation
** Infrastructure for collaboration
* Enterprise App Integration (EAI) all over again

= Web Services: The Problem =
* Can work really well when you have:
** Well-defined community
** Well-run governance
** Well-understood problem space
* Not true of the public Internet
* Not true of most vertical industries

= The Answer(?): REST vs. RPC =
* RPC: Remote Procedure Calls
** URIs are method names
** XML is the arguments format
** Implemented in [http://www.xmlrpc.com/ XML-RPC] and [http://www.w3schools.com/soap/soap_intro.asp SOAP]
* [http://www.xfront.com/REST-Web-Services.html REST]: Representational State Transfer
** Nouns are URIs, verbs are HTTP: GET, PUT, POST, DELETE
** XML documents are state information
** Implemented at [http://www.xml.com/pub/a/2005/09/21/atom-store-web-database.html Atom], [http://www.oreillynet.com/pub/wlg/3005 Amazon] (sorta)

= Advantages of REST over RPC =
* Much simpler to design
** Easy to identify appropriate nouns
** Don't need to define methods (verbs)
** Don't need a complete object model
* Easier to learn/invoke
** Always know what a URI means
** Need not 'tunnel' XML inside XML

= Challenges of REST =
;Discoverability: No standard way to find services
;Interoperability: Too many incompatible ways to encode links, data
;Extensability: What if your schema isn't 100% right?
;Comprehensability: What the heck does "state transfer" mean?

= Proposal: A Dual-Use (X)HTML Profile =
* Subset of REST that works with browsers
** XHTML Basic vs. arbitrary XML
** Just GET & POST (not PUT or DELETE)
** Encode URIs in hyperlinks (<a href>) and forms (<form action>)
** Inputs always key-value pairs (like database table)
* With CSS and AJAX, can '''be''' the website
** DRY = Don't Repeat Yourself
** Makes discovery and documentation trivial

= Three Challenges =
* Is HTML Machine-Parseable?
* Are there really only two verbs?
* Can you build real apps on key-value encoding?

= Challenge #1: Machine-Parseability =
* Screen scraping all over again? No!
* Use the "secret sauce" of "semantic salt"
** cf. "syntactic sugar" -- hides unpleasant details
** "semantic salt" -- brings out latent structure
* In other words, "[http://tantek.com/presentations/2005/06/what-are-microformats/ microformats]"

= What Are Microformats? =
* simple social conventions (rel="proflie")
* using existing tags or brief CSS class names
* to encode machine-readable semantics
* in human-readable HTML, XHTML, or even XML
** cf. <link rel> in Atom

= Kinds of Microformats =
* Link annotation, e.g.:
** RelTag (Technorati): <a rel="tag" href=...>
** RelNoFollow (Gooogle): <a rel="nofollow" href=...>
* User data
** [http://microformats.org/wiki/hcard hCard] (based on [http://www.ietf.org/rfc/rfc2426.txt vCard])
** [http://microformats.org/wiki/hcalendar hCalendar] (based on [http://www.ietf.org/rfc/rfc2445.txt iCalendar])
* Data structures
** [http://microformats.org/wiki/xoxo XOXO] lists: ol, ul, dl
** [http://microformats.org/wiki/table-examples XOXT] tables: th, tr, td

= Example: hCard =
* ''hCard'' class names := ''vCard'' fields
<div class="vcard">
<a class="url fn" href="http://tantek.com/">
Tantek Çelik
</a>
<div class="org">Technorati</div>
</div>

= Example: eXtensible Open XHTML Outlines =
* Reuse existing HTML tags
* Arbitrary data structure (like [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html property lists])
<dl class='xoxo'> <-- Dictionary -->
<dt>Key #1<dt>
<dd><ol> <-- Array -->
<li>subitem #1</li>
<li>subitem #2</li>
</ol></dd>
</dl>

= Challenge #2: Only Two Verbs =
* Overload URI with actions? No!
* Web 2.0 is an constructive medium
* Don't store a document: ask for creation
** POST parent&key1=value1 => child URI
* Don't edit document: create new revision
** The concept of bottomless stack: each document is also a collection of its revisions, with the latest revision sitting at the top of the stack. After the number of revisions reaches the arbitrary size of the stack, oldest revisions fall off the stack into oblivion (note: size=1 and size=0 are possible, too)
* Don't delete a document: flag for removal
** POST child&shouldDelete=true

= Challenge #3: Key-Value Data =
* Encode complex structures as XML text? No!
* Treat web service like a database
** Common classes (e.g. users, items, carts) => tables
** Key-value dictionaries => records
** URIs for each records => primary keys
* Need NOT reflect actual internal database
** Can present a synthetic view
** But, makes a great starting point (cf. [http://www.rubyonrails.org/ Ruby on Rails]

= The 0.8% Solution for Web Services =
* (80% of benefit/20% of effort)^3
** XOXO vs. XML: 80/20
** GET/POST vs. REST: 80/20 x 80/20 = 64/4
** Key-Value vs. structured input: 80/20 x 64/4 = [http://en.wikipedia.org/wiki/Pareto_principle 51.2/0.8]
* Half the benefit for 1% of the effort!
** Maybe not everything, but the basics easily
* Power comes from how much you can ignore
** cf. [http://intertwingly.net/slides/2005/rs/ Radical Simplification]

= Advantages =
* Reuse existing semantics and structure
** Generally only one way to encode something
* Reduce possible degrees of freedom
** Simplifies design, improves interoperability
** Focus on the 80% where agreement is easy
* Increase learnability
** Everyone (in this space) can write it
** Everything (in the world) can read it
** The API is the documentation is the format

= Implications =
* Is this the "[http://www.gladwell.com/tippingpoint/ tipping point]"?
** The 'LDAP' of web services?
** The 'missing link' for REST?
** The 'killer app' for Ruby on Rails?
* Why?
** Looser than XML => allows innovation
** Tighter than REST => encourages interoperability
** Simpler than SOAP => enables rapid adoption

= For More Information =
* Microformats http://microformats.org
** What are Microformats? http://tantek.com/presentations/2005/06/what-are-microformats/
** Discussion Lists http://microformats.org/discuss/
** XOXO: http://microformats.org/wiki/xoxo
* XHTML and REST
** research: http://microformats.org/wiki/rest-examples
** blog: http://www.opendarwin.org/~drernie/
** This presentation: http://microformats.org/wiki/duhper-proposal-preso

rest/rex-proposal

2005-10-18T14:23:11Z

DimitriGlazkov: /* Challenge #2: Only Two Verbs */

= DUHPER: A Dual-Use HTML Profile Expressing REST =
== The 0.8% Solution for Web Services ==
==== October 18th, 2005 ====

= Web Services: The Opportunity =
* "The Next Big Thing"
* Rewriting the web as a platform
* Foundation of [Web 2.0] businesses
** Architecture of participation
** Infrastructure for collaboration
* Enterprise App Integration (EAI) all over again

= Web Services: The Problem =
* Can work really well when you have:
** Well-defined community
** Well-run governance
** Well-understood problem space
* Not true of the public Internet
* Not true of most vertical industries

= The Answer(?): REST vs. RPC =
* RPC: Remote Procedure Calls
** URIs are method names
** XML is the arguments format
** Implemented in [http://www.xmlrpc.com/ XML-RPC] and [http://www.w3schools.com/soap/soap_intro.asp SOAP]
* [http://www.xfront.com/REST-Web-Services.html REST]: Representational State Transfer
** Nouns are URIs, verbs are HTTP: GET, PUT, POST, DELETE
** XML documents are state information
** Implemented at [http://www.xml.com/pub/a/2005/09/21/atom-store-web-database.html Atom], [http://www.oreillynet.com/pub/wlg/3005 Amazon] (sorta)

= Advantages of REST over RPC =
* Much simpler to design
** Easy to identify appropriate nouns
** Don't need to define methods (verbs)
** Don't need a complete object model
* Easier to learn/invoke
** Always know what a URI means
** Need not 'tunnel' XML inside XML

= Challenges of REST =
;Discoverability: No standard way to find services
;Interoperability: Too many incompatible ways to encode links, data
;Extensability: What if your schema isn't 100% right?
;Comprehensability: What the heck does "state transfer" mean?

= Proposal: A Dual-Use (X)HTML Profile =
* Subset of REST that works with browsers
** XHTML Basic vs. arbitrary XML
** Just GET & POST (not PUT or DELETE)
** Encode URIs in hyperlinks (<a href>) and forms (<form action>)
** Inputs always key-value pairs (like database table)
* With CSS and AJAX, can '''be''' the website
** DRY = Don't Repeat Yourself
** Makes discovery and documentation trivial

= Three Challenges =
* Is HTML Machine-Parseable?
* Are there really only two verbs?
* Can you build real apps on key-value encoding?

= Challenge #1: Machine-Parseability =
* Screen scraping all over again? No!
* Use the "secret sauce" of "semantic salt"
** cf. "syntactic sugar" -- hides unpleasant details
** "semantic salt" -- brings out latent structure
* In other words, "[http://tantek.com/presentations/2005/06/what-are-microformats/ microformats]"

= What Are Microformats? =
* simple social conventions (rel="proflie")
* using existing tags or brief CSS class names
* to encode machine-readable semantics
* in human-readable HTML, XHTML, or even XML
** cf. <link rel> in Atom

= Kinds of Microformats =
* Link annotation, e.g.:
** RelTag (Technorati): <a rel="tag" href=...>
** RelNoFollow (Gooogle): <a rel="nofollow" href=...>
* User data
** [http://microformats.org/wiki/hcard hCard] (based on [http://www.ietf.org/rfc/rfc2426.txt vCard])
** [http://microformats.org/wiki/hcalendar hCalendar] (based on [http://www.ietf.org/rfc/rfc2445.txt iCalendar])
* Data structures
** [http://microformats.org/wiki/xoxo XOXO] lists: ol, ul, dl
** [http://microformats.org/wiki/table-examples XOXT] tables: th, tr, td

= Example: hCard =
* ''hCard'' class names := ''vCard'' fields
<div class="vcard">
<a class="url fn" href="http://tantek.com/">
Tantek Çelik
</a>
<div class="org">Technorati</div>
</div>

= Example: eXtensible Open XHTML Outlines =
* Reuse existing HTML tags
* Arbitrary data structure (like [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html property lists])
<dl class='xoxo'> <-- Dictionary -->
<dt>Key #1<dt>
<dd><ol> <-- Array -->
<li>subitem #1</li>
<li>subitem #2</li>
</ol></dd>
</dl>

= Challenge #2: Only Two Verbs =
* Overload URI with actions? No!
* Web 2.0 is an constructive medium
* Don't store a document: ask for creation
** POST parent&key1=value1 => child URI
* Don't edit document: create new revision
** The concept of bottomless stack: each document is also a collection of its revisions, with the latest revision sitting at the top of the stack. After the number of revisions reaches the arbitrary size of the stack, oldest revisions fall off the stack into oblivion (note: size=1 and size=0 are possible, too)
* Don't delete a document: flag for removal
** POST child&shouldDelete=true

= Challenge #3: Key-Value Data =
* Encode complex structures as XML text? No!
* Treat web service like a database
** Common classes (e.g. users, items, carts) => tables
** Key-value dictionaries => records
** URIs for each records => primary keys
* Need NOT reflect actual internal database
** Can present a synthetic view
** But, makes a great starting point (cf. [http://www.rubyonrails.org/ Ruby on Rails]

= The 0.8% Solution for Web Services =
* (80% of benefit/20% of effort)^3
** XOXO vs. XML: 80/20
** GET/POST vs. REST: 80/20 x 80/20 = 64/4
** Key-Value vs. structured input: 80/20 x 64/4 = [http://en.wikipedia.org/wiki/Pareto_principle 51.2/0.8]
* Half the benefit for 1% of the effort!
** Maybe not everything, but the basics easily
* Power comes from how much you can ignore
** cf. [http://intertwingly.net/slides/2005/rs/ Radical Simplification]

= Advantages =
* Reuse existing semantics and structure
** Generally only one way to encode something
* Reduce possible degrees of freedom
** Simplifies design, improves interoperability
** Focus on the 80% where agreement is easy
* Increase learnability
** Everyone (in this space) can write it
** Everything (in the world) can read it
** The API is the documentation is the format

= Implications =
* Is this the "[http://www.gladwell.com/tippingpoint/ tipping point]"?
** The 'LDAP' of web services?
** The 'missing link' for REST?
** The 'killer app' for Ruby on Rails?
* Why?
** Looser than XML => allows innovation
** Tighter than REST => encourages interoperability
** Simpler than SOAP => enables rapid adoption

= For More Information =
* Microformats http://microformats.org
** What are Microformats? http://tantek.com/presentations/2005/06/what-are-microformats/
** Discussion Lists http://microformats.org/discuss/
** XOXO: http://microformats.org/wiki/xoxo
* XHTML and REST
** research: http://microformats.org/wiki/rest-examples
** blog: http://www.opendarwin.org/~drernie/
** This presentation: http://microformats.org/wiki/duhper-proposal-preso