That is my instinct as well. Unfortunately, everything seems to use iCal
(mozilla, outlook, apple iCal) and from what I can find xcal seems to be stuck
between draft 2 (from 2002?) and draft 3 which may change things up
significantly if it is ever finished.
Well, I feel like the xcal draft 2 features will be more than sufficient for use in cocoon. Thought if there were a draft 3 actually in active development, I'd naturally agree it's definitely worth planning for. :)
So, we are probably looking at
1) a generator to transform ical to some intermediate format (probably xcal?) as you note below. If someone happens to have native xcal lying around, they could then just feed it right into the next steps. By the same token, if someone has a custom non-ical format (i.e., database, exchange server, etc.) they can stick some other generator in here.
2) a transformer to take this format and decorate it with calendar data (transforming to yet another intermediate) and
3) possibly a utility stylesheet for transforming this to a pretty html format. The last one would be generally application-specific, but a well designed root stylesheet could go a long way toward simplifying that process.
I would also suggest a serializer capable of producing iCalendar text files from an xCalendar SAX stream.
This will allow Cocoon to make extensive use of published iCalendar files from, well, obviously wherever! :)
That'd be great. In fact, a sample providing a webav location for ical publishing and a few pipelines to view that data would probably be a big hit.
heh... sorta gives me goose bumps... er, hang on, what's that i missed on today's shopping list ... "A Life" ... ehem, i see ... ;)
One problem I see with the ical/xcal standard is that it's not designed to be a database - for example when selecting one week out of a calendar covering a year you may need to parse (and generate sax for) the whole thing though it would be otherwise unnessary.
well, i had already done some thinking on this one... but first it's worth mentioning that any really huge files you feed into any particular generator will logically cause a performance penalty of some sort... so there's a degree of responsibility of the individual managing the content to streamline this info.
that said...
perhaps the generator could filter out the important stuff using attributes in the generator tag... i'm picturing something like:
Load whole ical into SAX stream: <map:generator type="calendar" src="blah.ics" />
Load date range:
<map:generator type="calendar" src="blah.ics" from="2004-03-22" to="2004-04-01" />
Load all information from a certain date, on: <map:generator type="calendar" src="blah.ics" from="2004-03-22" />
Load all information upto a certain date: <map:generator type="calendar" src="blah.ics" to="2004-04-01" />
Then you can implement special values for use in the from and to attributes, like:
today today +/- 14
month month +/- 6
year year +/- 2
where "today," "month," and "year" are always based on the current date; and offsets can be specified by using + or - followed by an integer.
but maybe that's a can of worms ... ;-)
jL
John Lianoglou | Vice President | ARACHNEdesign http://www.arachnedesign.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
