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

Re: fed review

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 20 Jul 2011 20:05:27 +0100
Message-ID: <4E2726F7.3020201@epimorphics.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: public-rdf-dawg@w3.org


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

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

	Andy

>
> Lee
>
>>
>> Andy
>>>
>>> Lee
>>>
>>
>>
Received on Wednesday, 20 July 2011 19:05:58 GMT

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