Clearly define schema+json fragid forms. #245
Conversation
jsonschema-core.xml
Outdated
| have one that is an empty string. | ||
| <!-- All of the standard meta-schemas use an empty fragment in their id/$id values. --> | ||
| <cref> | ||
| How should an "$id" URI reference contianing a fragement with other components |
|
@epoberezkin I fixed the typo, does this otherwise seem like a good step forward? Even if it is not perfect. |
|
@handrews yes, thank you |
|
I THINK I understand this change, but possibly not fully understand all of the possible implications. I'd really like @awwright to weigh in on this. However, if this is for draft-6, he can just review it as part of the final review process. |
|
@awwright could you please review/approve as @Relequestual asked? @epoberezkin really wants to see this in Draft 06, and I support it (but would like to get it resolved- it's been open for more than two weeks). |
|
@awwright any comments? This is the last PR currently open that is marked for Draft 06 and it is blocked awaiting your feedback. For over 3 weeks now. |
jsonschema-core.xml
Outdated
| </t> | ||
| <t> | ||
| The effect of defining an "$id" that is appears to be a JSON Pointer that does not match | ||
| the expected JSON Pointer for that schema is not defined. |
There was a problem hiding this comment.
I'm wary of changing this section (on the definition of the $id keyword) to liberalize what's acceptable. The specification should positively define what's acceptable in a regular grammar, without excluding a referenced set/relying on a compliment.
Otherwise, it might be the case that if the current RFC for JSON Pointer is superseded, that changes the behavior of this specification in a possibly incompatible way. The current behavior is the same restriction found in other documents like XML (that's also legal in a 7-bit URI), so the restriction shouldn't come as much of a surprise.
If JSON gets a fragment identifier defined, I don't want to assume it looks anything like JSON Pointer. I suspect it might operate like e.g. text/plain (defined in RFC5147 where it introduces a format like #line=20 that's incompatible with e.g. XML's Name production.
Otherwise I like this PR. I'm trying to come up with some other comments, but this is turning into me re-reading XML and HTML.
There was a problem hiding this comment.
@awwright I'm happy to restore the XML-derived restrictions on plain name fragments. The possibility of JSON defining something different is a really good point.
Reference the JSON Pointer RFC for using JSON Pointers as fragids (includes encoding requirements). Remove the syntax description for how to write a fragment URI reference (leading "#") as that is covered by RFC 3986. Note that it is possible to give a fragment that is not valid in either style of fragid, and document that the effect of such a fragment is undefined. Also fill in a bit more of the IANA considerations section.
|
@awwright I've restored the exact restrictions that were previously present on plain name fragids, although I otherwise kept the new wording. I think this should address your concern, while also still addressing @epoberezkin's concerns over how re-stating what a fragment is (leading "#") was confusing. URI stuff references RFC 3986 which is correct, everything else is now explicitly defined either in the text or by referencing the JSON Pointer RFC. |
gregsdennis
added
clarification
5 participants
This addresses issue #243. (edit: and #144)
Reference the JSON Pointer RFC for using JSON Pointers
as fragids (includes encoding requirements).
Remove the syntax description for how to write a fragment
URI reference (leading "#") as that is covered by RFC 3986.
Also fill in a bit more of the IANA considerations section.