Mime type for annotated data

[Markus Demleitner]

Dear Colleagues,

On Fri, Dec 06, 2024 at 11:04:23AM -0800, Patrick Dowler via apps wrote:
> still, if I was prototyping something, I would start with
> content=mivot and see if it's useful/sufficient/consistent. I know
> that in our service implementations if a caller requests
> RESPONSEFORMAT={something} we always make sure that exact mime-type is
> in the content-type header of the output... so if someone queries with
> RESPONSEFORMAT=application/x-votable+xml;content=mivot and our service
> cannot map the QUERY to a data model, what would we do?
> - respond with a different content-type than requested (but more "correct")?
> - fail because we cannot provide content=mivot ??
> - respond with the  requested mime-type but put an empty mapping
> element in there??

For something like application/x-votable;serialisation=BINARY2 it
seems evident to me that the client is just indicating it understands
BINARY2, and I'm rather sure we'd be doing the users a disservice to
fail.  Other than that, I'd say we should follow the rules for HTTP
content negotiation (which we probably should have used in the first
place, even if it *is* somewhat messier) as closely as we can:

  If an Accept header field is present, and if the server cannot send
  a response which is acceptable according to the combined Accept
  field value, then the server SHOULD send a 406 (not acceptable)
  response.

Of course, "acceptable" is a much less dramatic word with the complex
specifications in Accept versus the one-string thing in
RESPONSEFORMAT...  But that's really tangential and would be another
topic for DALI.

For what we are talking about here, though, I am almost entirely
certain that we do *not* want to indicate presence or absence of
mivot blocks in the media type.  You see, the wide majority of
VOTables out there will have coordinates, and since we kept COOSYS
inadequate, pointing towards DM annotation for a comprehensive
solution, these will *all* have to contain mivot annotation.
Incidentally, similar considerations apply for time and photometry
and many other things.

Hence, having DM annotation necessarily needs to be the default
(unless we fix COOSYS and friends, of course, which I'd still be in
on), and adding some media type parameter to express "do what you
need to do" seems unwise.  Against that, having a parameter to say
"don't do DM annotation" seems unnecessary again, in particular
because any compliant VOTable parser will grok annotated VOTables,
just skipping the extra RESOURCE.

I give you that *for development* it's nice to let service software
spit out non-annotated VOTables by default for a time and then have
some way to tell it "I'm experimenting, do give me your new-fangled
things".

But we don't need some sort of anointed practice for a secret
handshake between bleeding-edge software and a freshly extended
server.  DaCHS, for instance, is using
application/x-votable+xml;version=1.6 to indicate "dump whatever you
currently implement of MIVOT into this file".  I'd argue that ought
to be fine as long as all parties agree this is for development and
not for eternity.

In operations, I am absolutely sure that servers should produce DM
annotation when clients just request VOTables (with the reservations
I made above, that is).

           -- Markus