Re: Grammar changes

Hi Andy,

I'm working through these grammar changes -- probably won't get to most of 
them until next week, but a comment:

> First stage of grammar changes: rq24 has been updated but I haven't 
> redeployed 
> the new grammar in yacker or the sparql.org validator yet.
> 
>    Andy
> 
> 2/ Optional
> 
> Optional moved to be clearer as to what it binds to for the left hand 
side.
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0278
> 
> Effect: Does not invalidate any CR1 legal query.

I'm not sure the new rules are that much clearer than the old ones. (OK, 
they're probably somewhat clearer, but still not *clear*.) We now have:

[20]            GroupGraphPattern         ::=           '{' GroupElement 
'}'
[21]    GroupElement      ::=           GraphPattern ( 
OptionalGraphPattern '.'? GroupElement )?
[22]    GraphPattern      ::=           BasicGraphPattern? ( 
GraphPatternNotTriples '.'? GraphPattern )?

So we can clearly read GroupElement such that the first argument of the 
OptionalGraphPattern is the GraphPattern that comes right before it. The 
problem is that the grammar token GraphPattern does not unambiguously 
represent a single specific pattern. With all the question marks in 
GraphPattern and the recursion, the GraphPattern token often represents a 
whole subtree of nodes in a parse tree. The intended semantics are (I 
guess?) that the first argument to OPTIONAL is the last BGP, 
GraphGraphPattern, GroupGraphPattern, or OptionalGraphPattern that 
precedes the OPTIIONAL, but that's not clear to me from this grammar. 
(Also, the GraphPattern token can consume nothing more than a constraint 
(FILTER clause), which is also unclear as to the semantics when a FILTER 
immediately precedes the OPTIONAL.)

All this is to say that I think we either need prose explaining how to 
determine the first argument to OPTIONAL, or else we need to take another 
stab at the grammar here. 

(I've updated my implementation to use this new grammar, but, for me at 
least, it didn't change the already somewhat convoluted logic of 
determining the first argument to OPTIONAL. The fact that this logic is 
convoluted may be entirely my fault. :-) )

Lee

(I'll have more comments on the rest of the grammar changes next week, I'd 
imagine. Most of it looks great and non-controversial to me.)

> 
> 
> 3/ Filter is now part of a group; there is no such thing as a filtered 
basic
> graph pattern.  Syntactic blank nodes (i.e. as variables) not 
> allowed in FILTER.
> 
> Effect: Any filter with a syntactic blank nodes (e.g. FILTER(_:x < 5)) 
becomes
> a syntax error.
> 
> For example: query-se-bNode-type-var.rq
> 
> 
> 4/ UCHAR has been removed. The text had already been changed to say that 
\u
> processing is done before tokenization.  The grammar now has no \u in 
it.
> 
> Effect: Does not invalidate any CR1 legal query.
>            Does allow \u escapes in new places (comments, keywords, 
> whitespace).
> 
> 
> 5/ Bug corrected: GRAPH [] {} was legal (blank node in GRAPH variable).
> 
> Effect: Queries with that form (and _:XYZ) are now syntactically 
illegal.
> 
> 
> 6/ Bug corrected: ORDER BY str(?x) required brackets for no good reason.
> 
> Effect: Does not invalidate any CR1 legal query.
> 
> 7/ Bug corrected: Rule NCNAME1p => NCNAME1P (tokens are uppercase)
> 
> 
> == Test changes:
> 
> I put a new copy of the development syntax tests into CVS into to the
> development copy of syntax tests:
> 
> http://www.w3.org/2001/sw/DataAccess/tests/data/SyntaxDev/
> 
> There are 174 of them currently.
> 
> == Doc changes:
> 
> Removed any text I could find that put filters with BGP.
> 
> New grammar table.
> 
>    Andy
> 
> 
>