Microformats Wiki - User contributions [en]

User:MikeTaylor

2016-06-05T22:21:31Z

MikeTaylor: update vcard

<div class="vcard">
<span class="fn">Mike Taylor</span> (<span class="email">bear@bear.im</span>).
<span class="org"> [http://circleci.com CircleCI]</span>
</div>

User:MikeTaylor

2005-10-22T07:00:01Z

MikeTaylor:

<div class="vcard">
<span class="fn">Mike Taylor</span> (<span class="email">bear@osafoundation.org</span>).
<span class="org"> [http://osafoundation.org Open Source Applications Foundation]</span>
</div>

zen-garden

2005-10-22T06:51:12Z

MikeTaylor: typos

= Microformats Zen Garden =

A [http://www.csszengarden.com/ CSS Zen Garden] for microformats is essential for popular adoption. Getting something that "looks cool" for "free" should be a key attraction for convincing authors to "steal" microformatted data and cut'n'paste it into their own sites, and for that matter, to reuse style sheets for microformatted data as well.

Developers of microformat-savvy tools would also benefit from common idioms for presenting and editing microformatted data (for example, consider the impact of Apple's Address Book person-layout/edit view on many other Mac applications).

Unlike the original Zen Garden, Javascript may also prove essential to unlocking designers' flexibility: people have expressed interest in hooking hCards to maps, or [http://web.mit.edu/glasser/www/JSCalendar/ this example of a renderer for hCalendar] [http://web.mit.edu/glasser/www/JSCalendar/hcalendar.html grid views].

== Interested parties ==

People who would be willing to spend time on the garden.

* Robert Bachmann
** could act as a point person
** writing the sample document
** providing styles (but he's not a good designer)

== Planning ==
...

=== Open questions ===
* What license should be used? --[[User:RobertBachmann|Robert Bachmann]] 10:34, 21 Oct 2005 (PDT)
** My personal favorites are http://creativecommons.org/licenses/by/2.0/ and http://creativecommons.org/licenses/publicdomain/ --14:03, 21 Oct 2005 (PDT)

blog-post-brainstorming

2005-10-22T05:24:09Z

MikeTaylor: added missing >

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.oreillynet.com Justin Watt]

= Purpose =
The 'blog-post-microformat' proposes a codification of how blog posts are indentifies within weblogs. It is hoped that this should be considered to be 'expansive': for example, the proposal could be used on [http://www.cnn.com CNN.com] to mark up news articles and summary pages.

= Terminology =

This section explores the terminology that should used to discuss a blog post microformat. To make it easier to talk about the various different types of teminology, We're using a XML-like namespace version so we can make statements like <code>atom:entry</code> is roughly equivalent to <code>rss20:feed</code>, <code>atom:feed/atom:link@relalternate</code> is roughly equivalent to <code>rss20:channel/rss20:link</code> or <code>atom:author</code> is '''not''' equivalent to <code>rss:entry/rss:author</code> (because RSS 2.0 is only the definition of an email address).

== Common terminology in weblogs ==

Reviewing [[blog-post-formats#Tools]], one can see that there's little standardization amongst tools or even within a individual tool (such as 'blogger') for names of elements of blog posts. There are however many common elements, including:

* a container for all posts/entries
* a container for individual posts
* the post content, which can be complete, summarized with a link to the complete link, or a couple of paragraphs with javascript/CSS tricks to reveal the remainder of the content
* the name of the author
* the posting date (in many many formats)

Although this looks like a bit of a dog's breakfast, there is usually a fair amount of rigour behind the presentation, as Atom and/or RSS feeds can be produced also from the same tools.

Furthermore, in developing a microformat for weblog posts, we want to be careful not to break any (or many) templates. Note that many weblog templates will have to be updated as they produce somewhat crufty HTML rather than shiny XHTML.

== Atom Terminology ==

See [http://www.atomenabled.org/ here] for the spec and [[blog-post-formats#Atom]] for analysis.

* <code>atom:feed</code> - (composite) a collection of entries plus information about them
** <code>atom:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>atom:id</code> - a permament identifier for a feed
** <code>atom:title</code> - the title of an atom:entry or a atom:feed
** <code>atom:updated</code> - the last time the feed was updated
** <code>atom:link@relalternate</code> - the home page of a feed
** <code>atom:link@relself</code> - the URI of the feed (where it can be downloaded)
** <code>atom:entry</code> - (composite) an entry within the feed
*** <code>atom:content</code> - the feed's content
*** <code>atom:summary</code> - a summary of the feed's content
*** <code>atom:entry/link</code> - the permament URI of the entry
*** <code>atom:published</code> - the time of the initial creation or first availability of the entry

== RSS Terminology ==

See [http://blogs.law.harvard.edu/tech/rss here] for the spec and [[blog-post-formats#RSS]] for analysis. There are a lot more elements in RSS but this covers the most commonly used ones.

* <code>rss2:channel</code> - (composite) a collection of entries plus information about them
** <code>rss2:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>rss2:link</code> - The URL to the HTML website corresponding to the channel (compare to atom:link@relalternate)
** <code>rss2:title</code> - the title of an rss2:channel or a rss2:item
** <code>rss2:pubDate</code> - The publication date for the content in the channel.
** <code>rss2:item</code> - (composite) an entry within the feed
*** <code>rss2:item/link</code> - The URL of the item. Note that this may not be a permalink for the item; it may be a link to some other page on the Internet that the rss2:item is about
*** <code>rss2:description</code> - The item synopsis [sic]. There is no special indication whether this is the full content of an entry, a summary, or a precis of what the rss2:item/link is pointing to
*** <code>rss2:author</code> - email address of the author of the item

== Recommendation ==

Atom has a much more precise mechanism for defining syndication feeds and weblog data. A mechanical transformation from Atom -> RSS will always lead to a correct RSS feed; a RSS -> Atom translation would have to make a decision amongst multiple definitions that may not always be correct. For example, the format of markup, the role of an author, or the meaning of a link.

IMPORTANT: we shall talk about things such as 'marking elements <code>atom:feed</code>'; consider this a purely conceptual thing. The text 'atom:feed' will not appear in the XHTML microformat -- we may decide later to use the actual phrase 'atom_feed', 'feed', 'items' or 'googlybear'. In the case where there is no clear or applicable atom terminology, we shall use 'weblog:xxx'.

= Discovered Elements =

This section explores the information discovered from [[blog-post-formats]] using the terminology discussed above. We will only focus on the major elements of weblog posts:

* the EntryGroup
* the individual Entry
* the Entry Title
* the Entry Content
* the Entry Permalink
* the Entry Datetimes

For now, the codification of the following major elements will be deferred as there is/may be overlap with other microformats that should be explored further

* the EntryGroup Title
* the EntryGroup Permalink
* the Entry Poster/Author - in particular, should hcard be used?

Further input from the community would be appreciated here

== EntryGroup ==

Roughly speaking, this corresponds to 'atom:feed' or 'rss2:channel' (in particular, the items within those XML elements). See [[blog-post-examples#EntryGroup]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog pages (including home pages, archives, category pages, tag pages and so forth) that may container multiple entries MUST enclose the entries in a <code>atom:feed</code> element
* weblog pages MAY have multiple <code>atom:feed</code> element enclosing different groups of entries
* <code>atom:feed</code> elements MUST NOT be nested
* weblog pages that have exactly one entry MAY use the <code>atom:feed</code>

=== Example Transformation ===

''Note that the string 'atom:feed' is a placeholder for something to be decided later.''

Original (obviously, if there is no existing EntryGroup block element, one can be added):

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div id="content" class="atom:feed">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

== EntryGroup Title ==
Not covered by this proposal yet.

== EntryGroup Permalink ==
Not covered by this proposal yet.

== Individual Entry ==

This corresponds almost exactly to the <code>atom:entry</code> or <code>rss2:item</code> elements. See [[blog-post-examples#Individual_Entry]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog entries MUST be enclosed in a single <code>atom:entry</code> element
* <code>atom:entry</code> elements MUST NOT be nested
* <code>atom:entry</code> MUST NOT belong to more than one <code>atom:feed</code> element

=== Example Transformation ===
''Note that the string 'atom:entry' is a placeholder for something to be decided later.''

==== Entries in existing block ====

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

==== Entries not in an existing block ====

Original:

<pre><nowiki>
<a name="112877372228959075">&nbsp;</a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

Note the additional changes were also made:
* <code><br></code> was made XHTML compliant
* <code><a name="..."></code> was converted to a <code>id="..."</code> (''confirm this is OK'')

==== Disjointed entries ====

Ignore any existing blocks and treat as the previous case of no block.

== Entry Title ==

This corresponds almost exactly to the <code>atom:title</code> or <code>rss2:title</code> elements. See [[blog-post-formats#Titles]] for examples from which we see that there are two fundemental ways titles are used in the wild: at the block level and inline. Our proposal must be capable of handling both forms.

=== Microformat Recommendation ===

* <code>atom:entry</code>s SHOULD have at most one title
* block level titles SHOULD be represented using <code><h#></code>, the first such element in a <code>atom:entry</code> should be considered the title; this need not be marked up or identified in any other way as the title
* inline titles MUST be marked as <code>atom:title</code>; it is also possible to do this using block level formatting such as <code><div></code>, but this is discouraged

=== Discussion: why not always <code><h#></code>? ===

Using CSS <code>display: inline</code>, block level elements can be converted to inline elements. Unfortunately, we cannot nest <code><h#></code> inside of a <code><p></code> block to achieve the correct effect. I.e. we cannot convert ...

<pre><nowiki>
<p><strong>The Title</strong>: The Text...</p>
</nowiki></pre>

... into ...

<pre><nowiki>
<p><h3 style="display: inline">The Title</h3>: The Text ...</p>
</nowiki></pre>

... because the XHTML will not validate. Also...

<pre><nowiki>
<h3 style="display: inline">The Title</h3><p>: The Text ...</p>
</nowiki></pre>

... will not work because presentation effect will be different than what the user intends (because the <code><p></code> will introduce a line break).

=== Example Transformation ===

''Note that the string 'atom:title' is a placeholder for something to be decided later.''

==== Header in <code><h#></code> block ====
Original (and Final):

<pre>
<div class="atom:entry">
<h2 id="post-59">Web Essentials Audio</h2>
... reset of entry ...
</div>
</pre>

No transformation is needed -- the blog-post microformat will recognize this as the <code>atom:title</code>.

==== Header in other block element ====

Original:

<pre>
<div class="atom:entry">
<div class"header">Web Essentials Audio</div>
</div>
</pre>

Transformed (the header level is to taste):

<pre>
<div class="atom:entry">
<h3>Web Essentials Audio</h3>
</div>
</pre>

It is possible to add <code>class"atom:title"</code> to the <code>div</code> but we recommend against it. However, we recognize that there may be certain [http://microformats.org/wiki/blog-post-formats#Discussion_Forum_.2F_Bulletin_Board_Formats BB Tools] that making this change may be too difficult.

==== Header in inline element ====

Original:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong class="atom:title">Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

== Entry Content ==

This roughly corresponds to <code>atom:content</code> and/or <code>atom:summary</code> elements. See [[blog-post-examples#Entry_Content]] for the various forms seen in the wild.

=== Discussion: the split content problem ===

The last item above (content broken into multiple sections) introduces a few unique problems. It is not sufficient to enclose all the different content sections in a <code>atom:content</code> element, as the following example illustrates:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
"Read More"
... second part of the content ...
</div>
</div>
</nowiki></pre>

"Read More" is not part of the content! Therefore, we propose that ''multiple'' content sections be allowed in a single <code>atom:entry</code>. The concatenation of all these content blocks will define the complete content:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
</div>
"Read More"
<div class="atom:content">
... second part of the content ...
</div>
</div>
</nowiki></pre>

The same argument is applicable to <code>atom:summary</code>.

=== Microformat Recommendation ===

* an <code>atom:entry</code> MAY have zero or more <code>atom:summary</code> sections. There is no requirement that different representations of the same entry (on different URIs) use the same summaries.
* an <code>atom:entry</code> MAY have zero or more <code>atom:content</code> sections. The serial concatenation of all the <code>atom:content</code> sections within the entry MUST represent the complete content of the entry. Note that the rule here is slightly different than [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom] which only allows one <code>atom:content</code>.

=== Example Transformation ===

''Note that the strings 'atom:summary' and 'atom:content' (etc.) are placeholders for something to be decided later.''

==== Entry with summary content ====
Original:

<pre><nowiki>
<div class="inlineBlog">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<p>
The folks at ... the rest of the content
</p>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="inlineBlog atom:entry">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink atom:permalink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<div class="atom:summary">
<p>
The folks at ... the rest of the content
</p>
</div>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Notes:
* we didn't do anything with the "abstract" section -- this is a discussion for another day
* we didn't include the tag stuff in the summary, and probably wouldn't if this was the complete content

==== Entry with complete content ====
Original:

<pre><nowiki>
<div class="entry single">
<h2 id="post-61">Class attributes are about more than styling</h2>

<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="entry single atom:entry">
<h2 id="post-61">Class attributes are about more than styling</h2>

<div class="atom:content">
<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...
</div>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Notes:
* the only thing that really needed to be done is enclose the content
* my preference would be to move the post <code>id</code> to the <code>atom:entry</code>

==== Entry with split content (multiple sections) ====
Original:

<pre><nowiki>
<div class="blogbody">
<a name="008148"></a>

<div class="title">
Face to face: why places will continue to exist
</div>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="blogbody atom:entry" id="008148">
<h3>
Face to face: why places will continue to exist
</h3>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<div class="atom:content">
<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...
</div>

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<div class="atom:content">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...
</div>

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Note:
* <code>atom:content</code> <code>div</code>s were created for each the of the text sections, so that non-content coded would not be incorrectly marked
* there are '''two''' <code>atom:content</code> sections; together they make the complete content
* the conversion of <code><div class="header"></code> to <code><h3></code>
* the addition of <code>atom:entry</code> as needed
* the removal of the <code><a name="008148"></code> in favor of placing an <code>id</code> on the <code>atom:entry</code>
* further manipulation of the author could be done
* further manipulation of the category could be done

== Entry Permalink ==

Permalinks roughly correspond to <code>atom:link</code>. See [[blog-post-examples#Entry_Permalinks]] for examples.

A permalink is called '''canonical''' if it is the best representation of the URI for that entry; the definition of what 'best representation' is is entirely at the discretion of the weblog's publisher. We recommend that weblogs use canonical URIs because it allows "threading" together multiple posts and sources with byte-level comparisons. In general, the canonical URI should be the link used in an Atom entry.

=== Microformat Recommendation ===

* an Entry MUST NOT have more than one permalink marked as <code>atom:link</code>
* permalinks SHOULD be absolute URIs
* permalinks SHOULD be canonical
* permalinks SHOULD be the same as the <code>atom:link</code> used in syndication feeds

=== Example Transformations ===

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="atom:link bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Original:

<pre><nowiki>
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry">
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a rel="atom:link" href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

== Entry Datetimes - Creation and Modified ==
Weblogs typically display (in HTML) the creation time of their posts (roughly but not exactly corresponding to <code>atom:published</code>) and not so much the last modified time (<code>atom:updated</code>).

Also see [[datetime-design-pattern]] for more information on specifying datetimes. The recommendation here is styled after datetimes in [[hcalendar]].

=== Forms seen in the wild ===
See [[blog-post-formats#Datetimes]]

=== Microformat Recommendation ===

* date headers between weblog entries are outside of this microformat
* <code>atom:published</code> SHOULD be indicated by an <code>abbr</code> element around the human readable version of the date or datetime.
** the 'class' attribute MUST indicate <code>atom:published</code>
** the 'title' attribute MUST be a complete datetime, in the format of [[datetime-design-pattern]]
* likewise for <code>atom:updated</code>, if present

=== Example transformation ===

''Note that the string 'atom:published' is a placeholder for something to be decided later.''

Original:

<pre>
<a href"...">Friday, September 30th, 2005 at 12:31 pm</a>
</pre>

Transformed:

<pre>
<a href"..."><abbr
class"atom:published"
title"200050930T12:31:01-0500">Friday, September 30th, 2005 at 12:31 pm</abbr></a>
</pre>

== Entry Author ==
A work in progress

=== Microformat Recommendation ===

* Entry Authors SHOULD be inside a <code><address></code> block

= Possible Uses =

This section describes potential applications for a blog post microformat

== Transformational Uses ==

By transformational, we mean feeding a weblog post to some sort of transformation tool (such as XSLT) to produce a different version of the post fit for a different use.

=== Printing Weblog Posts ===
=== Reblogging ===

== Archival Uses ==

By 'archival', we mean taking weblog entries and placing them in a database for later analysis, searching, aggregation and so forth.

=== Personal Database ===
=== Search Engines ===

=Obstacles=

==Header Tag for Entry Title?==
--[[User:Bryan|Bryan]] 14:55, 14 Aug 2005 (PDT)

Many weblog CMSes allow for concurrent publishing of entries in the following ways:

* multiple entries on a page (an "Index," monthly archive, category archive, etc. see [http://re-run.com/category/creative/comedy/ Example])
* one entry on a page (see [http://re-run.com/2005/02/11/nickels-worth-of-free-advice/ Example])

Early attempts at [[blog-post-formats]] have set the title of the blog post to use the h3 tag.

At least where individual entry pages are concerned (and possible including indexes and archives), I recommend using h1 for the entry title, given that the entry is by far the most important chunk of information on the page, and it's what we'd want search engines to recognize as such. In the case where the h1 was used for the site title, fears about "losing" this information should be allayed by simply including the site name in the title tag, <strong>after</strong> the title of the article / entry / post.

:Whether an h3 or h1 is used is irrelevant, the semantics will be applied with classnames. This is a non-issue. --[[User:RyanKing|RyanKing]] 22:35, 18 Aug 2005 (PDT)

=See Also=
* [[blog-post-formats]] - many examples taken from the real world about how blog content is marked up
* [[blog-post]] - coming soon; a proposal for a microformat
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [http://blogs.oreillynet.com/beasts/archives/2005/10/blog_post_microformat_proposal.html Blog Post Microformat Proposal] Some thoughts on the topic with useful illustrations.
* [http://dannyayers.com/archives/2005/08/27/hatom-no-seriously/ Danny Ayers] proposes the name hAtom and some applications
* [http://torrez.us/archives/2005/10/07/404 Elias Torres] says we need 'hAtom'

blog-post-brainstorming

2005-10-22T05:14:49Z

MikeTaylor: s/rgar/that/

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.oreillynet.com Justin Watt]

= Purpose =
The 'blog-post-microformat' proposes a codification of how blog posts are indentifies within weblogs. It is hoped that this should be considered to be 'expansive': for example, the proposal could be used on [http://www.cnn.com CNN.com] to mark up news articles and summary pages.

= Terminology =

This section explores the terminology that should used to discuss a blog post microformat. To make it easier to talk about the various different types of teminology, We're using a XML-like namespace version so we can make statements like <code>atom:entry</code> is roughly equivalent to <code>rss20:feed</code>, <code>atom:feed/atom:link@relalternate</code> is roughly equivalent to <code>rss20:channel/rss20:link</code> or <code>atom:author</code> is '''not''' equivalent to <code>rss:entry/rss:author</code> (because RSS 2.0 is only the definition of an email address).

== Common terminology in weblogs ==

Reviewing [[blog-post-formats#Tools]], one can see that there's little standardization amongst tools or even within a individual tool (such as 'blogger') for names of elements of blog posts. There are however many common elements, including:

* a container for all posts/entries
* a container for individual posts
* the post content, which can be complete, summarized with a link to the complete link, or a couple of paragraphs with javascript/CSS tricks to reveal the remainder of the content
* the name of the author
* the posting date (in many many formats)

Although this looks like a bit of a dog's breakfast, there is usually a fair amount of rigour behind the presentation, as Atom and/or RSS feeds can be produced also from the same tools.

Furthermore, in developing a microformat for weblog posts, we want to be careful not to break any (or many) templates. Note that many weblog templates will have to be updated as they produce somewhat crufty HTML rather than shiny XHTML.

== Atom Terminology ==

See [http://www.atomenabled.org/ here] for the spec and [[blog-post-formats#Atom]] for analysis.

* <code>atom:feed</code> - (composite) a collection of entries plus information about them
** <code>atom:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>atom:id</code> - a permament identifier for a feed
** <code>atom:title</code> - the title of an atom:entry or a atom:feed
** <code>atom:updated</code> - the last time the feed was updated
** <code>atom:link@relalternate</code> - the home page of a feed
** <code>atom:link@relself</code> - the URI of the feed (where it can be downloaded)
** <code>atom:entry</code> - (composite) an entry within the feed
*** <code>atom:content</code> - the feed's content
*** <code>atom:summary</code> - a summary of the feed's content
*** <code>atom:entry/link</code> - the permament URI of the entry
*** <code>atom:published</code> - the time of the initial creation or first availability of the entry

== RSS Terminology ==

See [http://blogs.law.harvard.edu/tech/rss here] for the spec and [[blog-post-formats#RSS]] for analysis. There are a lot more elements in RSS but this covers the most commonly used ones.

* <code>rss2:channel</code> - (composite) a collection of entries plus information about them
** <code>rss2:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>rss2:link</code> - The URL to the HTML website corresponding to the channel (compare to atom:link@relalternate)
** <code>rss2:title</code> - the title of an rss2:channel or a rss2:item
** <code>rss2:pubDate</code> - The publication date for the content in the channel.
** <code>rss2:item</code> - (composite) an entry within the feed
*** <code>rss2:item/link</code> - The URL of the item. Note that this may not be a permalink for the item; it may be a link to some other page on the Internet that the rss2:item is about
*** <code>rss2:description</code> - The item synopsis [sic]. There is no special indication whether this is the full content of an entry, a summary, or a precis of what the rss2:item/link is pointing to
*** <code>rss2:author</code> - email address of the author of the item

== Recommendation ==

Atom has a much more precise mechanism for defining syndication feeds and weblog data. A mechanical transformation from Atom -> RSS will always lead to a correct RSS feed; a RSS -> Atom translation would have to make a decision amongst multiple definitions that may not always be correct. For example, the format of markup, the role of an author, or the meaning of a link.

IMPORTANT: we shall talk about things such as 'marking elements <code>atom:feed</code>'; consider this a purely conceptual thing. The text 'atom:feed' will not appear in the XHTML microformat -- we may decide later to use the actual phrase 'atom_feed', 'feed', 'items' or 'googlybear'. In the case where there is no clear or applicable atom terminology, we shall use 'weblog:xxx'.

= Discovered Elements =

This section explores the information discovered from [[blog-post-formats]] using the terminology discussed above. We will only focus on the major elements of weblog posts:

* the EntryGroup
* the individual Entry
* the Entry Title
* the Entry Content
* the Entry Permalink
* the Entry Datetimes

For now, the codification of the following major elements will be deferred as there is/may be overlap with other microformats that should be explored further

* the EntryGroup Title
* the EntryGroup Permalink
* the Entry Poster/Author - in particular, should hcard be used?

Further input from the community would be appreciated here

== EntryGroup ==

Roughly speaking, this corresponds to 'atom:feed' or 'rss2:channel' (in particular, the items within those XML elements). See [[blog-post-examples#EntryGroup]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog pages (including home pages, archives, category pages, tag pages and so forth) that may container multiple entries MUST enclose the entries in a <code>atom:feed</code> element
* weblog pages MAY have multiple <code>atom:feed</code> element enclosing different groups of entries
* <code>atom:feed</code> elements MUST NOT be nested
* weblog pages that have exactly one entry MAY use the <code>atom:feed</code>

=== Example Transformation ===

''Note that the string 'atom:feed' is a placeholder for something to be decided later.''

Original (obviously, if there is no existing EntryGroup block element, one can be added):

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div id="content" class="atom:feed">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

== EntryGroup Title ==
Not covered by this proposal yet.

== EntryGroup Permalink ==
Not covered by this proposal yet.

== Individual Entry ==

This corresponds almost exactly to the <code>atom:entry</code> or <code>rss2:item</code> elements. See [[blog-post-examples#Individual_Entry]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog entries MUST be enclosed in a single <code>atom:entry</code> element
* <code>atom:entry</code> elements MUST NOT be nested
* <code>atom:entry</code> MUST NOT belong to more than one <code>atom:feed</code> element

=== Example Transformation ===
''Note that the string 'atom:entry' is a placeholder for something to be decided later.''

==== Entries in existing block ====

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

==== Entries not in an existing block ====

Original:

<pre><nowiki>
<a name="112877372228959075">&nbsp;</a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

Note the additional changes were also made:
* <code><br></code> was made XHTML compliant
* <code><a name="..."></code> was converted to a <code>id="..."</code> (''confirm this is OK'')

==== Disjointed entries ====

Ignore any existing blocks and treat as the previous case of no block.

== Entry Title ==

This corresponds almost exactly to the <code>atom:title</code> or <code>rss2:title</code> elements. See [[blog-post-formats#Titles]] for examples from which we see that there are two fundemental ways titles are used in the wild: at the block level and inline. Our proposal must be capable of handling both forms.

=== Microformat Recommendation ===

* <code>atom:entry</code>s SHOULD have at most one title
* block level titles SHOULD be represented using <code><h#></code>, the first such element in a <code>atom:entry</code> should be considered the title; this need not be marked up or identified in any other way as the title
* inline titles MUST be marked as <code>atom:title</code>; it is also possible to do this using block level formatting such as <code><div></code>, but this is discouraged

=== Discussion: why not always <code><h#></code>? ===

Using CSS <code>display: inline</code>, block level elements can be converted to inline elements. Unfortunately, we cannot nest <code><h#></code> inside of a <code><p></code> block to achieve the correct effect. I.e. we cannot convert ...

<pre><nowiki>
<p><strong>The Title</strong>: The Text...</p>
</nowiki></pre>

... into ...

<pre><nowiki>
<p><h3 style="display: inline">The Title</h3>: The Text ...</p>
</nowiki></pre>

... because the XHTML will not validate. Also...

<pre><nowiki>
<h3 style="display: inline">The Title</h3><p>: The Text ...</p>
</nowiki></pre>

... will not work because presentation effect will be different than what the user intends (because the <code><p></code> will introduce a line break).

=== Example Transformation ===

''Note that the string 'atom:title' is a placeholder for something to be decided later.''

==== Header in <code><h#></code> block ====
Original (and Final):

<pre>
<div class="atom:entry">
<h2 id="post-59">Web Essentials Audio</h2>
... reset of entry ...
</div>
</pre>

No transformation is needed -- the blog-post microformat will recognize this as the <code>atom:title</code>.

==== Header in other block element ====

Original:

<pre>
<div class="atom:entry">
<div class"header">Web Essentials Audio</div>
</div>
</pre>

Transformed (the header level is to taste):

<pre>
<div class="atom:entry">
<h3>Web Essentials Audio</h3>
</div>
</pre>

It is possible to add <code>class"atom:title"</code> to the <code>div</code> but we recommend against it. However, we recognize that there may be certain [http://microformats.org/wiki/blog-post-formats#Discussion_Forum_.2F_Bulletin_Board_Formats BB Tools] that making this change may be too difficult.

==== Header in inline element ====

Original:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong class="atom:title">Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

== Entry Content ==

This roughly corresponds to <code>atom:content</code> and/or <code>atom:summary</code> elements. See [[blog-post-examples#Entry_Content]] for the various forms seen in the wild.

=== Discussion: the split content problem ===

The last item above (content broken into multiple sections) introduces a few unique problems. It is not sufficient to enclose all the different content sections in a <code>atom:content</code> element, as the following example illustrates:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
"Read More"
... second part of the content ...
</div>
</div>
</nowiki></pre>

"Read More" is not part of the content! Therefore, we propose that ''multiple'' content sections be allowed in a single <code>atom:entry</code>. The concatenation of all these content blocks will define the complete content:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
</div>
"Read More"
<div class="atom:content">
... second part of the content ...
</div>
</div>
</nowiki></pre>

The same argument is applicable to <code>atom:summary</code>.

=== Microformat Recommendation ===

* an <code>atom:entry</code> MAY have zero or more <code>atom:summary</code> sections. There is no requirement that different representations of the same entry (on different URIs) use the same summaries.
* an <code>atom:entry</code> MAY have zero or more <code>atom:content</code> sections. The serial concatenation of all the <code>atom:content</code> sections within the entry MUST represent the complete content of the entry. Note that the rule here is slightly different than [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom] which only allows one <code>atom:content</code>.

=== Example Transformation ===

''Note that the strings 'atom:summary' and 'atom:content' (etc.) are placeholders for something to be decided later.''

==== Entry with summary content ====
Original:

<pre><nowiki>
<div class="inlineBlog">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<p>
The folks at ... the rest of the content
</p>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="inlineBlog atom:entry">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink atom:permalink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<div class="atom:summary">
<p>
The folks at ... the rest of the content
</p>
</div>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Notes:
* we didn't do anything with the "abstract" section -- this is a discussion for another day
* we didn't include the tag stuff in the summary, and probably wouldn't if this was the complete content

==== Entry with complete content ====
Original:

<pre><nowiki>
<div class="entry single">
<h2 id="post-61">Class attributes are about more than styling</h2>

<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="entry single atom:entry">
<h2 id="post-61">Class attributes are about more than styling</h2>

<div class="atom:content">
<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...
</div>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Notes:
* the only thing that really needed to be done is enclose the content
* my preference would be to move the post <code>id</code> to the <code>atom:entry</code>

==== Entry with split content (multiple sections) ====
Original:

<pre><nowiki>
<div class="blogbody">
<a name="008148"></a>

<div class="title">
Face to face: why places will continue to exist
</div>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="blogbody atom:entry" id="008148">
<h3>
Face to face: why places will continue to exist
</h3>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<div class="atom:content">
<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...
</div>

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<div class="atom:content">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...
</div>

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Note:
* <code>atom:content</code> <code>div</code>s were created for each the of the text sections, so that non-content coded would not be incorrectly marked
* there are '''two''' <code>atom:content</code> sections; together they make the complete content
* the conversion of <code><div class="header"></code> to <code><h3></code>
* the addition of <code>atom:entry</code> as needed
* the removal of the <code><a name="008148"></code> in favor of placing an <code>id</code> on the <code>atom:entry</code>
* further manipulation of the author could be done
* further manipulation of the category could be done

== Entry Permalink ==

Permalinks roughly correspond to <code>atom:link</code>. See [[blog-post-examples#Entry_Permalinks]] for examples.

A permalink is called '''canonical''' if it is the best representation of the URI for that entry; the definition of what 'best representation' is is entirely at the discretion of the weblog's publisher. We recommend that weblogs use canonical URIs because it allows "threading" together multiple posts and sources with byte-level comparisons. In general, the canonical URI should be the link used in an Atom entry.

=== Microformat Recommendation ===

* an Entry MUST NOT have more than one permalink marked as <code>atom:link</code>
* permalinks SHOULD be absolute URIs
* permalinks SHOULD be canonical
* permalinks SHOULD be the same as the <code>atom:link</code> used in syndication feeds

=== Example Transformations ===

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="atom:link bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Original:

<pre><nowiki>
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry">
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a rel="atom:link" href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

== Entry Datetimes - Creation and Modified ==
Weblogs typically display (in HTML) the creation time of their posts (roughly but not exactly corresponding to <code>atom:published</code>) and not so much the last modified time (<code>atom:updated</code>).

Also see [[datetime-design-pattern]] for more information on specifying datetimes. The recommendation here is styled after datetimes in [[hcalendar]].

=== Forms seen in the wild ===
See [[blog-post-formats#Datetimes]]

=== Microformat Recommendation ===

* date headers between weblog entries are outside of this microformat
* <code>atom:published</code> SHOULD be indicated by an <code>abbr</code> element around the human readable version of the date or datetime.
** the 'class' attribute MUST indicate <code>atom:published</code>
** the 'title' attribute MUST be a complete datetime, in the format of [[datetime-design-pattern]]
* likewise for <code>atom:updated</code>, if present

=== Example transformation ===

''Note that the string 'atom:published' is a placeholder for something to be decided later.''

Original:

<pre>
<a href"...">Friday, September 30th, 2005 at 12:31 pm</a>
</pre>

Transformed:

<pre>
<a href"..."><abbr
class"atom:published"
title"200050930T12:31:01-0500">Friday, September 30th, 2005 at 12:31 pm</abbr></a>
</pre>

== Entry Author ==
A work in progress

=== Microformat Recommendation ===

* Entry Authors SHOULD be inside a <code><address</code> block

= Possible Uses =

This section describes potential applications for a blog post microformat

== Transformational Uses ==

By transformational, we mean feeding a weblog post to some sort of transformation tool (such as XSLT) to produce a different version of the post fit for a different use.

=== Printing Weblog Posts ===
=== Reblogging ===

== Archival Uses ==

By 'archival', we mean taking weblog entries and placing them in a database for later analysis, searching, aggregation and so forth.

=== Personal Database ===
=== Search Engines ===

=Obstacles=

==Header Tag for Entry Title?==
--[[User:Bryan|Bryan]] 14:55, 14 Aug 2005 (PDT)

Many weblog CMSes allow for concurrent publishing of entries in the following ways:

* multiple entries on a page (an "Index," monthly archive, category archive, etc. see [http://re-run.com/category/creative/comedy/ Example])
* one entry on a page (see [http://re-run.com/2005/02/11/nickels-worth-of-free-advice/ Example])

Early attempts at [[blog-post-formats]] have set the title of the blog post to use the h3 tag.

At least where individual entry pages are concerned (and possible including indexes and archives), I recommend using h1 for the entry title, given that the entry is by far the most important chunk of information on the page, and it's what we'd want search engines to recognize as such. In the case where the h1 was used for the site title, fears about "losing" this information should be allayed by simply including the site name in the title tag, <strong>after</strong> the title of the article / entry / post.

:Whether an h3 or h1 is used is irrelevant, the semantics will be applied with classnames. This is a non-issue. --[[User:RyanKing|RyanKing]] 22:35, 18 Aug 2005 (PDT)

=See Also=
* [[blog-post-formats]] - many examples taken from the real world about how blog content is marked up
* [[blog-post]] - coming soon; a proposal for a microformat
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [http://blogs.oreillynet.com/beasts/archives/2005/10/blog_post_microformat_proposal.html Blog Post Microformat Proposal] Some thoughts on the topic with useful illustrations.
* [http://dannyayers.com/archives/2005/08/27/hatom-no-seriously/ Danny Ayers] proposes the name hAtom and some applications
* [http://torrez.us/archives/2005/10/07/404 Elias Torres] says we need 'hAtom'

blog-post-brainstorming

2005-10-22T05:10:16Z

MikeTaylor: second entry was oddly worded - tried to simplify the sentance

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.oreillynet.com Justin Watt]

= Purpose =
The 'blog-post-microformat' proposes a codification of how blog posts are indentifies within weblogs. It is hoped that this should be considered to be 'expansive': for example, the proposal could be used on [http://www.cnn.com CNN.com] to mark up news articles and summary pages.

= Terminology =

This section explores the terminology that should used to discuss a blog post microformat. To make it easier to talk about the various different types of teminology, We're using a XML-like namespace version so we can make statements like <code>atom:entry</code> is roughly equivalent to <code>rss20:feed</code>, <code>atom:feed/atom:link@relalternate</code> is roughly equivalent to <code>rss20:channel/rss20:link</code> or <code>atom:author</code> is '''not''' equivalent to <code>rss:entry/rss:author</code> (because RSS 2.0 is only the definition of an email address).

== Common terminology in weblogs ==

Reviewing [[blog-post-formats#Tools]], one can see that there's little standardization amongst tools or even within a individual tool (such as 'blogger') for names of elements of blog posts. There are however many common elements, including:

* a container for all posts/entries
* a container for individual posts
* the post content, which can be complete, summarized with a link to the complete link, or a couple of paragraphs with javascript/CSS tricks to reveal the remainder of the content
* the name of the author
* the posting date (in many many formats)

Although this looks like a bit of a dog's breakfast, there is usually a fair amount of rigour behind the presentation, as Atom and/or RSS feeds can be produced also from the same tools.

Furthermore, in developing a microformat for weblog posts, we want to be careful not to break any (or many) templates. Note that many weblog templates will have to be updated as they produce somewhat crufty HTML rather than shiny XHTML.

== Atom Terminology ==

See [http://www.atomenabled.org/ here] for the spec and [[blog-post-formats#Atom]] for analysis.

* <code>atom:feed</code> - (composite) a collection of entries plus information about them
** <code>atom:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>atom:id</code> - a permament identifier for a feed
** <code>atom:title</code> - the title of an atom:entry or a atom:feed
** <code>atom:updated</code> - the last time the feed was updated
** <code>atom:link@relalternate</code> - the home page of a feed
** <code>atom:link@relself</code> - the URI of the feed (where it can be downloaded)
** <code>atom:entry</code> - (composite) an entry within the feed
*** <code>atom:content</code> - the feed's content
*** <code>atom:summary</code> - a summary of the feed's content
*** <code>atom:entry/link</code> - the permament URI of the entry
*** <code>atom:published</code> - the time of the initial creation or first availability of the entry

== RSS Terminology ==

See [http://blogs.law.harvard.edu/tech/rss here] for the spec and [[blog-post-formats#RSS]] for analysis. There are a lot more elements in RSS but this covers the most commonly used ones.

* <code>rss2:channel</code> - (composite) a collection of entries plus information about them
** <code>rss2:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>rss2:link</code> - The URL to the HTML website corresponding to the channel (compare to atom:link@relalternate)
** <code>rss2:title</code> - the title of an rss2:channel or a rss2:item
** <code>rss2:pubDate</code> - The publication date for the content in the channel.
** <code>rss2:item</code> - (composite) an entry within the feed
*** <code>rss2:item/link</code> - The URL of the item. Note that this may not be a permalink for the item; it may be a link to some other page on the Internet that the rss2:item is about
*** <code>rss2:description</code> - The item synopsis [sic]. There is no special indication whether this is the full content of an entry, a summary, or a precis of what the rss2:item/link is pointing to
*** <code>rss2:author</code> - email address of the author of the item

== Recommendation ==

Atom has a much more precise mechanism for defining syndication feeds and weblog data. A mechanical transformation from Atom -> RSS will always lead to a correct RSS feed; a RSS -> Atom translation would have to make a decision amongst multiple definitions that may not always be correct. For example, the format of markup, the role of an author, or the meaning of a link.

IMPORTANT: we shall talk about things such as 'marking elements <code>atom:feed</code>'; consider this a purely conceptual thing. The text 'atom:feed' will not appear in the XHTML microformat -- we may decide later to use the actual phrase 'atom_feed', 'feed', 'items' or 'googlybear'. In the case where there is no clear or applicable atom terminology, we shall use 'weblog:xxx'.

= Discovered Elements =

This section explores the information discovered from [[blog-post-formats]] using the terminology discussed above. We will only focus on the major elements of weblog posts:

* the EntryGroup
* the individual Entry
* the Entry Title
* the Entry Content
* the Entry Permalink
* the Entry Datetimes

For now, the codification of the following major elements will be deferred as there is/may be overlap with other microformats that should be explored further

* the EntryGroup Title
* the EntryGroup Permalink
* the Entry Poster/Author - in particular, should hcard be used?

Further input from the community would be appreciated here

== EntryGroup ==

Roughly speaking, this corresponds to 'atom:feed' or 'rss2:channel' (in particular, the items within those XML elements). See [[blog-post-examples#EntryGroup]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog pages (including home pages, archives, category pages, tag pages and so forth) that may container multiple entries MUST enclose the entries in a <code>atom:feed</code> element
* weblog pages MAY have multiple <code>atom:feed</code> element enclosing different groups of entries
* <code>atom:feed</code> elements MUST NOT be nested
* weblog pages that have exactly one entry MAY use the <code>atom:feed</code>

=== Example Transformation ===

''Note that the string 'atom:feed' is a placeholder for something to be decided later.''

Original (obviously, if there is no existing EntryGroup block element, one can be added):

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div id="content" class="atom:feed">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

== EntryGroup Title ==
Not covered by this proposal yet.

== EntryGroup Permalink ==
Not covered by this proposal yet.

== Individual Entry ==

This corresponds almost exactly to the <code>atom:entry</code> or <code>rss2:item</code> elements. See [[blog-post-examples#Individual_Entry]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog entries MUST be enclosed in a single <code>atom:entry</code> element
* <code>atom:entry</code> elements MUST NOT be nested
* <code>atom:entry</code> MUST NOT belong to more than one <code>atom:feed</code> element

=== Example Transformation ===
''Note that the string 'atom:entry' is a placeholder for something to be decided later.''

==== Entries in existing block ====

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

==== Entries not in an existing block ====

Original:

<pre><nowiki>
<a name="112877372228959075">&nbsp;</a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

Note the additional changes were also made:
* <code><br></code> was made XHTML compliant
* <code><a name="..."></code> was converted to a <code>id="..."</code> (''confirm this is OK'')

==== Disjointed entries ====

Ignore any existing blocks and treat as the previous case of no block.

== Entry Title ==

This corresponds almost exactly to the <code>atom:title</code> or <code>rss2:title</code> elements. See [[blog-post-formats#Titles]] for examples from which we see that there are two fundemental ways titles are used in the wild: at the block level and inline. Our proposal must be capable of handling both forms.

=== Microformat Recommendation ===

* <code>atom:entry</code>s SHOULD have at most one title
* block level titles SHOULD be represented using <code><h#></code>, the first such element in a <code>atom:entry</code> should be considered the title; this need not be marked up or identified in any other way as the title
* inline titles MUST be marked as <code>atom:title</code>; it is also possible to do this using block level formatting such as <code><div></code>, but this is discouraged

=== Discussion: why not always <code><h#></code>? ===

Using CSS <code>display: inline</code>, block level elements can be converted to inline elements. Unfortunately, we cannot nest <code><h#></code> inside of a <code><p></code> block to achieve the correct effect. I.e. we cannot convert ...

<pre><nowiki>
<p><strong>The Title</strong>: The Text...</p>
</nowiki></pre>

... into ...

<pre><nowiki>
<p><h3 style="display: inline">The Title</h3>: The Text ...</p>
</nowiki></pre>

... because the XHTML will not validate. Also...

<pre><nowiki>
<h3 style="display: inline">The Title</h3><p>: The Text ...</p>
</nowiki></pre>

... will not work because presentation effect will be different than what the user intends (because the <code><p></code> will introduce a line break).

=== Example Transformation ===

''Note that the string 'atom:title' is a placeholder for something to be decided later.''

==== Header in <code><h#></code> block ====
Original (and Final):

<pre>
<div class="atom:entry">
<h2 id="post-59">Web Essentials Audio</h2>
... reset of entry ...
</div>
</pre>

No transformation is needed -- the blog-post microformat will recognize this as the <code>atom:title</code>.

==== Header in other block element ====

Original:

<pre>
<div class="atom:entry">
<div class"header">Web Essentials Audio</div>
</div>
</pre>

Transformed (the header level is to taste):

<pre>
<div class="atom:entry">
<h3>Web Essentials Audio</h3>
</div>
</pre>

It is possible to add <code>class"atom:title"</code> to the <code>div</code> but we recommend against it. However, we recognize rgar there may be certain [http://microformats.org/wiki/blog-post-formats#Discussion_Forum_.2F_Bulletin_Board_Formats BB Tools] that making this change may be too difficult.

==== Header in inline element ====

Original:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong class="atom:title">Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

== Entry Content ==

This roughly corresponds to <code>atom:content</code> and/or <code>atom:summary</code> elements. See [[blog-post-examples#Entry_Content]] for the various forms seen in the wild.

=== Discussion: the split content problem ===

The last item above (content broken into multiple sections) introduces a few unique problems. It is not sufficient to enclose all the different content sections in a <code>atom:content</code> element, as the following example illustrates:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
"Read More"
... second part of the content ...
</div>
</div>
</nowiki></pre>

"Read More" is not part of the content! Therefore, we propose that ''multiple'' content sections be allowed in a single <code>atom:entry</code>. The concatenation of all these content blocks will define the complete content:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
</div>
"Read More"
<div class="atom:content">
... second part of the content ...
</div>
</div>
</nowiki></pre>

The same argument is applicable to <code>atom:summary</code>.

=== Microformat Recommendation ===

* an <code>atom:entry</code> MAY have zero or more <code>atom:summary</code> sections. There is no requirement that different representations of the same entry (on different URIs) use the same summaries.
* an <code>atom:entry</code> MAY have zero or more <code>atom:content</code> sections. The serial concatenation of all the <code>atom:content</code> sections within the entry MUST represent the complete content of the entry. Note that the rule here is slightly different than [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom] which only allows one <code>atom:content</code>.

=== Example Transformation ===

''Note that the strings 'atom:summary' and 'atom:content' (etc.) are placeholders for something to be decided later.''

==== Entry with summary content ====
Original:

<pre><nowiki>
<div class="inlineBlog">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<p>
The folks at ... the rest of the content
</p>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="inlineBlog atom:entry">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink atom:permalink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<div class="atom:summary">
<p>
The folks at ... the rest of the content
</p>
</div>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Notes:
* we didn't do anything with the "abstract" section -- this is a discussion for another day
* we didn't include the tag stuff in the summary, and probably wouldn't if this was the complete content

==== Entry with complete content ====
Original:

<pre><nowiki>
<div class="entry single">
<h2 id="post-61">Class attributes are about more than styling</h2>

<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="entry single atom:entry">
<h2 id="post-61">Class attributes are about more than styling</h2>

<div class="atom:content">
<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...
</div>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Notes:
* the only thing that really needed to be done is enclose the content
* my preference would be to move the post <code>id</code> to the <code>atom:entry</code>

==== Entry with split content (multiple sections) ====
Original:

<pre><nowiki>
<div class="blogbody">
<a name="008148"></a>

<div class="title">
Face to face: why places will continue to exist
</div>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="blogbody atom:entry" id="008148">
<h3>
Face to face: why places will continue to exist
</h3>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<div class="atom:content">
<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...
</div>

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<div class="atom:content">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...
</div>

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Note:
* <code>atom:content</code> <code>div</code>s were created for each the of the text sections, so that non-content coded would not be incorrectly marked
* there are '''two''' <code>atom:content</code> sections; together they make the complete content
* the conversion of <code><div class="header"></code> to <code><h3></code>
* the addition of <code>atom:entry</code> as needed
* the removal of the <code><a name="008148"></code> in favor of placing an <code>id</code> on the <code>atom:entry</code>
* further manipulation of the author could be done
* further manipulation of the category could be done

== Entry Permalink ==

Permalinks roughly correspond to <code>atom:link</code>. See [[blog-post-examples#Entry_Permalinks]] for examples.

A permalink is called '''canonical''' if it is the best representation of the URI for that entry; the definition of what 'best representation' is is entirely at the discretion of the weblog's publisher. We recommend that weblogs use canonical URIs because it allows "threading" together multiple posts and sources with byte-level comparisons. In general, the canonical URI should be the link used in an Atom entry.

=== Microformat Recommendation ===

* an Entry MUST NOT have more than one permalink marked as <code>atom:link</code>
* permalinks SHOULD be absolute URIs
* permalinks SHOULD be canonical
* permalinks SHOULD be the same as the <code>atom:link</code> used in syndication feeds

=== Example Transformations ===

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="atom:link bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Original:

<pre><nowiki>
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry">
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a rel="atom:link" href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

== Entry Datetimes - Creation and Modified ==
Weblogs typically display (in HTML) the creation time of their posts (roughly but not exactly corresponding to <code>atom:published</code>) and not so much the last modified time (<code>atom:updated</code>).

Also see [[datetime-design-pattern]] for more information on specifying datetimes. The recommendation here is styled after datetimes in [[hcalendar]].

=== Forms seen in the wild ===
See [[blog-post-formats#Datetimes]]

=== Microformat Recommendation ===

* date headers between weblog entries are outside of this microformat
* <code>atom:published</code> SHOULD be indicated by an <code>abbr</code> element around the human readable version of the date or datetime.
** the 'class' attribute MUST indicate <code>atom:published</code>
** the 'title' attribute MUST be a complete datetime, in the format of [[datetime-design-pattern]]
* likewise for <code>atom:updated</code>, if present

=== Example transformation ===

''Note that the string 'atom:published' is a placeholder for something to be decided later.''

Original:

<pre>
<a href"...">Friday, September 30th, 2005 at 12:31 pm</a>
</pre>

Transformed:

<pre>
<a href"..."><abbr
class"atom:published"
title"200050930T12:31:01-0500">Friday, September 30th, 2005 at 12:31 pm</abbr></a>
</pre>

== Entry Author ==
A work in progress

=== Microformat Recommendation ===

* Entry Authors SHOULD be inside a <code><address</code> block

= Possible Uses =

This section describes potential applications for a blog post microformat

== Transformational Uses ==

By transformational, we mean feeding a weblog post to some sort of transformation tool (such as XSLT) to produce a different version of the post fit for a different use.

=== Printing Weblog Posts ===
=== Reblogging ===

== Archival Uses ==

By 'archival', we mean taking weblog entries and placing them in a database for later analysis, searching, aggregation and so forth.

=== Personal Database ===
=== Search Engines ===

=Obstacles=

==Header Tag for Entry Title?==
--[[User:Bryan|Bryan]] 14:55, 14 Aug 2005 (PDT)

Many weblog CMSes allow for concurrent publishing of entries in the following ways:

* multiple entries on a page (an "Index," monthly archive, category archive, etc. see [http://re-run.com/category/creative/comedy/ Example])
* one entry on a page (see [http://re-run.com/2005/02/11/nickels-worth-of-free-advice/ Example])

Early attempts at [[blog-post-formats]] have set the title of the blog post to use the h3 tag.

At least where individual entry pages are concerned (and possible including indexes and archives), I recommend using h1 for the entry title, given that the entry is by far the most important chunk of information on the page, and it's what we'd want search engines to recognize as such. In the case where the h1 was used for the site title, fears about "losing" this information should be allayed by simply including the site name in the title tag, <strong>after</strong> the title of the article / entry / post.

:Whether an h3 or h1 is used is irrelevant, the semantics will be applied with classnames. This is a non-issue. --[[User:RyanKing|RyanKing]] 22:35, 18 Aug 2005 (PDT)

=See Also=
* [[blog-post-formats]] - many examples taken from the real world about how blog content is marked up
* [[blog-post]] - coming soon; a proposal for a microformat
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [http://blogs.oreillynet.com/beasts/archives/2005/10/blog_post_microformat_proposal.html Blog Post Microformat Proposal] Some thoughts on the topic with useful illustrations.
* [http://dannyayers.com/archives/2005/08/27/hatom-no-seriously/ Danny Ayers] proposes the name hAtom and some applications
* [http://torrez.us/archives/2005/10/07/404 Elias Torres] says we need 'hAtom'

blog-post-brainstorming

2005-10-22T05:01:16Z

MikeTaylor: removed extranious "not" from "MUST NOT not"

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.oreillynet.com Justin Watt]

= Purpose =
The 'blog-post-microformat' proposes a codification of how blog posts are indentifies within weblogs. It is hoped that this should be considered to be 'expansive': for example, the proposal could be used on [http://www.cnn.com CNN.com] to mark up news articles and summary pages.

= Terminology =

This section explores the terminology that should used to discuss a blog post microformat. To make it easier to talk about the various different types of teminology, We're using a XML-like namespace version so we can make statements like <code>atom:entry</code> is roughly equivalent to <code>rss20:feed</code>, <code>atom:feed/atom:link@relalternate</code> is roughly equivalent to <code>rss20:channel/rss20:link</code> or <code>atom:author</code> is '''not''' equivalent to <code>rss:entry/rss:author</code> (because RSS 2.0 is only the definition of an email address).

== Common terminology in weblogs ==

Reviewing [[blog-post-formats#Tools]], one can see that there's little standardization amongst tools or even within a individual tool (such as 'blogger') for names of elements of blog posts. There are however many common elements, including:

* a container for all posts/entries
* a container for individual posts
* the post content, which can be complete, summarized with a link to the complete link, or a couple of paragraphs with javascript/CSS tricks to reveal the remainder of the content
* the name of the author
* the posting date (in many many formats)

Although this looks like a bit of a dog's breakfast, there is usually a fair amount of rigour behind the presentation, as Atom and/or RSS feeds can be produced also from the same tools.

Furthermore, in developing a microformat for weblog posts, we want to be careful not to break any (or many) templates. Note that many weblog templates will have to be updated as they produce somewhat crufty HTML rather than shiny XHTML.

== Atom Terminology ==

See [http://www.atomenabled.org/ here] for the spec and [[blog-post-formats#Atom]] for analysis.

* <code>atom:feed</code> - (composite) a collection of entries plus information about them
** <code>atom:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>atom:id</code> - a permament identifier for a feed
** <code>atom:title</code> - the title of an atom:entry or a atom:feed
** <code>atom:updated</code> - the last time the feed was updated
** <code>atom:link@relalternate</code> - the home page of a feed
** <code>atom:link@relself</code> - the URI of the feed (where it can be downloaded)
** <code>atom:entry</code> - (composite) an entry within the feed
*** <code>atom:content</code> - the feed's content
*** <code>atom:summary</code> - a summary of the feed's content
*** <code>atom:entry/link</code> - the permament URI of the entry
*** <code>atom:published</code> - the time of the initial creation or first availability of the entry

== RSS Terminology ==

See [http://blogs.law.harvard.edu/tech/rss here] for the spec and [[blog-post-formats#RSS]] for analysis. There are a lot more elements in RSS but this covers the most commonly used ones.

* <code>rss2:channel</code> - (composite) a collection of entries plus information about them
** <code>rss2:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>rss2:link</code> - The URL to the HTML website corresponding to the channel (compare to atom:link@relalternate)
** <code>rss2:title</code> - the title of an rss2:channel or a rss2:item
** <code>rss2:pubDate</code> - The publication date for the content in the channel.
** <code>rss2:item</code> - (composite) an entry within the feed
*** <code>rss2:item/link</code> - The URL of the item. Note that this may not be a permalink for the item; it may be a link to some other page on the Internet that the rss2:item is about
*** <code>rss2:description</code> - The item synopsis [sic]. There is no special indication whether this is the full content of an entry, a summary, or a precis of what the rss2:item/link is pointing to
*** <code>rss2:author</code> - email address of the author of the item

== Recommendation ==

Atom has a much more precise mechanism for defining syndication feeds and weblog data. A mechanical transformation from Atom -> RSS will always lead to a correct RSS feed; a RSS -> Atom translation would have to make a decision amongst multiple definitions that may not always be correct. For example, the format of markup, the role of an author, or the meaning of a link.

IMPORTANT: we shall talk about things such as 'marking elements <code>atom:feed</code>'; consider this a purely conceptual thing. The text 'atom:feed' will not appear in the XHTML microformat -- we may decide later to use the actual phrase 'atom_feed', 'feed', 'items' or 'googlybear'. In the case where there is no clear or applicable atom terminology, we shall use 'weblog:xxx'.

= Discovered Elements =

This section explores the information discovered from [[blog-post-formats]] using the terminology discussed above. We will only focus on the major elements of weblog posts:

* the EntryGroup
* the individual Entry
* the Entry Title
* the Entry Content
* the Entry Permalink
* the Entry Datetimes

For now, the codification of the following major elements will be deferred as there is/may be overlap with other microformats that should be explored further

* the EntryGroup Title
* the EntryGroup Permalink
* the Entry Poster/Author - in particular, should hcard be used?

Further input from the community would be appreciated here

== EntryGroup ==

Roughly speaking, this corresponds to 'atom:feed' or 'rss2:channel' (in particular, the items within those XML elements). See [[blog-post-examples#EntryGroup]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog pages (including home pages, archives, category pages, tag pages and so forth) that may container multiple entries MUST enclose the entries in a <code>atom:feed</code> element
* weblog pages MAY have multiple <code>atom:feed</code> element enclosing different groups of entries
* <code>atom:feed</code> elements MUST NOT be nested
* weblog pages that have exactly one entry MAY use the <code>atom:feed</code>

=== Example Transformation ===

''Note that the string 'atom:feed' is a placeholder for something to be decided later.''

Original (obviously, if there is no existing EntryGroup block element, one can be added):

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div id="content" class="atom:feed">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

== EntryGroup Title ==
Not covered by this proposal yet.

== EntryGroup Permalink ==
Not covered by this proposal yet.

== Individual Entry ==

This corresponds almost exactly to the <code>atom:entry</code> or <code>rss2:item</code> elements. See [[blog-post-examples#Individual_Entry]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog entries MUST be enclosed in a single <code>atom:entry</code> element
* <code>atom:entry</code> elements MUST NOT be nested
* <code>atom:entry</code> MUST NOT belong to more than one <code>atom:feed</code> element

=== Example Transformation ===
''Note that the string 'atom:entry' is a placeholder for something to be decided later.''

==== Entries in existing block ====

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

==== Entries not in an existing block ====

Original:

<pre><nowiki>
<a name="112877372228959075">&nbsp;</a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

Note the additional changes were also made:
* <code><br></code> was made XHTML compliant
* <code><a name="..."></code> was converted to a <code>id="..."</code> (''confirm this is OK'')

==== Disjointed entries ====

Ignore any existing blocks and treat as the previous case of no block.

== Entry Title ==

This corresponds almost exactly to the <code>atom:title</code> or <code>rss2:title</code> elements. See [[blog-post-formats#Titles]] for examples from which we see that there are two fundemental ways titles are used in the wild: at the block level and inline. Our proposal must be capable of handling both forms.

=== Microformat Recommendation ===

* <code>atom:entry</code>s SHOULD have at most 1 title
* block level titles SHOULD be represented using <code><h#></code>, the first such element for in a <code>atom:entry</code> being considered to be the title; this need not be marked up or identified in any other way as the title
* inline titles MUST be marked as <code>atom:title</code>; it is also possible to do this using block level formatting such as <code><div></code>, but this is discouraged

=== Discussion: why not always <code><h#></code>? ===

Using CSS <code>display: inline</code>, block level elements can be converted to inline elements. Unfortunately, we cannot nest <code><h#></code> inside of a <code><p></code> block to achieve the correct effect. I.e. we cannot convert ...

<pre><nowiki>
<p><strong>The Title</strong>: The Text...</p>
</nowiki></pre>

... into ...

<pre><nowiki>
<p><h3 style="display: inline">The Title</h3>: The Text ...</p>
</nowiki></pre>

... because the XHTML will not validate. Also...

<pre><nowiki>
<h3 style="display: inline">The Title</h3><p>: The Text ...</p>
</nowiki></pre>

... will not work because presentation effect will be different than what the user intends (because the <code><p></code> will introduce a line break).

=== Example Transformation ===

''Note that the string 'atom:title' is a placeholder for something to be decided later.''

==== Header in <code><h#></code> block ====
Original (and Final):

<pre>
<div class="atom:entry">
<h2 id="post-59">Web Essentials Audio</h2>
... reset of entry ...
</div>
</pre>

No transformation is needed -- the blog-post microformat will recognize this as the <code>atom:title</code>.

==== Header in other block element ====

Original:

<pre>
<div class="atom:entry">
<div class"header">Web Essentials Audio</div>
</div>
</pre>

Transformed (the header level is to taste):

<pre>
<div class="atom:entry">
<h3>Web Essentials Audio</h3>
</div>
</pre>

It is possible to add <code>class"atom:title"</code> to the <code>div</code> but we recommend against it. However, we recognize rgar there may be certain [http://microformats.org/wiki/blog-post-formats#Discussion_Forum_.2F_Bulletin_Board_Formats BB Tools] that making this change may be too difficult.

==== Header in inline element ====

Original:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong class="atom:title">Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

== Entry Content ==

This roughly corresponds to <code>atom:content</code> and/or <code>atom:summary</code> elements. See [[blog-post-examples#Entry_Content]] for the various forms seen in the wild.

=== Discussion: the split content problem ===

The last item above (content broken into multiple sections) introduces a few unique problems. It is not sufficient to enclose all the different content sections in a <code>atom:content</code> element, as the following example illustrates:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
"Read More"
... second part of the content ...
</div>
</div>
</nowiki></pre>

"Read More" is not part of the content! Therefore, we propose that ''multiple'' content sections be allowed in a single <code>atom:entry</code>. The concatenation of all these content blocks will define the complete content:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
</div>
"Read More"
<div class="atom:content">
... second part of the content ...
</div>
</div>
</nowiki></pre>

The same argument is applicable to <code>atom:summary</code>.

=== Microformat Recommendation ===

* an <code>atom:entry</code> MAY have zero or more <code>atom:summary</code> sections. There is no requirement that different representations of the same entry (on different URIs) use the same summaries.
* an <code>atom:entry</code> MAY have zero or more <code>atom:content</code> sections. The serial concatenation of all the <code>atom:content</code> sections within the entry MUST represent the complete content of the entry. Note that the rule here is slightly different than [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom] which only allows one <code>atom:content</code>.

=== Example Transformation ===

''Note that the strings 'atom:summary' and 'atom:content' (etc.) are placeholders for something to be decided later.''

==== Entry with summary content ====
Original:

<pre><nowiki>
<div class="inlineBlog">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<p>
The folks at ... the rest of the content
</p>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="inlineBlog atom:entry">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink atom:permalink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<div class="atom:summary">
<p>
The folks at ... the rest of the content
</p>
</div>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Notes:
* we didn't do anything with the "abstract" section -- this is a discussion for another day
* we didn't include the tag stuff in the summary, and probably wouldn't if this was the complete content

==== Entry with complete content ====
Original:

<pre><nowiki>
<div class="entry single">
<h2 id="post-61">Class attributes are about more than styling</h2>

<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="entry single atom:entry">
<h2 id="post-61">Class attributes are about more than styling</h2>

<div class="atom:content">
<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...
</div>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Notes:
* the only thing that really needed to be done is enclose the content
* my preference would be to move the post <code>id</code> to the <code>atom:entry</code>

==== Entry with split content (multiple sections) ====
Original:

<pre><nowiki>
<div class="blogbody">
<a name="008148"></a>

<div class="title">
Face to face: why places will continue to exist
</div>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="blogbody atom:entry" id="008148">
<h3>
Face to face: why places will continue to exist
</h3>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<div class="atom:content">
<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...
</div>

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<div class="atom:content">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...
</div>

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Note:
* <code>atom:content</code> <code>div</code>s were created for each the of the text sections, so that non-content coded would not be incorrectly marked
* there are '''two''' <code>atom:content</code> sections; together they make the complete content
* the conversion of <code><div class="header"></code> to <code><h3></code>
* the addition of <code>atom:entry</code> as needed
* the removal of the <code><a name="008148"></code> in favor of placing an <code>id</code> on the <code>atom:entry</code>
* further manipulation of the author could be done
* further manipulation of the category could be done

== Entry Permalink ==

Permalinks roughly correspond to <code>atom:link</code>. See [[blog-post-examples#Entry_Permalinks]] for examples.

A permalink is called '''canonical''' if it is the best representation of the URI for that entry; the definition of what 'best representation' is is entirely at the discretion of the weblog's publisher. We recommend that weblogs use canonical URIs because it allows "threading" together multiple posts and sources with byte-level comparisons. In general, the canonical URI should be the link used in an Atom entry.

=== Microformat Recommendation ===

* an Entry MUST NOT have more than one permalink marked as <code>atom:link</code>
* permalinks SHOULD be absolute URIs
* permalinks SHOULD be canonical
* permalinks SHOULD be the same as the <code>atom:link</code> used in syndication feeds

=== Example Transformations ===

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="atom:link bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Original:

<pre><nowiki>
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry">
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a rel="atom:link" href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

== Entry Datetimes - Creation and Modified ==
Weblogs typically display (in HTML) the creation time of their posts (roughly but not exactly corresponding to <code>atom:published</code>) and not so much the last modified time (<code>atom:updated</code>).

Also see [[datetime-design-pattern]] for more information on specifying datetimes. The recommendation here is styled after datetimes in [[hcalendar]].

=== Forms seen in the wild ===
See [[blog-post-formats#Datetimes]]

=== Microformat Recommendation ===

* date headers between weblog entries are outside of this microformat
* <code>atom:published</code> SHOULD be indicated by an <code>abbr</code> element around the human readable version of the date or datetime.
** the 'class' attribute MUST indicate <code>atom:published</code>
** the 'title' attribute MUST be a complete datetime, in the format of [[datetime-design-pattern]]
* likewise for <code>atom:updated</code>, if present

=== Example transformation ===

''Note that the string 'atom:published' is a placeholder for something to be decided later.''

Original:

<pre>
<a href"...">Friday, September 30th, 2005 at 12:31 pm</a>
</pre>

Transformed:

<pre>
<a href"..."><abbr
class"atom:published"
title"200050930T12:31:01-0500">Friday, September 30th, 2005 at 12:31 pm</abbr></a>
</pre>

== Entry Author ==
A work in progress

=== Microformat Recommendation ===

* Entry Authors SHOULD be inside a <code><address</code> block

= Possible Uses =

This section describes potential applications for a blog post microformat

== Transformational Uses ==

By transformational, we mean feeding a weblog post to some sort of transformation tool (such as XSLT) to produce a different version of the post fit for a different use.

=== Printing Weblog Posts ===
=== Reblogging ===

== Archival Uses ==

By 'archival', we mean taking weblog entries and placing them in a database for later analysis, searching, aggregation and so forth.

=== Personal Database ===
=== Search Engines ===

=Obstacles=

==Header Tag for Entry Title?==
--[[User:Bryan|Bryan]] 14:55, 14 Aug 2005 (PDT)

Many weblog CMSes allow for concurrent publishing of entries in the following ways:

* multiple entries on a page (an "Index," monthly archive, category archive, etc. see [http://re-run.com/category/creative/comedy/ Example])
* one entry on a page (see [http://re-run.com/2005/02/11/nickels-worth-of-free-advice/ Example])

Early attempts at [[blog-post-formats]] have set the title of the blog post to use the h3 tag.

At least where individual entry pages are concerned (and possible including indexes and archives), I recommend using h1 for the entry title, given that the entry is by far the most important chunk of information on the page, and it's what we'd want search engines to recognize as such. In the case where the h1 was used for the site title, fears about "losing" this information should be allayed by simply including the site name in the title tag, <strong>after</strong> the title of the article / entry / post.

:Whether an h3 or h1 is used is irrelevant, the semantics will be applied with classnames. This is a non-issue. --[[User:RyanKing|RyanKing]] 22:35, 18 Aug 2005 (PDT)

=See Also=
* [[blog-post-formats]] - many examples taken from the real world about how blog content is marked up
* [[blog-post]] - coming soon; a proposal for a microformat
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [http://blogs.oreillynet.com/beasts/archives/2005/10/blog_post_microformat_proposal.html Blog Post Microformat Proposal] Some thoughts on the topic with useful illustrations.
* [http://dannyayers.com/archives/2005/08/27/hatom-no-seriously/ Danny Ayers] proposes the name hAtom and some applications
* [http://torrez.us/archives/2005/10/07/404 Elias Torres] says we need 'hAtom'

blog-post-brainstorming

2005-10-22T04:57:18Z

MikeTaylor: typo

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.oreillynet.com Justin Watt]

= Purpose =
The 'blog-post-microformat' proposes a codification of how blog posts are indentifies within weblogs. It is hoped that this should be considered to be 'expansive': for example, the proposal could be used on [http://www.cnn.com CNN.com] to mark up news articles and summary pages.

= Terminology =

This section explores the terminology that should used to discuss a blog post microformat. To make it easier to talk about the various different types of teminology, We're using a XML-like namespace version so we can make statements like <code>atom:entry</code> is roughly equivalent to <code>rss20:feed</code>, <code>atom:feed/atom:link@relalternate</code> is roughly equivalent to <code>rss20:channel/rss20:link</code> or <code>atom:author</code> is '''not''' equivalent to <code>rss:entry/rss:author</code> (because RSS 2.0 is only the definition of an email address).

== Common terminology in weblogs ==

Reviewing [[blog-post-formats#Tools]], one can see that there's little standardization amongst tools or even within a individual tool (such as 'blogger') for names of elements of blog posts. There are however many common elements, including:

* a container for all posts/entries
* a container for individual posts
* the post content, which can be complete, summarized with a link to the complete link, or a couple of paragraphs with javascript/CSS tricks to reveal the remainder of the content
* the name of the author
* the posting date (in many many formats)

Although this looks like a bit of a dog's breakfast, there is usually a fair amount of rigour behind the presentation, as Atom and/or RSS feeds can be produced also from the same tools.

Furthermore, in developing a microformat for weblog posts, we want to be careful not to break any (or many) templates. Note that many weblog templates will have to be updated as they produce somewhat crufty HTML rather than shiny XHTML.

== Atom Terminology ==

See [http://www.atomenabled.org/ here] for the spec and [[blog-post-formats#Atom]] for analysis.

* <code>atom:feed</code> - (composite) a collection of entries plus information about them
** <code>atom:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>atom:id</code> - a permament identifier for a feed
** <code>atom:title</code> - the title of an atom:entry or a atom:feed
** <code>atom:updated</code> - the last time the feed was updated
** <code>atom:link@relalternate</code> - the home page of a feed
** <code>atom:link@relself</code> - the URI of the feed (where it can be downloaded)
** <code>atom:entry</code> - (composite) an entry within the feed
*** <code>atom:content</code> - the feed's content
*** <code>atom:summary</code> - a summary of the feed's content
*** <code>atom:entry/link</code> - the permament URI of the entry
*** <code>atom:published</code> - the time of the initial creation or first availability of the entry

== RSS Terminology ==

See [http://blogs.law.harvard.edu/tech/rss here] for the spec and [[blog-post-formats#RSS]] for analysis. There are a lot more elements in RSS but this covers the most commonly used ones.

* <code>rss2:channel</code> - (composite) a collection of entries plus information about them
** <code>rss2:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>rss2:link</code> - The URL to the HTML website corresponding to the channel (compare to atom:link@relalternate)
** <code>rss2:title</code> - the title of an rss2:channel or a rss2:item
** <code>rss2:pubDate</code> - The publication date for the content in the channel.
** <code>rss2:item</code> - (composite) an entry within the feed
*** <code>rss2:item/link</code> - The URL of the item. Note that this may not be a permalink for the item; it may be a link to some other page on the Internet that the rss2:item is about
*** <code>rss2:description</code> - The item synopsis [sic]. There is no special indication whether this is the full content of an entry, a summary, or a precis of what the rss2:item/link is pointing to
*** <code>rss2:author</code> - email address of the author of the item

== Recommendation ==

Atom has a much more precise mechanism for defining syndication feeds and weblog data. A mechanical transformation from Atom -> RSS will always lead to a correct RSS feed; a RSS -> Atom translation would have to make a decision amongst multiple definitions that may not always be correct. For example, the format of markup, the role of an author, or the meaning of a link.

IMPORTANT: we shall talk about things such as 'marking elements <code>atom:feed</code>'; consider this a purely conceptual thing. The text 'atom:feed' will not appear in the XHTML microformat -- we may decide later to use the actual phrase 'atom_feed', 'feed', 'items' or 'googlybear'. In the case where there is no clear or applicable atom terminology, we shall use 'weblog:xxx'.

= Discovered Elements =

This section explores the information discovered from [[blog-post-formats]] using the terminology discussed above. We will only focus on the major elements of weblog posts:

* the EntryGroup
* the individual Entry
* the Entry Title
* the Entry Content
* the Entry Permalink
* the Entry Datetimes

For now, the codification of the following major elements will be deferred as there is/may be overlap with other microformats that should be explored further

* the EntryGroup Title
* the EntryGroup Permalink
* the Entry Poster/Author - in particular, should hcard be used?

Further input from the community would be appreciated here

== EntryGroup ==

Roughly speaking, this corresponds to 'atom:feed' or 'rss2:channel' (in particular, the items within those XML elements). See [[blog-post-examples#EntryGroup]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog pages (including home pages, archives, category pages, tag pages and so forth) that may container multiple entries MUST enclose the entries in a <code>atom:feed</code> element
* weblog pages MAY have multiple <code>atom:feed</code> element enclosing different groups of entries
* <code>atom:feed</code> elements MUST NOT be nested
* weblog pages that have exactly one entry MAY use the <code>atom:feed</code>

=== Example Transformation ===

''Note that the string 'atom:feed' is a placeholder for something to be decided later.''

Original (obviously, if there is no existing EntryGroup block element, one can be added):

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div id="content" class="atom:feed">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

== EntryGroup Title ==
Not covered by this proposal yet.

== EntryGroup Permalink ==
Not covered by this proposal yet.

== Individual Entry ==

This corresponds almost exactly to the <code>atom:entry</code> or <code>rss2:item</code> elements. See [[blog-post-examples#Individual_Entry]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog entries MUST be enclosed in a single <code>atom:entry</code> element
* <code>atom:entry</code> elements MUST NOT be nested
* <code>atom:entry</code> MUST NOT not belong to more than one <code>atom:feed</code> element

=== Example Transformation ===
''Note that the string 'atom:entry' is a placeholder for something to be decided later.''

==== Entries in existing block ====

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

==== Entries not in an existing block ====

Original:

<pre><nowiki>
<a name="112877372228959075">&nbsp;</a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

Note the additional changes were also made:
* <code><br></code> was made XHTML compliant
* <code><a name="..."></code> was converted to a <code>id="..."</code> (''confirm this is OK'')

==== Disjointed entries ====

Ignore any existing blocks and treat as the previous case of no block.

== Entry Title ==

This corresponds almost exactly to the <code>atom:title</code> or <code>rss2:title</code> elements. See [[blog-post-formats#Titles]] for examples from which we see that there are two fundemental ways titles are used in the wild: at the block level and inline. Our proposal must be capable of handling both forms.

=== Microformat Recommendation ===

* <code>atom:entry</code>s SHOULD have at most 1 title
* block level titles SHOULD be represented using <code><h#></code>, the first such element for in a <code>atom:entry</code> being considered to be the title; this need not be marked up or identified in any other way as the title
* inline titles MUST be marked as <code>atom:title</code>; it is also possible to do this using block level formatting such as <code><div></code>, but this is discouraged

=== Discussion: why not always <code><h#></code>? ===

Using CSS <code>display: inline</code>, block level elements can be converted to inline elements. Unfortunately, we cannot nest <code><h#></code> inside of a <code><p></code> block to achieve the correct effect. I.e. we cannot convert ...

<pre><nowiki>
<p><strong>The Title</strong>: The Text...</p>
</nowiki></pre>

... into ...

<pre><nowiki>
<p><h3 style="display: inline">The Title</h3>: The Text ...</p>
</nowiki></pre>

... because the XHTML will not validate. Also...

<pre><nowiki>
<h3 style="display: inline">The Title</h3><p>: The Text ...</p>
</nowiki></pre>

... will not work because presentation effect will be different than what the user intends (because the <code><p></code> will introduce a line break).

=== Example Transformation ===

''Note that the string 'atom:title' is a placeholder for something to be decided later.''

==== Header in <code><h#></code> block ====
Original (and Final):

<pre>
<div class="atom:entry">
<h2 id="post-59">Web Essentials Audio</h2>
... reset of entry ...
</div>
</pre>

No transformation is needed -- the blog-post microformat will recognize this as the <code>atom:title</code>.

==== Header in other block element ====

Original:

<pre>
<div class="atom:entry">
<div class"header">Web Essentials Audio</div>
</div>
</pre>

Transformed (the header level is to taste):

<pre>
<div class="atom:entry">
<h3>Web Essentials Audio</h3>
</div>
</pre>

It is possible to add <code>class"atom:title"</code> to the <code>div</code> but we recommend against it. However, we recognize rgar there may be certain [http://microformats.org/wiki/blog-post-formats#Discussion_Forum_.2F_Bulletin_Board_Formats BB Tools] that making this change may be too difficult.

==== Header in inline element ====

Original:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong class="atom:title">Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

== Entry Content ==

This roughly corresponds to <code>atom:content</code> and/or <code>atom:summary</code> elements. See [[blog-post-examples#Entry_Content]] for the various forms seen in the wild.

=== Discussion: the split content problem ===

The last item above (content broken into multiple sections) introduces a few unique problems. It is not sufficient to enclose all the different content sections in a <code>atom:content</code> element, as the following example illustrates:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
"Read More"
... second part of the content ...
</div>
</div>
</nowiki></pre>

"Read More" is not part of the content! Therefore, we propose that ''multiple'' content sections be allowed in a single <code>atom:entry</code>. The concatenation of all these content blocks will define the complete content:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
</div>
"Read More"
<div class="atom:content">
... second part of the content ...
</div>
</div>
</nowiki></pre>

The same argument is applicable to <code>atom:summary</code>.

=== Microformat Recommendation ===

* an <code>atom:entry</code> MAY have zero or more <code>atom:summary</code> sections. There is no requirement that different representations of the same entry (on different URIs) use the same summaries.
* an <code>atom:entry</code> MAY have zero or more <code>atom:content</code> sections. The serial concatenation of all the <code>atom:content</code> sections within the entry MUST represent the complete content of the entry. Note that the rule here is slightly different than [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom] which only allows one <code>atom:content</code>.

=== Example Transformation ===

''Note that the strings 'atom:summary' and 'atom:content' (etc.) are placeholders for something to be decided later.''

==== Entry with summary content ====
Original:

<pre><nowiki>
<div class="inlineBlog">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<p>
The folks at ... the rest of the content
</p>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="inlineBlog atom:entry">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink atom:permalink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<div class="atom:summary">
<p>
The folks at ... the rest of the content
</p>
</div>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Notes:
* we didn't do anything with the "abstract" section -- this is a discussion for another day
* we didn't include the tag stuff in the summary, and probably wouldn't if this was the complete content

==== Entry with complete content ====
Original:

<pre><nowiki>
<div class="entry single">
<h2 id="post-61">Class attributes are about more than styling</h2>

<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="entry single atom:entry">
<h2 id="post-61">Class attributes are about more than styling</h2>

<div class="atom:content">
<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...
</div>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Notes:
* the only thing that really needed to be done is enclose the content
* my preference would be to move the post <code>id</code> to the <code>atom:entry</code>

==== Entry with split content (multiple sections) ====
Original:

<pre><nowiki>
<div class="blogbody">
<a name="008148"></a>

<div class="title">
Face to face: why places will continue to exist
</div>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="blogbody atom:entry" id="008148">
<h3>
Face to face: why places will continue to exist
</h3>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<div class="atom:content">
<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...
</div>

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<div class="atom:content">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...
</div>

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Note:
* <code>atom:content</code> <code>div</code>s were created for each the of the text sections, so that non-content coded would not be incorrectly marked
* there are '''two''' <code>atom:content</code> sections; together they make the complete content
* the conversion of <code><div class="header"></code> to <code><h3></code>
* the addition of <code>atom:entry</code> as needed
* the removal of the <code><a name="008148"></code> in favor of placing an <code>id</code> on the <code>atom:entry</code>
* further manipulation of the author could be done
* further manipulation of the category could be done

== Entry Permalink ==

Permalinks roughly correspond to <code>atom:link</code>. See [[blog-post-examples#Entry_Permalinks]] for examples.

A permalink is called '''canonical''' if it is the best representation of the URI for that entry; the definition of what 'best representation' is is entirely at the discretion of the weblog's publisher. We recommend that weblogs use canonical URIs because it allows "threading" together multiple posts and sources with byte-level comparisons. In general, the canonical URI should be the link used in an Atom entry.

=== Microformat Recommendation ===

* an Entry MUST NOT have more than one permalink marked as <code>atom:link</code>
* permalinks SHOULD be absolute URIs
* permalinks SHOULD be canonical
* permalinks SHOULD be the same as the <code>atom:link</code> used in syndication feeds

=== Example Transformations ===

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="atom:link bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Original:

<pre><nowiki>
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry">
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a rel="atom:link" href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

== Entry Datetimes - Creation and Modified ==
Weblogs typically display (in HTML) the creation time of their posts (roughly but not exactly corresponding to <code>atom:published</code>) and not so much the last modified time (<code>atom:updated</code>).

Also see [[datetime-design-pattern]] for more information on specifying datetimes. The recommendation here is styled after datetimes in [[hcalendar]].

=== Forms seen in the wild ===
See [[blog-post-formats#Datetimes]]

=== Microformat Recommendation ===

* date headers between weblog entries are outside of this microformat
* <code>atom:published</code> SHOULD be indicated by an <code>abbr</code> element around the human readable version of the date or datetime.
** the 'class' attribute MUST indicate <code>atom:published</code>
** the 'title' attribute MUST be a complete datetime, in the format of [[datetime-design-pattern]]
* likewise for <code>atom:updated</code>, if present

=== Example transformation ===

''Note that the string 'atom:published' is a placeholder for something to be decided later.''

Original:

<pre>
<a href"...">Friday, September 30th, 2005 at 12:31 pm</a>
</pre>

Transformed:

<pre>
<a href"..."><abbr
class"atom:published"
title"200050930T12:31:01-0500">Friday, September 30th, 2005 at 12:31 pm</abbr></a>
</pre>

== Entry Author ==
A work in progress

=== Microformat Recommendation ===

* Entry Authors SHOULD be inside a <code><address</code> block

= Possible Uses =

This section describes potential applications for a blog post microformat

== Transformational Uses ==

By transformational, we mean feeding a weblog post to some sort of transformation tool (such as XSLT) to produce a different version of the post fit for a different use.

=== Printing Weblog Posts ===
=== Reblogging ===

== Archival Uses ==

By 'archival', we mean taking weblog entries and placing them in a database for later analysis, searching, aggregation and so forth.

=== Personal Database ===
=== Search Engines ===

=Obstacles=

==Header Tag for Entry Title?==
--[[User:Bryan|Bryan]] 14:55, 14 Aug 2005 (PDT)

Many weblog CMSes allow for concurrent publishing of entries in the following ways:

* multiple entries on a page (an "Index," monthly archive, category archive, etc. see [http://re-run.com/category/creative/comedy/ Example])
* one entry on a page (see [http://re-run.com/2005/02/11/nickels-worth-of-free-advice/ Example])

Early attempts at [[blog-post-formats]] have set the title of the blog post to use the h3 tag.

At least where individual entry pages are concerned (and possible including indexes and archives), I recommend using h1 for the entry title, given that the entry is by far the most important chunk of information on the page, and it's what we'd want search engines to recognize as such. In the case where the h1 was used for the site title, fears about "losing" this information should be allayed by simply including the site name in the title tag, <strong>after</strong> the title of the article / entry / post.

:Whether an h3 or h1 is used is irrelevant, the semantics will be applied with classnames. This is a non-issue. --[[User:RyanKing|RyanKing]] 22:35, 18 Aug 2005 (PDT)

=See Also=
* [[blog-post-formats]] - many examples taken from the real world about how blog content is marked up
* [[blog-post]] - coming soon; a proposal for a microformat
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [http://blogs.oreillynet.com/beasts/archives/2005/10/blog_post_microformat_proposal.html Blog Post Microformat Proposal] Some thoughts on the topic with useful illustrations.
* [http://dannyayers.com/archives/2005/08/27/hatom-no-seriously/ Danny Ayers] proposes the name hAtom and some applications
* [http://torrez.us/archives/2005/10/07/404 Elias Torres] says we need 'hAtom'

hcalendar-issues

2005-10-15T07:06:58Z

MikeTaylor: removed extra bullet my previous edit introduced

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

* 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. 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
*# 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.
*# Here is example from Midgard CMS:
<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-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://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]].''

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

* 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]] 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 prifile URL?

* 2005-09-29 raised by RyanKing
*# How does one use ATTENDEE?

hcalendar-issues

2005-10-15T07:04:23Z

MikeTaylor: minor formatting change to place paragraphs inline with their siblings

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

* 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. 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
*# 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.
*# Here is example from Midgard CMS:
<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-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://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]].''

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

* 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]] 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 prifile URL?

* 2005-09-29 raised by RyanKing
*# How does one use ATTENDEE?

hcalendar-issues

2005-10-15T06:51:50Z

MikeTaylor: minor formatting change

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

* 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. 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
*# 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.
*# Here is example from Midgard CMS:
<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-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://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]].''

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

* 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]] 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 prifile URL?

* 2005-09-29 raised by RyanKing
*# How does one use ATTENDEE?

chat-examples

2005-10-15T06:36:49Z

MikeTaylor: /* IRC transcripts */

= chat examples =

Examples of how chat transcripts are marked up currently, with the idea of moving towards a

== Authors ==
* [http://epeus.blogspot.com Kevin Marks]

== IRC transcripts ==

These are plantext logs with space separated fields, so are posted wrapped in <pre>

<pre>12:06 Tantek: what does the datetime stamp represent?
12:07 KevinMarks: in iRC, when it was said
12:07 Tantek: is it a point in time *before* they started speaking?
12:07 Tantek: or *after*?
12:07 Tantek: or somewhere in the *middle*?
12:07 KevinMarks: usually it is quantised to seconds
12:07 KevinMarks: and it is time the msg was received
12:07 Tantek: but the second they started typing or pressed return?
12:08 KevinMarks: prssed return i think</pre>

Or as plaintext + <br> (eg http://chocnvodka.blogware.com/blog/_archives/2005/8/25/1169654.html)

(22:20) gturneruk: oh, i just remembered. windows 95 is ten years old today<br>
(22:22) Suw: good god. i mean, i shouldn't be surprised, it being 2005 and all. but still, where did that time go?<br>
(22:22) gturneruk: lost clusters<br>
(22:23) Suw: i obviously need to defrag

xChat2 log format

<pre>
**** BEGIN LOGGING AT Wed May 14 04:36:29 2003

May 14 04:36:29 --> You are now talking on #test
May 14 04:36:29 --- Topic for #test is Test Topic
May 14 04:36:29 --- Topic for #test set by nick1 at Thu May 8 18:45:05
May 14 04:58:45 --- You are now known as nick1
May 14 05:03:44 --> nick1 (~nick1@2.1.3.narf-42905) has joined #test
May 14 05:05:48 <nick1> test message
May 14 05:10:24 * nick1 test action
May 14 05:11:19 <-- nick1 has quit (quit)

**** ENDING LOGGING AT Fri Jul 4 00:28:22 2003
</pre>

Snak log format

<pre>
Log file opened at: 5/26/04 12:00:11 AM
[12:00:11:] nick1: test message
[12:10:29:] * nick1 test action
[12:13:16:] ***: nick2 (~nick2@test.net) has joined the channel
[12:20:35:] ***: nick2 has quit IRC ("Computer going to sleep...")
[12:21:31:] ***: You have joined the channel
Log file closed at: 5/26/04 2:29:08 AM
</pre>

== iChat transcripts ==

iChat handles timestamps differently, inserting them between statement blocks, every 5 minutes.

<pre>12:25 AM
Reconnecting to tantekatwork…
Kevin Marks: So, iChat shows timestamps between entries
Tantek: yes
Tantek: what about Adium?
12:30 AM
Kevin Marks: my copy is 230 days old...</pre>

== bash.org ==
Bash.org collects funny irc transcripts and lets people vote on them:
It uses plaintext + <br />, wrapped in <p>
http://bash.org/?23396
<p class="qt"><Donut[AFK]> HEY EURAKARTE<br />
<Donut[AFK]> INSULT<br />
<Eurakarte> RETORT<br />
<Donut[AFK]> COUNTER-RETORT<br />
<Eurakarte> QUESTIONING OF SEXUAL PREFERENCE<br />
<Donut[AFK]> SUGGESTION TO SHUT THE FUCK UP<br />
<Eurakarte> NOTATION THAT YOU CREATE A VACUUM<br />
<Donut[AFK]> RIPOSTE<br />
<Donut[AFK]> ADDON RIPOSTE<br />
<Eurakarte> COUNTER-RIPOSTE<br />
<Donut[AFK]> COUNTER-COUNTER RIPOSTE<br />
<Eurakarte> NONSENSICAL STATEMENT INVOLVING PLANKTON<br />
<Miles_Prower> RESPONSE TO RANDOM STATEMENT AND THREAT TO BAN OPPOSING SIDES<br />
<Eurakarte> WORDS OF PRAISE FOR FISHFOOD<br />
<Miles_Prower> ACKNOWLEDGEMENT AND ACCEPTENCE OF TERMS</p>

== Log Library ==
[http://www.loglibrary.com Log Library] displays a tabular format with divs
<pre>
<div class="row" name="GusVanNos">
<div class="timestamp">18:36:28</div>
<div class="nick"><GusVanNos></div>
<div class="message">.+. is a lazy way of saying .{2,}</div>
</div>

<div class="row" name="jawong">
<div class="timestamp">18:36:48</div>
<div class="nick"><jawong></div>
<div class="message">your model is waaaay better, xal.</div>
</div>
</pre>

chat-examples

2005-10-15T06:35:03Z

MikeTaylor: /* IRC transcripts */

= chat examples =

Examples of how chat transcripts are marked up currently, with the idea of moving towards a

== Authors ==
* [http://epeus.blogspot.com Kevin Marks]

== IRC transcripts ==

These are plantext logs with space separated fields, so are posted wrapped in <pre>

<pre>12:06 Tantek: what does the datetime stamp represent?
12:07 KevinMarks: in iRC, when it was said
12:07 Tantek: is it a point in time *before* they started speaking?
12:07 Tantek: or *after*?
12:07 Tantek: or somewhere in the *middle*?
12:07 KevinMarks: usually it is quantised to seconds
12:07 KevinMarks: and it is time the msg was received
12:07 Tantek: but the second they started typing or pressed return?
12:08 KevinMarks: prssed return i think</pre>

Or as plaintext + <br> (eg http://chocnvodka.blogware.com/blog/_archives/2005/8/25/1169654.html)

(22:20) gturneruk: oh, i just remembered. windows 95 is ten years old today<br>
(22:22) Suw: good god. i mean, i shouldn't be surprised, it being 2005 and all. but still, where did that time go?<br>
(22:22) gturneruk: lost clusters<br>
(22:23) Suw: i obviously need to defrag

xChat log format

<pre>
**** BEGIN LOGGING AT Wed May 14 04:36:29 2003

May 14 04:36:29 --> You are now talking on #test
May 14 04:36:29 --- Topic for #test is Test Topic
May 14 04:36:29 --- Topic for #test set by nick1 at Thu May 8 18:45:05
May 14 04:58:45 --- You are now known as nick1
May 14 05:03:44 --> nick1 (~nick1@2.1.3.narf-42905) has joined #test
May 14 05:05:48 <nick1> test message
May 14 05:10:24 * nick1 test action
May 14 05:11:19 <-- nick1 has quit (quit)

**** ENDING LOGGING AT Fri Jul 4 00:28:22 2003
</pre>

== iChat transcripts ==

iChat handles timestamps differently, inserting them between statement blocks, every 5 minutes.

<pre>12:25 AM
Reconnecting to tantekatwork…
Kevin Marks: So, iChat shows timestamps between entries
Tantek: yes
Tantek: what about Adium?
12:30 AM
Kevin Marks: my copy is 230 days old...</pre>

== bash.org ==
Bash.org collects funny irc transcripts and lets people vote on them:
It uses plaintext + <br />, wrapped in <p>
http://bash.org/?23396
<p class="qt"><Donut[AFK]> HEY EURAKARTE<br />
<Donut[AFK]> INSULT<br />
<Eurakarte> RETORT<br />
<Donut[AFK]> COUNTER-RETORT<br />
<Eurakarte> QUESTIONING OF SEXUAL PREFERENCE<br />
<Donut[AFK]> SUGGESTION TO SHUT THE FUCK UP<br />
<Eurakarte> NOTATION THAT YOU CREATE A VACUUM<br />
<Donut[AFK]> RIPOSTE<br />
<Donut[AFK]> ADDON RIPOSTE<br />
<Eurakarte> COUNTER-RIPOSTE<br />
<Donut[AFK]> COUNTER-COUNTER RIPOSTE<br />
<Eurakarte> NONSENSICAL STATEMENT INVOLVING PLANKTON<br />
<Miles_Prower> RESPONSE TO RANDOM STATEMENT AND THREAT TO BAN OPPOSING SIDES<br />
<Eurakarte> WORDS OF PRAISE FOR FISHFOOD<br />
<Miles_Prower> ACKNOWLEDGEMENT AND ACCEPTENCE OF TERMS</p>

== Log Library ==
[http://www.loglibrary.com Log Library] displays a tabular format with divs
<pre>
<div class="row" name="GusVanNos">
<div class="timestamp">18:36:28</div>
<div class="nick"><GusVanNos></div>
<div class="message">.+. is a lazy way of saying .{2,}</div>
</div>

<div class="row" name="jawong">
<div class="timestamp">18:36:48</div>
<div class="nick"><jawong></div>
<div class="message">your model is waaaay better, xal.</div>
</div>
</pre>

datetime-design-pattern

2005-10-15T06:00:18Z

MikeTaylor:

'''This page is a draft.'''

This is a page for exploring a datetime design pattern.

The pattern which is now used in [[hcalendar|hCalendar]] and [[hreview|hReview]] is something like this:

<pre><abbr class="foo" title="YYYYMMDDTHH:MM:SS+ZZZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time and "Date Time" is a human-friendly representation of the same date/time.

This pattern is likely to be highly resuable.

--[[RyanKing]]

Can this not be viewed as a microformat in itself?

--[[DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

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

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

hcalendar-examples

2005-10-11T19:53:16Z

MikeTaylor: /* Example 3 */

= hCalendar examples =

Example [[hcalendar|hCalendars]].

== Authors ==
* [http://diveintomark.org/ Mark Pilgrim]
* [http://theryanking.com/ Ryan King]
* [http://tantek.com/log/ Tantek Çelik]

== RFC 2445 examples in hCalendar ==
These are 1:1 hCalendar examples for each example in [http://www.ietf.org/rfc/rfc2445.txt RFC 2445].

Errata applied from [http://www.rfc-editor.org/cgi-bin/errata.pl#rfc2445 here].

=== 4.6.1 Event Component ===
The following is an example of the "VEVENT" calendar component used to represent a meeting that will also be opaque to searches for busy time:

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

This iCalendar event as an hCalendar:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Annual Employee Review</h1>
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div>
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div>
<div>This meeting is <span class="class">PRIVATE</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<h1 class="summary">Annual Employee Review</h1>
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div>
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div>
<div>This meeting is <span class="class">PRIVATE</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>

==== Example 2 ====
The following is an example of the "VEVENT" calendar component used to represent a reminder that will not be opaque, but rather transparent, to searches for busy time:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123402@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970401T163000Z
DTEND:19970402T010000Z
SUMMARY:Laurel is in sensitivity awareness class.
CLASS:PUBLIC
CATEGORIES:BUSINESS,HUMAN RESOURCES
TRANSP:TRANSPARENT
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<div>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123402@host.com</div>
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div>
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<div>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123402@host.com</div>
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div>
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>

==== Example 3 ====

The following is an example of the "VEVENT" calendar component used to represent an anniversary that will occur annually. Since it takes up no time, it will not appear as opaque in a search for busy time; no matter what the value of the "TRANSP" property indicates:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123403@host.com
DTSTAMP:19970901T1300Z
DTSTART:19971102
SUMMARY:Our Blissful Anniversary
CLASS:CONFIDENTIAL
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
RRULE:FREQ=YEARLY
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123403@host.com</div>
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div>
<div>This event is <span class="class">confidential</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<div class="rrule">Repeat <span class="freq">yearly</span></div>
</div>
</nowiki></pre>

ISSUES:
* We have a larger discusion about RRULE that needs to be resolved, hopefully these examples will help that. --RyanKing

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123403@host.com</div>
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div>
<div>This event is <span class="class">confidential</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<div class="rrule">Repeat <span class="freq">yearly</span></div>
</div>

=== 5. iCalendar Object Examples ===

The following example specifies a three-day conference that begins at 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, 1996.

<pre><nowiki>
BEGIN:VEVENT
DTSTAMP:19960704T120000Z
UID:uid1@host.com
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19960918T143000Z
DTEND:19960920T220000Z
STATUS:CONFIRMED
CATEGORIES:CONFERENCE
SUMMARY:Networld+Interop Conference
DESCRIPTION:Networld+Interop Conference and Exhibit\nAtlanta World Congress Center\nAtlant\, Georgia
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</div>
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div>
<div class="uid">uid1@host.com</div>
<div>Organized by: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div>
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div>
<div>Status: <span class="status">CONFIRMED</span></div>
<div>Filed under:</div>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</div>
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div>
<div class="uid">uid1@host.com</div>
<div>Organized by: [mailto:jsmith@host.com jsmith@host.com]</div>
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div>
<div>Status: <span class="status">CONFIRMED</span></div>
<div>Filed under:</div>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>

==== Example 2 ====
The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more calendar users in a group. A time zone specification for Eastern United States has been specified.

<pre><nowiki>
BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:US-Eastern
BEGIN:STANDARD
DTSTART:19981025T020000
RDATE:19981025T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19990404T020000
RDATE:19990404T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:19980309T231000Z
UID:guid-1.host1.com
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-A@host.com
DESCRIPTION:Project XYZ Review Meeting
CATEGORIES:MEETING
CLASS:PUBLIC
CREATED:19980309T130000Z
SUMMARY:XYZ Project Review
DTSTART;TZID=US-Eastern:19980312T083000
DTEND;TZID=US-Eastern:19980312T093000
LOCATION:1CP Conference Room 4350
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 3 ====
<pre><nowiki>
BEGIN:VCALENDAR
METHOD:xyz
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
DTSTAMP:19970324T1200Z
SEQUENCE:0
UID:uid3@host1.com
ORGANIZER:MAILTO:jdoe@host1.com
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
DTSTART:19970324T123000Z
DTEND:19970324T210000Z
CATEGORIES:MEETING,PROJECT
CLASS:PUBLIC
SUMMARY:Calendaring Interoperability Planning Meeting
DESCRIPTION:Discuss how we can test c&s interoperability\nusing iCalendar and other IETF standards.
LOCATION:LDB Lobby
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/conf/bkgrnd.ps
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<div>Method: <span class="method">xyz</span></div>
<div>Version: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vevent">
<div>DTSTAMP: span class="dtstamp">19970324T1200Z</span></div>
<div>SEQUENCE: <span class="sequence">0</span></div>
<div>UID: <span class="uid">uid3@host1.com</span></div>
<div>ORGANIZER: <a class="organizer" href="mailto:jdoe@host1.com">jdoe@host1.com</a></div>
<div>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jsmith@host1.com">jsmith@host1.com</a> RSVPed? <span class="rsvp">TRUE></span></span></div>
<div>START TIME: <abbr class="dtstart" tite="19970324T123000Z"></abbr></div>
<div>END TIME: <abbr class="dtend title="19970324T210000Z"></abbr></div>
<ul class="categories">
<li>MEETING</li>
<li>PROJECT</li>
</ul>
<div>CLASS: <span class="class">PUBLIC</span></div>
<div class="summary">Calendaring Interoperability Planning Meeting</div>
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div>
<div class="location">LDB Lobby</div>
<div>Attachment: <a class="attach" type="application/postscript" href="ftp://xyzCorp.com/pub/conf/bkgrnd.ps">ftp://xyzCorp.com/pub/conf/bkgrnd.ps</a></div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vcalendar">
<div>Method: <span class="method">xyz</span></div>
<div>Version: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vevent">
<div>DTSTAMP: span class="dtstamp">19970324T1200Z</span></div>
<div>SEQUENCE: <span class="sequence">0</span></div>
<div>UID: <span class="uid">uid3@host1.com</span></div>
<div>ORGANIZER: [mailto:jdoe@host1.com]</div>
<div>ATTENDEE: [mailto:jsmith@host1.com] RSVPed? <span class="rsvp">TRUE></span></div>
<div>START TIME: <abbr class="dtstart" tite="19970324T123000Z"></abbr></div>
<div>END TIME: <abbr class="dtend title="19970324T210000Z"></abbr></div>
<ul class="categories">
<li>MEETING</li>
<li>PROJECT</li>
</ul>
<div>CLASS: <span class="class">PUBLIC</span></div>
<div class="summary">Calendaring Interoperability Planning Meeting</div>
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div>
<div class="location">LDB Lobby</div>
<div>Attachment: [ftp://xyzCorp.com/pub/conf/bkgrnd.ps ftp://xyzCorp.com/pub/conf/bkgrnd.ps]</div>
</div>
</div>

==== Example 4 ====

The following is an example of a to-do due on April 15, 1998. An audio alarm has been specified to remind the calendar user at noon, the day before the to-do is expected to be completed and repeat hourly, four additional times. The to-do definition has been modified twice since it was initially created.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<div>VERSION: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vtodo">
<div>DTSTAMP: <span class="dtstamp">19980130T134500Z</span></div>
<div>SEQUENCE: <span class="sequence">2</span></div>
<div>UID: <span class="uid">uid4@host1.com</span></div>
<div>ORGANIZER: <a class="organizer" href="mailto:unclesam@us.gov">unclesam@us.gov</a></div>
<div>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jqpublic@host.com">jqpublic@host.com</a>, <span class="partstat">ACCEPTED</span></span></div>
<div>DUE: <abbr class="due" title="19980415T235959">April 15, 1998</abbr></div>
<div>STATUS: <span class="status">NEEDS-ACTION</span></div>
<div class="summary">Submit Income Taxes</div>
<div class="valarm">
<div>ACTION: <span class="action">AUDIO</span></div>
<div>TRIGGER: <span class="trigger">19980403T120000</span></div>
<div>ATTACHMENT: <a class="attach" type="audio/basic" href="http://host.com/pub/audio-files/ssbanner.aud">http://host.com/pub/audio-files/ssbanner.aud</a></div>
<div>REPEAT: <span class="repeat">4</span></div>
<div>DURATION: <span class="duration">PT1H</span></div>
</div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vcalendar">
<div>VERSION: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vtodo">
<div>DTSTAMP: <span class="dtstamp">19980130T134500Z</span></div>
<div>SEQUENCE: <span class="sequence">2</span></div>
<div>UID: <span class="uid">uid4@host1.com</span></div>
<div>ORGANIZER: [mailto:unclesam@us.gov]</div>
<div>ATTENDEE: [jqpublic@host.com], <span class="partstat">ACCEPTED</span></div>
<div>DUE: <abbr class="due" title="19980415T235959">April 15, 1998</abbr></div>
<div>STATUS: <span class="status">NEEDS-ACTION</span></div>
<div class="summary">Submit Income Taxes</div>
<div class="valarm">
<div>ACTION: <span class="action">AUDIO</span></div>
<div>TRIGGER: <span class="trigger">19980403T120000</span></div>
<div>ATTACHMENT: [http://host.com/pub/audio-files/ssbanner.aud http://host.com/pub/audio-files/ssbanner.aud]</div>
<div>REPEAT: <span class="repeat">4</span></div>
<div>DURATION: <span class="duration">PT1H</span></div>
</div>
</div>
</div>

==== Example 5: journal entry ====
The following is an example of a journal entry.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\nAgenda\n
1. Review of project version 1.0 requirements.\n
2. Definition of project processes.\n
3. Review of project schedule.\nParticipants: John Smith, Jane Doe, Jim Dandy\n
-It was decided that the requirements need to be signed off by product marketing.\n
-Project processes were accepted.\n
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.\n
-New schedule will be distributed by Friday.\n
-Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
</nowiki></pre>

(*note*: line-breaks have been added into the description, in reality it should be one line)

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
@TODO: VERSION:2.0
@TODO: PRODID:-//ABC Corporation//NONSGML My Product//EN
<div class="vjournal">
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div>
<div class="uid">uid5@host1.com</div>
<div>Organizer: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div>
<div>Status: <span class="status">DRAFT</span></div>
<div>This journal is<span class="class">PUBLIC</span></div>
<div>Filed under:</div>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<div class="description">DESCRIPTION:Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vjournal">
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div>
<div class="uid">uid5@host1.com</div>
<div>Organizer: [mailto:jsmith@host.com jsmith@host.com]</div>
<div>Status: <span class="status">DRAFT</span></div>
<div>This journal is<span class="class">PUBLIC</span></div>
<div>Filed under:</div>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<p class="description">Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</p>
</div>

==== Example 6. Free/Busy time ====

The following is an example of published busy time information. The iCalendar object might be placed in the network resource www.host.com/calendar/busytime/jsmith.ifb.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

== Other ==

* See [[hcalendar-brainstorming]] for more examples (which may eventually be moved here) and analysis.

hcalendar-examples

2005-10-11T19:48:54Z

MikeTaylor: /* Example 4 */

= hCalendar examples =

Example [[hcalendar|hCalendars]].

== Authors ==
* [http://diveintomark.org/ Mark Pilgrim]
* [http://theryanking.com/ Ryan King]
* [http://tantek.com/log/ Tantek Çelik]

== RFC 2445 examples in hCalendar ==
These are 1:1 hCalendar examples for each example in [http://www.ietf.org/rfc/rfc2445.txt RFC 2445].

Errata applied from [http://www.rfc-editor.org/cgi-bin/errata.pl#rfc2445 here].

=== 4.6.1 Event Component ===
The following is an example of the "VEVENT" calendar component used to represent a meeting that will also be opaque to searches for busy time:

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

This iCalendar event as an hCalendar:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Annual Employee Review</h1>
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div>
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div>
<div>This meeting is <span class="class">PRIVATE</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<h1 class="summary">Annual Employee Review</h1>
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div>
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div>
<div>This meeting is <span class="class">PRIVATE</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>

==== Example 2 ====
The following is an example of the "VEVENT" calendar component used to represent a reminder that will not be opaque, but rather transparent, to searches for busy time:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123402@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970401T163000Z
DTEND:19970402T010000Z
SUMMARY:Laurel is in sensitivity awareness class.
CLASS:PUBLIC
CATEGORIES:BUSINESS,HUMAN RESOURCES
TRANSP:TRANSPARENT
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<div>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123402@host.com</div>
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div>
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<div>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123402@host.com</div>
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div>
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>

==== Example 3 ====

The following is an example of the "VEVENT" calendar component used to represent an anniversary that will occur annually. Since it takes up no time, it will not appear as opaque in a search for busy time; no matter what the value of the "TRANSP" property indicates:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123403@host.com
DTSTAMP:19970901T1300Z
DTSTART:19971102
SUMMARY:Our Blissful Anniversary
CLASS:CONFIDENTIAL
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
RRULE:FREQ=YEARLY
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123403@host.com</div>
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div>
<div>This event is <span class="class">confidential</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<div class="rrule">Repeat <span class="freq">yearly</span></div>
</div>
</nowiki></pre>

ISSUES:
* We have a larger discusion about RRULE that needs to be resolved, hopefully these examples will help that. --RyanKing

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123403@host.com</div>
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div>
<div>This event is <span class="class">confidential</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<div class="rrule">Repeat <span class="freq">yearly</span></div>
</div>

=== 5. iCalendar Object Examples ===

The following example specifies a three-day conference that begins at 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, 1996.

<pre><nowiki>
BEGIN:VEVENT
DTSTAMP:19960704T120000Z
UID:uid1@host.com
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19960918T143000Z
DTEND:19960920T220000Z
STATUS:CONFIRMED
CATEGORIES:CONFERENCE
SUMMARY:Networld+Interop Conference
DESCRIPTION:Networld+Interop Conference and Exhibit\nAtlanta World Congress Center\nAtlant\, Georgia
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</div>
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div>
<div class="uid">uid1@host.com</div>
<div>Organized by: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div>
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div>
<div>Status: <span class="status">CONFIRMED</span></div>
<div>Filed under:</div>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</div>
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div>
<div class="uid">uid1@host.com</div>
<div>Organized by: [mailto:jsmith@host.com jsmith@host.com]</div>
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div>
<div>Status: <span class="status">CONFIRMED</span></div>
<div>Filed under:</div>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>

==== Example 2 ====
The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more calendar users in a group. A time zone specification for Eastern United States has been specified.

<pre><nowiki>
BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:US-Eastern
BEGIN:STANDARD
DTSTART:19981025T020000
RDATE:19981025T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19990404T020000
RDATE:19990404T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:19980309T231000Z
UID:guid-1.host1.com
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-A@host.com
DESCRIPTION:Project XYZ Review Meeting
CATEGORIES:MEETING
CLASS:PUBLIC
CREATED:19980309T130000Z
SUMMARY:XYZ Project Review
DTSTART;TZID=US-Eastern:19980312T083000
DTEND;TZID=US-Eastern:19980312T093000
LOCATION:1CP Conference Room 4350
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 3 ====
<pre><nowiki>
BEGIN:VCALENDAR
METHOD:xyz
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
DTSTAMP:19970324T1200Z
SEQUENCE:0
UID:uid3@host1.com
ORGANIZER:MAILTO:jdoe@host1.com
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
DTSTART:19970324T123000Z
DTEND:19970324T210000Z
CATEGORIES:MEETING,PROJECT
CLASS:PUBLIC
SUMMARY:Calendaring Interoperability Planning Meeting
DESCRIPTION:Discuss how we can test c&s interoperability\nusing iCalendar and other IETF standards.
LOCATION:LDB Lobby
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/conf/bkgrnd.ps
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<div>Method: <span class="method">xyz</span></div>
<div>Version: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vevent">
<div>DTSTAMP: span class="dtstamp">19970324T1200Z</span></div>
<div>SEQUENCE: <span class="sequence">0</span></div>
<div>UID: <span class="uid">uid3@host1.com</span></div>
<div>ORGANIZER: <a class="organizer" href="mailto:jdoe@host1.com">jdoe@host1.com</a></div>
<div>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jsmith@host1.com">jsmith@host1.com</a> RSVPed? <span class="rsvp">TRUE></span></div>
<div>START TIME: <abbr class="dtstart" tite="19970324T123000Z"></abbr></div>
<div>END TIME: <abbr class="dtend title="19970324T210000Z"></abbr></div>
<ul class="categories">
<li>MEETING</li>
<li>PROJECT</li>
</ul>
<div>CLASS: <span class="class">PUBLIC</span></div>
<div class="summary">Calendaring Interoperability Planning Meeting</div>
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div>
<div class="location">LDB Lobby</div>
<div>Attachment: <a class="attach" type="application/postscript" href="ftp://xyzCorp.com/pub/conf/bkgrnd.ps">ftp://xyzCorp.com/pub/conf/bkgrnd.ps</a></div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 4 ====

The following is an example of a to-do due on April 15, 1998. An audio alarm has been specified to remind the calendar user at noon, the day before the to-do is expected to be completed and repeat hourly, four additional times. The to-do definition has been modified twice since it was initially created.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<div>VERSION: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vtodo">
<div>DTSTAMP: <span class="dtstamp">19980130T134500Z</span></div>
<div>SEQUENCE: <span class="sequence">2</span></div>
<div>UID: <span class="uid">uid4@host1.com</span></div>
<div>ORGANIZER: <a class="organizer" href="mailto:unclesam@us.gov">unclesam@us.gov</a></div>
<div>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jqpublic@host.com">jqpublic@host.com</a>, <span class="partstat">ACCEPTED</span></span></div>
<div>DUE: <abbr class="due" title="19980415T235959">April 15, 1998</abbr></div>
<div>STATUS: <span class="status">NEEDS-ACTION</span></div>
<div class="summary">Submit Income Taxes</div>
<div class="valarm">
<div>ACTION: <span class="action">AUDIO</span></div>
<div>TRIGGER: <span class="trigger">19980403T120000</span></div>
<div>ATTACHMENT: <a class="attach" type="audio/basic" href="http://host.com/pub/audio-files/ssbanner.aud">http://host.com/pub/audio-files/ssbanner.aud</a></div>
<div>REPEAT: <span class="repeat">4</span></div>
<div>DURATION: <span class="duration">PT1H</span></div>
</div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vcalendar">
<div>VERSION: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vtodo">
<div>DTSTAMP: <span class="dtstamp">19980130T134500Z</span></div>
<div>SEQUENCE: <span class="sequence">2</span></div>
<div>UID: <span class="uid">uid4@host1.com</span></div>
<div>ORGANIZER: [mailto:unclesam@us.gov]</div>
<div>ATTENDEE: [jqpublic@host.com], <span class="partstat">ACCEPTED</span></div>
<div>DUE: <abbr class="due" title="19980415T235959">April 15, 1998</abbr></div>
<div>STATUS: <span class="status">NEEDS-ACTION</span></div>
<div class="summary">Submit Income Taxes</div>
<div class="valarm">
<div>ACTION: <span class="action">AUDIO</span></div>
<div>TRIGGER: <span class="trigger">19980403T120000</span></div>
<div>ATTACHMENT: [http://host.com/pub/audio-files/ssbanner.aud http://host.com/pub/audio-files/ssbanner.aud]</div>
<div>REPEAT: <span class="repeat">4</span></div>
<div>DURATION: <span class="duration">PT1H</span></div>
</div>
</div>
</div>

==== Example 5: journal entry ====
The following is an example of a journal entry.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\nAgenda\n
1. Review of project version 1.0 requirements.\n
2. Definition of project processes.\n
3. Review of project schedule.\nParticipants: John Smith, Jane Doe, Jim Dandy\n
-It was decided that the requirements need to be signed off by product marketing.\n
-Project processes were accepted.\n
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.\n
-New schedule will be distributed by Friday.\n
-Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
</nowiki></pre>

(*note*: line-breaks have been added into the description, in reality it should be one line)

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
@TODO: VERSION:2.0
@TODO: PRODID:-//ABC Corporation//NONSGML My Product//EN
<div class="vjournal">
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div>
<div class="uid">uid5@host1.com</div>
<div>Organizer: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div>
<div>Status: <span class="status">DRAFT</span></div>
<div>This journal is<span class="class">PUBLIC</span></div>
<div>Filed under:</div>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<div class="description">DESCRIPTION:Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vjournal">
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div>
<div class="uid">uid5@host1.com</div>
<div>Organizer: [mailto:jsmith@host.com jsmith@host.com]</div>
<div>Status: <span class="status">DRAFT</span></div>
<div>This journal is<span class="class">PUBLIC</span></div>
<div>Filed under:</div>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<p class="description">Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</p>
</div>

==== Example 6. Free/Busy time ====

The following is an example of published busy time information. The iCalendar object might be placed in the network resource www.host.com/calendar/busytime/jsmith.ifb.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

== Other ==

* See [[hcalendar-brainstorming]] for more examples (which may eventually be moved here) and analysis.

hcalendar-examples

2005-10-11T19:38:40Z

MikeTaylor: /* Example 5: journal entry */

= hCalendar examples =

Example [[hcalendar|hCalendars]].

== Authors ==
* [http://diveintomark.org/ Mark Pilgrim]
* [http://theryanking.com/ Ryan King]
* [http://tantek.com/log/ Tantek Çelik]

== RFC 2445 examples in hCalendar ==
These are 1:1 hCalendar examples for each example in [http://www.ietf.org/rfc/rfc2445.txt RFC 2445].

Errata applied from [http://www.rfc-editor.org/cgi-bin/errata.pl#rfc2445 here].

=== 4.6.1 Event Component ===
The following is an example of the "VEVENT" calendar component used to represent a meeting that will also be opaque to searches for busy time:

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

This iCalendar event as an hCalendar:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Annual Employee Review</h1>
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div>
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div>
<div>This meeting is <span class="class">PRIVATE</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<h1 class="summary">Annual Employee Review</h1>
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div>
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div>
<div>This meeting is <span class="class">PRIVATE</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>

==== Example 2 ====
The following is an example of the "VEVENT" calendar component used to represent a reminder that will not be opaque, but rather transparent, to searches for busy time:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123402@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970401T163000Z
DTEND:19970402T010000Z
SUMMARY:Laurel is in sensitivity awareness class.
CLASS:PUBLIC
CATEGORIES:BUSINESS,HUMAN RESOURCES
TRANSP:TRANSPARENT
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<div>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123402@host.com</div>
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div>
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<div>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123402@host.com</div>
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div>
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div>
<div>Filed under:</div>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>

==== Example 3 ====

The following is an example of the "VEVENT" calendar component used to represent an anniversary that will occur annually. Since it takes up no time, it will not appear as opaque in a search for busy time; no matter what the value of the "TRANSP" property indicates:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123403@host.com
DTSTAMP:19970901T1300Z
DTSTART:19971102
SUMMARY:Our Blissful Anniversary
CLASS:CONFIDENTIAL
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
RRULE:FREQ=YEARLY
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123403@host.com</div>
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div>
<div>This event is <span class="class">confidential</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<div class="rrule">Repeat <span class="freq">yearly</span></div>
</div>
</nowiki></pre>

ISSUES:
* We have a larger discusion about RRULE that needs to be resolved, hopefully these examples will help that. --RyanKing

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div>
<div class="uid">19970901T130000Z-123403@host.com</div>
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div>
<div>This event is <span class="class">confidential</span>.</div>
<div>Filed under:</div>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<div class="rrule">Repeat <span class="freq">yearly</span></div>
</div>

=== 5. iCalendar Object Examples ===

The following example specifies a three-day conference that begins at 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, 1996.

<pre><nowiki>
BEGIN:VEVENT
DTSTAMP:19960704T120000Z
UID:uid1@host.com
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19960918T143000Z
DTEND:19960920T220000Z
STATUS:CONFIRMED
CATEGORIES:CONFERENCE
SUMMARY:Networld+Interop Conference
DESCRIPTION:Networld+Interop Conference and Exhibit\nAtlanta World Congress Center\nAtlant\, Georgia
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</div>
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div>
<div class="uid">uid1@host.com</div>
<div>Organized by: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div>
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div>
<div>Status: <span class="status">CONFIRMED</span></div>
<div>Filed under:</div>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</div>
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div>
<div class="uid">uid1@host.com</div>
<div>Organized by: [mailto:jsmith@host.com jsmith@host.com]</div>
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div>
<div>Status: <span class="status">CONFIRMED</span></div>
<div>Filed under:</div>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>

==== Example 2 ====
The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more calendar users in a group. A time zone specification for Eastern United States has been specified.

<pre><nowiki>
BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:US-Eastern
BEGIN:STANDARD
DTSTART:19981025T020000
RDATE:19981025T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19990404T020000
RDATE:19990404T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:19980309T231000Z
UID:guid-1.host1.com
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-A@host.com
DESCRIPTION:Project XYZ Review Meeting
CATEGORIES:MEETING
CLASS:PUBLIC
CREATED:19980309T130000Z
SUMMARY:XYZ Project Review
DTSTART;TZID=US-Eastern:19980312T083000
DTEND;TZID=US-Eastern:19980312T093000
LOCATION:1CP Conference Room 4350
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 3 ====
<pre><nowiki>
BEGIN:VCALENDAR
METHOD:xyz
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
DTSTAMP:19970324T1200Z
SEQUENCE:0
UID:uid3@host1.com
ORGANIZER:MAILTO:jdoe@host1.com
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
DTSTART:19970324T123000Z
DTEND:19970324T210000Z
CATEGORIES:MEETING,PROJECT
CLASS:PUBLIC
SUMMARY:Calendaring Interoperability Planning Meeting
DESCRIPTION:Discuss how we can test c&s interoperability\nusing iCalendar and other IETF standards.
LOCATION:LDB Lobby
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/conf/bkgrnd.ps
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<div>Method: <span class="method">xyz</span></div>
<div>Version: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vevent">
<div>DTSTAMP: span class="dtstamp">19970324T1200Z</span></div>
<div>SEQUENCE: <span class="sequence">0</span></div>
<div>UID: <span class="uid">uid3@host1.com</span></div>
<div>ORGANIZER: <a class="organizer" href="mailto:jdoe@host1.com">jdoe@host1.com</a></div>
<div>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jsmith@host1.com">jsmith@host1.com</a> RSVPed? <span class="rsvp">TRUE></span></div>
<div>START TIME: <abbr class="dtstart" tite="19970324T123000Z"></abbr></div>
<div>END TIME: <abbr class="dtend title="19970324T210000Z"></abbr></div>
<ul class="categories">
<li>MEETING</li>
<li>PROJECT</li>
</ul>
<div>CLASS: <span class="class">PUBLIC</span></div>
<div class="summary">Calendaring Interoperability Planning Meeting</div>
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div>
<div class="location">LDB Lobby</div>
<div>Attachment: <a class="attach" type="application/postscript" href="ftp://xyzCorp.com/pub/conf/bkgrnd.ps">ftp://xyzCorp.com/pub/conf/bkgrnd.ps</a></div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 4 ====

The following is an example of a to-do due on April 15, 1998. An audio alarm has been specified to remind the calendar user at noon, the day before the to-do is expected to be completed and repeat hourly, four additional times. The to-do definition has been modified twice since it was initially created.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<div>VERSION: <span class="version">2.0</span></div>
<div>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></div>
<div class="vtodo">
<div>DTSTAMP: <span class="dtstamp">19980130T134500Z</span></div>
<div>SEQUENCE: <span class="sequence">2</span></div>
<div>UID: <span class="uid">uid4@host1.com</span></div>
<div>ORGANIZER: <a class="organizer" href="mailto:unclesam@us.gov">unclesam@us.gov</a></div>
<div>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jqpublic@host.com">jqpublic@host.com</a>, <span class="partstat">ACCEPTED</span></span></div>
<div>DUE: <abbr class="due" title="19980415T235959">April 15, 1998</abbr></div>
<div>STATUS: <span class="status">NEEDS-ACTION</span></div>
<div class="summary">Submit Income Taxes</div>
<div class="valarm">
<div>ACTION: <span class="action">AUDIO</span></div>
<div>TRIGGER: <span class="trigger">19980403T120000</span></div>
<div>ATTACHMENT: <a class="attach" type="audio/basic" href="http://host.com/pub/audio-files/ssbanner.aud">http://host.com/pub/audio-files/ssbanner.aud</a></div>
<div>REPEAT: <span class="repeat">4</span></div>
<div>DURATION: <span class="duration">PT1H</span></div>
</div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 5: journal entry ====
The following is an example of a journal entry.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\nAgenda\n
1. Review of project version 1.0 requirements.\n
2. Definition of project processes.\n
3. Review of project schedule.\nParticipants: John Smith, Jane Doe, Jim Dandy\n
-It was decided that the requirements need to be signed off by product marketing.\n
-Project processes were accepted.\n
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.\n
-New schedule will be distributed by Friday.\n
-Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
</nowiki></pre>

(*note*: line-breaks have been added into the description, in reality it should be one line)

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
@TODO: VERSION:2.0
@TODO: PRODID:-//ABC Corporation//NONSGML My Product//EN
<div class="vjournal">
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div>
<div class="uid">uid5@host1.com</div>
<div>Organizer: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div>
<div>Status: <span class="status">DRAFT</span></div>
<div>This journal is<span class="class">PUBLIC</span></div>
<div>Filed under:</div>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<div class="description">DESCRIPTION:Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vjournal">
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div>
<div class="uid">uid5@host1.com</div>
<div>Organizer: [mailto:jsmith@host.com jsmith@host.com]</div>
<div>Status: <span class="status">DRAFT</span></div>
<div>This journal is<span class="class">PUBLIC</span></div>
<div>Filed under:</div>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<p class="description">Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</p>
</div>

==== Example 6. Free/Busy time ====

The following is an example of published busy time information. The iCalendar object might be placed in the network resource www.host.com/calendar/busytime/jsmith.ifb.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

== Other ==

* See [[hcalendar-brainstorming]] for more examples (which may eventually be moved here) and analysis.

hcalendar-examples

2005-10-11T17:33:18Z

MikeTaylor: /* 5. iCalendar Object Examples */

= hCalendar examples =

Example [[hcalendar|hCalendars]].

== Authors ==
* [http://diveintomark.org/ Mark Pilgrim]
* [http://theryanking.com/ Ryan King]
* [http://tantek.com/log/ Tantek Çelik]

== RFC 2445 examples in hCalendar ==

These are 1:1 hCalendar examples for each example in [http://www.ietf.org/rfc/rfc2445.txt RFC 2445].

Errata applied from [http://www.rfc-editor.org/cgi-bin/errata.pl#rfc2445 here].

=== 4.6.1 Event Component ===

The following is an example of the "VEVENT" calendar component used to represent a meeting that will also be opaque to searches for busy time:

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

This iCalendar event as an hCalendar:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Annual Employee Review</h1>
<p>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></p>
<p>UID: <span class="uid">19970901T130000Z-123401@host.com</span></p>
<p>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></p>
<p>This meeting is <span class="class">PRIVATE</span>.</p>
<p>Filed under:</p>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<h1 class="summary">Annual Employee Review</h1>
<p>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></p>
<p>UID: <span class="uid">19970901T130000Z-123401@host.com</span></p>
<p>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> - <abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></p>
<p>This meeting is <span class="class">PRIVATE</span>.</p>
<p>Filed under:</p>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>

==== Example 2 ====
The following is an example of the "VEVENT" calendar component used to represent a reminder that will not be opaque, but rather transparent, to searches for busy time:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123402@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970401T163000Z
DTEND:19970402T010000Z
SUMMARY:Laurel is in sensitivity awareness class.
CLASS:PUBLIC
CATEGORIES:BUSINESS,HUMAN RESOURCES
TRANSP:TRANSPARENT
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<p>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></p>
<p class="uid">19970901T130000Z-123402@host.com</p>
<p>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></p>
<p>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</p>
<p>Filed under:</p>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Laurel is in sensitivity awareness class.</h1>
<p>Posted on: <abbr class="dtstamp" title=19970901T1300Z">September 1, 1997</abbr></p>
<p class="uid">19970901T130000Z-123402@host.com</p>
<p>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></p>
<p>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</p>
<p>Filed under:</p>
<ul>
<li class="category">BUSINESS</li>
<li class="category">HUMAN RESOURCES</li>
</ul>
</div>

==== Example 3 ====

The following is an example of the "VEVENT" calendar component used to represent an anniversary that will occur annually. Since it takes up no time, it will not appear as opaque in a search for busy time; no matter what the value of the "TRANSP" property indicates:

<pre><nowiki>
BEGIN:VEVENT
UID:19970901T130000Z-123403@host.com
DTSTAMP:19970901T1300Z
DTSTART:19971102
SUMMARY:Our Blissful Anniversary
CLASS:CONFIDENTIAL
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
RRULE:FREQ=YEARLY
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<p>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></p>
<p class="uid">19970901T130000Z-123403@host.com</p>
<p>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></p>
<p>This event is <span class="class">confidential</span>.</p>
<p>Filed under:</p>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<p class="rrule">Repeat <span class="freq">yearly</span></p>
</div>
</nowiki></pre>

ISSUES:
* We have a larger discusion about RRULE that needs to be resolved, hopefully these examples will help that. --RyanKing

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Our Blissful Anniversary</h1>
<p>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></p>
<p class="uid">19970901T130000Z-123403@host.com</p>
<p>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></p>
<p>This event is <span class="class">confidential</span>.</p>
<p>Filed under:</p>
<ul>
<li class="category">ANNIVERSARY</li>
<li class="category">PERSONAL</li>
<li class="category">SPECIAL OCCASSION</li>
</ul>
<p class="rrule">Repeat <span class="freq">yearly</span></p>
</div>

=== 5. iCalendar Object Examples ===

The following example specifies a three-day conference that begins at 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, 1996.

<pre><nowiki>
BEGIN:VEVENT
DTSTAMP:19960704T120000Z
UID:uid1@host.com
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19960918T143000Z
DTEND:19960920T220000Z
STATUS:CONFIRMED
CATEGORIES:CONFERENCE
SUMMARY:Networld+Interop Conference
DESCRIPTION:Networld+Interop Conference and Exhibit\nAtlanta World Congress Center\nAtlant\, Georgia
END:VEVENT
</nowiki></pre>

This iCalendar event as an hCalendar fragment:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<p class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</p>
<p>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></p>
<p class="uid">uid1@host.com</p>
<p>Organized by: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></p>
<p>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></p>
<p>Status: <span class="status">CONFIRMED</span></p>
<p>Filed under:</p>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vevent">
<h1 class="summary">Networld+Interop Conference</h1>
<p class="description">Networld+Interop Conference and Exhibit Atlanta World Congress
Center Atlanta, Georgia</p>
<p>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></p>
<p class="uid">uid1@host.com</p>
<p>Organized by: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></p>
<p>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></p>
<p>Status: <span class="status">CONFIRMED</span></p>
<p>Filed under:</p>
<ul class="categories">
<li>CONFERENCE</li>
</ul>
</div>

==== Example 2 ====
The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more calendar users in a group. A time zone specification for Eastern United States has been specified.

<pre><nowiki>
BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:US-Eastern
BEGIN:STANDARD
DTSTART:19981025T020000
RDATE:19981025T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19990404T020000
RDATE:19990404T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:19980309T231000Z
UID:guid-1.host1.com
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-A@host.com
DESCRIPTION:Project XYZ Review Meeting
CATEGORIES:MEETING
CLASS:PUBLIC
CREATED:19980309T130000Z
SUMMARY:XYZ Project Review
DTSTART;TZID=US-Eastern:19980312T083000
DTEND;TZID=US-Eastern:19980312T093000
LOCATION:1CP Conference Room 4350
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 3 ====
<pre><nowiki>
BEGIN:VCALENDAR
METHOD:xyz
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
DTSTAMP:19970324T1200Z
SEQUENCE:0
UID:uid3@host1.com
ORGANIZER:MAILTO:jdoe@host1.com
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
DTSTART:19970324T123000Z
DTEND:19970324T210000Z
CATEGORIES:MEETING,PROJECT
CLASS:PUBLIC
SUMMARY:Calendaring Interoperability Planning Meeting
DESCRIPTION:Discuss how we can test c&s interoperability\nusing iCalendar and other IETF standards.
LOCATION:LDB Lobby
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/conf/bkgrnd.ps
END:VEVENT
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<p>Method: <span class="method">xyz</span></p>
<p>Version: <span class="version">2.0</span></p>
<p>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></p>
<div class="vevent">
<p>DTSTAMP: span class="dtstamp">19970324T1200Z</span></p>
<p>SEQUENCE: <span class="sequence">0</span></p>
<p>UID: <span class="uid">uid3@host1.com</span></p>
<p>ORGANIZER: <a class="organizer" href="mailto:jdoe@host1.com">jdoe@host1.com</a></p>
<p>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jsmith@host1.com">jsmith@host1.com</a> RSVPed? <span class="rsvp">TRUE></span></p>
<p>START TIME: <abbr class="dtstart" tite="19970324T123000Z"></abbr></p>
<p>END TIME: <abbr class="dtend title="19970324T210000Z"></abbr></p>
<ul class="categories">
<li>MEETING</li>
<li>PROJECT</li>
</ul>
<p>CLASS: <span class="class">PUBLIC</span></p>
<p class="summary">Calendaring Interoperability Planning Meeting</p>
<p class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</p>
<p class="location">LDB Lobby</p>
<p>Attachment: <a class="attach" type="application/postscript" href="ftp://xyzCorp.com/pub/conf/bkgrnd.ps">ftp://xyzCorp.com/pub/conf/bkgrnd.ps</a></p>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 4 ====

The following is an example of a to-do due on April 15, 1998. An audio alarm has been specified to remind the calendar user at noon, the day before the to-do is expected to be completed and repeat hourly, four additional times. The to-do definition has been modified twice since it was initially created.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
<p>VERSION: <span class="version">2.0</span></p>
<p>PRODID: <span class="prodid">-//ABC Corporation//NONSGML My Product//EN</span></p>
<div class="vtodo">
<p>DTSTAMP: <span class="dtstamp">19980130T134500Z</span></p>
<p>SEQUENCE: <span class="sequence">2</span></p>
<p>UID: <span class="uid">uid4@host1.com</span></p>
<p>ORGANIZER: <a class="organizer" href="mailto:unclesam@us.gov">unclesam@us.gov</a></p>
<p>ATTENDEE: <span class="attendee"><a class="value" href="mailto:jqpublic@host.com">jqpublic@host.com</a>, <span class="partstat">ACCEPTED</span></span></p>
<p>DUE: <abbr class="due" title="19980415T235959">April 15, 1998</abbr></p>
<p>STATUS: <span class="status">NEEDS-ACTION</span></p>
<p class="summary">Submit Income Taxes</p>
<div class="valarm">
<p>ACTION: <span class="action">AUDIO</span></p>
<p>TRIGGER: <span class="trigger">19980403T120000</span></p>
<p>ATTACHMENT: <a class="attach" type="audio/basic" href="http://host.com/pub/audio-files/ssbanner.aud">http://host.com/pub/audio-files/ssbanner.aud</a></p>
<p>REPEAT: <span class="repeat">4</span></p>
<p>DURATION: <span class="duration">PT1H</span></p>
</div>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

==== Example 5: journal entry ====
The following is an example of a journal entry.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\nAgenda\n
1. Review of project version 1.0 requirements.\n
2. Definition of project processes.\n
3. Review of project schedule.\nParticipants: John Smith, Jane Doe, Jim Dandy\n
-It was decided that the requirements need to be signed off by product marketing.\n
-Project processes were accepted.\n-Project schedule needs to account for scheduled
holidays and employee vacation time. Check with HR for specific dates.\n
-New schedule will be distributed by Friday.\n
-Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
</nowiki></pre>

(*note*: line-breaks have been added into the description, in reality it should be one line)

This iCalendar as an hCalendar:

<pre><nowiki>
<div class="vcalendar">
@TODO: VERSION:2.0
@TODO: PRODID:-//ABC Corporation//NONSGML My Product//EN
<div class="vjournal">
<p>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></p>
<p class="uid">uid5@host1.com</p>
<p>Organizer: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></p>
<p>Status: <span class="status">DRAFT</span></p>
<p>This journal is<span class="class">PUBLIC</span></p>
<p>Filed under:</p>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<p class="description">DESCRIPTION:Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.\n-Project schedule needs to account for scheduled
holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</p>
</div>
</div>
</nowiki></pre>

This hCalendar could be displayed as:

<div class="vjournal">
<p>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></p>
<p class="uid">uid5@host1.com</p>
<p>Organizer: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></p>
<p>Status: <span class="status">DRAFT</span></p>
<p>This journal is<span class="class">PUBLIC</span></p>
<p>Filed under:</p>
<ul class="category">
<li>Project Report</li>
<li>XYZ</li>
<li>Weekly Meeting</li>
</ul>
<p class="description">DESCRIPTION:Project xyz Review Meeting Minutes<br />
Agenda<br />
1. Review of project version 1.0 requirements.<br />
2. Definition of project processes.<br />
3. Review of project schedule.<br />
Participants: John Smith, Jane Doe, Jim Dandy<br />
-It was decided that the requirements need to be signed off by product marketing.<br />
-Project processes were accepted.\n-Project schedule needs to account for scheduled
holidays and employee vacation time. Check with HR for specific dates.<br />
-New schedule will be distributed by Friday.<br />
-Next weeks meeting is cancelled. No meeting until 3/23.
</p>
</div>

==== Example 6. Free/Busy time ====

The following is an example of published busy time information. The iCalendar object might be placed in the network resource www.host.com/calendar/busytime/jsmith.ifb.

<pre><nowiki>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
END:VCALENDAR
</nowiki></pre>

This iCalendar as an hCalendar:

<pre><nowiki>
@TODO
</nowiki></pre>

This hCalendar could be displayed as:

@TODO

== Other ==

* See [[hcalendar-brainstorming]] for more examples (which may eventually be moved here) and analysis.

User talk:MikeTaylor

2005-10-11T16:59:44Z

MikeTaylor:

mailto<nowiki>:</nowiki>bear@code-bear.com