> have ADL, AOM, and object transforms What is missing is that xml offers validation and query out of the box, which means it has been developed and optimized for years by many companies and communities, and mostly is good quality software. Op 23 apr. 2013 09:14 schreef "Thomas Beale" < thomas.beale at oceaninformatics.com> het volgende:
> 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@** >> oceaninformatics.com <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 > > > ______________________________**_________________ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org<openEHR-technical at > lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/5b96915e/attachment.html>
