Having wasted a fair while trying to get the Antlr4 grammars at GitHub - openEHR/openEHR-antlr4: Antlr grammars, test files and Java libs. to read some of the ADL files off the CKM site and getting nowhere (the majority of the contents remain unparsed), I am intending to instead put my efforts into making use of the XML for which hundreds of good parsers exist for Python.
My question is: are there any weaknesses in doing so - i.e. is there anything in the ADL 1.4 which is not represented in the XML of the same?
I’m sorry for your experience using the grammar. It’s an area of openEHR that needs improvement has some hidden knowledge. I would caution against using XML, but others may be better Informed. There’s also some ongoing developments that might be relevant.
Could you share your goals for parsing ADL? It’s usually a niche use case. If we understand we can better tailor our advice re the above managed challenges.
Hi, do you have an issue parsing ADL with the java-libs?
I’ve been using it for almost 20 years without any problems. Can you share what specific errors you get?
Though the format shouldn’t be an issue, you can transform ADL to whatever you want and parse that in your code, in fact I’ll be doing just that in the next couple of months, to deprecate XML OPTs and use just JSON on our tools.
I haven’t tried the Java tools as I’m working in Python and my first preference was to do everything in there (antlr has decent Python support) though I guess I could write some Java to do transformation to something else which is more easily ingestible it adds complexity.
Ideally if the XML out of the CKM is reliable and not likely to go anywhere soon I’d just use that as it’s been pre-transformed into a format I can then work with in Python directly. I just wanted to check I’m not missing out on anything.
My use case is that I’m writing an openEHR library / platform in Python (mostly for my own enjoyment) and would like to be able to a) verify archetyped structures against definitions and b) generate “editor” web pages from the archetype definitions which I think needs the archetype parsed.
At some point I’ll probably work out how to contribute to the antlr grammars when I have a little more time and understanding of ADL.
That’s my code, and how I use the parser from the java-libs.
That’s actually a transformation from the ADL to XML implemented as a service that can be accessed from the UI. My point is that you can use a lib that is working, like the java one, as a tool, then transform the parsed ADL to whatever format you want, and then feed the output to your own implementation in any language you like. That’s a totally valid approach.
That’s a question for @sebastian.garde I’m not sure how models are handled internally and the current support for ADL2 in the CKM.
In any case, we still have the ADL1.4 => ADL2.x migration specification missing from the SEC, which would be required to migrate models in the CKM and CDRs too.
I am not sure how normative the XML transform of ADL1.4 is - there are certainly design choices that have been made back then.
In any case, the xml will certainly change if based on adl2. I think Archie can transform adl2 to xml (definitely json).
There is a fairly good - although probably not perfect -conversion from adl1.4 to id-coded adl2 and - with CKM 1.21.0 it is then at-coded adl 2.4. We can add transforms to
XML, json based on Archie to CKM once the adl1.4 to 2.4 conversion is stable as well.