Open gregsdennis opened 11 months ago
I checked the following for $schema
and it all seems mostly good to me:
There is also https://github.com/json-schema-org/json-schema-spec/issues/1442 where we're discussing a possible tweak to the meta-schema validation language (9.3.3), but I don't think the concept is going to change.
Checking for $id
raises some questions:
$id
defines a new schema resource$id
(maybe relax this? we have 9.1.1 Initial Base IRI to determine an identifier. also this isn't a requirement of implementors, but of authors, which... can we put a SHOULD requirement on authors? how would an implementation enforce that?)$id
). I think the language here could be cleaned up to make that more explicit (if that is what it's trying to say).$id
, the schema's base IRI would fall back to the base IRI of its parent, which may be another schema or ultimately the document which contains it.$id
(which defines the schema boundary) rather than a pointer that goes through it in order to support the case where a schema could be decomposed into its resources. We've had some discussion around this, but I'm not sure if we want to change it. It seems fine as is to me.$id
.$id
as an identifier (might be just data).$id
s.Any other references are minor usages or examples that don't describe the behavior of $id
.
It should also be noted that a lot of these sections have references to $dynamic*
operating within the same referencing system as $id
/$anchor
/$ref
. Part of the "removing bookending" and "removing initial resolution step" work is also "disconnecting$dynamicRef
and $ref
referencing systems." These sections will need to be revisited to address that. (Added to the list above)
I think the identification stuff needs a lot of attention. Probably after the initial release, I'd like to look into completely reworking this area.
Schema document roots SHOULD have an $id (maybe relax this? we have 9.1.1 Initial Base IRI to determine an identifier. also this isn't a requirement of implementors, but of authors, which... can we put a SHOULD requirement on authors? how would an implementation enforce that?)
Agree. I say relax it to make it informal or remove it entirely.
Pointers that cross resource boundaries are not explicitly disallowed, but as guidance to schema authors, the spec recommends using the value in $id (which defines the schema boundary) rather than a pointer that goes through it in order to support the case where a schema could be decomposed into its resources. We've had some discussion around this, but I'm not sure if we want to change it. It seems fine as is to me.
We identified that the behavior of pointers crossing schema resource boundaries needs to specified as "undefined" rather than "allowed" for compatibility reasons. (I feel like we talked about this in more detail than the short convo I linked to, but this is what I found.)
This section might actually be a candidate for removal since we're disallowing unknown keywords now.
That makes sense to me.
Probably after the initial release, I'd like to look into completely reworking this area.
Remember that we can't break things, so it's important to get this right with the first release.
That said, I'm uninterested in re-hashing old conversations, if that's what you're getting at.
I wasn't referring to any old conversations or any behavior changes. I just want to clean up the way the spec presents the concepts. That's why I said it can be done after the initial release.
In What current features should be considered unstable? we determined that most everything available in 2020-12 will be considered stable, with some things having a few changes.
This issue will catalog the things we need to do to resolve that discussion.
$schema
and$id
to ensure that everything is right because we can't change it if it's wrong$dynamicRef
(@jdesrosiers)$anchor
behavior from$dynamicAnchor
(@jdesrosiers)propertyDependencies
(see also #1443) (@gregsdennis & @jdesrosiers)if
/then
/else
to use annotation mechanism~ (@gregsdennis)contains
/minContains
/maxContains
to use annotation mechanism (requires #1358 first)~unevaluated*
(which currently uses annotation mechanism) is clearif
/then
/else
for clarity using evaluation-result dynamic dependency mechanismunevaluated*
)$ref
vs$dynamicRef
)I think that's everything. Edit this comment to add more. I'd like to keep everything here instead of having to search below.
If you start work on one of these, please edit the issue and put your name next to what you're working on so that effort isn't duplicated.
It should also be noted that this is not intended to be everything we need for stable release; only those things covered in the discussion.