Skip to content

Commit 09d6f9d

Browse files
committed
Clarify that plain name fragments are neither canonical or non-canonical (#1192)
* Clarify that plain name fragments are neither canonical or non-canonical Attempt to resolve #937 Add note and cref in appendix A clarifying that we intended to define a URI phrasing which would avoid the requirement to allow for location shadowing in implementations, as this is tricky. Clarifying that plain name fragments should always be supported, and that they only can work in relation to the base URI of the Schema Resource. Otherwise there could be duplicate plain name fragments and addressing wouldn't work.
1 parent df1d381 commit 09d6f9d

File tree

1 file changed

+22
-5
lines changed

1 file changed

+22
-5
lines changed

Diff for: jsonschema-core.xml

+22-5
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,7 @@
5050
</address>
5151
</author>
5252

53-
<date year="2021"/>
53+
<date year="2022"/>
5454
<workgroup>Internet Engineering Task Force</workgroup>
5555
<keyword>JSON</keyword>
5656
<keyword>Schema</keyword>
@@ -1824,10 +1824,10 @@
18241824
reference target, is preferable.
18251825
</t>
18261826
<t>
1827-
An implementation MAY choose not to support addressing schemas
1828-
by non-canonical URIs. As such, it is RECOMMENDED that schema authors only
1829-
use canonical URIs, as using non-canonical URIs may reduce
1830-
schema interoperability.
1827+
An implementation MAY choose not to support addressing schema resources
1828+
(and their subschemas) by non-canonical URIs.
1829+
As such, it is RECOMMENDED that schema authors only use canonical URIs,
1830+
as using non-canonical URIs may reduce schema interoperability.
18311831
<cref>
18321832
This is to avoid requiring implementations to keep track of a whole
18331833
stack of possible base URIs and JSON Pointer fragments for each,
@@ -1836,6 +1836,11 @@
18361836
no point in forbidding it, while others have argued that it complicates
18371837
schema identification and should be forbidden. Feedback on this
18381838
topic is encouraged.
1839+
After some discussion, we feel that we need to remove the use of
1840+
"canonical" in favour of talking about JSON Pointers which reference
1841+
across schema resource boundaries as undefined or even forbidden behavior
1842+
(https://github.com/json-schema-org/json-schema-spec/issues/937,
1843+
https://github.com/json-schema-org/json-schema-spec/issues/1183)
18391844
</cref>
18401845
</t>
18411846
<t>
@@ -3390,6 +3395,18 @@ https://example.com/schemas/common#/$defs/count/minimum
33903395
</t>
33913396
</list>
33923397
</t>
3398+
<t>
3399+
Note: The fragment part of the URI does not make it canonical or non-canonical,
3400+
rather, the base URI used (as part of the full URI with any fragment) is what
3401+
determines the canonical nature of the resulting full URI.
3402+
<cref>
3403+
Multiple "canonical" URIs? We Acknowledge this is potentially confusing, and
3404+
direct you to read the CREF located in the
3405+
<xref target="embedded">JSON Pointer fragments and embedded schema resources</xref>
3406+
section for futher comments.
3407+
</cref>
3408+
</t>
3409+
33933410
</section>
33943411

33953412
<section title="Manipulating schema documents and references">

0 commit comments

Comments
 (0)