I am happy to read this opinion and I do fully agree on this. This makes it possible to use templates for any purpose desired. I already had thought of some template enrichments which work with CSS.
Now that there is template parsing software in Java, I am thinking of further developing/implementing it. Next step will be a repository with archetyped controls, like a GUI building developing tool, it even could be an eclipse or visual studio plugin, or write an own development environment, and so enabling a drag and drop development tool for people close to the medical professions. The templates could be the base of a Windows-executable GUI, or Mono, or Java, or PHP, or Javascript/HTML (AJAX), a client application that changes, depending on the template loaded. It is all a matter of just work to do. Maybe I am jumping too many steps in one time, but something like that is my bit further goal. Bert Op 1-12-2010 19:30, Tim Cook schreef: > IMO templates are an implementation specific issue and should not be > part of the reference model. Archetypes that express a concept as a > maximal dataset are sufficient for interoperability. Local templates > are just that; local templates. Certain implementations may share > templates between applications but I dare say any attempt to 'standard' > across implementations is wheel-spinning. > > If people are expecting magic pop-out-of-the-box applications then they > are taking something mind-altering. :-) > > My 2 cents, > > Tim > > > On Wed, 2010-12-01 at 18:08 +0000, Ian McNicoll wrote: >> Hi Olof, >> >> I agree this is a significant missing piece of the reference model and >> I am not sure how close the overall ADL 1.5 spec is to being finalised >> but the operational template definition appears to be very stable and >> can act as a reference point for coalescing various local template >> implementations and tooling developments. Thomas has already added >> ADL1.5 support to the ADL Workbench and the specs seem to me to be >> stable enough to start implementation in Java. I think the issue is >> lack of time/resource, rather than immaturity of the specifications - >> it would be interesting to get Rong's take on this but I suspect he >> implemented a great deal of the current Java model prior to a stable >> RM being specified. Indeed I would only expect a truly stable >> specification to emerge after some implementation experience. >> >> IMO most real-world implementations which strive for interoperability >> and maximally-defined archetypes will almost all work via operational >> templates for validation, code -generation GUI integration. I don't >> think we have to wait for the full ratification of ADL1.5 and template >> spec to start doing interesting things in downstream support, assuming >> that the opt definition is pretty stable. The issues of extra >> directives and extensions are important at this stage as arguably some >> should be supported in the operational template, as I discussed above. >> >> Ian >> >> Dr Ian McNicoll >> office / fax +44(0)1536 414994 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian.mcnicoll at oceaninformatics.com >> >> >> Clinical analyst, Ocean Informatics >> openEHR Clinical Knowledge Editor www.openehr.org/knowledge >> Honorary Senior Research Associate, CHIME, UCL >> BCS Primary Health Care SG Group www.phcsg.org >> >> >> >> >> On 1 December 2010 17:19, Olof Torgersson<olof.torgersson at chalmers.se> >> wrote: >>> Hi, >>> When it comes to templates, what I would like to see is that they are >>> finalized and become a part of standard implementations such as the Java >>> reference model. This is something I've been waiting for since I first >>> viewed this list a couple of years ago. >>> Then, as a next step one could start discussing various extensions, >>> directives etc. >>> Regards >>> Olof Torgersson >>> 1 dec 2010 kl. 13.24 skrev Erik Sundvall: >>> >>> Hi All! >>> There was a related discussion regarding GUI-directives/hints around june >>> 2008, that I tried to summarize in the post >>> http://www.openehr.org/mailarchives/openehr-technical/msg03755.html >>> As you will see that post is somewhere in the middle of the thread, so you >>> can find other interesting things before and after that post in the >>> archives. >>> Now, if I understand things correctly there is now implementatin experience >>> from at least three projects regarding GUI-hints/directives (please add more >>> if you know any): >>> - Zilics >>> (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) >>> - GastrOs Endoscopy Application by Koray Atalag et.al. >>> - Open EHR-Gen by Pablo Pazos et.al. >>> What about trying to formalize some recommendations based on this >>> experience, and perhaps even write a piece of specification draft that fits >>> the new ADL 1.5 thinking regarding templates and archetypes. >>> Would it be possible for anybody from any of the three projects to start a >>> wiki page to describe your GUI-directives/hints and then we could compare >>> them all and get a discussion going on the list possibly followed by some >>> community driven development of a draft specification to try out. >>> Best regards, >>> Erik Sundvall >>> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 >>> <ATT00001..txt> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > Geen virus gevonden in dit bericht. > Gecontroleerd door AVG - www.avg.com <http://www.avg.com> > Versie: 10.0.1170 / Virusdatabase: 426/3291 - datum van uitgifte: 12/01/10 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/56ac0a4e/attachment.html>
