Working with Pablo, we fount these classes C_CODED_TEXT, C_COUNT, C_QUANTITY, C_ORDINAL in the AOM Java implementation of the CONSTRAINT package.
These classes are not present in the spec, so some information about the would be useful.
These are the questions we have:
What are they needed for? shouldn’t their functionality be covered with assertions and AOM.Primitive package?
It seems that there is a mapping between these classes and the RM.DATA_TYPE package classes, if this is the case, should we expect to see more of these classes in the future?
We also need more clarifications in respect to the C_SINGLE_ATTRIBUTE and the C_MULTIPLE_ATTRIBUTE classes form the constraint model.
While trying to do a “paper based parser run” to see how an archetype maps to the AOM we got into strong differences regarding the use of C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE.
One position defends that C_MULTIPLE_ATTRIBUTE is to be used for ITEM_STRUCTURE attributes no matter what it may contain. The other says it is to be used for collections at the same data_type objects.
If you could please elaborate around this we’d be very thankful.
Working with Pablo, we fount these classes C_CODED_TEXT, C_COUNT, C_QUANTITY, C_ORDINAL in the AOM Java implementation of the CONSTRAINT package.
These classes are implemented according to some old specifications. They don't exist anymore in the RM. Some of them have been moved into openEHR Archetype Profile specification, which has just been implemented in the Java kernel.
These classes are not present in the spec, so some information about the would be useful.
These are the questions we have:
- What are they needed for? shouldn't their functionality be covered with assertions and AOM.Primitive package?
there were some other questions regarding AOM in my previous mail, you probably did not see.
Here they go again.
… in respect to the C_SINGLE_ATTRIBUTE and the C_MULTIPLE_ATTRIBUTE classes form the constraint model.
While trying to do a “paper based parser run” to see how an archetype is loaded into the AOM we got into strong differences regarding the use of C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE.
One position defends that C_MULTIPLE_ATTRIBUTE is to be used for ITEM_STRUCTURE attributes no matter what it may contain. The other says it is to be used for collections of the same data_type objects.
If you could please elaborate around this we’d be very thankful.
hi,
we put the am.openehr_profile package in our program but we cant compile the CDvState class because it must implement the inherited method of CDomainType abstract class validValue ( ... ) which is in the spec.
hi,
we put the am.openehr_profile package in our program but we cant compile the CDvState class because it must implement the inherited method of CDomainType abstract class validValue ( ... ) which is in the spec.
- It seems that there is a mapping between these classes and the RM.DATA_TYPE package classes, if this is the case, should we expect to see more of these classes in the future?
generally we hope to limit these, they will most likely occur only at the level of the openEHR data types, i.e. things like C_QUANTITY etc. We don't have further plans to add more at this stage.
We also need more clarifications in respect to the C_SINGLE_ATTRIBUTE and the C_MULTIPLE_ATTRIBUTE classes form the constraint model.
While trying to do a "paper based parser run" to see how an archetype maps to the AOM we got into strong differences regarding the use of C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE.
One position defends that C_MULTIPLE_ATTRIBUTE is to be used for ITEM_STRUCTURE attributes no matter what it may contain. The other says it is to be used for collections at the same data_type objects.
If you could please elaborate around this we'd be very thankful.
These types are actually very simple - they just constrain the two kinds of attributes you get in object models:
- single: attributes like Person.name: String
- multiple attributes like Person.names: List<String>, History.events: List<Event>
C_MULTIPLE_ATTRIBUTE will occur in an archetype whenever attributes of the second kind are being constrained from the object model.
The problem is that there is a method CDomainType.validValue() in the spec
that is not in your implementation. CDvState doesnt compile because i'm following
the spec (version 1 rev 2.0.1) of the AOM that has the validValue() method, if it's removed
the compilation goes fine, my questions are: why is validValue() defined in CDomainType?
what kind of tasks need to call validValue() of a CDomainType() concrete class (like CDvState)?
Hi,
I found a class constraint_model.LeafConstraint in the java implementation which is not in the spec (aom 1 rev 2.0.1)
what is wrong the implementation or the missing class in the spec?
Hi,
I found a class constraint_model.LeafConstraint in the java implementation which is not in the spec (aom 1 rev 2.0.1)
what is wrong the implementation or the missing class in the spec?
thanks
Pablo Pazos
This is an abstract class extracted from CDomainType and CPrimitive because these two shared 4 identical methods which are used to describe a leave node constraint either it's a primitive type or domain type. In fact, I would like to propose it to be included in the specification.
The problem is that there is a method CDomainType.validValue() in the spec
that is not in your implementation. CDvState doesnt compile because i'm following
the spec (version 1 rev 2.0.1) of the AOM that has the validValue() method, if it's removed
I guess you try to use part of the Java kernel code with your own AOM implementation. It won't be necessary as soon as the kernel is updated.
the compilation goes fine, my questions are: why is validValue() defined in CDomainType?
what kind of tasks need to call validValue() of a CDomainType() concrete class (like CDvState)?
CDvState has a list of states which can be used to check if any given state is allowed.
The problem is that there is a method CDomainType.validValue() in the
spec
that is not in your implementation. CDvState doesnt compile because i'm
following
the spec (version 1 rev 2.0.1) of the AOM that has the validValue()
method, if it's removed
I guess you try to use part of the Java kernel code with your own AOM
implementation. It won't be necessary as soon as the kernel is updated.
But the problem is that there is a validValue() method in the spec that is
not in the implementation.
To: <openehr-implementers@openehr.org>
Sent: Friday, July 14, 2006 6:56 PM
Subject: Re: C_CODED_TEXT, C_COUNT, C_QUANTITY, C_ORDINAL?
Pablo Pazos, simplewebportal.net wrote:
The problem is that there is a method CDomainType.validValue() in the
spec
that is not in your implementation. CDvState doesnt compile because i'm
following
the spec (version 1 rev 2.0.1) of the AOM that has the validValue()
method, if it's removed
I guess you try to use part of the Java kernel code with your own AOM
implementation. It won't be necessary as soon as the kernel is updated.
But the problem is that there is a validValue() method in the spec that is
not in the implementation.