You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Mukul Gandhi <ga...@gmail.com> on 2009/09/21 07:39:38 UTC
psychopath API changes and xerces-j (was Re: xpathDefaultNamespace
implementation on xs:assert, with psychopath)
Hi all,
I have done some study yesterday and today, about what's currently
happening with PsychoPath APIs, and here are the issues I think, exist
with PsychoPath in relation to Xerces-J.
The PsychoPath XPath 2.0 engine available with, Eclipse WTP 3.2M1
milestone release, works fine with current Xerces-J SVN code.
(ref: http://download.eclipse.org/webtools/downloads/
http://download.eclipse.org/webtools/downloads/drops/R3.2/S-3.2M1b-20090814143519/)
PsychoPath with Eclipse WTP 3.2M1, has 96% spec compliance (ref:
http://intellectualcramps.blogspot.com/2009/08/psychopath-11m1-available.html).
<problem>
The problem actually comes up with current PsychoPath development code
base, which will likely become part of Eclipse WTP 3.2M2 and
eventually, Eclipse WTP 3.2.
The current PsychoPath development code base has made some API
changes, which are not compatible with the current Xerces-J SVN code.
Xerces-J assertions calls to PsychoPath APIs (on current PsychoPath
development code base, which I tested locally) give error, currently.
At present, the impact of PsychoPath API changes are minor, to Xerces-J.
for e.g, the following method call, in Xerces-J class
AbstractPsychoPathImpl.java:
nodeEvalRS.add(new ElementType(contextNode,
fDynamicContext.node_position(contextNode)));
now needs to be written like:
nodeEvalRS.add(new ElementType(contextNode));
and this is the only problem, which Xerces-J currently has, to
integrate with the current PsychoPath development code. But in future,
PsychoPath might do widespread API changes, which we don't know at
present.
</problem>
my simple question is, how should we handle these PsychoPath API
changes at Xerces-J end? Should we request PsychoPath project to do
something about this? Or can we (and how) handle this independently at
Xerces-J end?
I suggest the option to use a system property with Xerces-J, to handle
this. But I am not sure, if that's good enough for this situation.
Any opinions, please?
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: psychopath API changes and xerces-j (was Re: xpathDefaultNamespace
implementation on xs:assert, with psychopath)
Posted by Mukul Gandhi <ga...@gmail.com>.
Hi Michael,
Thanks for your reply. Kindly see few of my comments, below.
On Mon, Sep 21, 2009 at 9:16 PM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> Does the Eclipse team have a plan for when they might reach API stability?
I don't think so, Eclipse WTP team has any concrete plans at the
moment, when they might reach API stability for PsychoPath.
Here is a link to the proposed API changes with PsychoPath:
http://dev.eclipse.org/mhonarc/lists/wtp-wst-dev/msg00321.html
This is just a proposal at the moment, with no time frame as such,
when these changes would get implemented, and in which WTP release it
would be part of.
I have conveyed to the PsychoPath team, that it would be good, if they
do API changes, after PsychoPath processor reaches 100% compliance (or
near to that) to the spec, with a corresponding WTP milestone release
from Eclipse. But 96% compliance if also good, with WTP 3.2M1 release
(but that's with JDK 5) :)
> Incompatible changes to an API are a pain for consumers and would prefer if
> we didn't start introducing code to cope with incompatible changes to the
> PsychoPath API.
I agree.
> I do think the instability is okay at the moment because we have not had a
> release yet and once we do it would be a "developer preview" where we warn
> our users that things can and will change in the future. We could just
> change our code to align with the updates to the API.
That's nice, and I agree as well.
> However, once XML
> Schema 1.1 is included in a Xerces release from the main trunk I would hope
> that the PsychoPath API is stable and that the Eclipse team isn't changing
> it in the future in ways which could potentially break users.
I hope so. I'll share these thoughts with the PsychoPath team, so they
could be careful about this. I think, it would be good (as is a
general practice with successful projects) if PsychoPath can deprecate
older public APIs, instead of dropping any APIs suddenly.
> Would also be nice if the API signatures stay compatible with Java 1.3 (i.e.
> don't have visible dependencies on classes / interfaces in JDK 1.4+) so that
> it's possible for us to make a final JDK 1.3 PsychoPath jar around the time
> of the first "production" release, but also allow users to obtain newer
> versions from eclipse.org which may have internal dependencies on Java 5+.
I'll convey this to PsychoPath team. But porting a future 100%
compliant PsychoPath code base in entirety to JDK 1.3, would be pretty
challenging. PsychoPath does have plans, to port it's releases in
future to JDK 1.4 (but not 1.3).
Let's see how all this goes in future. I'll work with PsychoPath team,
and would try to have minimal impact on Xerces code, and it's users.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: psychopath API changes and xerces-j (was Re: xpathDefaultNamespace
implementation on xs:assert, with psychopath)
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Mukul,
Does the Eclipse team have a plan for when they might reach API stability?
Incompatible changes to an API are a pain for consumers and would prefer if
we didn't start introducing code to cope with incompatible changes to the
PsychoPath API.
I do think the instability is okay at the moment because we have not had a
release yet and once we do it would be a "developer preview" where we warn
our users that things can and will change in the future. We could just
change our code to align with the updates to the API. However, once XML
Schema 1.1 is included in a Xerces release from the main trunk I would hope
that the PsychoPath API is stable and that the Eclipse team isn't changing
it in the future in ways which could potentially break users. We're very
careful about compatibility with our own APIs (e.g. XNI and XML Schema API)
though I understand PsychoPath hasn't reached that level of maturity yet.
Would also be nice if the API signatures stay compatible with Java 1.3
(i.e. don't have visible dependencies on classes / interfaces in JDK 1.4+)
so that it's possible for us to make a final JDK 1.3 PsychoPath jar around
the time of the first "production" release, but also allow users to obtain
newer versions from eclipse.org which may have internal dependencies on
Java 5+.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Mukul Gandhi <ga...@gmail.com> wrote on 09/21/2009 01:39:38 AM:
> Hi all,
> I have done some study yesterday and today, about what's currently
> happening with PsychoPath APIs, and here are the issues I think, exist
> with PsychoPath in relation to Xerces-J.
>
> The PsychoPath XPath 2.0 engine available with, Eclipse WTP 3.2M1
> milestone release, works fine with current Xerces-J SVN code.
> (ref: http://download.eclipse.org/webtools/downloads/
> http://download.eclipse.org/webtools/downloads/drops/R3.
> 2/S-3.2M1b-20090814143519/)
>
> PsychoPath with Eclipse WTP 3.2M1, has 96% spec compliance (ref:
>
http://intellectualcramps.blogspot.com/2009/08/psychopath-11m1-available.html
> ).
>
> <problem>
> The problem actually comes up with current PsychoPath development code
> base, which will likely become part of Eclipse WTP 3.2M2 and
> eventually, Eclipse WTP 3.2.
>
> The current PsychoPath development code base has made some API
> changes, which are not compatible with the current Xerces-J SVN code.
> Xerces-J assertions calls to PsychoPath APIs (on current PsychoPath
> development code base, which I tested locally) give error, currently.
>
> At present, the impact of PsychoPath API changes are minor, to Xerces-J.
>
> for e.g, the following method call, in Xerces-J class
> AbstractPsychoPathImpl.java:
> nodeEvalRS.add(new ElementType(contextNode,
> fDynamicContext.node_position(contextNode)));
>
> now needs to be written like:
> nodeEvalRS.add(new ElementType(contextNode));
>
> and this is the only problem, which Xerces-J currently has, to
> integrate with the current PsychoPath development code. But in future,
> PsychoPath might do widespread API changes, which we don't know at
> present.
> </problem>
>
> my simple question is, how should we handle these PsychoPath API
> changes at Xerces-J end? Should we request PsychoPath project to do
> something about this? Or can we (and how) handle this independently at
> Xerces-J end?
>
> I suggest the option to use a system property with Xerces-J, to handle
> this. But I am not sure, if that's good enough for this situation.
>
> Any opinions, please?
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org