I agree with Leonardo. The current approach feels over-engineered and
over-restrictive for most simple circumstances and off-mainstream for
more complex rich-text outputs. I would like to DV_TEXT allow Unicode
characters, but also consider supporting something like the CDA
Narrative block (XHTML) directly.
Ian .
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
Clinical Modelling Consultant,?Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care ?www.phcsg.org
On 11 January 2012 09:30, Leonardo Moretti <lmoretti at noemalife.com> wrote:
>
> I don't think DV_PARAGRAPH is a good solution for me. I think the construct
> of DV_TEXT/DV_PARAGRAPH is too much complex to be used: we need to have an
> ?ad hoc text editor? to show and set the content of DV_PARAGRAPH. Moreover,
> I don't see which are the real advantages this approach gives: although
> DV_PARAGRAPH gives a sort of structure to text, this remain a free text, not
> coded, and without any metadata associated to DV_TEXT lines.
>
> Whatever I need to use text containing some words that are hyperlinked /
> coded / formatted, I prefer to use DV_PARSABLE, where a plain formalism is
> used (formalism matches {"text/plain"}).
>
> Anyway, carriage returns, tabs, line feeds are not parts of a specific
> formalism, but just characters. I think this is an excessive restriction (at
> least because I don't see the need for this restriction). Other data types,
> as ISO ST, let to use any valid unicode characters.
>
> leo
>
>
> Thomas Beale-3 wrote:
>>
>> On 10/01/2012 10:05, Leonardo Moretti wrote:
>>> If DV_TEXT doesn't allow to use carriage returns, line feeds, or other
>>> non-printing characters, as stated in
>>> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf,
>>> pag 29, there is a way to represent short text with minimal formatting
>>> characters (carriage returns)? Which data type should be used?
>>>
>>
>> It would be interesting to know how many other implementers agree with
>> this restriction. It was put in (from memory) in the very early days of
>> modelling, based on GEHR, and possibly somewhat on 13606 - nearly 10
>> years ago!
>>
>> The idea was that DV_TEXT models a 'text fragment', essentially the idea
>> of a word, string of words, sentence or possibly a group of sentences.
>> No CR/LF were allowed because this is taken as a paragraph delimiter,
>> and the type DV_PARAGRAPH was defined to represent multiple DV_TEXTs
>> making up a long tract of text like a report. In proper word processing
>> & publishing, this is correct; a 'paragraph' has no CR/LF in it, which
>> is what allows resizing to work properly in different screen / form
>> widths.
>>
>> Additionally, any 'atomic' text item, e.g. a single disease name, single
>> sentence etc - which make up the majority of text data within structured
>> data - should not have a CR/LF.
>>
>> This way of thinking may be dated, and it is a good question as to when
>> a piece of text can't be a single DV_TEXT. If we stick with the current
>> model
>> <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109597816149_873308_762Report.html>
>> (and remember, a DV_CODED_TEXT is-a DV_TEXT in openEHR), the openEHR RM
>> is imposing a simple word processing model of 'paragraphs' made up of
>> 'text fragments'. An alternative would be to allow anything in a
>> DV_TEXT. The decision about when you have to have a new DV_TEXT is made
>> on the basis of attributes other than the actual string value, i.e.:
>>
>> ? * hyperlink: if there is a hyperink, it applies to the entire DV_TEXT;
>> ? ? therefore, if you only want a link to correspond to 2 words, then
>> ? ? those 2 words = 1 DV_TEXT
>> ? * formattting: simple formatting like bolding, emphasis (about the
>> ? ? same level as typical wiki markup) applies to the whole DV_TEXT;
>> ? * mappings: coded mappings, e.g. ICD code applies to whole DV_TEXT;
>> ? ? need to use multiple DV_TEXTs if only some words are to have an
>> ? ? associated code mapping
>> ? * formal coding: if a DV_CODED_TEXT is to be used - i.e. when the
>> ? ? string value is the term for the code from its terminology (not just
>> ? ? some mapping), then the DV_CODED_TEXT.value can only consist of the
>> ? ? exact word string to which the code corresponds; more DV_TEXTs have
>> ? ? to be added using a DV_PARAGRAPH to construct a whole paragraph
>>
>> The best approach with the current model is:
>>
>> ? * for atomic text items, e.g. single word/sentence answers to
>> ? ? questions, single coded terms like names of diseases, procedures
>> ? ? etc, use a single DV_CODED_TEXT or DV_TEXT.
>> ? * for a tract of text containing some words that are hyperlinked /
>> ? ? coded / formatted, use a DV_PARAGRAPH containing multiple DV_TEXTs.
>> ? * Or else you use a DV_PARSABLE, containing XML, HTML, RTF or whatever
>> ? ? you like - but ... no guarantee the receiver can read it!
>>
>> This does not actually solve properly the problem of how CR/LFs are
>> added. If we assume one DV_PARAGRAPH = 1 CR/LF (as in word processing)
>> then a report needs to consist of multiple DV_PARAGRAPHs, and we don't
>> currently have a data type for that. To fix the current model we could
>> add a new type DV_DOCUMENT, which contains multiple DV_PARAGRAPHs. Or we
>> could remove the restriction on CR/LF on DV_TEXT, but that then would
>> allow CR/LFs to occur in single DV_CODED_TEXT strings, which is almost
>> certainly an error. But maybe we just assume that software never makes
>> this error?
>>
>> The real question is: do we want to have any explicit word-processor
>> like model of text? 10 years ago, the answer seemed obvious: yes,
>> because there is no reliable standard of marked up text (many variants
>> of HTML, XML, wiki markup, etc). I am not sure the answer is any
>> different today. From a clinical perspective, guaranteeing readability
>> of text in a standard way is paramount.
>>
>> - thomas
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/Carriage-returns-in-DV_TEXT-not-allowed-tp33113080p33119721.html
> Sent from the openehr-technical mailing list archive at Nabble.com.
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
