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