Hi! On Wed, Dec 15, 2010 at 00:30, Thomas Beale <thomas.beale at oceaninformatics.com>?wrote: > On 10/12/2010 08:49, Erik Sundvall wrote: >> If the already present annotation mechanism in templates is powerful enough >> (Do you think it is, Koray,?Pablo and others?) > > to be clear, do you mean the annotations documented in the ADL 1.5 draft > document? I.e. the new annotations section?
Yes, I was then thinking of section 9.8 in http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf When looking closer at this for GUI hint experimentation, perhaps we could instead use a combination of annotations and the assertion/rule mechanisms in ADL/AOM? The already present logic in the assertions mechanism is probably enough to define e.g. Boolean trigger variables. Annotations could then be used to let GUIs know what to do/show/hide based on those triggers. Discussion examples follow (with the risk of ADL errors that Tom's brain-integrated ADL parser :-) will catch and he then can correct) In section?6.5.4 of http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf a way of defining variables is specified. Perhaps a (preferably Boolean) variable could be defined as an archetype rule like... $smoker:BOOLEAN ::= /data/items[at0003.7]/items[at0009.3]/value/defining_code matches local::at0013 ...and an annotation on a tree structure that should be shown in GUIs only when documenting smokers could be... annotations = < ["/data/items[at0003.7]/items[at0010]"] = < items = < ["GUI-show-if"] = <"$smoker"> -- Other annotation name examples: GUI-hide-if ... ["some other annotation"] = <"whatever"> ...or perhaps... annotations = < ["/data/items[at0003.7]/items[at0010]"] = < items = < ["GUI-trigger"] = <"$smoker"> ["GUI-action"] = <"show"> -- Other annotation value examples: hide, collapse, expand ["some other annotation"] = <"whatever"> I guess the mess starts if such annotations are to be overridden in yet a specialization generation of the GUI-annotated template/archetype. That would have to be analyzed further, but maybe some refined variant of the examples above could be a useful start in the mean time? Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 > 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 >Erik Sundvall wrote: > 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. Thomas Beale wrote: > I agree - we don't yet have a clear list of the GUi semantics that would need > to be in a UI template...
