Cart
[Home] [By Thread] [By Date] [Recent Entries]
Yes, I'm guessing that the interoperability here depends on using these two specific implementations. "Architectural" was my hand-wavy way of saying that I was wondering about a solution that was implementation independent. 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? BTW, I like the factory proposal that you recommended to Lauren Wood to avoid spec bloat. Thanks - Francis. uche.ogbuji@f... wrote: > > > I get the impression that my desire to have xpath included in the DOM > > may be naive, but I haven't yet formed a clear picture of the > > alternatives. Is there an architectural solution which would allow one > > to plug any arbitrary (but compatible) xpath processor in to a DOM > > processor? And then use it to select nodes from a document that has been > > opened in the DOM, and then update those nodes using the DOM? > > I don't know whether it's what you term an "architectural solution", but > 4XPath and 4DOM allow such manipulation right now: > 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...)
|
