Microformats Wiki - User contributions [en]

hcard-brainstorming

2006-07-11T00:17:59Z

PhilipAshlock: /* Spam prevention */

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

__TOC__

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

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

== Problems Being Solved ==

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

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

== Examples ==

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

=== Using RFC2806 with hCard ===

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

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

It is practical to write your tel number like this.

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

or even

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

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

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

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

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

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

== Encoding "modern" attributes ==

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

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

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

Still to be addressed:

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

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

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

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

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

[[User:EtanWexler|EtanWexler]] disagrees with the value of the “type” attribute. The [http://www.iana.org/ Internet Assigned Numbers Authority] has no registration for a “text/vcard” type. The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”. It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. So a different rel type must be established to decribe that relationship. The ideas vary from specific to vague. The list and categories follow:
<pre><nowiki>
rel="contactinfo"
rel="profile"
rel="author"
rel='PIM'
rel='person'
rel='about'
rel='contact'
rel='hcard'
rel='microformat'
</nowiki></pre>
Example of mixing two rel types to a single page.
rel="hcard xfn"

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

=== Auto-Discovery for XFN ===

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

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

== geo improvements ==

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

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

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

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

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

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

...

Type example:

GEO:37.386013;-122.082932
</pre>

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

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

=== latitude longitude shorthand ===

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

=== geo links ===

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

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

(N.B. I tried and failed to get Yahoo Maps and local to do something intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").

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

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

However, my first guess is NO for two reasons.

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

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

=== altitude ===

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

=== radius/zoom ===

Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.
=== ISO6709 ===
There is a description method for geographic coordinates named [http://en.wikipedia.org/wiki/ISO_6709 ISO6709] though some differs from the notation of vCard.
It can describe latitude and the longitude. Height is optional.
If ISO6709 is used, it is likely to be able to write as follows.
<pre><nowiki>
examples
<abbr class="geo" title="+37.386013-122.082932/">
Mountain View, CA
</abbr>

<abbr class="geo" title="+275916+0865640+8850/">
Mount Everest
</abbr>

</nowiki></pre>

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

== Open Questions ==

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

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

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

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

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

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

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

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

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

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

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

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>



<a class="internet" href="mailto:jfriday@host.com">
<dfn>
Joe Friday
</dfn>
</a>

+1-919-555-7878
Area Administrator, Assistant


</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

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

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

=== Distributed Commentor Icons ===

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

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

A distributed commentor icon implementation could work like this:

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

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

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

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

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

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

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

== Post vCard additions ==

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

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

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

== TODO ==

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

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

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF and back.

== Ambiguous name components ==

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>

...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...

</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

hcard-brainstorming

2006-07-11T00:02:57Z

PhilipAshlock: /* Spam prevention */

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

__TOC__

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

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

== Problems Being Solved ==

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

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

== Examples ==

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

=== Using RFC2806 with hCard ===

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

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

It is practical to write your tel number like this.

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

or even

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

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

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

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

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

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

== Encoding "modern" attributes ==

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

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

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

Still to be addressed:

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

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

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

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

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

[[User:EtanWexler|EtanWexler]] disagrees with the value of the “type” attribute. The [http://www.iana.org/ Internet Assigned Numbers Authority] has no registration for a “text/vcard” type. The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”. It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. So a different rel type must be established to decribe that relationship. The ideas vary from specific to vague. The list and categories follow:
<pre><nowiki>
rel="contactinfo"
rel="profile"
rel="author"
rel='PIM'
rel='person'
rel='about'
rel='contact'
rel='hcard'
rel='microformat'
</nowiki></pre>
Example of mixing two rel types to a single page.
rel="hcard xfn"

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

=== Auto-Discovery for XFN ===

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

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

== geo improvements ==

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

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

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

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

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

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

...

Type example:

GEO:37.386013;-122.082932
</pre>

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

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

=== latitude longitude shorthand ===

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

=== geo links ===

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

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

(N.B. I tried and failed to get Yahoo Maps and local to do something intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").

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

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

However, my first guess is NO for two reasons.

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

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

=== altitude ===

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

=== radius/zoom ===

Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.
=== ISO6709 ===
There is a description method for geographic coordinates named [http://en.wikipedia.org/wiki/ISO_6709 ISO6709] though some differs from the notation of vCard.
It can describe latitude and the longitude. Height is optional.
If ISO6709 is used, it is likely to be able to write as follows.
<pre><nowiki>
examples
<abbr class="geo" title="+37.386013-122.082932/">
Mountain View, CA
</abbr>

<abbr class="geo" title="+275916+0865640+8850/">
Mount Everest
</abbr>

</nowiki></pre>

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

== Open Questions ==

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

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

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

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

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

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

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

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

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

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

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

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>



<a class="internet" href="mailto:jfriday@host.com">
<dfn>
Joe Friday
</dfn>
</a>

+1-919-555-7878
Area Administrator, Assistant


</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

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

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

=== Distributed Commentor Icons ===

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

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

A distributed commentor icon implementation could work like this:

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

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

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

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

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

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

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

== Post vCard additions ==

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

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

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

== TODO ==

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

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

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF and back.

== Ambiguous name components ==

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>

...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...

</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

hcard-brainstorming

2006-07-11T00:02:05Z

PhilipAshlock: /* Spam prevention */

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

__TOC__

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

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

== Problems Being Solved ==

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

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

== Examples ==

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

=== Using RFC2806 with hCard ===

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

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

It is practical to write your tel number like this.

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

or even

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

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

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

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

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

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

== Encoding "modern" attributes ==

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

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

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

Still to be addressed:

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

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

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

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

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

[[User:EtanWexler|EtanWexler]] disagrees with the value of the “type” attribute. The [http://www.iana.org/ Internet Assigned Numbers Authority] has no registration for a “text/vcard” type. The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”. It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. So a different rel type must be established to decribe that relationship. The ideas vary from specific to vague. The list and categories follow:
<pre><nowiki>
rel="contactinfo"
rel="profile"
rel="author"
rel='PIM'
rel='person'
rel='about'
rel='contact'
rel='hcard'
rel='microformat'
</nowiki></pre>
Example of mixing two rel types to a single page.
rel="hcard xfn"

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

=== Auto-Discovery for XFN ===

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

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

== geo improvements ==

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

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

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

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

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

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

...

Type example:

GEO:37.386013;-122.082932
</pre>

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

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

=== latitude longitude shorthand ===

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

=== geo links ===

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

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

(N.B. I tried and failed to get Yahoo Maps and local to do something intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").

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

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

However, my first guess is NO for two reasons.

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

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

=== altitude ===

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

=== radius/zoom ===

Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.
=== ISO6709 ===
There is a description method for geographic coordinates named [http://en.wikipedia.org/wiki/ISO_6709 ISO6709] though some differs from the notation of vCard.
It can describe latitude and the longitude. Height is optional.
If ISO6709 is used, it is likely to be able to write as follows.
<pre><nowiki>
examples
<abbr class="geo" title="+37.386013-122.082932/">
Mountain View, CA
</abbr>

<abbr class="geo" title="+275916+0865640+8850/">
Mount Everest
</abbr>

</nowiki></pre>

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

== Open Questions ==

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

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

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

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

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

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

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

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

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

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

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

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>



<a class="internet" href="mailto:jfriday@host.com">
<dfn>
Joe Friday
</dfn>
</a>

+1-919-555-7878
Area Administrator, Assistant


</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

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

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

=== Distributed Commentor Icons ===

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

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

A distributed commentor icon implementation could work like this:

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

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

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

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

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link:
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

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

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

== Post vCard additions ==

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

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

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

== TODO ==

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

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

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF and back.

== Ambiguous name components ==

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>

...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...

</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

hcard-brainstorming

2006-07-10T23:52:37Z

PhilipAshlock: /* Spam prevention */

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

__TOC__

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

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

== Problems Being Solved ==

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

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

== Examples ==

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

=== Using RFC2806 with hCard ===

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

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

It is practical to write your tel number like this.

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

or even

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

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

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

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

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

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

== Encoding "modern" attributes ==

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

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

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

Still to be addressed:

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

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

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

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

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

[[User:EtanWexler|EtanWexler]] disagrees with the value of the “type” attribute. The [http://www.iana.org/ Internet Assigned Numbers Authority] has no registration for a “text/vcard” type. The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”. It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. So a different rel type must be established to decribe that relationship. The ideas vary from specific to vague. The list and categories follow:
<pre><nowiki>
rel="contactinfo"
rel="profile"
rel="author"
rel='PIM'
rel='person'
rel='about'
rel='contact'
rel='hcard'
rel='microformat'
</nowiki></pre>
Example of mixing two rel types to a single page.
rel="hcard xfn"

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

=== Auto-Discovery for XFN ===

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

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

== geo improvements ==

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

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

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

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

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

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

...

Type example:

GEO:37.386013;-122.082932
</pre>

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

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

=== latitude longitude shorthand ===

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

=== geo links ===

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

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

(N.B. I tried and failed to get Yahoo Maps and local to do something intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").

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

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

However, my first guess is NO for two reasons.

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

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

=== altitude ===

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

=== radius/zoom ===

Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.
=== ISO6709 ===
There is a description method for geographic coordinates named [http://en.wikipedia.org/wiki/ISO_6709 ISO6709] though some differs from the notation of vCard.
It can describe latitude and the longitude. Height is optional.
If ISO6709 is used, it is likely to be able to write as follows.
<pre><nowiki>
examples
<abbr class="geo" title="+37.386013-122.082932/">
Mountain View, CA
</abbr>

<abbr class="geo" title="+275916+0865640+8850/">
Mount Everest
</abbr>

</nowiki></pre>

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

== Open Questions ==

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

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

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

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

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

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

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

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

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

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

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

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>



<a class="internet" href="mailto:jfriday@host.com">
<dfn>
Joe Friday
</dfn>
</a>

+1-919-555-7878
Area Administrator, Assistant


</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

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

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

=== Distributed Commentor Icons ===

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

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

A distributed commentor icon implementation could work like this:

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

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

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

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

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link:
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

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

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

== Post vCard additions ==

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

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

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

== TODO ==

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

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

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF and back.

== Ambiguous name components ==

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>

...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...

</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

hcalendar-faq

2006-05-23T20:05:47Z

PhilipAshlock: /* Q&A */

= hCalendar FAQ =

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

== Q&A ==

# ''How do I use a class inside when I don't want the element I use it on to be a property of the calendar?''
#*Use a class name that isn't a defined iCalendar property name.
# ''What happens if the class is used both inside and outside ?''
#* That works fine.
# ''What do I do if I want to add styling to a group of calendar events, especially if the calendar contains dynamic content? ''
#* You can write style rules that incorporate both the context of said group (say it is in an ordered list with class name "group" for example) and the events, e.g.:<code>ol.group .vevent { /* insert common styling here */ } </code>
# ''What do you do if you don't want the calendar or card to be displayed?''
#* If you don't want the calendar or card to be displayed, why are you publishing it on the Web?
# ''What if you don't want specific properties to show up?''
#* You can trivially use CSS to hide (or otherwise alter the display) of certain properties. E.g. if you want to hide the "location" from all your VEVENTs you would write a rule like this: <code> .vevent .location { display:none } </code>. This won't, however, keep the properties from being read in the HTML source.
# ''If we use <abbr> title for the ISODate, how do we specify a different tooltip?''
#* For reasons of metadata transparency and visibility, it is recommended that you DO NOT specify a different tooltip. However, if in your particular content or application you must, you can do so with a nested span e.g. <code> <abbr title="20050221">Feb. 21st</abbr></code>
# ''Would the use of <acronym> for DTSTART be just as good as <abbr>?''
#* It could be, but there is no need. The <abbr> element is also preferred as it is better defined. The <acronym> element, and in particular, the term "acronym" means different things to different people, and thus we are not using it in [[hcalendar|hCalendar]].
# ''What happens if a browser doesn't support <abbr>?''
#* Then the human readable contents inside the element are displayed, which is the desirable behavior.
# ''How is [[hcalendar|hCalendar]] different from xCalendar, i.e. [http://www.ietf.org/internet-drafts/draft-hare-xcalendar-03.txt draft iCalendar XML guidelines submitted to the IETF]?''
#* hCalendar and xCalendar are actually very similar in that they are both based on iCalendar standard, RFC2445. However, xCalendar is a way of representing iCalendar files using non-standard XML element names and attributes. This is inadequate and unwieldly for serving on web pages. xCalendar is still a separate, encapsulated document in the context of the web, that requires yet another namespace. Nobody would ever look at an xCalendar XML file in the context of their ordinary browsing, unless it's XSLTed into something else, e.g. hCalendar. On the other hand, [[hcalendar|hCalendar]] is easily embeddable into normal XHTML web pages, easily stylable with CSS, cleanly separates human presentable date information vs. machine parsable ISO-8601 dates, etc. With hCalendar, calendar and events content appears both to the human user *and* to hCalendar-aware machine implementations, parsers, indexers, etc., on *today's* web.
# ''Can you provide more precise location data for an hCalendar event such as latitude and longitude?''
#* Yes, it is possible, by overlaying an [[hcard|hCard]] with the location markup (see [[hcalendar-brainstorming#hCard_locations|the brainstorming on hCard locations]]), e.g. using your lat long example (taking the values as given, someone feel free to fix these to be the real values). The code example(s) are presumed to be inside an element with a class name of "vevent". See the [[hcalendar-location-hcard-example]] page for details. For more discussions of location data, geographic data, and research into current and potential future formats, see the [[location-formats|location formats]] page.
# ''When transforming an hCalendar to a .ics file, do I have to convert the time to UTC?''
#* Yes. The iCalendar format does not permit the time to be published with an offset. hCalendars can be published with offsets, because this promotes accuracy, as it can more easily be verified (timezone math is hard), but tools which transform hCalendar to iCalendar must transformat times to UTC.
# ''How are recurring events represented?''
#* If you take a look at [http://microformats.org/wiki/hcalendar-examples#Example_3 Example 3], there is a proposed means using an RRULE property along with a freq sub-property. It's a start - more brainstorming at [http://microformats.org/wiki/hcalendar-brainstorming#Recurring_Events hcalendar-brainstorming].
# ''How does one markup just the year as opposed to an entire date? e.g. to represent age, or discussing "the past year" ?
#* Depends on the context. If by "the past year", you mean the past *calendar* year, then mark it up as January 1st through December 31st. If you mean the past 365 days, then mark it up according to whatever date it is relative to. Etc.
# ''Are there any programs of services that convert from iCalendar to hCalender?''
#*At the moment there are no plans to create a program. There are several issues when converting, mainly HOW the information is represented in HTML. Since you can use just about any element which could the converter choose. This is not to say a converter shouldn't be built, but it is out of the scope of microformats.
# ''Is the list of possible types for an ADR and TEL case sensitive?''
#* No, enumerated values are case-INsensitive, therefore Home, home, HOME, etc are all equivalent
# ''Why won't Outlook import my ics file''
#* Outlook is picky about some properties. With outlook, UID, DTSTAMP and METHOD are mandatory. Be sure you have marked-up your hCalendar with a class="uid" and a class="dtstamp" in a class="vevent"
# ''Can I use YYYY-MM-DDThh:mm:ss dates or do I have to use the YYYYMMDDThhmmss format?''
#* hCalendar specifies [http://en.wikipedia.org/wiki/ISO8601 ISO8601 datetime format], and both examples are valid, you can use with or without hyphens/colons/spaces.
# ''Do I have to specify detailed time and timezone information?''
#* Include as much information as necessary, minimally include YYYY-MM-DD
# ''Why do I have to use a 'T' between the date and time in ISO Dates?''
#* You can NOT use a white-space character, the 'T' is mandatory to separate the date from the time.
# ''Why are the root class names "vcalendar" and "vevent" and not "hcalendar"?''
#* [[hcalendar|hCalendar]] is based on the iCalendar spec (RFC 2445), which itself is based on vCalendar. The names of objects have remained consistent throughout and are based on the original names from vCalendar.
# ''How do I mark-up a date-time with the proper timezone?''
#* There are two ways to do this. First, you can add your timezone offset to the end of your date-time like this: 2006-01-01T12:00:00-0600. [[http://aa.usno.navy.mil/faq/docs/world_tzones.html See a world timezone offset map here]]. Also, be sure to adjust offset to account for [[http://en.wikipedia.org/wiki/Daylight_saving_time Daylight Saving Time]] for events within applicable dates and locations. The other option is to convert your date-time with a timezone into a UTC date-time. iCalendar requires that times be in UTC, but hCalendar also allows for encoding your date-times as proper ISO date-times with timezone offsets.
# ''Why does my event end a day earlier than I want?''
#* DTEND is not inclusive. If you want an event to end on January 2nd, then you will need to set DTEND to 2006-01-03, one day later. This is because the event will END the first second of the date provided, so if you specify 2006-01-02, then that says that the end of the event is at midnight between the 1st and 2nd.
# ''How do I represent a repeating event in hCalendar?''
#* See [[hcalendar-brainstorming#Recurring_Events|hCalendar brainstorming: Recurring Events]]
# ''What is the best way to represent a full address in the Location?''
#* See [[hcalendar-brainstorming#hCard_locations|hCalendar brainstorming: hCard locations]]

hcalendar

2006-05-23T19:55:38Z

PhilipAshlock: /* Example */

<h1> hCalendar </h1>

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

Want to get started with writing an [[hcalendar|hCalendar]] event? Use the [http://microformats.org/code/hcalendar/creator hCalendar creator] to write up an event and publish it.

__TOC__

== Draft Specification ==

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

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

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

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

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

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

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

== Semantic XHTML Design Principles ==

{{semantic-xhtml-design-principles}}

== Format ==

=== In General ===

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

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

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

=== More Semantic Equivalents ===

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

=== Singular vs. Plural Properties ===

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

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

==== Plural Properties Singularized ====

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

=== Human vs. Machine readable ===
If an <code><nowiki><abbr></nowiki></code> element is used for a property, then the '<code>title</code>' attribute of the <code><nowiki><abbr></nowiki></code> element is the value of the property, instead of the contents of the element, which instead provide a human presentable version of the value. This specification recommends that such <code><nowiki><abbr></nowiki></code> elements be used for the following iCalendar properties:
* DTSTART, DTEND, DURATION, RDATE, RRULE

== Example ==

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

<pre><nowiki>

<a class="url" href="http://www.web2con.com/">
Web 2.0 Conference:
<abbr class="dtstart" title="2005-10-05">October 5</abbr>-
<abbr class="dtend" title="2005-10-08">7</abbr>,
at the Argent Hotel, San Francisco, CA
</a>

</nowiki></pre>
which could be displayed as:

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

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

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

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

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

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

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

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

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

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

=== New Examples ===
Please add new examples to this section.
* [http://www.worldcupkickoff.com/ World Cup KickOff] where you can download and keep all the fixtures you are interested in so you will never miss a single game of the 2006 football World Cup!
* [http://www.socaltech.com socalTECH] is a news and information site. Their front page event listing is marked up with hCalendar.
* [http://www.webanalyticsassociation.org/en/calendarevents/search.asp Web Analytics Association] - hCalendar microformat is in place on all Tendenci sites on the calendar events search page and consolidated list page.
* [http://www.tendenci.com/en/calendarevents/search.asp Tendenci Calendar Events] with hCalendar
* [http://www.argolon.com/2006/04/17/web20-conference-in-dublin/ Web2.0 Conference in Dublin] hCalendar event
* [http://www.meetup.com/ Meetup.com] has marked up [http://www.meetup.com/cities/us/ny/new_york city event calendars], [http://photo.meetup.com/100/events/ group event lists], and [http://www.meetup.com/ signed-in homepages] with hCalendar.
* [http://ukwindsurfing.com/ ukwindsurfing.com] has marked upcoming events with hCalendar, and the [http://ukwindsurfing.com/events/ events page] in a table.
* [http://ocono.com/ ocono.com] has marked up it's "Upcoming Events" list with hCalendar.
* [http://www.austinbloggers.org/ Austin Bloggers] has marked up their "Upcoming Events" box with hCalendar ([http://www.austinbloggers.org/blog/a/001123.html announcement]).
* Ning's cloneable Group app has [[hcalendar|hCalendar]] markup on its [http://group.ning.com/index.php?controller=event&action=list event calendar] and [http://group.ning.com/index.php?controller=event&action=view&id=727220 event detail] pages.
* [http://tantek.com/microformats/2006/03-01-TechPlenAgenda.html Agenda: W3C Technical Plenary Day, March 1 2006] has [[hcard|hCard]] and [[hcalendar|hCalendar]] markup. ([http://www.w3.org/2006/03/01-TechPlenAgenda.html original here]).
* The National Arbor Day Foundation has started using hCalendars for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].
* [http://www.multipack.co.uk The Multipack] features a vevent for the next meeting information.
* [http://www.stateofflux.com/ State of Flux street art site] has started adding events in hCalendar format
* The [http://barcamp.org/#BarCamps BarCamp home page lists upcoming BarCamps marked up with hCalendar] and even has a "Subscribe..." link.
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the schedule and events for the week with hCalendar.
* [http://www.code4lib.org/2006/schedule code4lib Conference 2006 Schedule] is marked up with hCalendar as [http://www.code4lib.org/node/65 announced on their blog].
* [http://grouper.ieee.org/groups/754 IEEE 754 Working Group] - trying hCalendar for upcoming meetings.
* [http://www.pehuen.org/node/494 Elecciones 2005 Chile] - the first spanish language hCalendar event found in the wild.
* [http://www.codewitch.org/it/2005/11/17/no-creative-commons-no-party/ Giocolando » No Creative Commons? No Party!] is marked up with hCalendar
* [http://www.cmprofessionals.org/events/calendar.html CM Pros Events Calendar] by Bob Doyle
* [http://www.midgard-project.org/community/events/ Midgard CMS Event calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius]
* [http://www.iowamilitaryveteransband.com/schedule/ Iowa Military Veterans Band Schedule] - hCalendar markup [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ added by Scott Reynen]
* [http://www.funfairgames.net/weblog/posts/00000011.html Upcoming events on Jason A.R. Moody Amusements Weblog] posted by Jason Moody on 15 Oct 2005. [http://www.funfairgames.net/weblog/index.html His weblog] in general has hCalendar events posted inside the blog posts.
* [http://tantek.com/microformats/2005/syndicate/tracks-sessions-schedule.html Syndicate - Tracks & Sessions]
* [http://tantek.com/microformats/2005/web2/program.html Web 2.0 Conference schedule page marked up with hCalendar]
* [http://www.thisiscmon.com/ C'MON] is a rock band from Canada, and their [http://www.thisiscmon.com/shows/ tour dates] have been marked up by [http://www.d2digitalmedia.com/ Ray Dickman] with hCalendar.
* [http://ifreebusy.com/ ifreebusy.com] will display freebusy information using hCalendar. See this [http://ifreebusy.com/neiljensen/freebusy/ example].
* [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.
* [http://www.asdvbonaparte.nl/ ASDV Bonaparte] is a Dutch debating society. Their events calendar has been marked up with the hCalendar conventions.
* [http://chocnvodka.blogware.com/blog Suw Charman] has marked up [http://suw.org.uk/archives/category/events/ her events] with hCalendar.
* [http://www.blogbusinesssummit.com/ Blog Business Summit] has published their [http://www.blogbusinesssummit.com/details.htm event details] marked up with hCalendar.
* [http://eventful.com Eventful.com] publishes all events with hCalendar and venues with [[hcard|hCard]]. Took them only 15 minutes to implement both! Their Atom feeds also contain hCalendar/hCard.
* [http://upcoming.org Upcoming.org] publishes all events and lists of events with hCalendar. Took them only an hour to add hCalendar support to the site.
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events, [http://laughingsquid.com/squidlist/calendar/9949/2005/5/9 e.g. this party], now supports hCalendar.
* [http://paulschreiber.com/ Paul] Schreiber's [http://concerts.shrub.ca/ Sunnyvale House Concerts] site publishes hCalendar event information for upcoming concerts. In addition the [http://concerts.shrub.ca/shows Past Shows] page contains hCalendar events for all past concerts.
* [http://paulschreiber.com/ Paul] Schreiber's [http://iceoasis.shrub.ca/ unofficial schedule site] publishes hCalendar information for upcoming hockey games at [http://www.iceoasis.com/ Ice Oasis]
* [http://www.complexspiral.com/ Complex Spiral Consulting], both in the "Events" box on left side, and the separate [http://www.complexspiral.com/events/ Events page].
* [http://tantek.com/log Tantek's Thoughts], specifically the "Events" roll in the right-most column.
* [http://suda.co.uk/projects/holidays/ Lesser Known Holidays], a list of holidays on [http://suda.co.uk suda.co.uk] that can be imported via iCal and hCal so you can compare actual transformation versus intended.
* [http://norman.walsh.name/2005/itinerary/ Norm Walsh's travel schedule] use hCalendar as well as GRDDL.
* [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting] uses hCalendar to record date-related decisions, and uses a vtodo microformat to record action items.
* The [http://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm.htm program] marked up with hCalendar.
* The [http://lufgi4.informatik.rwth-aachen.de Laboratory for Dependable Distributed Systems] publishes it's [http://lufgi4.informatik.rwth-aachen.de/cfps list of notable CfPs on dependability and security] with hCalendar-todo elements.
* The [http://laughingsquid.com/laughing-squid-10th-anniversary-party/ Laughing Squid 10th Anniversary Party] has an hcalendar page.
* SPRACI has hcalendar versions of its nightlife/clubbing/gigs/festivals listings for many cities worldwide - eg: [http://www.spraci.com/listhcalendar.php?parea=sydney&category=all Events in Sydney] (check the [http://www.spraci.com/api/ API] pages in the faq section of [http://www.spraci.com/ SPRACI] for more info about the area/city keywords and category tags to use to get data for your city/categories
* WWF-Australia events calendars: [http://wwf.org.au/act/events/ What's on], [http://wwf.org.au/act/volunteer/ Volunteer]
* [http://rubyholic.com rubyholic] uses hCalendar to publish calendars for ruby groups.
* [http://www.bath.ac.uk/whats-on/ University of Bath What's On] uses hCalendar on individual event pages

=== Examples with some problems ===
* [http://www.bokle.de/ s'Bokle] is a German music pub. Their events calendar has been marked up with hCalendar.
** improper use of rrule --[[User:RyanKing|RyanKing]] 16:04, 6 Jan 2006 (PST)

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

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

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

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

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

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

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

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

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

==== Web Services ====
These return iCalendar (.ics) and other calendar formats for easy importing into typical calendar programs or other processing.
* [http://feeds.technorati.com/events Technorati Events Feed service] uses X2V library to parse hCalendar and return iCalendar (.ics). Note friendly URL, e.g. http://feeds.technorati.com/events/http%3A//microformats.org
* [http://suda.co.uk/projects/X2V/ X2V] parses hCalendar and produces a .ics (iCalendar) stream. Note: needs to be updated to track changes in the specification as they occur.
* [http://lifelint.net/ Life Lint Parser] parses hCalendar and produces .ics, .rdf and debugging information and attempts to be more fully compliant to the iCal standard than previous implementations. It can be used in the same manner as X2V. Can output iCal (w optional Outlook 2002 compat), and RDF.
==== Firefox Greasemonkey Plugins ====
* [http://george.hotelling.net/90percent/ George] has built a [http://george.hotelling.net/90percent/geekery/greasemonkey_and_microformats.php Greasemonkey user script that detects hCalendar events and allows users to easily add them to their calendar application(s)].
* [http://blogmatrix.blogmatrix.com/ David Janes] has produced a [[Greasemonkey]] [http://www.blogmatrix.com/include/microformat-find.user.js script] that finds many microformat elements, including hCalendar events, and [http://blog.davidjanes.com/mtarchives/2005_08.html#003379 provides a popup menu of actions]. The hCalendar to vCalendar conversion is done internally within the script. ''This does not work with FireFox 1.5+/GreaseMonkey 0.6.4+.''
==== Aggregators ====
* [http://kula.jp/software/endo/screenshots/ Endo], an OS X aggregator, supports discovering hCal and adding those events to iCal. Look at the last screenshot at the bottom of the page.

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

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

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

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

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

=== Potential implementations ===

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

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

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

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

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

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

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

== Discussions ==

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

* [[hcalendar-brainstorming]]

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

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

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

hcalendar

2006-05-23T19:43:30Z

PhilipAshlock: /* Example */

<h1> hCalendar </h1>

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

Want to get started with writing an [[hcalendar|hCalendar]] event? Use the [http://microformats.org/code/hcalendar/creator hCalendar creator] to write up an event and publish it.

__TOC__

== Draft Specification ==

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

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

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

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

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

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

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

== Semantic XHTML Design Principles ==

{{semantic-xhtml-design-principles}}

== Format ==

=== In General ===

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

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

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

=== More Semantic Equivalents ===

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

=== Singular vs. Plural Properties ===

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

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

==== Plural Properties Singularized ====

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

=== Human vs. Machine readable ===
If an <code><nowiki><abbr></nowiki></code> element is used for a property, then the '<code>title</code>' attribute of the <code><nowiki><abbr></nowiki></code> element is the value of the property, instead of the contents of the element, which instead provide a human presentable version of the value. This specification recommends that such <code><nowiki><abbr></nowiki></code> elements be used for the following iCalendar properties:
* DTSTART, DTEND, DURATION, RDATE, RRULE

== Example ==

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

<pre><nowiki>

<a class="url" href="http://www.web2con.com/">
Web 2.0 Conference:
<abbr class="dtstart" title="2005-10-05">October 5</abbr>-
<abbr class="dtend" title="2005-10-08">7</abbr>,
at the Argent Hotel, San Francisco, CA
</a>

</nowiki></pre>
which could be displayed as:

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

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

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

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

Note 4: ISO8601 dates (required by iCalendar) are not very human friendly. In addition, the year is often understood implicitly by humans from the context. Thus <code><nowiki><abbr></nowiki></code> elements are used to simultaneously provide a human friendly date and/or time in the visible contents of the element, while placing the respective machine parsable comprehensive ISO8601 datetime in the 'title' attribute.
The notation YYYY-MM-DD should be used for better readability. The [http://en.wikipedia.org/wiki/ISO8601#Combined_representations ISO8601 standard] is valid with or without hyphens/colons/spaces (either YYYY-MM-DDThh:mm:ss or YYYYMMDDThhmmss are acceptable uses).

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

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

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

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

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

=== New Examples ===
Please add new examples to this section.
* [http://www.worldcupkickoff.com/ World Cup KickOff] where you can download and keep all the fixtures you are interested in so you will never miss a single game of the 2006 football World Cup!
* [http://www.socaltech.com socalTECH] is a news and information site. Their front page event listing is marked up with hCalendar.
* [http://www.webanalyticsassociation.org/en/calendarevents/search.asp Web Analytics Association] - hCalendar microformat is in place on all Tendenci sites on the calendar events search page and consolidated list page.
* [http://www.tendenci.com/en/calendarevents/search.asp Tendenci Calendar Events] with hCalendar
* [http://www.argolon.com/2006/04/17/web20-conference-in-dublin/ Web2.0 Conference in Dublin] hCalendar event
* [http://www.meetup.com/ Meetup.com] has marked up [http://www.meetup.com/cities/us/ny/new_york city event calendars], [http://photo.meetup.com/100/events/ group event lists], and [http://www.meetup.com/ signed-in homepages] with hCalendar.
* [http://ukwindsurfing.com/ ukwindsurfing.com] has marked upcoming events with hCalendar, and the [http://ukwindsurfing.com/events/ events page] in a table.
* [http://ocono.com/ ocono.com] has marked up it's "Upcoming Events" list with hCalendar.
* [http://www.austinbloggers.org/ Austin Bloggers] has marked up their "Upcoming Events" box with hCalendar ([http://www.austinbloggers.org/blog/a/001123.html announcement]).
* Ning's cloneable Group app has [[hcalendar|hCalendar]] markup on its [http://group.ning.com/index.php?controller=event&action=list event calendar] and [http://group.ning.com/index.php?controller=event&action=view&id=727220 event detail] pages.
* [http://tantek.com/microformats/2006/03-01-TechPlenAgenda.html Agenda: W3C Technical Plenary Day, March 1 2006] has [[hcard|hCard]] and [[hcalendar|hCalendar]] markup. ([http://www.w3.org/2006/03/01-TechPlenAgenda.html original here]).
* The National Arbor Day Foundation has started using hCalendars for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].
* [http://www.multipack.co.uk The Multipack] features a vevent for the next meeting information.
* [http://www.stateofflux.com/ State of Flux street art site] has started adding events in hCalendar format
* The [http://barcamp.org/#BarCamps BarCamp home page lists upcoming BarCamps marked up with hCalendar] and even has a "Subscribe..." link.
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the schedule and events for the week with hCalendar.
* [http://www.code4lib.org/2006/schedule code4lib Conference 2006 Schedule] is marked up with hCalendar as [http://www.code4lib.org/node/65 announced on their blog].
* [http://grouper.ieee.org/groups/754 IEEE 754 Working Group] - trying hCalendar for upcoming meetings.
* [http://www.pehuen.org/node/494 Elecciones 2005 Chile] - the first spanish language hCalendar event found in the wild.
* [http://www.codewitch.org/it/2005/11/17/no-creative-commons-no-party/ Giocolando » No Creative Commons? No Party!] is marked up with hCalendar
* [http://www.cmprofessionals.org/events/calendar.html CM Pros Events Calendar] by Bob Doyle
* [http://www.midgard-project.org/community/events/ Midgard CMS Event calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius]
* [http://www.iowamilitaryveteransband.com/schedule/ Iowa Military Veterans Band Schedule] - hCalendar markup [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ added by Scott Reynen]
* [http://www.funfairgames.net/weblog/posts/00000011.html Upcoming events on Jason A.R. Moody Amusements Weblog] posted by Jason Moody on 15 Oct 2005. [http://www.funfairgames.net/weblog/index.html His weblog] in general has hCalendar events posted inside the blog posts.
* [http://tantek.com/microformats/2005/syndicate/tracks-sessions-schedule.html Syndicate - Tracks & Sessions]
* [http://tantek.com/microformats/2005/web2/program.html Web 2.0 Conference schedule page marked up with hCalendar]
* [http://www.thisiscmon.com/ C'MON] is a rock band from Canada, and their [http://www.thisiscmon.com/shows/ tour dates] have been marked up by [http://www.d2digitalmedia.com/ Ray Dickman] with hCalendar.
* [http://ifreebusy.com/ ifreebusy.com] will display freebusy information using hCalendar. See this [http://ifreebusy.com/neiljensen/freebusy/ example].
* [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.
* [http://www.asdvbonaparte.nl/ ASDV Bonaparte] is a Dutch debating society. Their events calendar has been marked up with the hCalendar conventions.
* [http://chocnvodka.blogware.com/blog Suw Charman] has marked up [http://suw.org.uk/archives/category/events/ her events] with hCalendar.
* [http://www.blogbusinesssummit.com/ Blog Business Summit] has published their [http://www.blogbusinesssummit.com/details.htm event details] marked up with hCalendar.
* [http://eventful.com Eventful.com] publishes all events with hCalendar and venues with [[hcard|hCard]]. Took them only 15 minutes to implement both! Their Atom feeds also contain hCalendar/hCard.
* [http://upcoming.org Upcoming.org] publishes all events and lists of events with hCalendar. Took them only an hour to add hCalendar support to the site.
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events, [http://laughingsquid.com/squidlist/calendar/9949/2005/5/9 e.g. this party], now supports hCalendar.
* [http://paulschreiber.com/ Paul] Schreiber's [http://concerts.shrub.ca/ Sunnyvale House Concerts] site publishes hCalendar event information for upcoming concerts. In addition the [http://concerts.shrub.ca/shows Past Shows] page contains hCalendar events for all past concerts.
* [http://paulschreiber.com/ Paul] Schreiber's [http://iceoasis.shrub.ca/ unofficial schedule site] publishes hCalendar information for upcoming hockey games at [http://www.iceoasis.com/ Ice Oasis]
* [http://www.complexspiral.com/ Complex Spiral Consulting], both in the "Events" box on left side, and the separate [http://www.complexspiral.com/events/ Events page].
* [http://tantek.com/log Tantek's Thoughts], specifically the "Events" roll in the right-most column.
* [http://suda.co.uk/projects/holidays/ Lesser Known Holidays], a list of holidays on [http://suda.co.uk suda.co.uk] that can be imported via iCal and hCal so you can compare actual transformation versus intended.
* [http://norman.walsh.name/2005/itinerary/ Norm Walsh's travel schedule] use hCalendar as well as GRDDL.
* [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting] uses hCalendar to record date-related decisions, and uses a vtodo microformat to record action items.
* The [http://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm.htm program] marked up with hCalendar.
* The [http://lufgi4.informatik.rwth-aachen.de Laboratory for Dependable Distributed Systems] publishes it's [http://lufgi4.informatik.rwth-aachen.de/cfps list of notable CfPs on dependability and security] with hCalendar-todo elements.
* The [http://laughingsquid.com/laughing-squid-10th-anniversary-party/ Laughing Squid 10th Anniversary Party] has an hcalendar page.
* SPRACI has hcalendar versions of its nightlife/clubbing/gigs/festivals listings for many cities worldwide - eg: [http://www.spraci.com/listhcalendar.php?parea=sydney&category=all Events in Sydney] (check the [http://www.spraci.com/api/ API] pages in the faq section of [http://www.spraci.com/ SPRACI] for more info about the area/city keywords and category tags to use to get data for your city/categories
* WWF-Australia events calendars: [http://wwf.org.au/act/events/ What's on], [http://wwf.org.au/act/volunteer/ Volunteer]
* [http://rubyholic.com rubyholic] uses hCalendar to publish calendars for ruby groups.
* [http://www.bath.ac.uk/whats-on/ University of Bath What's On] uses hCalendar on individual event pages

=== Examples with some problems ===
* [http://www.bokle.de/ s'Bokle] is a German music pub. Their events calendar has been marked up with hCalendar.
** improper use of rrule --[[User:RyanKing|RyanKing]] 16:04, 6 Jan 2006 (PST)

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

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

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

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

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

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

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

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

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

==== Web Services ====
These return iCalendar (.ics) and other calendar formats for easy importing into typical calendar programs or other processing.
* [http://feeds.technorati.com/events Technorati Events Feed service] uses X2V library to parse hCalendar and return iCalendar (.ics). Note friendly URL, e.g. http://feeds.technorati.com/events/http%3A//microformats.org
* [http://suda.co.uk/projects/X2V/ X2V] parses hCalendar and produces a .ics (iCalendar) stream. Note: needs to be updated to track changes in the specification as they occur.
* [http://lifelint.net/ Life Lint Parser] parses hCalendar and produces .ics, .rdf and debugging information and attempts to be more fully compliant to the iCal standard than previous implementations. It can be used in the same manner as X2V. Can output iCal (w optional Outlook 2002 compat), and RDF.
==== Firefox Greasemonkey Plugins ====
* [http://george.hotelling.net/90percent/ George] has built a [http://george.hotelling.net/90percent/geekery/greasemonkey_and_microformats.php Greasemonkey user script that detects hCalendar events and allows users to easily add them to their calendar application(s)].
* [http://blogmatrix.blogmatrix.com/ David Janes] has produced a [[Greasemonkey]] [http://www.blogmatrix.com/include/microformat-find.user.js script] that finds many microformat elements, including hCalendar events, and [http://blog.davidjanes.com/mtarchives/2005_08.html#003379 provides a popup menu of actions]. The hCalendar to vCalendar conversion is done internally within the script. ''This does not work with FireFox 1.5+/GreaseMonkey 0.6.4+.''
==== Aggregators ====
* [http://kula.jp/software/endo/screenshots/ Endo], an OS X aggregator, supports discovering hCal and adding those events to iCal. Look at the last screenshot at the bottom of the page.

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

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

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

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

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

=== Potential implementations ===

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

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

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

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

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

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

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

== Discussions ==

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

* [[hcalendar-brainstorming]]

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

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

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

irc

2006-05-12T03:39:34Z

PhilipAshlock: /* People on irc */

__NOTOC__
= Microformats IRC =

We have an IRC channel, [irc://irc.freenode.net#microformats #microformats on the freenode network].

There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.

== People on irc ==
A list of IRC regulars and their normal timezones. (winter/summer)

* [[User:Amette|amette]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)
* [[User:Ben Ward|BenWard]] (+0000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:Boneill|boneill]] (+0000)
* [[User:Brian|briansuda]] (-0600/-0500)
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)
* [[User:Cgriego|cgriego]] (-0600/-0500)
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)
* [[User:ChristopherStJohn|cks]] (-0600/-0500)
* [[User:DanC|DanC]] (-0600/-0500)
** office hours: Wednesday afternoons, America/Chicago time
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)
* [[User:EdwardOConnor|hober]] (-0800/-0700)
* [[User:Enric|enric]] (-0800/-0700)
* [[User:Evan|evanpro]] (-0500)
* [[User:Fil|Fil]] (+0200)
* [[User:Hlb|hlb]] (+0800-0700)
* [[User:IanHickson|Hixie]] (-0800/-0700)
* [[User:Izo|IZO]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)
* [[User:Keri Henare|kerihenare]] (+1200)
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:neuro|neuro`]]
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)
** Office hours: Wednesday, 20:30-21:30 UTC
* [[User:RyanKing|kingryan]] (-0800/-0700)
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* [[User:Dana Benson|Snowden]] (-0800/-0700)
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)
* [[User:Tantek|Tantek]] (-0800/-0700)
* [[User:Dan Kubb|dkubb]] (-0800/-0700)

=== Greetings ===
To display a brief description of who you are each time you join the channel, you can create a definition for your username. To do so pass the <tt>?def</tt> command using something like the following convention (be brief):

<code>?def jdoe is John Doe and can be found online at <nowiki>http://www.jdoewebsite.com</nowiki></code>

More information about using JiBot commands can be found on the [http://joi.ito.com/joiwiki/JiBot jibot website]

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [http://joi.ito.com/joiwiki/JiBot jibot]

== Logs ==

Available here: http://rbach.priv.at/Microformats-IRC/

== IRC meetups ==

The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.

zen-garden

2006-02-04T05:21:04Z

PhilipAshlock: /* Interested parties */

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

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

* [[User:Scott Reynen|Scott Reynen]]
** could make the backend submission and switcher functionality

* Malarkey (Andy Clarke http://www.stuffandnonsense.co.uk)
** Designer
** I agreed to help by contributing design themes after talking with Kevin and Tantek

* [[User:PhilipAshlock|Philip Ashlock]] (http://www.philaestheta.com)
** Designer/Developer
** I agree to help by developing interface design - clean attractive implementations
** I have a server and domain names to contribute
** I have live data to implement with a university website and a record label website
** My university will essentially be paying me for development work
** Suggestions for where efforts should be focused are most appreciated

== 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/ --[[User:RobertBachmann|Robert Bachmann]] 14:03, 21 Oct 2005 (PDT)
* Should the example page contain examples for all microformats or should there be one example page per microformat? --[[User:RobertBachmann|Robert Bachmann]] 08:57, 24 Oct 2005 (PDT)
** I think the example pages should mirror real world examples as much as practical. In some cases, microformats will be mixed, and in others they will occur independently, and it would be nice to have an environment in which to test microformat applications on such a diversity of example data. On the other hand, I can see some benefit in keeping it simple to encourage use. --[[User:ScottReynen|Scott Reynen]] 12:44, 26 Oct 2005 (CST)

=== Back end prototype ===
Coded by Scott Reynen

* Demo: http://www.randomchaos.com/mfzen/
* Source: http://www.randomchaos.com/source/

zen-garden

2006-02-04T05:12:57Z

PhilipAshlock: /* Interested parties */

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

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

* [[User:Scott Reynen|Scott Reynen]]
** could make the backend submission and switcher functionality

* Malarkey (Andy Clarke http://www.stuffandnonsense.co.uk)
** Designer
** I agreed to help by contributing design themes after talking with Kevin and Tantek

* [[User:PhilipAshlock|Philip Ashlock]] (http://www.philaestheta.com)
** Designer/Developer
** I agree to help by developing interface design - clean attractive implementations
** I have a server and domain names to contribute
** I have lots of live data from a university to work with
** My university will essentially be paying me for development work
** Suggestions for where efforts should be focused are most appreciated

== 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/ --[[User:RobertBachmann|Robert Bachmann]] 14:03, 21 Oct 2005 (PDT)
* Should the example page contain examples for all microformats or should there be one example page per microformat? --[[User:RobertBachmann|Robert Bachmann]] 08:57, 24 Oct 2005 (PDT)
** I think the example pages should mirror real world examples as much as practical. In some cases, microformats will be mixed, and in others they will occur independently, and it would be nice to have an environment in which to test microformat applications on such a diversity of example data. On the other hand, I can see some benefit in keeping it simple to encourage use. --[[User:ScottReynen|Scott Reynen]] 12:44, 26 Oct 2005 (CST)

=== Back end prototype ===
Coded by Scott Reynen

* Demo: http://www.randomchaos.com/mfzen/
* Source: http://www.randomchaos.com/source/

zen-garden

2006-02-04T05:08:23Z

PhilipAshlock: /* Interested parties */

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

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

* [[User:Scott Reynen|Scott Reynen]]
** could make the backend submission and switcher functionality

* Malarkey (Andy Clarke http://www.stuffandnonsense.co.uk)
** Designer
** I agreed to help by contributing design themes after talking with Kevin and Tantek

* [[User:PhilipAshlock|Philip Ashlock]] (http://www.philaestheta.com)
** Designer/Developer
** I agree to help by developing interface design - clean attractive implementations
** I have lots of live data from a university to work with
** My university will essentially be paying me for development work
** Suggestions for where efforts should be focused are most appreciated

== 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/ --[[User:RobertBachmann|Robert Bachmann]] 14:03, 21 Oct 2005 (PDT)
* Should the example page contain examples for all microformats or should there be one example page per microformat? --[[User:RobertBachmann|Robert Bachmann]] 08:57, 24 Oct 2005 (PDT)
** I think the example pages should mirror real world examples as much as practical. In some cases, microformats will be mixed, and in others they will occur independently, and it would be nice to have an environment in which to test microformat applications on such a diversity of example data. On the other hand, I can see some benefit in keeping it simple to encourage use. --[[User:ScottReynen|Scott Reynen]] 12:44, 26 Oct 2005 (CST)

=== Back end prototype ===
Coded by Scott Reynen

* Demo: http://www.randomchaos.com/mfzen/
* Source: http://www.randomchaos.com/source/

zen-garden

2006-02-04T05:05:51Z

PhilipAshlock: /* Interested parties */

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

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

* [[User:Scott Reynen|Scott Reynen]]
** could make the backend submission and switcher functionality

* Malarkey (Andy Clarke http://www.stuffandnonsense.co.uk)
** Designer
** I agreed to help by contributing design themes after talking with Kevin and Tantek

* [[User:PhilipAshlock|Philip Ashlock]] (http://www.philaeshteta.com)
** Designer/Developer
** I agree to help by developing interface design - clean attractive implementations
** I have lots of live data from a university to work with
** My university will essentially be paying me for development work
** Suggestions for where efforts should be focused are most appreciated

== 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/ --[[User:RobertBachmann|Robert Bachmann]] 14:03, 21 Oct 2005 (PDT)
* Should the example page contain examples for all microformats or should there be one example page per microformat? --[[User:RobertBachmann|Robert Bachmann]] 08:57, 24 Oct 2005 (PDT)
** I think the example pages should mirror real world examples as much as practical. In some cases, microformats will be mixed, and in others they will occur independently, and it would be nice to have an environment in which to test microformat applications on such a diversity of example data. On the other hand, I can see some benefit in keeping it simple to encourage use. --[[User:ScottReynen|Scott Reynen]] 12:44, 26 Oct 2005 (CST)

=== Back end prototype ===
Coded by Scott Reynen

* Demo: http://www.randomchaos.com/mfzen/
* Source: http://www.randomchaos.com/source/

User:PhilipAshlock

2006-02-04T05:05:40Z

PhilipAshlock:

AIM: philaestheta

[http://www.philaestheta.com Website with contact info ]