commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo <>
Subject Re: jxpath ?
Date Wed, 15 Jun 2005 17:01:53 GMT
Hi Dimitri,

Glad to see you're "alive"...

> Do you believe such integration would be useful?

If there is a need for "abusing" XPath as a 
fast, in-memory OQL - yes, since we have a standard
interface now instead of JXPathContext.

> The JAXP 1.3 spec allows for non-DOM object models
> to be supported, so I 
> don't see a technical reason why we could not
> integrate JXPath with it.

So, obviously OQL-ing is encouraged.

> Do you see JXPath adding a compatibility module to
> map JAXP 1.3 APIs to JXPath APIs?

Compatibility is a nice touch, always. I don't know
about user base - maybe everybody uses jaxen and
it's a waste of time.
We (academic) have made the decision to use JXPath
a long time ago, that's why my original question
about its state. 

> Or, alternatively, should JXPath itself morph to
> adapt to the JAXP APIs.  If 
> we did that, would we preserve compatibility with
> JXPath 1.2,  or go straight  to JXPath 2?  Or, 
> better, skip a version and go to JXPath 3.0 to avoid

> confusion with XPath 2?

Wow XPath 2? Do I smell XQuery ?  ;)
Personally, I'd throw out a (jaxp) compatibility 
module and call it 1.3. XPath 2 would be called
JXPath 2, not necesseraly compatible with JXPath 
1.2/1.3 internally - even if "customization", 
OQL wise, would require a lot of work. 

Jakarta releases are coming slowly as of late, there's

a good chance to stay in the "top 10" for a while ;)

Overall, JXPath is/was one of the "better" modules
within commons...keep it up if you can. If it doesn't
"pay off", please tell.

Best regards,

How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message