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

[Thomas Beale <thomas.beale@oceaninformatics.com>]

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.

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

- thomas beale


On 19/08/2010 11:54, Ian McNicoll wrote:

PART 2 :

As about the other issue of as_string(), let me give you an example to express my concerns:
Lets suppose we have again hospital A residing in UK while B residing in NL. A is going to use CKM archetypes for ADDRESS, while B not, and lets suppose we have the following case/data for an address (I will only detail relevant fields)

... - other data

ADDRESS/details/items[at0002]/items[at0023]/value = 'MyHouseName'

ADDRESS/details/items[at0002]/items[at0028]/value = 'MyStreet'

ADDRESS/details/items[at0002]/items[at0029]/value = 100

ADDRESS/details/items[at0002]/items[at0031]/value = ' .... MyStreet 100 ...,  MyHouseName' -- address line

ADDRESS/details/items[at0004]/value = 'XYZ 123' -- zip

ADDRESS/details/items[at0005]/value = 'MyTown'

ADDRESS/details/items[at0007]/value = 'UK'

... - other data

So what you would expect from the as_string() is basically something like: 

MyHouseName

100 MyStreet

MyTown

XYZ 123

UK

which I guess is 'statically' implemented in the application used in A. As you can see the expected string might not be just a concatenated string of all values found in the object but rather a templated/formatted string. 

Now, if A is sending these data to B for further processing, then B requires the same archetype in order to parse/understand the data he got. Using local terminology (found in archetype) B can assign meaning to each of the node, but he cannot produce the same as_string() as he doesn't have the same knowledge as A. So he will probably produce a B-localized version of it. Is this enough or not? Is it really a problem or just weak in theory? - I don't know, but perhaps if we can capture the pattern in the archetype it will be better. This is why I was asking about this as_string().

If I can think of something like rules/assertions (although I'm not very familiar with them) in the cADL they can look similar to:

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

although I know this is not a valid cADL grammar. As I said, I'm not very familiar with the syntax, and I'm not sure how to use it afterwards - i.e. is the above going to assign an _expression_ to as_string() function? 

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