On 20/08/2010 11:01, Sebastian Iancu wrote:
> 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?
yes, should have thought of that myself;-) Only small challenge is that
we would still have to be careful to say what we mean by 'printf'
syntax, or 'excel' syntax (from memory excel or MS word have some kind
of templating mini-language for this kind of thing as well).
>
> However, I see this whole solution a bit cryptic towards end users
do you mean 'users' of archetype / template tools (presumably not system
users)? I would envisage a wizard for building the template - only
hardcore syntax fiends would look at the source.
> , 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()/.
*
* You gave the example:
as_string:
details/items[at0002]/items[at0023]/value + CRLF +
details/items[at0002]/items[at0029]/value +
details/items[at0002]/items[at0028]/value + CRLF +
details/items[at0005]/value +
details/items[at0007]/value
Issues here:
* you would need multiples of these to accommodate more than one
preferred style of address string formatting
* the expression would go very close to being legal rule, assuming
'CRLF' were defined in some way. openEHR rule syntax will migrate
toward Xpath, in the manner of the a-path specification done by a
Brazilian group (search wiki for this if you are interested).
* I personally think that a rule syntax is even more difficult for
people who are not mathematically / logically minded (which can be
doctors and IT people just like anyone else!). I think this is the
reason simpler formatting syntaxes are used in tools like Excel
and so on.
* I also think that we don't want to have to use a generic
expression editor to build string formatting expression templates;
I think something more like a wizard with elements you can drop
together would be better.
my thoughts for now. If you want to, feel free to raise this as a
problem report on the openEHR SPEC_PR Jira tracker - please include some
of the relevant discussion content, or else a URL pointing to the mail
archives.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100820/3b27e113/attachment.html>
