Re: Registration of media type application/calendar+xml

Julian Reschke <julian.reschke@gmx.de> Fri, 10 September 2010 10:11 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CEC3A6359 for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 03:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.615
X-Spam-Level:
X-Spam-Status: No, score=-104.615 tagged_above=-999 required=5 tests=[AWL=-2.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5MpgXyReZYR for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 03:11:24 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id D7DFC3A6A39 for <IETF@ietf.org>; Fri, 10 Sep 2010 03:11:12 -0700 (PDT)
Received: (qmail invoked by alias); 10 Sep 2010 10:11:38 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.142]) [217.91.35.233] by mail.gmx.net (mp068) with SMTP; 10 Sep 2010 12:11:38 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+9KzA7gVO9P8jLUQZyPUjCnzjcj5OE87SjD+stWm sWClzUzqrTTA2j
Message-ID: <4C8A044F.1040603@gmx.de>
Date: Fri, 10 Sep 2010 12:11:27 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3
MIME-Version: 1.0
To: Keith Moore <moore@cs.utk.edu>
Subject: Re: Registration of media type application/calendar+xml
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu> <B0EA09C87A5701A94419DB8F@socrates.local> <673F57D3-B2EC-4ABF-B450-EEEA3A4C185A@cs.utk.edu> <AANLkTinon97N3njcAV=FUj7-_ZJugazVCuaVbySbXr_L@mail.gmail.com> <193EC4D4-1B6C-4B14-ACD7-3237517566F5@cs.utk.edu>
In-Reply-To: <193EC4D4-1B6C-4B14-ACD7-3237517566F5@cs.utk.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Douglass Mike <douglm@rpi.edu>, Phillip Hallam-Baker <hallam@gmail.com>, Cyrus Daboo <cyrus@daboo.name>, Alexey Melnikov <Alexey.Melnikov@isode.com>, ietf-types@iana.org, Steven Lees <Steven.Lees@microsoft.com>, IETF@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 10 Sep 2010 10:11:36 -0000

On 10.09.2010 07:09, Keith Moore wrote:
> On Sep 10, 2010, at 12:34 AM, Phillip Hallam-Baker wrote:
> ...
>> If you want to have a system in which 95% of your data structures are
>> in XML you probably don't want to have to introduce a separate syntax
>> and you most certainly do not want to deal with a separate data model
>> for dealing with calendaring.
>
> It's not at all clear that trying to coerce 95% of the data models in
> your system to be compatible with XML is a worthwhile goal. The XML data
> model is tortured. Trying to impose it on network protocols should be
> regarded as an act of violence.
> ...

That's *far* from clear. Could you elaborate in the context of 
calendaring? As far as I can tell, the torture is more about having to 
parse what we have today.

> At any rate, this proposal doesn't change the iCalendar data model - it
> just makes it harder to use. If you have a beef with the iCalendar data
> model, feel free to try to come up with a better one.

I disagree that it makes it harder to use, *unless* somebody wants to 
require support for this alternate format.

On the other hand, having an agreed-upon mapping from/to XML will make 
it easier for many developers. Well, at least those who don't have a 
problem with XML :-)

>> The iCalendar format represents a 1990s style approach to the problem.
>> There is no real separation of syntax from the data model. Software
>> developed in that manner is notoriously difficult to get right for the
>> reasons that Keith describes.
>
> XML has lots of problems of its own. I recently had to review a
> specification that referenced WS-i and WS-security and about a couple of
> thousand other pages of useless crap that went with it. All for the sake
> of being able to transmit about six meaningful name-value pairs from a
> client to a server. It was completely ridiculous.

Yes, WS-* sucks. Big news.

> I'm no fan of the iCalendar format, nor the vCard and vCalendar formats
> that preceded it. But for all of its purported generality (and perhaps
> because of it) XML has turned out to be no better, and in many ways
> worse. It's amazing how hard people will work to make a simple idea
> complex, especially when the simple idea has become a bandwagon, or (in
> this case) a religion.
>
> In principle, it would make sense for things to have a uniform syntax.
> But XML gets this wrong in several different ways. The most obvious is
> that XML data structures don't map well onto data structures supported
> by programming languages. That's probably because SGML wasn't designed
> to do that - it was designed to mark up text. Another problem is that
> XML confuses typing and naming. Another problem (especially when mapping
> other structures to/from XML) is that the distinction between parameters
> and sub-elements is pretty much arbitrary.

That may all be true. But strangely enough, there doesn't seem to be 
much energy to come up with something better *and* get people to agree 
on that.

Turning a type registration request into an to-XML-or-not-to thread 
doesn't appear to be productive to me.

>> XML is a substantial overhead if you are dealing with a single
>> protocol but when you are dealing with multiple protocols the benefits
>> are substantial and allow something like 70% of your coding effort to
>> be pushed onto the platform layer. That means that you have 70% less
>> new code and new code paths to contend with.
>
> If your programmer is spending 70% of his coding time dealing with a
> presentation layer, even one as convoluted as iCalendar, you should fire
> him. It's not like regular expression parsers are hard to come by these
> days. Nor are libraries that can parse standard formats hard to come by.

Can iCalendar be parsed reliably with regexps? (just asking).

> Another of the big problems with the XML religion is that its adherents
> have the mistaken impression that defining the syntax is most of the
> work of defining a protocol - so that once you decide to use XML, most
> of the work is done. Apparently, semantics don't matter much.

Another big problem with the anti-XML religion is that its adherents 
like to over-generalize, such as deducing badness of XML from 
WS-deathstar encounters.

Yes, there's lots of bad use of XML. The same can be said about other 
formats as well.

> ...
> It enforces consistency in syntax. Taken by itself, that's a good thing.
> But when you parse XML you don't get a very usable data structure. You
> get a mess. And once you do the work of transforming that data structure
> into an effective internal representation, you've negated whatever
> advantage you might have found in not having to have written a
> parser/generator for it. You haven't solved the problem of needing a
> parser and generator - you've just moved it. Instead of parsing text
> you're parsing a DOM structure. You've added an extra layer or two for
> no benefit.

The benefit is that the XML parser already has taken care of many things 
people get wrong all the time; character encodings, escaping, line 
endings etc.

> You're essentially arguing the syntax by which data is represented on
> the wire - the presentation layer - should constrain how data is
> represented internally in a system. And then you're arguing that the
> particular constraints imposed by XML are appropriate constraints.
> That's brain damage.

I don't think anybody argued that.

>> Now I would quite prefer to take about 50% or more of the XML spec and
>> discard it. They did a good job of taking out the most insane features
>> of SGML but there is much more cruft that could be cut out. But that
>> does not change the fact that using XML as is produces clearer
>> specifications that are more likely to be implemented without errors
>> than with the 1990s approach.
>>
> As is often the case, you're simply and utterly incorrect.

OK, enough :-)

Can we please switch to a discussion of the RFC publication format now?

Best regards, Julian