On 22/04/2013 23:26, Bert Verhees wrote:
>
> Verstuurd vanaf mijn iPad
>
> Op 22 apr. 2013 om 23:19 heeft Thomas Beale <thomas.beale at 
> oceaninformatics.com> het volgende geschreven:
>
>> which rules is it breaking? As far as I know, openEHR XML documents validate 
>> normally against the schemas.
> yes, I said it wrong, later in the message I said it better and I forgot to 
> remove this statement.
>
> So let me correct myself:
>
> You cannot represent all Archetype constraints in XML schema, you can of 
> course validate against the master scheme, but that is not very interesting. 
> To validate you need to validate against the constraints. That is the 
> important point of multi level modeling.

that's true if you try to use XSD in its native form. I have been saying 
the same thing for years. But you can represent archetypes in XML in 
another way - as a straight object serialisation of an AOM structure. 
Have a look at the XML output of the current ADL workbench. I didn't 
create an XSD for that, but it would certainly be possible.

The XML format used by the Archetype Editor is of the latter form.

>
> I discovered some important problems, besides the restriction/extension 
> structure, which is quite disturbing. You are not allowed to restrict and 
> extend an derived element at the same time. Just for clarity, A restriction 
> in deriving in XML Schema is not the same as constraining in ADL.
> Read the Priscilla Walmsley book on this, she explains it very well.

yes, and she is correct, it's a mess. See my comments to Tim earlier ;-) 
But there is no danger of openEHR doing this, I think, since we know it 
won't work effectively. That's why all the

> There are ways around this, but it is not very elegant.
>
> Another very important restriction for using XML Schema, in my opinion, is 
> that you cannot have two or more elements with the same name but a different 
> data type. This data type must be in detail the same. XML Schema regards an 
> Element with a Dv_Text as a different datatype from an Element with a 
> Dv_CodedText.
>
> Both elements will be called "items" in an XML schema representing an OpenEhr 
> data structure, and thus is not allowed having them different details in data 
> types. This brought Tim Cook to using the GUIDs in the element-names, which 
> is unworkable in my opinion, and above all, probably unnecessary, because in 
> RelaxNG this restriction does not exist.
>
> Other tricks are also possible, for example augmenting element-names during 
> validation-time, but also that is cumbersome code, and that just for avoiding 
> the problems of an ivory tower stupid W3C standard?
>
> So this is indeed an important restriction, which makes the clean use of XML 
> Schema impossible in OpenEhr-rm, or any other ADL based multi level modeling 
> system. Dirty use, tricks, ignoring validation errors, etc of course remain 
> possible.
>
> There are more restrictions, but less important. For example it is not 
> possible to support the Dv_Time constraint/pattern hh:??:??, same for 
> Dv_DateTime. In the Dv_Date is also a problem, but can be worked around by 
> the "alternative" rule, but on another way then it is meant to use.
>
> Anyway, after a few weeks I will probably define the OpenEhr RM and all 
> possible constraints in RelaxNG.
>

I agree with most of this, but I don't understand the issue - we don't 
do any of the above anyway. That's why we have ADL, AOM, and object 
transforms of the AOM... am I missing something?

- thomas


Reply via email to