Re: Last Call: <draft-daboo-et-al-icalendar-in-xml-08.txt> (xCal: The XML format for iCalendar) to Proposed Standard

Mike Douglass <douglm@rpi.edu> Thu, 14 April 2011 19:36 UTC

Return-Path: <douglm@rpi.edu>
X-Original-To: ietf@ietfc.amsl.com
Delivered-To: ietf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 365A7E076D for <ietf@ietfc.amsl.com>; Thu, 14 Apr 2011 12:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R27RAjKem-Jy for <ietf@ietfc.amsl.com>; Thu, 14 Apr 2011 12:36:39 -0700 (PDT)
Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by ietfc.amsl.com (Postfix) with ESMTP id C05EFE074A for <Ietf@ietf.org>; Thu, 14 Apr 2011 12:36:35 -0700 (PDT)
Received: from [128.113.124.225] (blue-eyes-white-dragon-17.dynamic2.rpi.edu [128.113.124.225]) (authenticated bits=0) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id p3EJaXCV028312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <Ietf@ietf.org>; Thu, 14 Apr 2011 15:36:33 -0400
Message-ID: <4DA74CC1.2030205@rpi.edu>
Date: Thu, 14 Apr 2011 15:36:33 -0400
From: Mike Douglass <douglm@rpi.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Ietf@ietf.org
Subject: Re: Last Call: <draft-daboo-et-al-icalendar-in-xml-08.txt> (xCal: The XML format for iCalendar) to Proposed Standard
References: <4DA7488F.5040608@rpi.edu>
In-Reply-To: <4DA7488F.5040608@rpi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-RPI-SA-Score: 1.40 (*) [Hold at 10.00] RATWARE_GECKO_BUILD,22490(-25)
X-CanItPRO-Stream: outgoing
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 19:36:40 -0000

On 04/14/2011 03:18 PM, Keith Moore wrote:
> I appreciate that great pains have been taken to ensure that this 
> format is a dual of the standard iCalendar format, that translation 
> can be performed in both directions without loss, and that at least 
> some attempt has been made to specify the conversion algorithms in 
> such a way that (if carefully implemented) they should continue to 
> work with extensions to iCalendar.
>
> I think it's confusing that many elements are referred to using an 
> ICAL: prefix, when (a) the xml examples don't actually associate that 
> prefix with a namespace, and (b) when iCal is probably a trademark of 
> Apple.
>
> However (and I think it's been at least 10 years since this was first 
> proposed) I still find myself wondering, why is this format needed or 
> even useful?    Practically speaking, I think the adoption of this 
> format will only increase the burden on implementations and decrease 
> the likelihood of interoperability between implementations.  It will 
> increase the burden on implementations because now implementations 
> will need to be able to accept, and possibly generate, two different 
> calendar data formats instead of one.
>
> It will decrease interoperability because there will certainly be some 
> attempts to send xCalendar data created by new implementations, to old 
> implementations that only accept iCalendar data.  It will also 
> decrease interoperability because, inevitably, some implementations of 
> the conversion routines will fail to be sufficiently general in order 
> to handle currently-undefined properties and components.   This is an 
> almost inherent consequence of the likely use of XML schema 
> description languages that explicitly enumerate element names, and 
> processing languages that associate explicit element names with 
> processing actions.   Finally it will decrease interoperability 
> because it will no longer be the case that only producers and 
> consumers of iCalendar data have to interoperate - it will then be 
> necessary for producers, consumers, and converters to all interoperate 
> - thus introducing more opportunities for both implementation bugs and 
> version skew to create problems.
>
In many situations XML is the only acceptable data format. The work 
going on for the SmartGrid has made that clear to us. Far from 
decreasing interoperability this work will help keep the work done in 
XML based environments in line with that in the rest of the calendaring 
world.

It is already the case that other data formats are in use - we're not 
going to prevent that. The best we can do is to try to provide 
standardised approaches to conversion and data formats.
> I also get the impression that the mapping of "values" or data types 
> (section 3.6) between iCalendar and XML is not sufficiently general to 
> permit continued interoperability across extensions.
>
> I think that adoption of this format will in practice require that (a) 
> any extensions to iCalendar to also explicitly specify how they are 
> mapped into xCalendar, and (b) every, or nearly every, 
> iCalendar<>xCalendar conversion product to be updated every time there 
> is an extension to the iCalendar format.
In the JAXB and SOAP worlds at least this is not an issue. By default 
those environments ignore elements they are not aware of. That's fine as 
schemas can be updated when it is important to handle these extensions. 
An iCalendar XML schema is being developed for use in those environments 
and already does a reasonable job of handling extensions. We're aware of 
the problems posed by extensibility (as is most of the enterprise XML 
world) and are developing ways of mitigating them.

>
> I also suspect that converting the format to XML will encourage ad hoc 
> extensions to xCalendar which might not map well to iCalendar - since 
> the constraints and extension model of iCalendar will not be obvious 
> to the typical XML code developer.
>
> Use of the "XML" property in iCalendar implies that the conversion 
> routine needs to know which properties are "already" defined in 
> iCalendar, which either implies that iCalendar cannot be extended, or 
> that different converters (knowledgable about different versions of 
> iCalendar) will produce different results (some mapping unknown 
> properties to the iCalendar XML property, and some mapping them to 
> native iCalendar properties).
>
> Correct conversion from iCalendar to XML appears to require the 
> converter to know about the types of each of the properties even 
> though these are not explicitly specified in the source iCalendar 
> document.   This is problematic if new properties are defined for 
> iCalendar, as old converters won't know about the types of those 
> properties.
>
> So, in summary, I still don't think this is worth the trouble.   
> Regardless of the application, providing multiple ways to represent 
> the same information generally seems to degrade interoperability.
>
> Keith
>
It's worth remembering that the initial motivation for this 
specification was not to promote the use of XML but in response to the 
already widespread use of differing and incompatible XML forms of 
calendar data.

-- 

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180