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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf