error resource in UWS

[Patrick Dowler]

On 2008-7-17 03:16:18 Paul Harrison wrote:
> The original intention of this was that it could potentially be a
> rather large message - e.g. a log file, full stack trace etc. so that
> in my html interface I have it appear as a separate link from the job
> summary page - however, it strikes me that it might be nice to split
> this into two - an error summary (a short one line summary of the
> error) and the original "full" error message. The error summary could
> appear as an (optional) element in the job summary, and the full error
> message be available on at the (jobs)/(jobid)/error URI. - what do you
> think?

I could see usefulness in a small, standard error element (in the XML and 
expected to be displayed inline with in an HTML rendering of the job) plus a 
URI to some detailed error output (trace, log, a standard error document for 
the specific type of service, etc.) 

Alternatively, UWS specifies where the error resource is located (relative to 
the job) and the specific type of service has to define what it is. This 
would be about the same as the items in the result list I expect.

I do expect that having a URI to service-specific error documents and results 
will be common, so it might be worth it for UWS to specify simple error and 
result elements. A result could just have a URI and maybe a name/label; an 
error could have a short message, an error code, and a URI to details. 

For the error code I am just thinking of a standard way to 
distinguish "transient failure" (might work on retry) vs "permanent failure" 
(job will always fail -- something must be changed).

For example:

<uws:error>
	<uws:code>TRANSIENT</uws:code>
	<uws:message>server is down for maintainence until ... </uws:message>
	<uws:details>http://example.com/getStatus</uws:details>
</uws:error>

or maybe <uws:error type="TRANSIENT"> ...


> This does bring up another possible issue with the schema - they do
> not actually represent the places where a response is expected to
> return some sort of link to a fuller version of the resource - e.g.
> with results and error - I am not sure if this really matters, as the
> standard relative URIs to find these resources are documented, but it
> is "good REST style" to provide links to these subresources in the
> HTML interface to allow the user to drill down....

I assumed the HTML interface would do that as the developer can put arbitrary 
non-standard content and links in the output and the (human) user can make 
use of them. That is not true of the XML output: there, I think the way to do 
it needs to be specified and (as noted above) I think URIs or URLs in the 
error and result list will be a common pattern and hence maybe should be 
specified by UWS.

-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)