Re: fed review

so, if we leave it open, as Andy says, how could we specify that in the
document? in the evaluation semantics of SERVICE VAR, specifying that the
join is done with all possible URIs and add a restriction in there? using
the join relationship? this would allow to have SERVICE VAR in the document,
right?

Carlos


2011/7/21 Lee Feigenbaum <lee@thefigtrees.net>

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