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