Re: Choice

We probably don't want to take the list into a long discussion of this. No 
doubt users would prefer to capture a broader set of constraints, if there 
were no downsides.  On the other hand, a lot of this is about establishing 
a degree of checking that interops universally.  Java, much as I like it 
for many purposes, would presumably not be appropriate as part of an 
official W3C validation stack.  Neither would Microsoft .Net assemblies. 
Schematron doesn't have that problem, but there are some other questions 
that I think would have to be explored before it could be integrated as a 
first class adjunct to schemas as we know them (e.g. performance, 
integration with the type system, ability of tools to exploit it, etc.) 
Also:  Schematron is relatively declarative;  my concern was primarily 
with the possible jump to non-declarative languages.  It's much easier for 
tools to reason about constraints captured declaratively (e.g. in schema 
facets or derivations, or even Schematron assertions) than imperatively 
(in a Java loop).  The ability to build tools that manipulate and derive 
information from schemas is of key importance.  Writing programs that 
validate documents or types may not get us that.

Anyway, this is an interesting and important discussion, but I suspect the 
list will be happier if we wind it down.  Obviously the WG (and others) 
are considering these issues as we guage reaction to schemas 1.0 and 
consider possible directions for future versions.  Thanks much.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Jeni Tennison <jeni@jenitennison.com>
03/08/02 01:41 PM
Please respond to Jeni Tennison

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     xmlschema-dev@w3.org
        Subject:        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 16:16:10 UTC