-
-
Notifications
You must be signed in to change notification settings - Fork 269
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
Relative references from hyper-schema.json to schema.json #183
Comments
@handrews I would expect that a ui-schema would also need to point to data model, hyper-schema and schema potentially so a consistent way to define scopes for pointers seems to be required? A problem we have grappled with is how to point to within an anyOf or a model array relative to the current position within a ui-schema. Using an array key to define the current path goes some of the way to find the relevant data in another scope, but not all. |
@Anthropic This is just about whether to refer to the regular meta-schema as "http://json-schema.org/draft/schema#" or just plain "schema#" since combining that reference with the meta-schema's "id" as the base produces the correct URI. For relative references within a schema, you want #126 Or am I misunderstanding your concern? |
@handrews ah sorry, I just thought perhaps schema#/whatever could also be model#/whatever or state#/workflowstatus etc.. so I missed the point of what you were referring to. Sorry about that, got excited by the heading, I think I need to raise a new issue regarding how to apply scope to a JSON-pointer, 126 is for relative pointer and I'm not sure that fits the bill as I was meaning I could have a condition that when the schema has property value A and the data model value B I do something, in that case I need to point to json in two scopes. |
No worries. That might be covered by |
This is... a good question. Relative references make a lot of sense (we'd be able to change the location, draft number, authority, or protocol, without needing to update multiple references in the meta-schema). But the spec also suggests using full URIs for different reasons that make some sense... mostly clarity. |
I think full URIs make sense here. We had some relative ones and changed them while re-organizing links.json vs hyper-schema.json anyway, and I feel like clearly explicit references are best in this situation. |
For consideration after #168 is merged. Should reference to the regular meta-schema be full URIs or relative references?
The text was updated successfully, but these errors were encountered: