Re: Registration of media type application/calendar+xml

ned+ietf@mauve.mrochek.com Fri, 10 September 2010 17:39 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
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 5CB143A6A6B for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 10:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599]
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 ayyq6bAQC-mY for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 10:39:22 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 11D7A3A6A62 for <IETF@IETF.ORG>; Fri, 10 Sep 2010 10:39:04 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NRPZ7IZM9S004QHZ@mauve.mrochek.com> for IETF@IETF.ORG; Fri, 10 Sep 2010 10:39:29 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NRM5YC121S003JZ5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for IETF@IETF.ORG; Fri, 10 Sep 2010 10:39:22 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01NRPZ7G7HF8003JZ5@mauve.mrochek.com>
Date: Fri, 10 Sep 2010 10:12:15 -0700 (PDT)
Subject: Re: Registration of media type application/calendar+xml
In-reply-to: "Your message dated Fri, 10 Sep 2010 18:04:43 +0200" <4C8A571B.3070901@gmx.de>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu> <01NRP8H2AP2Y003JZ5@mauve.mrochek.com> <D07F8B0F-3157-47BF-8F8E-38A7B4C7A34E@cs.utk.edu> <01NRPV1K1YAM003JZ5@mauve.mrochek.com> <4C8A571B.3070901@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1284139195; i=@mrochek.com; bh=TZX05lMYymerjnMn2Ve5SqdyeemsZB5+lTG56G6wsYo=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=UoP9GL1HjVaDsDWaydPJXcn3dQailwaDpv7YKnfyS0XrE4NKaN8/LYl3OMfQdnrVy afYsRsjFCAA2IvzlumvPyhEM5csNwqgzYP4a7xHQtNbm7kGQ+Z9olXupetqjrdE5j/ 9wVl86BQhpxPuO60ieFA1097Naz3yP6/kswahdh8=
Cc: Ned Freed <ned.freed@mrochek.com>, Douglass Mike <douglm@rpi.edu>, "Cyrus Daboo \(cyrus@daboo.name\)" <cyrus@daboo.name>, Keith Moore <moore@cs.utk.edu>, 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 17:39:30 -0000

> On 10.09.2010 16:48, Ned Freed wrote:
> > ...
> > Unfortunately, now that I've had a chance to look at
> > draft-daboo-et-al-icalendar-in-xml-06.txt a little more, I find that it doesn't
> > do this well. For example, instead of mapping a property like dtstamp to
> > something like:
> >
> >      <property name="dtstart">
> >        <date-time>20080205T191224Z</date-time>
> >      </property>
> >
> > it maps it to:
> >
> >         <dtstamp><date-time>20080205T191224Z</date-time></dtstamp>
> >
> > This means that additional properties will necessitate a schema update. Not
> > good, and I believe this needs to be fixed.
> > ...

> Not really. How is adding a new allowed value to an XML attribute any
> different from adding a new element name (assuming a schema language
> than can express both constraints?).

First of all, there are many situations where you don't get to pick your schema
lannguage. (In fact I'd say it's the rule rather than the exception.) So even
there are Schema languages that support "any element can appear here" - the
fact that XML Schema doesn't allow this (xs:any has far too many restrictions
placed on it to be usefullly usable) means you shouldn't be defining things
this way.

Second, it is of course possible to impose restrictions on the values that can
appear in an attribute value (or element content for that matter). But just
because you can doesn't mean you should. And these sorts of mappings are
exactly the place where you shouldn't be doing this, at all, ever, because when
you do you end up having to change the schema for each extension that adds
properties (in the case of iCal) or actions/tests/controls (in the case of
Sieve).

Furthermore, in the case of Sieve at least, there are cases where it is
entirely valid to specify tests and actions in a script that the implementation
you're currently using doesn't support. For example:

    require "ihave";
    if ihave "ereject" { ereject "I hate this message"; }
    elsif ihave "reject" { reject "I still hate this message";}
    else { discard; }

or:

    require "ihave";
    if ihave "x-private-extension-nobody-else-has-heard-of" {
      if bletch "bar" "foo" { frob :zing "foo" 1 "bar";}
    }

If I've mapped actions and tests to elements here I'm screwed - there's no way
to make this work properly in XML Schema without either adding a ton of
superfluous bracketing elements all over the place (and we already have too
many of these), or creating a false distinction between extensions and base
elements that is, if anything, even uglier.

It's also easy to show that full script validity checking here requires solving
the satisfiability problem, which means its in NP. I'm pretty sure that exceeds
the capabilities of most schema languages ;-)

I believe similar issues exist in iCal and probably vCard.

				Ned