Rich text format in DV_TEXT
Hi Alessandro, Curious as to the use case for the DV_PARSABLE. Can you share? I'll let the engineers discuss potential enhancements to the datatype. Heather From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Alessandro Torrisi Sent: Friday, 20 September 2013 11:57 PM To: For openEHR technical discussions Subject: Rich text format in DV_TEXT Hello, we are using an archetypes from the CKM called openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is an DV_TEXT element called Synopsis One of our clients want to use rich text format inside that field. According the specification it is not allowed to put formatted text over there. I rather should use a DV_PARSABLE. How should i handle this correctly? The options i see are : - specialise the archetype and add an DV_PARSABLE, and leaf the existing DV_TEXT empty - create my own archetype where I set the Synopsis element to a DV_PARSABLE beside this question, i wonder if it will be better to give the DV_TEXT datatype the possibility to put over there rich text. If we also add the parameter formalism to it, there is no really need any more for a DV_PARSABLE. -- Alessandro Torrisi -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/a43d7219/attachment.html>
Polishing node identifier (at-codes) use cases.
On 20/09/2013 20:40, Bert Verhees wrote: > Op 20-9-2013 17:01, Thomas Beale schreef: >> it's simpler than you think - we made that property mandatory so that >> programmers would never get a null exception. > Must have been along time ago, nowerdays, programmers have no problem > handling a null property. actually, that's not quite true. It's probably the primary reason for exceptions in object-oriented software - method call on a void object. But I get what you are saying, and for this String field, being null would not pose a great problem. So we could change the spec to do that. > > I wonder what the idea behind stuffing the archetype_id in the > archetype_node_id property is? > Here you make it harder for programmers because the archetype_id has > another syntax in archetype-paths then the archetype_node_id has, and > anyway, lots of other functions, and a programmer has to check the > string-layout to find out if it is an archetype_id or an > archetype_node_id. It also blocks the possibility to store the > "at"-code for the root, and check the ontology for its contents. the idea is that there is only one field to look at to find archetype identifying information in data. It is either an archetype_id (string form) or an at-code, or (for systems that support it) it's empty / 'unknown' (which could be replaced by null/void). With the archetype id, you can always look up the archetype and find out the root code (at, or a matching pattern like at.1 or at.1.1). But if you can't look up the archetype, you are lost, and that's what the archetype_id is for. - thomas
Polishing node identifier (at-codes) use cases.
On 09/23/2013 10:38 AM, Thomas Beale wrote: > On 20/09/2013 20:40, Bert Verhees wrote: >> Op 20-9-2013 17:01, Thomas Beale schreef: >>> it's simpler than you think - we made that property mandatory so >>> that programmers would never get a null exception. >> Must have been along time ago, nowerdays, programmers have no problem >> handling a null property. > > actually, that's not quite true. It's probably the primary reason for > exceptions in object-oriented software - method call on a void object. > But I get what you are saying, and for this String field, being null > would not pose a great problem. So we could change the spec to do that. Yes, it is very easy to catch a null-exception and then do something with that information. Anyway, IMHO, specs should not solve technical problems, and they mostly don't do that. I believe this is also defined in UML. Technical problems are for implementers to solve. That is why this is a strange decision. > >> >> I wonder what the idea behind stuffing the archetype_id in the >> archetype_node_id property is? >> Here you make it harder for programmers because the archetype_id has >> another syntax in archetype-paths then the archetype_node_id has, and >> anyway, lots of other functions, and a programmer has to check the >> string-layout to find out if it is an archetype_id or an >> archetype_node_id. It also blocks the possibility to store the >> "at"-code for the root, and check the ontology for its contents. > > the idea is that there is only one field to look at to find archetype > identifying information in data. It is either an archetype_id (string > form) or an at-code, or (for systems that support it) it's empty / > 'unknown' (which could be replaced by null/void). With the archetype > id, you can always look up the archetype and find out the root code > (at, or a matching pattern like at.1 or at.1.1). But if > you can't look up the archetype, you are lost, and that's what the > archetype_id is for. The point is, the archetype_id is stored in the property archetype_node_id, Pablo implemented it like that in XML, and he found in the specs it should be that way. I think this is an unneeded complication of the specs. Better was to assign a special property for the archetype_id, besides the archetype_node_id. He found this spec in common.pdf, section 3.1.2 where is stated: "The archetype_node_id is the standardised semantic code for a node and comes from the corresponding node in the archetype used to create the data. The only exception is at archetype root points in data, where archetype_node_id carries the archetype identifier in string form rather than an interior node id from an archetype." This makes it difficult to implement, because, an implementer has to test if the archetype_node_id contains an at-code or an archetype_id. This can lead to ambiguities, for example if XML contains the archetype-slots and the connected instances are embedded, which is legal and can really speed up XPath-queries. This possibility ambiguities is special the possible because it is not really hard defined what an at-code looks at. Bert > > - thomas > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/90d53c59/attachment.html>
Polishing node identifier (at-codes) use cases.
Now the same message but the last sentence in better English :) (sorry for that) On 09/23/2013 10:38 AM, Thomas Beale wrote: > On 20/09/2013 20:40, Bert Verhees wrote: >> Op 20-9-2013 17:01, Thomas Beale schreef: >>> it's simpler than you think - we made that property mandatory so >>> that programmers would never get a null exception. >> Must have been along time ago, nowerdays, programmers have no problem >> handling a null property. > > actually, that's not quite true. It's probably the primary reason for > exceptions in object-oriented software - method call on a void object. > But I get what you are saying, and for this String field, being null > would not pose a great problem. So we could change the spec to do that. Yes, it is very easy to catch a null-exception and then do something with that information. Anyway, IMHO, specs should not solve technical problems, and they mostly don't do that. I believe this is also defined in UML. Technical problems are for implementers to solve. That is why this is a strange decision. > >> >> I wonder what the idea behind stuffing the archetype_id in the >> archetype_node_id property is? >> Here you make it harder for programmers because the archetype_id has >> another syntax in archetype-paths then the archetype_node_id has, and >> anyway, lots of other functions, and a programmer has to check the >> string-layout to find out if it is an archetype_id or an >> archetype_node_id. It also blocks the possibility to store the >> "at"-code for the root, and check the ontology for its contents. > > the idea is that there is only one field to look at to find archetype > identifying information in data. It is either an archetype_id (string > form) or an at-code, or (for systems that support it) it's empty / > 'unknown' (which could be replaced by null/void). With the archetype > id, you can always look up the archetype and find out the root code > (at, or a matching pattern like at.1 or at.1.1). But if > you can't look up the archetype, you are lost, and that's what the > archetype_id is for. The point is, the archetype_id is stored in the property archetype_node_id, Pablo implemented it like that in XML, and he found in the specs it should be that way. I think this is an unneeded complication of the specs. Better was to assign a special property for the archetype_id, besides the archetype_node_id. He found this spec in common.pdf, section 3.1.2 where is stated: "The archetype_node_id is the standardised semantic code for a node and comes from the corresponding node in the archetype used to create the data. The only exception is at archetype root points in data, where archetype_node_id carries the archetype identifier in string form rather than an interior node id from an archetype." This makes it difficult to implement, because, an implementer has to test if the archetype_node_id contains an at-code or an archetype_id. This can lead to ambiguities, for example if XML contains the archetype-slots and the connected instances are embedded, which is legal and can really speed up XPath-queries. These possible ambiguities can occur because it is not really hard defined what an at-code looks at. Bert > > - thomas > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/191eec15/attachment-0001.html>
Polishing node identifier (at-codes) use cases.
How does this 'unknown' value relate to the discussions we already had regarding the need of having all at codes present in the ontology? 2013/9/23 Thomas Beale > On 20/09/2013 20:40, Bert Verhees wrote: > >> Op 20-9-2013 17:01, Thomas Beale schreef: >> >>> it's simpler than you think - we made that property mandatory so that >>> programmers would never get a null exception. >>> >> Must have been along time ago, nowerdays, programmers have no problem >> handling a null property. >> > > actually, that's not quite true. It's probably the primary reason for > exceptions in object-oriented software - method call on a void object. But > I get what you are saying, and for this String field, being null would not > pose a great problem. So we could change the spec to do that. > > > >> I wonder what the idea behind stuffing the archetype_id in the >> archetype_node_id property is? >> Here you make it harder for programmers because the archetype_id has >> another syntax in archetype-paths then the archetype_node_id has, and >> anyway, lots of other functions, and a programmer has to check the >> string-layout to find out if it is an archetype_id or an archetype_node_id. >> It also blocks the possibility to store the "at"-code for the root, and >> check the ontology for its contents. >> > > the idea is that there is only one field to look at to find archetype > identifying information in data. It is either an archetype_id (string form) > or an at-code, or (for systems that support it) it's empty / 'unknown' > (which could be replaced by null/void). With the archetype id, you can > always look up the archetype and find out the root code (at, or a > matching pattern like at.1 or at.1.1). But if you can't look up the > archetype, you are lost, and that's what the archetype_id is for. > > - thomas > > > > __**_ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/0b0a0a68/attachment.html>
regular expressions
I have a question about the ADL-parser concerning the the
regular-expressions.
I checked page 65 in:
http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf
Can someone please explain why this fails:
value existence matches {1..1} matches {/[0-9]{1,8}/}
Error:
se.acode.openehr.parser.ParseException: Encountered " "/" "/ "" at line
186, column 57.
Was expecting:
"}" ...
Thanks very much
Bert Verhees
regular expressions
It should work, it is valid ADL
2013/9/23 Bert Verhees
> I have a question about the ADL-parser concerning the the
> regular-expressions.
>
> I checked page 65 in:
> http://www.openehr.org/**releases/1.0.2/architecture/**am/adl.pdf<http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf>
>
> Can someone please explain why this fails:
> value existence matches {1..1} matches {/[0-9]{1,8}/}
>
> Error:
> se.acode.openehr.parser.**ParseException: Encountered " "/" "/ "" at line
> 186, column 57.
> Was expecting:
> "}" ...
>
> Thanks very much
>
> Bert Verhees
>
>
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/d33770ca/attachment.html>
regular expressions
On 09/23/2013 01:29 PM, Diego Bosc? wrote:
> It should work, it is valid ADL
It works, I was using an older adl.jj, I updated it, and now it seems to
work.
Sorry for the trouble
Bert
>
>
> 2013/9/23 Bert Verhees <mailto:bert.verhees at rosa.nl>>
>
> I have a question about the ADL-parser concerning the the
> regular-expressions.
>
> I checked page 65 in:
> http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf
>
> Can someone please explain why this fails:
> value existence matches {1..1} matches {/[0-9]{1,8}/}
>
> Error:
> se.acode.openehr.parser.ParseException: Encountered " "/" "/ "" at
> line 186, column 57.
> Was expecting:
> "}" ...
>
> Thanks very much
>
> Bert Verhees
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> <mailto:openEHR-technical at lists.openehr.org>
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/d23096f5/attachment.html>
Polishing node identifier (at-codes) use cases.
rchetype_node_id. It also blocks the possibility to store the >>> "at"-code for the root, and check the ontology for its contents. >> >> the idea is that there is only one field to look at to find archetype >> identifying information in data. It is either an archetype_id (string >> form) or an at-code, or (for systems that support it) it's empty / >> 'unknown' (which could be replaced by null/void). With the archetype >> id, you can always look up the archetype and find out the root code >> (at, or a matching pattern like at.1 or at.1.1). But if >> you can't look up the archetype, you are lost, and that's what the >> archetype_id is for. > > The point is, the archetype_id is stored in the property > archetype_node_id, Pablo implemented it like that in XML, and he found > in the specs it should be that way. I think this is an unneeded > complication of the specs. Better was to assign a special property for > the archetype_id, besides the archetype_node_id. Well we thought about that a long time ago, and the view was that then you will have two fields in every LOCATABLE, one of which (hopefully) is null/void in each actual instance. This could easily lead to errors, and wastes a data property. > > He found this spec in common.pdf, section 3.1.2 where is stated: > "The archetype_node_id is the standardised semantic code for a node > and comes > from the corresponding node in the archetype used to create the data. > The only exception is at archetype > root points in data, where archetype_node_id carries the archetype > identifier in string form rather > than an interior node id from an archetype." > > This makes it difficult to implement, because, an implementer has to > test if the archetype_node_id contains an at-code or an archetype_id. > This can lead to ambiguities, for example if XML contains the > archetype-slots and the connected instances are embedded, which is > legal and can really speed up XPath-queries. This possibility > ambiguities is special the possible because it is not really hard > defined what an at-code looks at. We certainly need to make sure that the pathing in the XML expression of the specifications works as it should. I'm not sure if I understand your last statement though. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/397314d0/attachment-0001.html>
Rich text format in DV_TEXT
Hello, Actually the question is more generic, the archetype itself is not very important. What we need is to store rich-text (html from a web-editor) on a DV element. The text may include several paragraphs, and a few simple formatting tags like bold, italic, colors, etc. To my knowledge, to accomplish this the RM 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks holding necessary formatting) or alternatively DV_PARSABLE (with formalism=html). In any case not a single plain DV_TEXT. Thus, if we intend to use published archetypes on CKM (openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what is the best option: - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the right formatting ( = not an easy option to implement in our app, and also that specific archetype is not prepared for that) - specialize the archetype the so that allows also DV_PARAGRAPH or DV_PARSABLE ( = I don't think that is allowed by the owned constraints) - propose changes to RM so that DV_TEXT allows also 'simple' rich-text content, like html for instance, and not only per-word-formatting - create our own local archetypes based on CKM version, but with the 'right' DV elements ( = not a nice option considering knowledge management) - or use a single DV_TEXT, and misuse its 'value' to hold also html. Thanks, Sebastian Iancu On 9/23/2013 5:06 AM, Heather Leslie wrote: > > Hi Alessandro, > > Curious as to the use case for the DV_PARSABLE. Can you share? > > I'll let the engineers discuss potential enhancements to the datatype... > > Heather > > *From:*openEHR-technical > [mailto:openehr-technical-bounces at lists.openehr.org] *On Behalf Of > *Alessandro Torrisi > *Sent:* Friday, 20 September 2013 11:57 PM > *To:* For openEHR technical discussions > *Subject:* Rich text format in DV_TEXT > > Hello, > > we are using an archetypes from the CKM called > *openEHR-EHR-EVALUATION.clinical_synopsis.v1*. Over there is an > DV_TEXT element called *Synopsis* > > One of our clients want to use rich text format inside that field. > According the specification it is not allowed to put formatted text > over there. I rather should use a DV_PARSABLE. > > How should i handle this correctly? The options i see are : > > - specialise the archetype and add an DV_PARSABLE, and leaf the > existing DV_TEXT empty > > - create my own archetype where I set the Synopsis element to a > DV_PARSABLE > > beside this question, i wonder if it will be better to give the > DV_TEXT datatype the possibility to put over there rich text. If we > also add the parameter formalism to it, there is no really need any > more for a DV_PARSABLE. > > -- > Alessandro Torrisi > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/8287565a/attachment.html>
Rich text format in DV_TEXT
Can you elaborate a little more why do you think second option is not valid? 2013/9/23 Sebastian Iancu : > Hello, > > Actually the question is more generic, the archetype itself is not very > important. > > What we need is to store rich-text (html from a web-editor) on a DV element. > The text may include several paragraphs, and a few simple formatting tags > like bold, italic, colors, etc. To my knowledge, to accomplish this the RM > 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks holding > necessary formatting) or alternatively DV_PARSABLE (with formalism=html). In > any case not a single plain DV_TEXT. > > Thus, if we intend to use published archetypes on CKM > (openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what is > the best option: > - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the right > formatting ( = not an easy option to implement in our app, and also that > specific archetype is not prepared for that) > - specialize the archetype the so that allows also DV_PARAGRAPH or > DV_PARSABLE ( = I don't think that is allowed by the owned constraints) > - propose changes to RM so that DV_TEXT allows also 'simple' rich-text > content, like html for instance, and not only per-word-formatting > - create our own local archetypes based on CKM version, but with the 'right' > DV elements ( = not a nice option considering knowledge management) > - or use a single DV_TEXT, and misuse its 'value' to hold also html. > > Thanks, > Sebastian Iancu > > > > > On 9/23/2013 5:06 AM, Heather Leslie wrote: > > Hi Alessandro, > > > > Curious as to the use case for the DV_PARSABLE. Can you share? > > > > I?ll let the engineers discuss potential enhancements to the datatype? > > > > Heather > > > > From: openEHR-technical [mailto:openehr-technical-bounces at > lists.openehr.org] > On Behalf Of Alessandro Torrisi > Sent: Friday, 20 September 2013 11:57 PM > To: For openEHR technical discussions > Subject: Rich text format in DV_TEXT > > > > Hello, > > > > we are using an archetypes from the CKM called > openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is an DV_TEXT > element called Synopsis > > > > One of our clients want to use rich text format inside that field. According > the specification it is not allowed to put formatted text over there. I > rather should use a DV_PARSABLE. > > > > How should i handle this correctly? The options i see are : > > - specialise the archetype and add an DV_PARSABLE, and leaf the existing > DV_TEXT empty > > - create my own archetype where I set the Synopsis element to a DV_PARSABLE > > > > beside this question, i wonder if it will be better to give the DV_TEXT > datatype the possibility to put over there rich text. If we also add the > parameter formalism to it, there is no really need any more for a > DV_PARSABLE. > > > > -- > Alessandro Torrisi > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Rich text format in DV_TEXT
Trying with Archetype Editor was not possible. Besides, none on
DV_PARAGRAPH or DV_PARSABLE inherits from DV_TEXT. To make an
alternative sibling node next to DV_TEXT didn't looked right to me.
definition
EVALUATION[at] matches {-- Clinical Synopsis
data matches {
ITEM_TREE[at0001] matches {-- List
items cardinality matches {1..*; ordered} matches {
ELEMENT[at0002] matches {-- Synopsis
value matches {
DV_TEXT matches {*}
}
}
}
}
}
}
Do you have a suggestion or an example?
Sebastian
On 9/23/2013 3:00 PM, Diego Bosc? wrote:
> Can you elaborate a little more why do you think second option is not valid?
>
> 2013/9/23 Sebastian Iancu :
>> Hello,
>>
>> Actually the question is more generic, the archetype itself is not very
>> important.
>>
>> What we need is to store rich-text (html from a web-editor) on a DV element.
>> The text may include several paragraphs, and a few simple formatting tags
>> like bold, italic, colors, etc. To my knowledge, to accomplish this the RM
>> 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks holding
>> necessary formatting) or alternatively DV_PARSABLE (with formalism=html). In
>> any case not a single plain DV_TEXT.
>>
>> Thus, if we intend to use published archetypes on CKM
>> (openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what is
>> the best option:
>> - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the right
>> formatting ( = not an easy option to implement in our app, and also that
>> specific archetype is not prepared for that)
>> - specialize the archetype the so that allows also DV_PARAGRAPH or
>> DV_PARSABLE ( = I don't think that is allowed by the owned constraints)
>> - propose changes to RM so that DV_TEXT allows also 'simple' rich-text
>> content, like html for instance, and not only per-word-formatting
>> - create our own local archetypes based on CKM version, but with the 'right'
>> DV elements ( = not a nice option considering knowledge management)
>> - or use a single DV_TEXT, and misuse its 'value' to hold also html.
>>
>> Thanks,
>> Sebastian Iancu
>>
>>
>>
>>
>> On 9/23/2013 5:06 AM, Heather Leslie wrote:
>>
>> Hi Alessandro,
>>
>>
>>
>> Curious as to the use case for the DV_PARSABLE. Can you share?
>>
>>
>>
>> I?ll let the engineers discuss potential enhancements to the datatype?
>>
>>
>>
>> Heather
>>
>>
>>
>> From: openEHR-technical [mailto:openehr-technical-bounces at
>> lists.openehr.org]
>> On Behalf Of Alessandro Torrisi
>> Sent: Friday, 20 September 2013 11:57 PM
>> To: For openEHR technical discussions
>> Subject: Rich text format in DV_TEXT
>>
>>
>>
>> Hello,
>>
>>
>>
>> we are using an archetypes from the CKM called
>> openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is an DV_TEXT
>> element called Synopsis
>>
>>
>>
>> One of our clients want to use rich text format inside that field. According
>> the specification it is not allowed to put formatted text over there. I
>> rather should use a DV_PARSABLE.
>>
>>
>>
>> How should i handle this correctly? The options i see are :
>>
>> - specialise the archetype and add an DV_PARSABLE, and leaf the existing
>> DV_TEXT empty
>>
>> - create my own archetype where I set the Synopsis element to a DV_PARSABLE
>>
>>
>>
>> beside this question, i wonder if it will be better to give the DV_TEXT
>> datatype the possibility to put over there rich text. If we also add the
>> parameter formalism to it, there is no really need any more for a
>> DV_PARSABLE.
>>
>>
>>
>> --
>> Alessandro Torrisi
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
SV: Rich text format in DV_TEXT
This is a very relevant issue. We have the same in our application. Some of the fields will be DV_TEXT but we want to show some rich formatting. It is crucial to be compatible with Archetypes from CKM, and different vendors producing or consuming Archetypes. So it is not an option to make changes on the Archetype. Just as you tell. We did not find any workarounds. So any good idea or proposal is very welcome. Vennlig hilsen Bj?rn N?ss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10 Opprinnelig melding Fra: Sebastian Iancu Dato: 23.09.2013 14.57 (GMT+01:00) Til: For openEHR technical discussions Emne: Re: Rich text format in DV_TEXT Hello, Actually the question is more generic, the archetype itself is not very important. What we need is to store rich-text (html from a web-editor) on a DV element. The text may include several paragraphs, and a few simple formatting tags like bold, italic, colors, etc. To my knowledge, to accomplish this the RM 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks holding necessary formatting) or alternatively DV_PARSABLE (with formalism=html). In any case not a single plain DV_TEXT. Thus, if we intend to use published archetypes on CKM (openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what is the best option: - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the right formatting ( = not an easy option to implement in our app, and also that specific archetype is not prepared for that) - specialize the archetype the so that allows also DV_PARAGRAPH or DV_PARSABLE ( = I don't think that is allowed by the owned constraints) - propose changes to RM so that DV_TEXT allows also 'simple' rich-text content, like html for instance, and not only per-word-formatting - create our own local archetypes based on CKM version, but with the 'right' DV elements ( = not a nice option considering knowledge management) - or use a single DV_TEXT, and misuse its 'value' to hold also html. Thanks, Sebastian Iancu On 9/23/2013 5:06 AM, Heather Leslie wrote: Hi Alessandro, Curious as to the use case for the DV_PARSABLE. Can you share? I?ll let the engineers discuss potential enhancements to the datatype? Heather From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Alessandro Torrisi Sent: Friday, 20 September 2013 11:57 PM To: For openEHR technical discussions Subject: Rich text format in DV_TEXT Hello, we are using an archetypes from the CKM called openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is an DV_TEXT element called Synopsis One of our clients want to use rich text format inside that field. According the specification it is not allowed to put formatted text over there. I rather should use a DV_PARSABLE. How should i handle this correctly? The options i see are : - specialise the archetype and add an DV_PARSABLE, and leaf the existing DV_TEXT empty - create my own archetype where I set the Synopsis element to a DV_PARSABLE beside this question, i wonder if it will be better to give the DV_TEXT datatype the possibility to put over there rich text. If we also add the parameter formalism to it, there is no really need any more for a DV_PARSABLE. -- Alessandro Torrisi ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/2063f598/attachment-0001.html>
Rich text format in DV_TEXT
Hi Sebastian, This is a good summary of the alternatives. As I understand things the use of DV_PARAGRAPH is how this sort of rich-text markup was intended to be supported but I agree that it seems pretty tricky to implement. One other alternative approach would be to carry the stripped down 'raw text in the DV_TEXT value, with the HTML in the feeder_audit/original_context attribute (from LOCATABLE). It would still be interesting and useful to better understand the specific use-case for "Clinical synopsis" - will the markup be restricted to formatting and perhaps linking, or do you envisage there being further processable content within the HTML, which takes us more into the realm of CDA-style 'narrative block' markup? and where I think DV_PARSABLE is more appropriate. Whilst the idea of a multi-purpose Text datatype that can handle anything from plain text through to xml or json seems technically attractive, we have to be conscious of downstream systems being able to correctly display the maneing of the text and not inadvertantly hiding important content / context within the non-textual parts of a parsable string. Ian On 23 September 2013 13:56, Sebastian Iancu wrote: > Hello, > > Actually the question is more generic, the archetype itself is not very > important. > > What we need is to store rich-text (html from a web-editor) on a DV element. > The text may include several paragraphs, and a few simple formatting tags > like bold, italic, colors, etc. To my knowledge, to accomplish this the RM > 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks holding > necessary formatting) or alternatively DV_PARSABLE (with formalism=html). In > any case not a single plain DV_TEXT. > > Thus, if we intend to use published archetypes on CKM > (openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what is > the best option: > - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the right > formatting ( = not an easy option to implement in our app, and also that > specific archetype is not prepared for that) > - specialize the archetype the so that allows also DV_PARAGRAPH or > DV_PARSABLE ( = I don't think that is allowed by the owned constraints) > - propose changes to RM so that DV_TEXT allows also 'simple' rich-text > content, like html for instance, and not only per-word-formatting > - create our own local archetypes based on CKM version, but with the 'right' > DV elements ( = not a nice option considering knowledge management) > - or use a single DV_TEXT, and misuse its 'value' to hold also html. > > Thanks, > Sebastian Iancu > > > > > On 9/23/2013 5:06 AM, Heather Leslie wrote: > > Hi Alessandro, > > > > Curious as to the use case for the DV_PARSABLE. Can you share? > > > > I?ll let the engineers discuss potential enhancements to the datatype? > > > > Heather > > > > From: openEHR-technical [mailto:openehr-technical-bounces at > lists.openehr.org] > On Behalf Of Alessandro Torrisi > Sent: Friday, 20 September 2013 11:57 PM > To: For openEHR technical discussions > Subject: Rich text format in DV_TEXT > > > > Hello, > > > > we are using an archetypes from the CKM called > openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is an DV_TEXT > element called Synopsis > > > > One of our clients want to use rich text format inside that field. According > the specification it is not allowed to put formatted text over there. I > rather should use a DV_PARSABLE. > > > > How should i handle this correctly? The options i see are : > > - specialise the archetype and add an DV_PARSABLE, and leaf the existing > DV_TEXT empty > > - create my own archetype where I set the Synopsis element to a DV_PARSABLE > > > > beside this question, i wonder if it will be better to give the DV_TEXT > datatype the possibility to put over there rich text. If we also add the > parameter formalism to it, there is no really need any more for a > DV_PARSABLE. > > > > -- > Alessandro Torrisi > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- 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 openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org
Rich text format in DV_TEXT
e rich text format inside that field. >>> According >>> the specification it is not allowed to put formatted text over there. I >>> rather should use a DV_PARSABLE. >>> >>> >>> >>> How should i handle this correctly? The options i see are : >>> >>> - specialise the archetype and add an DV_PARSABLE, and leaf the existing >>> DV_TEXT empty >>> >>> - create my own archetype where I set the Synopsis element to a >>> DV_PARSABLE >>> >>> >>> >>> beside this question, i wonder if it will be better to give the DV_TEXT >>> datatype the possibility to put over there rich text. If we also add the >>> parameter formalism to it, there is no really need any more for a >>> DV_PARSABLE. >>> >>> >>> >>> -- >>> Alessandro Torrisi >>> >>> >>> >>> __**_ >>> openEHR-technical mailing list >>> openEHR-technical at lists.**openehr.org>> lists.openehr.org> >>> http://lists.openehr.org/**mailman/listinfo/openehr-** >>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >>> >>> >>> __**_ >>> openEHR-technical mailing list >>> openEHR-technical at lists.**openehr.org>> lists.openehr.org> >>> http://lists.openehr.org/**mailman/listinfo/openehr-** >>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >> __**_ >> openEHR-technical mailing list >> openEHR-technical at lists.**openehr.org> lists.openehr.org> >> http://lists.openehr.org/**mailman/listinfo/openehr-** >> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> > > > __**_ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/6fb01ca9/attachment.html>
Rich text format in DV_TEXT
ows also > 'simple' rich-text > content, like html for instance, and not only > per-word-formatting > - create our own local archetypes based on CKM version, > but with the 'right' > DV elements ( = not a nice option considering knowledge > management) > - or use a single DV_TEXT, and misuse its 'value' to hold > also html. > > Thanks, > Sebastian Iancu > > > > > On 9/23/2013 5:06 AM, Heather Leslie wrote: > > Hi Alessandro, > > > > Curious as to the use case for the DV_PARSABLE. Can you share? > > > > I'll let the engineers discuss potential enhancements to > the datatype... > > > > Heather > > > > From: openEHR-technical > [mailto:openehr-technical-bounces at lists.openehr.org > <mailto:openehr-technical-bounces at lists.openehr.org>] > On Behalf Of Alessandro Torrisi > Sent: Friday, 20 September 2013 11:57 PM > To: For openEHR technical discussions > Subject: Rich text format in DV_TEXT > > > > Hello, > > > > we are using an archetypes from the CKM called > openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is > an DV_TEXT > element called Synopsis > > > > One of our clients want to use rich text format inside > that field. According > the specification it is not allowed to put formatted text > over there. I > rather should use a DV_PARSABLE. > > > > How should i handle this correctly? The options i see are : > > - specialise the archetype and add an DV_PARSABLE, and > leaf the existing > DV_TEXT empty > > - create my own archetype where I set the Synopsis element > to a DV_PARSABLE > > > > beside this question, i wonder if it will be better to > give the DV_TEXT > datatype the possibility to put over there rich text. If > we also add the > parameter formalism to it, there is no really need any > more for a > DV_PARSABLE. > > > > -- > Alessandro Torrisi > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/11c12eb6/attachment-0001.html>
Rich text format in DV_TEXT
On 9/23/2013 3:29 PM, Ian McNicoll wrote: > Hi Sebastian, > > This is a good summary of the alternatives. As I understand things the > use of DV_PARAGRAPH is how this sort of rich-text markup was intended > to be supported but I agree that it seems pretty tricky to implement. Tricky, especially when formats were wrongly applied: like here, formatting not matching words boundaries will break the meaning of text stored in DV_TEXT. > One other alternative approach would be to carry the stripped down > 'raw text in the DV_TEXT value, with the HTML in the > feeder_audit/original_context attribute (from LOCATABLE). That comes also with an additional data costs, and syncing issues upon re-editing. > It would still be interesting and useful to better understand the > specific use-case for "Clinical synopsis" - will the markup be > restricted to formatting and perhaps linking, or do you envisage there > being further processable content within the HTML, which takes us more > into the realm of CDA-style 'narrative block' markup? and where I > think DV_PARSABLE is more appropriate. At this time not, just a few simple html formatting tags, to allow end user to highlight some parts of the text which might be important for the reader. > Whilst the idea of a multi-purpose Text datatype that can handle > anything from plain text through to xml or json seems technically > attractive, we have to be conscious of downstream systems being able > to correctly display the maneing of the text and not inadvertantly > hiding important content / context within the non-textual parts of a > parsable string. For me xml/json is more structured data rather than TEXT; a DV_PARSABLE is be more suitable for that. > Ian > > > > > > On 23 September 2013 13:56, Sebastian Iancu wrote: >> Hello, >> >> Actually the question is more generic, the archetype itself is not very >> important. >> >> What we need is to store rich-text (html from a web-editor) on a DV element. >> The text may include several paragraphs, and a few simple formatting tags >> like bold, italic, colors, etc. To my knowledge, to accomplish this the RM >> 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks holding >> necessary formatting) or alternatively DV_PARSABLE (with formalism=html). In >> any case not a single plain DV_TEXT. >> >> Thus, if we intend to use published archetypes on CKM >> (openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what is >> the best option: >> - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the right >> formatting ( = not an easy option to implement in our app, and also that >> specific archetype is not prepared for that) >> - specialize the archetype the so that allows also DV_PARAGRAPH or >> DV_PARSABLE ( = I don't think that is allowed by the owned constraints) >> - propose changes to RM so that DV_TEXT allows also 'simple' rich-text >> content, like html for instance, and not only per-word-formatting >> - create our own local archetypes based on CKM version, but with the 'right' >> DV elements ( = not a nice option considering knowledge management) >> - or use a single DV_TEXT, and misuse its 'value' to hold also html. >> >> Thanks, >> Sebastian Iancu >> >> >> >> >> On 9/23/2013 5:06 AM, Heather Leslie wrote: >> >> Hi Alessandro, >> >> >> >> Curious as to the use case for the DV_PARSABLE. Can you share? >> >> >> >> I?ll let the engineers discuss potential enhancements to the datatype? >> >> >> >> Heather >> >> >> >> From: openEHR-technical [mailto:openehr-technical-bounces at >> lists.openehr.org] >> On Behalf Of Alessandro Torrisi >> Sent: Friday, 20 September 2013 11:57 PM >> To: For openEHR technical discussions >> Subject: Rich text format in DV_TEXT >> >> >> >> Hello, >> >> >> >> we are using an archetypes from the CKM called >> openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is an DV_TEXT >> element called Synopsis >> >> >> >> One of our clients want to use rich text format inside that field. According >> the specification it is not allowed to put formatted text over there. I >> rather should use a DV_PARSABLE. >> >> >> >> How should i handle this correctly? The options i see are : >> >> - specialise the archetype and add an DV_PARSABLE, and leaf the existing >> DV_TEXT empty >> >> - create my own archetype where I set the Synopsis element to a DV_PARSABLE >> >> >> >> beside this question, i wonder if it will be better to give the DV_TEXT >> datatype the possibility to put over there rich text. If we also add the >> parameter formalism to it, there is no really need any more for a >> DV_PARSABLE. >> >> >> >> -- >> Alessandro Torrisi >> >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at lists.open
Rich text format in DV_TEXT
I would advise against putting markup directly in DV_TEXT.value - that
will surely led to non-interoperable data. I would suggest using
DV_PARSABLE, with the XML or HTML you want.
However the problem here is that the parent clinical_synopsis archetype
on CKM has this definition:
ELEMENT[at0002] matches {-- Synopsis
value matches {
DV_TEXT matches {*}
}
}
This is too narrow, since DV_PARSABLE does not inherit from DV_TEXT, but
is likely to be needed for situations requiring formatting. Ideally this
archetype in CKM would be upgraded to include DV_PARSABLE as an
alternative.
That's the solution within the current RM. It is debatable whether we
shouldn't fix the text cluster in the RM, so that there is a clearer way
of doing a) paragraphs and b) formatting. I believe we still need to
retain the atomic idea of a DV_TEXT as something containing no
formatting, and yet being minimally boldable / emphasised in the rendering.
We have had some discussions before on this, which I myself would need
to dig up to remember previous conclusions. But as we are about to enter
into a phase of RM revision we can certainly contemplate the kind of
updates we want.
I would suggest (without having done sufficient analysis - just thinking
out loud here) that we may need types like:
DATA_VALUE*
*
* *DV_TEXT* (abstract)
o <- DV_SIMPLE_TEXT (includes simple formatting + URL, that
applies to whole atom)
+ <- *DV_CODED_TEXT* -- coded term
+ <- DV_PLAIN_TEXT -- can only be plain text
o <- DV_FORMATTED_TEXT -- take care of paragraphs and formatting;
works like a DV_PARSABLE
The bolded types are RM 1.0.2 types. We can get very close to doing the
above and retaining backward compataibility for DV_TEXT and
DV_CODED_TEXT data.
If we want perfect backward compatibility, we would need to do the
following:
DATA_VALUE*
*
* DV_TEXT_ITEM (abstract)
o <- *DV_TEXT *(includes simple formatting + URL, that applies to
whole atom)
+ <- *DV_CODED_TEXT* -- coded term
+ <- DV_PLAIN_TEXT -- can only be plain text
o <- DV_FORMATTED_TEXT -- take care of paragraphs and formatting;
works like a DV_PARSABLE
We need to do a proper analysis on this in the upcoming revision, and I
suggest a change along these lines would go into release 1.0.3. Then
the current clinical synopsis archetype would in fact be correct!
BTW, I'm not in favour of any solution in which plain text and formatted
text replicate each others' content (see why
<http://wolandscat.net/2012/01/28/the-cda-dual-content-conundrum/>).
hope this helps. We'll be getting started on release 1.0.3 in the next
couple of weeks, so look out for announcements.
- thomas
On 23/09/2013 14:29, Ian McNicoll wrote:
> Hi Sebastian,
>
> This is a good summary of the alternatives. As I understand things the
> use of DV_PARAGRAPH is how this sort of rich-text markup was intended
> to be supported but I agree that it seems pretty tricky to implement.
>
> One other alternative approach would be to carry the stripped down
> 'raw text in the DV_TEXT value, with the HTML in the
> feeder_audit/original_context attribute (from LOCATABLE).
>
> It would still be interesting and useful to better understand the
> specific use-case for "Clinical synopsis" - will the markup be
> restricted to formatting and perhaps linking, or do you envisage there
> being further processable content within the HTML, which takes us more
> into the realm of CDA-style 'narrative block' markup? and where I
> think DV_PARSABLE is more appropriate.
>
> Whilst the idea of a multi-purpose Text datatype that can handle
> anything from plain text through to xml or json seems technically
> attractive, we have to be conscious of downstream systems being able
> to correctly display the maneing of the text and not inadvertantly
> hiding important content / context within the non-textual parts of a
> parsable string.
>
> Ian
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/64402208/attachment.html>
Rich text format in DV_TEXT
Thanks Sebastian,
I think we agree that there is a important difference between
formatted text which can gracefully degrade to plain text without loss
of meaning, and text where significant semantics are carried in the
markup, and where there will be clinical safety issues if the markup
is lost.
It is certainly possible to adapt the current archetype to allow something like
definition
EVALUATION[at] matches { -- Clinical Synopsis
data matches {
ITEM_TREE[at0001] matches { -- List
items cardinality matches {1..*; ordered} matches {
ELEMENT[at0002] matches { -- Synopsis
value matches {
DV_TEXT matches {*}
DV_PARSABLE matches {
formalism matches {"text/html", "text/rtf", "text/plain"}
}
as you said the specialisation is not possible since it widens the
datatypes allowed by the parent constraint.
I am not too keen on adding DV_PARSABLE multi-attribute values since,
as everyone agrees, almost every 'narrative-style' DV_TEXT element in
every archetype might reasonably need to be changed.
Although I appreciate the extra overhead of carrying the original HTML
in feeder_audit, I think this is the most sensible workaround for now,
and we should concentrate on reviewing DV_TEXT and its cousins as
Thomas has suggested.
Ian
On 23 September 2013 15:19, Sebastian Iancu wrote:
> On 9/23/2013 3:29 PM, Ian McNicoll wrote:
>>
>> Hi Sebastian,
>>
>> This is a good summary of the alternatives. As I understand things the
>> use of DV_PARAGRAPH is how this sort of rich-text markup was intended
>> to be supported but I agree that it seems pretty tricky to implement.
>
> Tricky, especially when formats were wrongly applied: like
> here, formatting not matching words boundaries will break the meaning
> of text stored in DV_TEXT.
>
>> One other alternative approach would be to carry the stripped down
>> 'raw text in the DV_TEXT value, with the HTML in the
>> feeder_audit/original_context attribute (from LOCATABLE).
>
> That comes also with an additional data costs, and syncing issues upon
> re-editing.
>
>> It would still be interesting and useful to better understand the
>> specific use-case for "Clinical synopsis" - will the markup be
>> restricted to formatting and perhaps linking, or do you envisage there
>> being further processable content within the HTML, which takes us more
>> into the realm of CDA-style 'narrative block' markup? and where I
>> think DV_PARSABLE is more appropriate.
>
> At this time not, just a few simple html formatting tags, to allow end user
> to highlight some parts of the text which might be important for the reader.
>
>> Whilst the idea of a multi-purpose Text datatype that can handle
>> anything from plain text through to xml or json seems technically
>> attractive, we have to be conscious of downstream systems being able
>> to correctly display the maneing of the text and not inadvertantly
>> hiding important content / context within the non-textual parts of a
>> parsable string.
>
> For me xml/json is more structured data rather than TEXT; a DV_PARSABLE is
> be more suitable for that.
>
>> Ian
>>
>>
>>
>>
>>
>> On 23 September 2013 13:56, Sebastian Iancu wrote:
>>>
>>> Hello,
>>>
>>> Actually the question is more generic, the archetype itself is not very
>>> important.
>>>
>>> What we need is to store rich-text (html from a web-editor) on a DV
>>> element.
>>> The text may include several paragraphs, and a few simple formatting tags
>>> like bold, italic, colors, etc. To my knowledge, to accomplish this the
>>> RM
>>> 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks
>>> holding
>>> necessary formatting) or alternatively DV_PARSABLE (with formalism=html).
>>> In
>>> any case not a single plain DV_TEXT.
>>>
>>> Thus, if we intend to use published archetypes on CKM
>>> (openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what
>>> is
>>> the best option:
>>> - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the
>>> right
>>> formatting ( = not an easy option to implement in our app, and also that
>>> specific archetype is not prepared for that)
>>> - specialize the archetype the so that allows also DV_PARAGRAPH or
>>> DV_PARSABLE ( = I don't think that is allowed by the owned constraints)
>>> - propose changes to RM so that DV_TEXT allows also 'simple' rich-text
>>> content, like html for instance, and not only per-word-formatting
>>> - create our own local archetypes based on CKM version, but with the
>>> 'right'
>>> DV elements ( = not a nice option considering knowledge management)
>>> - or use a single DV_TEXT, and misuse its 'value' to hold also html.
>>>
>>> Thanks,
>>> Sebastian Iancu
>>>
>>>
>>>
>>>
>>> On 9/23/2013 5:06 AM, Heather Leslie wrote:
>>>
>>> Hi Alessandro,
>>>
>>>
>>>
>>> Curious as to the use case for the DV_PARSABLE. Can you share?
>>>
>>>
>>>
>>> I?ll let the engineers discuss potential enhancements to the datatype?
>>>
>>>
>>>
>>> Heather
>>>
>>>
>>>
>>> From:
