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 On 31/01/2012 9:45 PM, "Erik Sundvall" <erik.sundvall at liu.se> wrote: > 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.pdfbut > 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 at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > > On Tue, Jan 31, 2012 at 00:07, Heath Frankel < > heath.frankel at oceaninformatics.com> wrote: > >> 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 >>> >>> >> _______________________________________________ >> 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/20120201/931710f8/attachment.html>
