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 13:59:00 UTC