You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xml-commons-dev@xerces.apache.org by Vivek Pandey <Vi...@Sun.COM> on 2002/09/17 23:09:58 UTC
Re: DOM L3 XPATH implementation (fwd)
Hi All,
I have started implementation work of DOM L3 XPATH 1.0
in my xerces 2.1 workspace.
Some points I want feedback on:
* All xpath interfaces as defined by w3c are included in
src/dom3/org/w3c/dom/xpath.
* CoreDOMImplementationImpl.hasFeature modified to include "XPATH", "3.0".
* The xpath implementation classes will be located at:
src/org/apache/xerces/dom/xpath.
* 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.
* 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.
public class XPathEvaluateImpl{
..
..
java.lang.Object(?) evaluate (String expression,
Node contextNode,
XPathNSResolver resolver,
short type,
java.lang.Object(?) result)
throws XPathException,
DOMException{
}
}
* Using org.apache.xpath packe in xalan for xpath parsing. is this
ok? or should i use org.apache.xpath.parser which seems to deal with
xpath2? Will it not be good if we have xpath parser in xml-commons which
both xerces and xalan use?
thanks,
-vivek.
>
> > I am sorry! I was not clear. By XSLT i meant Sun's xslt team! ok, i will
> > talk to Gopal to add you and Joseph Kesslman.
>
> Ah. My apologies. The XSLTC people are aware that we have been working on
> something, but we only got open source approval a couple of days ago, and
> so I wasn't able to divulge details, and haven't given them the full scoop
> yet. However, I don't think there's anything I said that I haven't
> discussed with the XSLTC team in the abstract. The DTM convergence isn't
> actually part of Xalan3/XSLT 2.0/XPath 2.0, and so they have been working
> fairly closely with us on that all along.
>
> > question: namespace::axis forms the part of expression. Even if they are
> > replaced by functions, can it not be abstracted in the
> > implementation/xpath parser?
>
> Yes, sure, if I get your meaning. I think you're just saying that the
> implementation can build the DOM3 namespace objects on the fly?
>
> But, my point is, if using the functions, there would be no namespace
> objects at all. You could just query information about the namespaces,
> like ask for the URL for a prefix, etc. (Again, this is just one proposal
> in the WG on the subject of namespaces).
>
>
> -scott
>
>
>
>
>
> Vivek Pandey
> <Vivek.Pandey@Sun To: scott_boag@us.ibm.com
> .COM> cc: elitani@ca.ibm.com, ilene@ca.ibm.com, keshlam@us.ibm.com, lmartin@ca.ibm.com,
> sun-ibm-xercesj@Sun.COM
> 07/31/2002 04:11 Subject: Re: DOM L3 XPATH implementation
> PM
> Please respond to
> Vivek.Pandey
>
>
>
>
>
>
> Hi Scott,
>
> scott_boag@us.ibm.com wrote:
> >>Gopal, are XSLT guys on sun-ibm-xerces alias? I am not sure if they are
> >>aware of xalan3 plan.
> >
> >
> > We're not. It would probably be a good thing if at least I was, and
> > probably keshlam@us.ibm.com (Joseph Kesslman) also.
>
> I am sorry! I was not clear. By XSLT i meant Sun's xslt team! ok, i will
> talk to Gopal to add you and Joseph Kesslman.
>
> >
> >
> >>What about issue of inscope namspace node with an element? I think its
> >>changed in XPATH 2.0. Then this will affect XPathNameSpace and
> >>XPathNSResolver. Comments?
> >
> >
> > I don't think it will effect the resolver. Actually, I don't think it
> will
> > effect XPathNameSpace either. But the namespace stuff still hasn't been
> > totally sorted out in XPath 2.0. Mainly I think it will effect what you
> > can traverse from a namespace node, and so will be largely buried in the
> > language semantics. There is a reasonable chance that the namespace::
> axis
> > will be deprecated altogether, replaced by various functions.
> >
> >
>
> ok.
>
> question: namespace::axis forms the part of expression. Even if they are
> replaced by functions, can it not be abstracted in the
> implementation/xpath parser?
>
> >>I would like to see the xalan xpath engine. Is it in CVS tree? Probably
> >>I will also like to do it from fresh.
> >
> >
> > In the Xalan 1.0 subproject of Xalan. It implemented 'STree', which was
> > our own implementation of the DOM, but could also traverse the DOM tree
> > directly.
> >
> >
> >>I have briefly saw xpath parser implementation with xalan.
> >
> >
> > The current one is old and awful (long story).
> >
>
> ok.
>
> >
> >>The other one
> >>is in the xerces impl package. I am not sure if they're same!
> >
> >
> > No, completely different. The one in the xerces package is meant to
> handle
> > only a thin 'streaming' subset of XPath, as specified by the schema
> > standard. But I think the parser itself can handle the full XPath
> syntax.
> >
> >
>
> I will go thru this.
>
> >>The one being worked on JavaCC/JJTree parser is in CVS? if not when can
> >>it be available?
> >
> >
> > Not yet. We'll be checking it in on a branch in the next couple of
> weeks.
> >
> >
> >>Which package its planned to go in to?
> >
> >
> > org.apache.xpath.parser. It might make sense to move the core parser
> > eventually to xml-commons.
> >
>
> Sounds good! Moving it to xml-commons is certainly a good idea. It will
> be better to plan about it so that after release in couple of weeks work
> can be started to move it to xml-commons for xerces DOM L3 xpath
> implementation to use this parser.
>
>
> > This parser is generated from an grammar written in XML
> (xpath-grammar.xml)
> > that we use to generate the XPath 2.0/XQuery 2.0 document specification
> BNF
> > (and it also describes XPath 1.0, as well as XSLT match patterns). The
> > JavaCC/JJTree code is generated from stylesheets that process the
> > xpath-grammar.xml. A pluggable factory allows you to create
> > implementation dependent parse tree nodes.
> >
>
> Thanks!
>
> I should have more questions after seeing xalan implementation and
> during implementation.
>
>
> -vivek.
>
>
>
> > -scott
> >
> >
> >
> >
> >
>
> > Vivek Pandey
>
> > <Vivek.Pandey@Sun To:
> scott_boag@us.ibm.com
>
> > .COM> cc:
> ilene@ca.ibm.com, elitani@ca.ibm.com, sun-ibm-xercesj@Sun.COM,
>
> > lmartin@ca.ibm.com,
> keshlam@us.ibm.com
> > 07/31/2002 03:27 Subject: Re: DOM L3 XPATH
> implementation
> > PM
>
> > Please respond to
>
> > Vivek.Pandey
>
> >
>
> >
>
> >
> >
> >
> >
> > Hi Scott,
> >
> > My comments inline blelow:
> >
> > scott_boag@us.ibm.com wrote:
> >
> >>Hi Vivek. I hope you don't mind that Ilene forwarded your note, and that
> >
> > I
> >
> >>respond directly.
> >
> >
> > Thats absolutely fine:)
> >
> >
> >>I don't know what the right answer is here, but we need
> >>to have an open dialog about to do.
> >>
> >>The current Xalan2 (and the upcoming Xalan3 which adds support for XSLT
> >>2.0) xpath implementation does not use the DOM directly. We use
> >
> > something
> >
> >>called the Document Table Model (DTM) which either reads directly from 1)
> >>SAX2, 2) XNI, and 3) a DOM tree. It views the input tree as arrays of
> >>indexes, is generally immutable, contains built-in iterators and
> >>"traversers" that are suited for XPath, and is generally tuned for
> >>incremental processing, lower memory overhead, and high performance.
> >
> > XSLTC
> >
> >>also uses a similar model, and we are in the process of unifying the two
> >>processors to use the DTM. Previous versions of Xalan used the DOM
> >>directly, and we found it very problematic. It is extremely unlikely
> >
> > that
> >
> >>we will adapt to using the DOM directly, or use the DOM3 XPath API
> >
> > (which,
> >
> >>BTW, does not pass enough context information to be used from an XSLT
> >>implementation). An additional complication is that we're refactoring
> >>Xalan to XSLT 2.0/XPath 2.0, and the DOM3 XPath API is only appropriate
> >
> > for
> >
> >>XPath 1.0 (the issue is mainly with the XPathResult object... a proposal
> >
> > is
> >
> >>on the table to allow the API to return a XPath20Result object, so this
> >
> > may
> >
> >>not be insurmountable).
> >
> >
> > ok. Thanks for this update! It helped me bring up to the speed with
> > xalan3 and xpath plan.
> >
> > Gopal, are XSLT guys on sun-ibm-xerces alias? I am not sure if they are
> > aware of xalan3 plan.
> >
> > What about issue of inscope namspace node with an element? I think its
> > changed in XPATH 2.0. Then this will affect XPathNameSpace and
> > XPathNSResolver. Comments?
> >
> >
> >>On the other hand, the Xalan XPath engine has a bit of a problem being
> >
> > used
> >
> >>as one-off queries with the DOM, because it has to construct a DTM
> >
> > adapter,
> >
> >>which is not as cheap as we would like, and has problems being used from
> >>one xpath evaluation to the next, without extra context information being
> >>passed. A further complication to reusing the DTM adapter is that
> >>mutations may occur inbetween invocations, which would invalidate the
> >>adapter data. So a lighter weight XPath implementation directly on the
> >
> > DOM
> >
> >>might not be at all inappropriate.
> >>
> >>I conclude from this:
> >>
> >>1) Since Xalan does implement a general purpose XPath implementation, we
> >>should go ahead and implement the DOM3 XPath API (it shouldn't be that
> >
> > much
> >
> >>work). This would not necessarily be the first choice of a user who
> >
> > wants
> >
> >>to query a DOM.
> >>
> >
> >
> > Ok.
> >
> >
> >>2) I would not at all mind seeing the Xerces DOM implement an XPath
> >>processing engine that is tuned to doing one-at-a-time DOM addressing.
> >>This is not totally trivial, and you may want to start with an existing
> >>implementation. One option would be to start with an early version of
> >
> > the
> >
> >>Xalan XPath engine, which used the DOM (though it would need cleanup and
> >>ripping out of some general adapters and caching constructs). I guess if
> >>it were me, I would start from scratch, and try to make the
> >
> > implementation
> >
> >>as tuned as possible for the DOM, and as lightweight as possible.
> >>
> >
> >
> > I would like to see the xalan xpath engine. Is it in CVS tree? Probably
> > I will also like to do it from fresh.
> >
> >
> >>3) One part that might be shared between these two is an XPath parser.
> >>We're working on a JavaCC/JJTree parser that would be reusable between
> >
> > the
> >
> >>two. On the other hand, Xerces already has a lightweight parser for use
> >
> > of
> >
> >>subset XPath in Schemas, that I think could be adapted to use with the
> >
> > DOM
> >
> >>XPath API.
> >>
> >
> >
> > I have briefly saw xpath parser implementation with xalan. The other one
> > is in the xerces impl package. I am not sure if they're same!
> >
> > The one being worked on JavaCC/JJTree parser is in CVS? if not when can
> > it be available? Which package its planned to go in to?
> >
> >
> > thanks,
> >
> > -vivek.
> >
> >
> >>Comments?
> >>
> >>-scott
> >>
> >>
> >>
> >>
> >>
> >
> >
> >> Ilene
> >
> >
> >> Seelemann@IBMCA To: Scott
> >
> > Boag/Cambridge/IBM@LOTUS
> >
> >> cc:
> >
> >
> >> 07/31/2002 12:57 Subject: Re: DOM L3 XPATH
> >
> > implementation
> >
> >> PM
> >
> >
> >
> >
> >>
> >>
> >>Scott,
> >>
> >>See Vivek's note, below.
> >>
> >>
> >>----- Forwarded by Ilene Seelemann/Toronto/IBM on 07/31/2002 12:54 PM
> >
> > -----
> >
> >
> >> Vivek Pandey
> >
> >
> >> <Vivek.Pandey@Sun To: Ilene
> >
> > Seelemann/Toronto/IBM@IBMCA, Elena Litani/Toronto/IBM@IBMCA
> >
> >> .COM> cc:
> >
> > Vivek.Pandey@Sun.COM, sun-ibm-xercesj@Sun.COMD
> >
> >
> >> Subject: Re: DOM L3 XPATH
> >
> > implementation
> >
> >> 07/31/2002 12:42
> >
> >
> >> PM
> >
> >
> >> Please respond to
> >
> >
> >> Vivek.Pandey
> >>
> >
> >
> >
> >>
> >>
> >>[included sun-ibm-xerces in CC]
> >>
> >>Elena/Ilene,
> >>
> >>is org.apache.xpath.domapi is implementation of org.w3c.dom.xpath?
> >>
> >>Or it defines DOM L3 xpath interfaces. I think you meant former. Please
> >>clarify.
> >>
> >>I think there should be implementation of org.w3c.dom.xpath APIs in
> >>xerces. An application developer using xerces parser may need to use dom
> >>l3 xpath and for this he should not work thru xalan.
> >>
> >>there can be 3 ways it can be done:
> >>
> >>1. xerces piggy-backs on xalan implementation
> >>
> >>2. implementation resides with xerces only and xalan uses it.
> >>
> >>3. Different implementations of DOM l3 xpath in xerces and xalan.
> >>
> >>Option 2 is preferable but since xalan already is working on it. So
> >>option (3) of having an implementation in xerces should be fine.
> >>
> >>What you guys think?
> >>
> >>
> >>thanks,
> >>
> >>-vivek.
> >>ilene@ca.ibm.com wrote:
> >>
> >>
> >>>Hi Vivek,
> >>>
> >>>Yes, Xalan is looking at implementing the DOM L3 XPath API. The
> current
> >>>thought on the package name is: org.apache.xpath.domapi. Since Xalan
> >>>already uses the package: org.apache.xpath, this should avoid conflicts
> >>>with xerces.
> >>>
> >>>Ilene.
> >>>------
> >>> XSLT Development, IBM Toronto Lab
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>> Vivek Pandey
> >>
> >>
> >>> <Vivek.Pandey@Sun To: Ilene
> >>
> >>Seelemann/Toronto/IBM@IBMCA
> >>
> >>
> >>> .COM> cc:
> >>
> >>Vivek.Pandey@Sun.COM, sun-ibm-xercesj@Sun.COM
> >>
> >>
> >>> Subject: DOM L3 XPATH
> >>
> >>implementation
> >>
> >>
> >>> 07/30/2002 06:41
> >>
> >>
> >>> PM
> >>
> >>
> >>> Please respond to
> >>
> >>
> >>> Vivek.Pandey
> >>
> >>
> >>
> >>
> >>>
> >>>Hi,
> >>>
> >>>I am in the process of implementing DOM L3 XPATH spec
> >>>(org.w3c.dom.xpath) in xerces-j. Elena gave me your pointer and
> >>>mentioned Xalan is considering implementing this API.
> >>>
> >>>Please let me know if DOM L3 XPATH API implementation is being
> >>>considered in xalan and if so then what package it will go to?
> >>>
> >>>thanks,
> >>>
> >>>-vivek.
> >>>
> >>>------------
> >>>Hi Vivek,
> >>>
> >>>Vivek Pandey wrote:
> >>>
> >>>
> >>>>Is DOM L3 XPath being implemented anywhere in apache?
> >>>
> >>>
> >>>I believe Xalan is considering implementing this API. For more
> >>>information you should contact Ilene Seelemann (ilene@ca.ibm.com).
> >>>
> >>>For now we don't have any plans to implement this API in Xerces.
> >>>
> >>>
> >>>Thank you,
> >>>-- Elena Litani / IBM Toronto
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
--
Vivek Pandey
XML & Webservices
Sun Microsystems, Inc.