# DV_STATE

**Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154)
**Created:** 2006-10-13 11:06 UTC
**Views:** 10
**Replies:** 5
**URL:** https://discourse.openehr.org/t/dv-state/12512

---

## Post #1 by @Mattias_Forss1

Hi,

I'm wondering where the DV\_STATE is used in archetypes? I have only
seen the ISM\_TRANSISTION state in the ACTION archetypes, but that is
probably something else\. I noticed there is a class C\_DV\_STATE in the
archetype profile that constrains allowed values of the attribute
'value' of the DV\_STATE, but I don't know what syntax a parser need to
find in order to create an instance of a C\_DV\_STATE\.

If the ISM\_TRANSITION is only supposed to correspond to an instance of
a C\_COMPLEX\_OBJECT and not a C\_DV\_STATE then I guess there's nothing
stopping me from implementing support for action archetypes in the
editor, but since I originally thought the ISM\_TRANSITION corresponded
to a C\_DV\_STATE I decided not to support action archetypes until the
Java ADL parser was fixed\.

Now, what are the minimum requirements on the reference implementation
before I can start working on adding support for action and
instruction archetypes? The Java reference implementation doesn't
fully support archetype slots, the assertion package is not
implemented and there is nothing in the parser that deals with
C\_DV\_STATE\. Can anyone point out the things that are needed before
action and instruction are fully supported by the parser and the
serializer?

Regards,

Mattias

---

## Post #2 by @thomas.beale

Mattias Forss wrote:
> Hi,
>
> I'm wondering where the DV\_STATE is used in archetypes? I have only
> seen the ISM\_TRANSISTION state in the ACTION archetypes, but that is
> probably something else\. I noticed there is a class C\_DV\_STATE in the
> archetype profile that constrains allowed values of the attribute
> 'value' of the DV\_STATE, but I don't know what syntax a parser need to
> find in order to create an instance of a C\_DV\_STATE\.
>
> If the ISM\_TRANSITION is only supposed to correspond to an instance of
> a C\_COMPLEX\_OBJECT and not a C\_DV\_STATE then I guess there's nothing
> stopping me from implementing support for action archetypes in the
> editor, but since I originally thought the ISM\_TRANSITION corresponded
> to a C\_DV\_STATE I decided not to support action archetypes until the
> Java ADL parser was fixed\.
>

it may be that ISM\_TRANSITION should be changed to a DV\_STATE from a
DV\_CODED\_TEXT\. This would be a small change\. I will raise this as an issue\.
> Now, what are the minimum requirements on the reference implementation
> before I can start working on adding support for action and
> instruction archetypes? The Java reference implementation doesn't
> fully support archetype slots, the assertion package is not
> implemented and there is nothing in the parser that deals with
> C\_DV\_STATE\. Can anyone point out the things that are needed before
> action and instruction are fully supported by the parser and the
> serializer?
>  

