This is not a valid test on systems built with longdoubles (where 16 bytes are allocated to floats) -- as the inputs here are not big enough to cause an overflow.

The test being referred to here is multipleOf.json - "invalid instance should not raise error when float division = inf" - "always invalid, but naive implementations may raise an overflow error". It also fails when 12 bytes are allocated to floats.

http://www.cpantesters.org/cpan/report/d1a4dd18-ca7c-11eb-932e-240466f710c6 http://www.cpantesters.org/cpan/report/2464b1aa-ca7c-11eb-8dc8-abf665f710c6 (on these test systems, doublekind=3, longdblkind=3)

Bumps glob-parent from 5.1.1 to 5.1.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/gulpjs/glob-parent/releases">glob-parent's releases</a>.</em></p> <blockquote> <h2>v5.1.2</h2> <h3>Bug Fixes</h3> <ul> <li>eliminate ReDoS (<a href="https://github-redirect.dependabot.com/gulpjs/glob-parent/issues/36">#36</a>) (<a href="https://github.com/gulpjs/glob-parent/commit/f9231168b0041fea3f8f954b3cceb56269fc6366">f923116</a>)</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/gulpjs/glob-parent/blob/main/CHANGELOG.md">glob-parent's changelog</a>.</em></p> <blockquote> <h3><a href="https://github.com/gulpjs/glob-parent/compare/v5.1.1...v5.1.2">5.1.2</a> (2021-03-06)</h3> <h3>Bug Fixes</h3> <ul> <li>eliminate ReDoS (<a href="https://github-redirect.dependabot.com/gulpjs/glob-parent/issues/36">#36</a>) (<a href="https://github.com/gulpjs/glob-parent/commit/f9231168b0041fea3f8f954b3cceb56269fc6366">f923116</a>)</li> </ul> <h2><a href="https://www.github.com/gulpjs/glob-parent/compare/v5.1.2...v6.0.0">6.0.0</a> (2021-05-03)</h2> <h3>⚠ BREAKING CHANGES</h3> <ul> <li>Correct mishandled escaped path separators (<a href="https://github-redirect.dependabot.com/gulpjs/glob-parent/issues/34">#34</a>)</li> <li>upgrade scaffold, dropping node <10 support</li> </ul> <h3>Bug Fixes</h3> <ul> <li>Correct mishandled escaped path separators (<a href="https://github-redirect.dependabot.com/gulpjs/glob-parent/issues/34">#34</a>) (<a href="https://www.github.com/gulpjs/glob-parent/commit/32f6d52663b7addac38d0dff570d8127edf03f47">32f6d52</a>), closes <a href="https://github-redirect.dependabot.com/gulpjs/glob-parent/issues/32">#32</a></li> </ul> <h3>Miscellaneous Chores</h3> <ul> <li>upgrade scaffold, dropping node <10 support (<a href="https://www.github.com/gulpjs/glob-parent/commit/e83d0c5a411947cf69eb58f36349db80439c606f">e83d0c5</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/gulpjs/glob-parent/commit/eb2c439de448c779b450472e591a2bc9e37e9668"><code>eb2c439</code></a> chore: update changelog</li> <li><a href="https://github.com/gulpjs/glob-parent/commit/12bcb6c45c942e2d05fc1e6ff5402e72555b54b6"><code>12bcb6c</code></a> chore: release 5.1.2</li> <li><a href="https://github.com/gulpjs/glob-parent/commit/f9231168b0041fea3f8f954b3cceb56269fc6366"><code>f923116</code></a> fix: eliminate ReDoS (<a href="https://github-redirect.dependabot.com/gulpjs/glob-parent/issues/36">#36</a>)</li> <li><a href="https://github.com/gulpjs/glob-parent/commit/0b014a7962789b2d8f2cf0b6311f40667aecd62c"><code>0b014a7</code></a> chore: add JSDoc returns information (<a href="https://github-redirect.dependabot.com/gulpjs/glob-parent/issues/33">#33</a>)</li> <li><a href="https://github.com/gulpjs/glob-parent/commit/2b24ebd64b2a045aa167c825376335555da139fd"><code>2b24ebd</code></a> chore: generate initial changelog</li> <li>See full diff in <a href="https://github.com/gulpjs/glob-parent/compare/v5.1.1...v5.1.2">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Bumps normalize-url from 4.5.0 to 4.5.1. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/sindresorhus/normalize-url/commits">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Hello. I'm trying to use CustomProperty in a typescript application. The index.d.ts file seems to be missing undefined or null from the return type of the validator function? Makes it difficult to write a custom validator in typescript without that, as it keeps complaining that the function i write can't be assigned to a CustomProperty.

