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

Re: Partial draft: CommentResponse:RC-4

From: Gregory Williams <greg@evilfunhouse.com>
Date: Tue, 20 Sep 2011 09:33:30 -0400
Cc: public-rdf-dawg@w3.org
Message-Id: <809E66C1-7490-4E4E-939E-BA5FD30BD3E3@evilfunhouse.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
On Sep 20, 2011, at 9:20 AM, Andy Seaborne wrote:

>> This draft says:
>> """ Security is one reason for making this distinction. A complete
>> and compliant implementation of SPARQL Query offered at an endpoint
>> will reject updates (whether this escape change is made or not)
>> because they do not parse as queries. """
>> I'm concerned about this text and the implication that a "complete
>> and compliant" implementation couldn't accept (as an extension of the
>> spec) an update request through the same mechanism as a query request
>> (through an API or the protocol). Is preventing such an extension the
>> intention of the spec?
> It's not the intention: the draft response says
> "A complete and compliant implementation of SPARQL Query"
> to try to emphasis the _query service_ rejecting queries that look like updates.  It's only talking about an unextended service.
> It does not say anything about a combined service, offering query and update facilities (with different URL query parameter presumably) which is what I think you are referring to.  Whether you want to call that two services, at a common endpoint or extended service is as much one of style because we don't define such a thing.

OK, this makes me feel better. I was actually thinking of a service which would provide both query and update through the same URL parameter, but any of these options are relevant to this discussion.

> Is there some rewording that can be done?

Yes. Let me think on it a bit and I'll try to help clarify the text to address my concerns.

Received on Tuesday, 20 September 2011 13:34:34 UTC

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