[DALI] error documents

[Mark Taylor]

More flexibility is not an absolute good, it can also mean more 
implementation effort.  In this case, it means three cases which 
the client must handle differently: success, error generated by
the VO service, error generated at some other level of the transport.

My suggestion could be more carefully phrased to decouple it from HTTP
language: for a result which is known to represent an error the
usual mechanisms of the transport protocol for should be used.
In HTTP this is a non-200 response, but other transport protocols
have their own corresponding arrangements.

Mark

On Tue, 6 Nov 2012, Douglas Tody wrote:

> 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/
> > 
> 

--
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/