Cart
[Home] [By Thread] [By Date] [Recent Entries]
uche.ogbuji@f... wrote: > > > As David Brownell points out, this could be achieved by having an > > xpath-in-DOM implementation that ran on top of your DOM. That way your > > xpath expressions could return live DOM nodes and you'd avoid DOM bloat. > > Though I'm not sure that such a nicely de-coupled approach would be as > > efficient as the messier bloatware implementations that do it all in > > one? > > I very often run into non-rigourous invocations of "DOM bloat". Note that > DOM is a very large interface, ... and constantly adding more functionality to it is the "bloat" to which I referred. The point's been raised that some of the current functionality might well be completed, before adding any newer functionality. (Everything DTD-related is incomplete, since one can't start with an empty DOM tree and add those functionalities without requiring proprietary extensions.) There's a concept called "software layering" that I adhere to -- I'm sure you know it well. Modules can use DOM without being bundled into DOM itself. XPath can (and IMHO should) be such a layer. - Dave 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 unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
