Hi! A very interesting discussion, thanks to everybody here! Great with all references too!
On Wed, Dec 8, 2010 at 16:26, pablo pazos <pazospablo at hotmail.com> wrote: > Maybe if we change the terminology to GUI Templates and openEHR Templates, > we will not have these problems. > Or perhaps "GUI focused templates" and "Structurally focused templates" (since both will be openEHR based). Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a "structural" template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] ...that is then annotated with GUI-hints by... a set of "GUI templates" with each template fitting a different recurring use case ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools On Wed, Dec 8, 2010 at 15:55, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > you have two choices: > > - A) mix it in with the languages & architectural layers you already > have > - B) create a dedicated layer or component type, and possibly dedicated > formalism if needed > > I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. On Mon, Dec 6, 2010 at 22:06, Koray Atalag <k.atalag at auckland.ac.nz> wrote: > I think having these discussions is a great start. But it'd be great if > someone from the core group 'owns' this thread and puts some pressure on us. > Koray, what makes you exclude yourself from the "core group"? Shouldn't openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official "core" that is busy prioritizing other important explorations. Whatever that "core" is I believe it will be actively involved in, and appreciate, the discussions. You already "own" the problem together with others owning the same problem. I think openEHR should be a platform to facilitate collective ownership of problem solving processes and solutions. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101210/9d6bfbd1/attachment.html>
