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
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
