- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Mon, 4 Oct 2010 14:53:51 -0400
- To: Richard Newman <rnewman@twinql.com>
- Cc: Richard Cyganiak <richard@cyganiak.de>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
* Richard Newman <rnewman@twinql.com> [2010-10-04 11:16-0700] > >>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. I think it is user-facing. I've not seen any endpoints which don't have HTML interfaces. I read this as a recognition that the browser interface is a very useful query development tool and one of the distinguishing features of the SemWeb. > 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? I'd say yes because it introduces no new requirements to the pipeline. The requirement of access to headers can seriously limit the choice of libraries and architectures. > >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. -- -ericP
Received on Monday, 4 October 2010 22:48:42 UTC