Subject: Re: XML DTD update proposition

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

Paul Hill replied:

>[email-masked] wrote:
>> We are also not assuming the XML iCalendar object would be parsed by a 
validating parser.

>I believe you can always feed an XML document that is highly
>specified by some (external) DTD into a non-validating parser regardless 
of how
>specified it is.

Of course. This will be the most common case. Few implementations will use 
a validating parser. 
The argument was being made to ignore the standard iCalendar data types 
and recast data types such as RECUR into elaborate XML data structures or 
spreadout over half a dozen attributes. The argument being that one should 
take advantage of the capabilities of an XML parser for structuring data.
My counter argument was that we had well defined, standardized data types 
in the iCalendar specification that any conforming implementation of RFC 
2445 would already be able to parse _and_ the fact that validating parsers 
(that could validate the more complex structuring against the DTD) would 
not be used be used by most implemenations.

---

From: Michael Krivoruchko <[email-masked]>
Date: Thu, 06 Jan 2000 16:44:31 +0000

Frank:

> You are missing the point.
>

Yes, I definitely do!

> 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.
>

I can not see a reason to use XML if those documents are readable only for tools
which know about iCalendar data types. The iCalendar tool can always read
RFC2445-document so it needs not "optional"(draft-many-ical-xmldoc-01.txt
p 2.3.2) XML.

> 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.
>

It sounds like you are ready to discuss cosmetic details of the document cover,
but you would not discuss the concept of the document.
I am not interested in "a new XML application for calendaring". Only things I am
talking about are more detailed XML representation of the data types defined in
RFC2445 and XML grammar which more adequate to grammar defined in the
same RFC2445.

Michael

--
---------------------------------------------------------------
Michael Krivoruchko                 CDE Group, Sun Microsystems
    Bool House, East Point Business Park, Dublin 3, Ireland
Ph: +353 1 819 9272               E-mail: [email-masked]
---------------------------------------------------------------

---

From: Philippe Lesage <[email-masked]>
Date: Thu, 6 Jan 2000 08:58:33 -0800

I think there is basically a contracdiction in your conception of ICal xml : 

You assume that both originator and recipient are RFC2445 compliant. So why
do they use xml to exchange data ? They could just use the regular format.
So from this point of view  xml is totaly useless for calendaring aplication,
and it was a error to write a DTD draft for that.

My point of view is that the xml format can be used when just one of the
originator or recipient is not RFC2445 compliant. And if some data are
not visible at the xml level, the application has to parse the string a second
time. This is obviously the consequence of a bad xml translation. The RFC
grammar use a comma separated list for the bylist, it is straighforward to
convert this in xml by a list of tags.

> 
> Philippe:
> You aren't really serious.

What I wanted to make clear is that the xml visibility limit you are arbitrary
fixing at the datatype level can be fixed at any other level (calendar,
component or property). If you asume that the recipient can parse RFC2445
string format, why not sending him all the data into two <ICalendar> tags ?

Or if you choose the limit to be at the component level then the recipient
would get an xml structure <ICalendar> </ICalendar> containing some <event>,
<todo>, ... , tags . And each component tag would just contain the ICal string
defining the component. 
It is a correct xml embedding and works fine (I mean two RCF2445
compliant application can exchange data this way), but that's totaly pointless. 

> Certainly, there is quite a difference between 
> leveraging standard data types in iCalendar within the XML DTD. A PCDATA 
> content type for these is appropriate. But a PCDATA content type for the 
> whole of the iCalendar object is not an equal argument.
> You seem to be approaching this as a XML application design problem, 
> rather than just a remapping of iCalendar semantics into an alternate 
> syntax. The originator and recipient of these objects are presumed to be 
> iCalendar conformant subsystems.
> validating parser. This would be a huge implementation overhead for client 
> environments. The only requirement that seems reasonable is that the XML 
> iCalendar object be well-formed, but not even a valid XML entity. That is, 
> there may not be a XML declaration or prolog/epilog in the entity.
> -- Frank

---

From: [email-masked]
Date: Fri, 7 Jan 2000 11:47:09 -0500

Michael:
I agree with you (and so has the mailing list) that the alternative XML 
representation for standard iCalendar doesn't make much sense, since 
conformant iCalendar products will understand the standard format. After 
all, multiple representations will present interoperability problems. We 
may want to take this to a XML iCalendar mailing list. I can ask IMC if 
they would host this.
However, the market hype around XML hasn't dissipated it's fervor, either.
This led a number of folks (myself, Doug Royer and Surendra Reddy) to 
craft the XML iCalendar DTD I-D. However, given the rabid interest in XML 
we put down some design principles to this work. 
Some of the recent discussion has crossed some of these principles, 
including the idea to redefine the basic iCalendar data types.
This just doesn't make sense. No one would think about redefining in XML 
the RFC822 address data type (i.e., "MAILTO:" local part "@" domain part). 
After all this is a part of an IETF standard. Like wise, it doesn't make 
much sense to create new formats for already existing proposed standards 
for iCalendar data model components.
See what I mean?
-- Frank

---

From: [email-masked]
Date: Mon, 10 Jan 2000 09:27:35 -0500

Philippe Lesage wrote in part:
>As Paul & Michael explained it better than me, other non iCalendar 
application
>might need to exchange data with a XML compliant calendaring server. So
>it is really a problem for them if they can't see the RECUR datatype 
internal
>structure for example. The XML representation is for me usefull is only 
one
>case : exchange with non ICal application.

This argument is very faulted. If we generalize your argument, then you 
say that you don't accept any data type unless your DTD defines it. After 
all, you don't seem to like accepting the iCalendar RECUR data type as a 
PCDATA entity. Extending this argument, you are telling me that you 
couldn't accept any other standard data types passed in a PCDATA element 
type's content information. I just don't buy this line of reasoning. In 
fact, there are many efforts underway to standardize schema and data types 
that would be passed in PCDATA content model, but that if you support 
these standard types your application would have to have secondary parsers 
for.
Well, for calendaring and scheduling information, iCalendar is the 
standard. It defines about a dozen data types that are used in the 
iCalendar model. It only makes sense to leverage the large investment made 
by the IETF CALSCH WG in any XML DTD for C&S also rather than arbitrarily 
defining new data types that strike the fancy of the new DTD designer.
I think that this on redefinition of data types is complete. The consensus 
of the WG was (in past discussions) to leverage as much of iCalendar as 
possible to create the iCalendar XML DTD. You haven't raised any new 
arguments.
Thanks for the open discussion but lets keep the use of the standard 
iCalendar data types. The date/time datums are also based on ISO standards 
for date and time that are being adopted across the industry, albeit the 
more terse "basic" format of ISO 8601.
Some of your other comments for improving the DTD are valid and will be 
incorporated.
-- Frank