Open lmckenzi opened 3 years ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
(from https://jira.hl7.org/browse/FHIR-9955)
The ask is to be able to take two instances - an instance that was POSTed or PUT to an interface (the 'original') and an instance that was subsequently retrieved from the same interface via a read (the 'stored') together with a profile (which designates certain elements as mandatory/mustSupport). The jar would then normalize both the 'original' and 'stored' instances by stripping out all elements that are not mustSupport or mandatory (and maybe modifier elements too) and then canonicalizes them and finally compares the instances to ensure they are identical. Essentially "ensure this application didn't lose or change any information that the conformance rules say it's not allowed to lose or change".
Testing tools could then make use of this function as part of testing an interface.
Note: This is a net new feature proposed in response to a negative ballot. It probably makes most sense to put in the validator, seeing as that's where we put profile compare, transform execution and other non-validator features implementers will need. Ideal would be to be passed the URL of the server and a sample 'valid' input instance. Alternative is we punt and say it's up to test tools to handle stuff like this.