W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Re: fed review

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 21 Jul 2011 17:02:29 +0100
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-dawg@w3.org
Message-Id: <AA0C8F0D-FC7D-4FF4-9C07-0B4E35CF9D33@garlik.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
On 2011-07-21, at 12:39, Lee Feigenbaum wrote:
> On 7/20/2011 3:05 PM, Andy Seaborne wrote:
>> 
>> 
>> On 20/07/11 16:23, Lee Feigenbaum wrote:
>>> On 7/20/2011 11:03 AM, Andy Seaborne wrote:
>>>> 
>>>> 
>>>> On 20/07/11 15:30, Lee Feigenbaum wrote:
>>>>> On 7/20/2011 10:14 AM, Steve Harris wrote:
>>>>>> On 2011-07-20, at 03:57, Lee Feigenbaum wrote:
>>>>>>>> So, the possible solutions are:
>>>>>>>> - For the SERVICE VAR semantics
>>>>>>>> - add a new operation that could allow the evaluation (operation
>>>>>>>> which wouldn't be bottom-up)
>>>>>>>> - define its whole semantics in a new way
>>>>>>>> - For the boundedness restriction
>>>>>>>> - specify all cases: it may take a bit long
>>>>>>>> - remove it? I do not think this is a good idea, how do we specify
>>>>>>>> then that a variable is bound (which is needed for the evaluation
>>>>>>>> semantics of SERVICE VAR)?
>>>>>>>> 
>>>>>>>> something missing? any other option?
>>>>>>> 
>>>>>>> As someone who was a bit uncomfortable including it in the first
>>>>>>> place, I'll add another, dramatic option: remove SERVICE VAR from the
>>>>>>> specification altogether.
>>>>>> 
>>>>>> That sounds like a good, pragmatic solution, but it would require a
>>>>>> second Last Call, no?
>>>>> 
>>>>> Given that we haven't yet published Last Call for this document, no.
>>>>> :-)
>>>> 
>>>> If it includes a grammar change, it is a change to the query doc. :-(
>>> 
>>> Good point, but I will argue vociferously that it's not something that
>>> should trigger a new LC for query.
>>> 
>>> Failing winning that argument, I'd "implement" this by keeping the
>>> grammar as is and putting a line in federated query that says "it is an
>>> error to follow SERVICE with a variable."
>> 
>> How leaving it leaving it in the gramamr and not defining it? Making it
>> an error would require a compliant engine to make it an error (this
>> isn't filter extensions - it's a whole-query error like a syntax error).
>> Not defining it allows engines to do something with it if they can
>> (optional feature of an optional feature).
> 
> This would be OK with me.

I would be fine with that as long as it's explicitly stated to be undefined behaviour, rather than brushed under the carpet.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Thursday, 21 July 2011 16:03:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT