Re: SPARQL 1.1 Protocol: Format of fault messages

>> 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 18:17:07 UTC