RE: DOM 2 and .NET

[Joshua Allen <joshuaa@microsoft.com>]

> > In the case of the "extra" stuff, pretty much every DOM
implementation
> > adds some extra stuff to cover things not covered in the spec, such
as
> > loading, saving, XPath, etc.  These particular three have
> > been in MSXML
> 
> (which after all, are proprietary) focused on implementing better
> implementations of the actual DOM specs.

Do you mean more complete implementations?  Your frustrations with
coding to different DOM specs and having to maintain three different
bodies of code are something I can sympathize with -- for W3C/DHTML DOM.
In my experience, though, the major popular XML DOM implementations are
pretty much 100% complete.  I haven't experienced any of the major XML
DOMs having gaps in spec support, and if any of them do, that should be
considered a bug and should be fixed by the vendor that ships that DOM.
So if there are things in the XML DOM spec that are not implemented is
MS XML DOM (for example), then we need to fix that.

Now, if we are talking about the *other* DOM (the one used for
manipulating HTML in a web browser) that predates XML DOM, it is another
story.  There is the Microsoft DHTML DOM, then in IE5+ there is partial
support for W3C DHTML DOM, and same issue in Netscape -- in Netscape 6
there is partial support for W3C DOM that is partially disjoint from the
support in IE5+, and previous versions of Netscape have a DOM that is
Netscape specific.  Basically, it is so complicated to write
cross-platform DHTML that many people would rather just use Flash.

> money just to take the responsibility of an open web on my shoulders,
> because vendors don't play fair. These vendors are actually making my
> life harder. They offer me non-compliant ways to make my work easy.
Wow.
> And if I choose them, I either have to promote only their side of the
> bank, or work twice as hard to promote all. They are all blackmailing
> me, while earning from me for pushing their platform.

This is perhaps an unfair characterization.  You can think of
standards/specs as treaties between competitors (individuals and
companies) for the benefit of the people who use their products.  In
other words, what makes it into the spec is what all of the competitors
can agree on.  It's unrealistic to think that a spec or standard could
list every feature that you might ever want.  It's equally unrealistic
to think that the competitors sitting around the standardization table
would all agree on every single feature that they think their users will
want.  Competitors disagree on certain things, and different users want
different things (and that is a very good thing by the way).  So the
spec just documents the lowest common denominator that everyone can
agree upon.

> sell their platform and build their earnings on their
> super_duper_but_also_closed semi-compliant specs. Consortiums could
have
> placed restrictions or penalties on vendors that take advantage of the

Well, I think this idea of companies getting rich from "closed
semi-compliant" specs is not always true.  In fact, I would argue that
the complete mess we had with DHTML DOMs has been very bad for both
Microsoft *and* Netscape.  In my opinion, it is a major factor in the
surging popularity of the proprietary Flash format.  And the DHTML mess
has *unquestionably* held back the growth of the web, as developers
become frustrated, paralyzed with indecision, and disenchanted.  It's
really hard for me to see how repeating that mess with XML DOM would be
in *anybody's* best interest.

With XML DOM, it seems that all of the vendors are obsessed with
avoiding mistakes of the past, and (at least in my happy sheltered
world) it seems to be working.  I also think that there is a universe of
difference between a half-implemented spec (evil) and a
fully-implemented spec that has added stuff to differentiate (good,
especially if such additions are documented as such).

Regards,
Joshua