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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/c411078d/attachment.html>
