Hi All, This extension idea is used in XForms in a similar manner. In fact this extension mechanism is actually something that I played with 18 months ago to represent AOM constraints of data associated with each form control expressed in XForms. I shelved this approach due to the complexity of implement this approach. I would be interested in revisiting this again with the aid of the community.
However, Rong is proposing the opposite, having form extensions within the template. This could be viable. The other consideration I had when I objected internally to the Hide-on-form attribute provided by the Ocean Template Designer, was to have a separate section within the template for form definition details. This again is borrowed from XForms where it has the multiple sections including the Model (similar to template definition but in an instance form, although you can also reference an XML schema in XForms I believe), and View (form definition). Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Thilo Schuler > Sent: Friday, 27 June 2008 10:12 PM > To: For openEHR technical discussions > Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to form > demo (of sorts)) > > Very interesting - maybe we could have seperate namespaces for the > core tags and extensions. Could be a good compromise! While I see the > advantages of keeping GUI stuff out of the template, I also see that > this more and more complicated as we add additional abstraction > layers. > > On Fri, Jun 27, 2008 at 2:26 PM, Rong Chen <rong.acode at gmail.com> wrote: > > Hi all, > > > > My thoughts on this is so far our experience with templates are mostly > > related to screen forms and GUI widgets. It's probably easiest to relate to > > screens when engage clinicians for templates reviewing, hence the need for > > visual presentation of templates from the NHS work. > > > > We also want to reuse the semantics in templates to generate messages, > > reports etc. The question is how much 'generic' semantics can be reused from > > the templates built for specific purpose - screen templates, message > > templates and report templates. Surely the content for all types of > > templates will be quite different and we probably would like to have special > > syntax to support GUI hints, but do we need special syntax to support other > > uses? How about indicators for decision support, clinical research data and > > information lifecycle management? > > > > I am thinking about an extendable markup language that can be plugged into > > the core template language as a way to add extensions to templates if there > > is any application specific meta-data required. I am also in favour of the > > idea to store these extra meta-data inside the templates to ease the > > maintenance. When passing these templates around, the template engines can > > ignore the extended markup and only process the standard part if they don't > > recognize the extended syntax. > > > > Something like > > > > <gui_markup_plugin> > > <hide_in_GUI path="..."/> > > <hide_in_GUI path="..."/> > > </gui_markup_plugin> > > > > > > Cheers, > > Rong > > > > > > On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler <thilo.schuler at gmail.com> > > wrote: > >> > >> Would also want GUI things like "hide_in_GUI" to be in a separate > >> artifact on top of a template. It is good to hear that Ocean only did > >> that as quick fix to meet customers requirements, which is very > >> plausible. > >> > >> As mentioned before templates are great to initially SCAFFOLD a GUI, > >> which has to be further adapted by humans for the best possible > >> usability results (use-case and device specific). This allows > >> verification of the templates and archetypes from a user point of view > >> and is very important as Richard pointed out. > >> > >> I can understand Josinas comments about clinicians not caring about > >> the difference between semantics and GUI stuff, so a tool like the > >> Template Designer should hide this important separation, where > >> appropriate. > >> > >> Thilo > >> > >> On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie > >> <hugh.leslie at oceaninformatics.com> wrote: > >> > Hi Erik > >> > > >> > Personally, I don't think that templates should contain GUI rendering > >> > hints > >> > as they should remain purely about the semantics. There are others that > >> > don't agree with me. The "hide on form" function in the Template > >> > designer > >> > was partly to meet requirements for documentation of the templates for > >> > some > >> > groups using this technology. I am not sure if the hide_in_ui parameter > >> > is > >> > going to make it into the final template spec - Tom will have something > >> > to > >> > say about that. > >> > > >> > Personally, I think that there should be some other artifact that > >> > details > >> > GUI specs - if we mix up the two things, then the purpose of the > >> > template > >> > becomes confused. Templates can be used for everything from GUI, to > >> > data > >> > instance, persistance and query. If we add a whole lot of parameters > >> > around > >> > GUI, then we will also probably need to add specific things for these > >> > other > >> > uses and it might get very messy. > >> > > >> > regards Hugh > >> > > >> > Erik Sundvall wrote: > >> > > >> > Hi! > >> > > >> > On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> > >> > wrote: > >> > > >> > > >> > Thanks to the java reference implementation I have a demo of importing > >> > archetypes to auto generate forms which have the references to the > >> > archetype. > >> > > >> > > >> > Nice. Keep up the good work. > >> > > >> > On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> > >> > wrote: > >> > > >> > > >> > One thing I noticed in the conversion that I don't have any way of > >> > distinguishing between a line of text and multiline text in the > >> > archetype (I would generate an appropriate pane in the latter case). > >> > Perhaps not a big deal. > >> > > >> > > >> > This might be a useful requirement for the current template > >> > specification currently being worked on, or possibly a new kind of > >> > related specification. > >> > > >> > I first thought that templates so far had been considered as purely > >> > specifying semantics and that they were not supposed to give hints > >> > regarding GUI rendering. But now I see a parameter "hide_in_ui" in the > >> > class T_COMPLEX_OBJECT found in the draft template specification. (A > >> > similar function is present in the Template Designer tool from Ocean > >> > Informatics there is an option to "hide" elements instead of > >> > constraining them to zero occurrence, in the output file this is > >> > persisted as hide_on_form="true".) Could anybody detail it's intended > >> > use a bit more? > >> > > >> > I think GUI rendering hints can be appropriate to specify at the same > >> > point in time as template design is taking place. If the hints are to > >> > be persisted in the template file or in a separate file I guess could > >> > be discussed, keeping it in the file could have maintenance > >> > advantages, but probably has some disadvantages too. Thoughts? (And > >> > no, GUI hints are not appropriate in Archetypes since they are meant > >> > to have a wider reuse and the use cases are not known in the same > >> > detail as for templates.) > >> > > >> > In some of our implementation experiments and in discussions with > >> > clinicians a possible need for specifying detail levels in templates > >> > have surfaced. Some elements from archetypes are easy to completely > >> > dismiss or include for the specific use case in mind when designing a > >> > template clinicians will say things like "this will always be needed" > >> > or "this will never be needed". Other things could be conditional and > >> > trickier "you can't have all these details om the form - users would > >> > go crazy - let them show up if i click a plus-button or if i tick > >> > value x was true". > >> > > >> > The requirement to use GUI screen area optimally is even more pressing > >> > when using small input devices such as PDAs. > >> > > >> > If there was some way of specifying detail level in the template > >> > perhaps using a simple integer (0=default, 1..n=deeper detail with > >> > increasing number) then the same template could better support > >> > automated or semi-automated design of entry forms different screen > >> > sizes etc. One naive/simple but useful way of using the integer could > >> > be to add a "plus-button" for things with detail level 1 and within > >> > that subform have further plus buttons for level 2 and so on. > >> > > >> > The "conditional" requirements are trickier and probably needs more > >> > experimentation and evaluation than can be allowed if a first template > >> > specification should be completed and released within reasonable time > >> > (we all want that). The conditions might also in some cases better be > >> > specified in decision support or workflow than in templates. Also a > >> > look at the previous work with gradually expanding forms in > >> > Clinergy/Pen&Pad should be considered, I believe they were partly auto > >> > generated from ontologies. > >> > > >> > Thoughts? > >> > > >> > Best regards, > >> > Erik Sundvall > >> > erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 > >> > _______________________________________________ > >> > openEHR-technical mailing list > >> > openEHR-technical at openehr.org > >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >> > > >> > > >> > > >> > > >> > -- > >> > > >> > ________________________________________________ > >> > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > >> > Clinical Director > >> > Ocean Informatics Pty Ltd > >> > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: > >> > www.oceaninformatics.com > >> > > >> > _______________________________________________ > >> > 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 > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
