Re: SPARQL 1.1 Protocol: Format of fault messages

>> And RDFa would be better than a magic class name.
> I'm afraid of demanding a generic RDFa parser for consumers of error
> messages. (Of course, I'm happy to see that practice flourish on its
> own.) Class was a poor choice, how about ID? New proposal:

Call me old fashioned, but I think putting an RDFa parser in a client error handler is just as bad as putting in an HTML scraper! You want to invoke a parser and search for a magic ID or class within an arbitrarily large chunk of HTML whenever the server reports an error?

Seriously, what's wrong with a modern, simple, structured format like:

* form-encoded parameters
* Turtle?

I think that returning human-readable content for a machine request, OR VICE VERSA, is dumb. We have this magic technology called "content negotiation", so how about we use it?

By all means put a header in the request which points to a resource that shows the error in a human readable form, or return multipart, but don't make everyone's ten-line shell scripts import an XSLT library to pull out an error line number.

Received on Sunday, 3 October 2010 23:08:44 UTC