search

json-schema-org / json-schema-spec

The JSON Schema specification
http://json-schema.org/
Other
3.43k stars 251 forks source link

Typo in section 8.2.3 of draft 7 leading to wrong information #1499

Closed Era-cell closed 3 months ago

Era-cell commented 3 months ago

https://json-schema.org/draft-07/draft-handrews-json-schema-01#rfc.section.8.2.3

Using JSON Pointer fragments requires knowledge of the structure of the schema. When writing schema documents with the intention to provide re-usable schemas, it may be preferable to use a plain name fragment that is not tied to any particular structural location. This allows a subschema to be relocated without requiring JSON Pointer references to be updated.

To specify such a subschema identifier, the "$id" keyword is set to a URI reference with a plain name fragment (not a JSON Pointer fragment). This value MUST begin with the number sign that specifies a fragment ("#"), then a letter ([A-Za-z]), followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), or periods (".").

The effect of using a fragment in "$id" that isn't blank or doesn't follow the plain name syntax is undefined. [CREF3]

------- The last line, I think it should be "$id" that is blank instead of "$id" that isn't blank

gregsdennis commented 3 months ago

No, this is correct: using an $id with a non-empty ("isn't blank") fragment is undefined.

In fairness, the spec uses "non-empty" in other places and should use it here, too.

Era-cell commented 3 months ago

So, using fragment in $id here means using fragment along with baseURI or base reference URI? Because it is draft 7, it can have fragment... Can you clarify the last statement

jdesrosiers commented 3 months ago

There's definitely something not quite right about that line. Greg, I think you're thinking of a case like, "$id": "https://example.com/schema/main#foo", but this section is talking about the old way of declaring an anchor, "$id": "#foo".

If it said, "that is blank", it would make the sentence make sense. However, I don't think that needs to be said at all. I think it's clear enough that an empty fragment would not follow the plain name syntax.

In any case, we can't change already published releases. We'll have to check if this error is still present and fix it in the next release.

jdesrosiers commented 3 months ago

If present, the value of these keywords MUST be a string and MUST conform to the plain name fragment identifier syntax

This is the current text. It looks like the problem has been corrected, so I'm going to close this issue.