Hi Diego,
When it comes down to trusted ADL tooling I'm always a bit lost. Which
one have you used? I tried to specialize original archetype with AE an
than validating with ADL Workbench (both latest version). My ADL was
definition
EVALUATION[at0000.1] matches { -- Clinical Synopsis!
data matches {
ITEM_TREE[at0001] matches { -- List
items cardinality matches {1..*; ordered} matches {
ELEMENT[at0002.1] matches { -- ! - Synopsis
value matches {
DV_TEXT matches {*}
DV_PARSABLE matches {*}
}
}
}
}
}
}
and I get
ERROR (VSONCT) object node at path /data[at0001]/items[at0002.1|! -
Synopsis|]/value (RM type DV_PARSABLE) does not conform to node at
parent path /data[at0001]/items[at0002]/value RM type DV_TEXT
which I can agree with.
Your code looks a bit different; it might be valid, but it is not a
specialization on original one, isn't it?
Thanks,
Sebastian
On 9/23/2013 3:30 PM, Diego Bosc? wrote:
> This is valid ADL
>
> definition
> EVALUATION[at0000] occurrences matches {1..1} matches { --
> Clinical synopsis
> data existence matches {1..1} matches {
> ITEM_TREE[at0001] occurrences matches {0..1} matches { --
> ITEM_TREE
> items existence matches {0..1} cardinality matches
> {0..*; unordered; unique} matches {
> ELEMENT[at0002] occurrences matches {0..*} matches
> { -- ELEMENT
> value existence matches {0..1} matches {
> DV_TEXT[at0003] occurrences matches {0..1}
> matches {*} -- DV_TEXT
> DV_PARSABLE[at0004] occurrences matches
> {0..1} matches {*} -- DV_PARSABLE
> }
> }
> }
> }
> }
> }
>
> Or even as an specialized archetype
>
> Im?genes integradas 1
>
>
> Im?genes integradas 2
>
>
>
> 2013/9/23 Sebastian Iancu <sebastian at code24.nl
> <mailto:sebastian at code24.nl>>
>
> 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
> <mailto: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
> <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>
