Registration of media type application/calendar+xml

[Julian Reschke]

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