You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by il...@ca.ibm.com on 2002/09/20 15:54:07 UTC
Prototype DOM L3 XPath Implementation
Hi,
I have just committed, to xml-xalan, a prototype implementation of the DOM
L3 XPath Specification.
The interfaces org.w3c.dom.xpath.* are being picked up from xercesImpl.jar.
The implementing classes can be found in the org.apache.xpath.domapi
package. One possible usage would be as follows. There are other
variations, such as using the evaluate method on XPathExpression instead of
XPathEvaluator. (I hope the formatting isn't too terrible...)
// Set up a DOM tree to query.
InputSource in = new InputSource(new FileInputStream(filename));
DocumentBuilderFactory dfactory = DocumentBuilderFactory.newInstance
();
dfactory.setNamespaceAware(true);
Document doc = dfactory.newDocumentBuilder().parse(in);
// some xpath expression
String xpath = "/";
// pass the document to the XPathEvaluatorImpl constructor to
parallel the case where XPathEvaluator was obtained by casting a document.
XPathEvaluator xpathEvaluator = new
org.apache.xpath.domapi.XPathEvaluatorImpl(doc);
XPathResult result = (XPathResult)xpathEvaluator.evaluate(xpath, doc,
xpathEvaluator.createNSResolver(doc),
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);
Node n;
int j = 0;
while (j < result.getSnapshotLength())
{
n = result.snapshotItem(j++);
// do something with node
}
The XPathNamespace node interface has not been implemented (yet?)
Otherwise, it should be reasonably conformant, but it still needs work. I
welcome feedback!
Ilene Seelemann.
------
IBM Toronto Lab
Internet: ilene@ca.ibm.com
Re: Prototype DOM L3 XPath Implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
Answered on the Xalan list; I think I forgot to hit reply-to-all so it may
not get here. Brief summary:
1) There's nothing wrong with having both an implemention directly in the
Xerces DOM, optimized for that DOM, and a
generic-but-possibly-less-efficient version provided via Xalan.
2) Some form of mutation notification is necessary internally. How that's
achieved is implementation dependent. The portable solution for the
generic version is DOM Mutation Events. Internally, other options may
exist; see how we implemented liveness of deep nodelists, for example. (In
my other note, I said named node maps; chalk that up to lack of caffeine.)
______________________________________
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: Prototype DOM L3 XPath Implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
(Oops. When I said NamedNodeMaps, strike that and replace with "deep
nodelists". Also "oops" that this wasn't copied to both mailing lists;
mornings recapitulate philogeny.)
______________________________________
Joe Kesselman / IBM Research
Re: Prototype DOM L3 XPath Implementation
Posted by Joseph Kesselman <ke...@us.ibm.com>.
> In XPathResult.getInvalidIteratorState() implementation, its assuming
the
> doc being event target. but it may not be necessary as per DOM L3 XPATH
> interface DOM L2 Core is the only mandatory requirement for DOM XPATH
> implementation. So what would be other way to find out if the document
is
> modified to mark the iterator state invalid?
Saying that L2 Core is the only mandatory DOM requirement only means that
it is the only requirement which must be exposed to the user.
Other dependencies may exist -- and generally will, since as you point out
the DOM XPath API must be able to track DOM mutation and invalidate its
iterators. Exactly how that's done is entirely up to the implementation.
The "other way" would be to use something unique to that particular DOM
implementation, such as the lightweight "version count" mechanism
currently used in the Xerces DOM to invalidate NamedNodeMaps.
> what does the community feels about DOM L3 XPATH being in xerces or in
> xalan or both.
Two different cases, not in conflict with each other. The version in Xalan
is intended to be generic and to run against *any* Level 2 DOM -- but that
generality may make it less efficient than one built directly into the
Xerces DOM would be, and does mean the process of initially obtaining the
objects is a bit different.
There's nothing wrong with implementing both. There's also also nothing
wrong with implementing the Xerces version so it calls Xalan internally,
if that suits your needs. (It may; it may not)
______________________________________
Joe Kesselman / IBM Research
Re: Prototype DOM L3 XPath Implementation
Posted by Vivek Pandey <Vi...@Sun.COM>.
Hi Ilene,
I just updated my xalan workspace and saw this prototype. Actually I am
also implementing similar (DOM L3 XPATH API) prototype and intend it to go
to org.apache.xerces.dom workspace.
I have not gone thru all the interfaces. So I dont have all the feedback
but I have a question about XPathResult.getInvalidIteratorState()
method...
In XPathResult.getInvalidIteratorState() implementation, its assuming the
doc being event target. but it may not be necessary as per DOM L3 XPATH
interface DOM L2 Core is the only mandatory requirement for DOM XPATH
implementation. So what would be other way to find out if the document is
modified to mark the iterator state invalid?
what does the community feels about DOM L3 XPATH being in xerces or in
xalan or both.
Either this prototype can become part of xercesImpl.jar or we do one for
xerces.
Problem with former would be DTM layer, XPathEvaluator being part of
document (but I think its ok, as XPathEvaluator implementation can come
from outside). I see references of DTM in XPathExpression.evaluate()
method.
IMO, I prefer latter which is DOM L3 XPATH being part of xerces. Here
XPathEvaluator is implemented by the document and works directly on the
DOM tree.
Comments?
-vivek.
On Fri, 20 Sep 2002 ilene@ca.ibm.com wrote:
> Hi,
>
> I have just committed, to xml-xalan, a prototype implementation of the DOM
> L3 XPath Specification.
>
> The interfaces org.w3c.dom.xpath.* are being picked up from xercesImpl.jar.
> The implementing classes can be found in the org.apache.xpath.domapi
> package. One possible usage would be as follows. There are other
> variations, such as using the evaluate method on XPathExpression instead of
> XPathEvaluator. (I hope the formatting isn't too terrible...)
>
> // Set up a DOM tree to query.
> InputSource in = new InputSource(new FileInputStream(filename));
> DocumentBuilderFactory dfactory = DocumentBuilderFactory.newInstance
> ();
> dfactory.setNamespaceAware(true);
>
> Document doc = dfactory.newDocumentBuilder().parse(in);
>
> // some xpath expression
> String xpath = "/";
>
> // pass the document to the XPathEvaluatorImpl constructor to
> parallel the case where XPathEvaluator was obtained by casting a document.
> XPathEvaluator xpathEvaluator = new
> org.apache.xpath.domapi.XPathEvaluatorImpl(doc);
> XPathResult result = (XPathResult)xpathEvaluator.evaluate(xpath, doc,
> xpathEvaluator.createNSResolver(doc),
> XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);
>
> Node n;
> int j = 0;
> while (j < result.getSnapshotLength())
> {
> n = result.snapshotItem(j++);
> // do something with node
> }
>
>
> The XPathNamespace node interface has not been implemented (yet?)
> Otherwise, it should be reasonably conformant, but it still needs work. I
> welcome feedback!
>
>
> Ilene Seelemann.
> ------
> IBM Toronto Lab
> Internet: ilene@ca.ibm.com
>
>
> ---------------------------------------------------------------------
> 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: Prototype DOM L3 XPath Implementation
Posted by Vivek Pandey <Vi...@Sun.COM>.
Hi Ilene,
I just updated my xalan workspace and saw this prototype. Actually I am
also implementing similar (DOM L3 XPATH API) prototype and intend it to go
to org.apache.xerces.dom workspace.
I have not gone thru all the interfaces. So I dont have all the feedback
but I have a question about XPathResult.getInvalidIteratorState()
method...
In XPathResult.getInvalidIteratorState() implementation, its assuming the
doc being event target. but it may not be necessary as per DOM L3 XPATH
interface DOM L2 Core is the only mandatory requirement for DOM XPATH
implementation. So what would be other way to find out if the document is
modified to mark the iterator state invalid?
what does the community feels about DOM L3 XPATH being in xerces or in
xalan or both.
Either this prototype can become part of xercesImpl.jar or we do one for
xerces.
Problem with former would be DTM layer, XPathEvaluator being part of
document (but I think its ok, as XPathEvaluator implementation can come
from outside). I see references of DTM in XPathExpression.evaluate()
method.
IMO, I prefer latter which is DOM L3 XPATH being part of xerces. Here
XPathEvaluator is implemented by the document and works directly on the
DOM tree.
Comments?
-vivek.
On Fri, 20 Sep 2002 ilene@ca.ibm.com wrote:
> Hi,
>
> I have just committed, to xml-xalan, a prototype implementation of the DOM
> L3 XPath Specification.
>
> The interfaces org.w3c.dom.xpath.* are being picked up from xercesImpl.jar.
> The implementing classes can be found in the org.apache.xpath.domapi
> package. One possible usage would be as follows. There are other
> variations, such as using the evaluate method on XPathExpression instead of
> XPathEvaluator. (I hope the formatting isn't too terrible...)
>
> // Set up a DOM tree to query.
> InputSource in = new InputSource(new FileInputStream(filename));
> DocumentBuilderFactory dfactory = DocumentBuilderFactory.newInstance
> ();
> dfactory.setNamespaceAware(true);
>
> Document doc = dfactory.newDocumentBuilder().parse(in);
>
> // some xpath expression
> String xpath = "/";
>
> // pass the document to the XPathEvaluatorImpl constructor to
> parallel the case where XPathEvaluator was obtained by casting a document.
> XPathEvaluator xpathEvaluator = new
> org.apache.xpath.domapi.XPathEvaluatorImpl(doc);
> XPathResult result = (XPathResult)xpathEvaluator.evaluate(xpath, doc,
> xpathEvaluator.createNSResolver(doc),
> XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);
>
> Node n;
> int j = 0;
> while (j < result.getSnapshotLength())
> {
> n = result.snapshotItem(j++);
> // do something with node
> }
>
>
> The XPathNamespace node interface has not been implemented (yet?)
> Otherwise, it should be reasonably conformant, but it still needs work. I
> welcome feedback!
>
>
> Ilene Seelemann.
> ------
> IBM Toronto Lab
> Internet: ilene@ca.ibm.com
>
>
> ---------------------------------------------------------------------
> 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