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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf