Re: comment on A.7 "Grammar" (punctuationSyntax)

Dan Connolly wrote:
> On Sun, 2006-06-11 at 07:55 +0100, Steve Harris wrote:
>> On 10 Jun 2006, at 20:35, Seaborne, Andy wrote:
>>>> Strictly speaking, commas may be unnecessary since SELECT ?a ?b + ?c
>>>> can be parsed.
>>> Unbracketed expressions would need commas to know when they end and  
>>> a new one start.  Given we are in CR, mandatory commas would be a  
>>> significant change.
>> Is that a huge setback? I'm not sure of the process implications.
> 
> I was thinking out loud about this sort of thing with EricP...
> 
> I expect that we'll make a number of changes of this magnitude during
> CR. We'll update the test cases to match, and make sure several
> implementations pass the corresponding tests. (Has anybody started
> tracking which implementations pass which tests?)
> 
> While these changes aren't huge, they are substantive in that they
> require people to change their code. So another last call will
> be in order. Say 3 to 4 to 6 weeks. Then (presuming the XQuery
> dependency and such are satisfied...) we should have enough materials
> for a successful request for PR; I don't
> think we need another CR for things like where the commas go.

IF (that's a big "if") we make syntax changes, let's make it a single batch of 
changes:

1/ Tidying up \u escapes
    Does not break any legal query
    http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0443.html

2/ Removing some recursion in the grammar
    Does not change the language but does change the grammar.
    Means that very large queries will work with more tools.

3/ Unary plus and minus
    SPARQL allows spaces between the sign and the number.
    N3 and Turtle don't allow whitespace between sign and number.
    N3 and turtle are different to programming languages I'm used to
    (e.g. Ruby, Java) where whitespace is allowed between the sign and
    the number.

Tidying up 3 leaves more syntax space for a future like property paths.

> 
> That's my suggestion. I wonder if it makes sense to anybody else...
> Kendall?
> 
>> Given that the commas-in-triple-patterns consistency problem is gone  
>> is seems a bit unfortunate to stick with a decision that results from  
>> that.
>>
>>> I hope I've shown that expressions in SELECT are possible.
>> You have, but not that it's particularly pleasant syntax.
> 
> I'm also inclined to add the commas in the SELECT syntax.
> I personally type it that way all the time. That in itself
> isn't new information... I'm not sure if the future consideration
> of expressions in select is new information or not... but
> then there's the addition of ORDER BY to the language... none
> of those by themselves was enough to get us to reconsider, but
> putting them altogether looks like a pretty good case, to me.
> 
> Making them optional would be friendly to existing code and queries,
> though it's kinda gross. I don't have a strong opinion in any
> direction.

Technical note: Optional commas don't work (for the motivation of expressions 
in the SELECT clause without brackets) because the comma is used to know an 
expression has ended and isn't followed by, say, "+ ?x" which is otherwise 
ambiguous.  Ditto ORDER BY.

	Andy

> 
>> - Steve

Received on Sunday, 11 June 2006 19:21:28 UTC