TAP 1.0/1.1 inconsistency: error document format

[Mark Taylor]

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/