On Wed, 18 Sep 2002, Joseph Kesselman wrote:

> On Wednesday, 09/18/2002 at 08:33 AST, Elena Litani <[EMAIL PROTECTED]>
> wrote:
> > Vivek Pandey wrote:
> > > I have started implementation work of DOM L3 XPATH 1.0
> > > in my xerces 2.1 workspace.
> >
> > To my knowledge Xalan already implements this API. So I am wondering if
> > we should implement it in Xerces...?
>
> 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 pulled
xalan3 workspace and found org.apache.xapth and org.apache.xpath.parser.

Anyway, still it doesn't make easy to use XPATH API when someone uses
xerces and works on a DOM tree.

>
> Currently Xalan's performance against DOMs is not wonderful; when we
> switched back to DTM we did so in a bit of a hurry and the DOM2DTM layer
> is somewhat inefficient as a result, especially if you want to run
> multiple XPaths against a DOM and change the DOM between those calls. I'm
> currently looking at whether we can improve that.
>

Yes. DOM2DTM layer and liveness issue will make xpath uses from DOM
difficult and inefficient.

> (Our biggest hassle is the difficulty of associating a DOM Object
> reference with a DTM Node-Handle integer. My prototype's currently
> leveraging Xerces' prototype of DOM3 named userData -- not blindingly
> fast, unfortunately. May try a DOM-subclassing solution next, after I've
> got the framework running.)
>
> > > * XPathEvaluator implementation will be in a separate class and will
> not
> > > be implemented by w3c Document implementation class CoreDocumentImpl.
>
> That's basically the approach Xalan is taking in its prototype.
> XPathEvaluator was specifically designed so it could be implemented by the
> Document node (in which case you can say the DOM actually supports this
> feature) or as a stand-alone (in which case the DOM does NOT support the
> feature, since obtaining the evaluator requires custom code... but the
> rest of the user code should be mostly compatable).
>
> > > * Using org.apache.xpath packe in xalan for xpath parsing. is this
> > > ok?
> >
> > I am not sure what do you mean? You are implementing this code in
> > Xerces, so how can you use the Xalan package??
>
> This may be my suggestion above of "Check whether the Xalan package is
> available -- eg via reflection -- and leverage it if so; if not, return
> feature-not-supported."
>

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.

thanks,

-vivek.

> > As a general rule you should not add ANY fields to NodeImpl.
>
> As I say, I'd _really_ like to add an integer node-ID for my own
> project... but I'm looking at userData and subclassing as possible
> solutions, and trying to design my code so it can plug in the appropriate
> module for whatever solution is available.
>
> ______________________________________
> Joe Kesselman  / IBM Research
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Vivek Pandey
XML & Webservices
Sun Microsystems, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to