Return codes

The Update document now refers to result codes for each operation.

A couple of things came up while I was doing this, and I would like
some feedback:

- I have explicitly avoided stating what a result looks like, as this
is a job for the interface. I'd expect some kind of representation to
be used for SPARQL Protocol, HTTP operations, an API, and any other
type of interface.

- Most operations can fail partially or completely. To describe the
mode of failure I said that a failure can contain extra information,
and in most cases that will be an integer representing the number of
triples that were correctly processed. DELETE/INSERT is the one
exception to this, as a failure there includes a pair of tuples.
Presuming everyone is OK with this – should a complete failure be a
separate type again, or is a failure(0) sufficient? I have gone with
failure(0).

- Going with the idea of failure data including the number of
successfully processed triples, I specified the failure of "DROP
GRAPH" due to partial deletion of data to include the number of
triples that were deleted. This makes sense to me, since the user can
always count whatever is left, but I just wanted to check that no one
wanted the failure to report the number of remaining triples instead.

Regards,
Paul Gearon

Received on Thursday, 6 May 2010 02:56:30 UTC