Re: Run-time name constraints and appropriate use of terminologies

[Sebastian Iancu <sebastian@code24.nl>]

On 8/20/2010 11:15 AM, Thomas Beale wrote:

The as_string() function certainly needs more thinking, but is essential for practical purposes. One way could be for another archetyped attribute to carry a formatting template, e.g.

ADDRESS/details/items[at0002]/items[at0096]/value = '$at0023\r\n$at0029 $at0028\r\n$at0005 $at0004\r\n$at0007'            -- at0096 = 'string formatting template'

This would then be processed by the application using the named siblings of at0096 to generate a string. There is currently no agreed 'standard' for this syntax, but for practical purposes, if one of the typical kinds of syntax, like unix as I have used above, or perhaps C printf were agreed, then the template could be shared. In this way in fact, more than one template could be shared, e.g. 'mailing format template', 'screen display template' etc.

This can be indeed a workable solution; perhaps in this case the 'ADDRESS/details/items[at0002]/items[at0096]' can be even set as a DV_PARSABLE to carry also the language/formalism, and thus no agreement on the standard is really necessary, isn't it?

However, I see this whole solution a bit cryptic towards end users, as requires some level of technical background (or at least knowledge outside openehr-language domain). I would prefer it to be in sync with is already stated within specifications, and that's why I though it can be accomplished with rules/assertions or some sort of constraint on as_string().

If this kind of approach were broadly acceptable, it could be documented in the demographic IM.

- thomas beale

Sebastian

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical