W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2003

RE: FW: XQuery: A.1.2 Lexical Rules

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Fri, 10 Jan 2003 23:39:38 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E621060453DF36@daemsg02.software-ag.de>
To: scott_boag@us.ibm.com, Michael Dyck <jmdyck@ibiblio.org>
Cc: public-qt-comments@w3.org

> >     (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...  :-)

In Saxon I have written a parser for the XPath grammar (admittedly much
simpler than the full XQuery grammar) which is based solely on the BNF; I
have never found a need to look at the state transition tables. Of course,
this isn't conclusive proof that they are unnecessary - I might be guessing,
or getting it wrong.

Michael Kay
Received on Friday, 10 January 2003 17:39:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:23 GMT