Stream: conformance
Topic: Validator Strategy
Grahame Grieve (Aug 21 2016 at 11:25):
so I'm thinking of changing strategy with regard to the validator
Grahame Grieve (Aug 21 2016 at 11:25):
at the moment, there is a validator for each version of the spec
Grahame Grieve (Aug 21 2016 at 11:26):
I'm thinking of folding the validator into the IG publisher, and having only one, that does version 1.4.0, 1.6.0 and current.
Grahame Grieve (Aug 21 2016 at 11:27):
I think that this is largely my interest as the maintainer of the various forks.
Grahame Grieve (Aug 21 2016 at 11:27):
but I'm interested to see if there's any opinions about this that influence my thinking
Ewout Kramer (Aug 22 2016 at 12:01):
I have been thinking about this too, as I am working on the .NET validator at the moment. The validator does use the StructureDefinition POCO as input for the definition (but not for the instance data), so you either need to have multiple versions of the POCO around, or not use poco's at all (not even for the definition). Which means you'd have to write your code for equality, ordering, cloning of the basic FHIR types again for the types you;'re going to use internally in your validator.
Or have a set of STU3 StructureDefinitions that define the DSTU2 resources, so it's just a STU3 validator downgrading to DSTU2.
Grahame Grieve (Aug 22 2016 at 13:02):
I use elementmodel entirely for the validator, so the only POCO I need is the current conformance ones
Grahame Grieve (Aug 23 2016 at 01:43):
ok, as of now, the validators in versions 1.4.0 and 1.6.0 (May and Sept ballots respectively) are no longer supported. They're still going to be there (balloted content and all) but anyone who reports any issues with them will be told to use the validator in the current build (which supports validating for those versions)
Last updated: Apr 12 2022 at 19:14 UTC
