Its been a while here...

Since my last post, I've survived a hard disk crash, travelled about 4000km of road and learnt some cool horse riding stuff... and met many many nice guys in the process...
ok... also did (try to?) write something for this year's Athens International System Dynamics Conference...

Emm... doesnt mean I havent been thinking of archetypes.
I must say that I am really excited about the open Xforms trend on the OpenMRS dev. And I am beginning to think that I should carry my 'kaya' (kaya is the Hausa word for load) from the InfoPath side of things to the open Xforms side of things.
And there is something cool on Mark Birbeck's blog. And I have copied some stuff from there (below).

Emmm...

"The subforms technique we used on the current project is to extend the XForms load action to include:
a target attribute to indicate where to place the sub-form;
an additional value in the show attribute of embed.
To show how it works, here is an example of how we place a sub-form into a case when the user toggles that case:



We use the term sub-form to describe the document that is loaded because it may have more than just controls; it may include its own models, submissions, bind statements, and so on.
Using XLinkThe extensions to load are of course non-standard, and this is still very experimental. But it is worth saying that there is logic behind the way we've done this.

For a start, XForms really should support a target attribute on the load action anyway, which would allow new documents to be loaded into frames or other locations.But also, the show attribute in XForms is actually modelled on the XLink show attribute, and the currently supported values--replace and new--come from that...as does embed. In other words, all we're suggesting here is that XForms supports a little bit more of XLink.As it happens, our first version of this functionality achieved it using raw XLink, but the problem is that XLink says nothing about when to load the sub-form. Once we started looking at attaching event listeners, we quickly came to the conclusion that load was much more appropriate, particularly because it already made use of XLink.

Conclusion
However we do this in the future, and whatever mark-up is used, XForms definitely provides the hooks for a flexible way to build complex forms on the fly. Defining the loading of sub-forms using declarative mark-up makes it intuitive for authors to use this feature, and makes the management of the components much easier."


How is this relevant?
I am thinking... archetypes, as in the OpenEHR specs, are not used directly to drive systems. They are used as 'subforms' or 'form parts' or 'formlets' which make up a template.
Of course there are cases where a form (or template) consists of just one archetype.

So, whats the advantage of deriving subforms from archetypes and not just creating from the scratch...
I just mentioned it, from the scratch. Implementers do not really want to do things from the scratch. They want to learn from others.

Another advantage is that if you can select the finite number of archetypes (of course its never finite cos medical requirements are inherently dynamic... but lets just use it for now, there is something called versioning)...you can have the finite number of concepts from the ontology section of the archetype...
So, how do you do that?
Not done that yet... but there's something called xpath that can point to those locations...