Tim Cook wrote:
> On Wed, 2008-05-07 at 22:03 +0100, Thomas Beale wrote:
>
>>> Okay, so now my understanding is that; the attribute contains the
>>> parent archetype of this archetype? Not the current ("owner of this
>>> ontology") archetype (which is circular). That kind of clears that up.
>>>
>>>
>> no - it is the latter - the owner archetype. 'parent' was a poor choice
>> of name....
>>
>
> Okay. So we now have a circular reference issue. Again, I do not
> understand the value of this in any implementation.
>
> First of all; an ontology instance cannot (should not) exist outside of
> an archetype instance. Therefore it is obvious which archetype it
> belongs with.
>
> Secondly, on the issue of persistence in your reply to Rong. It doesn't
> matter if the attribute is persistent or not, it'll still be a circular
> reference in memory.
>
sure, but that doesn't matter. Works fine in the current
implementations. It's not really that important - if it causes problems
in an implementation, I would leave it out....I would have to go back to
the model to have a good look at why it is there in fact...
>
> Okay, I have to object to the differential approach.
>
> First I like the axiom, "just because we can does not mean we should".
> So, what is the technical/operational value to the differential
> approach? I know that Ocean has a lot of implementation experience that
> most of us do not yet have. Maybe there are good reasons?
>
sure - it is just like OO code for subclasses - you don't include copies
of the methods and attributes already present in the parent, you only
include those being overridden or added. Doing otherwise creates a
maintenance problem, since child class B, containing copies of class A's
unchanged methods X and Y is out of date as soon as class A is modified
to change or remove X or Y.
>
> Secondly, a fundamental concept of clinical archetypes is that they are
> a complete representation of a clinical concept expressed as an object
> model. An ADL file is supposed to be the fully semantic serialization
> of that archetype.
>
it still will be, it is just that the .adl files of the future will be
generated objects from the .adls files.
> Third, there is already push back on using ADL (hence all the XML
> discussions) by developers. Making what I consider a pretty drastic
> change in just what an ADL file is, this early in the implementation
> game, will only add to the confusion and further hurt acceptance that
> ADL is a good thing. I think that the one ADL file per archetype object
> is simpler to implement and maintain in an application. This is
> especially true where you have special purpose apps with only a few
> archetypes required.
>
there is still only one .adl file per archetype; it is just that is a
.adls fle as well now. I don't see any way around this. Also, the XML
for all this is generated automatically by the tools, so I don't see any
problem with XML.
> Finally, maintainability should not be an issue. The versioning process
> and placing the version number as part of the ID takes care of
> maintainability. For example:
>
> If I create at1 and then a specialization called at1x. Then someone
> creates a new version of at1 called at2. at1x is still a specialization
> of at1. at1x has no association with at2 other than both having risen
> from at1.
>
yes, but that's not the problem. The problem is if at1 itself is changed
- all its child specialisations may be outdated.
- thomas
