"profile" media type parameter usage

[handrews]

In mnot/I-D#175 @dret states:

profile was not intended to refer to a schema. it is intended to refer
to a profile, which is defined as extending and/or constraining the
original media type. the spec gives examples.

yet in issue #26 filed here by @dret it looked like we had received his approval on how we are wording our specification around the use of "profile"

@dret can you help us out here? Is what we have acceptable or not? To me it seems like JSON Schema is doing exactly this- further constraining the application/json media type by declaring that only a subset of possible documents are valid rather than all possible expressions of the JSON syntax. But it sounds like you do not view it this way.

Also in the same issue in mnot/I-D:

a profile media type parameter has to be allowed by the media type.
very few media types do this. so while i think that it's possible (and
maybe even better) to use a media type profile parameter, if that
mechanism is required, in many cases the media type simply will not
allow such a parameter to be used.

Since application/json does not explicitly specify profile as a media type parameter, does that mean that even if "profile" is correct we cannot use it with application/json? Do we need to specify an application/instance+json media type in order to add a parameter (whether it is "profile" or not?) Honestly my entire API evolution strategy relies on having schema URIs in a media type parameter so it's a huge problem for me if we can't do this somehow.

The balkanization of IETF standards is immensely frustrating. "Look, here are these two great ideas that do not conflict in any way and perfectly complement each other, but you cannot use them together because the two RFC authors did not coordinate and/or wrote their RFCs at different times!"

Finally:

in my mind, "profile", "type", and "describedBy" are distinct, but i
have heard world views where they are more similar and do have quite
some overlap.

@dret if aspects of this distinction are relevant to JSON Schema and not covered in #26 could you please elaborate?

[awwright]

It's my understanding we can update the JSON media type registration to add the 'profile' parameter -- with the same semantics as expected, nothing JSON Schema specific.

Let's keep investigating this.

[handrews]

@awwright oh cool, glad you've thought of this. Yeah, let's keep this issue open to track that dependency.

Would it make sense to create an "RFC" milestone to group issues that need to be handled before RFC but are not directly part of the draft iteration process?

[dret]

On 2017-01-15 12:25, Austin Wright wrote: It's my understanding we can update the JSON media type registration to add the 'profile' parameter -- with the same semantics as expected, nothing JSON Schema specific. Let's keep investigating this.

please keep in mind that from the way RFC 6906 defines profiles, schemas are not profiles. what would be a profile of JSON is for example I-JSON a la RFC 7493 (i.e., it's still just JSON, but a more constrained version of it). for more background, please refer to RFC 6906, and maybe to this: http://dret.typepad.com/dretblog/2016/05/resource-profiles-and-types.html

[handrews]

@dret you and @awwright had this conversation in #26 and you gave your approval. What's changed?

[awwright]

As I understand that was about the link relation types, this is about the media type parameter.

…

On Jan 15, 2017 20:53, "Henry Andrews" ***@***.***> wrote: @dret <https://github.com/dret> you and @awwright <https://github.com/awwright> had this conversation in #26 <#26> and you gave your approval. What's changed? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#222 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAatDfU-QEN9qvmeWVYZb283FE9yJ9xdks5rSunWgaJpZM4La9ie> .

[handrews]

@awwright , @dret's comment about schemas not being profiles (and the blog post he linked) are not specific to link relation or media type parameter. A profile is semantically a profile either way it's expressed, that's the point of allowing both expressions, really.

[handrews]

I'm guessing there is one point of view that looks at a schema as defining a (possibly extremely) restricted subset of JSON, and the other that views it as carrying more meaning than that.

Looking @dret's example of I-JSON, that's a generally usable subset of JSON. Schemas are there to constrain the set of documents to a specific use, which is conceptually a very different thing. So if that's an ideal example (and since @dret wrote the profile spec we can assume it is), I'm likely to agree that schemas are not profiles.

I think it is critical to be able to request conformance to a schema through media type negotiation, so we should make that possible. We may need to choose or invent another relation, though. I'd like to use an existing one (and likewise a media type parameter that would be recognizable) if possible, but only if it actually fits.

[dret]

On 2017-01-15 20:22, Henry Andrews wrote: @awwright <https://github.com/awwright> , @dret <https://github.com/dret>'s comment about schemas not being profiles (and the blog post he linked) are not specific to link relation or media type parameter. A profile is semantically a profile either way it's expressed, that's the point of allowing both expressions, really.

agreed on this one. the fundamental question is whether a schema *is* a profile or is not. i don't think it is, but that's just my opinion, based on how i see schemas and profiles. i do not have the authority to "approve" how people use profiles. all i can say is that when i wrote the spec, i had different scenarios in mind, and i have tried my best to explain how they are different from schemas. if people still think that they want to use profiles as a way to signal schemas, then this is what is going to happen. as mentioned in the blog post and elsewhere, link relations are sufficiently fuzzy to make it a futile exercise to try to use spec exegesis to determine whether that's right or wrong. personally, i would think that "type" is much more fitting for this scenario, but that spec is equally fuzzy. coming back to the podcast example from the spec: i'd expect the "type" of a feed to link to the schema, linking the instance to the way how the class is defined. and in some cases i'd expect the "profile" of a feed to identify the fact that a feed indeed is a podcast, making it explicit that the specific feed instance follows all the podcast rules, while still being a legitimate feed.

[dret]

On 2017-01-15 20:30, Henry Andrews wrote: Looking @dret <https://github.com/dret>'s example of I-JSON, that's a generally usable subset of JSON. Schemas are there to constrain the set of documents to a specific use, which is conceptually a very different thing. So if that's an ideal example (and since @dret <https://github.com/dret> wrote the profile spec we can assume it is), I'm likely to agree that schemas are not profiles.

thanks, and good to hear that at least my point of view makes some sense. not everybody might agree with it, but that's a different thing.

[handrews]

@dret said:

personally, i would think that "type" is much more fitting for this scenario, but that spec is equally fuzzy.

Yeah, I noticed that :-/

I agree that it seems to be the closest one. Perhaps we can simply define and register a media type parameter for specifying type analogous to the profile one? I have on idea whether that sort of thing is likely to be embraced or frowned upon in the IETF.

[dret]

On 2017-01-17 12:24, Henry Andrews wrote: @dret <https://github.com/dret> said: I agree that it seems to be the closest one. Perhaps we can simply define and register a media type parameter for specifying type analogous to the profile one? I have on idea whether that sort of thing is likely to be embraced or frowned upon in the IETF.

my feeling is that if it's defined and used and deployed, you might get through with it. but JSON is an important thing, so doing anything that involves core JSON specs is not going to happen easily. one question you could ask yourself is whether you really need this as a media type parameter. XML, which is rather schema-centric, never had it and simply had a variety of embedded signals, depending on the schema language (for example, DTD and XSD have their own way of doing it). that seemed to work well enough, and in scenarios where you want to signal the schema outside of the instance, you simply have to make that part of your protocol design.