# Wish list updated and current status of the Java Archetype Editor **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2006-03-24 15:36 UTC **Views:** 12 **Replies:** 11 **URL:** https://discourse.openehr.org/t/wish-list-updated-and-current-status-of-the-java-archetype-editor/14520 --- ## Post #1 by @Johan_Hjalmarsson1 Hi all, Status: Currently our editor supports Composition and Section archetypes to the extent that the kernel allows. It also supports event series in Observation archetypes and some bugs have been fixed. The most severe issues are: 1. Kernel and parser don't support archetype slots fully which means the included or excluded archetypes aren't parsed, stored nor outputted. 2. The new archetype format with [] isn't supported by the kernel and parser. 3. Instruction and Action archetypes aren't supported by the kernel and parser. 4. Embedded dADL inside cADL e.g. "C_QUANTIY = < ... > " isn't supported by the kernel and parser. 5. Assumed value isn't supported by the kernel and parser. Solutions to the issues listed above will accordingly result in the following for our archetype editor: 1. The editor will fully support Section and Composition archetypes. 2. & 4. & 5. The editor will support many of the archetypes at openEHR knowledge repository and at Ocean Informatics archetype repository. 3. Will result in the possibility to support archetypes for the whole entry package in our editor. We really would appreciate if we could get some approximate estimates on when the issues listed above are solved. It would be nice if the easiest were dealt with first in order not to stop the progress with our archetype editor. Regards, Johan & Mattias --- ## Post #2 by @rong.chen Johan Hjalmarsson wrote: > Hi all, > > Status: > Currently our editor supports Composition and Section archetypes to > the extent that the kernel allows\. > It also supports event series in Observation archetypes and some bugs > have been fixed\. > > The most severe issues are: > 1\. Kernel and parser don't support archetype slots fully which means > the included or excluded archetypes aren't parsed, stored nor outputted\. > 2\. The new archetype format with \[\] isn't supported by the kernel and > parser\. > 3\. Instruction and Action archetypes aren't supported by the kernel > and parser\. > 4\. Embedded dADL inside cADL e\.g\. "C\_QUANTIY = < \.\.\. > " isn't > supported by the kernel and parser\. > 5\. Assumed value isn't supported by the kernel and parser\. > > Solutions to the issues listed above will accordingly result in the > following for our archetype editor: > 1\. The editor will fully support Section and Composition archetypes\. > 2\. & 4\. & 5\. The editor will support many of the archetypes at openEHR > knowledge repository and at Ocean Informatics archetype repository\. > 3\. Will result in the possibility to support archetypes for the whole > entry package in our editor\. > > We really would appreciate if we could get some approximate estimates > on when the issues listed above are solved\. It would be nice if the > easiest were dealt with first in order not to stop the progress with > our archetype editor\. Hi Johan, Mattias, Thanks for the update on the editor\. I have been working on the parser recently\. Here is my update of the parser development in relation to your wish list\. No\.2 issue is caused by the object key syntax included in dADL, which is now used to specify most parts of archetype, e\.g\. description, ontology\. The current parser doesn't really recognize dADL properly, instead it uses more specific syntax to parse different parts of the archetype\. It means the support of \[\] can be added into different parts of the parser by updating the grammar for differently parts respectively\. This is of course not the ideal way to do, but it works as quick fixes to the existing parser without major changes\. The support for \[\] in archetype description is probably OK now and I hope the update on the ontology part could be done within a couple of days\. No\.5 \(assumed values\) will be dealt with after the No\.2, so perhaps it will be ready end of this week\. No\.4 is related to \[\] support as well\. Complete fix for No\.1 \(archetype slot\) requires implementing assertion package of AOM and its link to the parser\. This would happen with 2\-3 weeks hopefully\. No\. 3 issues require some update of the RM, particularly the entry package from ehr\_im which is quite different from the current kernel\. It's hard to estimate since it depends how many developer could contribute\. But let say if the UCL group or your group can start to work on the RM upgrade while I am fix the parser/AOM, then it should be possible for these to be done within 3\-4 weeks\. Regards, Rong --- ## Post #3 by @Mattias_Forss1 2006/3/27, Rong Chen <[rong@acode.se](mailto:rong@acode.se)>: > Johan Hjalmarsson wrote: > > > Hi all, > > > > Status: > > Currently our editor supports Composition and Section archetypes to the extent that the kernel allows. > > It also supports event series in Observation archetypes and some bugs have been fixed. > > > > The most severe issues are: > > 1. Kernel and parser don't support archetype slots fully which means the included or excluded archetypes aren't parsed, stored nor outputted. > > 2. The new archetype format with [] isn't supported by the kernel and parser. > > 3. Instruction and Action archetypes aren't supported by the kernel and parser. > > 4. Embedded dADL inside cADL e.g. "C_QUANTIY = < ... > " isn't supported by the kernel and parser. > > 5. Assumed value isn't supported by the kernel and parser. > > > > Solutions to the issues listed above will accordingly result in the following for our archetype editor: > > 1. The editor will fully support Section and Composition archetypes. > > 2. & 4. & 5. The editor will support many of the archetypes at openEHR knowledge repository and at Ocean Informatics archetype repository. > > 3. Will result in the possibility to support archetypes for the whole entry package in our editor. > > > > We really would appreciate if we could get some approximate estimates on when the issues listed above are solved. It would be nice if the easiest were dealt with first in order not to stop the progress with our archetype editor. > > Hi Johan, Mattias, > > Thanks for the update on the editor. > > I have been working on the parser recently. Here is my update of the parser development in relation to your wish list. > > No.2 issue is caused by the object key syntax included in dADL, which is now used to specify most parts of archetype, e.g. description, ontology. The current parser doesn't really recognize dADL properly, instead it uses more specific syntax to parse different parts of the archetype. It means the support of [] can be added into different parts of the parser by updating the grammar for differently parts respectively. This is of course not the ideal way to do, but it works as quick fixes to the existing parser without major changes. Hi everyone, Thanks Rong for the time estimates. We have seen that the parser uses specific syntax for each case, but we assume it is hard to implement a general parser with JavaCC. As long as the description and ontology parts are changed, then it wouldn't be much problems in parsing some Ocean archetypes. > The support for [] in archetype description is probably OK now and I hope the update on the ontology part could be done within a couple of days. > > No.5 (assumed values) will be dealt with after the No.2, so perhaps it will be ready end of this week. > > No.4 is related to [] support as well. Great to hear that you have made progress, we're looking forward to seeing some commits soon :-) As we might have told you before number 4 often relates to the C_QUANTITY data type and object instantiation in the kernel can be completely ignored for this data type as long as the AOM for it hasn't been updated. > Complete fix for No.1 (archetype slot) requires implementing assertion package of AOM and its link to the parser. This would happen with 2-3 weeks hopefully. We looked at some specifications and we're wondering if it is needed to implement the assertion package now, since it adheres to an optional section in ADL. At this stage we would be happy just to see that the archetype slots are parsed into the AOM with real includes and excludes. What we would like to happen (if possible) is that the assertion package is implemented after the archetype slot object is supported with includes and excludes. Maybe the UCL group can implement the assertion package? > No. 3 issues require some update of the RM, particularly the entry package from ehr_im which is quite different from the current kernel. It's hard to estimate since it depends how many developer could contribute. But let say if the UCL group or your group can start to work on the RM upgrade while I am fix the parser/AOM, then it should be possible for these to be done within 3-4 weeks. We will focus on our archetype editor as long as we don't get completely stuck and dependent of updates to the kernel/parser. Cheers, Mattias & Johan --- ## Post #4 by @thomas.beale Johan Hjalmarsson wrote: > Hi all, > > Status: > Currently our editor supports Composition and Section archetypes to > the extent that the kernel allows\. > It also supports event series in Observation archetypes and some bugs > have been fixed\. > > The most severe issues are: > 1\. Kernel and parser don't support archetype slots fully which means > the included or excluded archetypes aren't parsed, stored nor outputted\. you need this for Instruction and Action archetypes as well as for Section archetypes\. In general, any kind of archeytpe can have a slot\. > 2\. The new archetype format with \[\] isn't supported by the kernel and > parser\. this should be very easy for Rong to change > 3\. Instruction and Action archetypes aren't supported by the kernel > and parser\. I suggest leaving this till we have it completely sorted in the ADL workbench and Archetype Editor \- which we have achieved last night I think, but we need a few days on testing etc\. We will put all the latest archetypes onto openEHR\.org within a week \- these will become the reference archetypes\. > 4\. Embedded dADL inside cADL e\.g\. "C\_QUANTIY = < \.\.\. > " isn't > supported by the kernel and parser\. this is easy to handle \- as long as you can detect sections of dADL embedded in cADL \- the easiest way to do this is in the archetype lexical analyser \- just read in the whole section and pass it to a dADL parser \(you need to have separate cADL and dADL parsers\)\. > 5\. Assumed value isn't supported by the kernel and parser\. this should be easy\. There is a test archetype on openEHR\.org to test this\. > > Solutions to the issues listed above will accordingly result in the > following for our archetype editor: > 1\. The editor will fully support Section and Composition archetypes\. > 2\. & 4\. & 5\. The editor will support many of the archetypes at openEHR > knowledge repository and at Ocean Informatics archetype repository\. > 3\. Will result in the possibility to support archetypes for the whole > entry package in our editor\. \- thomas --- ## Post #5 by @thomas.beale Rong Chen wrote: > > Complete fix for No\.1 \(archetype slot\) requires implementing assertion > package of AOM and its link to the parser\. This would happen with 2\-3 > weeks hopefully\. >   I suggest you limit this to just supporting slots which are defined by regular expressions on archetype ids, and nothing more\. I have rewritten the assertion grammar today and am testing it\. This should help\. > No\. 3 issues require some update of the RM, particularly the entry > package from ehr\_im which is quite different from the current kernel\. > It's hard to estimate since it depends how many developer could > contribute\. But let say if the UCL group or your group can start to work > on the RM upgrade while I am fix the parser/AOM, then it should be > possible for these to be done within 3\-4 weeks\. >   my group at UCL are working on this \- they have done data types and I think data structures by this week\. I guess 2 \- 3 weeks\. \- thomas --- ## Post #6 by @thomas.beale Mattias Forss wrote: > 2006/3/27, Rong Chen <rong@acode\.se <mailto:rong@acode.se>>: >> Johan Hjalmarsson wrote: >> > > Hi everyone, > > Thanks Rong for the time estimates\. We have seen that the parser uses > specific syntax for each case, but we assume it is hard to implement a > general parser with JavaCC\. As long as the description and ontology > parts are changed, then it wouldn't be much problems in parsing some > Ocean archetypes\. I don' t know how JavaCC works, but I have done a lot of parsing\. The general design has to be as 4 separate parsers: \- dADL parser \- cADL parser \- ADL arcetype parser \(very simple; just extracts the sections and gives them to the other parsers\) \- assertion language parser with ADL2, the ADL parser will go away \(ADL2 means the archetype is completely in dADL, with embedded cADL and assertion sections\)\. Currently, I just use the cADL parser to parse assertions, since \(due to archetype slots\) cADL can have embedded assertions\. So I pass the invariant section of an archetype to the cADL parser and it can produce the result\. BUT\.\.\.\. I suggest that you leave this to last, and you could reasonably assume that there will be no invariant section at all \- I think we only have one archetype so far where it is the case\. > > > We looked at some specifications and we're wondering if it is needed > to implement the assertion package now, since it adheres to an > optional section in ADL\. At this stage we would be happy just to see > that the archetype slots are parsed into the AOM with real includes > and excludes\. exactly\.\.\.\.\.just what I suggest > > What we would like to happen \(if possible\) is that the assertion > package is implemented after the archetype slot object is supported > with includes and excludes\. Maybe the UCL group can implement the > assertion package? at the moment it is not a priority, because assertions \(apart from very simple ones in slot expressions\) are not a priority for archetypes users\. \- thomas --- ## Post #7 by @Johan_Hjalmarsson We have come up some issues that concerns the parser and AOM\. For example the current implementation support standard ADL COUNT data type as it would be an openEHR profile C\_COUNT data type\. This means that whenever the parser finds a COUNT it will check for mandatory attributes that adhere to the C\_COUNT \(openEHR profile data type\) and try to instantiate the CCount class in the kernel, but this is not correct\. Instead it should only instantitate a CComplexObject so that it could be possible to have a data type that don't have any attributes, e\.g\. COUNT matches \{\*\} which means that the CComplexObject has the any allowed flag set to true\. So this means, that for all the constraints that are domain type constraints you need to check for the correct syntax in the parser which is C\_COUNT, C\_QUANTITY etc\. Another thing is that RM object creation sometimes rely on that the syntax for constraints is DV\_TEXT etc, but we think that the DV check in the function createRMObject should be skipped\. Regards, Johan & Mattias --- ## Post #8 by @Johan_Hjalmarsson1 We have come up some issues that concerns the parser and AOM. For example the current implementation support standard ADL COUNT data type as it would be an openEHR profile C_COUNT data type. This means that whenever the parser finds a COUNT it will check for mandatory attributes that adhere to the C_COUNT (openEHR profile data type) and try to instantiate the CCount class in the kernel, but this is not correct. Instead it should only instantitate a CComplexObject so that it could be possible to have a data type that don't have any attributes, e.g. COUNT matches {*} which means that the CComplexObject has the any allowed flag set to true. So this means, that for all the constraints that are domain type constraints you need to check for the correct syntax in the parser which is C_COUNT, C_QUANTITY etc. Another thing is that RM object creation sometimes rely on that the syntax for constraints is DV_TEXT etc, but we think that the DV check in the function createRMObject should be skipped. Regards, Johan & Mattias --- ## Post #9 by @thomas.beale Johan Hjalmarsson wrote: > We have come up some issues that concerns the parser and AOM\. > > For example the current implementation support standard ADL COUNT data > type as it would be an openEHR profile C\_COUNT data type\. This means > that whenever the parser finds a COUNT it will check for mandatory > attributes that adhere to the C\_COUNT \(openEHR profile data type\) and > try to instantiate the CCount class in the kernel, but this is not > correct\. Instead it should only instantitate a CComplexObject so that > it could be possible to have a data type that don't have any > attributes, e\.g\. COUNT matches \{\*\} which means that the CComplexObject > has the any allowed flag set to true\. So this means, that for all the > constraints that are domain type constraints you need to check for the > correct syntax in the parser which is C\_COUNT, C\_QUANTITY etc\. there is something wrong here; there is no such thing as C\_COUNT; only C\_QUANTITY\.\.\.\.see http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/openehr_archetype_profile.pdf > > Another thing is that RM object creation sometimes rely on that the > syntax for constraints is DV\_TEXT etc, but we think that the DV check > in the function createRMObject should be skipped\. > Do you mean to do with the names, i\.\.e whether "DV\_" is present? This is a small problem which is more or less political\. If we want archeytpes to be shared beyond the openEHR community, they see "DV\_" as an openEHR\-ism, so we often allow it to be removed in archetypes\. The proper solution is that a fixed set of aliases of class names is allowed; at the moment, this includes: \- all DV\_XXX can be just XXX in archetypes \- all ITEM\_XXX can be just XXX in archetypes The Ocean editor implements this mapping\. Any tool should probably allow both kinds of class names, i\.e\. the alias should not replace the original set of valid names, just add to it\. \- thomas --- ## Post #10 by @Mattias_Forss1 2006/4/3, Thomas Beale <[Thomas.Beale@oceaninformatics.biz](mailto:Thomas.Beale@oceaninformatics.biz)>: > Johan Hjalmarsson wrote: > > We have come up some issues that concerns the parser and AOM. > > > > For example the current implementation support standard ADL COUNT data > > type as it would be an openEHR profile C_COUNT data type. This means > > that whenever the parser finds a COUNT it will check for mandatory > > attributes that adhere to the C_COUNT (openEHR profile data type) and > > try to instantiate the CCount class in the kernel, but this is not > > correct. Instead it should only instantitate a CComplexObject so that > > it could be possible to have a data type that don't have any > > attributes, e.g. COUNT matches {*} which means that the CComplexObject > > has the any allowed flag set to true. So this means, that for all the > > constraints that are domain type constraints you need to check for the > > correct syntax in the parser which is C_COUNT, C_QUANTITY etc > there is something wrong here; there is no such thing as C_COUNT; only > C_QUANTITY....see > [http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/openehr_archetype_profile.pdf](http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/openehr_archetype_profile.pdf) Yes this is most definitely wrong. We got confused when we saw the class CCount in the Java kernel. It's inheriting CDomainType but according to the specifications, this class shouldn't even exist. Maybe it exists as help so that one doesn't need to use the CComplexObject and do extra verification, for example checking for a possible attribute "magnitude". The problem is still that the parser won't allow COUNT with no attributes, e.g. no magnitude. However it is possible to create COUNTs with empty attributes with Oceans editor. > > > > Another thing is that RM object creation sometimes rely on that the > > syntax for constraints is DV_TEXT etc, but we think that the DV check > > in the function createRMObject should be skipped. > > > Do you mean to do with the names, i..e whether "DV_" is present? This is > a small problem which is more or less political. If we want archeytpes > to be shared beyond the openEHR community, they see "DV_" as an > openEHR-ism, so we often allow it to be removed in archetypes. The > proper solution is that a fixed set of aliases of class names is > allowed; at the moment, this includes: > > - all DV_XXX can be just XXX in archetypes > - all ITEM_XXX can be just XXX in archetypes > > The Ocean editor implements this mapping. Any tool should probably allow > both kinds of class names, i.e. the alias should not replace the > original set of valid names, just add to it. This sounds okay, as long as the naming is consistent. We don't think it would be a good idea to allow things to be all mixed up. A question however, why is the naming C_QUANTITY often used in Oceans archetypes but not C_ORDINAL (only ORDINAL with a "value" attribute and not the specified "value" and "symbol") nor C_CODED_TEXT? It is very hard to remember the naming conventions and it would be good if the relations of the naming were explained in some FAQ. The question is probably easy to answer for the one who wrote the specifications but we tend to mix these up all the time. Regards, Mattias & Johan --- ## Post #11 by @rong.chen Mattias Forss wrote: > > 2006/4/3, Thomas Beale <Thomas\.Beale@oceaninformatics\.biz > <mailto:Thomas.Beale@oceaninformatics.biz>>: > >     Johan Hjalmarsson wrote: >     > We have come up some issues that concerns the parser and AOM\. >     > >     > For example the current implementation support standard ADL >     COUNT data >     > type as it would be an openEHR profile C\_COUNT data type\. This means >     > that whenever the parser finds a COUNT it will check for mandatory >     > attributes that adhere to the C\_COUNT \(openEHR profile data >     type\) and >     > try to instantiate the CCount class in the kernel, but this is not >     > correct\. Instead it should only instantitate a CComplexObject so >     that >     > it could be possible to have a data type that don't have any >     > attributes, e\.g\. COUNT matches \{\*\} which means that the >     CComplexObject >     > has the any allowed flag set to true\. So this means, that for >     all the >     > constraints that are domain type constraints you need to check >     for the >     > correct syntax in the parser which is C\_COUNT, C\_QUANTITY etc > >     there is something wrong here; there is no such thing as C\_COUNT; only >     C\_QUANTITY\.\.\.\.see >     http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/openehr_archetype_profile.pdf > > Yes this is most definitely wrong\. We got confused when we saw the > class CCount in the Java kernel\. It's inheriting CDomainType but > according to the specifications, this class shouldn't even > exist\. Maybe it exists as help so that one doesn't need to use the > CComplexObject and do extra verification, for example checking for a > possible attribute "magnitude"\. The problem is still that the parser > won't allow COUNT with no attributes, e\.g\. no magnitude\. However it is > possible to create COUNTs with empty attributes with Oceans editor\. All CDomainType classes will be updated according to the latest openehr\_archetype\_profile in the AOM and parser soon\. Rong --- ## Post #12 by @thomas.beale Mattias Forss wrote: > > 2006/4/3, Thomas Beale <Thomas\.Beale@oceaninformatics\.biz > <mailto:Thomas.Beale@oceaninformatics.biz>>: > >     Johan Hjalmarsson wrote: >     > We have come up some issues that concerns the parser and AOM\. >     > >     > For example the current implementation support standard ADL >     COUNT data >     > type as it would be an openEHR profile C\_COUNT data type\. This means >     > that whenever the parser finds a COUNT it will check for mandatory >     > attributes that adhere to the C\_COUNT \(openEHR profile data >     type\) and >     > try to instantiate the CCount class in the kernel, but this is not >     > correct\. Instead it should only instantitate a CComplexObject so >     that >     > it could be possible to have a data type that don't have any >     > attributes, e\.g\. COUNT matches \{\*\} which means that the >     CComplexObject >     > has the any allowed flag set to true\. So this means, that for >     all the >     > constraints that are domain type constraints you need to check >     for the >     > correct syntax in the parser which is C\_COUNT, C\_QUANTITY etc > >     there is something wrong here; there is no such thing as C\_COUNT; only >     C\_QUANTITY\.\.\.\.see >     http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/openehr_archetype_profile.pdf > > Yes this is most definitely wrong\. We got confused when we saw the > class CCount in the Java kernel\. It's inheriting CDomainType but > according to the specifications, this class shouldn't even > exist\. Maybe it exists as help so that one doesn't need to use the > CComplexObject and do extra verification, for example checking for a > possible attribute "magnitude"\. The problem is still that the parser > won't allow COUNT with no attributes, e\.g\. no magnitude\. However it is > possible to create COUNTs with empty attributes with Oceans editor\. some\_attr matches \{     COUNT matches \{\} \} \-\- this means: some\_attr has to be a COUNT, but we don't care what the values are \(any value is valid\) This kind of pattern has to be allowed for any type\. \- thomas --- **Canonical:** https://discourse.openehr.org/t/wish-list-updated-and-current-status-of-the-java-archetype-editor/14520 **Original content:** https://discourse.openehr.org/t/wish-list-updated-and-current-status-of-the-java-archetype-editor/14520