Re: SPARQL 1.1 Protocol: Format of fault messages

On 3 Oct 2010, at 17:03, Eric Prud'hommeaux wrote:
> 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 don't know what a SOAP fault is. I'm just concerned with the HTTP  
bindings.

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

Fair points.

>> And RDFa would be better than a magic class name.
>
> I'm afraid of demanding a generic RDFa parser for consumers of error
> messages.

I see your point. But I'm afraid of even demanding an XHTML parser. In  
reality, too much XHTML ends up as tag soup.

How about this:

[[
A malformedQueryFault response SHOULD be a text/plain document
containing a human-readable representation of the error. For
example:

    HTTP/1.1 400 Bad Request
    Content-Type: text/plain
    Content-Length: 37

    Parse error at [5:17], unexpected ' '

Conformant implementations MAY convey the error message using
other formats than text/plain. If they do so, or include more
content besides the one-line error message in a text/plain
response, then they MUST include a one-line human-readable
representation of the error as an X-Malformed-Query-Fault HTTP
header:

    HTTP/1.1 400 Bad Request
    Content-Type: application/xhtml+xml
    X-Malformed-Query-Fault: Parse error at [5:17], unexpected ' '

    <?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>
]]


Advantages:

1. Anyone can still do anything, as long as they include one HTTP header
2. Machine-readability is *always* given
3. Backwards compatible: If a client checks for presence of the  
header, and if absent checks for a text/plain body, then it will  
always get the message.

Best,
Richard




> (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 18:37:20 UTC