Re: Possible Bug in SPARQL 1.1 Grammar

Hi Andy,

That should be fine. I assume that for query the last BASE given will override the previous ones, and only the last BASE will be used to expand relative URIs.

Thanks,
Matt

On 10/5/2011 9:38 AM, Andy Seaborne wrote:
>
>
> On 04/10/11 16:16, Matthew Perry wrote:
>> Thanks Andy.
>>
>> I also noticed that multiple BASE declarations are allowed in 1.1:
>> Prologue ::= ( BaseDecl | PrefixDecl )*
>>
>> Is this intentional? Only one BASE declaration was allowed in 1.0:
>> Prologue ::= BaseDecl? PrefixDecl*
>
> Intentional - yes.  It wasn't a big thing though.
>
> In SPARQL 1.0, base URIs could be relative even though there was one one base (relative the URI of the query file).
>
> Update adds the possibility of prologues (BASE, PREFIX) before any operation, so BASE...BASE existed in Update.
>
> So making it a general ( BaseDecl | PrefixDecl )* seemed like a simplification.
>
> Is there some problem with that?
>
>     Andy
>
>
>
>>
>> Cheers,
>> Matt
>>
>> On 9/28/2011 5:30 PM, Andy Seaborne wrote:
>>> Looks like a bug to me.
>>>
>>> I've made a note in rq25 (editors draft) so it does not get lost:
>>>
>>> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#editors-notes
>>>
>>> and added it to
>>>
>>> http://www.w3.org/2009/sparql/wiki/PostLastCall
>>>
>>> Thanks
>>> Andy
>>>
>>> On 28/09/11 14:14, Matthew Perry wrote:
>>>> Hi Andy,
>>>>
>>>> I was working on a SPARQL 1.1 parser and noticed that this filter did
>>>> not parse:
>>>>
>>>> FILTER(3+3+4*5*2*3=126)
>>>>
>>>> I believe there is a problem with the AdditiveExpression production:
>>>>
>>>> AdditiveExpression ::= MultiplicativeExpression ( '+'
>>>> MultiplicativeExpression | '-' MultiplicativeExpression | (
>>>> NumericLiteralPositive | NumericLiteralNegative ) ( ( '*'
>>>> UnaryExpression ) | ( '/' UnaryExpression ) )? )*
>>>>
>>>> I think
>>>> ( ( '*' UnaryExpression ) | ( '/' UnaryExpression ) )*?*
>>>> should be
>>>> ( ( '*' UnaryExpression ) | ( '/' UnaryExpression ) )***
>>>>
>>>> Of course, I could have made a mistake somewhere else to cause the
>>>> problem too.
>>>>
>>>> Thanks,
>>>> Matt
>>>
>>
>

Received on Wednesday, 5 October 2011 13:44:55 UTC