Subject: [Ietf-calsify] another thought for simplification / levels

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Mon Dec 20 18:47:55 2004

XML does bring some advantages to the table that frankly, ought to be
considered for any new standard - the first and most significant, I
think, is that no new parsers need to be written.  Or at least, the
number of encoding and parsing errors that are likely to occur are
significantly decreased.  Internationalization is comparitively easy,
and no low-level description of the format would need be discussed. One
can focus on the schema instead.

Your suggestion that there exists support for XML in existing
applications is fair, but be wary about overcommitting libraries that
you are not intimately familiar with.  I suspect that there are several
XML parsers within many large codebases, but I cannot say whether any of
them are of sufficient or desirable to use in these circumstances.
Obviously it behooves vendors to develop good low-level support for
parsing XML, and it may very well be arguably good to push them in that
direction anyway.  Assuming they are there already might be bolder than
you think.

In general, I like your idea, but I think it is most meaningful for new
standards, and I see your suggestion as a new standard:  xCalendar
perhaps.  This might be very compelling especially for calendar
publishing software that could also provide transforms for these types
of data and thereby provide glowing chrome to navigate a .xcal on a web
site, for example. icalshare.com or icalx.com might both decide to do
some cool fancy things with that, especially if a vendor or two adopted
it.  My suspicion is that only some compelling new features would bring
vendors to the state of wanting to.  (e.g. support for
mime-type-specified bodies <DESCRIPTION
TYPE="text/xhtml">....</DESCRIPTION>, non-gregorian recurrences <RRULE
TYPE="lunar">...</RRULE> and the like)

Back to the current state of affairs, I believe the calsify endeavor is
to add nothing to the existing standard, but only to simplify it to the
point of standard-application-usability and interoperability.  I suggest
that a new and separate endeavor should pursue the xml-ified variation.

That's my take...

++cam;

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, December 20, 2004 6:09 PM
To: [email-masked]
Cc: Jonathan Boarman
Subject: [Ietf-calsify] another thought for simplification / levels

This idea was inspired by someone who asked about my XML-with-calendar
guideline draft; I'm posting it here because I think this may be the
most appropriate place to begin this discussion.

We've had some discussion about having various levels of iCalendar to
allow simplification. This would of course require a mechanism that
allowed one to know what levels were supported by sender and receiver.
There are also quite a few people that are thinking about and working on
events/scheduling information in XML - which makes sense because of the
large number of XML tools available to developers and its growing use as
an interchange mechanism. This has prompted me to think that perhaps the
"simplified" version of iCalendar ought to be an XML version instead? 

There are several advantages to this idea in my opinion:

	1. We could use XML to group things from different levels
together (this is just an example)
	    <vcalendar>
	      <vevent>
	        <basic-event-info>
	          (whatever we decide level 0 stuff is goes here)
	         </basic-event-info>
	         <extended-stuff>
	           (more advanced items go here)
	         </extended-stuff>
	      </vevent>
	    </vcalendar>

	2. XML allows developers to use namespaces for extensions and
additions
	3. XML tools are prevalent in many development packages and
databases systems, easing development
	4. XML is understood at some level by many more developers 
	5. We can always "down-convert" an XML representation to
iCalendar through XSLT
	6. For events calendars and the like: the structure of XML would
make it easier to create search tools for events

There of course will be negatives - one of which is the addition of code
to existing products that support iCalendar, to also support the new
XML-based format. My instincts tell me that many of these products
already support XML  in some ways, so  that much of the software
infrastructure to support XML is already there (for example, MS Office
supports XML for quite a few things now); but I am not a software
vendor, so take that with a grain of salt unless vendor representatives
on this list would care to comment.

I posting this a discussion-generator. This being the holidays,  I don't
expect a lot of discussion right at the moment, but please, let's kick
this one around for a bit.

Tim Hare
Interested Bystander, Non-Inc. 
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Dec 20 19:18:44 2004

>that a new and separate endeavor should pursue the xml-ified variation.
Yes, I completely agree, we have to solve the problem  of what is in the 
basic and
extended objects regardless of XML or iCal format.

And as I have been told many times by the IESG, they will not allow an 
XML-iCal
that is not compatible with 2445 formats.  We can not throw away existing
implementations, we have to first clarify existing standards.  Then we can
extend iCal. And iCal or XML format will not matter until that is solved.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041220/1656dc40/smime-0001.bin