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

> John Kemp writes:
>
>> Can you simply describe (by listing specific technical items) what
>> would be needed to profile XSD 1.1 in order to create "XSD Lite"? Is
>> that what you are looking to do?
>
> Rick:  I would also find it useful if you could outline what you see as
> the requirements and success criteria for such an XSD Lite profile.

Fatuously, there is only one success criteria: that it should *exist*,
with equal status to full XSD. Let the individual participants in the
market decide when they should use the profile and when they should use
the full.

The core of my argument is that the methodology used by the W3C XSD WG has
manifestly has failed, with XSD 1.1 the latest symptom. This methodology
deals with micro-issues, feature-by-feature with absolutely no
consideration for the nature of the whole package (or no effective
consideration.) Indeed, it avoids dealing with primary software quality
issues (simplicity, obviousness, layering, ready description, maximum
power through low-hanging fruit, modularity, evolve-ability, etc.) by
focusing on all issue through a single inadequate technical consideration:
the relationship with the rather weak single-inheritance type model.

So I am certainly not going to play the game that has *caused* the
problem: user group says "we only need A" and you say "But user group
needs B"; user group says "we need only B" then you say "But user group
needs A". This dodging has been going on for a decade (refer to Henry's
quote in my previous post.) It looks reasonable, but it is not in fact
reasonable because it is based on the idea that unless absolutely everyone
is satisfied by a profile, there should be no profile.

Indeed, that is why all the 5 methods I proposed the other day are based
on methods of obtaining a profile that did not require decision-making at
the individual level (or, at least, that any decision-making that was
needed had a methodology capable of producing a result.) And I believe
they all would result in very similar languages.

Indeed, I think the approach I am suggesting is similar to the one so
successful to XML: the goals of XML prescribed a technical shape and
software quality objectives that *forced* trimming. Much of the discussion
in developing XML was not about individual existing features because of
the commitment to being a profile of SGML (with SGML being minorly
changeable to accommodate XML), but on how to adjust this core SGML to new
technologies: Unicode, URLs, the unworkableness of HTTP charset, HTML
parsers, and so on.

Contrast this with the development mission of the XSD WG, whose task was
to merge bits from lots of different source schema languages: this task of
re-combining rather than profiling may certainly have been reasonable
then, but it is counter-productive as the sole methodology then and now.

In XML development discussions, we had the Desperate Perl Hacker (DPH.)
He/She needs be brought back. The Desperate Fortune 500 Development
Strategist is no substitute. A vendor may indeed speak for their clients,
but they cannot speak for all the people who have rejected becoming their
clients: hence the need for paternalistic fictions such as the DPH.

But if the question is to what the general shape of XSD Lite would be I am
happy to answer: each of the "five mechanical approaches" I posted
previously would zero in on a fairly similar profile as far as I can tell:
a resolved DTDs+Facets in XSD Syntax. No complex type derivation,
nillibility, xsi:type, abstract elements, blocking, PSVI (therefore UPA in
that form), keyref,  simple type derivation from user-defined simple type.
 Copious tabulations of outcomes would be inappropriate too, I would
imagine. Certainly enough to represent the HTML schemas for example.

Cheers
Rick Jelliffe

Received on Friday, 22 May 2009 03:13:45 UTC