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 From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Monday, 30 January 2012 11:52 PM To: openehr-technical at openehr.org Subject: pass_through and implementation directives in general On 30/01/2012 03:16, Heath Frankel wrote: 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 inteded for local use cases but are now also becoming important at jurisdictional levels for shared use. Heath, the options for passthrough today (ADL/AOM 1.5) seem to be the following: * leave it where it is today, specified on C_COMPLEX_OBJECT * move it to be an annotation within the new annotations section of ADL 1.5 archetypes, with a key such as 'view_directive' * create an entirely new section, structured the same (?) as the annotations section, within the archetype for view / other directives The potential problems with including a new view-directives section within archetypes include: * it makes the archetype dependent on those directives. They would need to be limited to universal directives, because most UI/presentation, as well as other implementation directives are locally specific, and there can clearly be more than one, for a given archetype. * we don't yet know what structure such a directives section should really take Potential benefits: * the section can be specified within the AOM & ADL docs, i.e. no new specs required * making a new section in archetypes & templates means that we don't need any new tools to process these directives - the main archetype compiler would do it * we could make it so that applying more local directives was done by defining correct inheritance rules for the implementation-directives section - i.e. use inheritance As I think about this, I am starting to be persuaded that continuing to use inheritance to achieve local additions and overrides is a good thing - it works for the rest of the archetype. If we commit to this path, the remaining question is: is the current annotations section structure sophisticated enough to contain implementation directives? An example of the annotations section from a current test archetype is as follows: annotations items = < ["en"] = < items = < ["/data[at0001]/items[at0.8]"] = < items = < ["design note"] = <"this is a design note on allergic reaction"> ["requirements note"] = <"this is a requirements note on allergic reaction"> ["medline ref"] = <"this is a medline ref on allergic reaction"> > > ["/data[at0001]/items[at0.10]"] = < items = < ["design note"] = <"this is a design note on intelerance"> ["requirements note"] = <"this is a requirements note on intolerance"> ["national data dictionary"] = <"NDD ref for intolerance"> > > ["/data[at0001]/items[at0002]"] = < items = < ["design note"] = <"this is a SPECIALISED design note on Statement"> ["NEW TAG"] = <"this is a SPECIALISED design note on Statement"> > > > > > So let's imagine that a new section could be of a similar structure. The first thing to note is that it is path-based. Is this sufficient? For now, I will assume it is. Secondly, do we need multiple languages? I would assume not, since we are now talking about computable strings rather than human-consumable strings. The tags will obviously be different. Here is a possible example. implementation_directives items = < ["/data[at0001]/items[at0.8]"] = < items = < ["presentation"] = <"pass_through"> ["querying"] = <"something_else"> > > ["/data[at0001]/items[at0.10]"] = < items = < ["presentation"] = <"widget_type=smart_text_coded_selector (args...)"> > > > The blue tags would have to be controlled somehow by agreement, and would define the possible 'implementation directives' that could be stated. The green values, or 'flags' could potentially also be controlled. The red part in the last one illustrates an example whereby the value is a piece of syntax (it could be a function call, or something like a Javascript expression). If the value space for a given 'flag' is controlled (e.g. 'widget_type' always = some javascript expression) then we have enabled some formal computing elements to be used, as are likely to be required for implementation. It seems clear to me at least that there would not be many of these implementation directives on international archetypes, but national and local archetypes, and particular templates would potentially have many. We would need to establish basic rules like: * tag names come from a) a central controlled vocabulary and additionally b) local values being allowed * this could be done by registering the vocabularies at different jurisdictional levels. Initially, I think we could just work off a central wiki page, with perhaps a few key tags defined in the AOM spec itself (if we can figure them out in time) * values could also potentially be defined in this controlled vocabulary, i.e. in the form * tag1 = value1 | value2 | value3 etc * or in other ways, e.g. tag1 = string; javascript syntax * specialised archetypes and templates could override the value of an existing tag with another legal value for that tag * but we probably need to allow locally defined values as well for tags with a fixed value set * specialised archetypes and templates can add directives containing new (locally-defined) tags and values * there may need to be a way to 'remove' a tag setting from an archetype This is obviously pretty 'soft' computing, and therefore open to some dangers, but if we manage it as a community in a sensible way, it could bring a lot of value. The use of specialisation to add new directives I think is the key to making it work properly with respect to localisation. thoughts? - thomas beale -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/0ee26490/attachment.html>
