[uf-new] Re: Calendar-wide scope for properties in hCalendar

[Toby A Inkster]

Ben Ward wrote:

> Plausible Solution #1: Include-Pattern
> We could extend hCalendar to permit use of the include pattern. This
> would parse. {<object class="include" data="#channel"></object>} to  
> reference a five character string. It's clumsy at best, definitely  
> ugly and I really feel that it's publisher unfriendly.

Yes, the present include pattern is very verbose. Whatsmore, use of  
the <object> element can trigger excessive memory usage in some  
browsers, and if you switch to <a>, then you might start interfering  
with the tab cycle. :-(

For these reasons, I proposed a replacement for the current include  
pattern, by which you'd just be able to use <li class="vevent  
#channel">...</li> to include the element with ID "channel" as part  
of the event.

Details:
http://microformats.org/wiki/include-pattern-strawman#Non- 
Verbose_Class-Based_Solution

This is currently implemented in Cognition (http://buzzword.org.uk/ 
cognition/).

If you were publishing the events as a table rather than a list, you  
could use the table header pattern described on the hcalendar- 
brainstorming page. This is supported by Cognition and IIRC X2V.

> Allow the LOCATION property to be a direct child of the VCALENDAR
> object, and apply that LOCATION to all VEVENT objects by default.

It seems to me that improving the include pattern to make it more  
usable is a better solution. Sure, this adjustment may seem fruitful  
in the short term, but then what happens when you have the same  
problem with organisations for multiple hCards, or items for multiple  
hReviews. An improvement to the include pattern would be usable for  
all properties in all compound microformats -- not just locations in  
hCalendar.

> In that regard, I'd like to ask those who build parsers to a more
> complex degree than I do to contribute here and answer whether such
> an optimisation would be unreasonably expensive to parse.

Although I've only been working on it for a month or so, I think  
Cognition is possibly the most complex parser around, in that it  
supports several different microformats, RDF (including RDFa and  
eRDF) and more. Such an extension wouldn't make hCalendars  
unreasonably difficult to parse. In the case of Cognition, it would  
basically be copying and pasting a chunk of code from the hEvent  
module to the hCalendar module.

But I really think that the include pattern is the way to go. If it's  
too verbose, then we should improve the include pattern for the  
benefit of all, rather than complicating hCalendar for the benefit of  
the few.

-- 
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>