The disadvantage remains:
The client software must represent, in one way or another, the archetype-based object in its internal structures.
So this means that a GUI programmer still needs to understand and reproduce the object, so still needs to know all about the archetype/object. The programmer needs to understand the reference model.
well if they have produced a Template Data Schema (TDS) or Template Data Object (TDO) then.... not really. And some companies are producing complete UI from the template.
You are right, Thomas, it is promising.
Now I need to explain why I decided to do it another way.
My path/value-work was started about three/five years ago, and the GUI-developers were/are happy with it.
So, first what was the emphasis in template-discussions a few years ago:
In that time, templating was often talked about in the context of combining archetypes.
This fitted in the idea of having several standard archetypes available in CKM and pick whatever one needed from them.
You can recognize this idea also in the fact, that there wasn't thought of archetypeId-structure in context of collisions which were very probable to happen in a world were people wrote archetypes themselves.
I remember how hard it was to explain my point on this on this list, a year ago. But now it is accepted.
So. in that time, I needed to leave the OpenEHR mainstream thinking about that.
In my experience archetypes to use were often inspired from CKM, good examples, that how it was understood.
As I said, the idea was using lego-stones and connect them with templates.
But this was hard to sell as a specific advantage of OpenEHR. Because most reference models offer this LEGO-concept.
Even well-thought-of legacy does. Like LDAP, in LDAP you find this LEGO-idea.
In addition, in the perception of many people, archetypes needed to be complete datasets which served a specific data-requirement/context completely.
You can also see this in the meta-information in archetypes.
So, what was then the use of having a concept of combining parts of them?
I remember that it was an example written by you why HL7 was no good. (my interpretation/remembrance of your writing)
The HL7 community had an ADDR datatype. And if one thing was bad, it was creating an ADDR-datatype, because there was no way, you could be sure every possible address convention would fit in it.
There are so many address-conventions, or name conventions that it is hard to write LEGO-stones which define them suitable for all cases.
I often, gratefully, used this example, but after that saying that using parts of the CKM-standard-defined ADDR-archetype in templates, seemed conflicting.
What would be the use of templates then?
So I explained that OpenEHR always gives the possibility to write your own Address-archetype, and I did not mention the archetypeID collisions which would became possible then.
I made my money with OpenEHR, but the customers thinking was HL7, that was what they learned at school.
So if they wanted OpenEHR, they wanted it to fit in their thinking, but leaving out the disadvantages.
HL7 was so rich, it had the extensive CDA, but also the summaries like VMR or other summary-definitions, software-eco-system, and tons of message-definitions.
I also had that joke, for those who do not know it:
B: I create an HL7 standard which makes all others obsolete
C: I create an HL7 stand......
How many hours I talked in explaining why OpenEHR is better then CDA or other HL7-definitions.
People had difficulties to believe that, because CDA was widely accepted on the market.
Additionally, It often turned out that they often did not know HL7 and they did not know OpenEHR, but still, that were the people to decide. That were the people to convince.
What they did was talking to more people to question, and making lists of features.
Most important arguments I used were flexibility and ownership. Just call, and we write an archetype.
It gave the idea of having control and specific needs being served
So, templates as a way of combining archetypes did not fit very well in this philosophy.
That was the level of thinking at decision-makers and technical state of art, only a few years ago.
Now you describe as main advantages of templates, that it is a way of communicating with the OpenEHR-kernel without needing much understanding of what OpenEHR is in detail.
You are right in this, I never thought about it.
What I created is a kind of templates, but then not externally defined.
Because some archetypes behave like a template, like Compositions, it are the content-items which decide the kind of composition. The composition itself is just a slot-connector, with some additional information.
So, that is how it works, for me
Think of having every leaf-node in an archetype having a unique-path inside that archetype, and then there is the leaf-value. There maybe slotted archetypes in the path.
But I think that what you describe now as template-use, a communication-protocol, will be the mainstream. So I will adapt it to to my kernel. Thanks for this advise.
I don't think it is hard to do, because, as I said, a kind of templating was already in my concept. The TDO-idea is very good, that is very convincing.
I am sure I can find matured worked out definitions or examples of this.
Only one remark on your writing rests to explain
But what the GUI-programmer really would need to know is how to communicate, for example a blood-pressure.
There was no need for the GUI-programmer to understand the difference between DvCodedText, CodePhrase, DvQuantity, ItemList, ItemTree, Composition, Section, ContentItem.
The GUI-programmer just needed a location to write the value 180, while sitting.
(I know, high bloodpressure, the patient is at medical care for reason 
for that you should just use TDS or TDO - that's what they are for. You could design a different TDS or TDO to flatten even the data types to just numbers I guess, but I think programmers who can't be bothered to deal with even that are being a bit lazy...
I shouldn't call them lazy, mostly people are under pressure, and they want a working solution.
I am sure you agree with this when you think again.
Projects have time-schedules, and it is not possible to say something like: we are defining a solution for next year. We postpone the project, and then the money stops flowing, but we have our savings and wait.
I know other companies, well known companies, which had similar struggle too, a few years ago.
regards
Bert
