[uf-discuss] hCalendar scope

[Hans Gerwitz]

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
>