[DALI] error documents

[Mark Taylor]

I'm in favour of the general idea.

On specifics, I'd be inclined to go a bit further than this suggestion
and say that services should be free (encouraged?) to provide non-VOTable
error documents for known error results even if the service normally
provides VOTable output.  Clients will need to be ready for non-VOTable
(probably, plain text) error documents attached to non-200 responses
in any case since the HTTP server may generate these outside of VO
service control.  So I'd suggest that VOTable error documents are
not encouraged for non-200 HTTP responses, regardless of the normal
successful output format of the service.  Using VOTable mechanisms to
indicate errors encountered during result generation (e.g. an INFO
indicating an overflow) is not affected by this, since such results
will have a 200 response code.

However, if that variant isn't popular, I'm happy to go with what
Pat has written.

Mark

On Tue, 30 Oct 2012, Patrick Dowler wrote:

> 
> One topic came up in the recent DALI session that we decided to consult a 
> wider audience on: error documents. In the past, it has been standard practice 
> that error documents from DAL services were always VOTable documents with a
> special INFO element showing the error state, plus whatever extra description 
> the service could provide.
> 
> It was pointed out that the practices in some GWS specs (eg VOSpace) of using 
> text/plain and specified could be alot easier for clients to consume and, if 
> they had a UI, display to the user.
> 
> I would like to change the language in the DALI spec to allow this. We would 
> keep the description of how to specify errors in VOTable as-is but also allow 
> non-VOTable responses if that made more sense in the specific service spec. The 
> language would be something like 
> 
> "if the service normally returns results in VOTable format, errors should also 
> be expressed with VOTable error documents"
> 
> "if a service does not use VOTable, it may use text/plain error documents" 
> 
> Specific services would decide, so services that support multiple response 
> formats (eg TAP) and that already require VOTable support could still specify 
> that all errors are VOTable documents.
> 
> The use case we envisioned was a service that did some data operations (eg 
> image mosaic service). In this case, input and output might be FITS files but 
> the client would need VOTable and XML parser support just to handle error 
> messages. That seemed asking too much to everyone at the DALI session.
> 
> So, this is just relaxing the language a bit to permit text/plain error 
> documents in specific DAL services. Comments?
> 
> -- 
> 
> Patrick Dowler
> Tel/Tél: (250) 363-0044
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9E 2M7
> 
> Centre canadien de donnees astronomiques
> Conseil national de recherches Canada
> 5071, chemin West Saanich
> Victoria (C.-B.) V9E 2M7
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/