Re: FW: XQuery: A.1.2 Lexical Rules

>     I have twice before ([1] and [2]) argued against this lexical
>     push-down automaton (PDA), and particularly against it being
>     made normative. I'm
>     still waiting to see a counter-argument.  I believe the only thing
>     that's been posted in its defense was this:
>         "The reason the PDA is valuable is because it works with
>          tools like JavaCC and Lex."

No, that was never the defense (or at least my defense).  It was that it
carried information beyond that the BNF specified.  But, read on...

>     This may well be true, but doesn't justify making it normative.

I'm beginning to see the light on this.

>     (1) The PDA has appeared 4 times, each time with mistakes, sometimes
>         blatant, sometimes subtle. How confident are you that the final
>         version will be bug-free?

It's a long story, but a lot of the errors occurred as a result of our
document production process.  I'm currently working to make the production
of the lex tables much more straight-forward, so I'm reasonably confident
we can make this bug-free.

>     (2) Do you think that the PDA imposes requirements (on
>         implementations) that aren't imposed elsewhere in
>         the spec?  If so, what are they?
>         And if not, why make it normative?

Right, that's the real question, or, I would term this as I stated above,
do the lex tables add information that is in addition to the BNF, and is
needed to parse the grammar?  If you want to disambiguate the operator
keyword 'div' from the QName 'div' at lex-only evaluation time (to take an
ultra simple example), they may be necessary, but it should be possible to
infer this from the BNF.  In other words, you could theoretically write a
program that builds a JavaCC parser spec, or any other parser, strictly
from the BNF... it would just be hard to programmatically generate the lex
states and actions.  So, I think I'm agreeing with you that these tables
should be made non-normative [currently I'm only speaking for myself, not
the WG].  I think, however, that they're probably still useful to
implementers as a non-normative appendix, to make sure it's clear why
reserved unprefixed QNames are not necessary, etc.  On the other hand, less
work if we loose them altogether from the spec...  :-)

[BTW, we haven't forgotten about the rest of your comments.  We'll be
working on these and will let you know.  Also, if it's not clear, I'm
grateful for your valuable critique and insight.]

-scott

Received on Friday, 10 January 2003 13:38:19 UTC