Re: Difference in DOM's

Heading back to what I just can't see at all:   DOM L2 may 
mention some end result ... but without defining the APIs used
to achieve it, that's not helpful.  And it's worse for the
XML DOM, which has a much wider range of "OK behaviors" with
which to foster portability problems.

Presumably some later DOM will eventually fix this (as I
think we heard a while back :-) but until then, this sort
of issue is smack at the heart of what makes DOM not be a
portability solution even for the simplest web applications:
you can't even bootstrap without relying on proprietary APIs.

- Dave


----- Original Message ----- 
From: "Lauren Wood" <lauren@sqwest.bc.ca>
To: <www-dom@w3.org>
Sent: Friday, 1 September, 2000 10:17 AM
Subject: Re: Difference in DOM's


> On 1 Sep 2000, David Brownell wrote:
> 
> > What W3C DOM API produces a DOM tree given an input
> > source document?  The closest I see to that is the
> > HTMLDocument.{open,close,write,writeln}, and that
> > clearly doesn't work for XML ... and of course, there
> > would still be the bootstrapping problem of how to
> > get one's hands on an HTMLDocument without relying
> > on some other non-DOM (proprietary, ...) API.
> 
> OK, now I get the problem. You're right, the HTML DOM doesn't 
> define *how* to get to the internal structure model that allows the 
> HTML DOM API to act on it to create elements etc. However, it 
> does define pretty clearly (at least, I think it does) *what* you 
> should find once you get there. So, although it doesn't define the 
> process, it does define the end result. 
> 
> 
> Lauren
>

Received on Friday, 1 September 2000 13:44:36 UTC