forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
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 02:03:52 GMT
David Crossley wrote:

>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 
>  
>
Hi,

See below....

>  
>
>>Best Regards,
>>
>>Antonio Gallardo.
>>*
>>    
>>
>
>* 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.

I am sorry for the errors in my last post. I was in a hurry trying to 
send the information to the list and I don't reviewed it as usually I do.

The good news is that the commons-jxpath community seems to accept and 
want to keep the request "enhancement". See:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32360#c26

The bad news is that seems like we are not using xpath 1.0 in the 
linkRewriterTransformer.

I wonder is we used XPath 1.0 notation in the LinkRewriter transformer 
since day 1? Is XPath 1.0 the desired expression language? I think we 
never used XPath 1.0 or maybe we used it in the beginnng when the 
linkmap.xml did not contain a default namespace.

I have a question, why we need a namespace in the linkmap.xml at all?

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?

Best Regards,

Antonio Gallardo.

P.S: Me expecting this time thunderbird does not wrote a lot of stars inbetween mail. :-)





Mime
View raw message