Re: XPath DOM and XPath 2.0 (Was Re: Comments on DOM XPath Interface)

At 2:32 PM -0800 3/29/02, Ray Whitmer wrote:


>This current XPath DOM specification is supported in the Mozilla 1.0 
>release, and that implementation has undergone many changes to match 
>every time there were legitimate reworkings of the specification. 
>The standardization efforts would seem wasted if those who have 
>stood on the sidelines without meaningful discourse or apparent 
>interest were permitted to now kill the specification at this late 
>date.  This is why the decision was made by the working group early 
>on based upon the realities rather than wishful thinking.  Feedback 
>has been taken from users all along the way, and I have seen nothing 
>yet to cause any realistic regret of that decision.
>

I think it's very symptomatic of W3C working groups that on the one 
hand you're complaining that the XPath 2.0 working group won't listen 
to you and on the other hand you're turning around and refusing to 
listen to them.

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.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

Received on Saturday, 30 March 2002 08:49:15 UTC