As to having multiple schema
languages, I don't see a reason why not.
With the exception of DTDs, these are all XML
application languages
and if someone were to say that we need the consortia
to eliminate
competitors there, I think a lot of us would ignore
such advice the same
way the procurement officials will ignore the Beltway
crowd that issues
opinions such as "W3C standards only". If you've
done much of this
kind of work, you may remember when it was "ISO only"
or "NIST only"
and so on. The ocean of innovation beats down any
barrier one can
put up and the results are that houses built on cliffs
loose that
exclusive view and sometimes disappear into the
swells.
Specifications and standards must stand on their
technical merits,
not their provenance. Trust yourselves to
figure out what is best
for your own applications. Those that
really need to interoperate
will negotiate. Those that don't don't need your
technology. The
best advice I have for anyone just getting into this is
to avoid
people who tell you that you must first "create buzz"
before
you have a working product, or that getting tight with
the W3C,
those of standing, whoever, is the first order of
business. Those
with standing recognize good work and will be a lot
happier to
see you coming with running code than a handful of
brochures.
The rules haven't changed: running code and rough
consensus
are the best predictors of
survival.
len
If XML Schema had the ability to specify allowed root nodes,
it would become even more complex (you'd need to also be able to specify root
*types* as well, I think, & perhaps that a given element may only be the
root if it has a particular attribute & <xsd:any namespace="http://www.w3c.org/2002/hideouslyComplexSchemaRules" />
).
If RELAX provided some inheritance support (putting aside
arguments as to whether a schema language should or not), it would start to
become more complex.
If either of these languages provided support for complex
co-constraints, things would get out of hand.
Schematron allows you to define allowed roots for a schema,
and I dare say it won't be long before someone devises a streaming Schematron
processor, so by combining the required features of different schema
languages, all kinds of things are possible. It's also IMHO a much neater way
to specify things like key/keyref relationships.
I think they called it component based development in the
90's. XSD doesn't have to be complex, regarless of verbosity, so perhaps the
answer is to try to refactor it as a set of modular features, which you can
specify as being supported or not in a schema or a processor (I'd personally
always turn off complex type restriction).
I don't believe XSD is inherently evil (except with a hangover
on a Monday morning), any more than the Dutch tax laws are (which are also
hideously complicated and subject to multiple interpretations, though some
would argue that *all* tax laws are evil) and it has some useful stuff. It
would be nice to see XSD V2.0 heading towards simplification - maybe even
<heresy>interoperable with RELAX NG</heresy> where each of the
languages focuses on it's core competency as a component in a possible whole.
However, having never designed a schema language, I have no idea if this is
either possible or desirable.
