OPT = Operational Template - it's the fully compiled version of a
template. See the Template Designer
<http://www.openehr.org/downloads/modellingtools> for this - it
generates them. Or else you can just do a fully flattened template in
the ADL 1.5 workbench. I can provide details on this if you need.
- thomas
On 16/05/2014 09:28, Bert Verhees wrote:
> On 16-05-14 03:55, pablo pazos wrote:
>> I mentioned the phases, several times, in my previous messages :)
>>
>> Maybe Thomas can break that up into more phases.
>
> On 16-05-14 09:16, Thomas Beale wrote:
>> I think Pablo has summarised some useful things:
>>
>> * validate based on OPTs - this is a must; it's based on the fact
>> that all your data are _templated_, not just archetyped
>> * RM validation pass - you could detect pathological structures at
>> this point
>> * archetype (OPT) pass
>>
>> Nobody should feel bad about having to experiment a bit here. There's
>> no standard answer yet.
>
>
> I agree that there is no standard answer, and there will never be one.
> There will always be technical progress. That keeps us, developers, at
> work. ;-)
>
> I wish more people would discuss their technical working out of the
> standards, so we can learn.
> ----
> I am not familiar with the term "OPT". I assume, this is opt-out. As
> Pablo gave an example, if some has a DV_TEXT in an archetype, he does
> not want a DV_CODED_TEXT at that point.
>
> I agree partly with this. But only if the DV_TEXT is not wildcarded.
> If it has an attribute mentioned in the archetype:
> DV_TEXT matches { value matches {*} }.
> Then there can come nothing but a value-attribute which is a
> constrained string, in this case, without constraints. (and if
> applicable, other required attributes also)
>
> But if in the archetype is DV_TEXT matches {*} then every attribute is
> allowed to use, and it is allowed to derive inheritors from DV_TEXT,
> which is DV_CODED_TEXT.
>
> I had this discussion some years ago, at that time you agreed that
> inheritance is allowed, according to the standard.
> http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007041.html
>
> Divergence from the theoretical standard on technical/practical
> reasons makes code in the context of that standard less flexible and
> less extensible and once diverged code leads to more divergence. It
> maybe can even lead to another standard on new premiss, of which I
> know an example. But as they say in Fawlty Towers: Never mention the
> war ;-)
>
> If I misunderstood the term OPTs, please forgive me, it was not with
> rhetorical intention.
> ------
> The RM-validation pass is very easy in code. Just check it against the
> RM-XSD and let it roll.
>
> Maybe we are not aware, because everything happens in a library. There
> may be a performance issue.
> Will it be more efficient to check before, what you are checking
> anyway afterwards?
>
> Also you do not detect all pathological structures, because the one I
> mentioned is perfectly legal in the RM, when DV_TEXT matches {*} is in
> the archetype. That makes this example dangerous, it is not possible
> to detect by a basic RM-check. But you can find other problems, and
> have a quick way out. That is true.
>
> The punishment is for data-sets which are valid, they need more
> processor-time to get accepted.
> ------
> I don't understand what is meant with "archetype (OPT) pass", so I
> cannot comment on that.
> -----
> The one pass situation: the logical path through an archetype is very
> hierarchical and very easy.
> It is a kind of classical visitor-pattern which is followed, but, in
> my case, without unnecessary formalities.
>
> I have rewritten the AOM validation-interpretation three times, every
> time to create an XML-validation.
> First for XML-Schema, then for RelaxNG, both combined with Schematron.
> XML-schema and RelaxNG have shortcomings which are trouble in relation
> to the features of the AOM/ADL. Some developers have written
> workarounds for that. But that is divergence of the standards.
>
> Now I have rewritten it for schematron-only. But the base-structure
> remained the same, just the simple one-pass validation. Schematron
> seems to be the best way, for now. The asserts are sorted to the
> context, so all tests for a specific node will be done in one group.
> This avoids, at validation-time, repeated retrieval of nodes, by the
> XML-interpreter.
>
> By the way, I have a basic RM-check in my validator, I have converted
> the XSD's to Schematron, which is not hard to do. I use it to check
> for existence of required attributes, which are not in the archetype,
> and check for valid inheritance. But this basic RM validator runs in
> the same one-pass validation.
>
> Thanks.
> Bert
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ocean Informatics <http://www.oceaninformatics.com/> *Thomas Beale
Chief Technology Officer*
+44 7792 403 613 Specification Program, /open/EHR
<http://www.openehr.org/>
Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/>
Health IT blog <http://wolandscat.net/category/health-informatics/>
View Thomas Beale's profile on LinkedIn
<http://uk.linkedin.com/in/thomasbeale>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/1cc2a489/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 4085 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/1cc2a489/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: btn_liprofile_blue_80x15.png
Type: image/png
Size: 511 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/1cc2a489/attachment.png>
