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

Re: Returning HTTP codes with HTML descriptions.

From: Andrei Sambra <andrei@fcns.eu>
Date: Sat, 03 Nov 2012 07:19:17 -0400
Message-ID: <5094FDB5.3070708@fcns.eu>
To: public-ldp-wg@w3.org
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 

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


> Cheers,
> 	   Michael
> --
> Dr. Michael Hausenblas, Research Fellow
> DERI - Digital Enterprise Research Institute
> NUIG - National University of Ireland, Galway
> Ireland, Europe
> Tel.: +353 91 495730
> http://mhausenblas.info/
> On 3 Nov 2012, at 03:46, Steve K Speicher wrote:
>> Alexandre Bertails <bertails@w3.org> wrote on 11/02/2012 06:58:11 PM:
>>> From: Alexandre Bertails <bertails@w3.org>
>>> To: "Wilde, Erik" <Erik.Wilde@emc.com>,
>>> Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Andrei Sambra
>> <andrei@fcns.eu>
>>> Date: 11/02/2012 06:58 PM
>>> Subject: Re: Returning HTTP codes with HTML descriptions.
>>> On 11/02/2012 09:45 PM, Wilde, Erik wrote:
>>>> hello.
>>>> On Nov 2, 2012, at 12:54, "Andrei Sambra" <andrei@fcns.eu
>>>> <mailto:andrei@fcns.eu>> wrote:
>>>>> For example, applications may not "speak" LDP at start (i.e. misusing
>>>>> REST verbs), thus resulting in '405 Method Not Allowed' errors. It
>> would
>>>>> be nice to have some HTML describing what they did wrong.
>>>> instead of just using HTML, i suggest to have a look at
>>>> http://tools.ietf.org/html/draft-nottingham-http-problem-01 and see
>> how
>>>> well it would fit. i think pretty good. the next version is supposed
>> to
>>>> add XML support (i'm working on a schema).
>>> There are some interesting ideas in this spec, but in our case, the
>>> client already understands RDF, so I don't see why we would return
>>> anything but RDF for "problem details".
>> I think the server should honor Accept header when replying with error
>> messaging too.  This is what I've done in practice, the non-HTML could
>> always refer to some HTML page that could be fetched if additional human
>> readable details where needed.

+1 from me too.

>> Thanks,
>> Steve Speicher
>> IBM Rational Software
>> OSLC - Lifecycle integration inspired by the web ->
>> http://open-services.net
Received on Saturday, 3 November 2012 11:19:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC