Carriage returns in DV_TEXT not allowed
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
Carriage returns in DV_TEXT not allowed
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
Carriage returns in DV_TEXT not allowed
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 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale Sent: Wednesday, 11 January 2012 1:19 AM To: openehr-technical at openehr.org Subject: Re: Carriage returns in DV_TEXT not allowed 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 modelhttp://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 # This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal
Carriage returns in DV_TEXT not allowed
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
Carriage returns in DV_TEXT not allowed
So, should the answer to Leonardo's question be to use DV_PARSABLE , with value= string, formalism =(unix/windows/mac ;ANSI/UTF8... )? Colin From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Leonardo Moretti Sent: Tuesday, 10 January 2012 9:05 PM To: openehr-technical at openehr.org Subject: Carriage returns in DV_TEXT not allowed 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? Thank you. Regards leo # This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal # IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. # -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/b78f372a/attachment.html
Carriage returns in DV_TEXT not allowed
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.
Carriage returns in DV_TEXT not allowed
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 On 10/01/2012 11:49 PM, Thomas Beale thomas.beale at oceaninformatics.com 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 modelhttp://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
Carriage returns in DV_TEXT not allowed
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? Thank you. Regards leo -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/c20eba63/attachment.html
Carriage returns in DV_TEXT not allowed
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/4922e19d/attachment.html
Carriage returns in DV_TEXT not allowed
On 10/01/2012 22:14, Peter Gummer wrote: 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. but there is no 'LIST' data type to contain the DV_PARAGRAPHs. - thomas
Carriage returns in DV_TEXT not allowed
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. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 10 Jan 2012 14:19:01 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Carriage returns in DV_TEXT not allowed 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! -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/e2eac81a/attachment.html
Carriage returns in DV_TEXT not allowed
On 10/01/2012 23:24, Peter Gummer wrote:
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.
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
Carriage returns in DV_TEXT not allowed
On 10/01/2012 23:24, 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? Hi Colin, you can already do that with DV_PARSABLE, which has two fields: the 'value' (text string) and the 'formalism', i.e. says whether it is HTML 1.4, PDF or whatever. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/d9cdf565/attachment.html
