search

w3c / dx-connegp

Content Negotiation by Profile
https://w3c.github.io/dx-connegp/connegp/
Other
6 stars 5 forks source link

Question on IETF definition of Profile #6

Closed aisaac closed 1 year ago

aisaac commented 5 years ago

This is especially for @RubenVerborgh but I'm eager to hear from others. In https://github.com/w3c/dxwg/issues/963 the new proposed definition for IETF profiles is:

a profile is a description of structural and/or semantic constraints documents can conform to in addition to the syntactical interpretation provided by more generic MIME types.

And now as per this commit it is

a profile is a description of structural and/or semantic constraints documents can conform to structural and/or semantic constraints on representations of documents in addition to the syntactical interpretation provided by more generic MIME types.

@smrgeoinfo suggested that

this IETF definition is that it defines 'profile' to only apply to profiles of MIME types-- certainly a narrower scope that our discussions here.

@RubenVerborgh refuted that, and I note that indeed the last bit of the definition seeks to clarify that profiles are not MIME type focused.

However I am really struggling with the first part of the definition, which mentions "representations of documents" and "structural constraints". Does this part include or exclude the JSON-LD profiles that are different from our profiles, as we're trying to establish here? Can you give examples of "structural contraints that wouldn't be semantic constraints nor syntactical constraint? Maybe a reference to a definition for "structural" would help here.

RubenVerborgh commented 5 years ago

@smrgeoinfo suggested that

this IETF definition is that it defines 'profile' to only apply to profiles of MIME types-- certainly a narrower scope that our discussions here.

@RubenVerborgh refuted that

Indeed. The definition says that profiles provide constraints in addition to those provided by more generic MIME types. For example, there could be a profile saying "use FOAF to represent people" and that profile could apply to text/turtle, application/ld+json, etc. Furthermore, there is nothing that says that profiles could not work together, and thus constrain each other. So there is a flexible relationship between profiles and MIME types; this definition just separates one from the other (which is not the case of some of the other proposed profile definitions).

Does this part include or exclude the JSON-LD profiles that are different from our profiles

An IETF profile can be a JSON-LD profile; we don't see any reason to restrict it. But the DXWG definition can be stricter than the IETF definition, so not a problem.

(I do have a problem with the exclusion of JSON-LD profiles, to the point I will be making below.)

Can you give examples of "structural contraints that wouldn't be semantic constraints nor syntactical constraint?

Also see earlier thinking on https://ruben.verborgh.org/articles/fine-grained-content-negotiation/#where-mime-types-fall-short

The difference between structure and syntax is not black and white, but where I draw the line is "would I need a different parser?". For instance, a JSON document for which specific keys are required, would likely still be parsed with a JSON parser, not with a custom one. Hence, I see JSON as a MIME type, and the requirement of specific keys as a profile.

Maybe a reference to a definition for "structural" would help here.

Constraints about what constitutes a valid (not "meaningful") document that are not covered by the parser corresponding to the MIME type.

agreiner commented 5 years ago

It feels odd to specify that I want a MIME type more than a profile when I want a profile with a certain MIME type. It's a bit like being asked whether I want an orange or to have it delivered on Tuesday.

RubenVerborgh commented 5 years ago

It's a bit like being asked whether I want an orange or to have it delivered on Tuesday.

That is exactly the current limitation of MIME types. You can only say "orange on Tuesday", not "apple or orange" and "Tuesday or Wednesday".

Hence, for backward compatibility, we include "orange on Tuesday", but now can also add "or orange" and "Tuesday or Wednesday".

agreiner commented 5 years ago

So if I want an orange on Tuesday, I have to state that I want an orange and then I have to state that I want an orange and I want it on tuesday, but I want the orange more than I want it on Tuesday. By conflating the two types of profile, you require extra ranking among what should be orthogonal desires. I suppose that ship has already sailed, but it just doesn't bode well for uptake, IMHO.

RubenVerborgh commented 5 years ago

I have to state

Not really, that's just the full version for backward compatibility.

orthogonal desires

They are. By all means, drop the backward compatibility; it was a shortcoming of past solutions that they were not orthogonal.

larsgsvensson commented 5 years ago

@aisaac Has your original questions been satisfactorily answered? There is much discussion but I haven't seen a resolution...

nicholascar commented 4 years ago

@aisaac can you respond about this Issue's status?

larsgsvensson commented 1 year ago

@aisaac this issue is now "due for closing". Last chance to say that you're not satisfied!

aisaac commented 1 year ago

@larsgsvensson I would gladly tell that I am satisfied, but I suppose a bit of due diligence is in order: can you point here to the latest definitions of profiles in the IETF draft and the Conneg spec(s) that have one, please? The links above don't work anymore, and I'm not sure I have the right pointers myself.

larsgsvensson commented 1 year ago

The definition of "profile" in the latest IETF draft (not yet submitted to IETF) is:

a description of structural and/or semantic constraints on representations of resources that apply in addition to the constraints inherently indicated by their MIME type: (I-D §1.1 Terminology)

In the current ED from DXWG-CNEG, the definition is:

A specification that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications. If the specification profiled is a specialized type of specification, for example a data or a functional specification, the profile will be of the same sort - a data or functional profile. This Content Negotiation by Profile specification concerns negotiation for data profiles, and specifies functional profiles for different ways of achieving this. In this document, most occurrences of the term "profile" refer to "data profile". (Content Negotiation by Profile §3 Definitions.)