TAP 1.0/1.1 inconsistency: error document format
Mark Taylor
m.b.taylor at bristol.ac.uk
Fri Oct 10 09:56:11 CEST 2025
Pat,
I generally agree with that. So a fix in DALI could look like
changing text in the DALI 1.2 current WD section 5.2 from:
"An error document describing errors in use of the DAL service
protocol may be a VOTable document [ref] or a plain text document."
to
"An error document describing errors in use of the DAL service
protocol must be a VOTable document [ref] if the client is
expecting a VOTable response; in other cases it should usually
be a plain text document."
The phrase before the semicolon would supply what I've been
complaining about here. The second part could be written more
prescriptively, but I've put "should usually" instead of "must"
to leave open the possibility of JSON or whatever that somebody
mentioned, I don't know if that's really a good idea or should
be tightened up.
Although I agree that text/plain is generally easier for clients,
what's not easier is having to examine the content-type and adjust
the parsing on the basis of that - you want to know what to expect.
Relevant: since I brought this up the Rubin service has now been
changed to work as expected (error document is VOTable not plain text),
which I believe is how all other services do it, so in practice this
isn't so much of a problem for me (I'm probably not going to make
code changes unless it comes up again).
Mark
On Thu, 9 Oct 2025, Patrick Dowler wrote:
> 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/
> >
> >
>
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk https://www.star.bristol.ac.uk/mbt/
More information about the dal
mailing list