Closed MrRobb closed 2 years ago
What is the reasoning behind this? Relative refs work quite well (with the exception of local cross-repo URIs...). This may have considerable implications for availability / performance; though I guess your assumption is that implementers will replace w/ local copies/links?
Also - question: Is there a way to have a substitution variable for an URI template?
Off the top of my head, I can think of the following:
I don't have a strong preference for one or the other. We could also use $id.
- The support is wider for absolute refs than relative refs in json schema validation libraries.
Dooh... That's more of an issue helping you to choose the right validator I guess (I use the YAML form of the schemas & don't run into issues beyond the point-to-the-properties-root).
- You can use software like https://www.jsonschemavalidator.net since the JSON schema is self-contained.
O.k.; helpful during dev maybe? But then, you have a local validator etc.
- We can create a release and reference the schemas on a specific commit / release.
- You don't enforce a specific folder structure. Implementors can replace the full urls with their own and not worry about where the file is referenced.
Good point - we actually point to schemas independent of the local structure by serving them through a service URL such as https://progenetix.org/services/schemas/dataset. Still, you have to edit the schemas of your local version with each update then since the paths vary from the upstream one...
I don't have a strong preference for one or the other. We could also use $id.
That's not what I meant. It was about using something like
$globals:
schema_root: https://raw.githubusercontent.com/ga4gh-beacon/beacon-framework-v2/main
...
$ref: {schema_root}/configuration/beaconConfigurationSchema.json
...
I have no idea if such a concept exists in JSON Schema :-)
I don't object (we rewrite the schemas anyway), but I'm not sure if this is the cleanest move (I mean - really not sure what is common & stable etc.).
Changes