Skip to content
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

Rename "id" to "$id" #20

Closed
JanTvrdik opened this issue Apr 21, 2016 · 14 comments
Closed

Rename "id" to "$id" #20

JanTvrdik opened this issue Apr 21, 2016 · 14 comments

Comments

@JanTvrdik
Copy link

json-schema/json-schema#215

@seagreen
Copy link
Collaborator

seagreen commented May 1, 2016

This might be a bad idea, but was $scope ever considered as well? id was a really confusing name to me when I was first learning about JSON schemas.

@handrews
Copy link
Contributor

In json-schema/json-schema#215 , @YurySk commented:

  1. My, reasonably composed, V4 schemas are valid in V5 without a simple change. I can then change a validator to a version with V5 support. Then I do QA, see that the things are working and leave the schemas be (i.e. not even bother with any DevOps stuff related to the schema files).
  2. My, reasonably composed, V4 schemas are NOT V5 valid for a number of good reasons. Then I sit down, update them thoughtfully, QA, deploy, etc.
  3. same as 2, but with the only incompatibility being '$id'. Do I really need to go though the motions knowing full well "$id" is the only difference?

My response to this is that we should supply an upgrade tool that handles all automatable conversions from one draft to the next. So far that could include:

I know that it is possible to preserve order while loading, editing, and writing JSON back out in Python's standard JSON library, so this could be done without scrambling everyone's schemas.

This makes the upgrade mechanical- not entirely without risk, but does not require "thoughtful" updates or extensive testing.

@Relequestual
Copy link
Member

If we or someone made such a tool as you describe @handrews, we should make a fuss about it on the site.

@Relequestual
Copy link
Member

I'm in favour of this proposal.

@epoberezkin
Copy link
Member

It's quite easy to make a conversion tool using Ajv and schema with custom keywords ;)
So a special schema will be used to convert schema to the next version. Very meta.
I can make it once the standard is stable.

@Relequestual
Copy link
Member

Draft 5 is done. I haven't looked at the diffs in details to determin if it was non version forward compatible. I believe @awwright intended draft 5 to mostly be a fix for issues in draft 4

@handrews
Copy link
Contributor

handrews commented Nov 2, 2016

Draft 5 is done. I haven't looked at the diffs in details to determine if it was non version forward compatible.

Validation is compatible. Hyper-schema is not (previously, method in the LDO was explicitly documented to use HTTP methods, but @awwright changed it to be based on "get" vs "post" usage in HTML forms instead, invalidating all methods that were set to "PUT", "PATCH", or "DELETE" and adding ambiguity to "GET" and "POST").

@awwright
Copy link
Member

awwright commented Nov 2, 2016

@handrews "... and certain changes to make the spec compatible with existing standards" is pretty much what the idea was; eventually, the semantics of "method" was slightly tweaked, but backwards-compatible for the most part; four special-case "rel" keywords were dropped, "base" keyword was introduced (I might propose changing that because it's a schema keyword, we might want it to mean something else... I forget what), also in Validation the "uriref" format was introduced; also in Core use of $ref and "id" was restricted

@handrews
Copy link
Contributor

There don't seem to be any objections to this in the nearly six months since it was filed, just the suggestion to consider $scope instead of $id. As long as we are retaining the identification functionality of the keyword (it sets the schema's identifying URI as well as changing the resolution base), I think we should stick with $id.

I have also seen at least one implementation which only supports $id and not id, so that's some running code to add to the consensus :-)

I think that it would make sense to add support for $id and deprecate, but not yet remove id. When we have a good migration story and tool(s) we can then drop id from the next draft.

@seagreen
Copy link
Collaborator

@handrews Sounds good to me. I agree that as long as identification is part of it's functionality $id is better than $scope.

handrews added a commit to handrews/json-schema-spec that referenced this issue Nov 15, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
handrews added a commit to handrews/json-schema-spec that referenced this issue Nov 16, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
handrews added a commit to handrews/json-schema-spec that referenced this issue Nov 17, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
handrews added a commit to handrews/json-schema-spec that referenced this issue Nov 21, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
handrews added a commit to handrews/json-schema-spec that referenced this issue Nov 23, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
@awwright awwright added this to the draft-next milestone Nov 30, 2016
@awwright
Copy link
Member

awwright commented Dec 3, 2016

This is a pretty big change so I still need to review implementations and see what sort of impact it would have. Hopefully this means next meta-schema update, but I'm not totally sure.

@handrews
Copy link
Contributor

handrews commented Dec 3, 2016

@awwright can you be a little more clear on what needs to be researched? We can help collect the information if we know what you are looking for.

handrews added a commit to handrews/json-schema-spec that referenced this issue Dec 5, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
handrews added a commit to handrews/json-schema-spec that referenced this issue Dec 12, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
@Relequestual
Copy link
Member

Looks like this should be fixed by #154

handrews added a commit to handrews/json-schema-spec that referenced this issue Dec 28, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.

The current plan is to continue to allow for "id" until a migration
tool can be provided.
handrews added a commit to handrews/json-schema-spec that referenced this issue Dec 28, 2016
This addresses issue json-schema-org#20.

"$id" matches "$schema" and "$ref", establishing a clear naming
pattern for all keywords defined in the core specification.  This
also reduces confusion in the very common case where objects
described by the schema have an "id" property.
@handrews
Copy link
Contributor

handrews commented Jan 5, 2017

Resolved by #212.

@handrews handrews closed this as completed Jan 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants