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.
The thing is that a DvText can have the attribute: mappings and
then can find a the attribute: purpose, of type DvCodedText, which again
can have an attribute: mappings, which can again have an attribute:
purpose, etc.
So, the occurrence of the leafnode can be far away, and still be compliant
with the statement: DvText matches {*}, and a 100% compliant validator
will need to follow al these steps. Of course this is not a normal
situation, but it can happen. As said, we cannot always control incoming
data sets. There maybe buggy software in the ecosystem where a kernel runs.
To be safe and with feasibility in mind, a validator would need to stop
validating, at some arbitrary point, although there is no error. So a
validator which follow the rules for 100% is dangerous! it can crash a
system.
That was my point.
You are right in your statement, that when a part of an archetype is
wildcarded, the XSD is the place where to find the validation rules.
Best regards
Bert
Op dinsdag 13 mei 2014 heeft pablo pazos <pazospablo at hotmail.com> het
volgende geschreven:
> Hi Bert, I'll clarify because what you interpreted is not what I tried to
> say, but we're on the same page.
>
>
> > Date: Tue, 13 May 2014 08:47:35 +0200
> > From: bert.verhees at rosa.nl<javascript:_e(%7B%7D,'cvml','bert.verhees at
> > rosa.nl');>
> > To: openehr-technical at
> > lists.openehr.org<javascript:_e(%7B%7D,'cvml','openehr-technical at
> > lists.openehr.org');>
> > Subject: Re: Cyclic datatypes: OpenEHR virus
> >
> > On 13-05-14 07:22, Ing. Pablo Pazos wrote:
> > > If the value is not constrained, the validator should return true
> without continuing checking in cascade-recursive mode. For this to work as
> expected, the data structure should be validated before than the data
> validation. The easiest way of validating the structure is serializing the
> instance to XML and using XSD.
> >
> > That is the problem, I do not agree, it has to check in cascade because
> > there can be required properties left out, or fantasized properties
> > which make no sense put in. Every occurring class in a dataset needs, in
> > my opinion, to be validated, if there are no constraints, against the
> > Reference Model-rules.
>
> What I meant with "structure validation" is to validate against the IM
> (i.e. syntactic validation), when I say "data validation" I mean to
> validate against archetypes (i.e. semantic validation).
>
> If the constraint over a node is "not constrained at all", so there are
> not required values defined by the archetype, but, there might be required
> values defined by the information model.
>
> >
> > By the way, you cannot validate OpenEHR datasets against an archetype by
> > using XSD. You cannot create XSD's according archetype-constraints, not
> > even by hand. I have been there, a few years ago.
> >
>
> The information model can be validated with the XSDs, because the XSDs
> define the IM constraints.
>
> The XSDs are not to validate against archetypes (totally agree with you),
> is the IM validation that validates the structure and some required fields
> (by the IM!).
>
> Once you receive a well formed structure (should be valid against the IM)
> you can validate it against archetypes.
>
> If you already checked the instance against the IM and is valid, you'll
> have all the required values (required by the IM), then when validating
> data (this is the archetype validation!) and you find a {*} constraint, why
> the validator should need to continue traversing the instance?
>
>
> Hope that helps (or at least make sense :)
>
> Kind regards,
> Pablo.
>
>
> > Best regards
> > Bert
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at
> > lists.openehr.org<javascript:_e(%7B%7D,'cvml','openEHR-technical at
> > lists.openehr.org');>
> >
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
--
*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140514/3c556edc/attachment.html>
