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 <#43 (comment)>, 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)