adding possibility of completing mime-type by dataproduct_type parameter

[Bonnarel]

The pull request adds in the content_type subsection the possibility to add a parameter in the mime-type in order to type the dataproduct retrieved by the link. This is related to issue #42. the proposal is to uses the parameter "dataproduct_type" and to reuse standard lists of values (for that, ObsCore, Vocabulary WG)

[msdemlei]

A couple of comments:

(a) Please don't have lines longer than 72 characters -- it spoils the diffs and will lead to unnecessary conflicts.

(b) I'm always unhappy with "may" in specs. I'd say we should be clear under which circumstances the product type helps clients (and, frankly, I don't have language to propose here just yet), and then say people should (or perhaps "are strongly encouraged to foster useful interaction with client programmes") have the media type parameter.

(c) Just cite the vocabulary as it is now; so, I'd say it should just be: "The values of the dataproduct_type parameters must be taken from the IVOA vocabulary \url{http://www.ivoa.net/rdf/dataproduct_type}."

(d) I'd say as a matter of courtesy, the change of the makefile should be taken out of the PR.

[Bonnarel]

Hi markus

Le 05/05/2020 à 15:23, msdemlei a écrit :

A couple of comments:

(a) Please don't have lines longer than 72 characters -- it spoils the diffs and will lead to unnecessary conflicts.

OK Sorry. Will fix this after the email

(b) I'm always unhappy with "may" in specs. I'd say we should be clear under which circumstances the product type helps clients (and, frankly, I don't have language to propose here just yet), and then say people should (or perhaps "are strongly encouraged to foster useful interaction with client programmes") have the media type parameter.

Hum!. Only when the link is a dataproduct. This parameter is useless for documentation and may be for #proc. or auxliary.

(c) Just cite the vocabulary as it is now; so, I'd say it should just be: "The values of the dataproduct_type parameters must be taken from the IVOA vocabulary \url{http://www.ivoa.net/rdf/dataproduct_type} http://www.ivoa.net/rdf/dataproduct_type%7D."

Well if the dataproduct_type vocabulary is a recom and still is consistent with ObsCore we can do that

(d) I'd say as a matter of courtesy, the change of the makefile should be taken out of the PR.

OK

Cheers

François

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ivoa-std/DataLink/pull/43#issuecomment-624052298, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMP5LTCB7N6RHKF4EG2YYYTRQAHNBANCNFSM4MZRLSSQ.

[Bonnarel]

Changes made following Markus comments

[pdowler]

The issue is still marked TBD and I thought we would confirm going ahead with this at the session. I am fine with it personally...

[msdemlei]

So... prompted by Norman I've made the mistake of actually reading RFC 2045, which, on the topic of media type parameters says this:

""" The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining content type or subtype or they may be optional. MIME implementations must ignore any parameters whose names they do not recognize.

For example, the "charset" parameter is applicable to any subtype of "text", while the "boundary" parameter is required for any subtype of the "multipart" media type.

There are NO globally-meaningful parameters that apply to all media types. Truly global mechanisms are best addressed, in the MIME model, by the definition of additional Content-* header fields. """

While I would yet allow that the "meaningful" up there may not entirely preclude the use of ad-hoc parameters, I think the rest of this text makes it very clear that you're not supposed to just add parameters willy-nilly.

Datalink already is in trouble because of the content="datalink" clause, but then that's modifying x-votable+xml. so, disregarding the little scandal that we've been using a non-standard media type for decades we at least could legalise that (and the serialization parameter from VOTable itself) if we ever define a proper VOTable media type.

If, on the other hand, we now add parameters to essentially all other media types, most of which are totally not under our control, I'd say we shouldn't do it. It's just too much of a violation of RFC 2045.

And certainly if we did this, it can't happen based on a github discussion -- it needs to go the mailing list.

[pdowler]

Add a new field to links response (name: dataproduct_type? content_qualifier?) for a vocabulary term (use case: data product type vocab). Optional column in 1.1, maybe mandatory later.

[Bonnarel]

replaced by PR #56 (DataLink-#51)