TAP 1.0/1.1 inconsistency: error document format

[Patrick Dowler]

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/