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

Generative use case guidance #793

Merged
merged 1 commit into from
Sep 3, 2019

Conversation

handrews
Copy link
Contributor

This is going to be a powerful technique for generative use
cases, which have been observed either requiring references
(as opposed to subschemas) in certain places, or implementing
various sorts of inferencing around references on their own
or in conjunction with other keywords.

For example, one OpenAPI documentation tool assumes that
in an "allOf" of several references, the first is a base
class of some sort. While this is not correct behavior
by either JSON Schema or OpenAPI, it demonstrates a feature
built by making implicit assumptions about certain references.

This section provides a recommendation for making such
behavior explicit, and also guides writers of such tools
to the concept of extension vocabularies and annotations.

This is going to be a powerful technique for generative use
cases, which have been observed either requiring references
(as opposed to subschemas) in certain places, or implementing
various sorts of inferencing around references on their own
or in conjunction with other keywords.

For example, one OpenAPI documentation tool assumes that
in an "allOf" of several references, the first is a base
class of some sort. While this is not correct behavior
by either JSON Schema or OpenAPI, it demonstrates a feature
built by making implicit assumptions about certain references.

This section provides a recommendation for making such
behavior explicit, and also guides writers of such tools
to the concept of extension vocabularies and annotations.
@handrews handrews added this to the draft-08 milestone Aug 25, 2019
@handrews handrews requested a review from a team August 25, 2019 06:03
@Relequestual
Copy link
Member

Given this section you've added has no requirement keywords, and is for illustration, does it fit better in an appendix as opposed to the spec body?

@handrews
Copy link
Contributor Author

handrews commented Sep 3, 2019

@Relequestual It is in an appendix. Any <section> tag after the </middle> closing tag is an appendix. There's no <appendix> tag :-)

Copy link
Member

@Relequestual Relequestual left a comment

Choose a reason for hiding this comment

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

Well that's a yes from me then!

@handrews handrews merged commit 5e86633 into json-schema-org:appendix-base Sep 3, 2019
@handrews handrews deleted the sem-ref2 branch May 15, 2020 18:45
@gregsdennis gregsdennis added clarification Items that need to be clarified in the specification and removed Type: Maintenance labels Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Items that need to be clarified in the specification core question
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants