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

Re: fed review

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Thu, 21 Jul 2011 07:39:13 -0400
Message-ID: <4E280FE1.9060407@thefigtrees.net>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: public-rdf-dawg@w3.org
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.

> EricP had a HCLS use case that used a variable in SERVICE.

Ack.

Le
>
> Andy
>
>>
>> Lee
>>
>>>
>>> Andy
>>>>
>>>> Lee
>>>>
>>>
>>>
>
Received on Thursday, 21 July 2011 11:39:49 GMT

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