-
-
Notifications
You must be signed in to change notification settings - Fork 292
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
Comments
This might be a bad idea, but was |
In json-schema/json-schema#215 , @YurySk commented:
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. |
If we or someone made such a tool as you describe @handrews, we should make a fuss about it on the site. |
I'm in favour of this proposal. |
It's quite easy to make a conversion tool using Ajv and schema with custom keywords ;) |
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 |
Validation is compatible. Hyper-schema is not (previously, |
@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 |
There don't seem to be any objections to this in the nearly six months since it was filed, just the suggestion to consider I have also seen at least one implementation which only supports I think that it would make sense to add support for |
@handrews Sounds good to me. I agree that as long as identification is part of it's functionality |
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.
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.
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.
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.
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.
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. |
@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. |
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.
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.
Looks like this should be fixed by #154 |
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.
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.
Resolved by #212. |
json-schema/json-schema#215
The text was updated successfully, but these errors were encountered: