- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 27 Jul 2010 12:41:29 -0400
- To: Axel Polleres <axel.polleres@deri.org>
- CC: Andy Seaborne <andy.seaborne@epimorphics.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 7/27/2010 11:47 AM, Axel Polleres wrote: > > On 27 Jul 2010, at 14:53, Andy Seaborne wrote: >> On 27/07/2010 2:24 PM, Lee Feigenbaum wrote: >>> On 7/26/2010 1:02 PM, Andy Seaborne wrote: >>>>> ======================================================================= >>>>> ISSUE-1 >>>>> >>>>> How to specify BasicFederatedQuery in a way that acknowledges optional >>>>> nature of feature& security issues >>>>> >>>>> Anybody has a proposal on this? >>>>> My proposal would be to just keep it in a separate document and mark >>>>> it as "SHOULD" or "MAY be implemented" plus tie it to a feature in sd: >>>> >>>> I thought we had decided that, on balance, it would go in the query doc. >>>> It would be edited separately for now but merged in when stable. >>> >>> I thought that the optionality (?) of the whole thing was still up in >>> the air? Though there was a leaning towards making SERVICE optional and >>> BINDINGS required? >> >> That's my recollection so BINDINGS is definitely in the query doc. IIRC >> we decided that, on balance, if it's just SERVICE, then a whole doc for >> it would be appreciable overhead and not enough benefit - an initial >> para say "optional feature" is sufficient. > > > Ok, the usual way to do this would be just to make the respective > section "Informative", wouldn't it? I don't think so. I think we want it to be normative (this is how it must be implemented if it is implemented) but we want our conformance criteria to explicitly not require implementations to support it. Lee > > Axel > > > >> Andy >> >>> >>>> The grammar includes SERVICE and BINDINGS anyway. >>> >>> OK. >> >> >> > >
Received on Tuesday, 27 July 2010 16:42:08 UTC