[uf-discuss] hCalendar scope

[brian suda]

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