- From: Richard Newman <rnewman@twinql.com>
- Date: Mon, 4 Oct 2010 11:16:37 -0700
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Eric Prud'hommeaux <eric@w3.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
>> 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