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. 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. 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. Bert
