On 23/04/2013 18:09, Timothy W. Cook wrote: > > > On Mon, Apr 22, 2013 at 7:26 PM, Bert Verhees <bert.verhees at rosa.nl > <mailto:bert.verhees at rosa.nl>> wrote: > > > > 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. > > > There are many reasons and benefits to using Type4 UUIDs. I cannot > imagine that RelaxNG has any magic to allow global elements to be the > same name and have different types or two elements at the same level > have different types. Certainly no programming language allows that. > There are other approaches that can be used and not use UUIDs. You > can nest all of your complexTypes and create VERY wide artifacts. You > can use intricate namespacing if you want. > > 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? > > > Interesting here that you call it a stupid standard and then in a > later email you praise it for its industry acceptance.
I think Bert is comparing Relax NG to XML Schema, he's not just talking generic 'XML'. > > But, the things you continue to call tricks are not tricks, they are > features of the standard that are implemented because one or > more people presented sufficient use cases. Just because Priscilla > Walmsley doesn't bless their use doesn't mean that they are any less > valid. > > > 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. > > > Yes, be specific. You probably can't model an ADL based RM in Haskell > or Erlang either. But that doesn't mean they are not useful in > multi-level modeling with a functional design. If you goal is to stay > with ADL then you have to live with those requirements. I chose not > to in MLHIM for all the other benefits that come with adopting XML > technologies. out of interest Tim, did you look at Releax NG or Schematron? > > > 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. > > > There are very clean and efficient ways to allow for partial dates in > XML Schema. They are catered for <http://www.w3schools.com/schema/schema_dtypes_date.asp>, but I have to admit, in a pretty annoying way. But better than not being catered for... The lack of support for hh:??:?? is actually the fault of the ISO8601 standard, and I suspect it's because the writers never actually implemented a parser, and had the simple realisation that a partial date or time (e.g. "1995", "12") is impossible to distinguish syntactically from an integer in a mixed data stream - some other help is always needed. XML Schema solves it with the data types gMonthDay, gYear etc. Ugly, but not really their fault. A slightly better designed 8601 standard would have saved a lot of problems, and the ultimate fault in my view lies at the door of ISO: a completely wrong model of doing standards. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/886ad6ff/attachment-0001.html>
