Skip to content

Commit 8fba211

Browse files
committed
Incorporate awwright's suggestions on cref #1
Better explanation of the concerns around and possible future direction of $schema usage. Also add an XML comment to remind us of the most notable concern, so we can skip the whole thing where we forget about it and then argue about it until we work it out again. Which of course has never happened...
1 parent 66e0046 commit 8fba211

File tree

1 file changed

+14
-3
lines changed

1 file changed

+14
-3
lines changed

jsonschema-core.xml

+14-3
Original file line numberDiff line numberDiff line change
@@ -436,10 +436,21 @@
436436
</t>
437437
<t>
438438
<cref>
439-
While this pattern is likely to remain best practice for schema authoring,
440-
implementation behavior is subject to be revised or liberalized in future
441-
drafts.
439+
Using multiple "$schema" keywords in the same document would imply that the
440+
vocabulary and therefore behavior can change within a document. This would
441+
necessitate resolving a number of implementation concerns that have not yet
442+
been clearly defined. So, while the pattern of using "$schema" only in root
443+
schemas is likely to remain the best practice for schema authoring,
444+
implementation behavior is subject to be revised or liberalized in
445+
future drafts.
442446
</cref>
447+
<!--
448+
In particular, the process of validating an instance, including validating a
449+
schema as an instance against its meta-schema, only allows for a single set
450+
of rules across the entire instance document. There is no equivalent of
451+
changing the meta-schema partway through the validation for non-schema
452+
instances.
453+
-->
443454
</t>
444455
<t>
445456
Values for this property are defined in other documents and by other parties.

0 commit comments

Comments
 (0)