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: <b>lik</b>e
he<i>re</i>, 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 <sebastian at code24.nl> 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
>
>
