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 Tue, 22 Jun 2004 00:24:58 GMT
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/


Mime
View raw message