Re: Difference in DOM's

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.

- Dave

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


> On 1 Sep 2000, at 9:45, David Brownell wrote:
> 
> > Lauren, since DOM doesn't include parsing APIs,
> > I don't know how you can claim "you'll get the
> > same trees" ... all APIs to turn *ML text into a
> > DOM tree are by definition proprietary at this
> > time (or at least must be promulgated by some
> > non-W3C group).
> 
> I think for HTML you should get the same tree, since most of the 
> optional things (e.g., entities) are in XML, not HTML. I guess some 
> processors could decide to throw out comments, although the 
> HTML processors I know of don't. The HTML DOM module 
> specifies a few things that need to be in the tree, such as the 
> TBODY elements, which may not be in the source document, so I 
> can't think of any place (again, modulo comments) where you 
> would get variations on the tree of a *valid* (not just "good") HTML 
> 4.0 document. Can you point some concrete places out to me that 
> the HTML module doesn't explicitly cover?
> 
> 
> Lauren
>

Received on Friday, 1 September 2000 13:09:53 UTC