<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 10, 2010, at 12:39 PM, Phillip Hallam-Baker wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Fri, Sep 10, 2010 at 10:48 AM, <span dir="ltr"><<a href="mailto:ned%2Bietf@mauve.mrochek.com">ned+ietf@mauve.mrochek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>Even if XML-specific tools like stylesheets prove less than useful in<br>
performing manipulations of calendar data, there's still significant benefit<br>
associated with being able to use built in parsing capbilities, espcially when<br>
those capabilites are nicely tied to automatic creation of complex data<br>
stuctures in various languages.<br></blockquote></div><div><br></div>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.</blockquote><div><br></div>I, at least, understand that. But in my experience the backing data classes generally end up being ridiculously baroque.</div><div><br></div><div><blockquote type="cite"><div>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.</div><div><br></div><div><br>
</div><div>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.</div></blockquote><div><br></div>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.</div><div><br></div><div><blockquote type="cite"><div>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.</div></blockquote><div><br></div>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).</div><div><br><blockquote type="cite">
<div>So what takes me no time at all with XML is likely to take a couple of days and considerably more skill with EBNF.</div></blockquote><br></div><div>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.</div><div><br></div><div>(not that any of the above has much to do with iCalendar, since the data model there is already largely determined.)</div><div><br></div>Keith<div><br></div></body></html>