fix the type for $recursiveAnchor

[karenetheridge]

Keywords from draft2019-09 are intended to be silently accepted (with a deprecated annotation), not cause validation failure.

[jdesrosiers]

Good catch.

I'm not sure why this is in the schema in the first place. The keyword was removed. Why is it important that it's a boolean if the keyword has no effect anyway?

I'm not saying remove it now, but it's definitely something to clean up for the next release.

[Relequestual]

Thanks @karenetheridge!

I agree in that I don't want to modify the meta-schema now. The impact is likely pretty low given it's depricated.

This would be a case where we release a new meta-schema with a new current year-month ID, as is allowed by the spec.

If you feel strongly we should, then we can proceed to, but we have to consider how we represent that new schema in multiple places.

We probably wouldn't find anyone using the new ID as their $schema value I suspect.

@karenetheridge did you just notice this by chance or were you executing a use case?

[karenetheridge]

I believe the intent was to permanently reserve these keywords so implementations couldn't create custom keywords with the same name. If we want to really be strict about this, we could change the schema to false (or rather, not: true, to live alongside the deprecated: true, rather than specifying a type.

@karenetheridge did you just notice this by chance or were you executing a use case?

I was validating a schema from a stackoverflow question that happened to use the draft2019-09 metaschema, but my command-line evaluator was failing to see the $schema keyword and ran it against draft2020-12 instead, therefore hitting this type check.
Now fixed: https://metacpan.org/release/ETHER/JSON-Schema-Modern-0.549/changes

[karenetheridge]

This was reverted from the master branch, but I think we should still apply it to draft-next.

[jdesrosiers]

This would be a case where we release a new meta-schema with a new current year-month ID, as is allowed by the spec.

I disagree. This is clearly a bug and we've always fixed bugs without changing the identifier in the past. In any case, we discussed that changing the meta-schema identifier without changing the dialect was a bad idea and we weren't going to do it (json-schema-org/community#48). We came up with a workable alternative, but until we update the spec, we can't implement that alternative. Therefore, our choices are to leave it broken or fix it without id changes. Despite the low impact of the bug, I'd say fix it.

I believe the intent was to permanently reserve these keywords so implementations couldn't create custom keywords with the same name.

That's possible, but I don't think it achieves that goal. If someone wanted to make a vocabulary that redefines $recursiveAnchor, they would need to make their own dialect schema and wouldn't include that check. So, all that really achieves is marking the keyword deprecated in the 2020-12 dialect, which is not correct. In any case, nothing in the spec says that vocabularies can't redefine keywords from the past or the present, so it would be inappropriate for the meta-schema to enforce that in any way.

[karenetheridge]

If someone wanted to make a vocabulary that redefines $recursiveAnchor, they would need to make their own dialect schema and wouldn't include that check

If they had a $ref or $dynamicRef on the specification metaschema, they couldn't not include it. Sure, they could define a whole new dialect that wasn't based off of draft2020-12 at all, but that's a much bigger undertaking and would require changing the code of an implementation, rather than simply defining a new schema document -- and if you're able to modify an implementation, you're already free to do whatever you like with json schema keywords anyway.

This is clearly a bug and we've always fixed bugs without changing the identifier in the past

I thought we had too but I didn't see this as the hill I wanted to die on.

In any case, nothing in the spec says that vocabularies can't redefine keywords from the past or the present

I think this section comes close:

This document defines a core vocabulary that MUST be supported by any implementation, and cannot be disabled. Its keywords are each prefixed with a "$" character to emphasize their required nature.

But I agree that if we want to put something in the metaschema that prohibits the re-purposing of past kewords, the spec should say something explicitly about it (and list them). I also thought we had some wording strongly discouraging the use of custom keywords starting with "$", but I can't find it.

If we had explicit wording prohibiting the redefinition of existing or past '$' keywords (and possibly defining new ones), then the metaschema can just say: "patternProperties": { "^\$": false }