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[at0000] 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 <sebastian at code24.nl>:
>> 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
