Re: SPARQL 1.1 Protocol: Format of fault messages

* 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