xml-dev - Proliferation of validation options

[Bob Kline <bkline@rksystems.com>]

Dear xml-dev'ers:

I'm only now beginning to appreciate just how many specifications have
sprouted up for XML document validation mechanisms.  In the face of the
limitations of DTDs, we have no shortage of proposals for approaches to
the problem of specifying constraints on document content: XML Schema,
DSD, SOX, RDF, Schematron, RELAX, to name some of the options.
Unfortunately, the only one of these which has the backing of the W3C
behind it -- XML Schema -- has a number of significant drawbacks.  In
spite of the frequent complaints (not difficult to understand) about the
complexity of the draft specification, XML Schema does not address all
of the basic requirements commonly needed in document validation.  For
example, we could not use XML Schemas to specify that the acceptable
content for a given element differs based on the presence or value of
one of its attributes.

We've looked at RELAX, but the only one of the three existing
implementations which fully supports the spec is not open source, and we
understand that all three will need to be rewritten from the ground up
to accommodate a newly published algorithm.  We're looking at some of
the others (Schematron, for example, appears to have a very nice
mechanism for specifying context-specific rules for content
constraints), but the real problem is that we have no way of knowing
which -- if any -- of these options will still be around a year from
now.  If we're going to pick something that's going to disappear in six
months we might as well roll our own specification and implementation,
throwing yet another option onto the heap.

XML Schema seems to be in that worst-of-both-worlds state.  On one hand
the tool vendors say they can't support it because it's not an approved
standard (so we'll have to produce DTDs for the XML editor, since none
of the candidate products with a customization API sufficient for our
requirements has any Schema support).  On the other hand, the working
group says the specification documents are in the "Last-Call" stage, and
that no further changes in functionality can be expected.

So, two questions:

 1. How did Schema get so far, with a spec that's harder to read
    than any of the others, and still leave out functionality
    the absence of which is causing all of these competing specs 
    to appear?

 2. Are projects really expected to choose between
     (a) rolling their own validation grammar and implementation;
     (b) adopting possibly ephemeral proposals; and
     (c) omitting support for required functionality?

Cheers,
Bob Kline