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