Skip to content
This repository has been archived by the owner on Nov 3, 2023. It is now read-only.

Rework the section regarding $id and $ref #104

Closed
Relequestual opened this issue Aug 8, 2019 · 4 comments · Fixed by #162
Closed

Rework the section regarding $id and $ref #104

Relequestual opened this issue Aug 8, 2019 · 4 comments · Fixed by #162

Comments

@Relequestual
Copy link
Member

The example of how to use $id with $ref is not how we would like people to do things.

https://json-schema.org/understanding-json-schema/structuring.html#using-id-with-ref

We should rework this to show the intended general use case, where you reference another file by it's $id, including relative URI resolutions.

It's possibly worth noting that you can use an $id in a subschema, but it's not advised because it makes things more complex.

Additionally, is the statement about no support for this true in terms of the python library?

@Julian ?

@Julian
Copy link
Member

Julian commented Aug 9, 2019

It definitely supports id+ref generally, but what that seems likely to be trying to say at the minute is the "location independent" references which aare indeed not supported yet (and are a pain to implement. But some day I guess it will have to happen).

@handrews
Copy link

handrews commented Aug 9, 2019

@Julian would json-schema-org/json-schema-spec#729 make this any easier or harder?

IIRC the problem was doing the pre-scan to find all of the "$id": "#foo" anchors, so changing that to "$anchor": "foo" would not really make that easier.

Although it would arguably make it less confusing: instead of being this weird well... some $ids work and some don't situation, it would just be $anchor is not supported. So that would seem to be a slight argument in favor of #729? (Recall that I brought up putting it in draft-08 after all a couple of weeks ago).

@Julian
Copy link
Member

Julian commented Aug 9, 2019

I think #729 is a positive change (for the reasons you mentioned, so you've got my vote), but yeah doesn't help the key issue which is having to do two passes (or, having to do one, ahead of time pass to collect them, followed by a lazy lookup once you've collected those kinds of refs).

The only thing I think that'd help that is having a designated section for location-independent refs so that you don't need 2 passes and can just know to always look there, but I think I remember you saying there are reasons that the way things are now is needed or convenient for authors, so yeah definitely not saying I have all the answers on that one.

@handrews
Copy link

We now have more clarity in the spec on why you would want to use $id outside of a document root, and have also split out the use case in this section of Understanding JSON Schema into the $anchor keyword, which should make all of this less confusing.

The section referenced by this bug should now talk about $anchor, and the rest of $id's behavior should show up somewhere else (I don't know if it already does in the current book or if we'll need to add that).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants