Re: Return codes

Hi,

On 6 May 2010, at 03:55, Paul Gearon wrote:

> 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.

Would some HTTP codes for failure / success be defined in the protocol ?

> 
> - 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.

We decided (F2F3) to not indicate the number of triples added / deleted in Update [1] so we probably should stick to that.
Counting the number of triples that left may also be cumbersome (e.g. if it deletes entailed triples, or if you simply forgot to check number of triples in the store before the query), even from the implementation side itself I guess.

Alex.

[1] http://www.w3.org/2009/sparql/meeting/2010-03-25#resolution_5

> 
> Regards,
> Paul Gearon
> 

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Thursday, 6 May 2010 06:09:44 UTC