Antonio Gallardo wrote: > David Crossley wrote: > >Antonio Gallardo wrote: > >>David Crossley wrote: > >>> > >>>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.....
I reckon that elharo thinks that we are not using JXPath correctly in Cocoon's Linkrewriter. Probably requires your solution #3 below. > >>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 > > > >* Starry, starry night at your place is it Antonio * * * :-) > > ?? The "stars" where placed by Thunderbird, not by me. I am sorry for > that. BTW, you are right, today is a starry night here. How do you knew > that! ;-) lol. A guess for the sake of the joke. I knew it was night-time for you. > I have a question, why we need a namespace in the linkmap.xml at all? Or in site.xml in the Forrest case. That was asked earlier in this thread. I reckon that the answer is so that it clearly defines which version of the linkrewriter is suitable for processing that file. Later we might need to radically change the behaviour of the Linkrewriter, so i suppose that we would require users to upgrade their site.xml files. Anyway we already have released versions of Forrest and Cocoon, with people using namespaces on their site.xml etc. So we must support it. > If we really need a default namespace in the linkmap.xml, then let's use > the correct behavior for XPath 1.0 in the linkrewriter. Hence, use > something like: > > /linkmap:site/linkmap:myIndex/@href for the linkmap rewriter. > > The 3rd solution is (not too easy?): > > 1- Detect a default namespace URI > 2-Create a "weird" namespace prefix and register it with the default > namespace URI > 3-Rewrite the "location xpath expression" using the generated namespace > prefix. > > Sample: > > Given the linkmap: > > <site href="" xmlns="http://apache.org/cocoon/linkmap/1.0";> > <myIndex href="index.html"/> > </site> > > and given the location xpath expression: > > /site/myIndex/@href > > 1- Detect the default namespace URI: > Output: > http://apache.org/cocoon/linkmap/1.0 > > 2-Generate a dummy namespace prefix: cgnp. > Output: context.registerNamespace("dummy", > "http://apache.org/cocoon/linkmap/1.0";); > > 3- Rewrite the xpath expression > Output: /dummy:site/dummy:myIndex/@href > > How sounds this solution? I feel that this is the way to go. > Best Regards, > > Antonio Gallardo. > > P.S: Me expecting this time thunderbird does not wrote a lot of stars > inbetween mail. :-) Yes. If the rain clouds rolled in, then send them over here please. -David
