SPARQL 2004-10-12 syntax and grammar issues

Pulling my thoughts together in one email, my overall general concern
is that the language is already too large and still growing.  I
expected a strawman language based on BRQL to be removing things as
well as adding them.

I've seen a tendency to when given two choices, pick both.  Which has
been making the language larger and full of syntactic sugar or a
sugary mess if you like.  This is a flaw of RDF/XML that I see
starting to be repeated here.

There are lots of items in this email, several of which I've brought
up in different places and I include pointers.  I'll put ISSUE:
before each one I find significant.  I could pull them out into
separate subject threads - my preference for tracking, but spawning
6-7 new threads.

Dave

-----

ISSUE: Variables with $ or variables with ?
After the telcon discussion and preferences (vote?), I'm still
waiting for the editors to announce what they are doing / have done.

The 2004-10-26 telcon
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0194.html
had strawpoll approximately  no preference: 4  $: 5+1ish  ?: 1
which I saw as favouring $ alone.


ISSUE: PrefixDecl allowed before or after Select
After my posting:
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0161.html
and proposal:
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0164.html
and the telcon discussion 2004-10-26:
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0194.html
still waiting for any (if any) grammar change to be announced.


ISSUE: Comments in SPARQL - /**/ // OR # OR both
My initial posting
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0199.html
waiting for the editors to announce if there are any document changes.
I don't actually see any decision in the last telcon minutes
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0210.html


ISSUE: Commas or no commas
I've already seen user confusion when they tried to use ','s inside
WHERE (s, p, o) and omitting them outside with SELECT ?x ?y.  I've
mentioned this many times as likely to happen.  It's hard to remember.


ISSUE: OPTIONAL or []s
I've asked several times to pick just one of these.  The WG looked
favourably at F2F on a syntax containing the latter only.  This
is related to the more general need for a grouping construct - not
needed at all if nested optionals are ditched.


ISSUE: Keywords to be allowed in upper and lowercase

Breaking with the trend, I'd like an alternative.
I'd like 'select' to be allowed as well as 'SELECT' for all keywords
since stylistically uppercase "shouting" is getting tiresome and this
is already done in RDQL, BRQL, SQL* languages and grammaras.  Note:
This is NOT about making them case independent, allowing 'sElECt'.


ISSUE: SPARQL EBNF / grammar detail suggestions
I gave some layout suggestions in
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0524.html
some of which were added.

Since then I've been through all the grammar in detail and I've got
more detailed suggestions:

* Add a grammar terms SelectClause, ConstructClause, DescribeClause
  as part of ReportFormat.

* To make things easier for me in lex/yacc I renamed things that were
  0 or 1 (not lists) to be ThingOpt - it'd be nice if that was used,
  but just a suggestion.  I renamed FromClauseOpt, WhereClauseOpt.

* Non-terminals used only once.
  I deleted FromSelector and others as they are used once only as an
  alias for another non-terminal.  My preference to just put the
  non-terminal in FromClause.  (The particular non-terminal may
  change since it's related to the prefix issue - could be QuotedURI
  or URI.)

  PatternElement1 and SingleTriplePatternOrGroup are also used once
  only.

* I'm still not clear what GraphPattern1, PatternElementForms... are
  for.  I re-arranged and merged many non-terminals [6]-[14] just for
  my convenience.

* [12] PatternElementForms - 'SOURCE *' - I asked this before:
     http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0025.html
  Please explain where this syntax comes from and what it means.

* Use shorter EBNF: [15] TriplePatternList ::= TriplePattern TriplePattern*
  can be written more concisely as TriplePattern+
  Similarly for other lists such as GraphPattern.

* I added VarOrURIList, VarList and URIList terms to handle the
  optional comma messes.

* Several things inside the expression evaluation can be merged with
  little loss - ConditionalOrExpression into Expression,
  StringEqualityExpression into ValueLogical, StringComparitor into
  StringEqualityExpression, RelationalComparitor into
  EqualityExpression, NumericComparitor into RelationalExpression, 
  AdditiveOperation into AdditiveExpression, MultiplicativeOperation
  into MultiplicativeExpression, PrimaryExpression into
  UnaryExpressionNotPlusMinus, NumericLiteral/TextLiteral both into Literal

* Use more of XML's EBNF and fix things up to match
    http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-notation
  Use the correct syntax for terminals; <NAME> is not allowed as
    symbol name in XML's EBNF.
  [51], [61] ["A"-"Z"] is not legal.
  [54] ["x", "X"] is not legal.
  [57] ~[">", " "] is not legal
  [48] (<NCNAME>)? doesn't need the ()s, similar in [59].
  [51] <A2Z> is missing an open < or has an extra trailing >


ISSUE: grammar lex/yacc shift/reduce conflicts
I raised this in:
  http://lists.w3.org/Archives/Public/www-archive/2004Jul/0016.html
based on an IRC chat.  No reply so far.  The first shift/reduce
conflict I think is serious.

Received on Monday, 8 November 2004 12:23:00 UTC