I am going to see if i can workaround this issue in the meantime. maybe through disabling a lint config?

Thanks.

we need to work out what happens when they are used together

When they are used together, they each assert independently just like any other keyword. That does mean it's possible for them to contradict each other, but not in any way that isn't possible already in JSON Schema. They don't need to interact or override each other. optional would be no more affected by a reference than additionalProperties is. That's what I like about this proposal.

The only change I would make to the proposal is to not forbid required when using optional. That would make a good linting rule, but it's unnecessary from JSON Schema architecture point of view.

Agreed. But this also means we need to work out what happens when they are used together: for example if one schema pulls in another with $ref, and the reffed schema contains one of these keywords and the first schema contains the other. Would 'required' always overrule 'options'? Or the other way around? or should the innermost keyword always overrule the outermost (akin to a subclass overriding a superclass)?

I can see how this could work. It would work similarly to additionalProperties in that it would collect the property names declared by properties and use that to make its assertion. The only change I would make to the proposal is to not forbid required when using optional. That would make a good linting rule, but it's unnecessary from JSON Schema architecture point of view.

Something like this has been requested for a long time, but this is the first proposal of this type that I think fits well into the JSON Schema architecture and I think we should consider it. Requiring properties by default (#1096) and requiredProperties (#846) are problematic because they assert more than one thing: (1) a property schema and (2) that the property is required. This proposal is better because it deals only with which properties are required.

Although I hate to add more keywords that break keyword independence, I think this is a good solution. In particular, this wouldn't have the same kind of problems with combining schemas that additionalProperties has.

I think this one came out of a discussion as to whether it was possible to predict the path a $recursiveRef would take simply by inspecting the schema. I was going through my old test cases and all the other ones for $recursiveRef had been incorporated into the test suite, except for this one.

oops, fixed :)

😆

This seems like a duplicate/variant of #1096.

<!-- Love json-schema? Please consider supporting our collective: 👉 https://opencollective.com/json-schema/donate -->

I don't write objects with optional properties most of the time. I tend to prefer to use polymorphism to allow one of several data structures. When I do have an optional field, it's often something like "comments" or "extra info", and even then I don't have any philosophical objection to simply making it required but allowing it to contain the empty string.

An optional keyword to complement required would greatly benefit me (and hopefully others), without treading on the toes of people who are writing schemata with many optional values.

My proposition is thus:

• Either required or optional may be provided
• It is an error to provide both
• The default remains as it is (everything optional), which is the same as providing required with an empty array
• If optional is provided, anything not mentioned is now required
• Passing an empty array to optional means everything is required

Hope that's both clear and a useful idea.

@karenetheridge $schema is the only keyword that applies to the schema that contains it, rather than to the instance. $schema says nothing about the instance at all. It is essentially a self-annotation on the schema (an annotation rather than a reference because it is not automatically followed). $vocabulary, however, applies to the instance.

Given:

• plain JSON Instance (I)
• Schema (S)
• Meta-Schema (MS)

Those keywords operate as follows:

• $schema in S annotates S with the URI for MS, which can then be applied to S if desired.
• $vocabulary in S annotates I with the vocabulary semantics it could use... but I doesn't use them because it's plain JSON
• $schema in MS annotates MS with the URI for whatever it's own meta-schema is (possibly itself, but maybe not)
• $vocabulary in MS annotates S with the available vocabulary semantics, which it does use when it is in turn applied to I because S is a JSON Schema.

So $schema and $vocabulary aren't operating on the same target, so there's not really a concept of "we should annotate with one vs the other." They don't annotate the same thing.

Resolves #22