# pass_through attribute in ADL 1.5

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2012-01-05 08:54 UTC
**Views:** 2
**Replies:** 39
**URL:** https://discourse.openehr.org/t/pass-through-attribute-in-adl-1-5/15130

---

## Post #1 by @yampeku

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\.

---

## Post #2 by @thomas.beale

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.

<img src="upload://lmCj2ljGvgIZSvpSViumXmgG8IM.png" alt="">

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

---

## Post #3 by @Koray_Atalag

Hi Tom and Diego,

Short response is yes this is a better way of hardwiring a pure presentation related attribute into Archetypes which are supposed to deal with meta-data, structure and semantics of information only. The ideal solution would be to have an accompanying (but separate) layer of model responsible for GUI stuff.

Our experience is that there are three types of such ‘things’:

1) Pure GUI related (such as passthrough or depicting a particular GUI widget, style etc.)

2) Assumed (e.g. to render a textbox for DV_TEXT or draw a frame/indend children nodes under CLUSTER)

3) Mixed – where it is not easy to separate presentation from semantics.

Regarding (3), for example we have a GUI Directive called isCoreConcept (which we were inspired by the openSDE project by Astrid van Ginneken) which when modelling clinical findings and causes GUI generator to put a four state checkbox (null, present, absent, unknown). This actually applies to any ‘thing’ which we can also talk about its absence. This semantics implies to show or hide all of its children based on its presence (or absence).

I think we can use one Archetype attribute (to depict the semantics that this is a clinical finding or perhaps a new class of its own (e.g. DV_CLINICAL_FINDING) and perhaps separate GUI directives (or make it an assumed behaviour when that semantic attribute is set) create this appearance and behaviour.

Not so sure if I can show you other clear examples (other than core concept) at this stage but I suspect there are others.

Oh and we have also identified a whole new territory which we call ‘information axes’ and ‘semantic equivalence’ ;) This also has to do with both semantics and presentation I believe. Think about capturing (and modelling archetypes) a clinical statement as:

“Polyps were present in sigmoid colon and rectum and ulceration was seen in rectum.”

“In rectum polyps and ulceration were seen and ulceration was present in sigmoid colon”

These are equivalent but how to model the archetypes; e.g. finding or site oriented will depend on modelling best practices and use cases. Rule of thumb is to design archetypes as close to screen representation as possible (hence the clinicians thinking). We must be able to depict in archetypes and/or presentation model that alternative representations exist and how to construct these. SNOMED CTs normal/canonical forms is pretty related with this but then the semantics is hardcoded into the SCT axes.

My 2 cents


[details="(attachments)"]

