Why don't we use the new annotations feature to handle these type of concerns? You can put pretty much anything you want into annotations section for a node. The whole section is optional, so one can simply ignore that section, and no concerns are mixed...
In fact, given the external ref mechanism, one can even create "annotation archetypes" simply consisting of nodes to annotate in another archetype, and the annotation section. On Mon, Jan 9, 2012 at 7:03 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 05/01/2012 08:54, Diego Bosc? wrote: > > Put a couple of comments on the wiki, but I think it is a thing that > should be discussed on the list. > In ADL 1.5 a flag 'pass_through' was added. Its definition is 'Allows > nodes required for structuring data but otherwise redundant for screen > display and reporting to be detected by rendering software'. So now we > have a GUI directive on the ADL. Shouldn't this be a part of the > reference model information (if it is never supposed to be displayed) > or part of a 'visualization template' (another different level). > I would say that more information about visualization will be needed, > and having visualization information separated between two different > places feels like a bad design move. > > > In general I am inclined to agree, and I have to say I have been in two > minds about having this attribute in there. I am convinced by clinical > modellers who say that something is needed to control interior tree nodes > not appearing on the GUI (indeed, it is visual pollution). And - even if > the template were being used to build a message definition (generated XSD > or similar), and the data were processed into some report or other output, > this attribute would be respected (technically, this is still 'user > interface'). > > I know the passthrough attribute is used often from the current .oet > template usage, so we need a way of dealing with the requirement. If we > take it out, and say it is a GUI directive, the problem is we currently > have no formal framework for that yet. Maybe the lesser of two evils is to > do what Koray (I think?) said, and make it a special kind of annotation. I > have implemented annotations in ADL/AOM 1.5, and they work nicely. We need > to agree on some kind of standard representation, e.g. > > > > I originally didn't like this approach (I still don't really) but we have > to be realistic and it's not the end of the world to bootstrap like this. > As you can see it is 'soft programming', so error-prone, but it can > obviously be made to work, and isn't hard to implement. However, now > rendering software has to know to look for "ui" annotations and do sensible > things with them. > > thoughts? > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/7e3bd9d7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: fdcdijfa.png Type: image/png Size: 8902 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/7e3bd9d7/attachment.png>
