Not to throw a spanner in the works, but i would disagree.
Part of the reason the other VComponents were never formalized into a
microformat was use-cases. When we started working with encoding events,
it seemed most natural to look to iCalendar. Now, iCalendar DOES have
several of those other components, but no one was interested in looking
to see if applications consumed them, or if people were even publishing
their free-busy time on the web already.
After a year of working on microformats, there has been some interest
recently in starting a ToDo format. It only makes sense to look to VTODO
for a model since applications support it already. So wouldn't "throw
the baby out with the bath water" and disallow all non-vevent components
in the RFC spec.
As for free-busy time, it is exactly the same as vevent with a different
root class name vevent=>vfreebusy, the main reason it has not been
implements is interest, not because of parsing or application support.
So i think we should keep our options open for that as well.
Also, hCalendar doesn't support the full spectrum of iCalendar. There is
still on going discussion about how to encode Re-occurring events
properly and if it is even an issue? There has been discussion of
modeling hCalendar after the ICAL Basic spec[1,2] and NOT the RFC (of
which the ICAL Basic is a subset).
-brian
[1] - http://www.ietf.org/internet-drafts/draft-royer-ical-basic-04.txt
[2] -
http://www.google.com/search?rls=en&q=site:http://microformats.org/discuss/+ical+basic&ie=UTF-8&oe=UTF-8
Hans Gerwitz wrote:
Alright, I'm giving in to the hegemony and will adopt vevent for all
calendar use cases. My sample content
<http://hans.gerwitz.com/2006/06/01/she-said-yes.html> has been
adjusted and the various parsers all like it, now.
What drove this decision is a consideration of the iCalendar-hCalendar
impedance mismatch. VJOURNAL is not the only component not
represented in hCalendar; VTODO and VFREEBUSY are also unaccounted for
(in the ecosystem, at least. Only Mark Mansour's parser accounts for
non-event components).
So, I'd like to propose the VEVENT-centric scope of hCalendar be
formalized:
- Ryan's "remove vjournal" to-do item should be expanded to include
vtodo and vfreebusy, and executed to prevent others falling into the
trap I did.
- References to iCalendar (especially "1:1 representation" of RFC
2445!) in wiki/hcalendar should be re-worded to specify that only the
VEVENT component is mapped.
I'd be happy to handle the wikicleanup if there is a consensus. Is
there a voting process here?
- - -
Hans Gerwitz
hans.gerwitz.com
On Jun 3, 2006, at 12:00 PM, Hans Gerwitz wrote:
Thanks for replying, Ryan. That's exactly what I suspected had
occurred and is completely reasonable.
Would you mind sharing your thoughts on formatting records like "I
<?>met <hcard>Ryan</hcard> today for lunch at <hreview>The Pink
Door</hreview></?>"? It looks like if I want to live in the uf
ecosystem I need to use hcalendar's vevent; but that feels like an
abuse of that spec, since it would be inappropriate in iCalendar.
Perhaps I'm showing my age by taking an RFC too seriously.
- - -
Hans Gerwitz
hans.gerwitz.com
On Jun 2, 2006, at 5:30 PM, Ryan King wrote:
Our reasoning behind dropping vjournal is this:
1. For the most part, vjournal and hatom cover the same ground.
2. vjournal was rejected in the hatom process
3. we don't want two ways to do the same thing
4. perhaps we should drop vjournal?
The only part that's up for debate is #1, and I, personally, think
that making that case would be pretty difficult, as I think there is
a significant overlap, with the divergences amounting to edge cases,
which we tend to no worry about.
-ryan
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
