Stream: implementers
Topic: json-schema
Grahame Grieve (Dec 30 2016 at 19:07):
I'm working on qa issues prior to publishing STU3. One on my list is validating the json-schemas - they are not quite valid right now.
Grahame Grieve (Dec 30 2016 at 19:07):
I'm hoping I can get some help with this...
Grahame Grieve (Dec 30 2016 at 19:07):
I'm not sure what the id should be for the json schemas; does anyone have any comments?
nicola (RIO/SS) (Dec 30 2016 at 21:24):
What id do you mean? Attribute id in a root object?
nicola (RIO/SS) (Dec 30 2016 at 21:26):
It's related to how $ref's are resolved. https://github.com/json-schema/json-schema/wiki/The-id-keyword
Grahame Grieve (Dec 30 2016 at 21:50):
yes, that's the one. how should we use it
nicola (RIO/SS) (Dec 30 2016 at 21:57):
it depends on how we are going $ref-erence
nicola (RIO/SS) (Dec 30 2016 at 21:58):
one option- do not use it at all
Grahame Grieve (Dec 30 2016 at 22:01):
it had been my intent that it would be the canonical reference to the schema - the way we usually do it
nicola (RIO/SS) (Dec 30 2016 at 22:09):
most convenient distribution format - put everything in one file - so json schema engine does not need resolve external refs . In one file we could use json pointers - #/definitions/Patient
nicola (RIO/SS) (Dec 30 2016 at 22:11):
because all resources are cross-referencing (contained element) - and most of engines are eagerly loading all references - i think, this is right way
nicola (RIO/SS) (Dec 30 2016 at 22:19):
https://github.com/json-schema-org/json-schema-spec/issues/66 here is a long discussion about problems with $ref resolution - so lets keep it simple
Grahame Grieve (Dec 31 2016 at 00:16):
ok that's sort of a persausive argument.
Grahame Grieve (Dec 31 2016 at 00:19):
so there's no point generating single schema then. What's the correct schema reference for a type then?
Grahame Grieve (Dec 31 2016 at 03:52):
as in, from outside the schema (already using the correct one internally)
nicola (RIO/SS) (Dec 31 2016 at 08:00):
Not sure, I understand question. You could reference by absolute, relative uri (resolved using id as base or if no id - current document location) + fragment ( #id or #/json/pointer). So formula is uri#/json/pointer (referencing by id inside doc is not common for json schema). You could ref like - datatypes.json#/definitions/HumanName - like a common logic of links resolution, but where #id replaced by #/json-pointer. We can generate schema per resource/type and use only uri part fo referencing
Grahame Grieve (Dec 31 2016 at 19:27):
if I generate schema per resource type, then I need to give them an id. At least experimentally that was true. I'm generating a single schema now, with no id, and it validates all the resources
nicola (RIO/SS) (Jan 01 2017 at 18:31):
How do you handle bundle and contained resources (anyOf - is not exactly what we need) and polymorphic elements (again :) We use discriminator to dispatch to specific schema in bundle or in contained (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#models-with-polymorphism-support) and introduced new extension for json-schema - exclusiveProperties to describe polymorphic elements.
Grahame Grieve (Jan 01 2017 at 18:35):
well, for json-schema I'm generating oneOf. We agreed that I would use the swagger extension for swagger, but I haven't done the swagger generation yet - looks like that will be in Feb
nicola (RIO/SS) (Jan 01 2017 at 18:38):
We also could add FHIR specific extensions for json-schema - for example binding keyword and reference - to validate codes and references.
nicola (RIO/SS) (Mar 27 2017 at 20:19):
Paper about Foundation of JSON-schema - http://www2016.net/proceedings/proceedings/p263.pdf
Last updated: Apr 12 2022 at 19:14 UTC
