Re: Comment on XSD 1.1

Michael Kay wrote:
> Personal response:
>
> The goals for XSD 1.1 were relatively modest: they are described here
>
> http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/
>
> The specification was not designed to address the known problems with the
> complexity of the 1.0 specification, which arise in large measure because of
> the sheer variety of requirements it originally set out to meet. Rather, XSD
> was designed as a modest backwards-compatible increment from XSD 1.0
> designed to remove some of the deficiencies of that specification in terms
> of its technical capabilities; in my view, it has succeeded admirably in
> doing that. Though of course everyone would like it to have been done rather
> sooner, and most of us who were involved I'm sure feel that it could have
> been done better if only there weren't so many different views on each
> topic. 
>   
Yes, and...?

I acknowledged that XSD 1.1 had many virtues.

But we must admit that the XML Schema WG has proved itself incapable of 
addressing the issue of rationalizing or profiling XML Schemas. There 
may be lots of good excuses for this, but none of them matter. We need 
to figure out how to move XSD in the direction of even less layering and 
more complexity with XSD 1.1. The appropriate channel for escalation in 
this case, as I understand it, is the TAG.
 
> You are arguing that it would have been better to do something more radical. ...
No, I am arguing not arguing about the past, I am commenting on the 
fresh start that is needed today, now, before XSD 1.1 diverts 
developers' attention for the next few years.  Nor am I saying to throw 
away the XSD 1.1 work. XSD 1.1 may be implemented in the course of doing 
something more reasonable, not as an excuse for avoiding it or papering 
over the problems. Some parts of XSD 1.1 would make simplification 
easier, while other parts would make simplification more difficult; I am 
not taking some kind of extreme or emotive blanket judgment on it at 
all, i hope. 

My point is not about the excellence of the new band-aid but fixing the 
gaping, festering wound ;-)
> Furthermore, we are no longer in 2003, and XSD 1.1 is
> essentially finished, so the only choice the community now needs to make is
> to decide whether it is an improvement on XSD 1.0 (that is, a sufficient
> improvement to justify the cost of implementing and adopting it). You don't
> seem to say anything to suggest that this is not the case, so it's hard to
> see how your arguments are relevant to the decisions that the community now
> needs to make.
>   
Since I have been making these kinds of arguments for almost a decade, 
and since there has never been more objective evidence that my POV is 
legitimate and reflects reality, that my arguments failed to influence 
the WG in 2003 or in 2009 or be irrelevant at this stage in the standard 
lifecycle does not assuage me. Nor does it extinguish the problem.

My comments may be irrelevant to the committee timetable, but they are 
entirely relevant for what decisions the community needs to be faced with.

And who is this community anyway?  If you mean the community is those 
people who have already implemented a full version of XML Schemas but 
ignore the community of people who have these problems (I am sure you 
don't really mean that!) then the game is indeed over.
> By saying that there are big problems with XSD, you aren't saying anything
> new or anything that we don't all know. But the fact is, that the software
> industry and the user community has an enormous investment in this
> technology, and XSD 1.1 needs to be judged on the benefits it offers to this
> community, not on the benefits that some hypothetical alternative might have
> delivered if we had taken a different direction in 2003.
>   
"Everyone knows its rotten" is surely a rather weak reason for pushing 
ahead with something?  But you are right, there is universal agreement 
that these problems exist and are extensive and unfortunate. I don't 
think this was the commonplace view even 5 years ago, which is why 
re-envigorating the XSD WG with a mandate to re-layer and relax XSD is 
thinkable now while it was unthinkable then.

There is certainly an enormous investment in XSD 1.n, which is why the 
full language I propose maintains it with its fault and virtues.  But 
there is also a large investment in software which implements something 
far less than XSD, and merely scrapes the XSD schemas for the bits it 
can use. Consider me a voice calling for first-class support for them.

And that language looks far more like RELAX NG than it does XSD.
> W3C organized a workshop in 2005 designed to analyze user experience with
> XSD 1.0: see
>
> http://www.w3.org/2005/03/xml-schema-user-program
>
> Some hoped that this would provide a springboard to generate the
> requirements for a refactoring or layering of the kind you described.
> Unfortunately, it failed to do so: although I was not present, my
> understanding is that it essentially confirmed that all the requirements
> that XSD 1.0 aimed to satisfy were real, and that all the features of XSD
> 1.0 were needed by someone.
>   
Of course everyone probably needs something and something different. It 
is farcical to use that as a justification for inactivity. It should if 
anything be taken as a red flag about the level of disfunction at the 
WG: it has itself in some kind of bind or groupthink or ultra-complexity 
that it cannot even weigh up a profile or even figure out a way to 
partition users? Surely all that is made redundant by the reports on the 
schema patterns unacceptable by databinding, now? Why not embrace that 
as new information that can break the logjam.

A lot of SGML users were disenfranchised by XML: all those who used tag 
minimization and short-references for example. They benefited more from 
the subset than they lost. But remember I am calling for a layering 
including a layering of concepts (e.g. no notion of type derivation of 
complex types in the broad language) which would not cause any 
subsetting of the specialized XSD language.

And indeed, it is not unlikely that the two-layer model would actually 
allow *more* progress and focus by the XSD group on the needs of XQuery 
stakeholders, because the language design and constraints would not have 
to cope with the requirements of those whose needs were met by the 
broader simpler base language. Get rid of mixed content, for example in 
the full XSD for example (no flames please!)  I don't see what I am 
proposing as remotely antagonistic to the needs of XQuery or those whose 
needs are currently well-met by XSD 1.n.

(Is there also a conceptual lack of imagination at work too: the idée 
fixe that complex type derivation is actually core to XML Schemas, when 
it is not: it is just a (clunky) mechanism which can be sloughed off to 
a different layer? XML Schemas dug itself into hole of complexity by 
making what should have been a topping into the main course, but it is 
not too late to fix (though too late to save the metaphor.) A simpler 
broad version of XSD with explicit content models and only type 
referencing rather than type derivation would be perfectly feasible, and 
the same schema would be completely explicable under an XSD 1.n -style 
complex type derivation regime as well. If you don't cut the cord with 
complex type derivation, then you cannot address the core complexity 
problem.)

Cheers
Rick Jelliffe

Received on Wednesday, 13 May 2009 17:21:19 UTC