On Wednesday, 09/18/2002 at 11:29 MST, Vivek Pandey <[EMAIL PROTECTED]> wrote: > On Wed, 18 Sep 2002, Joseph Kesselman wrote: > > Well, Xalan is certainly intending to implement it, and I think we've got > > a prototype. Obviously our version wouldn't put the factory on the > > Document node; that needs modification of the DOM. One possible approach > > would be to have Xerces set up to check if Xalan is avaialble and leverage > > it if so. > > is this prototype DOM L3 XPath API? Where can i get hold of it?
I don't think it's checked in yet. Give us a little while longer... > Anyway, still it doesn't make easy to use XPATH API when someone uses > xerces and works on a DOM tree. Outside of the very first call in the process -- since we can't add a method to the Xerces DOM and can't change its list of supported features -- using this wrapper should be similar-to-identical, since it'll implement the DOM's APIs and behaviors. (Modulo bugs, and modulo the known fringe case of parentage of Namespace Nodes where Xalan anticipates XPath2 behavior rather than adhering to XPath1.) > Yes. DOM2DTM layer and liveness issue will make xpath uses from DOM > difficult and inefficient. DOM2DTM2 will address some of that. How well is still to be determined. > org.apache.xpath.parser looks like generic xpath parser. Would it not make > sense to move it to xml-commons? Then other xpath APIs can use it. See other note. We're switching to a new version of the parser, which may in fact be general enough to be worth sharing. There are questions about how best to achieve that. To Be Determined. ______________________________________ Joe Kesselman / IBM Research --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
