[DALI] error documents

[Andreas Wicenec]

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/