Add "contentSchema" #673
Add "contentSchema" #673
Conversation
Also clean up some of the wording for the other content keywords. Include a JWT example.
|
Last call for comments on this- it's been up for two weeks and has two approvals, so I'll merge it in the next day or two. |
| <t> | ||
| The value of this property MUST be a string. | ||
| The value of this property MUST be a string, which MUST be a media type, | ||
| as defined by <xref target="RFC2046">RFC 2046</xref>. |
There was a problem hiding this comment.
What are the expectations on implementations here? There are a LOT of media types. Are we expected to be able to identify (if not validate) them all?
There was a problem hiding this comment.
See the Implementation Requirements section. The short version is that you aren't expected to be ably to identify or validate any of them. The slightly longer version is that it's basically like format, except we are not picking a default set of recognizable values.
I kind of expect most implementations to handle these as annotations passed on to the application, maybe with a callback mechanism to automatically validate the decoded text against contentSchema.
Since this is not changed in this PR (I just moved the phrase "media type" from the first paragraph to the second), I'm not going to hold up this PR on it. Although if you think there is something specific to contentSchema (as opposed to contentMediaType) that needs clarification I would be happy to work on that a bit more.
There was a problem hiding this comment.
Hmm... I could see that people might expect contentSchema to always be implemented, without really thinking about the dependency on having the right plugin (or whatever) for the underlying contentMediaType and contentEncoding values. Is that your concern, @gregsdennis ?
There was a problem hiding this comment.
My concern is that the "MUST" implies that implementations are required to be able to validate that a given value is a media type as defined by RFC 2046.
If it's like format, then maybe similar language can be used that allows implementations to defer that validation to the application in the form of returning the value as an annotation, as you said.
There was a problem hiding this comment.
@gregsdennis the "Implementation Requirements" section is practically copy-pasted from the format section. What is missing? I don't want to repeat them for each keyword, if you read the spec outside of the diff lines I think it's already clear. Can you point to specific problems in that section?
Also, I don't hear anything specific to contentSchema here (you're talking about moved text, not new requirements) so please file it as a new issue. This PR is just for contentSchema.
|
Fair enough. Carry on. |
Addresses #669 (paging @gcallaghan)
Also clean up some of the wording for the other content keywords.
Include a JWT example.