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
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