I would not worry about assertions yet \- there is a certain level of
complexity, and they are in the category of the "80% of effort that
supports 20% of use cases"\. Slots do need to be implemented, and I would
encourage that to happen earlier rather than later \(within the
contraints of people's time;\-\)\. I would also assume the current model of
ISM\_TRANSITION , as shown in
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html
\- i\.e\. not using DV\_STATE\. If we decided to include DV\_STATE, then we
should treat this as a CR when it comes, and it will incur a very small
change in the RM, and I think small changes in the parser\.

So \- in summary, I would assume the RM as documented on the website in
the Release 1\.0\.1 candidate \(plus recent changes discussed among us, but
not yet published online\)\.

Let me know if this helps \- or what further concerns need to be
addressed so you can continue coding right now\.

\- thomas

---

## Post #3 by @Mattias_Forss1

> > Now, what are the minimum requirements on the reference implementation
> > before I can start working on adding support for action and
> > instruction archetypes? The Java reference implementation doesn't
> > fully support archetype slots, the assertion package is not
> > implemented and there is nothing in the parser that deals with
> > C\_DV\_STATE\. Can anyone point out the things that are needed before
> > action and instruction are fully supported by the parser and the
> > serializer?
> >
> I would not worry about assertions yet \- there is a certain level of
> complexity, and they are in the category of the "80% of effort that
> supports 20% of use cases"\. Slots do need to be implemented, and I would
> encourage that to happen earlier rather than later \(within the
> contraints of people's time;\-\)\. I would also assume the current model of
> ISM\_TRANSITION , as shown in

Thanks for your answer Thomas\.

So is it okay to change the implementation of the ArchetypeSlot class
in the Java reference implementation to hold two sets of CString as
includes and excludes instead of sets of Assertion?

Should it be possible to create different types of ArchetypeSlot
instances, e\.g\. with domain concept matching, rm originator matching,
concept name or specialisation name matching or should that be
specified in the CString \(later in the Assertion\)? I don't know what's
been specified concerning that part of the ARCHETYPE\_SLOT\.
> http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html
> \- i\.e\. not using DV\_STATE\. If we decided to include DV\_STATE, then we
> should treat this as a CR when it comes, and it will incur a very small
> change in the RM, and I think small changes in the parser\.

All right, sounds fine, but should the parser treat the ISM\_TRANSITION
classes of the ism\_transition attribute of ACTION as C\_COMPLEX\_OBJECT
or something else?

Two more questions related to this:

1\) Why isn't the transition attribute of ISM\_TRANSITION found in
archetypes? I think there are some settings for it in the Ocean
editor, but the ADL never changes when you modify these\.\.\.

2\) The attribute 'instruction\_details' of the ACTION class is never
found in archetypes\. Is this because the details of the instruction
that caused the action are added when the action data is created
\(which always is created with the instruction that caused the action\)?

> So \- in summary, I would assume the RM as documented on the website in
> the Release 1\.0\.1 candidate \(plus recent changes discussed among us, but
> not yet published online\)\.

Yes, I try to assume this, but when I found the C\_DV\_STATE in the AOM
constrained a thing in the RM which didn't seem to be used, I was
unsure what I can implement before action archetypes can be fully
supported\. Is the C\_COMPLEX\_OBJECT form of the ISM\_TRANSITION that the
parser currently instantiates the definite representation, or will it
change to C\_DV\_STATE?

Regards

Mattias

---

## Post #4 by @thomas.beale

Mattias Forss wrote:
>  
> Thanks for your answer Thomas\.
>
> So is it okay to change the implementation of the ArchetypeSlot class
> in the Java reference implementation to hold two sets of CString as
> includes and excludes instead of sets of Assertion?
>  

yes, that would be a reasonable compromise at the moment \- there are no
archetypes so far for which the slot specification is not just a regex
on the ids\. So that is a safe thing to do\.
> Should it be possible to create different types of ArchetypeSlot
> instances, e\.g\. with domain concept matching, rm originator matching,
> concept name or specialisation name matching or should that be
> specified in the CString \(later in the Assertion\)? I don't know what's
> been specified concerning that part of the ARCHETYPE\_SLOT\.
>  

we don't even bother with that in the Ocean Editor, but doing that would
probably not be hard to do \- I would think of 2 drop\-downs, or other
choice controls, for the 1\) domain concept and 2\) the model \- class
combination \(i\.e\. "EHR\-Observation"\)\. You could hardwire this at the
moment \- I know it doesn't feel good to do that in software, but in
fact, the combinations of model and class won't change in the future, so
that is one thing that won't break anytime soon\.
>> http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html
>> \- i\.e\. not using DV\_STATE\. If we decided to include DV\_STATE, then we
>> should treat this as a CR when it comes, and it will incur a very small
>> change in the RM, and I think small changes in the parser\.
>>    
> All right, sounds fine, but should the parser treat the ISM\_TRANSITION
> classes of the ism\_transition attribute of ACTION as C\_COMPLEX\_OBJECT
> or something else?
>  

