- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Tue, 20 Sep 2011 09:33:30 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-dawg@w3.org
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. thanks, .greg
Received on Tuesday, 20 September 2011 13:34:34 UTC