W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Returning HTTP codes with HTML descriptions.

From: Nathan <nathan@webr3.org>
Date: Sat, 03 Nov 2012 11:49:46 +0000
Message-ID: <509504DA.5010007@webr3.org>
To: Andrei Sambra <andrei@fcns.eu>
CC: public-ldp-wg@w3.org
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:33 UTC