[Ietf-calsify] Re: What's wrong with more radical simplification?

[Reinhold Kainhofer]

On Friday 11 February 2005 18:04, Helge Hess wrote:
> On Feb 11, 2005, at 17:33, Michiel van Leeuwen wrote:
> > Helge Hess wrote:
> >> If you have some standard you basically always loose information
> >> since you need to find a viable common denominator.

I would argue to the contrary. What I like so much about iCalendar is that it 
defines a way to do almost anything you might ever want to do. So when you 
implement a new feature in your calendar application, most of the time, 
iCalendar already gives you a format how to store this feature in an 
iCalendar object (for drag'n'drop, invitations, even storing). So you don't 
have to cook your own soup, but instead can use a standard which other 
clients (that implement a similar feature) can also understand.

I think it basically boils down to the two views of standards:
1) A standard should describe what every application MUST implement. If an 
application wants to do something more, it's on its own. ("lowest common 
denominator")
2) A standard gives a suggestion how an application might implement any (even 
very exotic) feature. No application will ever implement full support for 
every little detail of such a standard, but if it implements one feature, it 
can be sure that any other application that implements a similar feature will 
be able to reuse the data.

it seems most people here think that a standard is just for those parts that 
every application must implement (i.e. every detail of a standard needs to be 
supported by an application). 
However, what I like so much about iCalendar is that it gives you a 
standardized way for lots of advanced features. 


> You have the assumption that fixing the clients is an easy and viable
> task. I had the impression that currently rrules can represent every
> recurrence model which was supported by the initial protocol creators.

I think it was meant to be able to describe every possible combination one 
might ever need. Anything else wouldn't make sense, because again it would 
lead to fragmentation, since one would need to invent a new solution if an 
application has needs that are not covered by a limited standard. And then 
one can be sure that interoperaility between two applications that both 
support such an advanced feature will never work.


> This in turn makes it very complex and forces everyone to implement all
> the rrules of the others (and in practice nobody does that which makes
> rrules not interoperable).
> But people suggested that I might be wrong on how compliant current
> clients are. Do Outlook, Kontact, Evolution, Mozilla, iCal.app really
> support 100% of the currently specified iCalendar rrules? 

No, at least korganizer / kontact doesn't. AFAICR, BYSETPOS is not correctly 
handled. The GUI of korganizer or kontact might not suggest it, but our 
libkcal library does in fact support almost the whole specification.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/7bc4c12b/attachment.bin