W3C home > Mailing lists > Public > www-dom@w3.org > January to March 1999

Re: "Empty" Text Nodes

From: David Brownell <David.Brownell@Eng.Sun.COM>
Date: Fri, 5 Mar 1999 19:44:04 -0500 (EST)
Message-ID: <36E0793E.CBEB1E8A@eng.sun.com>
To: Arkin <arkin@trendline.co.il>
CC: www-dom@w3.org
> > I'd say it's clear that as written, DOM is attached to the application
> > rather than to the "XML Processor" (not parser!) level.
> 
> That's perfectly clear. The DOM does not attempt to cover the behavior
> of processors. But we're talking about real life situation where you
> either use some parser, any parser (e.g. SAX API), or get the document
> from some third-party library.

As Lauren said, terminology time.  XML and DOM specs cover
different territory and use different terminology to indicate
that.  An "XML Processor" must do certain things, and DOM must
do certain things, but there's no reason to expect that what
hands a DOM object to you be an XML processor rather than
some other sort of system component!


>	 You expect some common behavior, so you
> can write it once, run it everywhere.

This is an issue.  DOM isn't specified to be that portable yet,
and that needs to be addressed. 


> 	 The DOM specs relies on
> understanding and acquiantance with the XML specs. You can use the DOM
> alone if all you do is manage in-memory tree, but once you get into
> input/output and human readable files, you have to resort to the XML
> specs. We are, after all, talking about input/output.

The DOM spec does not talk about input/output!! ... even though
all applications must do so.  I'm hoping DOM will address this, but
haven't seen much support for it yet.


> It would be beneficial if the DOM API is extended to cover the SAX API,
> which seems to be commonly accepted and used. That would certainly clear
> up many issues. It would also be beneficial if the DOM API could
> recommend acceptable default behavior, which might be different in a
> browser and server-side environments, but consistent across all
> browsers.

I'm not alone in wanting to keep DOM and SAX separate!!  They're two
different APIs with extremely different processing models (and goals).

But I agree that the portability problems need to be resolved.

- Dave



> > > I think the W3C has the obligation to strictly clarify this point in the
> > > specification, so that: a) all parsers behave consistently,
> >
> > Make that "All DOM implementations behave consistently" and I'd be
> > far more inclined to agree!  It gets back to that testing/conformance
> > issue:  the DOM spec isn't testable without making certain assumptions
> > which are not supportable within scope of the spec.
> 
> Agreed.
> 
> >
> > - Dave
Received on Monday, 8 March 1999 04:48:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:46 GMT