- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 20 Jul 2011 20:05:27 +0100
- To: Lee Feigenbaum <lee@thefigtrees.net>
- CC: public-rdf-dawg@w3.org
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). EricP had a HCLS use case that used a variable in SERVICE. Andy > > Lee > >> >> Andy >>> >>> Lee >>> >> >>
Received on Wednesday, 20 July 2011 19:05:58 UTC