On 30/12/2010 01:07, Koray Atalag wrote: > > Hi Tom, I wasn't aware of that -- thanks. > > My initial thinking was to introduce GUI directives at the template > level, persisting with it and passing onto OPT. I was reluctant to > introduce "yet-another-layer" due to mainly maintainability concerns > but it has been suggested that tooling should be able to handle that > and hide complexity from users. That makes sense now (still with > caution though ;). > > Until this is defined may I suggest reserving a keyword (i.e. "GUI > directive") for use in annotations section. Or perhaps this can just > be a design-pattern as you originally suggested which we all stick to > so that our existing implementations will have some level of > interoperability? >
it is certainly possible at a local level for anyone to do this. However, I doubt if the annotations structure will be expressive enough. At the moment, it is defined as a hash of Strings, where the keys are Strings, or (as per my proposal), some kind of code, e.g. an-codes. > I'd be very keen to contribute to the definition of a new GUI > artefact; perhaps it'd be great if you could provide a basis for (i.e. > such as an initial set of requirements and design principles inline > with the current specs and where openEHR wants to go) and facilitate > the discussions. Referring back to Eric's and Thilo's messages perhaps > we can work as a working group or a SIG and come up with useful proposals. > I would suggest that people who have experience in this area (including you ;-) put together some example statements in any kind of syntax you like - just try to get the semantics sorted out first, we can crystallise it into some part of a template later on. > Another point was whether there were any directives to do with the > structure and semantics (hence domain knowledge) within the list we > came up with. The "CoreConcept" directive which basically depicts > whether a CLUSTER and its downstream items can be recorded as absent, > indeterminate etc. Ian also pointed out a more comprehensive set of > requirements around the same issue referring the need to the need to > represent detailed clinical findings without the need to insert > unnecessary CLUSTERS for single ELEMENTS which may hold further > ELEMENTS in future when there is a need to extend. I am not aware of > the result of this discussion (if any) either. > I still think this requirement is best solved by a design pattern that is defined and that tools can trust - one that fits with the current reference model.* * - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110102/9ca20164/attachment.html>
