diff --git a/spec/index.html b/spec/index.html index ed5ad663..81556cbb 100644 --- a/spec/index.html +++ b/spec/index.html @@ -8730,10 +8730,10 @@

Variable Scope

query. The definition below provides a way of determining this from the abstract syntax tree of a query.

Note that a subquery with a projection can hide variables; use of a variable in - FILTER or in MINUS does not cause the variable to be in-scope + `FILTER` or in `MINUS` does not cause the variable to be in-scope outside of those forms.

Let P, P1, and P2 be graph patterns, and E, - E1,..., through En be expressions. A variable v is in-scope if:

+ E1,..., through En be expressions. A variable `v` is in-scope if:

@@ -8742,70 +8742,81 @@

Variable Scope

- + - + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + + + + +
Basic Graph Pattern (BGP)v occurs in the BGP`v` occurs in the BGP
Pathv occurs in the path`v` occurs in the path
Group { P1 P2 ... }v is in-scope if it is in-scope in one or more of P1, P2, ...Group `{ P1 P2 ... }``v` is in-scope if it is in-scope in one or more of P1, P2, ...
GRAPH term { P }v is term or v is in-scope in P`GRAPH term { P }``v` is `term` or `v` is in-scope in P
{ P1 } UNION { P2 }v is in-scope in P1 or in-scope in P2`{ P1 } UNION { P2 }``v` is in-scope in P1 or in-scope in P2
OPTIONAL {P}v is in-scope in P`OPTIONAL {P}``v` is in-scope in P
SERVICE term {P}v is term or v is in-scope in P`SERVICE term {P}``v` is `term` or `v` is in-scope in P
BIND (expr AS v)v is in-scope`BIND (expr AS v)``v` is in-scope
SELECT .. v .. { P }v is in-scope`SELECT .. v .. { P }``v` is in-scope
SELECT ... (expr AS v)v is in-scope`SELECT ... (expr AS v)``v` is in-scope
GROUP BY (expr AS v)v is in-scope`GROUP BY (expr AS v)``v` is in-scope
SELECT * { P }v is in-scope in P`SELECT * { P }``v` is in-scope in `P`
VALUES v { values }v is in-scope`VALUES v { values }``v` is in-scope
VALUES varlist { values }v is in-scope if v is in varlist`VALUES varlist { values }``v` is in-scope if `v` is in `varlist`
`EXISTS` and `NOT EXISTS` + `v` is in-scope if it is in-scope for the + solution mapping + where the expression containing `EXISTS` or `NOT EXISTS` is applied. +
-

The variable v must not be in-scope at the point of the (expr AS - v) form. The scoping for (expr AS v) applies immediately in - SELECT expressions.

-

In BIND (expr AS v) requires that the variable v is not - in-scope from the preceeding elements in the group graph pattern in which it is used.

-

In SELECT, the variable v must not be in-scope in the graph - pattern of the SELECT clause, nor used in another select expression earlier in - the clause.

+

The variable `v` must not be in-scope at the point of the + `(expr AS v)` form. The scoping for `(expr AS v)` + applies immediately in `SELECT` expressions. +

+

In `BIND (expr AS v)` requires that the variable `v` is not + in-scope from the preceeding elements in the group graph pattern in which it is used. +

+

In `SELECT`, the variable `v` must not be in-scope in the graph + pattern of the `SELECT` clause, nor used in another select expression earlier in + the clause. +

Converting Graph Patterns

@@ -10971,52 +10982,95 @@

Grammar

section 6 Notation.

