[oslc-core] Question/remarks about error responses

[John Arwe]

Marc, most standards(-like) bodies can/will do more with a concrete 
proposal of the form "do X" ... even if through the process of commenting 
it turns into X' or X'' or even Y, it's the initial proposal that gets 
things rolling.  In bodies driven by scenarios, like OSLC working groups, 
you'll want to add a relatively concrete scenario [1] that shows how the 
proposal improves their clients' lot in life... is it worth the complexity 
(to all newcomers forever after) of adding it.  People's opinions simply 
vary, it is a subjective evaluation.
One alternative that I think adds no new work for you: share with Core the 
extension you end up adding, and an example (concrete!) use case that 
motivates the necessity for it.
[1] http://open-services.net/bin/view/Main/CmScenarios

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   Thunissen Marc <marc.thunissen at oce.com>
To:     Steve K Speicher/Raleigh/IBM at IBMUS
Cc:     oslc-core at open-services.net
Date:   10/17/2011 01:44 AM
Subject:        Re: [oslc-core] Question/remarks about error responses
Sent by:        oslc-core-bounces at open-services.net



Hello Steve,

Thank you for your reply.
I am trying to clarify my ideas and you already give interesting 
suggestions.

I think we may have to provide several levels of response.

First, this is an API, so we need a short machine-readable response to 
guide the client software.
The oslc:statusCode is of this kind.
But there may be so many reasons to issue an HTTP 400.

A second level of information should be a small human readable message 
(maybe only in English or in the language of the server) that the client 
software can display (this can help in case the client software need to be 
better configured) or log in a file.

The oslc:message seems to be this level.

A third level could often be necessary to provide details about the error, 
such as:
 - the line number and column where the xml parser found something bad
 - the name of the attribute with a bad value
 - may be the posted content
I don't like using the oslc:moreInfo URL to provide such information: this 
could be too big to fit in an URL and this mean that a second call must be 
performed to get a readable display.

I think there is a need for an embedded String or XMLLiteral property in 
the Error resource to provide details about the error.
For now I will add my own extension but I think I would be better to 
normalize this.

Best regards,

Marc

-----Original Message-----
From: Steve K Speicher [mailto:sspeiche at us.ibm.com] 
Sent: jeudi 13 octobre 2011 22:26
To: Thunissen Marc
Cc: oslc-core at open-services.net
Subject: Re: [oslc-core] Question/remarks about error responses

Hello,

Response below...

> From: Thunissen Marc <marc.thunissen at oce.com>
> To: <oslc-core at open-services.net>,
> Date: 10/12/2011 04:20 AM
> Subject: [oslc-core] Question/remarks about error responses Sent by: 
> oslc-core-bounces at open-services.net
> 
> Hello,
> 
> I am a little bit disappointed about the definition of the Error and 
> ExtendedError resources definition.
> 
> I would like to be able to return brief and understandable error
messages, 
> and in some case I also need to provide more information to help the 
> diagnose on the OSLC client.
> 
> I can use the oslc:Error.oslc:message property for the understandable 
> message but I can’t find a place for the additional information.
> The oslc:ExtendedError.oslc:moreInfo is defined as a resource to 
> provide
“by
> reference”.
> This means that another REST request must be issued to get the this
information.
> So I must keep the details of the error somewhere on the server !?
> But, by definition, REST does not allow this.
The idea is not to store the state/session information for the request's 
error but perhaps respond with a URL to a form (with fields to fill in the 
from included in the URL).  For example, if there is a failed creation of 
a resource (POST), then the POST'd content could be encoded into the URL 
for a web form.

> So what should I do ?

What additional information are you needing to provide to a client?

I'd say that you can just simply add to the oslc:Error definition the 
additional items you need within your own namespace.  If there are things 
that you need and believe they need to be part of the spec, please outline 
what is needed to be considered.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


This message and attachment(s) are intended solely for use by the 
addressee and may contain information that is privileged, confidential or 
otherwise exempt from disclosure under applicable law.

If you are not the intended recipient or agent thereof responsible for 
delivering this message to the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited.

If you have received this communication in error, please notify the sender 
immediately by telephone and with a 'reply' message.

Thank you for your co-operation.
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111017/c383c0d3/attachment-0003.html>