Stream: hapi
Topic: Java RI dependencies
Grahame Grieve (Dec 08 2016 at 23:40):
@James Agnew I have a question for you
Grahame Grieve (Dec 08 2016 at 23:41):
I need to upgrade the standard validator so it can handle STU2 and STU3 inputs
Grahame Grieve (Dec 08 2016 at 23:41):
I have the code to do it, but I have a package dependency issue.
Grahame Grieve (Dec 08 2016 at 23:42):
org.hl7.fhir.convertors depends on org.hl7.fhir.dstu3, org.hl7.fhir.dstu2, and org.hl7.fhir.dstu2016may
Grahame Grieve (Dec 08 2016 at 23:42):
each of those doesn't depend on any of the others.
Grahame Grieve (Dec 08 2016 at 23:42):
the conversion code is in org.hl7.fhir.convertors
Grahame Grieve (Dec 08 2016 at 23:43):
making dstu3 depend on convertors seems like a bad idea to me
Grahame Grieve (Dec 08 2016 at 23:43):
moving the validator to a new package or to convertors is hard for me
Grahame Grieve (Dec 08 2016 at 23:43):
HAPI is probably the main impact. Any opinions?
James Agnew (Dec 09 2016 at 03:47):
How are you going to change the validator to handle both kinds of inputs? Does converter convert the structuredefinition from 2 to 3 or something? (headed to bed now, won't see your response until morning :) )
Grahame Grieve (Dec 09 2016 at 03:49):
a -version parameter - if you specify -version 1.0.2, then it will convert everything on the fly
Grahame Grieve (Dec 09 2016 at 03:50):
InstanceValidator.java won't change - the conversion will have to be done in the wrapper (e.g. ValidationEngine)
Grahame Grieve (Dec 09 2016 at 21:11):
@James Agnew ping on this subject please
James Agnew (Dec 09 2016 at 21:32):
Oops sorry.. So the idea here is that we have:
A - DSTU2 model
B - DSTU2.1 model
C - STU3 model and validator
D - Converter code for DSTU2 > STU3 model
C depends on A B C
You want to have the validator be able to validate DSTU2/2.1 data, but that means D needs to depend on A B C
James Agnew (Dec 09 2016 at 21:32):
That means you have a circular dependency though.. I don't actually get how that even compiles.
Should the validator be moved out into its own JAR maybe that depends on A B C D?
Grahame Grieve (Dec 09 2016 at 21:37):
yes, that's an option.
Grahame Grieve (Dec 09 2016 at 21:37):
I hadn't found out whether I could resolve the circular dependency.
Grahame Grieve (Dec 09 2016 at 21:38):
it's ok for HAPI for me to move the validator to E that depends on ABCD?
James Agnew (Dec 09 2016 at 21:38):
that would be better actually... that way android users don't need to include the validator. They'll thank you.
Grahame Grieve (Dec 09 2016 at 21:40):
hmmm. I wasn't going to go that far. I was just going to clone ValidationEngine and Validationout of dstu3 package. and leave InstanceValidator in there
Grahame Grieve (Dec 09 2016 at 21:40):
why would android users be happy?
Grahame Grieve (Dec 09 2016 at 21:40):
and wouldn't other users be unhappy because now they could only have the validator if they had ABC not just C?
James Agnew (Dec 09 2016 at 21:43):
Android: With Android every class and method in your dependency count contributes to an overall count of methods, and if you have more than some number of them (I forget the threshold) you need to jump through a bunch of hoops. So every class you don't need that can be avoided is a good thing.
Other users: I figured I'd set this up in a way that it detected which dependencies were on the classpath and acted accordingly. It does this already in a few spots..
What do you mean "clone out"? Like you'll have the same validator code in C and this newly created E?
Grahame Grieve (Dec 09 2016 at 21:44):
well, I was just going to move the wrapper that invokes it, not the whole thing. But I can move all the validator code from abc to e. that just means that anyone using the validator has to have abc not just the particular version. I don't know how that works with HAPI now...?
James Agnew (Dec 09 2016 at 21:47):
Currently the validators are bundled with their respective versions. So the STU3 model JAR has the stu3 validator, and the DSTU2 JAR has the stu2 validator. (i guess that part is obvious)
In order to validate though, you already need to bring in a second dependency since the validation resources (profiles.xml, valuesets.xml, etc.) are in a separate JAR. I'm not fretting about that.. it's a bit of a pain maybe, but the benefit of having 1 validator across both versions of FHIR would far outweigh that.
Grahame Grieve (Dec 09 2016 at 21:48):
ok, well, I'll do that
Grahame Grieve (Dec 09 2016 at 21:48):
it has a long tail, though. So I don't know how long it'll take
Grahame Grieve (Dec 09 2016 at 21:58):
hmm. I don't know what to do with IResourceValidator
James Agnew (Dec 09 2016 at 22:01):
Well, for the DSTU3 one i'd say just move it to D
Do the DSTU2/2.1 ones even have a place under your new scheme? I'm assuming you have some kind of wrapper code that takes in a DSTU2 resource, calls the converter, calls the STU3 validator, then converts the response back? If s, does that code implement the DSTU2 IResourceValidator method? If so, that interface goes in D too I guess?
Grahame Grieve (Dec 09 2016 at 22:02):
nah, figured that. ValidationMessage might be a big harder
Grahame Grieve (Dec 09 2016 at 22:02):
I'm not sure what to do with the validator for DSTU2. I'm not maintaining it, but it's still there for people to run, and me to think about. Actually removing it is a big step
Grahame Grieve (Dec 09 2016 at 22:03):
anyway, the back yard calls...
James Agnew (Dec 09 2016 at 22:03):
ah right, and if you're leaving it in the DSTU2 JAR you need the interface I guess is the issue?
Grahame Grieve (Dec 09 2016 at 22:03):
I need the interface i I'm pulling it out still
Grahame Grieve (Dec 09 2016 at 22:04):
but i can leave the interface, and just have the actual validator implement all the version interfaces. if I decide to do it that way
James Agnew (Dec 09 2016 at 22:04):
Yeah that makes sense
James Agnew (Dec 09 2016 at 22:04):
Have fun in the back yard :)
Grahame Grieve (Dec 10 2016 at 22:29):
ok done
Last updated: Apr 12 2022 at 19:14 UTC
