Typo in section 8.2.3 of draft 7 leading to wrong information
Era-cell opened this issue · comments
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
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.
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
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.
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.