![fdcdijfa.png|614x230](upload://lmCj2ljGvgIZSvpSViumXmgG8IM.png)

[/details]

---

## Post #4 by @Seref

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.


[details="(attachments)"]

![fdcdijfa.png|614x230](upload://lmCj2ljGvgIZSvpSViumXmgG8IM.png)

[/details]

---

## Post #5 by @pablo

Hi Diego & Thomas,

I think this should be out of the scope of the new semantic/structural archetypes & templates specs, and should be included in a new specification of GUI Templates.

I been working on this subject for a while and want to formalize a XML format to have GUI directives / GUI definition (input controls, position, visibility, order, ...) and binding with structural archetypes and templates (in a system this bindings should be to OPTs).

[http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates](http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates)

On february/march 2012 I'll be working on this to improve the flexibility of our current templates: [http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen%2Ftemplates%2Fhce](http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen%2Ftemplates%2Fhce)

If anyone want to work on this, would be a pleasure to colaborate.

FYI: We have developed a prototype editor for those GUI templates: [http://code.google.com/p/template-editor-open-ehr-gen/](http://code.google.com/p/template-editor-open-ehr-gen/)
It is web based, and can access archetypes repositories via HTTP to pull archetypes to be included in a GUI template.


[details="(attachments)"]

![fdcdijfa.png|614x230](upload://lmCj2ljGvgIZSvpSViumXmgG8IM.png)

[/details]

---

## Post #6 by @yampeku

If it is really needed for the moment for representing templates then
it&#39;s OK with me \(as long as we agree that this is a temporal thing\),
but I still feel that having two separated places to rule UI
generation is a bad idea\.
I think that annotations could work for you \(even creating a new
specific ADL section would\)\.
We currently have all the GUI directives for representation in a
documentation file for each reference model \(as you can see in this
screen capture http://i.imgur.com/tQxRt.png). This could be extended
to general templates in similar way to the one that Pablo has posted\.
on the other hand, EHRFlex uses a complete MVC architecture, in which
the intermediate model \(which also depends of your RM\) is the one
responsible to transform archetypes/templates into classes that the
&#39;view&#39; part can then paint\.

---

## Post #7 by @ian.mcnicoll

Hi Diego,

&#39;pass\-through&#39; is required to construct clear clinical views of
template models in some circumstances\. I think the suggestion to use
the annotations feature makes sense\.

A common example might be where a complex Discharge summary
requirement asks for a Diagnosis field\. This would be modelled as
something like

EVALUATION\. diagnosis\.v1
items
&nbsp;&nbsp;Diagnosis name

From a clinical review perspective the EVALUATION root node and items
node are redundant, and it is confusing to have them appear in the
tooling views

It would be great if we could make some progress on a GUI templating
formailsm putting together the work done in EHRFlex, Koray&#39;s GastrOS
directives and, of course, Pablo&#39;s work, bearing in mind that at least
some of the directives and transformations have utility in other
outputs e\.g Documentation and not just in GUI production\.

Ian

Dr Ian McNicoll
office \+44 \(0\)1536 414 994
fax \+44 \(0\)1536 516317
mobile \+44 \(0\)775 209 7859
skype ianmcnicoll
ian\.mcnicoll@oceaninformatics\.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation  www\.openehr\.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care  www\.phcsg\.org

---

## Post #8 by @Heath_Frankel3

Hi Paplo,
Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer.
If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class.
The term view was adopted because it is used in both GUI and data oriented contexts.
I can provide the XML schema for this AOM extension used by the template designer if people are interested.
Heath

---

## Post #9 by @pablo

Hi Heath,

Hi Paplo,

Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer.

In that case, I think we should separate the uses of the directive. IMO is a little anoying to use the same directive to do semantic processing of the structure and to do GUI generation/customization.

If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class.

I'm afraid I could not see what you mention, I don't have a licence for the TD.

The term view was adopted because it is used in both GUI and data oriented contexts.

I can provide the XML schema for this AOM extension used by the template designer if people are interested.

It would be nice to see the schema and some documentation about the structure and rationale behind it if you have some (just to understand the XML structure).

Cheers,
Pablo.

---

## Post #10 by @pablo

Hi!

> From: yampeku@gmail.com
> Date: Wed, 11 Jan 2012 10:12:39 +0100
> Subject: Re: pass_through attribute in ADL 1.5
> To: openehr-technical@openehr.org
>
> If it is really needed for the moment for representing templates then
> it's OK with me (as long as we agree that this is a temporal thing),
> but I still feel that having two separated places to rule UI
> generation is a bad idea.

I totally agree with Diego.

> I think that annotations could work for you (even creating a new
> specific ADL section would).
> We currently have all the GUI directives for representation in a
> documentation file for each reference model (as you can see in this
> screen capture http://i.imgur.com/tQxRt.png). This could be extended
> to general templates in similar way to the one that Pablo has posted.
> on the other hand, EHRFlex uses a complete MVC architecture, in which
> the intermediate model (which also depends of your RM) is the one
> responsible to transform archetypes/templates into classes that the
> 'view' part can then paint.

EHRGen also is MVC but we generate HTML forms for creating & editing clinical records, and a other HTMLs for showing individual records (documents/compositions).

Maybe we could share our current GUI directive formalisms to think about a new/common formal way to express all the things we need to generate GUI. I also want to work on generation of reports with aggregated data, trying to reuse what we could for the GUI generation for clinical recording & viewing.

Cheers,
Pablo.

---

## Post #11 by @Heath_Frankel3

Hi Pablo,

The Ocean Template Desiner is now freely available from [https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+Releases](https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+Releases).

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.

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.

The XSD for the view constraint is as follows:

<xs:complexType name="T_VIEW">

<xs:sequence>

<xs:element name="constraints" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="items" maxOccurs="unbounded" >

<xs:complexType>

<xs:sequence>

<xs:element name="value" type="xs:anySimpleType"/>

</xs:sequence>

<xs:attribute name="id" type="xs:string" use="required"/>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="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

---

## Post #12 by @thomas.beale

Hi Diego

> If it is really needed for the moment for representing templates then
> it&#39;s OK with me \(as long as we agree that this is a temporal thing\),
> but I still feel that having two separated places to rule UI
> generation is a bad idea\.
> I think that annotations could work for you \(even creating a new
> specific ADL section would\)\.

technically, the annotations might work \- it depends on how much needs
to be said, because the annotations are not very powerful in terms of
structure or semantic expressions \- they are after all designed to be
&#39;notes&#39; of some kind\. But the real problem is likely to be that for a
given archetype \(most likely national or local ones\) or template \(e\.g\. a
national one for discharge summary\), there are more than one UI template
&#39;overlay&#39; \- e\.g\. let&#39;s say you have a Spanish template &amp; some e\-health
groups in Andalusia &amp; Galicia regions want different UIs\. That means
multiple UI\-templates\.

> We currently have all the GUI directives for representation in a
> documentation file for each reference model \(as you can see in this
> screen capture http://i.imgur.com/tQxRt.png).

I don&#39;t understand which of these settings inn the right hand group is
too do with UI rendering of the data\.\.\.?

\- thomas

---

## Post #13 by @yampeku

visible, allowed types, icon\.\.\.

---

## Post #14 by @thomas.beale

ok \- I understood those were settings relating to the display of that
kind of node within the modelling tool, not of the data in a deployed
system\.\.\.\. so its about data? What does icon mean then?

\- thomas

---

## Post #15 by @yampeku

No, but they can be used for different things, from creating specific
editors, to mindmaps or sample GUI generation

---

## Post #16 by @pablo

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:complexType name="T_VIEW">

<xs:sequence>

<xs:element name="constraints" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="items" maxOccurs="unbounded" >

<xs:complexType>

<xs:sequence>

<xs:element name="value" type="xs:anySimpleType"/>

</xs:sequence>

<xs:attribute name="id" type="xs:string" use="required"/>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="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.

---

## Post #17 by @thomas.beale

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

[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #18 by @pablo

Hi Thomas,

Maybe we should talk about Presentation templates instead of GUI templates, but I definetly we should separate attributes for data related logic and presentation/GUI logic.

Regards,
Pablo.


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #19 by @system

2012/1/25 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)>

> 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?

In this sense I can see the reason for this attribute, since it can be understood as part of the documentation of the clinical model. But definitely it is not clearly described at the specs since there it seems to be linked to the presentation template only.

I fact, there is a similar attribute in EN13606 ITEM class, but used in an opposite sense. The attribute is "emphasis" and it is described as "A way of denoting that the composer wished to mark this ITEM as being of particular note (an unusual measurement value, an unexpected outcome, anything that might be considered necessary to highlight to a future reader)."

I have never thought about this. I don't know if this kind of annotations ("this item is important or clinically relevant or not") better fits as part of the RM or part of the AOM. In other words, if this marker is related to a specific data instance or to a data item definition in an archetype.

Thoughts on this?

---

## Post #20 by @yampeku

Would this attribute value change depending on where is the archetype
used? i\.e\. if we use it on a GUI of a smartphone rather than a
standalone or web application

---

## Post #21 by @system

Following this new sense for it, I think that the implications for a GUI or visual representation would depend on a decision of the implementers. If the screen space is reduced, they could opt for just showing the "clinically relevant" data and leave the rest for a second screen, a pop-up or something like that.

2012/1/25 Diego Boscá <[yampeku@gmail.com](mailto:yampeku@gmail.com)>

---

## Post #22 by @yampeku

but they won&#39;t show everything on a &#39;full&#39; GUI either\. Maybe what is
needed is not only a boolean but a way to tell exactly the criteria
with different values of a controlled vocabulary, such as &#39;mandatory&#39;,
&#39;recommended&#39;, &#39;passable&#39;/&#39;skippable&#39;\.\.\.

---

## Post #23 by @system

In fact, the "emphasis" attribute of 13606 is a CV.

2012/1/26 Diego Boscá <[yampeku@gmail.com](mailto:yampeku@gmail.com)>

---

## Post #24 by @thomas.beale

> 2012/1/25 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)>
>
> > 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?
>
> In this sense I can see the reason for this attribute, since it can be understood as part of the documentation of the clinical model. But definitely it is not clearly described at the specs since there it seems to be linked to the presentation template only.
>
> I fact, there is a similar attribute in EN13606 ITEM class, but used in an opposite sense. The attribute is "emphasis" and it is described as "A way of denoting that the composer wished to mark this ITEM as being of particular note (an unusual measurement value, an unexpected outcome, anything that might be considered necessary to highlight to a future reader)."

I remember many arguments about that one in CEN meetings. It was intended originally to be used on text items.

> I have never thought about this. I don't know if this kind of annotations ("this item is important or clinically relevant or not") better fits as part of the RM or part of the AOM. In other words, if this marker is related to a specific data instance or to a data item definition in an archetype.

well I am always suspicious of subjective markers like 'important' and so on. At least 'pass-through' is a mechanistic kind of concept. I agree that it has not been analysed properly though, and I think that can only be done in the clinical realm. At the moment, I think we need to support it because it is already in use in the .oet templates. The question is whether it turns out to have some proper semantic basis or is indeed 'just presentation'. We should ask why it is there at all: the reason is that it deals with information nodes that are not needed cognitively (i.e. for human understanding) but are an unavoidable artefact of information trees - but only sometimes... as far as I know there is no reliable algorithm for removing these nodes from presentation.

- thomas

---

## Post #25 by @thomas.beale

I know that sounds logical but that is not the way clinical people use
this attribute\. They look at certain archetypes and simply decide to add
it, with out regard for which particular device it is displayed on\. For
them it is not optional to remove it or keep it \- in a given archetype\.
In other archetypes it is not used at all\. I will try to obtain some
examples\.\.\.

\- thomas

---

## Post #26 by @Heath_Frankel3

Hi Pablo,

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.

No, that is not what I are saying. I are saying it can be used for more than display purposes such as data views, 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 .

Ocean doesn’t bind to XML schema either, I used this as an example of why you may want to ensure your presentation view is consistent with a data view derived from the same template artefact.

The use of the annotation-like structure for view directives allows us to separate these kind of directives from true annotations and the data definition itself whilst providing flexibility for specifying a set of directives that we know of now but may improve on later such as pass_through, add to in the future, and also use in local environments. We need to remember that templates where intended for local use cases but are now also becoming important at jurisdictional levels for shared use.

I don’t believe that pass_through should be hard coded into the AOM. It should be in a more generic framework such as that I proposed in my previous email.

Heath

---

## Post #27 by @Heath_Frankel3

David,

Pass_through has no relevance to this emphasis concept in any way. It has been a means to collapse container attributes such as items when the hierarchical structure inherited from the RM or Archetype is no longer desired or relevant in a template perhaps because sibling items in a cluster or multiplicity has been constrained.

Heath

---

## Post #28 by @thomas.beale

Hi Pablo,

---

## Post #29 by @system

Please rewind to [http://www.openehr.org/mailarchives/openehr-technical/msg05530.html](http://www.openehr.org/mailarchives/openehr-technical/msg05530.html) and the followup messages in that thread.

Using an RDF like URI-based approach still seems to be an option. No registering hassle or new sections in adl, just alternate use of the existing annotation section.

// Erik

---

## Post #30 by @thomas.beale

Hi Erik,

your examples are:

annotations = <
["/data/items[at0003.7]/items[at0010]"] = <
items = <
["GUI-show-if"] = <"$smoker"> -- Other annotation name examples: GUI-hide-if ...
["some other annotation"] = <"whatever">

...with RDF-like annotations, some additional examples (and a wildly guessed language subsection syntax) it might turn out something like...

annotations = <
language = <
["RDF"] = <
["/data/items[at0003.7]/items[at0010]"] = <
items = <
["[http://schema.openehr.org/GUI-v0_1#show-if](http://schema.openehr.org/GUI-v0_1#show-if)"] = <"$smoker">
["/data/items[at0004.8]/items[at0011]"] = <
items = <
["[http://schema.openehr.org/GUI-v0_1#view](http://schema.openehr.org/GUI-v0_1#view)"] = <"[http://schema.openehr.org/GUI-v0_1#pass_through](http://schema.openehr.org/GUI-v0_1#pass_through)">
["[http://s.skl.se/qualreg/diab/](http://s.skl.se/qualreg/diab/)v-3_1#q10.2"] = <"[http://s.skl.se/qualreg/diab/v-3_1#daily](http://s.skl.se/qualreg/diab/v-3_1#daily)">
...

These look reasonable to me. As you can see from the below, they have a different structure from the annotations section - which contains linguistic strings and a language subdivision. This would not be needed as far as I can see with implementation directives.

I don't see any great problem in having a different section, given the purpose is quite different, and the flattening rules will probably be different (with annotations, the rule that makes sense is that the annotation for a given tag is concatenation with the value for that tag in a parent, whereas here, it would be replacement, i.e. override).

Using the RDF approach, the registering problem doesn't go away, it just gets moved to a different (arguably better) place - a schema or ontology. Fine by me also.

---

## Post #31 by @Heath_Frankel3

Hi Erik,
No problem with your RDF approach but I agree with Thomas that the purpuse of view directives. (or more generally, program directives) is very different from annotations. XML Schema separates these two concepts.
Ocean has reused annotations in the template designer for these kind of directives for some time as well as the hard coded hide-on-form, and it is from this experience that we have proposed this separate section.
Heath

---

## Post #32 by @Heath_Frankel3

Hi Thomas,

I think you’re going too far with this controlled key and syntax approach. The important thing at this point is we get a structure that we can start using to get more experience with. Although my proposal was a simple property value bag, I think your idea of a triplet is good, but we should do this using attributes rather than syntax. So a directive type, an name/ID and value attributes seems like a pretty powerful structure, its similar the Claim class in an Identity Model for authorisation (claim type, right, resource).

I think the majority of view directive use will be in templates at the local level, but certainly some directives are likely at the jurisdictional level (e.g. pass_through). For this reason, I think that we should not restrict the values to only controlled values, controlled values are only necessary for shared use and it is these that certainly need to have a registry. Erik’s RDF suggestion seems like a reasonable approach to doing this rather than openEHR inventing a new scheme. We need to support innovation in this area and hence allow local groups to use local directive type/identifiers/values at will and when they have something to bring back to the community somewhere to register and align their local directives with shared directives. A consumer should only need to process the directives it is interested in, unless we provide something like a must-understand attribute.

With regard to inheritance of directives, I think this needs to be based on the directive type. In some cases we will want an override, in others we would want addition or constraint. Not sure yet whether this needs to be specified in the directive or not so that the compile can generate the appropriate result or always have the complete set and leave the responsibility to the consumer to interpret the set.

I don’t think we need to make this too complicated at first, the main thing is to get the containment structure right, we can always add attributes such as must_understand and override mode to the directive class later.

Regards

Heath

---

## Post #33 by @system

Hi!

Ok, if implementation experience says it is better to have separate sections for human readable annotations and machine-targeted "program directives" then I guess that is a good approach. Are there any tools that support this now?

If going for an RDF-like URI based approach for "program directives" or "implementation_directives" then those serialization formats that aim for human readability (e.g. ADL and YAML) may want to use some kind of URI-prefixing-mechanism to make the directives shorter and more readable. (Similar approaches are used in XML (namespaces) and many RDF serialization formats.)

I assume "program directives" will include both pass_through and more purely GUI-oriented directives. Will they contain everything annotation/directive-like that is intended to be machine processable and human language independent? Is that a correct and shared view of the purpose?

Are both "annotations" and "program directives" supposed to be attributes of the class AUTHORED_RESOURCE? I don't find them in the current [http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdf](http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdf) but I guess that might be a matter of time constraints - or are they going to be only a part of AOM/ADL itself? I just want to check what the future thoughts are.

Is "program directives" the best name? "Annotations" is very a very generic and useful name, but that word is already taken for the human readable stuff. Could anything from the following list inspire somebody with a more native feel for English to come up with alternate name suggestions?
- directives (shorter and more general than "program directives").
- instructions

- notes
- meta...something
- commands
- processing...
- triples
- links
- extensions
- ...

Best regards,
Erik Sundvall
[erik.sundvall@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733

---

## Post #34 by @thomas.beale

> Hi!
>
> Ok, if implementation experience says it is better to have separate sections for human readable annotations and machine-targeted "program directives" then I guess that is a good approach. Are there any tools that support this now?

well not today, but if we decide to specify this concept, I can implement it with examples in the reference ADL compiler very quickly. The code for more dADL sections is easy. Others are working in getting the Java parser up to ADL 1.5. Changes like this don't make that much difference because they are just straight dADL => objects transforms.

If we specifiy and implement the outer structure I proposed, but don't say anything about the tag or values, we can accommodate the RDF approach just as easily as anything else.

> If going for an RDF-like URI based approach for "program directives" or "implementation_directives" then those serialization formats that aim for human readability (e.g. ADL and YAML) may want to use some kind of URI-prefixing-mechanism to make the directives shorter and more readable. (Similar approaches are used in XML (namespaces) and many RDF serialization formats.)

I would opt for "implementation_directives", less ambiguous.

> I assume "program directives" will include both pass_through and more purely GUI-oriented directives. Will they contain everything annotation/directive-like that is intended to be machine processable and human language independent? Is that a correct and shared view of the purpose?

that's my understanding. I don't think anyone has any more than an ad hoc knowledge so far of what these things are likely to be, much less a structured theory about what *should* be included.

> Are both "annotations" and "program directives" supposed to be attributes of the class AUTHORED_RESOURCE? I don't find them in the current [http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdf](http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdf) but I guess that might be a matter of time constraints - or are they going to be only a part of AOM/ADL itself? I just want to check what the future thoughts are.

you can see annotations in section 7.1 of that doc. 'implementation_directives' I think should go on the ARCHETYPE class for now.

> Is "program directives" the best name? "Annotations" is very a very generic and useful name, but that word is already taken for the human readable stuff. Could anything from the following list inspire somebody with a more native feel for English to come up with alternate name suggestions?

well I think 'implementation_directives' says what we mean here, but it is annoyingly long, that's for sure. I am fine with 'directives', as long as we define what this means in the documentation and everyone understands its scope. 'processing_directives' or 'processing_instructions' seem like reasonable synonyms, but are also annoyingly long. Does 'processing' on its own make sense?

- thomas

---

## Post #35 by @thomas.beale

Hi Thomas,

I think you’re going too far with this controlled key and syntax approach. The important thing at this point is we get a structure that we can start using to get more experience with. Although my proposal was a simple property value bag, I think your idea of a triplet is good, but we should do this using attributes rather than syntax. So a directive type, an name/ID and value attributes seems like a pretty powerful structure, its similar the Claim class in an Identity Model for authorisation (claim type, right, resource).

I think the majority of view directive use will be in templates at the local level, but certainly some directives are likely at the jurisdictional level (e.g. pass_through). For this reason, I think that we should not restrict the values to only controlled values, controlled values are only necessary for shared use and it is these that certainly need to have a registry.

---

## Post #36 by @system

Hi!


> > If going for an RDF-like URI based approach for "program directives" or "implementation_directives" then those serialization formats that aim for human readability (e.g. ADL and YAML) may want to use some kind of URI-prefixing-mechanism to make the directives shorter and more readable. (Similar approaches are used in XML (namespaces) and many RDF serialization formats.)
>
> I would opt for "implementation_directives", less ambiguous.

In that part of the mail I was thinking of shortening serialisations of things like...

["[http://schema.openehr.org/GUI-v0_1#view](http://schema.openehr.org/GUI-v0_1#view)"] = <"[http://schema.openehr.org/GUI-v0_1#pass_through](http://schema.openehr.org/GUI-v0_1#pass_through)">

...to something like...

["gui:[view](http://schema.openehr.org/GUI-v0_1#view)"] = <"gui:[pass_through](http://schema.openehr.org/GUI-v0_1#pass_through)">

...by somewhere in the file defining

gui:

...to mean...

[http://schema.openehr.org/GUI-v0_1#](http://schema.openehr.org/GUI-v0_1#pass_through)

// Erik

---

## Post #37 by @thomas.beale

Erik,

which file do you mean here? Where is this alias?

- thomas

---

## Post #38 by @Heath_Frankel3

Erik,
I suspect the only tools using this are the Ocean Template Designer in its Operational Template XML output which extends the release 1.0.x AOM. This is only the second time I have presented this proposal, last time we had this same discussion it got no traction.
The CKM uses the Ocean OPT to generate HTML documentation of templates and uses the pass-through directive to collapse insignificant containers.

There are a couple applications that use the Ocean OPT extensions of the AOM for GUI generation but not sure if the use this directive.

Our implementation simply uses views, but my suggestion that we may want to extend the scope to all program directives seems to have been accepted.

XML uses processing_instructions, not sure we need to worry about length, we haven't until now and it only needs to be specified once.
Heath

---

## Post #39 by @system

> Erik,
> which file do you mean here? Where is this alias?

Oh, never mind, it was just a sidetrack, focus on other things if you don't get it. Let's not spend more email electrons, CPU cycles and brainpower on this part of the thread.

What I meant was that a serialized archetype- or template-file that uses a lot of similarly prefixed URIs could use internal aliases (defined in that specific archetype- or template-file) for long URI prefixes. This is done by many other RDF and XML serialization approaches to increase readability. But let's not do anything like that for ADL now. Maybe those of us that are interested in e.g. XML and YAML (that already have built-in prefix/namespace mechanisms) could look at this later.

Best regards,
Erik Sundvall
[erik.sundvall@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733

---

## Post #40 by @thomas.beale

that's what I wanted to check. I expect it would be useful in ADL archetypes - essential, if we are going to connect semantic net to archetypes - we just need a bit more solid theory on some of this stuff, to see how it should be done. I would guess at least that the AUTHORED_RESOURCE class should have some generic schema namespacing / alias capability, which is easy enough to do.

- thomas

---


**Canonical:** https://discourse.openehr.org/t/pass-through-attribute-in-adl-1-5/15130
**Original content:** https://discourse.openehr.org/t/pass-through-attribute-in-adl-1-5/15130