Provide guidance on hyperschema and validation #251
Conversation
It's been commonly assumed that hyper-schema keywords apply only
when validation is successful. Be explicit about this, and resolve
ambiguous situations.
Most notably, remove any burden on implementations to figure out
what to do with situations such as:
{"not": {"not": {"links": [...]}}}
where the schema containing links technically must validate against
the instance, but any less trivial nesting of "not"s
(including such situations as a "not" inside of a "oneOf" branch
that fails validation while the overall "oneOf" succeeds) rapidly
becomes extremely difficult to reason about.
|
Question: What effect, if any, would hyper-schema defined in "propertyNames" have? I think it would let you build links off of the property names instead of values, which might have some use case? I'm really not sure, so not clear to me whether to allow hyper-schema there ore require that it be ignored. |
|
@Relequestual It mostly has to do with just following through the logical implications of how hyper-schema and validation have to interact. An implementation has to make SOME sort of choice for these things, and it's not clear what that choice is. In most cases, I don't have any specific need for a choice one way or another, I just can't have a probabilistic implementation :-) The ones I'm most concerned about area "oneOf" and "not". For "not", I may re-use a schema that includes hyper-schema to exclude some instances. It's not at all clear, in general, how such hyper-schema keywords could possibly apply, so I don't want to have to invent something for a conforming implementation. I could always split the validation and hyper-schema parts and only combine them with "allOf" when I'm not using "not", but that introduces a lot of complication for schema authors, and I feel like just making it clear that you MUST ignore such hyper-schema keywords is a much better approach. With "oneOf", I think it's pretty straightforward. It's basically a union, and often the instance pieces necessary for the hyper-schema in a non-validating branch won't even be present. So again, it's not clear what to do with them other than ignore, so let's be explicit that they MUST be ignored. That removes the ambiguity from the situation where, more or less by coincidence, it happens to be possible to apply hyper-schema from a non-validating branch to an instance. Detecting that is relatively challenging and does not have a clear benefit, so let's deliberately exclude it. All of this is not so much that I have schemas that need these decisions (although I can probably dig up some old public Riverbed schemas with sufficiently complex oneOf uses), it's that as an implementation author, I have to make some decision on what to do if they occur. And I need to know which decision will cause my implementation to be considered conforming. Does that make sense? It's all about the implementation choices for a generic client, not about having a schema that does this. |
|
OK. Yes. Thanks for your explanation. Having that as my grounding, re-reading the changes makes a lot more sense. I wonder if it should be SHOULD rather than MUST to leave the flexability for potentail use cases, but I'm also inclined to suggest that we should close off that avenue till a use case is presented. |
|
@awwright you indicated on IRC a few days ago that you thought this was "in the right direction" or something of the sort. Could you please review/approve? This is the last thing that I personally really want to get into Draft 06, and @Relequestual has already approved. |
|
Don't have my computer at the moment but this looks fine to merge.
…On Feb 18, 2017 16:30, "Henry Andrews" ***@***.***> wrote:
@awwright <https://github.com/awwright> you indicated on IRC a few days
ago that you thought this was "in the right direction" or something of the
sort. Could you please review/approve? This is the last thing that I
personally really want to get into Draft 06, and @Relequestual
<https://github.com/Relequestual> has already approved.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#251 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAatDdAty0pR42tsNfC8JdRzDzQabk0Bks5rd38UgaJpZM4MA85S>
.
|
This documents the assumptions I have found myself forced to
make while writing a generic hyper-client. There are other workable
assumptions so the exact form (and the use of MUST vs SHOULD)
is open to debate.
It's been commonly assumed that hyper-schema keywords apply only
when validation is successful. Be explicit about this, and resolve
ambiguous situations.
Most notably, remove any burden on implementations to figure out
what to do with situations such as:
{"not": {"not": {"links": [...]}}}
where the schema containing links technically must validate against
the instance, but any less trivial nesting of "not"s
(including such situations as a "not" inside of a "oneOf" branch
that fails validation while the overall "oneOf" succeeds) rapidly
becomes extremely difficult to reason about.