Subject: RE: XML and CAP discussion

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Fri, 12 Mar 1999 18:49:49 -0800

I worked a while ago on a list of reasons why I'd like to see XML more
broadly used for calendar access, espeically if co-exists in some manner
with iCalendar.  This email includes and expands that list:
 
 - Thin clients (PDAs, cell phones, etc) should not have to support many
data formats.  Since XML is becoming so common, we can take advantage of the
XML parser that will already likely be on thin clients, and not force them
to support another format.  XML parsers are also lightweight.
 
 - Extensibility. XML is designed to be extensible.  So is iCalendar, but
the way that iCalendar does extensibility is more limited.  Experience has
shown that using "x-" doesn't prevent collisions.  XML namespaces should
help greatly there.
 
 - Searchability.  XML is designed to support searches like "author is
Winston Churchill", which is much more specific than "contains Winston
Churchill".  XML search engines should also become pretty common.
 
 - Structure.  XML is very good for data that has structure.  It's easy to
tell where each part of the structure begins and ends. It's also easy to
embed one XML structure (e.g. for an ACL) inside another XML structure (e.g.
for a calendar object)  An applicable example, where acl stands for "access
control list" and ace stands for "access control entry":
   <acl>
    <ace>
      <grant/>
      <principal> [email-masked] <mailto:[email-masked]>
</principal>
      <right>write</right>
      <properties>
        <property>author</property>
        <property>dtstart</property>
        <property>dtend</property>
    </properties>
    </ace>
    <ace>
      etc.
    </ace>
  </acl>
 
 - Easily combined with other standards.  Many of the e-commerce and
information exchange groups (e.g. ICE, OFX, EDI) are already using XML.  If
we have an XML format, then combination is possible -- e.g. information on
how to order concert tickets online can be embedded in the same XML document
that has the start time, end time and location of the concert.
 
 - XML has data typing and language support that meets or exceeds the
support of iCalendar.
 
 - Encoding support -- XML can be encoded in several ways, such as UTF-8.
 
 - Easy to display XML.  Clients already exist that can take random XML
documents and display them nicely, parsing data types and presenting types
such as dates in a friendly format.  XSL (Extensible Style Language) can
optionally be used to transform XML-based data into HTML or another
presentation format.  Some web browsers already support XSL.
 
I'd also like to add another possible scenario to your list, Bruce: 
 
#4:  We design CAP to use existing iCalendar for representing calendar
objects, and we may allow negotiation to also retrieve XML-formatted
calendar objects through CAP, but whenever CAP requires new formatting (i.e.
how are search requests presented, how are ACLs formatted), we use XML.
 
It's not that iCalendar is broke -- it's a good standard -- but the world of
data on-the-wire is changing, and we can take account of it sooner or
later.  I'd like to take the long-term view.
 
Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 08, 1999 8:24 AM
To: Doug Royer; [email-masked]
Subject: Re: XML and CAP discussion

Doug replied: 
>Its is NOT early in the race. The iCalendar objects are already an RFC,
>as in iTIP, and iMIP. There are already products shipping using
>implementations based on the RFC's. We can't just abandon them.

  Hear, hear!  Ive been swapped out on other business for the past 2 months
so Ive only lurked at best.  With the current amount of time, sweat,
frequent flyer miles and maybe even blood invested in gettting to RFC status
w/iCalendar, iTIP and iMIP we are not 'early' in any thing.  I havent heard
the CAP editors arguments for/against this mid-stream switch/change so Ill
just state my own views. 

  I wont buy any argument that XML is a standard and that iCalendar is not
(or is not as good).  W/all the cycles that has been collectively put into
getting iCalendar to RFC (but not XML that Ive seen), that wont hold water. 

  If there is a proposal afoot to create some XML DTD that can co-represent
iCalendar data/intent then a few options open up. 

1: Leave it for later and just focus on iCalendar based CAP. 
2: Consider how to tweak/extend the architecture to allow multiple content
based C&S (ie: mixed or negotiated use of iCal and XML) 
3: Build CAP such that it obsoletes iCalendar (eventually) in favor of XML. 

There could be a few other flavors of options but Id need more caffine to
clearly deliniate them.  In any case, as the CAP effort is going to take
some time to complete (IMHO), I think that either 1 or 2 is a better choice.
 #3 is much like saying that we want to create some new SGML-like language
to replace HTML so that we can be 'standard'.  (After all both iCal and HTML
are RFCs but the new stuff isnt).  This option is not as desireable as a
vendor since I want to get a product done and out to customers before I
retire.  If we can build what the customers want w/the current resources
(RFCs) then lets do it.  If we think that the current resources are
indadequate then what will it take to get the foundation we need? 

Pat asked: 
>There is a proposal on the table to have an
>addendum added to the document that show how to implement CAP using XML.
>However, it would be with the understanding that the underlying MUST syntax
>would be ICAL-based.  Then, once the draft was submitted, CAP version 2
>would be started and the direction for that draft would be towards XML,
>which by that time has had time to evolve itself. 

  I was with you up until that last line.  Perhaps if you or the pro-XML CAP
Editors could explain why iCalendar is insufficient for our needs it may
help me (and others) make up their minds...  (Im still taking the KISS and
'If it ain't broke, why fix it?' line of thinking so make it good!) 

Bruce 
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Sat, 13 Mar 1999 14:06:29 +0000

"Lisa Lippert (Dusseault) (Exchange)" wrote:

> - Thin clients (PDAs, cell phones, etc) should not have to support
> many data formats.

Yah, but, since we can't afford to throw out the existing iCalendar
format, there is no way they're going to get out of it.

> Extensibility. XML is designed to be extensible.  So is iCalendar, but
> the way that iCalendar does extensibility is more limited.  Experience
> has shown that using "x-" doesn't prevent collisions.

Only because past x- conventions don't divide up the namespace after the
x-.  If we adopt a Java-like convention ("extensions defined by the
owner of example.com start with x-com-example-"), then we're OK.

> Searchability.  XML is designed to support searches like "author is

Irrelevant--in pretty much any real app, the searches are going to be
done on a database backend.

> XML is very good for data that has structure.

I will agree with this one.

> Easily combined with other standards.  Many of the e-commerce and
> information exchange groups (e.g. ICE, OFX, EDI) are already using
> XML.  If we have an XML format, then combination is possible -- e.g.
> information on how to order concert tickets online can be embedded in
> the same XML document that has the start time, end time and location
> of the concert.

MIME multipart.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/