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

Re: Adressing more error cases ?

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Wed, 3 Oct 2012 13:34:21 -0400
To: Andy Seaborne <andy.seaborne@epimorphics.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-ID: <CC91C392.A7D7%erik.wilde@emc.com>
hello.

On 2012-10-03 1:25 , "Andy Seaborne" <andy.seaborne@epimorphics.com> wrote:
>>Olivier Berger <olivier.berger@it-sudparis.eu> wrote on 09/28/2012
>> 10:41:59 AM:
>>The intent of the submission was to add in explicit status codes when it
>> is not obvious.  So there are some indicated and I believe that we
>>should
>> follow this (in other words don't repeat HTTP spec).  I'm fine with
>>there
>> being an issue opened but I can't see any cases in current draft that
>>need
>> clarity.  Perhaps if the issue was clearly in an area that was lacking
>>or
>> a use case that wasn't supported, that would help.
>There ought to be a common approach - either rely on the HTTP spec or
>put in enough text to make the LDP doc stand on its own.
>At the moment, status codes are relying on the HTTP spec but the
>majority of the document (e.g. section 4) contains text so that reader
>does not need to look at the RFC.

the idea of the "HTTP Problem" draft is that there ought to be both:
well-behaving web citizens should always use appropriate HTTP status
codes, and clients should be able to rely on the status code semantics as
defined by HTTP, without the need to look into any specifics of the
service. that is the rule of the uniform interface that you cannot get
around, unless you want to violate basic REST and web principles.

that does not mean, however, that there isn't *more* that could be said
about why a specific status code was used, either generically for the
service, or even specifically for the request. in that case, it would be
useful to have a convention for how this could be communicated as well,
and since it is service-specific, it needs to be documented as part of the
media type definition describing a specific service. so far, many REST
services have done this, but on an ad-hoc basis (defining their own
vocabulary). "HTTP Problem" is an approach to allow media types (and thus
services) to reuse a common pattern and vocabulary for that, and while the
current draft is JSON-only, the core of it is the vocabulary, which of
course can be RDFized.

i hope this clarifies matters a little bit. cheers,

dret.
Received on Wednesday, 3 October 2012 17:35:17 UTC

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