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