As part of the finalisation of fixes to the Archetype Editor, ADL and
ADL parsers, Sam has proposed to add a precision attribute to
C_QUANTITY. This would be of type Interval<Integer>, although in the
archetypes he is currently doing, only a single value is needed. The
typical example is to allow/disallow decimals, such as for blood
pressure values (where they are never used), so the precision would be 0.
I will add this to the Eiffel parser so that he can put it in the Ocean
tool; I will also update the C_QUANTITY definition to include it, so
that Rong can change the Java parser, which should be easier, and
Mattias can change the Archetype Editor. Lastly we will put in a CR for
it, so it is indicated properly in the specs. All in the right order,
just backwards
Once this change is done, we intend to put up a "clean" set of
archetypes onto the knowledge SVN repo, which should address the many
issues Mattias and others have found over the last few months. When we
have all done a bit of further checking and testing on this, we will tag
the release in SVN so it becomes a reference baseline.
As part of the finalisation of fixes to the Archetype Editor, ADL and
ADL parsers, Sam has proposed to add a precision attribute to
C_QUANTITY. This would be of type Interval<Integer>, although in the
archetypes he is currently doing, only a single value is needed. The
typical example is to allow/disallow decimals, such as for blood
pressure values (where they are never used), so the precision would be 0.
of course, I meant to say C_QUANTITY_ITEM - that is where the precision
has to go...
As part of the finalisation of fixes to the Archetype Editor, ADL and
ADL parsers, Sam has proposed to add a precision attribute to
C_QUANTITY. This would be of type Interval, although in the
archetypes he is currently doing, only a single value is needed. The
typical example is to allow/disallow decimals, such as for blood
pressure values (where they are never used), so the precision would be 0.
of course, I meant to say C_QUANTITY_ITEM - that is where the precision
has to go…
I will add this to the Eiffel parser so that he can put it in the Ocean
tool; I will also update the C_QUANTITY definition to include it, so
that Rong can change the Java parser, which should be easier, and
Will do (right now in the middle of fixing invariants support in the parser)
Mattias can change the Archetype Editor. Lastly we will put in a CR for
it, so it is indicated properly in the specs. All in the right order,
just backwards
Once this change is done, we intend to put up a “clean” set of
archetypes onto the knowledge SVN repo, which should address the many
issues Mattias and others have found over the last few months. When we
have all done a bit of further checking and testing on this, we will tag
the release in SVN so it becomes a reference baseline.
That will be very nice to have indeed. Maybe we can collect a small set of archetypes created solely for testing parser purpose. I have some of them in the adl-parser package and will be happy to sync them with yous.
