TAP 1.0/1.1 inconsistency: error document format

[Patrick Dowler]

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/