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
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
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
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
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
-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.
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
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
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
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
: 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
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
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
13 matches
Mail list logo
