xml-dev - Re: Ambiguity in XML spec

["David Brownell" <david-b@pacbell.net>]

> >It's pretty common for language specs to ensure that their grammars
> >can easily be handled by parser generators -- commonly they'll be
> >done as LALR(1) [yacc/bison/...] or somesuch.
> 
> ...SGML/XML is highly
> context-sensitive when it comes to deciding whether a given character
> is a delimiter or not.

Right, I that's another way of looking at what I had called a
"layering" issue that a more formal treatment would have turned
up.  There's a curiously tricky sentence somewhere in the middle
of chapter 2 -- which says that PE handling for productions
before the sentence (notably, quoted strings) is different from
PE handling for subsequent ones.  To paraphrase your phrasing
below, that means that there are two separate BNF grammars
within the XML spec, on either side of that sentence...


> You end up with the equivalent of a half-dozen or so separate lexical
> analyzers, and at any given point during the parse you invoke one of
> them, according to context. It's all rather messy and you pretty much
> lose all of the benefits of a lex/yacc-style table-driven approach.

Those of us not deeply invested in the SGML history before XML
have been known to consider that a design bug in the spec (the
sort you want to see fixed before REC stage).  It's demonstrably
a characteristic that leads to other bugs.

And at any rate, my point was that the spec has only slowly been
accumulating details enough to let someone even build one of
those "half-dozen or so" lexical analysers, without needing to
refer to the SGML spec (much less to accept its words as truth
where the XML spec has been missing information).

In the best of all worlds, the "corrected" XML spec will at the
least clearly define all of the different contexts needed to
accomplish a correct parse, AND call out the fact that the sort
of parser construction tools taught in most university courses
accordingly aren't particularly effective.

- Dave



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************