[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    RE: bug fix for XPath using Namespace
From:       "Eric Vasilik" <ericvas () bea ! com>
Date:       2004-06-22 17:47:37
Message-ID: 4B2B4C417991364996F035E1EE39E2E10D8EE6 () uskiex01 ! bea ! com
[Download RAW message or body]

Comments inline ...

> -----Original Message-----
> From: David Waite [mailto:mass@akuma.org]
> Sent: Tuesday, June 22, 2004 8:47 AM
> To: xmlbeans-dev@xml.apache.org
> Subject: Re: bug fix for XPath using Namespace
> 
> On Jun 21, 2004, at 5:48 PM, Eric Vasilik wrote:
> 
> > Let me try to shed a little light on the history of selectPath in
> > Apache
> > XmlBeans.
> >
> <snip interesting history>
> 
> > 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.
> 
> I'm curious whether (with an adequate time machine) you would prefer
> the XmlObject.selectPath()/execQuery() mechanism, or to use a JAXP
> 1.3-style XPath interface/JSR 225-style XQuery interface.

I have not looked at these closely.  At the time, I was restricted to
using internal interfaces.

> > 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.
> Yes, it is nice. I've bumped into several instances where I could
> really have used a self-contained namespace context.
> 
> > 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.
> 
> I'd recommend not doing this on the target document, but I effectively
> have a patch to do that now, based on the namespace uri -> prefix map
> of SAVE_SUGGESTED_PREFIXES. This could easily be swapped to a
different
> or new XmlOption.

Where the prefix resolver comes from is really up to the user.  If one
wants to resolve prefixes against the document on which the path is
executing, you can simply get a resolver from there.  Otherwise, it
makes more sense to get a resolver from the document in which the xpath
is embedded.  

I had always thought that XPaths were self-contained or could, at least,
be able to define their own namespaces.  It turns out that they are much
more like QNames in text: the prefix is in the QName text, the prefix
definition is somewhere above you in the tree.  Makes sense for a
document containing QNames which is immutable, but try modifying such a
document, and you can end up with undefined prefixes.

I would recommend a different option for this.

> The only real side-effect is that the SelectPathInterface changes to
> also hold a setNamespaceContextMap method.

The interface need not change.  There is a version which takes
XmlOptions.

> > 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.
> 
> This might be appropriate as an XmlOption as well, since we are
> effectively allowing (and preprocessing) a hybrid syntax.

Agreed, but a user would have to nearly always specify such an option.  

> > 3) At some point in the future, switch over to an XPath 2.0 engine.
> > Perhaps Saxon.  And, perhaps, implement execQuery as well.
> 
> Why XPath 2.0? I admit, all I know about XPath 2.0 is that they
> deprecated the namespace axis and added some type of schema awareness
> (like automatically matching against individual names from a NMTOKENS
> type).

Because we intend to do XQuery, XPath 2.0 is compatible with the paths
in XQuery.

> -David Waite
> 
> 
> -
---------------------------------------------------------------------
> 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/


[prev in list] [next in list] [prev in thread] [next in thread]