# Implementation planning **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2006-06-26 12:39 UTC **Views:** 12 **Replies:** 15 **URL:** https://discourse.openehr.org/t/implementation-planning/14550 --- ## Post #1 by @Mattias_Forss1 Hello development team, I think we need to start a discussion on possible changes/updates to the current implementation plan for the Java reference implementation. What I've seen this far is that the UCL team has done a fair part of the RM and I wonder if the team can possibly implement some parts in the AOM and the parser in the near future. Personally I believe the assertion package of the AOM and its link to the parser is important to implement so that the Java archetype editor can handle archetype slots properly. Further, there is a need to implement support for assumed values of CDomainType datatypes in the AOM and parser. Currently only CPrimitive datatypes can have assumed values and I'm not even sure if the current implementation support assumed values for all primitive datatypes. Another important upgrade is to deal with the adl_version keyword and also to finish the description part which doesn't work fully for round trips (save/load) with the editor. I have encountered problems with keywords, originial_resource_uri and other_contributors in the description part. Now to the implementation of action and instruction support. I understand that this require some major updates of the RM (mostly in the entry package) but how has this work progressed? Has it started at all? If not, can other resources be put on this work? When can I expect to start implementing support for action and instruction archetypes in the Java archetype editor? Regards, Mattias Forss --- ## Post #2 by @thomas.beale Hi Mattias, Mattias Forss wrote: > Hello development team, > > I think we need to start a discussion on possible changes/updates to > the current implementation plan for the Java reference implementation\. > What I've seen this far is that the UCL team has done a fair part of > the RM and I wonder if the team can possibly implement some parts in > the AOM and the parser in the near future\. we're just getting the date/time stuff sorted \- it's amazingly annoyingly difficult\.\.\.\. > > Personally I believe the assertion package of the AOM and its link to > the parser is important to implement so that the Java archetype editor > can handle archetype slots properly\. > > Further, there is a need to implement support for assumed values of > CDomainType datatypes in the AOM and parser\. Currently only CPrimitive > datatypes can have assumed values and I'm not even sure if the current > implementation support assumed values for all primitive datatypes\. I had originally envisaged assumed values for non\-prmitive types, but have never seen an example of where it is needed\. Do you have such an example? > > Another important upgrade is to deal with the adl\_version keyword and > also to finish the description part which doesn't work fully for round > trips \(save/load\) with the editor\. I have encountered problems with > keywords, originial\_resource\_uri and other\_contributors in the > description part\. is this because the java parser doesn't yet implement dADL completely? > > Now to the implementation of action and instruction support\. I > understand that this require some major updates of the RM \(mostly in > the entry package\) but how has this work progressed? Has it started at > all? If not, can other resources be put on this work? When can I > expect to start implementing support for action and instruction > archetypes in the Java archetype editor? hm\.\.\.good question \- I have to check with Yin Su about how much time she has\.\.\.will get back to the group in the next day or so on this\. \- thomas --- ## Post #3 by @Mattias_Forss1 > Hi Mattias, > > Mattias Forss wrote: > > Hello development team, > > > > I think we need to start a discussion on possible changes/updates to > > the current implementation plan for the Java reference implementation. > > What I've seen this far is that the UCL team has done a fair part of > > the RM and I wonder if the team can possibly implement some parts in > > the AOM and the parser in the near future. > we're just getting the date/time stuff sorted - it's amazingly > annoyingly difficult.... In the Java reference implementation? I thought it was okay according to the specifications. The parser says question marks are okay and I believe we have to deviate from the ISO8601 in order to see what we are dealing with when dates are too inaccurate. I guess that is needed for all the peculiar situations that can occur in this domain. < V_ISO8601_DATE_CONSTRAINT_PATTERN: (){4}"-""-" > < #YY: ["y","Y"]> > < #MMQX_2: (["m","M","?","X"]){2}> > < #MMQ_2: (["m","M","?"]){2}> > > > > Personally I believe the assertion package of the AOM and its link to > > the parser is important to implement so that the Java archetype editor > > can handle archetype slots properly. > > > > Further, there is a need to implement support for assumed values of > > CDomainType datatypes in the AOM and parser. Currently only CPrimitive > > datatypes can have assumed values and I'm not even sure if the current > > implementation support assumed values for all primitive datatypes. > I had originally envisaged assumed values for non-prmitive types, but > have never seen an example of where it is needed. Do you have such an > example? Yes, a good example is for body positions when measuring a blood pressure: ELEMENT[at0008] occurrences matches {0..1} matches { -- Position value matches { CODED_TEXT matches { code matches { [local:: at1000, -- Standing at1001, -- Sitting at1002, -- Reclining at1003; -- Lying at1001] -- assumed value } } } } > > > > Another important upgrade is to deal with the adl_version keyword and > > also to finish the description part which doesn't work fully for round > > trips (save/load) with the editor. I have encountered problems with > > keywords, originial_resource_uri and other_contributors in the > > description part. > is this because the java parser doesn't yet implement dADL completely? Yes, but also due to the ADLOutputter which is not outputting some parts at all. > > > > Now to the implementation of action and instruction support. I > > understand that this require some major updates of the RM (mostly in > > the entry package) but how has this work progressed? Has it started at > > all? If not, can other resources be put on this work? When can I > > expect to start implementing support for action and instruction > > archetypes in the Java archetype editor? > hm...good question - I have to check with Yin Su about how much time she > has...will get back to the group in the next day or so on this. > > - thomas Okay, thanks. Regards, Mattias --- ## Post #4 by @rong.chen Mattias Forss wrote: > Hello development team, > > I think we need to start a discussion on possible changes/updates to > the current implementation plan for the Java reference implementation\. > What I've seen this far is that the UCL team has done a fair part of > the RM and I wonder if the team can possibly implement some parts in > the AOM and the parser in the near future\. Currently all unit cases of the RM have been disconnected after the RM update\. I would recommend the team to re\-connect the unit test code to conclude the update\. It perhaps requires more effort to do testing than just to update the main classes, but we really need to have good coverage of test code to insure the quality of the kernel\. Actually I believe it should be the next logical step for the reference Java implementation development\. > Personally I believe the assertion package of the AOM and its link to > the parser is important to implement so that the Java archetype editor > can handle archetype slots properly\. > > Further, there is a need to implement support for assumed values of > CDomainType datatypes in the AOM and parser\. Currently only CPrimitive > datatypes can have assumed values and I'm not even sure if the current > implementation support assumed values for all primitive datatypes\. Yes, it does\. All primitive datatypes support assumed values\. They are implemented in the parser and all covered by according unit test\. See adl\-test\-entry\.basic\_types\.test\.adl and BasicTypesTest\.java from the parser package\. > > Another important upgrade is to deal with the adl\_version keyword and > also to finish the description part which doesn't work fully for round > trips \(save/load\) with the editor\. I have encountered problems with > keywords, originial\_resource\_uri and other\_contributors in the > description part\. I will look into these\. I am aware of a limitation from the parser that it is sensitive to the order of these keywords\. It shouldn't of course\. It will be helpful if you could send in a minimum ADL that demonstrate the bug you encountered\. Regards, Rong --- ## Post #5 by @thomas.beale Mattias Forss wrote: > >     Hi Mattias, > >     Mattias Forss wrote: >     > Hello development team, >     > >     > I think we need to start a discussion on possible changes/updates to >     > the current implementation plan for the Java reference >     implementation\. >     > What I've seen this far is that the UCL team has done a fair >     part of >     > the RM and I wonder if the team can possibly implement some parts in >     > the AOM and the parser in the near future\. >     we're just getting the date/time stuff sorted \- it's amazingly >     annoyingly difficult\.\.\.\. > > In the Java reference implementation? I thought it was okay according > to the specifications\. > > The parser says question marks are okay and I believe we have to > deviate from the ISO8601 in order to see what we are dealing with when > dates are too inaccurate\. I guess that is needed for all the peculiar > situations that can occur in this domain\. > > < V\_ISO8601\_DATE\_CONSTRAINT\_PATTERN: \(<YY>\)\{4\}"\-"<MMQX\_2>"\-"<DDQX\_2> > > >   < \#YY: \["y","Y"\]> > > >   < \#MMQX\_2: \(\["m","M","?","X"\]\)\{2\}> > > >   < \#MMQ\_2: \(\["m","M","?"\]\)\{2\}> We have made a major effort to upgrade the specs to be ISO8601\-compliant \(the latest drafts will go online today\) but in places where there is no context \- e\.g\. you don't know what data type you are dealing with, which is the case with dADL, ISO8601 is not great, because they didn't take care to make the syntax context\-insensitive\. Thus you can't safely differentiate the following: \- 1924 \(an integer\) \- 1924 \(a year\) \- 1924 \(a time, i\.e\. 19:24 in the evening\) Nevertheless, for all other dates and times, if extended format is used \(':', '\-' markers\) then ISO8601 is distinguishable from other things\. My proposal in dADL is to support standard ISO8601 as far as possible \- allow extended form only; but also to support the form I describe using the ?? characters, so that a single year lke 1924 can be written unambiguously as 1924\-??\-??\. This means: \- for me in Eiffel, adding in the ?? support in dADL \- for you in Java \- adding in ISO8601 support for extended form\. This means that both parsers will be "forgiving" but still allow a way of avoiding the ambiguity of ISO8601\. I have all the parsing patterns and ISO8601 classes in Eiffel if you want to look at them, and Yin Su is nearly done converting these to Java, which you should be able to look at very soon\. thoughts on this approach? > >     > >     > Personally I believe the assertion package of the AOM and its >     link to >     > the parser is important to implement so that the Java archetype >     editor >     > can handle archetype slots properly\. > do you have some examples of where more complex assertions are needed than are now possible? > >     > >     > Further, there is a need to implement support for assumed values of >     > CDomainType datatypes in the AOM and parser\. Currently only >     CPrimitive >     > datatypes can have assumed values and I'm not even sure if the >     current >     > implementation support assumed values for all primitive datatypes\. >     I had originally envisaged assumed values for non\-prmitive types, but >     have never seen an example of where it is needed\. Do you have such an >     example? > > Yes, a good example is for body positions when measuring a blood > pressure: > >                     ELEMENT\[at0008\] occurrences matches \{0\.\.1\} matches > \{ \-\- Position >                         value matches \{ >                             CODED\_TEXT matches \{ >                                 code matches \{ >                                     \[local:: >                                     at1000, \-\- Standing >                                     at1001, \-\- Sitting >                                     at1002, \-\- Reclining >                                     at1003; \-\- Lying >                                     at1001\] \-\- assumed value >                                 \} >                             \} >                         \} >                     \} ah \- this is already supported in the specs and in the Eiffel parser \- so it is just a limitation of the Java parser at the moment\. > >     > >     > Another important upgrade is to deal with the adl\_version >     keyword and >     > also to finish the description part which doesn't work fully for >     round >     > trips \(save/load\) with the editor\. I have encountered problems with >     > keywords, originial\_resource\_uri and other\_contributors in the >     > description part\. >     is this because the java parser doesn't yet implement dADL completely? > > Yes, but also due to the ADLOutputter which is not outputting some > parts at all\. In the Eiffel parser, there is an AOM object ARCHETYPE\_DESCRIPTION and a generic dADL serialiser / deserialiser\. I read that part of the archetype in using the generic dADL reader and then call the dADL deserialiser and it generates the ARCHETYPE\_DESCRIPTION object\. And the reverse for deserialising\. When we get to ADL 2, the whole archetype will be dADL with a lump of cADL in the middle and possibly some assertions; this will enable the archetype as a whole to be parsed as a dADL document, and sub\-parsers invoked for the non\-dADL parts\. I have already tested some of this in Eiffel\. \- thomas --- ## Post #6 by @Mattias_Forss Thomas Beale wrote: > Mattias Forss wrote: >   >>     Hi Mattias, >> >>     Mattias Forss wrote: >>     > Hello development team, >>     > >>     > I think we need to start a discussion on possible changes/updates to >>     > the current implementation plan for the Java reference >>     implementation\. >>     > What I've seen this far is that the UCL team has done a fair >>     part of >>     > the RM and I wonder if the team can possibly implement some parts in >>     > the AOM and the parser in the near future\. >>     we're just getting the date/time stuff sorted \- it's amazingly >>     annoyingly difficult\.\.\.\. >> >> In the Java reference implementation? I thought it was okay according >> to the specifications\. >> >> The parser says question marks are okay and I believe we have to >> deviate from the ISO8601 in order to see what we are dealing with when >> dates are too inaccurate\. I guess that is needed for all the peculiar >> situations that can occur in this domain\. >> >> < V\_ISO8601\_DATE\_CONSTRAINT\_PATTERN: \(<YY>\)\{4\}"\-"<MMQX\_2>"\-"<DDQX\_2> > >> >>   < \#YY: \["y","Y"\]> >> > >>   < \#MMQX\_2: \(\["m","M","?","X"\]\)\{2\}> >> > >>   < \#MMQ\_2: \(\["m","M","?"\]\)\{2\}> >>     > > We have made a major effort to upgrade the specs to be ISO8601\-compliant > \(the latest drafts will go online today\) but in places where there is no > context \- e\.g\. you don't know what data type you are dealing with, which > is the case with dADL, ISO8601 is not great, because they didn't take > care to make the syntax context\-insensitive\. Thus you can't safely > differentiate the following: > \- 1924 \(an integer\) > \- 1924 \(a year\) > \- 1924 \(a time, i\.e\. 19:24 in the evening\) > > Nevertheless, for all other dates and times, if extended format is used > \(':', '\-' markers\) then ISO8601 is distinguishable from other things\. > > My proposal in dADL is to support standard ISO8601 as far as possible \- > allow extended form only; but also to support the form I describe using > the ?? characters, so that a single year lke 1924 can be written > unambiguously as 1924\-??\-??\. > > This means: > \- for me in Eiffel, adding in the ?? support in dADL > \- for you in Java \- adding in ISO8601 support for extended form\. > > This means that both parsers will be "forgiving" but still allow a way > of avoiding the ambiguity of ISO8601\. > > I have all the parsing patterns and ISO8601 classes in Eiffel if you > want to look at them, and Yin Su is nearly done converting these to > Java, which you should be able to look at very soon\. > > thoughts on this approach? >   Sounds find to me\. I don't think there are much changes \(if any\) to do in the Java parser\. It is already very "forgiving" for date/times and what I can tell it looks for extended form of ISO8601 and with an extra check for question marks if present\. Perhaps it should also allow ":" as a delimiter for the extended form? Currently only "\-" is allowed as a delimiter\. >>     > >>     > Personally I believe the assertion package of the AOM and its >>     link to >>     > the parser is important to implement so that the Java archetype >>     editor >>     > can handle archetype slots properly\. >> > > do you have some examples of where more complex assertions are needed > than are now possible? >   No, but I heard from Rong that he wanted to implement this package in order to support archetype slots\. Maybe I'm not getting this right, a new package is maybe not needed for archetype slot support\.\.\. >>     > >>     > Further, there is a need to implement support for assumed values of >>     > CDomainType datatypes in the AOM and parser\. Currently only >>     CPrimitive >>     > datatypes can have assumed values and I'm not even sure if the >>     current >>     > implementation support assumed values for all primitive datatypes\. >>     I had originally envisaged assumed values for non\-prmitive types, but >>     have never seen an example of where it is needed\. Do you have such an >>     example? >> >> Yes, a good example is for body positions when measuring a blood >> pressure: >> >>                     ELEMENT\[at0008\] occurrences matches \{0\.\.1\} matches >> \{ \-\- Position >>                         value matches \{ >>                             CODED\_TEXT matches \{ >>                                 code matches \{ >>                                     \[local:: >>                                     at1000, \-\- Standing >>                                     at1001, \-\- Sitting >>                                     at1002, \-\- Reclining >>                                     at1003; \-\- Lying >>                                     at1001\] \-\- assumed value >>                                 \} >>                             \} >>                         \} >>                     \} >>     > > ah \- this is already supported in the specs and in the Eiffel parser \- > so it is just a limitation of the Java parser at the moment\. >   >>     > >>     > Another important upgrade is to deal with the adl\_version >>     keyword and >>     > also to finish the description part which doesn't work fully for >>     round >>     > trips \(save/load\) with the editor\. I have encountered problems with >>     > keywords, originial\_resource\_uri and other\_contributors in the >>     > description part\. >>     is this because the java parser doesn't yet implement dADL completely? >> >> Yes, but also due to the ADLOutputter which is not outputting some >> parts at all\. >>     > > In the Eiffel parser, there is an AOM object ARCHETYPE\_DESCRIPTION and a > generic dADL serialiser / deserialiser\. I read that part of the > archetype in using the generic dADL reader and then call the dADL > deserialiser and it generates the ARCHETYPE\_DESCRIPTION object\. And the > reverse for deserialising\. When we get to ADL 2, the whole archetype > will be dADL with a lump of cADL in the middle and possibly some > assertions; this will enable the archetype as a whole to be parsed as a > dADL document, and sub\-parsers invoked for the non\-dADL parts\. I have > already tested some of this in Eiffel\. >   This strategy should be used in the java reference implementation if possible\.\.\. --- ## Post #7 by @Mattias_Forss1 Thomas Beale wrote: > Mattias Forss wrote: > > > Hi Mattias, > > > > Mattias Forss wrote: > > > Hello development team, > > > > > > I think we need to start a discussion on possible changes/updates to > > > the current implementation plan for the Java reference > > implementation. > > > What I've seen this far is that the UCL team has done a fair > > part of > > > the RM and I wonder if the team can possibly implement some parts in > > > the AOM and the parser in the near future. > > we're just getting the date/time stuff sorted - it's amazingly > > annoyingly difficult.... > > > > In the Java reference implementation? I thought it was okay according to the specifications. > > > > The parser says question marks are okay and I believe we have to deviate from the ISO8601 in order to see what we are dealing with when dates are too inaccurate. I guess that is needed for all the peculiar situations that can occur in this domain. > > > > < V_ISO8601_DATE_CONSTRAINT_PATTERN: (){4}"-""-" > > > > > < #YY: ["y","Y"]> > > > > > < #MMQX_2: (["m","M","?","X"]){2}> > > > > > < #MMQ_2: (["m","M","?"]){2}> > > We have made a major effort to upgrade the specs to be ISO8601-compliant (the latest drafts will go online today) but in places where there is no context - e.g. you don't know what data type you are dealing with, which is the case with dADL, ISO8601 is not great, because they didn't take care to make the syntax context-insensitive. Thus you can't safely differentiate the following: > - 1924 (an integer) > - 1924 (a year) > - 1924 (a time, i.e. 19:24 in the evening) > > Nevertheless, for all other dates and times, if extended format is used (':', '-' markers) then ISO8601 is distinguishable from other things. > > My proposal in dADL is to support standard ISO8601 as far as possible - allow extended form only; but also to support the form I describe using the ?? characters, so that a single year lke 1924 can be written unambiguously as 1924-??-??. > > This means: > - for me in Eiffel, adding in the ?? support in dADL > - for you in Java - adding in ISO8601 support for extended form. > > This means that both parsers will be "forgiving" but still allow a way of avoiding the ambiguity of ISO8601. > > I have all the parsing patterns and ISO8601 classes in Eiffel if you want to look at them, and Yin Su is nearly done converting these to Java, which you should be able to look at very soon. > > thoughts on this approach? Sounds find to me. I don't think there are much changes (if any) to do in the Java parser. It is already very "forgiving" for date/times and what I can tell it looks for extended form of ISO8601 and with an extra check for question marks if present. Perhaps it should also allow ":" as a delimiter for the extended form? Currently only "-" is allowed as a delimiter. > > > > > > Personally I believe the assertion package of the AOM and its > > link to > > > the parser is important to implement so that the Java archetype > > editor > > > can handle archetype slots properly. > > do you have some examples of where more complex assertions are needed than are now possible? No, but I heard from Rong that he wanted to implement this package in order to support archetype slots. Maybe I'm not getting this right, a new package is maybe not needed for archetype slot support... > > > > > > Further, there is a need to implement support for assumed values of > > > CDomainType datatypes in the AOM and parser. Currently only > > CPrimitive > > > datatypes can have assumed values and I'm not even sure if the > > current > > > implementation support assumed values for all primitive datatypes. > > I had originally envisaged assumed values for non-prmitive types, but > > have never seen an example of where it is needed. Do you have such an > > example? > > > > Yes, a good example is for body positions when measuring a blood pressure: > > > > ELEMENT[at0008] occurrences matches {0..1} matches { -- Position > > value matches { > > CODED_TEXT matches { > > code matches { > > [local:: > > at1000, -- Standing > > at1001, -- Sitting > > at1002, -- Reclining > > at1003; -- Lying > > at1001] -- assumed value > > } > > } > > } > > } > > ah - this is already supported in the specs and in the Eiffel parser - so it is just a limitation of the Java parser at the moment. > > > > > > > Another important upgrade is to deal with the adl_version > > keyword and > > > also to finish the description part which doesn't work fully for > > round > > > trips (save/load) with the editor. I have encountered problems with > > > keywords, originial_resource_uri and other_contributors in the > > > description part. > > is this because the java parser doesn't yet implement dADL completely? > > > > Yes, but also due to the ADLOutputter which is not outputting some parts at all. > > In the Eiffel parser, there is an AOM object ARCHETYPE_DESCRIPTION and a generic dADL serialiser / deserialiser. I read that part of the archetype in using the generic dADL reader and then call the dADL deserialiser and it generates the ARCHETYPE_DESCRIPTION object. And the reverse for deserialising. When we get to ADL 2, the whole archetype will be dADL with a lump of cADL in the middle and possibly some assertions; this will enable the archetype as a whole to be parsed as a dADL document, and sub-parsers invoked for the non-dADL parts. I have already tested some of this in Eiffel. This strategy should be used in the java reference implementation if possible... --- ## Post #8 by @Mattias_Forss1 Hi Rong, I'm attaching three ADL-files I've experienced bugs with. The **imaging** archetype has the following attributes under details for the description part, but they are not stored in the ArchetypeDescription object by the parser. use = <""> keywords = <"Xray", "X-ray", "radiology"> misuse = <""> The **adverse** archetype fails on other contributors. se.acode.openehr.parser.TokenMgrError: Lexical error at line 13, column 15. Encountered: "c" (99), after : "other_" Also, this archetype has an original_resource_uri but it will fail saying java.lang.IllegalArgumentException: null or empty details when other_contributors is removed. If you compare the original_resource_uri content in the adverse archetype with what the ADLOutputter gives when I create an archetype the result is not the same so this must be fixed according to specifications. My test result: original_resource_uri = <"a","b","c"> The **apgar** archetype has the following error: se.acode.openehr.parser.ParseException: Encountered "| P1m |" at line 30, column 65. I think the parser expects an interval but in some Ocean archetypes an interval is not neccesarily present within the pipe-delimiters. "|" ... > ``` > Mattias Forss wrote: > > ``` > > > ``` > > Hello development team, > > > > I think we need to start a discussion on possible changes/updates to > > the current implementation plan for the Java reference implementation. > > What I've seen this far is that the UCL team has done a fair part of > > > > the RM and I wonder if the team can possibly implement some parts in > > the AOM and the parser in the near future. > > > > ``` > > ``` > Currently all unit cases of the RM have been disconnected after the RM > update. I would recommend the team to re-connect the unit test code to > conclude the update. It perhaps requires more effort to do testing than > > just to update the main classes, but we really need to have good > coverage of test code to insure the quality of the kernel. Actually I > believe it should be the next logical step for the reference Java > implementation development. > > ``` The test cases are of course the most important, but for me as an archetype editor developer I don't find them as important at this stage since I'm not dealing with that part of the kernel. However, it must be done in order to create valid EHRs with the archetypes but probably they will have to be improved over a long time. I think it will take quite a lot of time to develop proper test cases. > ``` > > > ``` > > > ``` > > Personally I believe the assertion package of the AOM and its link to > > the parser is important to implement so that the Java archetype editor > > can handle archetype slots properly. > > > > Further, there is a need to implement support for assumed values of > > CDomainType datatypes in the AOM and parser. Currently only CPrimitive > > datatypes can have assumed values and I'm not even sure if the current > > > > implementation support assumed values for all primitive datatypes. > > > > ``` > > ``` > Yes, it does. All primitive datatypes support assumed values. They are > implemented in the parser and all covered by according unit test. See > adl-test-entry.basic_types.test.adl and BasicTypesTest.java from the > > parser package. > > ``` Assumed values should also be implemented in CCodedText and maybe COrdinal. [details="(attachments)"] [openEHR-EHR-OBSERVATION.imaging.v1.adl|attachment](upload://r4o7JrpW7A6ThvaRulpURN4SxFs.adl) (6.8 KB) [openEHR-EHR-EVALUATION.adverse.v1.adl|attachment](upload://16VR8tdcYU8zxMDVe7vVbAbpprK.adl) (8.29 KB) [openEHR-EHR-OBSERVATION.apgar.v1.adl|attachment](upload://kPiac4hm3Y6e1nQRtGA6rpe8gZg.adl) (12.1 KB) [/details] --- ## Post #9 by @thomas.beale Mattias Forss wrote: > Thomas Beale wrote: >> Mattias Forss wrote: >> >>>     Hi Mattias, >>> >>>     Mattias Forss wrote: >>>     > Hello development team, >>>     > >>>     > I think we need to start a discussion on possible >>> changes/updates to >>>     > the current implementation plan for the Java reference >>>     implementation\. >>>     > What I've seen this far is that the UCL team has done a fair >>>     part of >>>     > the RM and I wonder if the team can possibly implement some >>> parts in >>>     > the AOM and the parser in the near future\. >>>     we're just getting the date/time stuff sorted \- it's amazingly >>>     annoyingly difficult\.\.\.\. >>> >>> In the Java reference implementation? I thought it was okay >>> according to the specifications\. >>> >>> The parser says question marks are okay and I believe we have to >>> deviate from the ISO8601 in order to see what we are dealing with >>> when dates are too inaccurate\. I guess that is needed for all the >>> peculiar situations that can occur in this domain\. >>> >>> < V\_ISO8601\_DATE\_CONSTRAINT\_PATTERN: \(<YY>\)\{4\}"\-"<MMQX\_2>"\-"<DDQX\_2> > >>> >>>   < \#YY: \["y","Y"\]> >>> > >>>   < \#MMQX\_2: \(\["m","M","?","X"\]\)\{2\}> >>> > >>>   < \#MMQ\_2: \(\["m","M","?"\]\)\{2\}> >>>     >> >> We have made a major effort to upgrade the specs to be >> ISO8601\-compliant \(the latest drafts will go online today\) but in >> places where there is no context \- e\.g\. you don't know what data type >> you are dealing with, which is the case with dADL, ISO8601 is not >> great, because they didn't take care to make the syntax >> context\-insensitive\. Thus you can't safely differentiate the following: >> \- 1924 \(an integer\) >> \- 1924 \(a year\) >> \- 1924 \(a time, i\.e\. 19:24 in the evening\) >> >> Nevertheless, for all other dates and times, if extended format is >> used \(':', '\-' markers\) then ISO8601 is distinguishable from other >> things\. >> >> My proposal in dADL is to support standard ISO8601 as far as possible >> \- allow extended form only; but also to support the form I describe >> using the ?? characters, so that a single year lke 1924 can be >> written unambiguously as 1924\-??\-??\. >> >> This means: >> \- for me in Eiffel, adding in the ?? support in dADL >> \- for you in Java \- adding in ISO8601 support for extended form\. >> >> This means that both parsers will be "forgiving" but still allow a >> way of avoiding the ambiguity of ISO8601\. >> >> I have all the parsing patterns and ISO8601 classes in Eiffel if you >> want to look at them, and Yin Su is nearly done converting these to >> Java, which you should be able to look at very soon\. >> >> thoughts on this approach? >>   > > Sounds find to me\. > > I don't think there are much changes \(if any\) to do in the Java > parser\. It is already very "forgiving" for date/times and what I can > tell it looks for extended form of ISO8601 and with an extra check for > question marks if present\. Perhaps it should also allow ":" as a > delimiter for the extended form? Currently only "\-" is allowed as a > delimiter\. it should definitely implement ':' for time and '\-' for date \- that is one thing everyone agrees on\! >>>     > >>>     > Personally I believe the assertion package of the AOM and its >>>     link to >>>     > the parser is important to implement so that the Java archetype >>>     editor >>>     > can handle archetype slots properly\. >>> >> >> do you have some examples of where more complex assertions are needed >> than are now possible? >>   > > No, but I heard from Rong that he wanted to implement this package in > order to support archetype slots\. Maybe I'm not getting this right, a > new package is maybe not needed for archetype slot support\.\.\. I think we need to be driven by real needs at the moment \- let's not build too much software that doesn't need to be built\. \- thomas --- ## Post #10 by @Mattias_Forss1 2006/6/27, Thomas Beale <[Thomas.Beale@oceaninformatics.biz](mailto:Thomas.Beale@oceaninformatics.biz)>: > Mattias Forss wrote: > > Thomas Beale wrote: > >> Mattias Forss wrote: > >> > >>> Hi Mattias, > >>> > >>> Mattias Forss wrote: > >>> > Hello development team, > >>> > > >>> > I think we need to start a discussion on possible > >>> changes/updates to > >>> > the current implementation plan for the Java reference > >>> implementation. > >>> > What I've seen this far is that the UCL team has done a fair > >>> part of > >>> > the RM and I wonder if the team can possibly implement some > >>> parts in > >>> > the AOM and the parser in the near future. > >>> we're just getting the date/time stuff sorted - it's amazingly > >>> annoyingly difficult.... > >>> > >>> In the Java reference implementation? I thought it was okay > >>> according to the specifications. > >>> > >>> The parser says question marks are okay and I believe we have to > >>> deviate from the ISO8601 in order to see what we are dealing with > >>> when dates are too inaccurate. I guess that is needed for all the > >>> peculiar situations that can occur in this domain. > >>> > >>> < V_ISO8601_DATE_CONSTRAINT_PATTERN: (){4}"-""-" > > >>> > >>> < #YY: ["y","Y"]> > >>> > > >>> < #MMQX_2: (["m","M","?","X"]){2}> > >>> > > >>> < #MMQ_2: (["m","M","?"]){2}> > >>> > >> We have made a major effort to upgrade the specs to be > >> ISO8601-compliant (the latest drafts will go online today) but in > >> places where there is no context - e.g. you don't know what data type > >> you are dealing with, which is the case with dADL, ISO8601 is not > >> great, because they didn't take care to make the syntax > >> context-insensitive. Thus you can't safely differentiate the following: > >> - 1924 (an integer) > >> - 1924 (a year) > >> - 1924 (a time, i.e. 19:24 in the evening) > >> > >> Nevertheless, for all other dates and times, if extended format is > >> used (':', '-' markers) then ISO8601 is distinguishable from other > >> things. > >> > >> My proposal in dADL is to support standard ISO8601 as far as possible > >> - allow extended form only; but also to support the form I describe > >> using the ?? characters, so that a single year lke 1924 can be > >> written unambiguously as 1924-??-??. > >> > >> This means: > >> - for me in Eiffel, adding in the ?? support in dADL > >> - for you in Java - adding in ISO8601 support for extended form. > >> > >> This means that both parsers will be "forgiving" but still allow a > >> way of avoiding the ambiguity of ISO8601. > >> > >> I have all the parsing patterns and ISO8601 classes in Eiffel if you > >> want to look at them, and Yin Su is nearly done converting these to > >> Java, which you should be able to look at very soon. > >> > >> thoughts on this approach? > >> > > Sounds find to me. > > > > I don't think there are much changes (if any) to do in the Java > > parser. It is already very "forgiving" for date/times and what I can > > tell it looks for extended form of ISO8601 and with an extra check for > > question marks if present. Perhaps it should also allow ":" as a > > delimiter for the extended form? Currently only "-" is allowed as a > > delimiter. > it should definitely implement ':' for time and '-' for date - that is > one thing everyone agrees on! Sorry I got confused about the delimiters! The parser has of course already implemented this! :-) --- ## Post #11 by @rong.chen Thomas Beale wrote: > Mattias Forss wrote: >   >> Thomas Beale wrote: >>     >>> Mattias Forss wrote: >>> >>>>     Hi Mattias, >>>> >>>>     Mattias Forss wrote: >>>>     > Hello development team, >>>>     > >>>>     > I think we need to start a discussion on possible >>>> changes/updates to >>>>     > the current implementation plan for the Java reference >>>>     implementation\. >>>>     > What I've seen this far is that the UCL team has done a fair >>>>     part of >>>>     > the RM and I wonder if the team can possibly implement some >>>> parts in >>>>     > the AOM and the parser in the near future\. >>>>     we're just getting the date/time stuff sorted \- it's amazingly >>>>     annoyingly difficult\.\.\.\. >>>> >>>> In the Java reference implementation? I thought it was okay >>>> according to the specifications\. >>>> >>>> The parser says question marks are okay and I believe we have to >>>> deviate from the ISO8601 in order to see what we are dealing with >>>> when dates are too inaccurate\. I guess that is needed for all the >>>> peculiar situations that can occur in this domain\. >>>> >>>> < V\_ISO8601\_DATE\_CONSTRAINT\_PATTERN: \(<YY>\)\{4\}"\-"<MMQX\_2>"\-"<DDQX\_2> > >>>> >>>>   < \#YY: \["y","Y"\]> >>>> > >>>>   < \#MMQX\_2: \(\["m","M","?","X"\]\)\{2\}> >>>> > >>>>   < \#MMQ\_2: \(\["m","M","?"\]\)\{2\}> >>>>     >>> >>> We have made a major effort to upgrade the specs to be >>> ISO8601\-compliant \(the latest drafts will go online today\) but in >>> places where there is no context \- e\.g\. you don't know what data type >>> you are dealing with, which is the case with dADL, ISO8601 is not >>> great, because they didn't take care to make the syntax >>> context\-insensitive\. Thus you can't safely differentiate the following: >>> \- 1924 \(an integer\) >>> \- 1924 \(a year\) >>> \- 1924 \(a time, i\.e\. 19:24 in the evening\) >>> >>> Nevertheless, for all other dates and times, if extended format is >>> used \(':', '\-' markers\) then ISO8601 is distinguishable from other >>> things\. >>> >>> My proposal in dADL is to support standard ISO8601 as far as possible >>> \- allow extended form only; but also to support the form I describe >>> using the ?? characters, so that a single year lke 1924 can be >>> written unambiguously as 1924\-??\-??\. >>> >>> This means: >>> \- for me in Eiffel, adding in the ?? support in dADL >>> \- for you in Java \- adding in ISO8601 support for extended form\. >>> >>> This means that both parsers will be "forgiving" but still allow a >>> way of avoiding the ambiguity of ISO8601\. >>> >>> I have all the parsing patterns and ISO8601 classes in Eiffel if you >>> want to look at them, and Yin Su is nearly done converting these to >>> Java, which you should be able to look at very soon\. >>>       That will be interesting to look at when it's ready\. >>> thoughts on this approach? >>>   >> >> Sounds find to me\. >> >> I don't think there are much changes \(if any\) to do in the Java >> parser\. It is already very "forgiving" for date/times and what I can >> tell it looks for extended form of ISO8601 and with an extra check for >> question marks if present\. Perhaps it should also allow ":" as a >> delimiter for the extended form? Currently only "\-" is allowed as a >> delimiter\. >>     > > it should definitely implement ':' for time and '\-' for date \- that is > one thing everyone agrees on\! >   That's exactly how it is implemented now\. >>>>     > >>>>     > Personally I believe the assertion package of the AOM and its >>>>     link to >>>>     > the parser is important to implement so that the Java archetype >>>>     editor >>>>     > can handle archetype slots properly\. >>>> >>> >>> do you have some examples of where more complex assertions are needed >>> than are now possible? >>>   >> >> No, but I heard from Rong that he wanted to implement this package in >> order to support archetype slots\. Maybe I'm not getting this right, a >> new package is maybe not needed for archetype slot support\.\.\. >>     > > I think we need to be driven by real needs at the moment \- let's not > build too much software that doesn't need to be built\. >   I agree\. The current ArchetypeSlot class uses Assertion class to specify inclusion and exclusion list\. Therefore, working ArchetypeSlot class would require implementation of assertion package, which is missing in the RM now\. I recall a temporary solution based on archetype name list were discussed, but not sure if it is worthy the effort to implement\. It may allow the editor/parser to work in round trips and but not useful for object creation\. Rong --- ## Post #12 by @Mattias_Forss1 By the way, now that I looked a bit more closely on the Java parser I saw that it allows the question mark extesion to ISO8601 only when the archetype contains a constraint of a date e.g. yyyy-??-?? but values with extensions, e.g. 1954-??-?? are not supported only values matching a pattern "yyyy-MM-dd". < V_DATE: (["0"-"9"]){4} "-" ( "0"["1"-"9"] | "1"["0"-"2"] ) "-" ( "0"["1"-"9"] | ["1"-"2"]["0"-"9"]|"3"["0"-"1"] ) > /Mattias 2006/6/27, Mattias Forss <[mattias.forss@gmail.com](mailto:mattias.forss@gmail.com)>: --- ## Post #13 by @rong.chen Mattias Forss wrote: > By the way, now that I looked a bit more closely on the Java parser I > saw that it allows the question mark extesion to ISO8601 only when the > archetype contains a constraint of a date e\.g\. yyyy\-??\-?? but values > with extensions, e\.g\. 1954\-??\-?? are not supported only values > matching a pattern "yyyy\-MM\-dd"\. > >   < V\_DATE: \(\["0"\-"9"\]\)\{4\} "\-" \( "0"\["1"\-"9"\] | "1"\["0"\-"2"\] \) "\-" >             \( "0"\["1"\-"9"\] | \["1"\-"2"\]\["0"\-"9"\]|"3"\["0"\-"1"\] \) > This is because the constraint is either a pattern which matches V\_ISO8601\_DATE\_CONSTRAINT\_PATTERN \(see below\), a date value or a list of date values, which matches the syntax you quoted above\. So I am not sure"1954\-??\-??" is valid according to the current ADL specs\. Rong \-\-\-\-\-\-\-\-\-\-/\* V\_ISO8601\_DATE\_CONSTRAINT\_PATTERN \*/ \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \[yY\]\[yY\]\[yY\]\[yY\]\-\[mM?X\]\[mM?X\]\-\[dD?X\]\[dD?X\] --- ## Post #14 by @Mattias_Forss1 This was what Thomas talked about in a previous mail: >> We have made a major effort to upgrade the specs to be >> ISO8601-compliant (the latest drafts will go online today) but in >> places where there is no context - e.g. you don't know what data type >> you are dealing with, which is the case with dADL, ISO8601 is not >> great, because they didn't take care to make the syntax >> context-insensitive. Thus you can't safely differentiate the following: >> - 1924 (an integer) >> - 1924 (a year) >> - 1924 (a time, i.e. 19:24 in the evening) >> >> Nevertheless, for all other dates and times, if extended format is >> used (':', '-' markers) then ISO8601 is distinguishable from other >> things. >> >> My proposal in dADL is to support standard ISO8601 as far as possible >> - allow extended form only; but also to support the form I describe >> using the ?? characters, so that a single year lke 1924 can be >> written unambiguously as 1924-??-??. /Mattias 2006/6/27, Rong Chen <[rong@acode.se](mailto:rong@acode.se)>: --- ## Post #15 by @rong.chen Mattias Forss wrote: > This was what Thomas talked about in a previous mail: > > >> We have made a major effort to upgrade the specs to be > >> ISO8601\-compliant \(the latest drafts will go online today\) but in > >> places where there is no context \- e\.g\. you don't know what data type > >> you are dealing with, which is the case with dADL, ISO8601 is not > >> great, because they didn't take care to make the syntax > >> context\-insensitive\. Thus you can't safely differentiate the following: > >> \- 1924 \(an integer\) > >> \- 1924 \(a year\) > >> \- 1924 \(a time, i\.e\. 19:24 in the evening\) > >> > >> Nevertheless, for all other dates and times, if extended format is > >> used \(':', '\-' markers\) then ISO8601 is distinguishable from other > >> things\. > >> > >> My proposal in dADL is to support standard ISO8601 as far as possible > >> \- allow extended form only; but also to support the form I describe > >> using the ?? characters, so that a single year lke 1924 can be > >> written unambiguously as 1924\-??\-??\. So it's coming\. It will be clear when the syntax is published\. Rong --- ## Post #16 by @thomas.beale See section 3\.5 of http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html We could also just remove the ?? stuff from dADL \(where it is not a constraint, just a way of indicating partial dates & times\) \- I don't mind one way or the other, but we need to find a way to express date=1924, time =19 \(i\.e\. 7pm\) in a way that won't be confused with integers\. \- thomas Rong Chen wrote: --- **Canonical:** https://discourse.openehr.org/t/implementation-planning/14550 **Original content:** https://discourse.openehr.org/t/implementation-planning/14550