-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a functionality to test round-tripping of 'mustSupport/mandatory' #515
Comments
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.
The text was updated successfully, but these errors were encountered: