Re: Returning HTTP codes with HTML descriptions.

On 03/11/12 04:48, Michael Hausenblas wrote:
>
> +1 to mnot's I-D and big thanks to dret for pointing it out (as I was
> not aware of this - heck, how many I-Ds does Mark issue per month ???
> ;)
>
>> I think the server should honor Accept header when replying with
>> error messaging too
>
> +1
>
> Should we maybe step back a bit and first ask ourself who the primary
> consumer of the message is?

yes!

>
> At least implicitly, Andrei seems to assume a human the primary
> consumer (?) - so, one scenario could for example be that the UA
> renders this message in some meaningful way, presents it to the human
> user and asks for confirmation or offers choices for next steps to
> overcome the current situation. In this case I'd certainly want
> either JSON or HTML and no RDF at all. The former in Ajax setups
> where the client uses the JSON to fill in UI elements, and the latter
> for good old, plain rendering.
>
> However, I'm wondering, are there maybe also cases where the primary
> consumer is not a human user? What would this change? Should we take
> this into account and would then be RDF/Turtle the 'dominant'
> representation?
>
> Cheers, Michael

In the case of errors, even when it's an agent that asking for the RDF 
or invoking some action like deleting a LDPR, if there is an error, then 
letting the user know is the right response.

Otherwise, the danger of making a error (RDF, JSON) document is that the 
agent caller has to grok the content and know all the error cases (and 
so does this WG have to define all the possibilities?).

Sometimes, the best thing is to pass the information to the user on 
whose behalf the agent is acting.  Of course, this risks low level 
gobbledygook being presented to the user.

It depends on how "far" down the software agent is from the user.

	Andy

Received on Saturday, 3 November 2012 18:38:27 UTC