RE: [xml-dev] XML spec and XSD

["Glidden, Douglass A" <Douglass.A.Glidden@boeing.com>]

From the perspective of an application developer who uses XML for storing fairly complex hierarchical data (as opposed to documents), I have a very basic question:  Is there any real, practical reason that Relax NG is _universally_ better than XSD?

Here's the background for my question:  I've been using XSDs for generating object-oriented data models for some time, and have been frustrated by various inflexibilities in XSDs.  For instance:
- Derivation by restriction, while conceptually very useful, seems slightly cumbersome in operation; in particular, I wish it could be accomplished with less repetition (I'm a fanatical believer in DRY).  I can live with the repetition, though, because I am assured that, if I make a typographical or some other error, the XSD will (almost) always fail to validate ("Bar is not a valid restriction of Foo"), so the the possiblity of unintended changes being introduced due to the repetition is kept to a minimum.
- Certain fairly simple data structures can only be achieved in XSD (if at all) with ridiculously verbose patterns; for instance, how do you represent a structure with five possible elements, at least one of which must be present and none of which may be repeated?  The best method I have found takes about 25 lines and far too much code repetition.
- Most business logic cannot be represented, like "the value of the foo element must be less than or equal to the value of the bar element".
- I occasionally was foiled by XSDs strict "no ambiguity" rules, which make it difficult to enforce rules such as "if the value of the foo element is xyz, then the bar and baz elements are required, but otherwise they are optional".

Nonetheless, I have been more or less pleased with the final results in most cases.  Having heard much praise of Relax NG, I recently decided to try it out, hoping it would be able to resolve these issues.  Here's what I found:
- It does relieve the "no ambiguity" problem and makes enforcing that sort of rules much easier.
- It does not resolve most of the business logic issues, but there are other technologies that can be used in combination with either Relax NG or XSD to resolve these issues, so that can be worked around in either case.
- It does not appear to relieve the complexity of representing some types of data structures (see the one described above-as far as I can tell, it would not be significantly easier to define in Relax NG than it is in XSD).
- There is only a rudimentary concept of type definition and virually none of inheritance.  Designing good, object-oriented data models is practically impossible in Relax NG; for me, this is a HUGE deficiency.  For instance, say Foo is an abstract data type with several fields, including an id field (any mixed data allowed) and a type field (with enumerated values); Bar is one of several concrete subtypes of Foo, which restricts the content of the id field (must contain two elements, a groupId and a subId) and the type field (to a subset of the values enumerated by Foo) and appends several new fields; other subtypes have completely different restrictions on the id and type fields and append various different new fields.  In XSD, implementing this is fairly straightforward (although not necessarily simple and certainly more verbose than I would prefer):  Foo is an abstract complex type, and Bar and the other subtypes must derive from it first via restriction (creating the restrictions on id and type) and then via extension (appending the new fields).  In Relax NG, by contrast, I could find only two ways of doing this, neither of which was at all acceptable:  One is to get rid of Foo completely and reference its fields separately in each subtype-this is unacceptable to me as it completely violates DRY and object-oriented design; the other is to define each subtype of Foo in a separate file, importing Foo and redefining as necessary-this is marginally better from an OOP point-of-view, but still makes it impossible for a schema to use "any valid subtype of Foo" as a content definition without violating the Open-Closed principle.
- Relax NG provides no way of specifying cardinalities other than 0, 1, and infinity!  This is also a big one for me--if I need at least 2 and no more than 20 occurrences of the foo element (fairly common in my data definitions), there's NO WAY I'm going to define two required foo elements and eighteen optional ones!

Now, I'm hoping that some Relax NG expert will come along and prove me wrong about some or all of these things, since I only experimented with it for a couple of days.  If not, for me these deficiencies in Relax NG *far* outweigh its benefits over XSD-there's really no comparison.  As much as I would like to see some aspects of XSD improved, unless someone can propose real alternatives for issues like the ones above, Relax NG is simply not an option for the type of data I work with.

As a postscript, let me say I'm very thankful that the tone of this thread has been gradually transitioning to actual constructive argument (at which this list is normally rather good) rather than the ridiculously juvenile mud-slinging that was predominant early last week-in particular, I've appreciated the level-headed input from Jim Tivy, Liam Quin, Ken Holman, and Michael Kay.  Unfortunately there are still some emotionally charged but pretty much meaningless (or worse, completely false) words being thrown around, but at least those aren't in the majority anymore.  In all good humor, I have to say that XML-dev is by far the most argumentative mailing list to which I've ever been a subscriber. :-)

Doug Glidden
Software Engineer
The Boeing Company
Douglass.A.Glidden@boeing.com