GSP Test `DELETE - existing graph` has wrong expected result

[Qup42]

The SPARQL Graph Store Protocol Test DELETE - existing graph has an incorrect expected result. The standard states If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code. The graph being deleted - <http://$HOST/$GRAPHSTORE$/person/2.ttl> - does not exist so the correct response should be 404 Not Found like it is for DELETE - non-existent graph.

The intent is clear though: a graph that exists and is DELETEd should result in response code 200 or 204. The interesting questions seems to me how to best resolve this. <http://$HOST$/$GRAPHSTORE$/person/1.ttl> is still required later on. So I see two ways to resolve this:

• Create a graph for this test to drop it
• Drop the default graph which is only used before this test

[afs]

For some systems, based on quad storage and not having separate graph management, "empty graph" and "no graph" are not distinguished. I suspect that 200 happens in the wild.

This is general area discussed in 5.3. HTTP PUT.

I think the spec should be revised to SHOULD for 404, or say MUST return 404 or 200.

cc @kasei

[Qup42]

For some systems, based on quad storage and not having separate graph management, "empty graph" and "no graph" are not distinguished. I suspect that 200 happens in the wild.

• DELETE - non-existent graph (following DELETE - existing graph with a GET in between) does the exact same operation but now expects a 404 Not Found. This heavily indicates to me that the graph should exist for the first test case.
  Edit: In an old list of all Conformance Tests I found PUT - empty graph which creates the graph being deleted. This seems to be caused by the removal of the unapproved test cases which are required for the setup of this case.
• As far as I can tell Jena returns 404 for DELETE - existing graph (I used indirect graph identification though) when I manually execute the tests in the manifest in order.

This is general area discussed in 5.3. HTTP PUT.

I think the spec should be revised to SHOULD for 404, or say MUST return 404 or 200.

I agree that allowing 404/200 to accommodate both types of graph management seems sensible. The general status code remarks contain the clause and the operation requires that it does which for me leaves enough freedom for both implicit and explicit graph existence. 5.4 HTTP DELETE on the other hand only has If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code. without this clause. How can I return anything else than 404 here without deviating the standard?

[afs]

Jena isn't a good example. The "dataset" abstraction has several implementations. Some handle empty graphs differently to no-such-graph, some don't. It is a reflection of the implementation approach.

The GSP operations have special code to make this look the same in the most frequent cases. But it is a thin layer and it is possible to see through the abstraction.

. 5.4 HTTP DELETE on the other hand only has If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code.

How can I return anything else than 404 here without deviating the standard?

That's something that can be treated as an errata since there is a working group at the moment. The issue list is at https://github.com/w3c/sparql-graph-store-protocol/issues

What we need to know is what the deployed de facto behaviours.

There's scope for a "practice and experience" note somewhere to discuss empty graphs.

[kasei]

I generally agree with the discussion on updating the normative language in the spec surrounding non-existent graphs.

After going through the manifest and the old 1.1 WG minutes, I think this is also a case where we messed up the tests in the process (maybe similar to some of the issues we've seen recently in the Protocol tests).

The approval process does seem to have missed approving the PUT - empty graph, which would have made many of the subsequent tests make sense (even if only for systems that can have empty graphs and for which a DELETE/GET sequence would yield a 404). I think this miss was because we approved tests based on a list Chime provided of tests which already had two passing implementations. But the tests were inter-dependent, and so they needed to be approved all or nothing to make sense (modulo the orthogonal issue of supporting empty graphs). Our mistake was in mixing implementation report data into the approval process, which should have just been based on whether the tests made sense or not.

[kasei]

I'll add that none of my systems implement GSP. I do have a similar situation as Jena with an abstraction that supports both kinds of datasets (and so would have some situations where I pass these tests and some where I don't), but since I don't implement GSP, it's never come up as an issue.