Stream: Announcements
Topic: New Validator Release with Significant Bug Fix
Grahame Grieve (Jul 30 2019 at 06:37):
I am about to release a new version of the Java validator which contains a significant bug fix:
If a profile specifies a fixed value, and it had a null for any element in the fixed value (in the profile), then the validator would ignore any provided value for the specified element in any instances that were supposed to conform to the profile.
Note that it's not valid, if you have a fixed value, and it has a null, for the instance not to have null, but this wasn't being checked. It will be now. Resources previously wrongly validating ok will now be picked up as an error
Ewout Kramer (Aug 12 2019 at 11:58):
I find these kind of bugs in my validator to be some of the worst. Fixing them is really a breaking change, and requires a major version update of the library - but still people may find that hundreds or thousands of entries in their database are now invalid. So far, whenever I have tried to tighten up validation like this, I had so much pushback, that I had to add another option in the settings to disable the checks again. I know this will not help interop, but I understand the practicalities for my users. I wonder what others think on how to deal with these kind of issues.....
Josh Mandel (Aug 12 2019 at 12:53):
It's a tough thing. https://doc.rust-lang.org/edition-guide/editions/index.html#compatibility is one example of a model where users (in their case: library authors) explicitly options in to a specific edition of the language, but each new compiler release supports all editions.
Josh Mandel (Aug 12 2019 at 12:54):
In FHIR validation terms, this is basically like producing a validator that supports all previous behaviors, so a piece of software using this validator can validate at different levels In different contexts. To take your example @Ewout Kramer , they may opt into older rules when validating historical database entries, but opt into the newest rules when processing new resources to be stored in the database.
Josh Mandel (Aug 12 2019 at 12:54):
Er, moving this discussion to #implementers
Grahame Grieve (Nov 29 2019 at 07:22):
Well, I am yet again releasing a validator with significant bug fixes:
- I found that my fixed value fix from before was not always effective (false postives)
- pattern matching wasn't really working (false negatives and false positives)
- Invariants on elements other than the root resource weren't being checked (false positives)
(where false positive = falsely calling a resource ok)
Mark Kramer (Dec 05 2019 at 14:44):
@Grahame Grieve Does the validator support the feature of comparing two profiles, as you demonstrated at the last WG meeting? Is there code in there capable of merging two StructureDefinitions to create another explicit StructureDefinition with the combined constraints (e.g., intersection of cardinality)?
Grahame Grieve (Dec 05 2019 at 18:09):
follow up here: https://chat.fhir.org/#narrow/stream/179177-conformance/topic/New.20Validator.20Release.20with.20Significant.20Bug.20Fix
Shovan Roy (Dec 05 2019 at 22:47):
(deleted)
Grahame Grieve (Dec 05 2019 at 22:50):
yes please do not ask questions like this in Announcements. Ask on #IG creation
Grahame Grieve (Mar 06 2020 at 20:43):
Yet another announcement of a significant bug fix in the validator: for properties that have a primitive type which are a list, it has not been checking that the JsonElement is an array. E.g. for Resource.meta.profile, which is a string with cardinality 0..*, the right format is this:
{ "resourceType": "XX", "meta": { "profile": ["YY"] },
but the validator has also been accepting this as valid:
{ "resourceType": "XX", "meta": { "profile": "YY" },
This is true for all properties, not just Meta.profile. The next release of the validator fixes this, and it will now flag this as an error
Grahame Grieve (Mar 06 2020 at 20:44):
I expect the next version to be released sometime in the next 48 hours
Last updated: Apr 12 2022 at 19:14 UTC
