If we had a 'GUI template' facility in openEHR, I am not 100% sure that this pass-through setting would go into it. It's not GUI-specific, but I think it probably is 'presentation-specific', i.e. GUI, reports, any rendering of data onto a display device. Not all display devices are active GUIs: a tablet showing a PDF isn't.
Maybe another way of understanding this flag is as 'this node can be skipped without loss of meaning'. I would be very interested to know if we should make AQL queries sensitive to this flag. Has anyone thought about that? - thomas On 25/01/2012 18:05, pablo pazos wrote: > Hi Heath! > > Just for the record, I think as Diego: I don't have a problem to have > the pass_through attr on templates right now, but we have to comment > possible issues with this and other attributes to improve templates in > the future. > > The pass_through view constraint is not a GUI directive, it is a data > view directive which is consistent with archetypes/templates being > definitions of data structures. Just as form generators may use this > data definition to lay out a form and bind to a data instance, it may > use this pass_through view constraint to collapse a redundant grouping > on a screen. Similarly an XML schema or class generator may use this > same constraint to collapse a redundant element grouping. This > ensures that screen layout and binding are consistent with the XML > schema or class it will bind to. > > If I understand correctly, the pass_through attribute is only for data > displaying on a screen (as you mention the use for data grouping or > collapsing). If that's right, I don't think that should be part of the > generic template structure, because templates are meant to represent > other elements than data views/GUI, like messages, reports, etc. > > > As you mention "screen layout and binding are consistent with the XML > schema or class it will bind to" I feel maybe this is a little > attached to Oceans implementation, e.g. in our implementaition we > don't have binding with XML Schemas . > > > I historically was of the opinion that GUI only directives such as > control type or position should be provided separately as these a > really implementation specific and have minimal use in shared > artefacts such as archetypes and templates. Having said that the view > constraint could easily be used for this purpose if desired. > > I totally agree with you. Having an operative template with all the > data structure in it, the last step should be define the GUI Template > with controls, position, style, etc., and that should be the artefact > consumed by EHR software for clinical data recording and displaying. > > > The XSD for the view constraint is as follows: > > <xs:complexTypename="T_VIEW"> > > <xs:sequence> > > <xs:elementname="constraints"minOccurs="0"maxOccurs="unbounded"> > > <xs:complexType> > > <xs:sequence> > > <xs:elementname="items"maxOccurs="unbounded"> > > <xs:complexType> > > <xs:sequence> > > <xs:elementname="value"type="xs:anySimpleType"/> > > </xs:sequence> > > <xs:attributename="id"type="xs:string"use="required"/> > > </xs:complexType> > > </xs:element> > > </xs:sequence> > > <xs:attributename="path"type="xs:string"use="required"/> > > </xs:complexType> > > </xs:element> > > </xs:sequence> > > </xs:complexType> > > An example use of this is as follows: > > <template xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns="http://schemas.openehr.org/v1";> > > ... > > <view> > > <constraints > path="/content[openEHR-EHR-OBSERVATION.lab_test.v1]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.specimen.v1]/items[at0046]"> > > <items id="pass_through"> > > <value>true</value> > > </items> > > </constraints> > > </view> > > </template> > > Heath > > > > Kind regards, > > Pablo. > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/cbcca1a9/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/cbcca1a9/attachment.jpg>
