xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Vasilik" <eric...@bea.com>
Subject RE: bug fix for XPath using Namespace
Date Mon, 21 Jun 2004 23:48:04 GMT
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/


Mime
View raw message