On Sep 10, 2010, at 12:39 PM, Phillip Hallam-Baker wrote:
On Fri, Sep 10, 2010 at 10:48 AM,
<ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com> wrote:
Even if XML-specific tools like stylesheets prove less than useful in
performing manipulations of calendar data, there's still significant benefit
associated with being able to use built in parsing capbilities, espcially when
those capabilites are nicely tied to automatic creation of complex data
stuctures in various languages.
What many XML-haters do not understand is that the syntax is designed to
completely automate the process of writing the parser and the backing data
classes.
I, at least, understand that. But in my experience the backing data classes
generally end up being ridiculously baroque.
Starting with an XML Schema definition I can generate the corresponding data
structures automatically with one mouse click together with the corresponding
parser/serializer calls.
Starting from an EBNF description, I have to first read the description. This
has already taken more time than working with the XML version would.
Really you should be able to generate the parser from the *BNF. But you're of
course correct that it won't generate the data structures for you. All you
get is a state machine that recognizes the language.
I then have to work out if the grammar is an FSM or LR(1) or something else.
When I was a grad student I used to write yacc parsers but these days I have
written enough parser generators that I can actually hand code quicker than
it takes me working round the peculiarities of yacc.
Biggest problem I had with using yacc based parsers was doing good error
recovery, because people would inevitably generate data representations that
didn't quite fit the grammar. But XML parsers tend to not be much better at
that than yacc is. With both XML and yacc, either the entire message is
recognized or it isn't, unless you do a fair bit of work (often redefining the
language in the process).
So what takes me no time at all with XML is likely to take a couple of days
and considerably more skill with EBNF.
Granted. But surprisingly, this actually comes at a cost. When every protocol
had its own syntax for representing data, there was pressure to keep the data
models from getting too complex. With XML, people are free to make the data
models as complex as they want - and often, this means that the data models are
not well thought out. That's not to say that having a standard, uniform
presentation syntax which translates readily to and from an internal data
structure is a bad thing. (Even if I don't like XML specifically, I think the
underlying goal is sound.) What it means is that protocol designers and data
model designers still need to exercise discipline to keep their data models
simple.
(not that any of the above has much to do with iCalendar, since the data model
there is already largely determined.)
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf