Antonio Gallardo wrote: > David Crossley wrote: > > > >Uh'oh, looks like we are one step ahead of ourselves. > > > >See the comments at the Commons JXPath issue: > >http://issues.apache.org/bugzilla/show_bug.cgi?id=32360 > > > >Also elharo kindly added a note to the Cocoon bug > >warning that we might have the wrong fix: > >http://issues.apache.org/bugzilla/show_bug.cgi?id=36810 > > > I wonder why he claims we broke the JXPath implementation. I understand > the new method in jxpath is a hack, but..... > > Well, I think we are learning and that is good. :-) If this is the case, > we can try the suggested solution: > > Given a simple linkmap.xml as: > > *<site* href="" xmlns="http://apache.org/cocoon/linkmap/1.0"*>* > *<myIndex* href="index.html"*/> > </site> > > Then the xpath expression "/site/index/@href"
Presume you mean "/site/myIndex/@href" > cannot be used. It returns null. The reason is below. > > <snip from="http://www.xml.com/pub/a/2004/02/25/qanda.html";> > *The real difficulty is that XPath syntax needs to satisfy two > irreconcilable requirements: handling elements in a declared but > default (unprefixed) namespace and handling elements in no namespace > at all, which do not have expanded names. In reconciling this dilemma, > the XPath spec says that an unprefixed name /in an XPath > expression/ is assumed to be in an undeclared namespace, even when > the name as it appears /in the instance document/ has (as a > result of a namespace declaration) an expanded name. Thus, |//myIndex| > "query" is instructing XPath to > locate an element which does not exist, a > |"myIndex"| element in an undeclared namespace. > </snip> > * > > One of the suggested solutions in the document is strip the default > namespace form the file. (This was the David solution). > > If the above is not posible, then we can also make a simple trick with > JXPath: > > *context.registerNamespace(foo, "http://apache.org/cocoon/linkmap/1.0 > > and then write the xpath using it: > > *"/foo:site/foo:index/@href"* > * Yes, that is what i reckon needs to happen in the Linkrewriter or it gets defined as a parameter for configuration of Cocoon's input modules, or something. Sorry, i am not a good enough Cocooner to know where. One trouble is that we need to handle two possible namespaces. This Linkrewriter started life at Forrest then moved to Cocoon. http://apache.org/forrest/linkmap/1.0 http://apache.org/cocoon/linkmap/1.0 > Best Regards, > > Antonio Gallardo. > * * Starry, starry night at your place is it Antonio * * * :-) -David
