resolve #90 (ObsCore example) and resolve #91 (relax content-type)

[pdowler]

resolve #90 (ObsCore example) resolve #91 (relax content-type in response headers) make INFO element with standardID a MUST

Hopefully these are final changes before PR.

[pdowler]

Will give other authors a chance to comment.

[Bonnarel]

Le 01/02/2023 à 01:21, Patrick Dowler a écrit :

Will give other authors a chance to comment.

— Reply to this email directly, view it on GitHub https://github.com/ivoa-std/DataLink/pull/93#issuecomment-1411258925, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMP5LTDTBS7HXCLVRN7A26DWVGUCPANCNFSM6AAAAAAUNB6ETQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>

OK for me. François

[msdemlei]

On Tue, Jan 31, 2023 at 04:21:58PM -0800, Patrick Dowler wrote:

Will give other authors a chance to comment.

I'm fine with the drift of the comment, and feel free to merge. However, I'm not quite sure why you went from MUST to {\bf must} in L507; by RFC whatever, that's equivalent, but I suspect people will still wonder whether there's any special meaning to the difference in typography.

Similarly nitpicking, your "the content-type header of the response MAY be any value allowed by the VOTable specification" technically means "it can be anything at all". I'd prefer if this said

the content-type header of the response MUST be one of the media types allowed by the VOTable specification, [and so on as it's now]

[Bonnarel]

Le 01/02/2023 à 09:29, msdemlei a écrit :

On Tue, Jan 31, 2023 at 04:21:58PM -0800, Patrick Dowler wrote:

Will give other authors a chance to comment.

I'm fine with the drift of the comment, and feel free to merge. However, I'm not quite sure why you went from MUST to {\bf must} in L507; by RFC whatever, that's equivalent, but I suspect people will still wonder whether there's any special meaning to the difference in typography.

Similarly nitpicking, your "the content-type header of the response MAY be any value allowed by the VOTable specification" technically means "it can be anything at all". I'd prefer if this said yes good point Markus.

the content-type header of the response MUST be one of the media types allowed by the VOTable specification, [and so on as it's now]

— Reply to this email directly, view it on GitHub https://github.com/ivoa-std/DataLink/pull/93#issuecomment-1411650164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMP5LTGSG7ZWPSUXHQVHMRLWVINIHANCNFSM6AAAAAAUNB6ETQ. You are receiving this because you commented.Message ID: @.***>

[pdowler]

on MUST vs {\bf must}.... the document uses the latter form (or unformatted) everywhere else. I can make the change in the other direction if that's what we should be doing.

git blame didn't really help me figure out where this came from, but the section on conformance terms (eg MUST) was added by Mark. Otherwise we've all used unformatted and bold lowercase.

[msdemlei]

On Wed, Feb 01, 2023 at 11:57:52AM -0800, Patrick Dowler wrote:

on MUST vs {\bf must}.... the document uses the latter form everywhere else. I can make the change in the other direction is that's what we should be doing.

I don't care at all, as long as it's halfway consistent so people don't wonder whether varied typography means something. In the current master, I still count two MAY, seven SHOULD, and two MUST (not counting the ones in the preamble).

I note in passing that writing {\bf xy} has been (more or less) deprecated for about two decades now because it breaks NFSS (i.e., it would be trouble once we changed the base font in ivoatex). We should rather use \textbf{must}.

I can make the edits either towards boring old MUST, \textbf{must} throughout or possibly even \rfcmust, \rfcshould, and \rfcmay (for eventual inclusion in ivoatex). While the latter may sound a bit overengineered, now that I think of it they may actually be useful for people writing validators... but that's probably another discussion.

But then I'm grateful if you push whatever pattern you prefer into this PR...

[pdowler]

along with this, the CADC datalink service you get to by querying the ivo://cadc.nrc.ca/argus TAP service now support the applicable DataLink-1.1 features:

• always include the standardID INFO element
• accept both VOTable mimetypes in RESPONSEFORMAT and set that same value in response header
• include 3 new optional fields
• added descriptions for the new fields

example for public data:

https://ws.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/caom2ops/datalink?ID=ivo://cadc.nrc.ca/IRIS?f212h000/IRAS-25um

For CADC, link_auth is always optional and link_authorized is used, will remove our custom "readable" once our UI is adapted to use link_authorized).

We have not added the code to populate content_qualifier yet but it is feasible to do it - just don't have time right now.

[pdowler]

Thanks Mark. Unsufficient latex-fu on my part :-)