Re: Choice

Hi Noah,

> The point is that, as we say in the rec, the purpose of the schema
> language is to capture a useful set of constraints; we can't
> possibly capture "every" useful constraint. What's useful is a value
> judgement. I agree completely that co-occurrence constraints are
> important, that the set we currently handle aren't sufficiently
> powerful for many purposes, and that XPath based systems such as
> Schematron are among those that point the way for doing better. I
> hope we consider such enhancements to XML Schema for a possible
> version 2.0. When we do we'll have to consider a variety of issues
> including expressive power, performance, ability to support
> streaming, integration with our type system, etc. I did want to make
> the point that, when we're done, almost no matter what we do, we'll
> still be having discussions on this mailing list about all the
> useful constraints that we still can't model.

I agree wholeheartedly that designing a schema language is about
deciding both what constraints you need to articulate and how to
articulate them. My view is that when you need validation, you should
use whatever tools you have to in order to achieve the level of
validation you require - XML Schema, RELAX NG, Schematron, Java code,
whatever. And when you need a schema for documentation, you should
fill in the gaps with natural language.

However, it seems to me that people who try to use a schema language,
and especially XML Schema because it comes from the W3C, want it to be
able to express everything (and I really do mean everything). When
someone learns that they can't do X in XML Schema, their reaction
seems to be "then XML Schema is useless". I don't think that is a
reasonable reaction - I'm not condoning it - but it seems to be a
common one in my experience.

In general, people don't view XML Schema as just one way of expressing
the constraints on a markup language, to be used in concert with
others, they view it as the *only* way. So if it can't do exactly what
they need it to do, it has failed in their eyes. And from the other
side of the coin, people who don't like XML Schema focus on the things
that it can't do rather than the whole raft of things that it can do
and does do very well.

From a social/political point of view, then, I think that it's
important that the next version of XML Schema has the flexibility to
support *all* kinds of constraints. If that requires embedding a
declarative language, so be it.

Let the next version of XML Schema be modular, so that implementers
can choose not to implement those parts that would undermine the speed
or practicality of their validator - at least then it will be the
implementations that fail to make the grade in the eyes of the users,
and not the standard.

Or perhaps a better alternative would be to put together a
Recommendation that describes how to use XPath rules within the
xs:appinfo element, so that there's a W3C standard way of using
something like Schematron as a schema adjunct.

As I said, this is from a social/political point of view, and not a
technical one. I agree that there are big technical issues that also
have to be considered, for example problems with reconciling the
tree-based view of XPath with the object-oriented view of XML Schema -
the one place where XPath is already used within XML Schema (i.e.
identity constraints) demonstrates the problems that arise with
namespaces and with modularity very nicely. *Hopefully* XPath 2.0 will
make that somewhat easier...

My point is that whether or not a schema language chooses to support
all possible constraints is a design issue in its own right. And my
opinion is that the next version of XML Schema would be more
satisfactory to more people if it did.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 8 March 2002 13:41:29 UTC