- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Thu, 21 Jul 2011 07:39:13 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: public-rdf-dawg@w3.org
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 >>>> >>> >>> >
Received on Thursday, 21 July 2011 11:39:49 UTC