Mime type for annotated data

[Laurent Michel]

Hello folks,

Following the Dave's request, I reply on one list, this one with the wider scope. I hope I will touch every concerned people despite all.

There is a consensus to say that there is no need for a mime type or a query FORMAT that refers to annotation, except perhaps for a prototying phase which is the situation now.
In this case the good candidate would be application/x-votable+xml;content=mivot since it is consistant with Datalink.
The Markus suggestion (application/x-votable+xml;version=1.6) does not fit very well since MIVOT is not connected with any specific VOTable version.

As we are in a testing phase, I think that the HTTP negotiation is not an issue.
A client explicitly requesting for annotated data (either with the HTTP accept(s) or the FORMAT query parameter) is likely to be MIVOT aware, and we can assume that it is flexible enough to accept responses as simple VOTables (application/x-votable+xml)

In conclusion, I would suggest  the following implementation guideline:
1) A service can return annotated data without using a specific Content-type.
2) A service that needs to be able to turn on the annotation process on demand can do this by accepting FORMAT=application/x-votable+xml;content=mivot. However, it must return  Content-type=application/x-votable+xml to be consistent with 1)
3),A client that claims to only accept  Content-type=application/x-votable+xml;content=mivot would get a 406 from services that do not annotate.
4- once the test period is over, 2) and 3) become obsolete.

Laurent

> On 9 Dec 2024, at 21:42, Patrick Dowler via apps <apps at ivoa.net> wrote:
> 
> 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
>>