xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nn" <nna...@comcast.net>
Subject Re: bug fix for XPath using Namespace
Date Tue, 22 Jun 2004 01:40:13 GMT
Eric,
I have done this SAXON and XMLBeans integration to support XPath 2.0, XQuery
1.0 and XSLT.
The easiest integration is using newDomNode and passing the Dom object to
SAXON's net.sf.saxon.dom.DocumentWrapper. That's all.

The problem of this approach is when XPath, like ./a/b is eavaluated, it
returns wrapper objects of b node, not object of B generated by XMLBeans.
Also if we modify the returned b node, it won't change the original content
of the target document.
Replacing newDomNode by getDomNode may resolve this asigenment problem, but
I felt it is not satisfactory solution. At least current Jaxen based
approach will return actual object of B, and We can use this object to
change the state through assignement for B object.
This approach is not faborable in XML binding context, we will again start
using typeless XML object.

I tried another approach which returns B object like Jaxen based selectPath
implemenation for SAXON.
This was implemented simulating NodeWrapper class implementation for XMLBean
object, basically XmlObject.
The wrapper needed to implement a few DOM like API, getChildren, getParent
etc, but full API implementation was not necessary.
This approach worked, but when compared the performance with other DOM,
JDOM, and JAXEN based implementation, it was quite slow, compared to
DOM,JDOM, it was 1/2, and compared to JAXEN, it was about 1/10 th of the
performance. One of the major bottle neck was repeated evaluation of
getChilden, since in DOM, HDOM, these are 'cached', but in XMLBeans case, it
is always calculated through XmlCursor.
These may be improved if we introduced cache for the wrapper. But this was
also not so satisfactory since when the same XmlObject is passed to SAXON,
the wrapper's cache are no longer used, and the wrppaer must be rebuild for
the evaluation.

So the best approach will be to have implementation for NodeWrapper
interface by XmlObject itself. (no need to implement DOM API for XmlObject
for this purpose), since it can use the cache(getChildren etc) again and
again. no need to cretae wrapper for each XPath(XQuery) evaluation.

I have almost done this using AspectWerkz introduction AOP feature(adding
interface implementation dynamically or statically though post processing of
the class files), but because of some bug of AspectWerkz, I could not finish
this. (though this bug was fixed for unstable head version, but not for
stable version!)
So anyway the idea is that if we use new feature of XMLBeans to implement
interface at code generation time(?),
we may take the similar approach without AOP.

nn

----- Original Message ----- 
From: "Eric Vasilik" <ericvas@bea.com>
To: <xmlbeans-dev@xml.apache.org>
Sent: Monday, June 21, 2004 5:24 PM
Subject: RE: bug fix for XPath using Namespace


It seems that having a live DOM implementation would ease the
integration of Saxon, but we're not there yet on that feature.  I expect
that in a month or two the live DOM and the new store will be online.
This is why Jaxen would be used in the interim.

- Eric

