- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Wed, 20 Jul 2011 11:23:38 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: public-rdf-dawg@w3.org
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." Lee > > Andy >> >> Lee >> > >
Received on Wednesday, 20 July 2011 15:24:21 UTC