W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2000

Re: Difference in DOM's

From: David Brownell <david-b@pacbell.net>
Date: Fri, 1 Sep 2000 10:44:25 -0700
Message-ID: <000c01c0143c$44ffc520$6500000a@brownell.org>
To: <lauren@sqwest.bc.ca>, <www-dom@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:07 UTC