[
Lists Home |
Date Index |
Thread Index
]
Hi Stan,
On Jun 28, 2006, at 23:37, Stan Kitsis wrote:
> The second issues, as Robin pointed out, can be a problem when
> schemas need to be used with different processors. This is a much
> bigger issue and applies to Xml Schema spec in general, not just in
> this specific case. If there is a schema processor that doesn't
> support a certain part of the spec and is intended to be used with
> a given schema, then I agree - schema authors should avoid using
> that part of the spec.
The problem is that this can get incredibly difficult for the users.
If it's a single more or less well-separated feature like keys that's
not working everywhere, as is the case in this instance, that's easy
enough: just don't use keys. However a lot of the incompatibilities
are on much trickier combinations of features that map to obscure
parts of the specification (or clear parts with obscure
interactions). Those can be extremely hard to create tests for and
understand, let alone explain to users.
> Relax NG is not the best way to solve these kinds of problems.
I'm not sure what you're getting at here, are you making the
statement that using a specification that is much simpler, much
better defined, and already well implemented and tested is not a good
way of addressing issues with a technology that is known to be
obscure and problematic?
> We know about the problems listed above because Xml Schema and
> various processors have been extensively tested and used in real
> world. A lot of corner cases were found and software was adjusted
> to handle them. The most popular schema processors are much closer
> to the spec today than they were a year or two ago.
And how long is it going to take until one can safely use any feature
of the specification without fearing that it'll break as soon as we
leave the simple stuff? It's been *five* years since the
Recommendation, almost six since the Call for Implementation (nice
work on the CR phase there) and there still are serious
interoperability issues between major implementations. Getting better
over the past two years doesn't mean much, two years ago the
interoperability of XML Schema processors was quite simply abysmal.
> I don't know if various Relax NG engines have gone through similar
> real world usage and cleanup. How confident are you that if Howard
> starts using Relax NG, he wouldn't be in the same situation?
I'm very confident that he'll not see such issues with RelaxNG, and
equally confident that he will if using XML Schema. The first XML
Schema I ever wrote, and it wasn't complex, worked in Xerces and blew
up in MSXML. This has happened to me (not necessarily between those
two implementations) with practically every single XML Schema that I
wrote. The interoperability problems I've seen between RelaxNG
processors have been minor.
> Also, does RELAX NG have enough conformant implementations on
> different languages and platforms to make data defined with RELAX
> NG truly portable?
Yes. It certainly is more portable than using a schema language that
won't even work the same way between two implementations on the same
platform :)
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
|
