regarding the jcr name constants in QName: i would loved to move them out of the QName class to some interfaces: - JSR170Names for names defined by jsr170 - (JSR283Names for names defined by jsr283) - JRNames for names used internally by jackrabbit, like rep:system - XPathNames for the names in the xpath query builder
we can still have QName implement some of the interfaces for backward compatibility. what do you think? regards, toby On 7/26/06, Julian Reschke <[EMAIL PROTECTED]> 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. > 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. 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? Best regards, Julian
-- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
