W3C home > Mailing lists > Public > www-tag@w3.org > May 2009

Re: XML Schema usage statistics (WAS: Draft minutes of 2009-05-12 TAG weekly)

From: Rick Jelliffe <rjelliffe@allette.com.au>
Date: Fri, 22 May 2009 00:17:50 +1000
Message-ID: <4A15628E.3040309@allette.com.au>
To: www-tag@w3.org
Mukul Gandhi wrote:
> I agree. But we shouldn't make things so simple, that we do not meet
> the requirements of the stakeholders. We already have Lite Schema
> technologies, like RELAX NG or Schematron. Why do you want to impose
> everything from there onto XSD?
Err, so that XSD users (including me) can get our jobs done without all 
the mucking around?
To increase interoperability? To claw back XSD from the serial 
inflators?  To try to help XML
get back on its small-is-beautiful foundations? To make sure that core 
XML technologies are
small enough that small FOSS developers can  implement them (with code 
and functionality
that is simple enough for Eric Raymond's million  eyeballs effect to 
come into play for maintenance.)
Take your pick!

Last week, a colleague of mine implemented Schematron (using CSS 
selectors) for browser-side
validation. It took him 300 lines of JavaScript code (it doesn't use 
XSLT). And it is  more powerful
in the constraints it can validate than XSD. And people can understand 
its validation messages. And the schemas are compact. I don't know if 
the XSD WG really realizes how low XSD's bang-per-buck ratio actually 
is. There is an incredibly high price being paid (in complexity and its 
flow-ons of
spec complexity, implementation incompleteness, consequent random 
interoperability, and
subsequent abandonment of using XSD for actual validation) for the niche 
features and monolithic construction of XSD.
> I like the type system of XSD (the concepts of simple and complex
> types) very appealing. 
But complex type derivation doesn't work. You often have to change the 
base schema.
But gee it looks scientific.
> I can point to one specific technology (NVDL, http://www.nvdl.org/)
> which makes heterogeneous Schema technologies to coexist in a single
> application.
Yes, I worked on its development. It is pretty good, and was designed to 
play with XSD.
Has the XSD WG ever considered it? Have they ever considered any 
external layered
> On the hindsight, from your arguments so far, I can judge, you are in
> absolute conflict with the goals of the XSD WG. You want to
> significantly change the core of XSD. 
But XSD currently does not have a core, or at least, looking for it is 
like looking for the core of a
plate of spaghetti.

Certainly I do differ from what I think is the viewpoint of many on the 
XSD WG: I don't
see type derivation as the substance of XSD, but just as an additional 
feature for
organization and modelling,  related to "how" constraints are organized and
modeled. A useful layer in some cases, but severable and otiose and bloating
as an explicit facility for an XSD Lite (and indeed, unnecessary 
conceptually for XSD Lite.)

Complex type derivation is no more inseparable from XSD than  <import> is.

The grammar and facets and XPaths are the things that express the 
The basic mechanisms of referencing types is all that is needed.

> You were free to propose any requirements to XSD, when the whole XSD
> processes started (1.0 or 1.1). But you are suggesting to hold XSD
> 1.1, when we are almost complete, and XSD 1.0 users are waiting for
> XSD 1.1 to become REC.
I first stated my preference for uncomplicatedness to the XML Schema WG 
ten years and
14 days ago:  "This kind of complication...rings lots  of alarm bells 
with me."   (The particular
issues changed,  of course.)

Trawling through the archive I note Henry's comment: from Jan 2000* in 
response to a couple
of calls for a more layered approach to XSD:

"The next draft will have a much more layered 'look-and-feel', I promise."

"Feature bloat is always a temptation to be guarded against:  but
remember Occam:  "Do not multiply entities _beyond necessity_".  Each
of the things you identify in your list of 'not needed' is on someone
else's 'must have' list.  The WG has done its best to balance a wide
range of requirements and use cases against complexity, scale and

After ten years, it is time to make good on that promise!  (I am not 
picking on Henry, nor
trying to do some long-term bait-and-switch: but I think his comment was 
typical of what
we have heard from the start and no different from what we get today.) 
Sorry, but saying,
in effect, "we have no real metric for stopping adding features" is no 
reason for not
having a profile: indeed,  the bloated standards generated by that 
approach surely must
need a profile in short measure.

Rick Jelliffe

Received on Thursday, 21 May 2009 14:18:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:28 UTC