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
|