C\_COMPLEX\_OBJECT
> Two more questions related to this:
>
> 1\) Why isn't the transition attribute of ISM\_TRANSITION found in
> archetypes? I think there are some settings for it in the Ocean
> editor, but the ADL never changes when you modify these\.\.\.
>  

I have to check up on this with the archetype group, but I would not be
surprised not to see this specified in the archetype\. Remember, the
archetype editor only has to allow archetyping for "what makes sense to
archetype", which is not everything in a reference model, only things
that can be configured at design time\. Some attributes will only be set
at runtime, and ISM\_TRANSITION\.transition is probably one of these\.
Since the current\_state attribute is archetyped, it doesn't matter what
transition led to that state \- that is most likely the design thinking\.
> 2\) The attribute 'instruction\_details' of the ACTION class is never
> found in archetypes\. Is this because the details of the instruction
> that caused the action are added when the action data is created
> \(which always is created with the instruction that caused the action\)?
>  

this is another thing that makes no sense to archetype\. This object is
used to record: what Instruction and Activity does this Action
correspond to? So it is only ever set at runtime\.
>  
>> So \- in summary, I would assume the RM as documented on the website in
>> the Release 1\.0\.1 candidate \(plus recent changes discussed among us, but
>> not yet published online\)\.
>>    
> Yes, I try to assume this, but when I found the C\_DV\_STATE in the AOM
> constrained a thing in the RM which didn't seem to be used, I was
>  

it isn't yet;\-\)
> unsure what I can implement before action archetypes can be fully
> supported\. Is the C\_COMPLEX\_OBJECT form of the ISM\_TRANSITION that the
> parser currently instantiates the definite representation, or will it
> change to C\_DV\_STATE?
>  

no, it will always be C\_COMPLEX\_OBJECT\. The only questoin is whether
ISM\_TRANSITION\.current\_state changes from C\_DV\_CODED\_TEXT  to C\_DV\_STATE
\(which we will solve later\)\.

\-    thomas

---

## Post #5 by @Mattias_Forss1

> Mattias Forss wrote:
> >
> >>
> >
> > Thanks for your answer Thomas\.
> >
> > So is it okay to change the implementation of the ArchetypeSlot class
> > in the Java reference implementation to hold two sets of CString as
> > includes and excludes instead of sets of Assertion?
> >
> yes, that would be a reasonable compromise at the moment \- there are no
> archetypes so far for which the slot specification is not just a regex
> on the ids\. So that is a safe thing to do\.

Thanks\.\.\. maybe I can do some coding in the reference implementation
in order to support archetype slots in the editor\. If you are reading
this Rong, what are your opinions on this?

> > Should it be possible to create different types of ArchetypeSlot
> > instances, e\.g\. with domain concept matching, rm originator matching,
> > concept name or specialisation name matching or should that be
> > specified in the CString \(later in the Assertion\)? I don't know what's
> > been specified concerning that part of the ARCHETYPE\_SLOT\.
> >
> we don't even bother with that in the Ocean Editor, but doing that would
> probably not be hard to do \- I would think of 2 drop\-downs, or other
> choice controls, for the 1\) domain concept and 2\) the model \- class
> combination \(i\.e\. "EHR\-Observation"\)\. You could hardwire this at the
> moment \- I know it doesn't feel good to do that in software, but in
> fact, the combinations of model and class won't change in the future, so
> that is one thing that won't break anytime soon\.

I actually think it's not that bad to hardwire it in this case,
because the editor has only a fixed set of rm originator, model and
class combinations that it supports\.

On the other hand, we could have two text fields where the users are
allowed to input any model and class combinations\.\.\.
> >> http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html
> >> \- i\.e\. not using DV\_STATE\. If we decided to include DV\_STATE, then we
> >> should treat this as a CR when it comes, and it will incur a very small
> >> change in the RM, and I think small changes in the parser\.
> >>
> >
> > All right, sounds fine, but should the parser treat the ISM\_TRANSITION
> > classes of the ism\_transition attribute of ACTION as C\_COMPLEX\_OBJECT
> > or something else?
> >
> C\_COMPLEX\_OBJECT

