commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dplot...@yahoo.com>
Subject Re: Quick question/comment re JXPath
Date Wed, 04 Dec 2002 22:08:18 GMT
Joe,

Thank you very much for your comments.

--- Joseph Kesselman <keshlam@us.ibm.com> wrote:
> Question: Apologies if this is on the website, but I didn't see it if
> 
> so... Is there a good summary of how the XPath axes are mapped in
> JXPath? 
There is no good documentation on the issue.  I know, I know...  I
promise to do that before the next release.

> Specifically:
> 
> a)  I know bean property equals child, but... is there a concept of 
> Parent? Ancestor? Sibling? Or did you just declare that you're
> supporting 
> only a subset of XPath without those axes?
There is no easy way to define those mappings, because applying XPath
to beans is like mixing oil and water.  There is no "natural" way to do
it.  Therefore some of those mappings a quite arbitrary.

Here's the summary:

Parent:: is defined in the XPath evaluation context only. For example,
consider the path "//foo[../@name='bar']".  As JXPath descends down the
graph, it maintains the context path from the root to the current leaf.
So, in order to get the parent it will simply step back on notch on
that path. I believe that in the case of whole XML documents it
produces results consistent with the spec, at least I could not come up
with a counter example.

Ancestor:: same mechanism

Sibling:: axes are supported as well. In the current cut of JXPath bean
properties are ordered alphabetically and that order is used for the
"document" order.  I am not convinced we want to keep it that way. 
After all the alphabetical order has no real significance in the
JavaBeans world.  Do you believe we should disable those axes for beans
or maybe declare their results "unpredictable"?

> b) You've got an example which uses //. Given that bean relationships
> may 
> be arbitrary graphs rather than directed trees, how does JXPath
> prevent 
> that from potentially becoming an infinite recursion? 
> (a.getB().getC().getA().getB().getC()....)
Yes, it can get into infinite recursion.  At this point JXPath does not
handle it well.  I am afraid to introduce a set of visited nodes
because of the performance overhead it will introduce.  I wonder if
there is a better algorithm?

> Comment: Something odd is happening to styling of the JXPath pages;
> half 
> the time, they're displaying with a dark blue background; some of the
> 
> lettering shows up as white and some as black, with links in blue.
> The 
> result is pretty near unreadable. The OTHER half the time, they show
> up 
> with standard black-text-on-white-background. I haven't been able to
> find 
> a reliable pattern, though entering the URI directly appears to be
> more 
> likely to cause trouble than following a link from another page. 
> Admittedly, I'm viewing the pages with Netscape 4.75, which probably 
> doesn't have the most robust CSS engine in the world... but I haven't
> seen 
> this effect before; you may want to look at the generated HTML and
> see if 
> you can figure out what's provoking it.
Where are you seeing this? On the Apache website or the HTML that comes
with the download?  I am asking because they are generated with
different engines.  The docs on the website are made with Maven, while
the downloaded package is built with Anakia. 

> ______________________________________
> Joe Kesselman  / IBM Research

Thanks again,

- Dmitri

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message