Lists Home |
Date Index |
On Wed, Mar 20, 2002 at 11:56:07AM -0800, Dare Obasanjo wrote:
> > 2. If the spec is clear and the implementation simply does
> > not implement
> > the spec, let the vendor know the problem, and that
> > compatibility really
> > matters to you. Let's put pressure on the vendors.
> This is good advice. Unfortunately many people don't have the time nor
> inclination to send bug reports to vendors nor do they know whom to
It's not just time and inclination that's a factor here. It's the fact
that XML Schema is about as user-friendly as a stick in the eye.
Let's concern ourselves with the domain of XML users. For the sake of
argument, let's say that:
80% of these users don't care about schemas
80% of these users have given up on XML Schema because of
it's impenetrability, complexity, or sheer size
80% of the remaining users have given up on XML Schema because
of the difficulty in finding tools and APIs that they
can actually understand, use and incorporate into their
If I'm doing my math right, that leaves roughly 1% of XML users
actually *trying* to do something with XML Schema. From there:
80% are creating very simple schemata, and not pushing the
envelope. For them, rudimentary features and the
handful of existing implementations are sufficient.
80% of the remainder give up when attempting to use more
complex features, either by failing to continue to use
XML Schema, constraining themselves to features they
know to work (or err on the side of false positives
instead of false negatives)
At this point, a very small number of users are using XML Schemas
with validators and *might* be having conformance problems. This
should not be news, it's simply a statement of the early adopter
However, the fact that there is no standard API to use with XML Schema
is impeding matters; XSLT and XSL-FO provide a very simple, testable
standard interface to the user, which helps to explain why XSLT is so
much more heavily implemented, deployed and used than XML Schema.
Furthermore, once one of those <1% who do have problems get past the
limiting factors of finding the right address[es] where problem reports
will be appreciated, and find the tuits to send those reports, then we
have to tackle the issue of identifying whether the problem is:
- a lack of understanding of the specification
- a corner case of the specification
- a conformance error
Most programmers I know err on the side of caution and choose (1),
rather than doing the extra work to see if a problem is truly an
error of some kind (or embarassing themselves when Henry points
out their misconceptions). As a result, either they start trying
to find a work-around with XML Schema or their particular validator,
or they give up and fall back into the majority.
Foisting the problems with XML Schema and validators upon a user
population that does not report problems is a big fat dead and
bloated red herring. The true problem is with XML Schema itself,
and that too is not news.
Other XML Technologies (SAX, DOM, XSLT, XInclude etc.) have higher
adoption rates simply because there aren't as many barriers in the
way filtering people out of the equation.
Surely XInclude isn't being used by 90% of the XML user base, but
the fact that it can be implemented in a trivial and obvious XSLT
stylesheet or SAX filter certainly *helps* anyone who happens to
stumble across it. Furthermore, simple specifications don't have
the issues of debugging problems to be bugs with the specification,
implementation or understanding of a technology.