Subject: RE: Accelerated CAP (draft-2)

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Wed, 16 Sep 1998 15:04:44 -0700 (PDT)

> From: "Surendra Reddy" <[email-masked]>
> ...
> 
> Having said these, I would like to see how many in this group are strongly
> opposing XML and if so, Can I ask them to give 5 good reasons how current
> iCalendar model is better than  XML  Model or why they oppose XML?

Its not that I am not opposed to the idea that iCalendar objects could
be representable as XML objects (I do not really know XML well).

The problem is that they are not currently XML objects.

So rather than throw away the iCalendar, iTIP, and iMIP documents.
Why don't we finish with the iCalendar-ish container work.

Aside from the container format - we still need to define objects
for ACLs and properties. We need to define search/query and
administration - independent of the container format used
to transport the data.

For now I am taking your and Lisa's word for it that XML is a
good thing. After all of the objects and operations are defined
with the existing container - I would have no objection to an XML-CALSCH
container mapping standard.

The only reason that I would be in favor of an iCalendar-ish
container in CAP - is because that is what it already *is*.

I think that at this point in time an XML container would only
slow down the unresolved container independent issues.

> Regards,
> Surendra Reddy
> (650) 506 5441

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/dougr.html
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: "Frank Dawson" <[email-masked]>
Date: Fri, 18 Sep 1998 11:11:37 -0400

Surendra:

What is the open trading group going to do about an EDI "package"? How will
you group an EDI tranaction, as is done today in the real world, with
different document types in one container? XML doesn't define an equivalent
of "SDIF"? Both EDIFACT UN Messages and X12 documents are based on the idea
of "containerizing" a group of EDI business documents.

This is one of the current shortcomings of a "pure" XML solution.

- - Frank

---

From: "Frank Dawson" <[email-masked]>
Date: Fri, 18 Sep 1998 10:52:33 -0400

Surendra:

IMNSHO XML is a prime candidate for encoding new objects. However, if we
already have a syntax that has industry standardization, re-encoding into
XML can be counter-productive.

XML is certainly getting alot of attention in the industry's trade press.
However, most of this press writing is of a very high level and does not
focus on some disturbing aspects within the XML space.

The prime benefit of XML over any other syntax is the support for strong
data integrity provided by the XML document type definition (DTD). However,
within the W3C, the DTD structure is under attack. There is a very strong
likelihood that the DTD will be replaced by a mechanism that weakens the
data integrity checking to only a name-space element check. Hence, we will
loose the capability to understand if the iCalendar semantics are being
compromised.

The SCAP DTD effort may not have uncovered this, as that DTD was very
primitive and did not provide for the complete functionality of iCalendar.
You may want to look at the vCard DTD draft. It provides for some of the
important design concepts that are also in the current iCalendar format.

A second BIG worry is that many of the XML parsers are non-validating
parsers. Without DTD validation, we have lost the primary benefit of XML...
data integrity checking. You will have an idea of the correctness of the
formation of elements/tags, but will not have any idea whether these tags
are placed in their appropriate sequencing in an "iCalendar" document type.
This is a big hit against blind adoption of XML.

A third worry is that XML does not lend itself to mapping into a backend
relational style database. This is a current point of discussion in the
industry. The "rows of columns" architecture of a relational database
presents problems with dealing with the hierarchical form of an XML DTD.
Well...maybe this is why some within the W3C is trying to gut the DTD
structure! Of course, as noted this is also gutting the primary benefit of
XML.

And lastly, you can't get around dealing with the MIME encoding anyway. XML
does not define the "SDIF" equivalent for bundling together (ala a ZIP file)
all of the XML entities you need to convey a "real world" application
document, such as a calendar. The most practical solution for this is a MIME
multipart content type/container. However, then you will have to place the
XML entities in a text/mxl content type. My simple study of the text/xml
content type left me wondering how I was going to find out what kind of
application processing I was going to need to handle the XML content type
without first opening and parsing with a validating parser the XML content.
This is a further step backwards from our current text/calendar specificity
we have with the iCalendar content type.

Naw, I think that Doug's proposal to use iCalendar for the initial, year-end
draft of CAP makes sense; given that we don't even know where the XML train
is leading us.

It looks like an application you define today with XML v1.0 will not work
with what comes out of the W3C for future version of XML. Very ugly risk for
application developers.

- - Frank