Okay, great\! Now I know I can start working on supporting the action
and instruction archetypes\. I actually could have done it long ago,
but other usability and bug fixes has been made before I knew this\.
The original issue that blocked the progress on supporting action and
instruction archetypes in the editor was that I thought lots of things
were needed in the reference implementation before it could parse and
output these archetypes\.

Rong actually pointed out that he had to do major changes in the AOM
\(the assertion package etc\.\) before action and instruction could be
supported, so I went on working with other things\. Now if we could
leave the assertions for archetype slots I guess I can start working
on the stuff that have been left behind for far too long and maybe we
can soon release a much more complete editor than before\.

> > Two more questions related to this:
> >
> > 1\) Why isn't the transition attribute of ISM\_TRANSITION found in
> > archetypes? I think there are some settings for it in the Ocean
> > editor, but the ADL never changes when you modify these\.\.\.
> >
> I have to check up on this with the archetype group, but I would not be
> surprised not to see this specified in the archetype\. Remember, the
> archetype editor only has to allow archetyping for "what makes sense to
> archetype", which is not everything in a reference model, only things
> that can be configured at design time\. Some attributes will only be set
> at runtime, and ISM\_TRANSITION\.transition is probably one of these\.
> Since the current\_state attribute is archetyped, it doesn't matter what
> transition led to that state \- that is most likely the design thinking\.

Yes I understand that, I just thought it was supposed to be in
archetypes since the editor had a setting for transition\.

> > 2\) The attribute 'instruction\_details' of the ACTION class is never
> > found in archetypes\. Is this because the details of the instruction
> > that caused the action are added when the action data is created
> > \(which always is created with the instruction that caused the action\)?
> >
> this is another thing that makes no sense to archetype\. This object is
> used to record: what Instruction and Activity does this Action
> correspond to? So it is only ever set at runtime\.

That was a 'yes' answer to my question, so I assumed what you said\.\.\.

By the way, why doesn't the Ocean editor allow to set run\-time name
constraints for the Activity? An Instruction is supposed to have
several Activities, and therefore I think it would be logical that
they should be able to have different names at run\-time\. Also, the
Activity class inherits Locatable, so it's legal for it to have the
name attribute\.

> no, it will always be C\_COMPLEX\_OBJECT\. The only questoin is whether
> ISM\_TRANSITION\.current\_state changes from C\_DV\_CODED\_TEXT  to C\_DV\_STATE
> \(which we will solve later\)\.

Thanks a lot, your answer has helped me figuring out a lot of issues\.
I have tried to get a grip on these things several times, but maybe my
questions have been too unspecified to get a clear answer\. I guess my
perseverance has finally paid off ;\-\)

Regards,

Mattias

---

## Post #6 by @rong.chen

Mattias Forss wrote:
>  
>> Mattias Forss wrote:
>>    
>>> Thanks for your answer Thomas\.
>>>
>>> So is it okay to change the implementation of the ArchetypeSlot class
>>> in the Java reference implementation to hold two sets of CString as
>>> includes and excludes instead of sets of Assertion?
>>>
>>
>> yes, that would be a reasonable compromise at the moment \- there are no
>> archetypes so far for which the slot specification is not just a regex
>> on the ids\. So that is a safe thing to do\.
>>    
> Thanks\.\.\. maybe I can do some coding in the reference implementation
> in order to support archetype slots in the editor\. If you are reading
> this Rong, what are your opinions on this?
>  

Actually it's just fixed as the last commit to AOM on the sandbox
branch\. The parser still needs to be updated for this\.

/Rong

---


**Canonical:** https://discourse.openehr.org/t/dv-state/12512
**Original content:** https://discourse.openehr.org/t/dv-state/12512