>>This is in fact an interesting thought. It could mean the end of archetypes. They only need to exist virtual, as inner-parts of templates. >>The system does not need to know them, as long as the template designer says they exist, somewhere, and on other existence, they are the same. Exactly.
However, you are also correct that you run the risk of having different templates using different revisions and even versions of archetypes. At the moment that is mostly managed by clearly separating the opt creation process from day-to-day archetype and templating design. This is not really any different from managing the archetypes as individual entities. There does have to be careful control of the versioning. The new numbering rules should make it easier for this to be well-managed, and to warn of potential conflicts. The templates will equally have to have careful versioning rules, though I would expect this just to bubble-up from what is happening to child archetypes i.e if any of the children has a major revision, the template must have a major revision. This is not something that CKM does right now but it should be possible. You are correct, you can get to the same place by managing all of the component archetypes as a set, but since many will be diffs, you are going to have to compile them to a flattened form at some point - .opt is just an XML representation of that flattened form. It is really the choice between building a piece of OS software from source or downloading the installer :-) Archetype and template consumers may not need the source files but authors like me definitely do. When you agree to give up managing your source code as files , I will do the same ;-) Seriously there are huge advantages in keeping things as independent files for authors but I agree no need for these to be managed onside operational repositories. The idea of ADL 2.0 is to replace .oet with pure ADL - there is flattened for of templated ADL and ongoing work to be able to produce .opt from that. There is some thought about changing the .opt form to be less wordy, and your input would be very helpful if you wanted to get involved. Ian On 22 October 2014 14:07, Bert Verhees <bert.verhees at rosa.nl> wrote: > On 22-10-14 13:10, Ian McNicoll wrote: > >> In practice this means that if I create a .opt , I can upload this to one >> of these systems and it will be ready to use, with no need to upload or >> manage the individual archetypes. >> > > This is in fact an interesting thought. It could mean the end of > archetypes. They only need to exist virtual, as inner-parts of templates. > The system does not need to know them, as long as the template designer > says they exist, somewhere, and on other existence, they are the same. > > It will be the templates which take over control, the decide what is > right, they decide the ADL-paths, they decide the structure, and there is > no way to validate if they are right. > > And the naming of archetypes in file-names. > As archetypes do not need to be managed anymore, then they don't need to > be in files. We had that discussion just a few weeks ago. > > Virtual Archetypes! > > Suppose you are wrong, archetypes are still needed on a system, suppose > you fantasized this purpose, then the existence of the OPT-templates would > be useless. > Why need OPT-templates if all the information already is on a system. > > I therefor think you are right, I think this is really the purpose of the > OPT-templates. I cannot think of another purpose. > > Quite some conclusion is that. > > > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141022/bbbc5dc1/attachment.html>
