[
Lists Home |
Date Index |
Thread Index
]
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.
|
