On Wednesday, 09/18/2002 at 11:18 MST, Vivek Pandey <[EMAIL PROTECTED]> wrote: > I found XPath API in xalan but they are not DOM L3 XPath API
Those aren't. I believe we have a version of the DOM L3 XPath API in development, but it probably isn't checked in yet. >I also saw the code of xalan3 at > org.apache.xerces.xpath.parser. They are XPath parser and provide XPath > API which works with DTM (not DOM). We _can_ process a DOM, if you pass us a DOMSource. As I said earlier, that's currently not very efficient but I'm working on improving it. > IMO, there should be DOM L3 XPath API implementation as part of xerces Agreed, a prototype of this functionality would be a good thing. (Note that it can only be a prototype since DOM3 isn't a Recommendation yet.) Whether that's implemented by calling Xalan under the covers or by implementing your own DOM-specific XPath processor's up to you. I would recommend the former as a starting point because, if nothing else, it'll be a lot faster to get running than writing your own XPath interpreter. > > > * The xpath implementation classes will be located at: > > > src/org/apache/xerces/dom/xpath. > > > > Not sure we need this new package. You _definitely_ need this package. DOM L3 is not a Recommendation yet. The API may continue to change. You really don't want to get into the question of what happens if you have the latest version and someone else has an earlier version, or vice versa, and odd effects arise depending on who's on the classpath first. We've been there. It was ugly. If it isn't a REC, don't use the REC's package name. Use a temporary package, pre-deprecated if you want to help warn folks that it is temporary. When the REC comes out, all they have to do is change their imports (assuming that you and they have been tracking the API and nothing else has been altered) and they're good to go. Meanwhile, you've avoided a LOT of support hassle. > The package org.apache.xpath.parser, looks generic xpath parser, please > correct me if i am worng. I think it should be more appropriate to keep it > in xml-commons. I think that's our long-term intent, as we replace the current parser with one generated directly from the XPath grammar. But I'm not sure whether the current version is really sufficiently stand-alone to be reused easily. Can't hurt to try, I suppose... As to whether xml-commons is the right place... I'm not sure. So far, xml-commons has mostly been standards. There *is* some intent to have it contain utility code ... but this is a pretty big chunk of code; it's unclear whether it should or shouldn't be in the standard xml-commons jarfile that some of us are hoping to support. ______________________________________ Joe Kesselman / IBM Research --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
