[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which "Standard"?



At 08:58 AM 4/1/97 -0800, you wrote:
>At 8:29 AM -0800 4/1/97, Alan Johnson wrote:
>>So, as a developer, which specification should we be developing for?
>
>It's up to you, but I would say "both". vCalendar exists today, and you can
>have interoperability with any company that has already implemented it.
>iCalendar is coming, but is of course still in flux because things might
>change in the spec.
>
>When iCalendar is finished, vCalendar 2.0 will become iCalendar. However,
>it is not clear when that will be. For now, vCalendar 1.0 is a solid,
>stable base to work from, and it appears that it will not be all that hard
>to convert from vCalendar 1.0 to 2.0.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>

"Both" was the expected answer, frankly. And while true, converting between
1.0 and 2.0 doesn't seem all that difficult now, we do not know what lies
ahead in the iCalendar spec. Fundamental properties, such as RRULE and
XRULE, should not be changing except for adding and modifying to meet
needs. The basic grammar should remain consistent between versions for
backward compatible purposes.

Trying to shoehorn in code to handle both possiblities in limited space,
such as PDAs, defeats an interchange format's purpose in life: to guarantee
interoperability. One would expect a 2.0 reader/writer to be able to deal
with 1.0 files as well instead of having to translate into a 2.0 compatible
format.

If such things as an existing property's basic grammar changes such that
previous versions are no longer compatible and must be dealt with in a new
fashion, then there is hardly an incentive to support previous versions
thus limiting interchangeability.

While I realize that any spec must change to meet growing and/or unexpected
needs, basic grammar should not be changing between versions. This just
screams out to developers that supporting 1.0 is not the correct thing to
do and is not a strategic direction.

vCalendar is an excellent spec and I would hate to see this initiative die
out. But if future versions cannot be more backward compatible, there will
be less developers that are inclined to support such a moving target.