Mime type for annotated data

[Patrick Dowler]

I cannot disagree with anything Markus said and feel pretty convinced
that services *should* just include annotations in every VOTable.

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

On Mon, 9 Dec 2024 at 01:01, Markus Demleitner via dal <dal at ivoa.net> wrote:
>
> 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
>