Re: www-dom@w3.org feedback

"....unnecessary complexity..."
I subscribe to 3 newsgroups; a web developer forum, a web developer dom
forum and this one.  Guess which one the above applies..

".. the problem is in the process.."
If the Queen said black was white what proportion of the population would
disagree?

An observation and a philosophical teaser,
Mike Flynn,
4thside.com

----- Original Message -----
From: "Ray Whitmer" <rayw@netscape.com>
To: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
Cc: <www-dom@w3.org>; <michael.h.kay@ntlworld.com>
Sent: Monday, April 01, 2002 8:59 PM
Subject: Re: XPath DOM and XPath 2.0 (Was Re: Comments on DOM XPath
Interface)


> Elliotte Rusty Harold wrote:
>
> > For what it's worth I agree that XPath 2.0 should be out of scope for
> > this work and disagree with Michael Kay. However, I do think his
> > proposals should be considered on their merits, and should not be
> > summarily rejected because DOM XPath is at last call. I've lost count
> > of the number of times my suggestions have been brushed off by one
> > working group or another simply because it's too late in the process.
> > The W3C has an institutional problem that actively discourages
> > developers from looking at, working with or implementing early drafts,
> > and then refuses to listen to commentary on later ones.
> >
> > Both the XPath 2.0, DOM Level 3, and almost every other working group
> > I've encountered at the W3C acts similarly, which leads me to believe
> > the problem is in the process, not the personalities. The closed,
> > insular nature of working group discussions leads to a situation where
> > the working groups develop a consensus reality that can be wildly
> > divergent from what everyone outside the working group thinks. They
> > tend to get wrapped up in all the effort they've put into a spec and
> > then defend their approach against all comers, no matter how massive
> > the problems. The effort they've expended in producing a sometimes
> > fundamentally flawed spec prevents them from accepting constructive
> > criticism. The deeper the criticism the less likely they are to take
> > it, no matter how accurate they may be. Editorial corrections are
> > accepted. Changes to functionality are resisted. Any suggestion that
> > the entire specification is fundamentally flawed and should be
> > scrapped so that the process can start from scratch or at least not
> > get in the way of third party efforts are never considered. But the
> > fact is, sometimes the specs the W3C (or anyone else) produces are
> > abominations and deserve to be scrapped, no matter how much wasted
> > work that entails. It is better to have no spec at all than one that
> > is fundamentally wrong.
>
> The DOM XPath APIs have been significantly altered to the point they do
> not resemble the original straw-man proposals, in direct response to
> feedback from the public working group.  The reason I am happy with
> where we are now is that it is the result of lots of feedback.  It does
> not resemble what I proposed to get the process started but enough
> people seem to like it.  Some may say unnecessary complexity was added
> by too much public involvement, but I think it strikes a reasonable
> balance.  To say they "defend their approach against all comers, no
> matter how massive the problems" is not true in this case or many others
> I can show.  It is not possible to satisfy everyone simultaneously --
> not all suggestions are compatible -- but it is clear that the group
> seriously considered and reconsidered feedback received.  Please point
> out the prior notes that were ignored and we will correct that.  Even
> good suggestions may have to be denied in some cases.  We have tried to
> account for every one.  It is possible that the record of some issues
> that were considered was lost during the major revisions of the document
> -- especially where the issue was favorably resolved the rewrite may
> have superceded the issue -- or may have been rewritten or summarized
> beyond recognition, but they were considered in their original messages.
>
> Every issue received on this list will continue to be considered
> including those already recently posted (since the last draft).  I
> responded personally on two of those that I thought reflected an
> unrealistic view of the state of the DOM XPath API specification and
> XPath 2.0, which was a bit discouraging.  If I gave the impression that
> any issue would not be considered, then that was unintentional and
> wrong.  This is also true of the DOM working group in general, carefully
> tracking issues, bringing people into the process as well as they can.
>  But it takes a significant time committment to expect to make a real
> impact.  I do not see how it can be otherwise.  It is natural for a
> novice to expect his first suggestions to be instantly understood and
> embraced by others as easily at the end of the process as in the middle,
> but it is unrealistic.
>
> But speaking again for myself, I point out again that the issue of XPath
> 2.0 has been previously decided by the group, and I see no new
> significant information on that from Michael Kay, so he needs to make
> the case and try to overcome some obstacles from long before we had
> satisfied implementations and other feedback as we do now.  Reopening
> would also seem to be a significant change in the priorities and
> requirements, breaking those who who have invested much in good faith
> after much discussion.  No one didn't want compatibility with future
> versions of XPath, but in it's current state XPath 2.0 seems scarey to
> contemplate -- it also does not seem to have changed fundamentally since
> the decision was made in terms of compatibility, stability,
> completeness, etc.
>
> I, too, would be happy if certain W3C proposals never saw the light of
> day.  But I believe that this XPath DOM does not fall into that category
> because in my own analysis it works, is very useful, and overcomes the
> significant problems with the current de-facto xpath implementations in
> the major browsers such as not properly handling namespaces, etc.  It
> does not have to do everything.  It has to be useful enough to be
> implemented by multiple providers.  If it is not, it will never become a
> specification.
>
> This discussion has reminded me that I need to submit XPath 2.0 issues
> again and see what comes of it.  And when that specification starts to
> get some of the big issues resolved, we all need to come back and look
> at it again.  I just scanned the spec and came up with a list that then
> I had to shorten because many already-known issues are still unresolved.
>
> Ray Whitmer
> rayw@netscape.com
>
>
>

Received on Monday, 1 April 2002 15:11:19 UTC