Re: fed review

Dear all,

I uploaded a new version of the federated query, please, have a look a it, I
modified the SERVICE var section as suggested.

Carlos

PS Greg: I also fixed the issues you pointed in your emails, please, tell me
if you are ok with them.

2011/7/22 Carlos Buil Aranda <cbuil@fi.upm.es>

> after all opinions, I will add a new semantics section for the special case
> of SERVICE VAR, which I will evaluate as it is, adding a constrain that it
> is not possible to know in advance what URIs can be in VAR, before
> evaluating it, so there may be all possible values there, and the behavior
> is undefined. Then, I will explicitly say that this is optional providing a
> set of basic constrains (boundedness condition), and saying that this could
> be used to implicitly determine an order of evaluation.
>
> is that ok?
>
> Carlos
>
>
> 2011/7/21 Steve Harris <steve.harris@garlik.com>
>
>> 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
>>
>>
>>
>