Notes:

    -
  1. Keywords are matched in a case-insensitive manner with the exception of - the keyword 'a' which, in line with Turtle and N3, is used - in place of the IRI rdf:type - (in full, http://www.w3.org/1999/02/22-rdf-syntax-ns#type).
    2. -
  2. Escape sequences are case sensitive.
    3. -
  3. When tokenizing the input and choosing grammar rules, the longest match is chosen.
    4. -
  4. The SPARQL grammar is LL(1) when the rules with uppercased names are used as terminals.
    5. -
  5. There are two entry points into the grammar: QueryUnit for the SPARQL query language - and UpdateUnit for the SPARQL update language.
    6. -
  6. In signed numbers, no white space is allowed between the sign and the number. +
  7. + Keywords are matched in a case-insensitive manner with the exception of + the keyword '`a`' which, in line with Turtle and N3, is used + in place of the IRI `rdf:type` (in full, + http://www.w3.org/1999/02/22-rdf-syntax-ns#type). +
    8. +
  8. + Escape sequences are case sensitive. +
    9. +
  9. + When tokenizing the input and choosing grammar rules, the longest match is chosen. +
    10. +
  10. + The SPARQL grammar is LL(1) when the rules with uppercased names are used as terminals. +
    11. +
  11. + There are two entry points into the grammar: `QueryUnit` for the SPARQL query language + and `UpdateUnit` for the SPARQL update language. +
    12. +
  12. + In signed numbers, no white space is allowed between the sign and the number. The AdditiveExpression grammar rule allows for this by covering the two cases of an expression followed by a signed number. These - produce an addition or subtraction of the unsigned number as appropriate.
    13. -
  13. The tokens INSERT DATA, + produce an addition or subtraction of the unsigned number as appropriate. +
    14. +
  14. + The tokens INSERT DATA, DELETE DATA and DELETE WHERE allow any amount of white space between the words. - The single space version is used in the grammar for clarity.
    15. -
  15. The QuadData and + The single space version is used in the grammar for clarity. +
    16. +
  16. + The QuadData and QuadPattern rules both use rule Quads. The rule QuadData, used in INSERTDATA and DELETE DATA, - must not allow variables in the quad patterns.
    17. -
  17. Blank node syntax is not allowed in DELETE WHERE, - the DeleteClause for - DELETE, - nor in DELETE DATA.
    18. -
  18. Rules for limiting the use of blank node identifiers are given in section 19.6.
    19. -
  19. The number of variables in the variable list of VALUES block - must be the same as the number of each list of associated values in the DataBlock.
    20. -
  20. Variables introduced by AS in a SELECT clause - must not already be in-scope.
    21. -
  21. The variable assigned in a BIND clause must not be already + must not allow variables in the quad patterns. +
    22. +
  22. + Blank node syntax is not allowed in + DELETE WHERE, + in a DeleteClause, + nor in DELETE DATA. +
    23. +
  23. + Rules for limiting the use of blank node identifiers are given in + section 19.6. +
    24. +
  24. + The number of variables in the variable list of VALUES block + must be the same as the number of each list of associated values in the + DataBlock. +
    25. +
  25. + Variables introduced by AS in a SELECT clause + must not already be in-scope. +
    26. +
  26. + The variable assigned in a BIND clause must not be already in-use within the immediately preceding TriplesBlock within a - GroupGraphPattern.
    27. -
  27. Aggregate functions can be one of the + GroupGraphPattern. +
    28. +
  28. + Aggregate functions can be one of the built-in keywords for aggregates - or a custom aggregate, which is syntactically a function - call. Aggregate functions may only be used in + or a custom aggregate, which is syntactically a + function call. + Aggregate functions may only be used in SELECT, HAVING - and ORDER BY clauses.
    29. -
  29. The expression argument of an aggregate function can not contain an aggregate function.
    30. -
  30. Only custom aggregate functions use the DISTINCT keyword - in a function call.
    31. -
  31. A reifier or + and ORDER BY clauses. +
    32. +
  32. + Any variable that is assigned to in the graph pattern of `EXISTS` or `NOT EXISTS` + must not be in-scope. This applies to `BIND`, + variables introduced by `AS` in a `SELECT` clause, + variables introduced by `AS` in `GROUP BY`, + and variables in a `VALUES` clause. +
    33. +
  33. + The expression argument of an aggregate function can not contain an aggregate function. +
    34. +
  34. + Only custom aggregate functions use the DISTINCT keyword + in a function call. +
    35. +
  35. + A reifier or annotation syntax is only permitted after a triple when the property position is a simple path (an IRI, the keyword a, or a variable),