[DALI] error documents

[Douglas Tody]

An issue that needs to be kept in mind for many of the DAL services is the
separation of the logical service protocol (service API) from the
transport protocol (HTTP in this case).  So if there is an HTTP level
error, of course a HTTP error response should be returned.  But if HTTP
is working just fine and there is a service level error (e.g., undefined
parameter), then we have an HTTP OK/200 but an error response from the
logical service protocol.  These are not the same thing and it is best
to distinguish the two.  There is no need to tie the logical service
protocol explicitly to the HTTP transport, and we may well wish to use a
different protocol in the future.  If we were calling a DAL service
running locally on a desktop system for example, we might in the future
use SAMP or some high performance messaging system to do the
request/response.  There is no reason that something like an object
interface to access an image or spectrum has to be tied to transport
protocol intended for the Internet.

Sorry for the long explanation, but if we just go with what Pat has
suggested a service interface will have the flexibility to be described
either way, and we retain consistency with the current DAL interfaces.
 	- Doug


On Wed, 31 Oct 2012, Andreas Wicenec wrote:

> Hi all,
>
> I really like Mark's suggestion. It's a lot more HTTP standard than what is suggested up to now. Everything non-200 should just follow the HTTP error conventions as much as possible. A VOClient has to implement HTTP anyway, thus this should not cause any additional work.
>
> -Andreas
>
> On 31/10/2012, at 5:33 PM, Mark Taylor wrote:
>
>> 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/
>
>