TAP 1.0/1.1 inconsistency: error document format

[Mark Taylor]

The impossible-to-provide-VOTable point doesn't apply in this context.
TAP 1.1 sec 3.3 does talk about errors in the use of the HTTP protocol,
which would lead to non-VOTable error responses, but the case I'm
talking about here is an error document retrieved from the UWS
error document endpoint /async/<jobid>/error:

  "Error documents should be in a format that matches the requested format
   where possible; see DALI for details. If the error document is being
   retrieved from the /async/<jobid>/error resource (specified by UWS)
   after an asynchronous query, the HTTP status code should be 200."

So where a VOTable result is implicitly or explicitly requested
it is possible to supply a VOTable response; the TAP 1.0->1.1
inconsistency is the "should" which used to be a "must".


On Wed, 17 Sep 2025, Patrick Dowler wrote:

> At this point it has been written/advertised that way for years, so we
> should consider whether it is something to fix or just something to
> accept and adapt to... I know it is not always possible to adhere to
> the strict "error must be VOTable" because some errors happen before
> handling the request gets anywhere near the code that can feasibly
> write a VOTable.
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 
> On Wed, 17 Sept 2025 at 02:51, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> >
> > It might be the spirit, but between TAP 1.1 and DALI 1.1 the text does
> > seem to allow a plain text error document, which is what Rubin are
> > currently doing, though I haven't encountered it in other services.
> >
> > So I think that means that clients and validators have to be prepared
> > for that (topcat and taplint currently are not; I don't know about
> > other TAP clients).
> >
> > Unless we consider this Erratum fodder?
> >
> > On Mon, 15 Sep 2025, Patrick Dowler wrote:
> >
> > > iirc, it was deliberate to change from "must be VOTable" to be able to
> > > play nice with other formats, so it probably should have been as close
> > > to "must be in the requested format" as possible. But of course, not
> > > all tabular output formats can carry error messages, so it gets kind
> > > of tricky in the details.
> > >
> > > The spirit is still definitely that if the client expects a VOTable
> > > response they get that for both success and error, but the DALI quote
> > > shown is much too vague... I think that is where the
> > > clarification/detail is needed.
> > >
> > > --
> > > Patrick Dowler
> > > Canadian Astronomy Data Centre
> > > Victoria, BC, Canada
> > >
> > > On Mon, 15 Sept 2025 at 06:41, Mark Taylor via dal <dal at ivoa.net> wrote:
> > > >
> > > > Hi DAL.
> > > >
> > > > Following a taplint query by Stelios, I've just noticed the following
> > > > inconsistency between TAP 1.0 and TAP 1.1 as regards the format of
> > > > UWS error documents resulting from failed async TAP queries:
> > > >
> > > >    TAP 1.0 Sec 2.7.3:
> > > >       "Error documents for TAP errors must be VOTable documents;
> > > >        any result-format specified in the request is ignored."
> > > >
> > > >    TAP 1.1 Sec 3.3:
> > > >       "Error documents should be in a format that matches the requested
> > > >       format where possible; see DALI for details."
> > > >
> > > >    DALI 1.1 Sec 4.2:
> > > >       "An error document describing errors in use of the DAL service
> > > >        protocol may be a VOTable document (...) or a plain text document."
> > > >
> > > > For an expected VOTable result, this is effectively a downgrade of a
> > > > MUST to a SHOULD for VOTable as the format of the error document.
> > > >
> > > > So a TAP 1.0 client will expect a VOTable error document from a failed
> > > > async TAP query, but may get tripped up by receiving instead a plain
> > > > text error document.  This change is not explicitly noted in
> > > > Appendix A of TAP 1.1 "Changes from TAP-1.0 to TAP-1.1",
> > > > though A.1 says, somewhat misleadingly, "Removed text that duplicates
> > > > material from DALI.".
> > > >
> > > > This looks to me like an oversight since it is (from the client's
> > > > point of view) a backwardly incompatible behaviour change from TAP 1.0
> > > > to TAP 1.1.
> > > >
> > > > Has anybody come across this before, or remember whether it was
> > > > deliberate?
> > > >
> > > > Mark
> > > >
> > > > --
> > > > Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> > > > m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/
> > >
> >
> > --
> > Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> > m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/