Cart
[Home] [By Thread] [By Date] [Recent Entries]
Jirka Kosek wrote: >> A >> lot of corner cases were found and software was adjusted to handle >> them. > > Weren't such corner cases caused by a lack of formal underpinning and > complexity of XSD spec? That may be, but I believe Stan's point is that the extensive real-world use of XSD has uncovered them. The formal underpinnings of RELAX NG *may* prevent these problems, but AFAIK that remains to be convincingly shown. There do seem to be RELAX NG test suites, but are they anywhere near as comprehensive as the XSD ones? In my experience, most of the complexities of the higher-level XML specs and APIs come from the nastiness of XML's corner cases. RELAX NG has a nice formal underpinning, but XML does not. It's not clear without actual evidence that RELAX NG sidesteps XML's corner cases without creating some little nasty scenarios of its own. > > It is time to say that XSD was designed to describe unambiguous > mapping between XML instances and data-types which was needed to > support XML<->object and XML<->database mappings in software packages > from big vendors. But for capturing arbitrary XML structures XSD is > really insufficient. 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. RELAX NG is probably a "better" language for document-like XML structures, but it is insufficient for data-intensive applications. Speaking for myself, I wish the XSD WG had tried harder to understand what Murata Makoto was telling them about hedge automata and used that knowledge to make the W3C standard cleaner and more formally grounded. 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. > > So if you are using XML mainly as a serialization of object or > relational data, you can live quite happily with XSD. But once you > need more flexible document structures, or you need to develop highly > modular and customizable schema, you will have very hard times with XSD. Trouble is, a lot of people have flexible documents full of data that came from objects or databases. They'll have a hard time with the "flexible document" limitations of XSD, but a hard time with the "object serialization" limitations of RELAX NG. 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.
|
