xml-dev - Re: Proliferation of validation options

[Rick JELLIFFE <ricko@geotempo.com>]

Bob Kline wrote:
 
> 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?

XML Schemas requires a change in idiom, but the same 'information' 
can be modelled (taking a very remote view of 'information' no flames):
Instead of 
   <li type="ul"> 
or 
   <li type="ol">
one must do
   <li><ul>
and 
   <li><ol>
or
   <li xsd:type="ul">
and
   <li xsd:type="ol">
or even (and I think this is what the WG thinks will be happening most)
   <ul>    where it is a derived type from li
and
   <ol>    where it is aderived type from li

I think XML Schemas WG can be criticized for not starting from the
viewpoint "what do people do in markup" thoroughly, but on the
other hand the participants do have very definite use-cases that
they do want to support, and which RELAX or Schematron do not.
If XML is a data interchange language, it makes sense to have
a schema language that has maximum interoperability with SQL and
Java, is the appropriate line I suppose.

Perhaps part of the reason it does not have it is that, I cannot
be sure of this, for the last two years there have been a vocal
group saying "we don't need attributes" and "we need to support
data not documents" and "computers write XML not people, so human
factors issues should not be overrated".  I think some on the WG
may feel sympathetic to these views.  You have diagnosed the result,
are you willing to trace it to its promoters?

I hope XML Schemas will evolve into something more humanistic, 
but for now just a standard good enough for a base with clearly
stated and understood limitations is all we can expect (and,  I
believe, all that anyone should expect).

>  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?

Yes. 

(a) Rolling your own will be needed in lots of cases anyway: a
schema language can only provide certain general purpose constraints
without turning into a general purpose language.

(b) Schematron does not come from the rich and powerful, but it is
only the thinnest layer on a well-implemented and designed spec
from W3C.  An open-source schema language that takes two pages to 
implement has very different tradeoffs than one that takes 200.

(c) The problem isnt functionality per se: it is a matter of
choosing idioms in the particular case you give.  

If this is an important markup idiom for anyone, write to
the schema interest group (if you are w3c member) or through me
if you are not. I will be happy to report it to the schema WG.

Rick Jelliffe
Academia Sinica