Hi all,
I just made a new commit on the TRUNK of ref_impl_java.
Changes:
1. Better support of C_QUANTITY in the parser (also resulting a new
CDvQuantity in the new openehrprofile package in AOM)
2. Corrected ADL path grammar in the parser
3. Adjusted the archetype description again
4. Big fix in the ArchetypeID (initially reported by LiU group)
5. Added a batch parsing method into command-line interface of the parser
6. Rearranged the unit test code a bit
All these contributed to better result of parsing ADL files from openEHR
knowledge repository. Now out of 46 EHR archetypes from the latest
revision (17), 36 are parsed correctly straight away. The rest 10 failed
in parsing are caused by the following reasons:
1) 6 for C_QUANTITY related issues, e.g. missing units in the item,
missing property (not sure know to create DvCodedText out of string in
the parser).
2) 2 for term_binding issues. it seems that perhaps the URLs in the ADL
are not based on RFC
3) 1 for incomplete invariant support
4) 1 caused by invalid values in DvDuration
Please let me know how does this version work for you (does this break
your current working ADLs)? Next step, I will firstly fix the output
bug, then move on with more domain types support. We soon need to
declare an internal version - kernel 1.25 and parser 1.0.2 (taking away
the "SNAPSHOT" flag). So any feedback on this will be appreciated.
Cheers,
Rong
Hi all,
Great work Rong on the AOM and parser (this is very good for our java archetype editor). We are currently implementing Quantity support in our editor with the new AOM objects you commited recently.
We have found some issues about the kernel and parser that we wanted to inform about:
- Parse error for other_contributors in the description part.
- Parser inconsistent with the archetype system specification when handling archetype version in the ArchetypeID. ([a-zA-Z0-9]+ is allowed according to parser but in the specifications only one letter and one number is allowed)
- The parser doesn’t validate the specialisation in the domain concept. Should be some loop that verifies all specialisations after the concept name.
By the way, what progress have the UCL team made on the kernel?
Best regards,
Johan Hjalmarsson and Mattias Forss
Hi again,
We forgot one issue with the parser - shouldn’t the parser allow a path that looks like this:
/[at0000]/data[at0001]…
We have seen that the parser wants an attribute name before the [local code reference]. But should it be mandatory for the root?
adl.jj, line 414:
< #PATH_SEGMENT: “/” <V_ATTRIBUTE_IDENTIFIER> ( <V_LOCAL_TERM_CODE_REF>)? >
Regards,
Johan & Mattias
Johan Hjalmarsson wrote:
Hi all,
Great work Rong on the AOM and parser (this is very good for our java
archetype editor). We are currently implementing Quantity support in
our editor with the new AOM objects you commited recently.
We have found some issues about the kernel and parser that we wanted
to inform about:
- Parse error for other_contributors in the description part.
- Parser inconsistent with the archetype system specification when
handling archetype version in the ArchetypeID. ([a-zA-Z0-9]+ is
allowed according to parser but in the specifications only one letter
and one number is allowed)
- The parser doesn't validate the specialisation in the domain
concept. Should be some loop that verifies all specialisations after
the concept name.
By the way, what progress have the UCL team made on the kernel?
Yin Su is powering through the RM. Note - we are really doing Release
1.1, since almost all the changes are just bug fixes from 1.0, apart
from the big addition, which is the EHR Extract. She might commit the
changes tomorrow - we will see if it makes sense. Anyway, data types,
data structures, support, and I think about 50% of Common is done.
However we need to go back and do the test cases.
- thomas