Joe, Thank you very much for your comments.
--- Joseph Kesselman <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
