Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add section about keyword interaction mechanics being illustrative #1445

Merged
merged 9 commits into from
Jun 18, 2024
28 changes: 23 additions & 5 deletions jsonschema-core.md
Original file line number Diff line number Diff line change
Expand Up @@ -523,11 +523,29 @@ to inform the user of the evaluation path that produced the error or annotation.

### Keyword Interactions

Keyword behavior MAY be defined in terms of the annotation results of
[subschemas](#root) and/or adjacent keywords (keywords within the same schema
object) and their subschemas. Such keywords MUST NOT result in a circular
dependency. Keywords MAY modify their behavior based on the presence or absence
of another keyword in the same [schema object](#schema-document).
Unless otherwise specified, keywords act independently.

Keywords MAY modify their behavior based on the presence, absence, or value of
another keyword in the same schema object. Such keywords MUST NOT result in a
circular dependency.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems unexpected to have a MUST NOT here about this. It's not wrong, but pretty much all the other MUSTs are either what implementations must do, or what schemas must conform to. This is something another vocabulary or keyword specification must do, so only relevant for a minuscule fraction of readers. Not that it shouldn't be here, but maybe some clarification of the context, what this MUST applies to, would help.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was already present, I just flipped the sentences because it made more sense to me and felt less redundant this way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that it shouldn't be here, but maybe some clarification of the context, what this MUST applies to, would help.

I have a bigger issue with the flow of the document, and I intend to make some bigger changes to the organization. I think this is better saved for when I tackle that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, no objection to that.


Supplementary specifications are encouraged to specify any dependencies as part
of the dependent keyword (i.e. the keyword whose behavior is modified).

Within this document, keyword dependencies are expressed using one of the
following mechanisms:

- Static dependencies, in which the dependency relies on the presence or
contents of another keyword.
- Dynamic dependencies, in which the dependency relies on the evaluation of
another keyword against an instance. This dependency may be on either the
annotations produced by the keyword or the validation result of its
subschema(s).

These mechanisms are used merely to describe dependencies; they are for
illustrative purposes and not prescriptive. Implementations MAY use whatever
mechanisms make sense given the needs of their architecture and language in
order to achieve the specified behaviors.

### Default Behaviors {#default-behaviors}

Expand Down