[uf-discuss] Aggregation of vevents in vcalendar [newbie]

[Brian Suda]

On 1/18/07, Chris Newell <chris.newell at rd.bbc.co.uk> wrote:
> Doesn't this contradict the specification? Quoting from http://microformats.org/wiki/hcalendar it says: "Authors may explicitly use elements with class="vcalendar" to wrap sets of vevents that all belong to the same calendar, e.g. when publishing multiple calendars on the same page".

you can certainly add class="vcalendar", but then you will have
multiple calendars on a single HTML page. This is NOT the default, but
it can be possible. This does cause problems later because then when
you use something like X2V or the other service, you will need to also
specify WHICH calendar you want to extract because you can only
extract one calendar at a time to an .ics file.

If you have a specific senario please let us know, no one has pressed
this issue so all the details have not been fully flushed out yet.

> >Multiple events on an HTML correspond to multiple VEVENT in
> >the iCalendar.
> >
> >If you look at the structure of the VCALENDAR it takes only a few
> >parameters, the calendar type, calendar name (this is taken from the
> >HTML page <title> element) and a METHOD all of which are usually
> >metadata purely for machines (except the <title> that is for both).
>
> Could you point me to where this is documented. I've had good look at the server but can't find this anywhere.

Not sure exactly what you mean here? so i'll have a guess.
If you look at the iCalendar RFC:
http://www.faqs.org/rfcs/rfc2445.html

a VCALENDAR can take only icalbody as paramaters. icalbody is defined as:

icalbody   = calprops component

     calprops   = 2*(

                ; 'prodid' and 'version' are both REQUIRED,
                ; but MUST NOT occur more than once

                prodid /version /

                ; 'calscale' and 'method' are optional,
                ; but MUST NOT occur more than once

                calscale        /
                method          /

                x-prop

                )


So that gives us ONLY 4 parameters to deal with.PRODID, VERSION,
CALSCALE, METHOD.

PRODID is the product who does the transformation, so this is NOT
something the user can define. VERSION we all are using 3.0, so that
again is not something that the user can update. CALSCALE is optional
and is not used. METHOD is defaulted to PUBLISH for iteroperability
issues with OUTLOOK 200X but is also optional.

So there is NO value in having these as additional parameters
explicitly marked-up in the HTML.

I can see your point about wanting multiple calendar containers to
keep things seperated, but most publishers want to either have ALL of
their events listed on a person's calendar, or have individual HTML
pages for each calendar type and allow users to subscribe to
individual event lists.

Does that make sense?
-brian

-- 
brian suda
http://suda.co.uk