Stream: implementers
Topic: Schematron .Net
David Fallas (Apr 27 2016 at 20:56):
Question to participants - I want to do some Schematron work in .Net, in particular using some new features that were introduced in v1.6 (let, abstract, code-lists). The .Net implementation at NuGet does not support these, and the MS XPath libraries do not support xslt2 anyway. FHIR sch use some of the v1.6 features, but my current .Net code fails to process the Schematron published with the FHIR spec. Can anyone give me some guidance on where I might find some .Net code that implements Schematron v1.6?
Brian Postlethwaite (Apr 27 2016 at 21:15):
Is this to process the invariants?
If so, moving forward we should be able to use the fhirpath expressions for these.
David Fallas (Apr 27 2016 at 21:49):
In part, my intent is to use Schematron as a 'unit test' to provide insurance that any of our code changes, FHIR and/or v2 client and/or server, do not break existing creation of resource instances, business rules or functionality. Our code base is .Net and we need a Schematron-based library for developers. For example we want to be able to use Schematron to check instance codes against specific value-sets which requires a v1.6 implementation.
David Fallas (Apr 27 2016 at 21:50):
I am afraid I don't know much about fhirpath expressions (yet). So much to keep up to date with - so little time!
Brian Postlethwaite (Apr 27 2016 at 21:52):
That's for sure.
Brian Postlethwaite (Apr 27 2016 at 21:54):
A schematron is part of the way there. Profiles are the next step and then valueset bindings/reference existence checks...
If you are just looking for insurance, probably best approach is to use the core FHIR Validator package (yes its java) and jsut run over your content.
But that's no good if you want it as part of your server.
David Fallas (Apr 27 2016 at 21:58):
I suspect the java validator would be too much of a 'force-fit' for our developers to use routinely. And yes, ideally it would be very beneficial to be able to embed a native .Net library in various places.
Brian Postlethwaite (Apr 27 2016 at 22:03):
Our server will be doing this using the fhirpath and additional internal logic (profile checking)
Brian Postlethwaite (Apr 27 2016 at 22:03):
And yes, the javavaidator could be a force-fit.
But you could wire it up in a unit tester in your build environment (so they dont have to remember to do it)
David Fallas (Apr 27 2016 at 22:08):
Thanks for the suggestions here Brian - I'll look into fhirpath. Note though, that I am including v2 (i.e v2xml) messages in addition to FHIR resources as candidates for validation by the same Schematron library - we know we are going to have to handle both in tandem for a number of years to come! I'll keep on searching for a way to get .Net to do this.
Brian Postlethwaite (Apr 27 2016 at 22:09):
Thanks. The fhirpath expressions in the current DSTU2 lib are not 100%, but I will talk with Grahame as to how we might get the updated ones in there.
Ewout Kramer (Apr 28 2016 at 02:27):
HI David, yes, too bad Microsoft just stopped updating their xpath library (in favor of LINQ to XML). We have had some sketchy xpath 2 support for the invariants in the spec by using the extension interface of the xpath engine, but obviously, we could not support new language constructs. So, for now, I am focusing on supporting the FluentPath language in .NET - since the new FHIR spec will have the invariants translated to this new constraint language. So as for the xpath - I've given up on it.
David Fallas (Apr 28 2016 at 02:30):
Hi Ewout, thanks for confirming that - I pretty much found out the same during the last few days. It is a shame that xslt2 was dropped from the MS roadmap - nevermind. I will try to school myself with some of the FluentPath spec.
Grahame Grieve (Apr 28 2016 at 06:23):
the latest expressions for the montreal freeze are available from http://fhir3.healthintersections.com.au/index.html
Grahame Grieve (Apr 28 2016 at 06:23):
you can use fluent path against v2 as well, though that would require additional work
Grahame Grieve (Apr 28 2016 at 06:24):
there should be a C# version of the validator. In fact, I could easily produce that, given some specific work hapenning in the C# reference implementation
Brian Postlethwaite (Apr 28 2016 at 06:25):
I'm wanting to get this done when time permits.
Brian Postlethwaite (Apr 28 2016 at 06:25):
Happy to receive guidance Grahame ;)
Grahame Grieve (Apr 28 2016 at 06:35):
well, if someone was to port the classes in org.hl7.fhir.instance.metamodel to C# - they're approximately what you need for many uses anyway
Grahame Grieve (Apr 28 2016 at 06:35):
then translating the validator would be largely a java -> C# automatible thing
Grahame Grieve (Apr 28 2016 at 06:35):
Ewout and I were talking about this yesterday
David Fallas (Apr 28 2016 at 20:22):
Hi Grahame - maybe you could point me to the code-base. I'm not that good with Java, but have written an Atlassian plugin or two so might be able to stumble my way through some of it.
David Fallas (Apr 28 2016 at 20:22):
On second thoughts, might be the best way for me to get to know the validator and fluentpath?
Ewout Kramer (Apr 28 2016 at 21:04):
David, are you looking into using .NET or another plaform?
David Fallas (Apr 28 2016 at 21:15):
Ewout, in my area we are mostly .Net so that's our developer's comfort zone.
David Fallas (Apr 28 2016 at 21:22):
Ideally, I'm aiming for a .Net library that we would make available on our in-house NuGet server.
Brian Postlethwaite (Apr 29 2016 at 04:17):
Current version of the spec:
http://hl7.org/fhir/2016May/fluentpath.html
and the dotnet code for this is here:
https://github.com/ewoutkramer/fhir-net-fluentpath
Brian Postlethwaite (Apr 29 2016 at 04:18):
I was working on the old version of this code that was in the dotnet fhir client to make it work on the model, but haven't been able to get back onto doing this since the split
Last updated: Apr 12 2022 at 19:14 UTC
