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,
Ricardo
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
