Re: fed review

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