Make id informational only

[fge]

This would solve all the addressing woes currently plaguing JSON Schema.

If id becomes informational only, then it may be completely ignored as a requirement for addressing, which has the very nice consequence that addressing is now completely unambiguous, since it only relies on JSON Reference and JSON Pointer.

Implementations wishing to rely on id to define the current resolution context MAY do so; however, such implementations MUST NOT expect that peer implementations use this mechanism.

A net win for everybody.

(I said I wasn't involved in JSON Schema anymore, but this problem is still nagging me, and this simple change makes implementation of JSON Schema MUCH easier)

[jdesrosiers]

👍

[awwright]

If there's particular suggestions that don't make functional changes to implementations or the normative meaning of the current draft, or even refining functionality not currently in the JSON Schema Test Suite, then we can work those into v5.

Take a look at the current draft, "resolution context" and a lot of that problematic language is gone now. Can you point to the particular language, in the current Git graft, that's being problematic? Preferably even some examples, and the impacted audiences (JSON consumers, schema authors?).

[seagreen]

"id" gives me more headaches than the rest of JSON Schema Draft 4 combined. It's not even close:/ So I'm also interested in a hopefully cleaned up "id" specification in Draft 5.

@awwright is this the right document to be looking at to see how draft5 work is going: https://github.com/json-schema-org/json-schema-spec/blob/master/jsonschema-core.xml#L469

[handrews]

I think there's a fair amount of support for doing something to make id less confusing, but (particularly with @awwright 's improved language in the latest draft), I don't think this is the right approach.

Specifically, it is MUCH MORE confusing to me if I cannot know by looking at a schema whether an id will affect URI Reference resolution or not. How can I write a schema using id at all if different implementations will treat it differently, producing radically different results?

@yuloh, @seagreen, @jdesrosiers can any of you address this concern? If not, can we get a consensus to drop this and focus on other ways to make id easier to deal with (in separate issues, please do not pile more suggestions onto this one).

[awwright]

"id" got a new definition in the draft-wright-json-schema-00 I-D that should be much simpler to grok.

Please review that document and let's figure out any problems the new definition might pose to implementors and authors.

[seagreen]

@awwright: Would you mind linking to that? I'm not sure if I should be looking in this repo or on json-schema.org.

[handrews]

https://tools.ietf.org/html/draft-wright-json-schema-00

[Relequestual]

@handrews go back to sleep! =p

[seagreen]

@handrews:

Specifically, it is MUCH MORE confusing to me if I cannot know by looking at a schema whether an id will affect URI Reference resolution or not. How can I write a schema using id at all if different implementations will treat it differently, producing radically different results?

fge's proposal would have id neither change the scope of references nor how the schema can be addressed by other schemas. That would be unambiguous.

Another option would be to keep either the scope change or the change to how the schema can be referenced, but not both. Is there any chance we could drop one of those functions? Neither seem to be related to structural validation to me, but I am open to being convinced.