You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Elena Litani <el...@ca.ibm.com> on 2002/09/18 14:33:15 UTC
Re: DOM L3 XPATH implementation
Hi Vivek,
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...?
> * All xpath interfaces as defined by w3c are included in
> src/dom3/org/w3c/dom/xpath.
You will need to define a new build target, i.e. "xpath-dom3".
For PSVI for example we've created new PSVIDocumentImpl and
events/ranges/traversal is part of DocumentImpl.
> * The xpath implementation classes will be located at:
> src/org/apache/xerces/dom/xpath.
Not sure we need this new package. The reason that most DOM is in one
package is because we needed to access protected variables /methods or
the ones that have default accessibility.
So maybe it makes sense to put it to *dom* package.
> * XPathEvaluator implementation will be in a separate class and will not
> be implemented by w3c Document implementation class CoreDocumentImpl. This
> should be done to allow customization for custom variable and function
> context.
I am not sure what you mean, by definition:
[[
In a DOM implementation which supports the XPath 3.0 feature, as
described above, the XPathEvaluator interface will be implemented on the
same object which implements the Document interface permitting it to be
obtained by the usual binding-specific method such as casting or by
using the DOM Level 3 getInterface method
]]
Do you want to extend CoreDocumentImpl and make that class implement
XpathEvaluator?
If yes, then CoreDOMImplementationImpl.has feature should recognize
"XPath":
> * CoreDOMImplementationImpl.hasFeature modified to include "XPATH", "3.0".
Instead, you should create XPathDOMImplementationImpl. See how we handle
PSVI in DOM or events/ranges/traversal.
> * XPathResult
> With XPATH 2.0 the evaluate result XPathResult object seems to be the only
> class which will get impacted. Inorder to provide XPATH 2.0 support, the
> result object returned by XPathEvaluatorImpl can be java.lang.Object
> (inplace for XPathResult as defined in the interface). When XPATH 2.0
> result object (e.g. XPath20Result interface) is defined then it will be easier
> to use the existing API.
You should be able to access DOM-IG mailing list and you will find the
latest XPath *editors* copy there ( Tue, 20 Aug).
> * 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??
When implementing new features in the Xerces DOM you should be very
careful not to effect performance or memory. As a general rule you
should not add ANY fields to NodeImpl.
Thanks,
--
Elena Litani / IBM Toronto
Re: DOM L3 XPATH implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
On Wednesday, 09/18/2002 at 08:33 AST, Elena Litani <el...@ca.ibm.com>
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.
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.
(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."
> 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: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: DOM L3 XPATH implementation
Posted by Vivek Pandey <Vi...@Sun.COM>.
Makes sense. Thaks for pointing it out!
I see that the experimental interfaces like ls is in xercesImpl.jar.
the xpath interfaces will go in to org.w3c.dom.xpath.
thanks,
-vivek.
On Wed, 18 Sep 2002, Elena Litani wrote:
> Elena Litani wrote:
> > The W3C DOM XPath interfaces will be located in dom3/org/w3c/dom/xpath
> > package.
>
>
> Actually I am wrong on that one :). The Xpath API should go under
> org.w3c.dom.xpath package, where each interface marked as experimental.
> This is what we do with DOM Level 3 Load and Save. These packages are
> included in xercesImpl.jar not in xmlParserAPI.jar.
>
> We could not do it for DOM Core because of JAXP JSR compatibility
> issues.
> --
> Elena Litani / IBM Toronto
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
--
Vivek Pandey
XML & Webservices
Sun Microsystems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: DOM L3 XPATH implementation
Posted by Vivek Pandey <Vi...@Sun.COM>.
Makes sense. Thaks for pointing it out!
I see that the experimental interfaces like ls is in xercesImpl.jar.
the xpath interfaces will go in to org.w3c.dom.xpath.
thanks,
-vivek.
On Wed, 18 Sep 2002, Elena Litani wrote:
> Elena Litani wrote:
> > The W3C DOM XPath interfaces will be located in dom3/org/w3c/dom/xpath
> > package.
>
>
> Actually I am wrong on that one :). The Xpath API should go under
> org.w3c.dom.xpath package, where each interface marked as experimental.
> This is what we do with DOM Level 3 Load and Save. These packages are
> included in xercesImpl.jar not in xmlParserAPI.jar.
>
> We could not do it for DOM Core because of JAXP JSR compatibility
> issues.
> --
> Elena Litani / IBM Toronto
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
--
Vivek Pandey
XML & Webservices
Sun Microsystems, Inc.
Re: DOM L3 XPATH implementation
Posted by Elena Litani <el...@ca.ibm.com>.
Elena Litani wrote:
> The W3C DOM XPath interfaces will be located in dom3/org/w3c/dom/xpath
> package.
Actually I am wrong on that one :). The Xpath API should go under
org.w3c.dom.xpath package, where each interface marked as experimental.
This is what we do with DOM Level 3 Load and Save. These packages are
included in xercesImpl.jar not in xmlParserAPI.jar.
We could not do it for DOM Core because of JAXP JSR compatibility
issues.
--
Elena Litani / IBM Toronto
Re: DOM L3 XPATH implementation
Posted by Elena Litani <el...@ca.ibm.com>.
Elena Litani wrote:
> The W3C DOM XPath interfaces will be located in dom3/org/w3c/dom/xpath
> package.
Actually I am wrong on that one :). The Xpath API should go under
org.w3c.dom.xpath package, where each interface marked as experimental.
This is what we do with DOM Level 3 Load and Save. These packages are
included in xercesImpl.jar not in xmlParserAPI.jar.
We could not do it for DOM Core because of JAXP JSR compatibility
issues.
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: DOM L3 XPATH implementation
Posted by Elena Litani <el...@ca.ibm.com>.
Hi Joe,
Joseph Kesselman wrote:
> > > > * 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.
Vivek is thinking of adding xerces/dom/xpath package which will include
Xerces _implementation_ of XPath API, and I don't think we need to do
that since he might need to reference protected fields in xerces/dom/
package.
The W3C DOM XPath interfaces will be located in dom3/org/w3c/dom/xpath
package.
--
Elena Litani / IBM Toronto
Re: DOM L3 XPATH implementation
Posted by Elena Litani <el...@ca.ibm.com>.
Hi Joe,
Joseph Kesselman wrote:
> > > > * 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.
Vivek is thinking of adding xerces/dom/xpath package which will include
Xerces _implementation_ of XPath API, and I don't think we need to do
that since he might need to reference protected fields in xerces/dom/
package.
The W3C DOM XPath interfaces will be located in dom3/org/w3c/dom/xpath
package.
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: DOM L3 XPATH implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
On Wednesday, 09/18/2002 at 11:18 MST, Vivek Pandey <Vi...@Sun.COM>
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
Re: DOM L3 XPATH implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
On Wednesday, 09/18/2002 at 11:18 MST, Vivek Pandey <Vi...@Sun.COM>
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: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: DOM L3 XPATH implementation
Posted by Vivek Pandey <Vi...@Sun.COM>.
Hi Elina,
On Wed, 18 Sep 2002, Elena Litani wrote:
> Hi Vivek,
>
> 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...?
I found XPath API in xalan but they are not DOM L3 XPath API or may be i
missed them. 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).
IMO, there should be DOM L3 XPath API implementation as part of
xerces which will allow applications dealing with DOM tree manipulation
and xerces, do xpath query using DOM L3 XPath API.
>
> > * All xpath interfaces as defined by w3c are included in
> > src/dom3/org/w3c/dom/xpath.
>
> You will need to define a new build target, i.e. "xpath-dom3".
>
> For PSVI for example we've created new PSVIDocumentImpl and
> events/ranges/traversal is part of DocumentImpl.
>
ok. I will take a look at PSVI implementation.
> > * The xpath implementation classes will be located at:
> > src/org/apache/xerces/dom/xpath.
>
> Not sure we need this new package. The reason that most DOM is in one
> package is because we needed to access protected variables /methods or
> the ones that have default accessibility.
> So maybe it makes sense to put it to *dom* package.
>
ok.
>
> > * XPathEvaluator implementation will be in a separate class and will not
> > be implemented by w3c Document implementation class CoreDocumentImpl. This
> > should be done to allow customization for custom variable and function
> > context.
>
> I am not sure what you mean, by definition:
> [[
> In a DOM implementation which supports the XPath 3.0 feature, as
> described above, the XPathEvaluator interface will be implemented on the
> same object which implements the Document interface permitting it to be
> obtained by the usual binding-specific method such as casting or by
> using the DOM Level 3 getInterface method
> ]]
>
> Do you want to extend CoreDocumentImpl and make that class implement
> XpathEvaluator?
>
Yes. Thats what I meant by my above statement, sorry it was not obvious
from that.
> If yes, then CoreDOMImplementationImpl.has feature should recognize
> "XPath":
>
> > * CoreDOMImplementationImpl.hasFeature modified to include "XPATH", "3.0".
>
> Instead, you should create XPathDOMImplementationImpl. See how we handle
> PSVI in DOM or events/ranges/traversal.
>
ok. I will have a look at it.
>
> > * XPathResult
> > With XPATH 2.0 the evaluate result XPathResult object seems to be the only
> > class which will get impacted. Inorder to provide XPATH 2.0 support, the
> > result object returned by XPathEvaluatorImpl can be java.lang.Object
> > (inplace for XPathResult as defined in the interface). When XPATH 2.0
> > result object (e.g. XPath20Result interface) is defined then it will be easier
> > to use the existing API.
>
> You should be able to access DOM-IG mailing list and you will find the
> latest XPath *editors* copy there ( Tue, 20 Aug).
>
ok.
>
> > * 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??
>
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.
Other approach will be to write xpath parser in xerces and DOM L3 Xpath
uses it to query the DOM.
> When implementing new features in the Xerces DOM you should be very
> careful not to effect performance or memory. As a general rule you
> should not add ANY fields to NodeImpl.
>
ok. I have started and till now dont see need to make any changes
NodeImpl. I will keep posting my codes and changes for your feedback.
I understand, I will be sending all the new/modified code as zip file,
right? I am following java coding conventions, is there something I should
know specific to xerces as far as coding conventions goes?
thanks,
-vivek.
> Thanks,
> --
> Elena Litani / IBM Toronto
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
--
Vivek Pandey
XML & Webservices
Sun Microsystems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: DOM L3 XPATH implementation
Posted by Vivek Pandey <Vi...@Sun.COM>.
Hi Elina,
On Wed, 18 Sep 2002, Elena Litani wrote:
> Hi Vivek,
>
> 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...?
I found XPath API in xalan but they are not DOM L3 XPath API or may be i
missed them. 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).
IMO, there should be DOM L3 XPath API implementation as part of
xerces which will allow applications dealing with DOM tree manipulation
and xerces, do xpath query using DOM L3 XPath API.
>
> > * All xpath interfaces as defined by w3c are included in
> > src/dom3/org/w3c/dom/xpath.
>
> You will need to define a new build target, i.e. "xpath-dom3".
>
> For PSVI for example we've created new PSVIDocumentImpl and
> events/ranges/traversal is part of DocumentImpl.
>
ok. I will take a look at PSVI implementation.
> > * The xpath implementation classes will be located at:
> > src/org/apache/xerces/dom/xpath.
>
> Not sure we need this new package. The reason that most DOM is in one
> package is because we needed to access protected variables /methods or
> the ones that have default accessibility.
> So maybe it makes sense to put it to *dom* package.
>
ok.
>
> > * XPathEvaluator implementation will be in a separate class and will not
> > be implemented by w3c Document implementation class CoreDocumentImpl. This
> > should be done to allow customization for custom variable and function
> > context.
>
> I am not sure what you mean, by definition:
> [[
> In a DOM implementation which supports the XPath 3.0 feature, as
> described above, the XPathEvaluator interface will be implemented on the
> same object which implements the Document interface permitting it to be
> obtained by the usual binding-specific method such as casting or by
> using the DOM Level 3 getInterface method
> ]]
>
> Do you want to extend CoreDocumentImpl and make that class implement
> XpathEvaluator?
>
Yes. Thats what I meant by my above statement, sorry it was not obvious
from that.
> If yes, then CoreDOMImplementationImpl.has feature should recognize
> "XPath":
>
> > * CoreDOMImplementationImpl.hasFeature modified to include "XPATH", "3.0".
>
> Instead, you should create XPathDOMImplementationImpl. See how we handle
> PSVI in DOM or events/ranges/traversal.
>
ok. I will have a look at it.
>
> > * XPathResult
> > With XPATH 2.0 the evaluate result XPathResult object seems to be the only
> > class which will get impacted. Inorder to provide XPATH 2.0 support, the
> > result object returned by XPathEvaluatorImpl can be java.lang.Object
> > (inplace for XPathResult as defined in the interface). When XPATH 2.0
> > result object (e.g. XPath20Result interface) is defined then it will be easier
> > to use the existing API.
>
> You should be able to access DOM-IG mailing list and you will find the
> latest XPath *editors* copy there ( Tue, 20 Aug).
>
ok.
>
> > * 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??
>
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.
Other approach will be to write xpath parser in xerces and DOM L3 Xpath
uses it to query the DOM.
> When implementing new features in the Xerces DOM you should be very
> careful not to effect performance or memory. As a general rule you
> should not add ANY fields to NodeImpl.
>
ok. I have started and till now dont see need to make any changes
NodeImpl. I will keep posting my codes and changes for your feedback.
I understand, I will be sending all the new/modified code as zip file,
right? I am following java coding conventions, is there something I should
know specific to xerces as far as coding conventions goes?
thanks,
-vivek.
> Thanks,
> --
> Elena Litani / IBM Toronto
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
--
Vivek Pandey
XML & Webservices
Sun Microsystems, Inc.
Re: DOM L3 XPATH implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
On Wednesday, 09/18/2002 at 08:33 AST, Elena Litani <el...@ca.ibm.com>
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.
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.
(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."
> 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