Hi, On 7/27/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
I'm ok with putting the namespace and default prefix constants in QName. But only for namespaces that are final and that's exactly the problem with the xpath-functions namespace.
Good point. Another alternative for breaking the dependency is simply to duplicate the namespace URI in the XPathQueryBuilder class until we are happy with putting it to jackrabbit-commons.
Please note that http://www.w3.org/2005/xpath-functions is not final either. XPath 2.0 as of today is still a W3C Candidate Recommendation. See also: http://www.w3.org/TR/xquery-operators/#namespace-prefixes here the fn prefix is bound to http://www.w3.org/2006/xpath-functions ;)
Oh, bugger.
Because the namespace uri http://www.w3.org/2004/10/xpath-functions is already bound to 'fn' an attempt to register e.g. http://www.w3.org/2006/xpath-functions as 'fn' will result in a binding like 'fn2' -> 'http://www.w3.org/2006/xpath-functions'. The new namespace introduced with the more recent jackrabbit release will in effect be hidden to an existing application. I think this is acceptable.
A better upgrade path would probably be to detect a previous "fn" namespace mapping and remap it as "fn2004" -> "http://www.w3.org/2004/10/xpath-functions" or as "fn2005" -> "http://www.w3.org/2005/xpath-functions" before mapping "fn" -> "http://www.w3.org/2006/xpath-functions". BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development