ADL parser error using both se.acode.openehr.parser.ADLParser and org.openehr.adl.parser.AdlDeserializer

flaviociaware · 30 October 2020 16:37

We are trying to deserialize an ADL file (ADMIN-ENTRY), but an error occurs when using both ADLParser and ADLDeserializer.

Using se.acode.openehr.parser.ADLParser return this error message:
se.acode.openehr.parser.ParseException: Encountered " <V_LOCAL_CODE> "“at0108” “” at line 109, column 112.
Was expecting:
“}” …

at se.acode.openehr.parser.ADLParser.generateParseException(ADLParser.java:7327)
at se.acode.openehr.parser.ADLParser.jj_consume_token(ADLParser.java:7191)
at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2832)
at se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2604)
at se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2587)
at se.acode.openehr.parser.ADLParser.c_object(ADLParser.java:2632)
at se.acode.openehr.parser.ADLParser.c_attr_values(ADLParser.java:2868)
at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2831)
at se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2604)
at se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2587)
at se.acode.openehr.parser.ADLParser.c_object(ADLParser.java:2632)
at se.acode.openehr.parser.ADLParser.c_attr_values(ADLParser.java:2868)
at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2831)
at se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2604)
at se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2587)
at se.acode.openehr.parser.ADLParser.c_object(ADLParser.java:2632)
at se.acode.openehr.parser.ADLParser.c_attr_values(ADLParser.java:2868)
at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2831)
at se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2604)
at se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2587)
at se.acode.openehr.parser.ADLParser.c_object(ADLParser.java:2632)
at se.acode.openehr.parser.ADLParser.c_attr_values(ADLParser.java:2868)
at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2831)
at se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2604)
at se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2587)
at se.acode.openehr.parser.ADLParser.c_object(ADLParser.java:2632)
at se.acode.openehr.parser.ADLParser.c_attr_values(ADLParser.java:2868)
at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2831)
at se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2604)
at se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2587)
at se.acode.openehr.parser.ADLParser.cadl_text(ADLParser.java:2553)
at se.acode.openehr.parser.ADLParser.arch_definition(ADLParser.java:738)
at se.acode.openehr.parser.ADLParser.archetype(ADLParser.java:295)

Using org.openehr.adl.parser.AdlDeserializer return this error message:

org.openehr.adl.parser.AdlParserException: 1:0 extraneous input '' expecting {ARCHETYPE, TEMPLATE, TEMPLATE_OVERLAY}
335:0 mismatched input 'ontology' expecting <EOF>
at org.openehr.adl.parser.AdlDeserializer.parse(AdlDeserializer.java:68)
at org.openehr.adl.parser.AdlDeserializer.parse(AdlDeserializer.java:51)

This is the ADL file: https://drive.google.com/file/d/1m7vQ7fw7EvQI58t3kbL73Py713DYV-Q9/view?usp=sharing

Does anyone know how do I solve this?

thomas.beale · 31 October 2020 18:13

Hi Flavio,
looking at the archetype around line 109, I see this:

ELEMENT[at0107] occurrences matches {0..1} matches {	-- Tipo de Universal ID
	value matches {
	DV_TEXT matches {
		value matches {"at0108", "...", "at0118"}
	}
}

I assume what is really meant here is a DV_CODED_TEXT, not a DV_TEXT, i.e. you want a constraint like the following (this is taken from the CKM BP archetype; but it’s the same form needed here):

	DV_CODED_TEXT matches {
		defining_code matches {
			[local::
			at1000, 	-- Standing
			at1001, 	-- Sitting
			at1002, 	-- Reclining
			at1003, 	-- Lying
			at1014]	-- Lying with tilt to left
		}
	}

flaviociaware · 31 October 2020 19:25

I agree, but why does Archetype Editor both WEB (better) and desktop (ocean) open this archetype (file) without errors?

thomas.beale · 31 October 2020 20:50

I would guess the first error is because that code does not handle lists of Strings as a constraint on String. @sebastian.garde or someone from Cambio may know more (@rong.chen - who works with the acode ADL code these days?).

The second error is because that library is expecting ‘terminology’ not ‘ontology’.

rong.chen · 1 November 2020 16:34

Not sure if this is technically a bug of the ADL parser. Have you tried some other more recent java implementations like EtherCIS, Archie or EhrBase?

birger.haarbrandt · 1 November 2020 19:26

If I remember correctly, we don’t have any ADL parsing in EHRbase but only use the RM implementation of Archie and our own template introspects which are used for validation, AQL querying and in the SDK.

flaviociaware · 1 November 2020 23:36

I have not tried other libraries, only the two I mentioned. But, analyzing the answers, I also believe that it is not a technical error, just implementation differences between the import option of the openehr designer tool (“tools.openehr.org/desgner”) and the ADLParser / ADLDeserializer libraries ("github.com/ openehr "). I will correct the syntax as per @thomas.beale 's instruction and report the result here soon.

pablo · 2 November 2020 01:54

@flaviociaware in the openEHR toolkit (toolkit.cabolabs.com) we use the Java reference implementation ADL parser.

lypefm · 3 November 2020 15:25

i try change for ELEMENT[at0107] occurrences matches {0…1} matches { – Universal ID type
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0108,
at0109,
at0110,
at0111,
at0112,
at0113,
at0114,
at0115,
at0116,
at0118]
}
}
}
}

not work for me,

<V_LOCAL_CODE> "“at0108” “” at line 106, column 112.
Was expecting:
“}” …
at se.acode.openehr.parser.ADLParser.generateParseException(ADLParser.java:7327)
at se.acode.openehr.parser.ADLParser.jj_consume_token(ADLParser.java:7191)
at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2832)
at se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2604)
at se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2587)
at se.acode.openehr.parser.ADLParser.c_object(ADLParser.java:2632)

@thomas.beale

pablo · 3 November 2020 15:58

Don’t change that by hand, use an editor. I think the Archetype Editor will get the correct result that will validate on all parsers.

Which editor are you using?

lypefm · 3 November 2020 16:05

i use archetype editor by ocean, but i not understand… i change for internal code,
how can I get through the way it is there?

thomas.beale · 3 November 2020 16:06

My guess is that there is a missing or extra ‘{’ or ‘}’ further up in the archetype. Would be easy to see in a typical coding editor that matches brackets. I would at least check for that first, before looking for more complicated causes!

lypefm · 3 November 2020 16:11

I understand, I will check correctly, thanks!

thomas.beale · 3 November 2020 16:18

Also, I suggest you use the Archetype Designer - its validation will be better.

pieterbos · 3 November 2020 19:34

Checked with Archie - it parses, converts to ADL 2 and validates. But Archie’s ADL 1.4 parser accepts a bit too much incorrect syntax to be used as any kind of validation. It does however mean that the {}-characters are correct.

damoca · 4 November 2020 08:23

I have tried with LinkEHR Studio and parses it correctly. But I think I found the source of the error, and it is that the archetype is not complete. Where does it come from?

A Thomas pointed, that archetype defines something like:
DV_TEXT matches {
value matches {“at0108”, “…”, “at0118”}
}

That means that it is just constraining the value (primitive String) with the literal text values “at0108”, “at0109”… and not with a term definition.

If you change the constraint to use the CODE_PHRASE domain type, the problem is that any of those atNNNN codes exist in the ontology section of the archetype. Maybe this is the source of the error, but the messages are not being quite clear.