W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: tomorrow's agenda (and initial open ISSUES summary.. )

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 27 Jul 2010 17:33:36 +0100
Message-ID: <4C4F0A60.1050304@epimorphics.com>
To: Axel Polleres <axel.polleres@deri.org>
CC: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>

On 27/07/2010 4:47 PM, 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 guess so - certainly not "normative" - but I think it's still worth a 
line or two to explain.  In a W3C doc, there can be "Informative" 
sections that are about required features - that is, they explain 
something which is normatively defined elsewhere in the spec.

Here the "informative" is about a not-required feature.

Received on Tuesday, 27 July 2010 16:34:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:01 UTC