Julian Reschke wrote:
Jukka Zitting schrieb:
Hi,
On 7/26/06, Julian Reschke <[EMAIL PROTECTED]> 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
acceptable.
Oh, and regarding the JCR spec, which references an unreleased W3C
recommendation, well, that's already too late to fix :-(
regards
marcel
