Re: Comment on XSD 1.1

Rick, 

A minute ago I commented on this thread as someone who has been active in 
the development of XML Schema.  Here I speak as TAG chair.

Rich Jelliffe writes:

> The appropriate channel for escalation in this case, as I understand
> it, is the TAG.

In short, I'm not convinced that's formally true, but I'm certainly glad 
to try and get the TAG to play a constructive role, particularly if other 
TAG members are inclined to engage in this issue.  I believe the process 
requires that the TAG vote on whether to undertake this as an issue, and I 
will schedule the appropriate vote shortly.

In more detail, I think the pertinent issues with respect to W3C process 
are:

* A W3C Working Group has taken a draft specification to Candidate 
Recommendation status.  You as a member of the community have expressed a 
concern that I would summarize as:  the design is deeply flawed and should 
not go forward as a W3C Recommendation.

* The normal W3C Process involves processing of comments by the schemas 
working group.  Presuming that you and the working group fail to agree on 
a resolution, and presuming the working group at some point continues down 
the path to Recommendation, then the unresolved issue would be taken 
forward to the AC and the Director (Tim).

Dan, as TAG staff contact, do I have that right?  Without repeating all 
the pertinent text in the TAG charter [1], one pertinent bit appears to 
be:

"...it is likely that the Director will consult the TAG when issues of Web 
architecture arise. For instance, the Director may consult the TAG in 
cases where architectural issues are raised during the process of deciding 
whether to advance a document on the Recommendation track. "

The charter does also say:

" Issues may be brought to the TAG by a variety of parties: Working 
Groups, the public, the W3C Team, as part of an appeal to the W3C 
Director, the TAG itself, etc. Issues may arise in the interpretation of 
already published Architectural Recommendations, or with new issues not 
(yet) within the scope of such Recommendations.

" If the TAG agrees by majority vote, it will consider an issue as having 
sufficient breadth and technical impact to warrant its consideration. The 
TAG will work to prioritize the issues before it, and to address those of 
most immediate impact in a timely manner. "

Sorry for all the process stuff, but since you said that the TAG is the 
appropriate channel for escalation, I thought it was worth rechecking the 
groundrules.

Here's my net:  Rick has, at least informally, asked the TAG to consider 
his concerns with XML Schema.  Consistent with all the process stuff 
quoted above, I hereby ask the TAG to consider whether it wishes to 
undertake work on this issue, and if so how to prioritize relative other 
things.  I will take the appropriate vote on an upcoming teleconference. 
If the TAG decides not to get involved at this time, then there is also 
the opportunity for Tim to ask the TAG's advice during the approval 
process for XSD 1.1.

Noah

[1] http://www.w3.org/2004/10/27-tag-charter.html


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Rick Jelliffe <rjelliffe@allette.com.au>
Sent by: www-tag-request@w3.org
05/13/2009 01:20 PM
 
        To:     Michael Kay <mike@saxonica.com>
        cc:     www-xml-schema-comments@w3.org, www-tag@w3.org, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        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:51:01 UTC