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
o 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
o tag1 = value1 | value2 | value3 etc
o 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
o 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/20120130/cf7139a9/attachment.html>
