Thanks Ian,
Just to clear out few things:
- I was not intending to go for a specialized synopsis, but for a
completely new local (offline) archetype with similar structure and
meaning;
- I know that is not good for CKM usage, but it is a workaround for us
until RM will be fixed;
- it is clear for me that a change (by adding PARSABLE) on archetypes
from CKM is not elegant and neither sustainable on long term (as more
archetype may need to suffer the same);
- off course we can move this discussion to CKM, but I think the things
are clear for now, and it is anyway more related to RM than to archetypes.
Sebastian
On 9/24/2013 12:03 PM, Ian McNicoll wrote:
> Hi Sebastian,
>
> In that case you will need to create a specialisation with a new
> element to hold the parsable text. I am interested in knowing from
> other implementers whether there is a strong case for adding this to
> the current 'official' archetype.
>
> This could be done as a revision i.e backwardly compatible. We could
> also add DV_PARSABLE to the current Synposis element as a 'datatype
> choice' but I am pretty sure this would require us to create a new
> version 2 archetype, for the same reasons that this is not possible to
> do as a specialisation, which would not be backward compatible.
>
> The real solution is, I think we agree, to handle this in the RM so I
> am reluctant to mess about too much with the existing archetype but if
> there is a strong demand for immediate changes from implementers, we
> have to take that seriously, even if it feels like a bit of a
> temporary hack.
>
> I would be interested to know from others whether you agree with
> Sebastian's approach, or whether my suggestion to use the existing
> feeder_audit/original_content attribute is an acceptable workaround.
>
> Also, I would like to start to move this conversation on the CKM
> discussion space for clinical _synopsis, so that we can document
> thoughts and approaches there for future reference. Any objections?
>
> Ian
>
>
>
> On 24 September 2013 10:13, Sebastian Iancu <sebastian at code24.nl> wrote:
>> Thank you all for your feedback.
>> It was good to see the same concern on others (facing similar problems), the
>> suggested workarounds and the openness of addressing this on an upcoming RM
>> change.
>>
>> In the mean time I'm more in favor of using locally modified archetypes,
>> that allows PARSABLE alternative to TEXT. We only need this on a few
>> archetypes (at this time), and we anyway need to change them later again as
>> soon as the new RM is released.
>>
>> Sebastian
>>
>>
>> On 9/23/2013 7:28 PM, Ian McNicoll wrote:
>>> 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[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 {*}
>>> 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 <sebastian at code24.nl> 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: <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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>
>
