Canonical RESPONSEFORMAT values to use for different VOTable serializations?

[Markus Demleitner]

Hi Gregory,

On Wed, Aug 19, 2026 at 04:45:52AM +0000, Dubois-Felsmann, Gregory P. via dal wrote:
> A since-superseded draft of TAPRegExt 1.1
>
> https://www.ivoa.net/documents/TAPRegExt/20151117/WD-TAPRegExt-1.1-20151117.html
>
> appears to be the only place on ivoa.net where candidates for
> canonical RESPONSEFORMAT values for requesting specific
> serializations of VOTable can be found in a document.

Somewhat regrettably, there are no canonical media types for the
various VOTable serialisations, at least not in the sense of strings
you can simply compare.

There is the serialization parameter to the application/x-votable+xml
parameter as defined in VOTable sect. 8:
<https://ivoa.net/Documents/VOTable/20250116/REC-VOTable-1.5.html#tth_sEc8>.

As is shown there, however, there can be additional parameters, and,
SIGH, RFC 2045 media types are case-insensitive (oh pain!).  So, with
the current level of standardisation, you really have to write (or
use) a media type parser and look at the serialization parameter if
you want plausible interoperability.

Could we make that simpler?  Sure.  DALI could define canonical,
opaque strings, for example, possibly building on what TAPRegExt has
done (the ivoids there were defined before we had the serialization
parameter, and i probably wouldn't have defined them if it had.  But
having some pre-defined strings you wouldn't have to parse like
TAPRegExt's StandardsRegExt keys would still be nice).

Could we make that less haphazard?  Sure.  Someone would need to
follow the rules of RFC 2045 and mint a proper media type for
VOTables.  As part of this process, we would produce a document that
strictly defines the legal parameters for that proper VOTable media
type.

Yes, that wouldn't alleviate the need for parsing the input to
RESPONSEFORMAT, but at least we'd finally be following the IETF rules
by their spirit.  We've thought about that occasionally, but frankly:
Changing the VOTable media type seems much too difficult by now, and
the IANA wouldn't let us keep x-votable.  So, I don't think is will
ever happen, and in a note on "Dirty secrets of the VO" I've always
wanted to write I'd note about that much.

>     <outputFormat ivo-id="ivo://ivoa.net/std/TAPRegExt#output-votable-binary2">
>     <outputFormat ivo-id="ivo://ivoa.net/std/TAPRegEXT#output-votable-td">
>
> This example is not in more recent drafts and appears to have been moved to

Oh, but it is: See
<https://github.com/ivoa-std/TAPRegExt/blob/master/sample.xml>.

After all that, here's my implementation advice: don't sweat
responseformat.  Proper clients shouldn't have much business
requesting one sort of VOTable over the other, and requesting other
formats is something that's outside of VO and interoperability
anyway (for now, at least; this might be different when we bless,
say, parquet+VOTable as a second first-class response format), so
there's probably some human in the loop doing something manually.

If you can give them a chance to discover what sort of values they
can stick into RESPONSEFORMAT, you've done what you can.

Enabling that discovery, however, still is a bit of a problem *right
now*.  But you can already adopt VODataService 1.3's stat child (cf.
<https://ivoa.net/documents/VODataService/20260601/PR-VODataService-1.3-20260601.html#tth_sEc3.5>)
for a RESPONSEFORMAT inputParam in your vs:ParamHTTP interface in
your capabilities.  That's (regrettably) a somewhat new thing to do,
but it solves quite a few of our problems, and the earlier we start
showing this sort of parameter metadata, the earlier our users will
start looking of it.

Thanks,

         Markus