The Peace Process: DOM and namespaces...

James Clark jjc at
Fri Feb 12 02:47:46 GMT 1999

Yes.  Namespace processing doesn't need any information that isn't in
the DOM tree.  The layering does have a cost, but you can probably make
the layer pay for itself by also using it to handle things like:

- document order comparison (handy for some select patterns)

- expanding entities

- hiding the difference between CDATA and other text

- merging text nodes

- ignoring white-space only text nodes where required by XSL

- allowing navigation from an attribute to its owner element

Is it acceptable for your XSL processor to mutate the DOM for the source
document?  If so, there are alternatives that might be worth

Rick Ross wrote:
> One of the benefits we are trying to deliver to customers, however, is the
> ability to use any parser that offers a standard DOM and SAX
> implementations. Could this approach be implemented solely within our
> processor-side logic, and rely only on standard implementations of DOM Level
> 1 that exist in most of today's XML parsers?
> Rick
> James Clark wrote:
> >
> > Rick Ross wrote:
> >
> > > the XSL working draft
> > > specification requires  namespace support that apparently cannot be
> > > implemented effectively if the primary input source is a dynamically built
> > > DOM tree.
> >
> > I can't see this.
> >
> > Why can't you put a layer on top of the DOM that provides namespace
> > processing? For example, you could have an NSNode object that points to
> > the DOM Node and a set of prefix bindings (and probably a parent
> > NSNode).   The NSNode objects will be temporary.  You wouldn't have to
> > reparse the document, and you don't have to keep two trees in memory.
> > You can also provide other things in this layer that help XSL
> > performance such as document order comparison.
> >
> > James

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list