- From: Steve Harris <steve.harris@garlik.com>
- Date: Thu, 21 Jul 2011 17:02:29 +0100
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-dawg@w3.org
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
Received on Thursday, 21 July 2011 16:03:00 UTC