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