Subject: Re: XML DTD update proposition

From: [email-masked]
Date: Wed, 5 Jan 2000 21:21:02 -0500

Michael:
You are missing the point. 
There are already well defined iCalendar data types. We don't need to 
redefine these. 
Creating a more structured on the wire format, that takes more bandwidth 
(both on the wire and to parse), when the originator and recipient already 
understand the IETF standard iCalendar semantics makes not sense.
Unless you are interested in defining a new XML application for 
calendaring.
Which we are not. We already have a single standard for representing 
calendar information and scheduling semantics. Let's leverage it.
-- Frank

---

From: Paul Hill <[email-masked]>
Date: Thu, 06 Jan 2000 11:41:09 -0700

[email-masked] wrote:
> Creating a more structured on the wire format, that takes more bandwidth (both 
> on the wire and to parse), when the originator and recipient already understand
> the IETF standard iCalendar semantics makes not sense.

Yes, a more wordy, more structured format has the disadvantage that it does 
take more space to store and transmit. I would think that the time and 
space it takes to parse would be comparable.  The advantage is that
these apparently excessive markings helps apps that never have heard of
iCalendar to deal with calendar information.

> Unless you are interested in defining a new XML application for calendaring.

While iCalendar is more optimized for communication between
general purpose calendar user agents and between calendar systems,
the advantage of defining a translation to an alternate, but more 
general (yet verbose) XML compliant format, is that this alternate format
can be used where applicable to solve _additional_ problems outside of
'normal' calendaring. It is the potential to work with the data elsewhere that
drives a desire for an XML form of iCalendar. XML applications
parsing libraries, books etc. already exist and are being written as we speak, 
all they need is a DTD to drive them.  These include XML aware browsers,
XML viewers, multiple general purpose parsing libraries (each with a different
power), XML utilities, and maybe even XML editors.

The simplest gain might come from the use of the power and features
of the existing general purpose applications that could be leverage by
having a well-defined and detailed as possible XML mapping.

A second and potentially larger gain might come from the the
creation of additional tools, utilities, calendar agents, by anyone 
who understands and uses the more general purpose XML/DTD formats, because
this larger community could create other uses for calendar data.

An incidental, but more immediate gain, for the iCalendar standard 
and its users is that the technical problem of converting between two well 
defined detailed forms helps to identify any ambiguity which exists in the
interpretation of either form.

-Paul
----
Myriad Genetics: http://www.myriad.com/
Java FAQ: http://www.afu.com/javafaq.html (Section 9, Computer Dating)