Re: Returning HTTP codes with HTML descriptions.

Andrei Sambra wrote:
> On 11/03/2012 12:48 AM, 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?
>>
>> 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?
>>
> Given the context of this WG, I think it's safe to assume the primary 
> consumer will almost always be an agent asking for RDF. I wonder if 
> we're not going to overcomplicate things by trying to support too many 
> formats.
> 
> So..in the interest of keeping things simple, maybe we should just go 
> with RDF/Turtle for now (as a MUST), and leave other formats at the 
> discretion of each implementation (as a SHOULD).

I'd suggest that the vocabulary/predicates used are the thing that need 
specified, since "MUST be RDF" doesn't really help anybody understand 
the messages.

Received on Saturday, 3 November 2012 11:50:22 UTC