Re: Registration of media type application/calendar+xml

[Keith Moore <[e-mail]>]

On Sep 10, 2010, at 6:11 AM, Julian Reschke wrote:

> 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?

Sigh.  Do I have to write the code to parse the XML and do something with it to show that it's tortured?

> As far as I can tell, the torture is more about having to parse what we have today.

Granted, iCalender is ugly.  But you still have to parse it if you want to interoperate with the installed base. 

> Yes, WS-* sucks. Big news.

I mention it because it's a good example of the "everything should be XML" disease, and a "2010s style" approach to the problem.  Things were better in the 1990s.

>> 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.

Give it time.  Of course, now that there is all of this XML to displace, it's hard for something new to get traction.

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

Fortunately, we don't need to.  iCalendar already exists, and is not XML.  There's no demonstrated need for a new type, whether in XML or any other syntax.

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

WIthout actually doing the exercise, yes I think so.  I don't recall much (if any) recursion in iCalendar.  Of course the real question is how easy it is to translate ABNF into code that uses regexps.  

(I do think it's ironic that we went to all of this trouble way back in the DRUMS WG to produce a new version of ABNF that would allow the syntax of something to be completely specified - without resorting to comments - and machine parseable.   And then we went to the trouble to rewrite a number of protocols using the new ABNF, accepting the pain and the possibility to introduce errors.   And now that we have it, we're not using it to generate parsers, and people are claiming that they need to use XML instead.  I suppose the one thing that XML adds here is that you don't have to design an internal data structure.  You can use the one that generates naturally from the XML even though it's likely to be very awkward to use.)

>> 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.

Fair enough - but I do think it's a good example of what happens when people insist that everything be XML.

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

And I'm not arguing that iCalendar is a well-designed syntax.   If we were building it today, I'd be okay with using XML (not because I like XML, but because it would be politically expedient, and the chances are good than an ad hoc format designed by a WG today would be no better).   My objection is to having two calendar formats.

> 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.

Yes, but you can get some of those things wrong (e.g. character encodings, and other differences between internal/external representation) internally to your program.

>> 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.

That's a consequence of the argument that 95% of formats should be XML.  Which was the justification for having an XML version of iCalendar.

Here's the argument in a nutshell: XML or no XML, a new iCalendar format should require substantial technical justification because of the harm it will do to interoperability.

Keith