At 10:44 26/3/2003, Thomas Beale wrote:
>Grahame Grieve wrote: > >>These comments refer to V1.4.2 >> >>3.1 The class Locatable has a name, which is of type DV_TEXT. >>DV_TEXT seems inappropriate here, it includes formatting, >>hyperlinks, coded values, etc. I would've thought that string >>was appropriate? >> >>actually, this comment also applies in many other places when >>DV_TEXT is used. Other cases are the names of the items in >>a LIST_S, and the use of DV_CODED_TEXT for a null flavour > >Hyperlinks and formatting are still being discussed. Hyperlinks should >probably only be in data, not in name values as you say. However, I don't >know if we yet have enough experience to say how they will be used even >there. I suspect that invariants should be added to some places like >LOCATABLE to prevent hyperlinks and formatting being present in the name. >This can be done in any class, but it would be better to know if we have >to keep them at all in tis class, or put them elsewhere (e.g. DV_PARAGRAPH...) > >A plain String isn't appropriate because what is required is: >- a string value >- the language (consider that some words appear the same in multiple >languages but have different meanings) I thought all the content of a single transaction was confined to a single language? >- the possibility of the value being coded rather than just an entered string. yes, indeed. But the DV_TEXT and DV_CODED_TEXT are too complex to be used as constructs where simple coded values are required. They may be appropriate for clinical coding, but in these simpler "infrastructural" coding, it's not so clear I'm not necessarily arguing for a plain string. There has to be code, code system, version, text - ideally that would be all in a general infrastructural coding situation? Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
