forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: [jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
Date Tue, 01 Nov 2005 00:21:29 GMT
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

Mime
View raw message