I repost this discussion from the java implementation list, I think it could be interesting to get feedback from the general implementers community.
---------- Forwarded message ---------- From: Thomas Beale <[email protected]> Date: 2014-04-02 12:51 GMT+02:00 Subject: Re: Invalid language codes in languages codeset To: ref_impl_java at lists.openehr.org I have not been following closely here, but I think the general approach should be that you perform a *design time *validation pass, that reports things like language incompatibility, i.e. never let there be ambiguity close to runtime. The question then is: how does the validation of this particular thing work? The first thing to note is that the possible slot fillers of a given slot in an archetype are only those that are found in the current *working set *of archetypes, not some theoretical maximum set (e.g. all of CKM or all Spanish MOH etc). So, within a chosen working set, validation on language compatibilty can probably only occur at the point of operational template (OPT) generation, i.e. where the user specifies which actual languages and terminologies (for terminology bindings) should be used, then a tool could run a relatively simple test to see that all archetypes in the working set do have translations in the chosen language(s). One could imagine more complex validations to do with figuring out of all slot-filling archetypes have any language in common with slot-defining archetypes, but I don't think this is useful. I have no check like this in the ADL Workbench yet, so I am interested to know what others think it should be. We don't really have a proper definition of 'working set' or other possible 'sets' of archetypes, but we probably need them. Getting a common definition means everyone agreeing on a standard workflow for archetype development, and possible ideas like defining a 'deployment set' from a larger 'working set', or maybe a publisher's 'release set'. - thomas On 02/04/2014 11:33, Diego Bosc? wrote: Just today we had another interesting discussion on a related topic about languages, translations, and slot solving. The problem comes when you have an archetype whose original language is different from the one that you are solving the slot with. There are several alternatives, but seems that there is no 'perfect' one. There is always the possibility of taking the original language of the solved slot archetype and just add it to the original archetype as a translation, marking the strings in the other languages in some way. This is related to the languages codes as we could assume that a slot with an 'en-gb' can be safely placed in a 'en' archetype and reuse all the texts and descriptions. The problem comes the other way around (can we assume that a 'en' slot can be safely placed in a 'en-gb' archetype?). Even if you have the same language in both archetypes, we have to consider if a translation from a slot has the same validity to be included in the original language descriptions of an given archetype (In theory, all translations should be made from the original language, and if the original language was another one, can we assure that the meaning is the same as the original?) Anyone of the list has been dealing with this problem? Which solutions have you adopted for your tools/systems? -- [image: Ocean Informatics] <http://www.oceaninformatics.com/> *Thomas Beale Chief Technology Officer* +44 7792 403 613 Specification Program, *open*EHR<http://www.openehr.org/> Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/> Health IT blog <http://wolandscat.net/category/health-informatics/> [image: View Thomas Beale's profile on LinkedIn] <http://uk.linkedin.com/in/thomasbeale> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140402/25db87f3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: btn_liprofile_blue_80x15.png Type: image/png Size: 511 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140402/25db87f3/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 4085 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140402/25db87f3/attachment.jpg>
