# Carriage returns in DV_TEXT not allowed **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2012-01-10 10:05 UTC **Views:** 2 **Replies:** 13 **URL:** https://discourse.openehr.org/t/carriage-returns-in-dv-text-not-allowed/15120 --- ## Post #1 by @Leonardo_Moretti 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](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? Thank you. Regards leo --- ## Post #2 by @thomas.beale 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 --- ## Post #3 by @Peter_Gummer1 Thomas Beale wrote: > 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\. You could model multiple paragraphs as a LIST of DV\_PARAGRAPH\. I think the DV\_DOCUMENT idea would be unnecessary, unless you wanted to specify additional information such as sections or chapters within the document\. \- Peter --- ## Post #4 by @thomas.beale but there is no 'LIST' data type to contain the DV\_PARAGRAPHs\. \- thomas --- ## Post #5 by @Peter_Gummer1 Thomas Beale wrote: >> You could model multiple paragraphs as a LIST of DV\_PARAGRAPH\. > > but there is no 'LIST' data type to contain the DV\_PARAGRAPHs\. Sorry, not a LIST, I meant a multiple\-occurrence element like this:   ELEMENT\[at0009\] occurrences matches \{0\.\.\*\} matches \{ \-\- My document     value matches \{       DV\_PARAGRAPH matches \{\*\}     \}   \} In data this would become a sequences of paragraphs\. By the way, I wanted to generate the above ADL in Archetype Editor, but I discovered that DV\_PARAGRAPH hasn't been implemented there yet\! There's never even been a feature request for DV\_PARAGRAPH in Archetype Editor\. To write the above example, I had to generate another data type in AE and then edit the data type by hand\. I guess it would be safe to assume, then, that almost no one would be using DV\_PARAGRAPH\. \- Peter --- ## Post #6 by @Colin_Sutton Couldn’t the text stored in the eHR include HTML paragraph separators, replacing Windows or Unix specific line separators? And HTML escape sequences…. DV_HTMLTEXT? Regards, Colin --- ## Post #7 by @pablo Hi Thomas, In our RM implementation (Open EHRGen Framework), we use DV_TEXT to keep all kinds of non coded text: words, sentences, paragraphs, documents, etc. We don't use DV_PARAGRAPH. --- ## Post #8 by @Peter_Gummer1 Colin Sutton wrote: > Couldn’t the text stored in the eHR include HTML paragraph separators, replacing Windows or Unix specific line separators? > And HTML escape sequences…\. > > DV\_HTMLTEXT? That's what DV\_PARSABLE is for, as Thomas mentioned ;\-\) \- Peter --- ## Post #9 by @thomas.beale yes, but this needlessly creates multiple ELEMENTs, when intuitively you would expect one ELEMENT with the whole report in it\. You are right \- this is the solution available today\. But I think its wrong\.\. \- thomas --- ## Post #10 by @thomas.beale Couldn’t the text stored in the eHR include HTML paragraph separators, replacing Windows or Unix specific line separators? And HTML escape sequences…. DV_HTMLTEXT? --- ## Post #11 by @Colin_Sutton So, should the answer to Leonardo’s question be to use DV_PARSABLE , with value= string, formalism =(unix/windows/mac ;ANSI/UTF8… )? Colin --- ## Post #12 by @Leonardo_Moretti 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: --- ## Post #13 by @ian.mcnicoll 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@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 --- ## Post #14 by @Heath_Frankel3 We currently ignore this constraint as most multi line cases don't need the complexity of dv-text and the parsing overhead to get a list of dv-text is significant, and as you say we don't have a container of dv-paragraph unless you use multiple elements which is a heavy solution. I don't think dv-docunent is the right term to use considering the correlation between composition and document in cda-openEHR mappings. We have talk in the past about an element supporting a list of values, e.g. dv-list, otherwise another glyph grouping term should be used. Having said that, there certainly are issues with using new lines in dv-text, in particular which new line character sequence scheme to use but also how these are represented in XML, as literal characters or emcoded. Finally there is an issue when applying xslt to these new line representations, we currently need to support all possibilities. Using dv-paragraph would make it explicit but has overhead and issues described above. I think we need to support new lines in dv-text for simple scenarios but we need normalized guidance on XML representation, while ensuring we can properly support dv-paragraph for more complex situations in future. Heath --- **Canonical:** https://discourse.openehr.org/t/carriage-returns-in-dv-text-not-allowed/15120 **Original content:** https://discourse.openehr.org/t/carriage-returns-in-dv-text-not-allowed/15120