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

[Ben Ward]

Hi hi,

We (by which I mean ‘Steve Marshall’) at Yahoo! recently relaunched  
our European TV Listings page. We've attempted to integrate a full  
complement of hCalendar across the various listings pages.

In doing so, there are a few issues we've found, and I'll raise them  
here as separate threads for ease of management.

First up:

Consider pages like these:

   • http://uk.tv.yahoo.com/listings/channel-4/2008-03-15/
   • http://uk.tv.yahoo.com/listings/bbc-two/2008-03-15/

These are pages listing programmes on one particular channel. Each  
programme is a single VEVENT, the DTSTART, SUMMARY, and URL+UID are  
self explanatory from the page. The issue is LOCATION — the channel  
name — which for a page like this only appears once, in the heading  
of the page.

Currently, hCalendar requires the following structure:

VCALENDAR (implied)
   VEVENT
     SUMMARY
     LOCATION
     URL
     UID
     DTSTART
   VEVENT
     …
   VEVENT
     …
   VEVENT
     …

But the implied publishing structure we actually have on our page is:

VCALENDAR (implied)
   VEVENT
     SUMMARY
     LOCATION
     URL
     UID
     DTSTART
   VEVENT
     …
   VEVENT
     …
   VEVENT
     …

But, in terms of our *publishing* pattern, we actually have:

VCALENDAR (implied)
   LOCATION
   VEVENT
     SUMMARY
     URL
     UID
     DTSTART
   VEVENT
     …

Now, this seems like an extremely reasonable page structure, not just  
for television channels, but also for pages which list events from  
one single LOCATION (e.g. http://upcoming.yahoo.com/venue/22943/).

Plausible Solution #1: Include-Pattern

We could extend hCalendar to permit use of the include pattern. This  
would parse. However, in the case of pages like ours it would produce  
a huge amount of extraneous mark-up. On the "BBC 2" page, we'd have  
to repeat the include code  42 times.

  {<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.

Plausible Solution #2: Permit certain properties to be used globally  
in hCalendar

The include-pattern solution is publisher-unfriendly, especially  
since hCalendar could, I think, support a far more graceful data  
structure to solve this particular problem.

• Allow the LOCATION property to be a direct child of the VCALENDAR  
object, and apply that LOCATION to all VEVENT objects by default.  
(where a VEVENT has a LOCATION child, the default LOCATION would be  
overridden)

This way, the location data is only added once, whilst remaining a  
structurally contained part of the calendar. Mark-up would look  
something like this:

<div class="vcalendar">
    <div class="location">BBC 2</div>
    <ol>
         <li class="vevent">…</li>
         <li class="vevent">…</li>
         <li class="vevent">…</li>
         <li class="vevent">…</li>
     </ol>
</div>

The downside, of course, is that this deviates from data structure in  
the VCALENDAR spec, and would require parsers to perform more complex  
processing to include a LOCATION property for each VEVENT that may be  
exported.

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.

• I would spec this to *require* that the VCALENDAR class name be  
explicit in cases where properties are used globally
• This concept of globalising certain calendar properties could be  
extended to a few others, too. Namely ORGANIZER, for pages where a  
particular organisation is the sole organiser of events (I don't have  
an example to hand, though, hence this further expansion is offered  
only as a footnote to keep in mind).

Thanks,

Ben