Wish lists for the Holidays

[Francis Norton]

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 at fourthought.com 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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)