I agree that in many use-cases it is better to have a separate template
intended for GUI/application hints overlayed on a "normal" data content
definition template. (Quick experimentation may be an exception.)

That is why I added "layers of templates" in my previous comment - sorry
for not explaining in detail. So a GUI-hint-annotated template based on
another "normal" content aggregation/constraint-focused template would be a
way to do it. I guess the effect in a resulting operational template (OPT)
is essentially the same no matter how many layers of templates you choose
to work with, right? So a form/GUI-renderer based on OPTs does not care how
you layer the design, but your maintenance headaches might be affected if
not separating things at design time.

I agree with Diego and Bert and suggest starting experimenting in the AM
end (for example using annotations with GUI-hints in templates) and see how
far that takes us, before possibly considering extending the RM (or
whatever *M).

Annotations do not require any changes to AM or RM, the mechanism is
already defined in the specifications. Conventions regarding patterns or
prefixes in annotation keys and/or annotation values will likely give
enough to start with.

A (not so very thought through yet) possible example of annotation use for
application building is available in picture 40 (and supported by picture
36 in


mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees <bert.verh...@rosa.nl>:

> On 18-02-18 23:09, GF wrote:
> > Is it an idea to annotate nodes with instructions for display.
> Personally I think having special templates/archetypes for display is
> better. Templates are create per purpose, and mixing purposes in a
> single template does  seem good idea to me
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
openEHR-technical mailing list

Reply via email to