[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Restrictions on existence of attributes?
Michael Champion said: > It's not clear without actual evidence > that RELAX NG sidesteps XML's corner cases without creating some little > nasty scenarios of its own. I have been making and selling RELAX NG and XSD products for about 5 years now. I have never had a single problem reported with the mature RELAX NG implementations (that I can recall) or with RELAX NG interoperability. For XSD we use MSXML which I rate very highly and Xerces, which I rate quite well but unbelievably over-engineered. But XSD's interoperability problems are notorious. The fact that after so long there are still major implementations that don't conform, despite the test suites, finance, and goodwill, shows there is something wrong with the XSD technology (and/or the bug-fixing processes of the implementors). No using in squirming or evading it. The issues were well known and predicted *years* before the XSD spec was finalized: indeed James Clark and Murata Makoto developed RELAX NG largely as a counter to these apparant problems. An attempt to claim that RELAX NG has "nasty scenarios" smacks of FUD. Where is this boogie man? I am not sure people buy the argument "We should only make a change if it can be proven to have no bad effects, and we insist there are bad effect lurking even with no proof ourselves" any more. It was used a few too many times during XSD's development! It sounds conservative and alarming, but is without foundation and prevents progress. And the idea that XML is to blame somehow for XSD's complexity evades me. I'd put out the opposite challenge: does anyone have *any* examples of RELAX NG having interoperability problems? > The position that Stan, I, and the others who deal with this question at > Microsoft have come to is that XSD's insufficiency is most practically > addressed by complementing XSD schemas with Schematron constraints. Yes, but I think it goes deeper than that, for the future. XSD suffers three big problems: XSD is not specified in nearly a modular enough way making staged implementation and formal characterization and evolution difficult, the particular features XSD does provide fall short of their potential, and XSD contains niche features as requirements that would be better as optional add-ins at a different layer (such as xsi:type, nillability, complex type derivation). By comparison a modular approach, with clearer and more expressive parts, is DSDL. Compared to XSD's 2 parts, it separates out * grammar, but more expressive of common idioms (RELAX NG) * data types, but more powerful at accepting idioms (such as "27 March, 2005") (DTLL) * path/key/integrity & co-occurrence constraints, but way more powerful than XSD (Schematron) * constructing schemas from multiple namespace schemas (NVRL) * renaming elements and namespaces for better versioning and substitution (DSRL) * character repertoire constraints that also work for mixed content (CRDL) * (future) link checking Niche features such as checking whether two grammars are compatible in some way, which XSD is based on yet which is too limited to provide much value, are implemented outside the standard, by toolmakers as a utility, which is where it belongs. Now, of course, there are some stengths that XSD has that DSDL currently misses: but the adoption of XML-in/XML-out rather than PSVI is just as much a feature as a weakness. > But with my Microsoft hat on, implementing one schema spec (and > suggesting people use the XSLT-based reference implementation of > Schematron when XSD runs out of gas) is a better story than supporting > two and somehow telling the story of when to use one vs the other. Sure, but Sun's MSV shows how it is possible to have one implementation supporting both grammars. I think vendors need to be more proactive, and move out of damage control mode with XSD, towards demanding that W3C XSD WG evolve XSD progressively move towards DSDL. Modularize it first into compatible parts. Then evolve each part independently. Then implement each part independently. A monolithic spec promotes a monolithic implementation. For example, RELAX NG allows attributes in content models. This is really useful, and in fact, as this discussions shows, XSD does have a non-type-based hack that works in the same area. Changing XSD to follow RELAX NG in this area would be great. > Again, the bottom line here is that it would be good to have a lot more > hard evidence that RELAX NG is really a more pragmatic solution than XSD > to problems such as this one before recommending it, irrespective of its > many excellent technical properties. I have been working on a large project for a government agency. The (third party) XML consultant uses RELAX NG to manage and specify the data, he loves the compact syntax and tools, and then delivers it to stakeholders in whatever form they want: RELAX NG, XSD, even DTDs. It is working well, and one of the reasons it works well is that the XSD being delivered is pretty conservative. Cheers Rick Jelliffe
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|