Re: BIND semantics (2)

To assist with my previous comments, here are some suggested textual 
changes.
These are not intended as a further formal comment, and if they are 
unhelpful, please ignore them.


Current draft:
"Use of |BIND| ends the preceding basic graph pattern"

Earlier drafts:
http://www.w3.org/TR/2012/WD-sparql11-query-20120105/#bind
"Use of |BIND| is a separate element of a group graph pattern and it 
ends any basic graph pattern."

I suggest that BIND should apply to the preceding part of the group 
graph pattern, making the whole paragraph:

"The |BIND| form allows a value to be assigned to a variable from a 
group graph pattern. Use of |BIND| ends the preceding group graph 
pattern in which the variable introduced by the |BIND| clause must not 
have been used. "

To clarify this I suggest the following changes to the syntax - these do 
not change the accepted sequences, simply the parse trees - to clarify 
the scope of BIND as above.

OLD
[53]      GroupGraphPattern      ::=      '{' ( SubSelect | 
GroupGraphPatternSub ) '}'
[54]      GroupGraphPatternSub      ::=      TriplesBlock? ( 
GraphPatternNotTriples '.'? TriplesBlock? )*
[56]      GraphPatternNotTriples      ::= GroupOrUnionGraphPattern | 
OptionalGraphPattern | MinusGraphPattern | GraphGraphPattern | 
ServiceGraphPattern | Filter | Bind | InlineData

NEW
  GroupGraphPattern      ::=      '{' ( SubSelect | GroupGraphPatternSub 
) '}'
  GroupGraphPatternSub ::=     ( GroupGraphPatternSub Bind ) ? 
GroupGraphPatternSubNoBind
  GroupGraphPatternSubNoBind      ::=      TriplesBlock? ( 
GraphPatternNotTriples '.'? TriplesBlock? )*
  GraphPatternNotTriples      ::=      GroupOrUnionGraphPattern | 
OptionalGraphPattern | MinusGraphPattern | GraphGraphPattern | 
ServiceGraphPattern | Filter | InlineData

The idea, which perhaps could be formalized in the semantics, is that 
each Bind element as a left-sibling in the parse tree being the 
GroupGraphPaternSub to which it applies.

I believe with these changes that some consequential changes would then 
be needed in the semantics - also it may be clearer to introduce a new 
term (better than GroupGraphPatternSub) to clarify issues like moving 
FILTERs is legal within a GroupGraphPatternSubNoBind but not before or 
after a BIND (obviously if the FILTER does not refer to the variable 
introduced by the BIND this point is moot).

Jeremy