Hugh Grady wrote: >This thread seemed to start with the assumptions that firstly, a >DV_CODED_TEXT will inevitably be stored in XML and that, secondly, the >mapping to XML will be a very direct one, even up to the names of the >corresponding elements. Are either of these valid assumptions? Even if they >are, should the low-level implementation details really be a concern in the >ADL language design? I'm sure there are all sorts of clever tricks that >will be use to persist OpenEHR data efficiently, and it's by no means a >given that the persistence solution will involve XML when large datasets are >being managed. > > > I'm coming around to this argument, and I am also against making openEHR specifications particularly XML oriented (what if XML disappears one day?-)... Heath Frankel also pointed out to me privately that although having SNOMED::12314134 etc in the XML might be nice sometimes, but could also be incredibly annoying since you a) have to keep stripping the XXXXX:: bit off all the codes, and b) you may want to just search on code value or terminology id separately for various reasons.
I think that the correct answer to this is to leave the spec as is, and potentially to put a function into DV_CODED_TEXT that will generate the single string form; adding such a function makes no difference to the persisted data or anything else in the reference model. The XML-schema still has the freedom to use the single string form if desired, but I think it might be better if we went the orthodox object route there as well. We will need more implementation experience to know which is best. - thomas beale
