Fix bug evaluating resolve() in contained resources when doing slicing
This commit is contained in:
Grahame Grieve
parent
cabee9a341
commit
ef800e372f
|
|
@ -7061,7 +7061,7 @@ public class InstanceValidator extends BaseValidator implements IResourceValidat
|
|||
errorSummaryForSlicingAsText(ei.sliceInfo), ei.sliceInfo, I18nConstants.THIS_ELEMENT_DOES_NOT_MATCH_ANY_KNOWN_SLICE_);
|
||||
}
|
||||
} else if (ei.definition.getSlicing().getRules().equals(ElementDefinition.SlicingRules.CLOSED)) {
|
||||
bh.see(rule(errors, NO_RULE_DATE, IssueType.INVALID, ei.line(), ei.col(), ei.getPath(), false, I18nConstants.VALIDATION_VAL_PROFILE_NOTSLICE, (profile == null ? "" : " defined in the profile " + profile.getVersionedUrl()), errorSummaryForSlicing(ei.sliceInfo)));
|
||||
bh.see(rule(errors, NO_RULE_DATE, IssueType.INVALID, ei.line(), ei.col(), ei.getPath(), false, I18nConstants.VALIDATION_VAL_PROFILE_NOTSLICE, (profile == null ? "" : "defined in the profile " + profile.getVersionedUrl()), errorSummaryForSlicing(ei.sliceInfo)));
|
||||
}
|
||||
} else {
|
||||
// Don't raise this if we're in an abstract profile, like Resource
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ public class ValidationContext {
|
|||
public ValidationContext forSlicing() {
|
||||
ValidationContext res = new ValidationContext(appContext);
|
||||
res.resource = resource;
|
||||
res.rootResource = resource;
|
||||
res.rootResource = rootResource;
|
||||
res.groupingResource = groupingResource;
|
||||
res.profile = profile;
|
||||
res.checkSpecials = false;
|
||||
|
|
|
|||
|
|
@ -1,207 +0,0 @@
|
|||
# Introduction
|
||||
|
||||
This document describes the use of the advisor format that advises the validator which rules to enforce.
|
||||
By default the validator enforces the entire FHIR specification as described. Implementers simply wishing
|
||||
to know whether a resource is valid or not should not be using the advisor functionality.
|
||||
|
||||
The advisor functionality exists to assist implementers who are using the validator in pipelines where
|
||||
known issues are tolerated and suppressed. Usually this arises because additional rules were added in
|
||||
later validator versions after design decision had been made, and the specific issues cannot be rectified,
|
||||
though there are other reasons.
|
||||
|
||||
Warning: Implementers use the advisor functionality to hide known issues with their resources.
|
||||
|
||||
To use this functionality, use the command line parameter ```-rules {filename}``` to make a set of rules apply.
|
||||
|
||||
There are two ways to turn off validation rules:
|
||||
|
||||
* Suppressing output messages
|
||||
* Controlling what validation runs
|
||||
|
||||
## Suppressing Output Messages
|
||||
|
||||
This approach is conceptually simple: the entire validation is executed, and then
|
||||
messages are filtered from the output based on their messageId.
|
||||
|
||||
The message ids are not usually shown in the validator output; use the command line parameter
|
||||
```-show-message-ids``` to show the message ids in the output.
|
||||
|
||||
Messages can be suppressed by id, or by path and id (where path is the element the message is associated with).
|
||||
|
||||
Some notes on this approach:
|
||||
|
||||
* This turns off all uses of that message id(+path) - there's no way to be selective about what context they occur in beyond the element path
|
||||
* the messageId is directly tied to the format of the message. For some messages, there are multiple variants of the message, each with their own id, and these all need to be suppressed
|
||||
* message ids are stable (including across languages), but sometimes an existing message is improved in some contexts, and new message ids are introduced in later versions
|
||||
* the underlying validation still happens, even when the messages are suppressed
|
||||
* for invariants in profiles, the message id is the profile URL and the invariant id e.g. http://hl7.org/fhir/StructureDefinition/DomainResource#dom-6
|
||||
|
||||
## Controlling what validation runs
|
||||
|
||||
An alternative approach is to control what parts of the validation logic are executed.
|
||||
As each step of the validation process occurs, the validator looks in the advisor file
|
||||
to see whether any applicable rules apply at the point it is at, and proceeds as advised
|
||||
by the rules in the advisor file.
|
||||
|
||||
# Validation Rules
|
||||
|
||||
The validator uses several different kinds of rules:
|
||||
|
||||
* resource: what to do when validating a resource
|
||||
* element: what to do when validating an element
|
||||
* invariant: what to when checking an invariant
|
||||
* coded: what to do when validating a coded element (e.g. an element with a binding)
|
||||
* reference: what to do when validating a reference to another resource
|
||||
* contained: what to do when validating a contained resource
|
||||
|
||||
Each rule comes with a set of filters that decide whether the rule applies in a given context, and a set of options to choose from
|
||||
|
||||
## resource
|
||||
|
||||
What to do when validating a resource
|
||||
|
||||
Filters:
|
||||
* path: the path in/from the validated resource where this resource is found. For the validated resource itself, this is the type of the resource, but for contained/referenced resource etc, this can be a complex path
|
||||
* type: the type of the resource e.g. Patient
|
||||
|
||||
Options:
|
||||
* base: validate against the base standard
|
||||
* stated: validate against the profiles stated in the parameters to the validator
|
||||
* meta: validate against the profiles stated in the meta element
|
||||
* global: validate against the known global profiles
|
||||
|
||||
## element
|
||||
|
||||
What to do when validating an element
|
||||
|
||||
Filters:
|
||||
* path: the path in/from the validated resource where this element is found
|
||||
* Structure: the url|version for the applicable profile (may be a the base definition of a resource)
|
||||
* id: the element id in the profile
|
||||
|
||||
Options:
|
||||
* cardinality: check the element against it's stated cardinality
|
||||
* invariants: check the element against it's applicable invariants
|
||||
* bindings: check the element against it's applicable bindings (including additional bindings)
|
||||
* fixed: check the element against it's applicable fixed/pattern values
|
||||
|
||||
Note that slicing determination happens irrespective of these options
|
||||
|
||||
## invariant
|
||||
|
||||
What do when evaluating an invariant
|
||||
|
||||
Filters:
|
||||
* path: the path in/from the validated resource where this element is found
|
||||
* Structure: the url|version for the applicable profile (may be a the base definition of a resource)
|
||||
* id: the element id in the profile
|
||||
* key: the key assigned to the invariant
|
||||
|
||||
Options:
|
||||
* check: check the invariant
|
||||
* warning: downgrade to a warning (if it's an error)
|
||||
|
||||
|
||||
## coded
|
||||
|
||||
What to do when validating an element with a binding (including additional bindings)
|
||||
|
||||
Filters:
|
||||
* path: the path in/from the validated resource where this element is found
|
||||
* Structure: the url|version for the applicable profile (may be a the base definition of a resource)
|
||||
* id: the element id in the profile
|
||||
* type: the data type of the element
|
||||
* kind: the binding strength (required, extensible, preferred)
|
||||
* valueSet: the url|version of the valueSet in the binding
|
||||
* system: a code system in the coded element (note: system isn't known at the decision point for `code` datatypes)
|
||||
|
||||
Options:
|
||||
* concepts: check that the concepts are valid
|
||||
* displays: check that the displays are valid
|
||||
* status: check the status of the applicable value sets and code systems
|
||||
|
||||
## reference
|
||||
|
||||
what to do when validating a reference
|
||||
|
||||
Filters:
|
||||
* path: the path in/from the validated resource where this element is found
|
||||
* Structure: the url|version for the applicable profile (may be a the base definition of a resource)
|
||||
* id: the element id in the profile
|
||||
* url: the reference itself
|
||||
|
||||
Options:
|
||||
* exists: check that the reference can be resolved
|
||||
* type: check that the reference resolves to something of the correct type
|
||||
* valid: validate the target of the reference against any applicable profiles
|
||||
|
||||
## contained
|
||||
|
||||
what to do when validating a contained resource
|
||||
|
||||
Filters:
|
||||
* path: the path in/from the validated resource where this contained resource is found
|
||||
* kind: the kind of containment (bundled, contained, parameter, outcome)
|
||||
* type: the type of the resource e.g. Patient
|
||||
* id: the id of the resource
|
||||
|
||||
Options:
|
||||
* valid: validate the contained resource
|
||||
|
||||
|
||||
# Format
|
||||
|
||||
There are two supported formats: text, and json.
|
||||
|
||||
Each format presents a list of rules. Rules are evaluated in order, and the first matching rule (all filters are true, or no filters) is used.
|
||||
For each rule, zero or more filters are provided, and a set of options (which may be empty) is specified.
|
||||
|
||||
## Text Format
|
||||
|
||||
The file begins with zero or more suppression statements:
|
||||
|
||||
```
|
||||
- VALIDATION_VAL_STATUS_INCONSISTENT_HINT@CodeSystem.valueSet
|
||||
- MSG_DEPRECATED # comments are allowed
|
||||
# comments are allowed here too
|
||||
- This_element_does_not_match_any_known_slice_
|
||||
```
|
||||
|
||||
Then there is zero or more rules. Each rule is a line of text. The line starts with the kind of rule, then a list of name=value pairs for the filters, followed by an ':', and then zero or more options separated by spaces:
|
||||
|
||||
```
|
||||
element (path=Patient.identifier.*): cardinality fixed # comments
|
||||
```
|
||||
|
||||
Comments can also be on empty lines e.g. lines with no rules:
|
||||
|
||||
```
|
||||
# comment
|
||||
```
|
||||
|
||||
## Json format
|
||||
|
||||
```json
|
||||
{
|
||||
"suppress" : ["VALIDATION_VAL_STATUS_INCONSISTENT_HINT@CodeSystem.valueSet", "MSG_DEPRECATED", "This_element_does_not_match_any_known_slice_"],
|
||||
"rules" : [{
|
||||
"type" : "element",
|
||||
"filters" : [{
|
||||
"name" : "path",
|
||||
"value" : "path=Patient.identifier.*"
|
||||
}],
|
||||
"options" : ["cardinality", "fixed"]
|
||||
}]
|
||||
```
|
||||
|
||||
other properties are ignored, so comments etc can be introduced with any other property name
|
||||
|
||||
## Filter matching
|
||||
|
||||
Except for the path, filter matching is string based, using * as the wild card. A filter starting with ^ is treated as a regex that the filter value must match.
|
||||
|
||||
In the path, matching is based on segments, broken up by ```.```. If the path syntax in the filter rule doesn't specify an index, it applies to all occurrences. Indexes can be specified as
|
||||
integer offsets. No selection criteria such as FHIRPath can be used
|
||||
|
||||
# Examples
|
||||
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
rule (filter): details
|
||||
|
||||
types of rule:
|
||||
|
||||
references (path, url): (exists, type, valid)*
|
||||
|
||||
contained (path, kind, type, id): (type, valid)*
|
||||
|
||||
resource (path, type): (base, stated-profiles, meta-profiles, global-profiles)*
|
||||
|
||||
element (path, structure, id) : (cardinality, invariants, bindings, additional-bindings, fixed, status)*
|
||||
|
||||
coded (path, structure, id, strength, kind, url, system) : (codes, displays, status)*
|
||||
|
||||
|
||||
2
pom.xml
2
pom.xml
|
|
@ -22,7 +22,7 @@
|
|||
<commons_io_version>2.17.0</commons_io_version>
|
||||
<guava_version>32.0.1-jre</guava_version>
|
||||
<hapi_fhir_version>6.4.1</hapi_fhir_version>
|
||||
<validator_test_case_version>1.5.27</validator_test_case_version>
|
||||
<validator_test_case_version>1.5.28-SNAPSHOT</validator_test_case_version>
|
||||
<jackson_version>2.17.0</jackson_version>
|
||||
<junit_jupiter_version>5.9.2</junit_jupiter_version>
|
||||
<junit_platform_launcher_version>1.8.2</junit_platform_launcher_version>
|
||||
|
|
|
|||
Loading…
Reference in New Issue