RE: [XPath] Consistency of Appendix A Grammar presentation for Fu ncti onName

Hi Scott

There should be no problem with the solution I suggest, it just
provides editorial emphasis to what the spec already says.

If you're after a more technically detailed solution:

My JFlex lexer parses for
"and"
"as"
...
for all reserved words
then NcName
and then QNameWithColon
as maximal length no-whitespace matches.

NcName is therefore short of all reserved words.
QNameWithColon is QName less NcName.

Then my CUP grammar builds up the FunctionName 'terminal' as
the summation of the NcName sub-set plus all reserved words except
appendix A.3. Then the NcName can be built as FunctionName plus
the remaining reserved words. Then QName as QNameWithColon
and NcName. No shift-reduce conflicts.

In practice my grammar is rather more complex because it is part of
NiceXSL and so has XSLT keywords to deal with as well. In working form look
the xpath_* productions in:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/nicexsl/nicexsl/src/net/sf/
nicexsl/NiceXSL.cup?rev=1.3

http://cvs.sourceforge.net/viewcvs.py/*checkout*/nicexsl/nicexsl/src/net/sf/
nicexsl/NiceXSL.lex?rev=1.3

	Regards

		Ed Willink

> -----Original Message-----
> From: scott_boag@us.ibm.com [mailto:scott_boag@us.ibm.com]
> Sent: 28 January 2004 14:59
> To: Willink, Ed
> Cc: 'public-qt-comments@w3.org'
> Subject: Re: [XPath] Consistency of Appendix A Grammar 
> presentation for
> Functi onName
> 
> 
> Ed, thanks for your last call comment.  It will be processed by the 
> working group.
> 
> You make an interesting and valuable point that function 
> names in the BNF 
> need some sort of annotion spelling out the relation with reserved 
> function names.  There may be some technical problems with 
> the solution 
> you suggest, but I'll see what can be done.
> 
> -scott
> 
> public-qt-comments-request@w3.org wrote on 01/27/2004 06:48:02 AM:
> 
> > 
> > Hi
> > 
> > Section A.1.1 and A.2.1 provide helpful grammar notes that 
> are clearly
> > visible in the preceding BNF.
> > 
> > Section A.3 provides equally significant clarification that 
> does not.
> > For no very obvious reason gratuitous ElementName and AttributeName
> > aliases for QName are provided, yet there is no 
> FunctionName to which 
> the
> > A.3 text should be annotated.
> > 
> > Therefore please replace QName by FunctionName in FunctionCall and
> > add e.g.
> > 
> > FunctionName ::= QName /* A.3 reserved names */ 
> > 
> >    Regards
> > 
> >       Ed Willink
> > 
> > 
> --------------------------------------------------------------
> ----------
> > E.D.Willink,                             Email: 
mailto:EdWillink@iee.org
> Thales Research and Technology (UK) Ltd, Tel:  +44 118 923 8278 (direct)
> Worton Drive,                            or  +44 118 986 8601 (ext 8278)
> Worton Grange Business Park,             Fax:  +44 118 923 8399
> Reading,   RG2 0SB
> ENGLAND          http://www.computing.surrey.ac.uk/personal/pg/E.Willink
> ------------------------------------------------------------------------
>

Received on Wednesday, 28 January 2004 10:16:21 UTC