TAP 1.0/1.1 inconsistency: error document format

[Grégory Mantelet]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20251009/8594d6f4/attachment.htm>