Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