> -----Original Message-----
> From: Noah Campbell [mailto:noahcampbell@gmail.com]
> Sent: Monday, June 21, 2004 5:15 PM
> To: xmlbeans-dev@xml.apache.org
> Subject: Re: bug fix for XPath using Namespace
>
> Excuse my ignorance, but why not implement saxon up front?  Why create
> a jaxen based Xpath engine and then rip it out again?
>
> I like the idea of the XbeanXPath implementation, but that would seem
> like a Jaxen feature and be unrelated to the xmlbeans project.
>
> My 2 cents,
> Noah
>
> On Mon, 21 Jun 2004 16:48:04 -0700, Eric Vasilik <ericvas@bea.com>
wrote:
> >
> > Let me try to shed a little light on the history of selectPath in
Apache
> > XmlBeans.
> >
> > When we donated Xmlbeans to Apache, I had to remove the XQuery
support
> > that BEA had build into XmlBeans because we could not donate the
XQuery
> > engine at the same time.
> >
> > At that time, we were using xqrl.jar (an internal BEA xquery engine)
to
> > implement the functionality behind execQuery and selectPath.  Now,
it
> > turns out that the interface between XmlBeans and this XQuery engine
was
> > not as fast as we wanted to it be for simple paths.  So, I wrote a
very
> > high performance xpath engine which could handle simple paths
(foo/bar,
> > or .//foo, for example).  This high performance engine could not
handle
> > predicates, for example.  In addition to making simple paths fast,
we
> > also used this path engine to help implement Xml Schema identity
> > constraint validation.
> >
> > Now, when I prepared Xmlbeans for donation, I neglected to unhook
this
> > fast path engine from the selectPath api.  It was there only to
> > accelerate simple path, and was not complete.  My intention was to
> > remove execQuery and selectPath until a later date when we could
hook up
> > some other engine.
> >
> > Furthermore, this engine did not really implement any sanctioned
dialect
> > of XPath, it implemented a subset of the XQuery spec of the time.
In
> > particular, it allows one to declare namespaces before the path
> > specification.  Like:
> >
> >    declare namespace foo = "foo.com" .//foo:bar
> >
> > Would be a legal path expression.  When I look at the XPath 1.0 and
2.0
> > specifications, I do not see this kind of syntax allowed.  It seems
that
> > the XQuery folks allow it for queries, but not for paths.  This is a
> > shame because one cannot write a self contained path expression.
One
> > must programmatically specify some kind of prefix resolver for the
path
> > expression.  I liked the way XQuery declaratively allowed one to
give
> > definitions to prefixes.
> >
> > Now, after the donation, someone recognizes that the implementation
of
> > selectPath is incomplete.  So, we decide to hook Jaxen up, but we
don't
> > provide a way to supply a prefix resolver.  This leaves selectPath
> > nearly useless for documents which use namespaces.  And, we're not
using
> > XPath 1.0 when BEA's version of XPath effectively implemented xpath
2.0.
> > I would rather not have such differences.
> >
> > I think the right way to go from here is to:
> >
> > 1) Allow one to pass in a prefix resolver map as an XmlOption to
> > selectPath.  You can obtain such a map from the
> > XmlCursor.getAllNamespaces method.
> >
> > 2) Before passing the path onto Jaxen, perform a check for namespace
> > declarations (ala XQuery), peel them off and automatically supply
these
> > namespaces as the prefix resolver.
> >
> > 3) At some point in the future, switch over to an XPath 2.0 engine.
> > Perhaps Saxon.  And, perhaps, implement execQuery as well.
> >
> > Comments?
> >
> > - Eric
> >
> >
> >
> > > -----Original Message-----
> > > From: nn [mailto:nnakae@comcast.net]
> > > Sent: Monday, June 21, 2004 11:50 AM
> > > To: xmlbeans-dev@xml.apache.org
> > > Subject: Re: bug fix for XPath using Namespace
> > >
> > > Maybe I  need to understand how these context dependent features
are
> > used
> > > in
> > > XMLBeans application.
> > > I'm assuming it is used only from outside of XML docment.
> > > Although you provide an exmple of XPath which is used as part of
XSLT,
> > I
> > > think XMLBeans won't be used that way.
> > >
> > > nn
> > >
> > > ----- Original Message -----
> > > From: "David Waite" <mass@akuma.org>
> > > To: <xmlbeans-dev@xml.apache.org>
> > > Sent: Monday, June 21, 2004 11:02 AM
> > > Subject: Re: bug fix for XPath using Namespace
> > >
> > >
> > > > The context of an xpath (current position, functions, variables,
and
> > > > namespace/prefix mappings) is a function of how the xpath
expression
> > is
> > > > used, not of the document it is operating on.
> > > >
> > > > -David Waite
> > > >
> > > > On Jun 21, 2004, at 11:33 AM, nn wrote:
> > > >
> > > > > Cezar,
> > > > > Why is it necessary to make XPath independent from the
XmlObject?
> > > > > Typically XPath (XSLT) assumes XML document structure
implicitly.
> > > > > Then why do we need to make namespace independent from
XmlObject?
> > > > >
> > > > > nn
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Cezar Andrei" <cezar@bea.com>
> > > > > To: <xmlbeans-dev@xml.apache.org>
> > > > > Sent: Friday, June 18, 2004 7:00 AM
> > > > > Subject: RE: bug fix for XPath using Namespace
> > > > >
> > > > >
> > > > > The problem with this approach is that the user of the
selectPath
> > > > > method has
> > > > > to know for sure what prefixes and namespaces are used in the
> > > > > XmlObject.
> > > > >
> > > > > I think the prefixes in xpath expressions a independent from
the
> > ones
> > > > > in the
> > > > > document, so this means that the user should provide their own
> > prefix
> > > > > resolver. This resolver can come from the same XmlObject if
this
> > is
> > > the
> > > > > intent, but otherwise they should be different.
> > > > >
> > > > > Cezar
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: nn [mailto:nnakae@comcast.net]
> > > > >> Sent: Friday, June 18, 2004 5:49 AM
> > > > >> To: xmlbeans-dev@xml.apache.org
> > > > >> Subject: bug fix for XPath using Namespace
> > > > >>
> > > > >>
> > > > >> Hi,
> > > > >> I think it is important to remove the restriction for not
> > > > >> allowing to use
> > > > >> namespace in complex XPath expression.
> > > > >> (s.t ./po:purchaseOrder/po:shipTo[po:name = 'Helen Zoe']" ).
> > > > >>
> > > > >> Since otherwise, the useful XPath (which is provided by
> > > > >> JAXEN) cannot be
> > > > >> used for most XML data associated with XMLSchema. I thought
> > > > >> this may be a
> > > > >> restriction of JAXEN, but it wasn't.
> > > > >> This fix is relatively simple. I  hope this should be
> > > > >> incorporated in the
> > > > >> release (after reviewed by commiters and tested throughly).
> > > > >>
> > > > >
> > > > > -
> > --------------------------------------------------------------------
> > > -
> > > > > To unsubscribe, e-mail:
xmlbeans-dev-unsubscribe@xml.apache.org
> > > > > For additional commands, e-mail:
xmlbeans-dev-help@xml.apache.org
> > > > > Apache XMLBeans Project -- URL:
http://xml.apache.org/xmlbeans/
> > > > >
> > > > >
> > > > > -
> > --------------------------------------------------------------------
> > > -
> > > > > To unsubscribe, e-mail:
xmlbeans-dev-unsubscribe@xml.apache.org
> > > > > For additional commands, e-mail:
xmlbeans-dev-help@xml.apache.org
> > > > > Apache XMLBeans Project -- URL:
http://xml.apache.org/xmlbeans/
> > > > >
> > > >
> > > >
> > > > -
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
xmlbeans-dev-unsubscribe@xml.apache.org
> > > > For additional commands, e-mail:
xmlbeans-dev-help@xml.apache.org
> > > > Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > > >
> > >
> > >
> > > -
> >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > > Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> >
> > -
---------------------------------------------------------------------
> > To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> >
> >
>
> -
---------------------------------------------------------------------
> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message