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 On 31/01/2012 8:12 AM, "Erik Sundvall" <erik.sundvall at liu.se> wrote:
> Please rewind to > 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 > Den 30 jan 2012 14:31 skrev "Thomas Beale" < > thomas.beale at oceaninformatics.com>: > >> 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 >> >> >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/66eb5d9c/attachment.html>
