Re: Update

> On 2015-10-12, at 15:54, Karima Rafes <karima.rafes@gmail.com> wrote:
> 
>> That sounds like a problem with how some developers are interacting with SPARQL endpoints, not with the SPARQL protocol spec. When staying within the spec, there are lots of conformant implementations that can all be used properly with content negotiation. In these cases, the SPARQL Protocol spec is “enough”.
> 
>> the protocol permits those variations for good reason.
>> it also provides means to discover the respective capabilities.
>> what is missing?
> 
> Ok if I resume, if the developers have to use a different code for
> each triplestore... it's for a good reason...
> I thought the aim was to become interoperable. Sorry ;)

the goal is to afford interoperability.
a failure to recognize an “update” argument would be just that, a “failure”, not a variation.
at the same time there can be reasons to distinguish the two service endpoints.
authentication realms is the most obvious which comes to mind.

> 
> When you will be agree on one clear protocol for SPARQL,

it is “one clear protocol”. the protocol permits two distinct end points.
the protocol provides means to discover the capabilities of those two endpoints.
for example, provided with a declaration of the endpoints for a service, a harness which intends to test federation knows that it will perform query requests only (as of 1.1) and can rely on the respective service description to decide which endpoint to use.

how is that not sufficient?

> I will be
> able to help you on the SPARQL test suite because for the moment, I
> have no the time to develop a new patch for all interpretations of
> each editor.

there is but one interpretation.
it just happens to include alternatives.
if a test suite intends to verify conformance to the protocols described in the recommendations, it may be necessary for it to follow them.

best regards, for berlin,

---
james anderson | james@dydra.com | http://dydra.com