Implementation planning

Reference Implementation: Java (archive)
1

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

2

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

3

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}“-”<MMQX_2>“-”<DDQX_2> >

< #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

4

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

5

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

6

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...

7

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}“-”<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…

8

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.

“|” <V_ISO8601_DURATION> …

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.

(attachments)

openEHR-EHR-OBSERVATION.imaging.v1.adl (6.8 KB)
openEHR-EHR-EVALUATION.adverse.v1.adl (8.29 KB)
openEHR-EHR-OBSERVATION.apgar.v1.adl (12.1 KB)

9

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

10

2006/6/27, Thomas Beale <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}“-”<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!

Sorry I got confused about the delimiters! The parser has of course already implemented this! :slight_smile:

11

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

12

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>:

13

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]

14

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>:

15

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

16

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: