On 14/05/2014 10:05, Bert Verhees wrote:
> It should not be focused on OpenEHR, I guess many more
> modeling-systems (not only two level) can have same situations, but I
> guess developers have caught most of them. But since this is an
> OpenEHR-list, and I run against this problem in an OpenEHR kernel, I
> discuss it in the context of OpenEHR.
>
>
> On 14-05-14 03:04, pablo pazos wrote:
>> Hi Bert,
>>
>> why the validator should need to continue traversing the instance?
>>
>>
>> Hi Pablo, because in the attributes are often also complex OpenEhr
>> datatypes, so the validator needs to check these complex data types
>> in the attributes too, and those datatypes again can have complex
>> datatypes. In case of this example: Dv_Text matches {*} you'll need
>> to check everything, every structure, until you reach the leaf nodes,
>> which, in this example can be anything. Only then, you can be sure
>> that the data set is OpenEhr compliant.
>>
>> That was my point :) The validation that needs to reach leaf nodes is
>> not the archetype validation, but the IM structure validation. That
>> has nothing to do with the open constraint {*} in the archetype. In
>> fact, that validation can be done completely without considering the
>> archetype. What I said about using the XSD is just one way of
>> implementation, you can do that by code also.
> This, I do not agree, an archetype constraints the structure of a
> dataset, and it constraints the contents of a leafnode. The archetype
> constraints, IMHO, which class-attributes are to be used, and
> what/where they will lead to.
> Of course the archetype is modeled inside the boundaries of the
> reference model (possible expressed in XSD), so that is always
> something that has to fit.
> If there are no constraints in an archetype (wildcarded) then
> everything, which is possible in the reference model, is legal in a
> dataset.
Both of these statements are correct I guess, but I would suggest that
what Pablo is saying is usable at a practical level. We could in theory
(and I remember thinking about doing this 10 eras ago) add an invariant
to the DV_TEXT class of the form:
context DV_TEXT
mappings.for_all (m: TERM_MAPPING | m.purpose /= self)
This invariant would be expressible in e.g. OCL and maybe even
Schematron, and could be evaluated completely independently from the
archetype level validation. Admittedly these kind of checks are not
routinely built into programming languages or XML, so you have to go to
some effort to implement them. But it is certainly doable, and I would
say this kind of check would belong in a small library of data
validation checks that are executed in various passes over the data,
with the archetype checks coming later than more basic checks.
I would recommend a 2 or 3 pass validator. It's tempting to try to do
everything in one pass, and it may be more efficient, but it's much
harder to get the logic right.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140514/7aae1841/attachment-0001.html>
