jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Re-using the query parsers outside Jackrabbit
Date Thu, 27 Jul 2006 09:06:38 GMT
Julian Reschke wrote:
> Jukka Zitting schrieb:
>> Hi,
>> On 7/26/06, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> org.apache.jackrabbit.core.query.xpath.XPathQueryBuilder has a
>>> dependency on org.apache.jackrabbit.core.SearchManager, for the sole
>>> purpose of importing to constants for namespace URIs. Would it be
>>> possible to get rid of that dependency?
>> I don't see any reason not to, though it would be nice to avoid
>> duplicating the constants. Putting the constants to QName sounds
>> reasonable. Would you like to contribute a patch for that?
> QName would be ok for me but may be non-optimal for other use cases. But 
> as long as nobody complains, QName is fine.

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.

>> PS. A related issue, we should perhaps update the XPath function
>> namespace from the draft namespace
>> http://www.w3.org/2004/10/xpath-functions we currently use to the
>> official XPath 2.0 function namespace
>> http://www.w3.org/2005/xpath-functions. I'm not sure if there will be
>> backwards compatibility implications in doing this.

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 ;)

> As far as I can tell, it doesn't affect JCR compliance (the string 
> doesn't appear in the spec). So that change would affect people who 
> overwrite the internal "fn" prefix mapping? That may be a problem; not 
> sure how big. Maybe just try it in the development branch first?

I don't think there will be a problem with client applications. The 
namespace is only used in the context of an XPath statement and there 
only the 'fn' prefix is used and never the namespace uri. The only 
issue that I see is upgrading from an earlier Jackrabbit version. 
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 

Oh, and regarding the JCR spec, which references an unreleased W3C 
recommendation, well, that's already too late to fix :-(


View raw message