RE: SPARQL 2004-10-12 syntax and grammar issues

-------- Original Message --------
> From: Dave Beckett <>
> Date: 8 November 2004 12:15
> 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
> had strawpoll approximately  no preference: 4  $: 5+1ish  ?: 1
> which I saw as favouring $ alone.

Both: as noted in:

> ISSUE: PrefixDecl allowed before or after Select
> After my posting:
> and proposal:
> and the telcon discussion 2004-10-26:
> still waiting for any (if any) grammar change to be announced.

0164 was "Mon, 25 Oct 2004"

Well - I have been on holiday and on business travel.

I see in the telecon you reference: (I wasn't there)
Eric P gave his decision, accpt 1 and 3, but not 2

Seems clear to me.

> ISSUE: Comments in SPARQL - /**/ // OR # OR both
> My initial posting
> waiting for the editors to announce if there are any document changes.
> I don't actually see any decision in the last telcon minutes

All three.  Or just # (c.f. common in scripting languages).

> 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.

And I have replied on IRC and elsewhere.  You don't like the approach of
allowing different styles of writing; I see that the effect is so small
on the implementer (and is done in RDLQ) as to not justify picking one.
Syntax is a value judgement - see other DAWG syntax issues.

Please also note that it takes time to process all the changes - my
JavaCC grammar has optional commas so I can test it but my grammar isn't
the one in the doc. 

The grammar in the document will be brought up to date when the language
features are stable.  As you are an issue owner on SOURCE, I would
rather see the proposals so I can see what work will be needed rather
doing something (and may it being in a working draft) then undoing it.

> 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.

This is slipping into language design by syntax: I think that rejecting
a feature (nested optionals) based purely on a minor syntax issue is a
very bad basis for a decision.

> 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
> some of which were added.
> Since then I've been through all the grammar in detail and I've got
> more detailed suggestions:

Input noted - your style of writing grammars is one of many.  

I do not intend yacc to be prescriptive - the grammar is to illustrate
the langauge and will require the implementer to work on it to transofrm
it into a form suitable for their parser generator of choice.

> * 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:
> 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
>   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:
> based on an IRC chat.  No reply so far.  The first shift/reduce
> conflict I think is serious.

Answered elswhere.


Received on Monday, 8 November 2004 14:51:54 UTC