TAP 1.0/1.1 inconsistency: error document format

[Patrick Dowler]

In my view the TAP-1.1 text is about as good/correct as possible;
TAP-1.0 was too strict given that we allowed other output formats. The
main problem is that DALI-1.1 is too vague, but I'd also hate for this
to become too complicated.

essentially:
if request is VOTable: error response should be VOTable
if request is csv or tsv: error response in text/plain should be fine
if request is parquet (aka VOParquet):  error response is ???

We currently use text/plain in the last case (prototype) and I don't
see any other choice as viable... to be clear, I think even this is
too much to write in DALI because other services are working with say
xml and json serialisation formats.

I don't want to go so far as to say it was a mistake to ever put error
messages into VOTable, but to be honest text/plain is almost always
easier and better for the client...

So the fix is nominally in DALI, TAP-1.2 could make a more careful
statement aligning with DALI... if we can agree on it we can get it
into 1.2

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Thu, 9 Oct 2025 at 07:47, Grégory Mantelet
<gregory.mantelet at astro.unistra.fr> wrote:
>
> Hi Pat, Mark,
>
> As web client developer, I indeed appreciate when I can have something else than a XML
> document to parse in case of query error. I already have the possibility to get some errors in
> JSON, and apparently Rubin already accept text errors.
>
> On the other hand, I'd also understand if a service cannot supply the error in multiple formats.
> It is not always easy or possible to do. Because of this, I agree with the approach stating
> that the error documents should be provided, as much as possible, in the requested format.
> Then, we should probably say that the fallback standard format must be VOTable. This way,
> it is a safe format that a generic client can rely on. So, in a word, I agree.
>
> Anyway, I am a bit lost. Where do you plan to apply a fix?
> DALI, TAP, UWS?
> If DALI, is it expected in the upcoming DALI-1.2?
>
> Cheers,
> Grégory
>
>
> On 17/09/2025 18:12, Mark Taylor via dal wrote:
>
> 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/
>
>