[DALI] error documents

[Douglas Tody]

Sounds reasonable; like a lot of things the exact behavior of a protocol
should be up to the specific protocol to define, while specs like DALI
define a standard generic default behavior.

In the early services votable was adopted for the error documents as the
service was already returning a votable response during normal
execution, and it would actually have been more complicated to use a
different format for error returns.  Then it turned out to be useful to
do things like echo the query or service parameters in INFO elements to
aid debugging, and votable worked well for this.

If however a protocol is not normally returning a votable then I agree
some other response would be reasonable, and simpler.

 	- Doug


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
>