(unknown charset) Re: [Fwd: Re: [Fwd: Re: A little RSS+events app]]

Thanks Par, I think your comments are very useful.

I've had similar comments by webmasters that RSS events is a clear, well
documented and above all very simple format, making it practical for
people to create, even if their technical knowledge (of RDF, RSS,
iCalendar and the rest) is limited or non-existent.

http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_event.html

However, there are some issues which make it difficult to
combine it with or transform to icalendar data, and these stem from the
vagueness of the definitions of location, organizer and type fields,
and the notion of an 'implied' timezone from the location if not
specified in statedate and enddate. As an example, if a location is a
string, then variation in the sort of string over different feeds will
mean they are not compatible, and if that is so, then calculation of
timezones may not be interoperable. Similarly if there are no
constraints on the sort of string that goes in organizer property, then
we can't easily find all the events organised by person x.

In RDF we tend to use intermediate nodes to describe semantics rather
than constraining the form of strings (which we could do in rss events
with an XML schema for example). It seems to me that the RDF way is
potentially more interesting, but will result in a reduction in
simplicity and be offputting, especially in the RSS community. In either
case, precise constraining of semantics is very important for calendar
interoperability, with other RSS events feeds and with calendar
applications.

Any thoughts? At the moment there aren't too many feeds, but if lots of
people were to create them, it would be annoying if they weren't
accurately transformable to iCalendar so that existing applications (for
example Mozilla's calendar) could deal with them.

cheers,

Libby

On 29 Aug 2002, [ISO-8859-1] Pär Lannerö wrote:

>
> Hi all,
> Libby Miller asked me to share a private conversation about RSS+events
> with this list, so here comes:
>
> -----Forwarded Message-----
>
> > On 29 Aug 2002, [ISO-8859-1] Pär Lannerö wrote:
> >
> > > Libby Miller wrote:
> > > > By the way, how would you as a rss+events creator feel if the events
> > > > module was a bit more complicated, e.g. had intermediate nodes for
> > > > dates? I've had some complaints that the events module isn't accurate
> > > > enough compared with icalendar. what do you think?
> > >
> > > Here are some preliminary thoughts...
> > >
> > > According to the KISS doctrine, the RSS+events format is a lot better
> > > than iCalendar. It is easy to implement - something which can not be
> > > said about iCalendar. But if usage catches on, there will soon be a need
> > > for a revised version. The interesting question is whether RSS+events is
> > > TOO simple to be useful in real life situations.
> > >
> > > In order to answer that question, one should first decide what real life
> > > situations RSS+events is good for. If the situation is "to function as a
> > > synchronization format between desktop calendar applications" then I
> > > believe the format is too simple. Desktop calendar apps tend to allow
> > > lots of semantics to be associated with a calendar entry. Recurrence
> > > rules being just one important example. iCalendar, obviously, has a five
> > > year headstart in dealing with this situation.
> > >
> > > If, on the other hand, the situation is "to allow webmasters to encode
> > > calendaring information in a machine readable format for events
> > > aggregators to collect" then perhaps RSS+events is just right. I just
> > > whish there were a number of those aggregators out there! When will
> > > Google publish a specialized events search interface?
> > >
> > > The situation we have been working with SKiCal is somewhere in between:
> > > "allowing large (and sometimes complex) events databases to exchange
> > > events with one another". SKiCal, as you may remember, is a superset of
> > > iCalendar, thus allowing for all kinds of information about the event.
> > > But it has been implemented in no more than a dozen or so systems.
> > > Probably because of the relative complexity of the format.
> > >
> > > I think RSS+events in its current form is good enough to begin with. As
> > > you wrote, a natural next step would be to add a second module for the
> > > specification of simple recurring rules. Recurrence rules can get
> > > extremely complex. A language which can express simple recurrence rules
> > > in a simple way (but perhaps not able to express complex rules at all)
> > > would be very useful. I think Greg has written a few draft
> > > specifications for such languages...
> > >
> > > As from next week, I will put aside half of my time for a few months to
> > > write a report on the SKiCal project. (In the form of a master's
> > > thesis.) So I will probably have lots of better thought-through
> > > conclusions a few weeks from now. I'd be very glad to discuss these
> > > things with you if you like.
> > >
> > > /Pär
> > >
> > >
> > >
>
>
>

Received on Thursday, 29 August 2002 05:16:55 UTC