Re: SPARQL 1.1 Protocol: Format of fault messages

Richard,

We are in violent agreement, except I believe that

a) Given that the SPARQL Protocol is based on XML, a simple XML  
message should be preferred over Turtle or JSON for error reporting.

b) For the same reason, simple XML should be preferred over form- 
encoding, although that case is less clear-cut because form-encoded  
data is so easily parsed.

c) Communicating SPARQL error conditions in HTTP headers *only* is  
undesirable. Users do frequently poke around SPARQL endpoint with  
their browsers, and they won't see error messages that are only in the  
header.

I fully agree with your points regarding XHTML for error reporting and  
regarding the importance of simple and reliable error reporting.

Thanks for the informative examples of protocol clients that do  
interesting stuff based on reported errors.

Best,
Richard


On 4 Oct 2010, at 19:16, Richard Newman wrote:

>>> In that case, all errors must be reported primarily using protocol  
>>> mechanisms — HTTP error codes and headers, and SOAP faults — and  
>>> only secondarily through any response body.
>>
>> Are you seriously suggesting that the protocol should define that  
>> error messages be communicated in JSON or Turtle or something else  
>> that requires a parser other than an XML parser?
>
> Not sure how you got to that assertion from mine, but:
>
> I'm suggesting that JSON or Turtle are better machine-processable  
> error formats than XHTML with embedded RDFa. That's important if  
> there's no other error channel: machines need to read errors, and  
> making them dig through HTML is a bad idea.
>
> Further, I'm suggesting that headers or "simple" (form-encoded)  
> machine-readable bodies are better than any of those formats, and  
> that content negotiation and other HTTP mechanisms would make it  
> easier to satisfy more people.
>
> I view encoding a simple error (such as "expected token FOO, got  
> token BAR on line 5") in XHTML to be unnecessary complexity.
>
>
> I consider "playing nice" with protocol channels to be important.  
> That means using SOAP faults rather than in-response error codes,  
> and using HTTP error codes and headers rather than relying on  
> parsing the body. The SPARQL Protocol is not a user-facing web  
> application, so returning only HTML which will be dumped into a log  
> is a waste of time.
>
>
> HTTP takes the tack of putting human-readable suggestions ("the  
> server SHOULD include an entity containing an explanation of the  
> error situation ... display any included entity to the user") in the  
> response body, and machine-processable advice (e.g., Retry-After,  
> Proxy-Authenticate, Allow) in headers. I suggest that the SPARQL  
> Protocol should follow the conventions of the underlying protocol.
>
> If you put enough machine-processable information in the protocol  
> channel, the body can be left as HTML or plain text for users, and  
> automated clients can ignore it. That would make me happy.
>
>
> To flip the question around: are you seriously suggesting that it's  
> better to embed a one-line error message inside a chunk of XHTML,  
> rather than to put it in a well-known header or similar HTTP-level  
> format?
>
>
>> If so, then can you give me an example of an existing SPARQL client  
>> that parses error messages but does not parse successful responses?
>
> To be honest, I'm not aware of any existing SPARQL clients. The  
> SPARQL tools I've seen use proprietary protocols, are interactive  
> toys that don't do any processing at all, or are directly served by  
> the SPARQL endpoint (and thus don't use the SPARQL Protocol). I  
> haven't seen any that do batching, consume from a queue, backoff and  
> retry queries, etc. -- these would all require the processing of  
> error messages, but not the body.
>
> Of course, I've been distant from the whole Semantic Web smorgasbord  
> for a while now, so I might have missed Joe's Awesome SPARQL Client®  
> or something.
>
>
>> And if that is not the case, then what is the closest equivalent in  
>> another, similar, protocol?
>
> I've seen this pattern several times recently.
>
> One example is with Facebook OAuth (the Graph API). A client library  
> makes an HTTP request on behalf of other code. If it detects that  
> the response is an OAuth authentication failure (e.g., token  
> expiration) it re-authenticates and replays the request. It is (or  
> should be) completely unaware of the content of the response (which  
> might be JSON, an image file, or something else); on success, that  
> opaque lump gets passed back to the caller.
>
> Another similar example is the Weave protocol used by Firefox Sync,  
> which actually deals in encrypted bodies: it can't use the body for  
> error communication.

Received on Monday, 4 October 2010 19:21:38 UTC