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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/fd52bdb8/attachment-0001.html>
