Skip to content

Clarify various things about canonical URIs #1196

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 14, 2022

Conversation

Relequestual
Copy link
Member

Fixes #937

I screwed up a force push on #1104 so this is the replacement.

Will contain the same commits.

Extract from the first comment on #1104

Fixes issue #937, clarifying a number of other things along the way.
While it touches a fair number of lines, I'm fairly sure that it
doesn't anything about conformance.

[NOTE: This does not address the question of whether "canonical" is what we want - that is too large of a change for a https://github.com/json-schema-org/community/discussions/7 which is what this PR is targeted for. That topic should get its own issue if someone wants to propose something about it. It also does not deal with https://github.com//issues/1059, although it clarifies some things based on discussions there.]

@Relequestual Relequestual changed the base branch from draft-next to master March 14, 2022 14:00
Fixes issue json-schema-org#937, clarifying a number of other things along the way.
While it touches a fair number of lines, I'm fairly sure that it
doesn't anything about conformance.

After spending more time reading various writings on the concept
of the "canonical" URI for a resource, and reviewing our language,
I came to the following conclusions:

* canonical URIs only make sense at the whole-resource scope
* A URI with a fragment is neither canonical nor non-canonical
* It makes more sense to talk about fragments w.r.t. canonical URIs
* Our language was sufficiently confusing that going this way seems fine.

As part of this, I fixed an outright incorrect statement that
identifier keywords set canonical URIs.  Since there is only
one canonical URI and a single schema object could contain
three ($id, $anchor, $dynamicAnchor) or more identifier keywords,
this statement is clearly a bug.  These keywords assign URIs,
but only $id assigns a canonical one.

I revamped a lot of wording in descriptions and examples to
hopefully be more precise.  I separated the discussion of
the empty fragment in $id from the main paragraph of its
functionality, and clarified that this is talking about a
media-type-specific semantic equivalence, and is not asserting
that RFC 3986 normalization applies to fragments (this has
been a point of confusion).
@Relequestual
Copy link
Member Author

Commits originally aurthored by @handrews and approved by myelf, @jdesrosiers, and @karenetheridge.
Merging.

@Relequestual Relequestual merged commit afca53d into json-schema-org:master Mar 14, 2022
@Relequestual
Copy link
Member Author

@Relequestual Relequestual added this to the draft-patch for 2020-12 milestone Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clarify whether plain name fragment URIs are canonical, and what it means if they are (or aren't)
2 participants