Re: "Empty" Text Nodes

Lauren Wood wrote:
> 
> David Brownell wrote:
> >
> > I'd say it's clear that as written, DOM is attached to the application
> > rather than to the "XML Processor" (not parser!) level.
> 
> Terminology time: the DOM talks about the hosting implementation
> (e.g. browser, editor, server) and the client application (e.g. the
> script). 

And in the context of the XML specification, all of those are part
of the "application" except the bit that is an "XML Processor".

What the DOM spec call an application isn't what the XML spec calls
an application (any software using an XML processor).  If one were
to draw a picture using ASCII "art" (I know I'm stretching the term!)
it might look like this:

	XML term	Software	DOM Term
		    +----------------+
		    |    servlet     |
		    |    script      |
		    |	 etc.	     |	Application
		    +----------------+	-----------
		    |   DOM Impl &   |	Hosting Impl
	Application | other platform |
	----------- +----------------+
	Processor   |  "XML Parser"  |
		    +----------------+

That is, the relevant lines are drawn differently in the two specs,
such that there's lots of ambiguity about what is really required
from an implementation of DOM that provides access to XML ... even
beyond the issue of how to provide such access portably!

- Dave


>	The DOM defines the interface between these (some if it, at
> least). The DOM does not define what an XML parser/processor does;
> it can't define whether an XML processor chooses to pass on
> ignorable whitespace, for example, or comments.   I could imagine a
> browser that does not pass on comments, or that completely expands
> entity references before the DOM tree is even built, so that the DOM
> interfaces have no idea that the comments or parsed entities were
> present in the original source document.
> 
> The Level 2 work includes filters, which will help in some ways. For
> example, you can say you want to see the DOM tree without comments,
> or with entity references expanded. So this should help in getting
> rid of the differences between XML processors, and at a level where
> the DOM can say something.
> 
> The DOM spec can't add to the XML spec; what is defined as optional
> behaviour for an XML processor results in different DOM trees.
> 
> Lauren

Received on Friday, 5 March 1999 20:00:40 UTC