On Sep 10, 2010, at 12:34 AM, Phillip Hallam-Baker wrote:
> The objections raised by Keith do not appear to me to fall under any of the requirements for MIME type registration set out in RFC 4288.
I didn't claim that they did. I'm just taking the opportunity to ask that the proposal be voluntarily withdrawn.
> I disagree with the argument made in any case.
>
> 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.
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.
> 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.
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.
> 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.
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 problem with XML is that it makes data models so easy to extend (just add more element definitions) that people often don't take due care in defining their data models.
> One of the discoveries of the mid 1990s was that yacc and LR(1) grammars are no more useful for describing computer languages than they are for describing natural languages.
That's a ridiculous statement. (Okay, maybe strictly speaking LR(1) isn't quite enough, but it's close enough for most computer languages that you can usually make an LR(1) parser work.) Computer languages don't need the same kind of expressive power that natural languages have. Natural languages have to allow for a certain amount of ambiguity, but that's a liability in computer languages.
> The most useful feature of a computer grammar is regularity and consistency. XML enforces a high degree of consistency.
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.
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.
> 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.
Let's stamp out XML in our lifetime. Even FORTRAN deserves to live longer.
Keith
