Re: SPARQL 1.1 Protocol: Format of fault messages

* Richard Cyganiak <richard@cyganiak.de> [2010-10-03 16:31+0100]
> 
> On 1 Oct 2010, at 21:24, Eric Prud'hommeaux wrote:
> >>1. To state in the HTTP binding that clients SHOULD use the XML
> >>fault message format when reporting faults.
> >
> >It may be polite to still have two, one for SOAP interfaces, which
> >have some standard tooling and contracts, etc.
> 
> I'm just concerned about the HTTP bindings. I don't really see the
> SOAP bindings used out there in the wild; my clients certainly don't
> support them, and I had no user requests for SOAP support.

I read that as you're OK with the SOAP binding specifying a SOAP fault
which is different from the HTTP bindings, so <malformed-query/> stays
as is.


> >I expect your principle
> >issue is with the free-form beat poetry style of the rest bindings.
> 
> My issue is with two things:
> 
> 1. The current spec says: “Use this HTTP status code, everything
> else is up to you.”
> 
> It should say: “You SHOULD report the error message this way.”
> 
> 2. The current spec has an example that shows the error message
> embedded in HTML in a way that it can't be gotten out by a client.
> 
> It should not use such an example.
> 
> >We'd kind of like to leave room for implementors to innovate
> 
> Saying that you SHOULD use a certain format leaves enough wiggle
> room for implementors to innovate, IMO.

Sure, but we'd also like to encourage a backwards-compatible
extensibility model which allows me to have a great new idea without
breaking all the old code which e.g. reports errors to humans.


> I think the spec should really communicate one no-brainer way of
> implementing error reporting, for anyone who really just wants to be
> conformant without any desire to do fancy innovative stuff. I really
> want that format to be machine-readable; beyond that I really don't
> care much.
> 
> I have no objection against also proposing alternative response
> formats, as long as one option is clearly highlighted as the “no-
> brainer” option.

And I'm interested in making sure that the alternatives subsume the
no-brainer in a way that the no-brainer parser can use.


> >and reply with
> >our baseline error response plus some structured stuff to say what
> >line and character caused what sort of error.
> 
> I'm all for reporting line and column in a structured format if
> possible, but that would be the cherry on the cake.
> 
> I'd be sufficiently happy with just the cake.

+1, I wanted to illustrate to you how the no-brainer could grow.


> >We'd also like that to
> >show up in browsers. What if we say that it must appear in a pre with
> >a particular class?
> >
> ><?xml version="1.0" encoding="UTF-8"?>
> ><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN"
> >"http://www.w3.org/MarkUp/DTD/xhtml.dtd">
> ><html xmlns="http://www.w3.org/1999/xhtml">
> > <head>
> >   <title>D'oh!</title>
> > </head>
> > <body>
> >   <pre class="malformedQueryFault" style="display:none">Parse
> >error at [5:17], unexpected ' '</pre>
> 
> Why would you make it display:none? If you use HTML already, then at
> least make the error message show up in the browser!

Oops, I meant that to be display:none only in the more structured
extensions.


> 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:

[[
A malformedQueryFault response SHOULD be an XHTML document in which an
element with an XML ID of <code>malformedQueryFault</code> conveys a
human-readable representation of the error. For example:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <title>Malformed Query</title>
    </head>
    <body>
      <h1>Malformed Query</h1>
      <pre id="malformedQueryFault">Parse error at [5:17], unexpected ' '</pre>
    </body>
  </html>

Other HTML elements in the response do not change the interpretation
of the element with the XML ID of <code>malformedQueryFault</code>/
]]


> Best,
> Richard

-- 
-ericP

Received on Sunday, 3 October 2010 16:04:17 UTC