contentValidation

[jd-nictiz]

Per discussion with Alexander: try to not repeat the mistakes of earlier and just 'get something out there' for you to see, review, perhaps use, expand upon, etc.

In a session with Niek we created a profile by hand (or using Forge), which resulted in the following execution:
https://touchstone.aegis.net/touchstone/scriptexecution?exec=202208311007574346710307&qn=/FHIRSandbox/Nictiz/dev/FHIR4-0-1-Test/PatientCorrections-1-0/PHR-Client/patientcorrections-phr-1-send-one-correctionrequest#WAITING_OPER

I used https://github.com/Nictiz/Nictiz-testscripts/blob/main/dev/FHIR4-0-1-Test/PatientCorrections-1-0/_reference/resources-specific/dwv-Transaction-Scenario-1.xml as input (in/dwz-Transaction-Scenario-1.xml). in/ also contains our manual work as 'expected output' and a snapshot of the profile being used as reference, although the XSLT downloads the snapshot automatically from Simplifier given a package name and version.

The out/ folder contains the output profile being generated at the moment. It is not identical to te reference input, but I placed some comments in the reference input to 'justify' the differences.

The XSLT itself (nothing fancy ANTy yet, just Input -> XSLT -> Output at the moment) is rich in comments with thoughts, explanations and caveats. It is built to terminate if it stumbles across something it doesn't know (yet). It reuses (hopefully upcycles) work of the content asserts phase of this project.

How to move forward? In my opinion:

• More input gives more output. It would be nice to have some more fixtures with manually made profiles to serve as test material
• On the other hand, during developing all kinds of different scenario's pop up. It would be nice to develop some sort of test folder with all kinds of edge cases.
• It would be nice to 'test' the error messages in Touchstone. This means for every fixture we generate a matching profile from, an 'unhappy flow' fixture should be created to see what kind of error Touchstone throws and if that is understandable for implementers.

I have not done anything with generating constraints (invariants) yet, but I imagine this could involve some work generating FHIRpath expressions. Please note that I have 'something like that' laying around which I used so generate content asserts, I suppose that could be recycled.