Re: psychopath API changes (was Re: [Fwd: Re: [Wtp-wst-dev] Dates Times.

[Mukul Gandhi <mukul.gandhi@xxxxxxxxxx>]

Hi all,
    I have full support for the WTP API policy shared by David Williams.

However, I would summarize below the current issues between PsychoPath and
Xerces, my analysis of the situation, and possible actions.

Xerces currently makes calls like following, to PsychoPath library (which
works fine with Eclipse WTP 3.2M1 release, as well) [1]:

ResultSequence nodeEvalRS = ResultSequenceFactory.create_new();
nodeEvalRS.add(new ElementType(contextNode,
                   fDynamicContext.node_position(contextNode)));

The current PsychoPath code base on Eclipse CVS server, has made following
changes for above API calls:

node_position method is now not available, and is I think renamed to,
context_position().
The ElementType constructor, which is used by above Xerces code [1], is
removed from current code base. We now only have following constructors on
ElementType.java:

ElementType()
ElementType(Element v)

I foresee following options, about how Xerces can recover from these API
changes in current PsychoPath code base (with some side remarks as well):

1. Xerces needs to change it's code to use the new PsychoPath APIs. But
that would force Xerces users (who would use PsychoPath based XML Schema
1.1 features), to work on JDK 1.5. So this is probably not a desirable
solution for Xerces.
Xerces currently supports min JDK level of 1.3. We made an internal port of
PsychoPath for JDK 1.3, using an old version of PsychoPath code base (by
taking it from Eclipse CVS 2-3 months back), which used older PsychoPath
APIs (as shown at, section [1]).
So, if we change Xerces code now, to use the latest PsychoPath APIs, we
need to do a difficult and timeconsuming task of creating a JDK 1.3 port
again. I think, we wouldn't want to do this presently.

Ideally, I think Xerces project would like to keep Xerces code unchanged,
and still allow users (who can work in JDK 1.5 environment) to use the
latest PsychoPath JARs.

2. An easy solution could be, which involves less work both for Xerces and
PsychoPath could be:
PsychoPath provides the earlier APIs in deprecated mode, and delegate the
older APIs to the new APIs. The new PsychoPath APIs would exist, it's just
that two of the missing APIs in PsychoPath (as mention above, [1]) are
added again. From PsychoPath/XPath 2.0 design point of view, this may not
be a nice solution, but it will solve Xerces's problem at the moment, with
lesser disruption.
I am also willing to do this change for PsychoPath as well :)

I currently prefer solution, 2.

Any opinions, please about the points above?

I think, we must explore retrotranslator too.

Going forward, I am in full support for adhering to the WTP API policy
document.

Regards,
Mukul



                                                                       
             Jesper Steen                                              
             Møller                                                  
             <jesper@selskabet                                          To
             .org>                     "Web Standard Tools developer   
             Sent by:                  discussions."                   
             wtp-wst-dev-bounc         <wtp-wst-dev@xxxxxxxxxxx>       
             es@xxxxxxxxxxx                                             cc
                                                                       
                                                                   Subject
             09/22/2009 03:14          Re: psychopath API changes (was Re:
             PM                        [Fwd: Re: [Wtp-wst-dev] Dates   
                                       Times..and Duration fixes])     
                                                                       
             Please respond to                                         
               "Web Standard                                           
              Tools developer                                          
               discussions."                                           
             <wtp-wst-dev@ecli                                         
                 pse.org>                                              
                                                                       
                                                                       




I am aware of the API policy and I know it is serious stuff, but so are the
issues with the current API. If this is not an appropriate place to discuss
cross cutting API concerns, then where should such discussions be held and
recorded?

The issues are these, as I see them:

1) The Xerces branch is relying on the current XPath2 API which IMHO has
some serious flaws and performance hindrances.
2) The Xerces branch is also relying on internal packages. We should
consider extending the API to avoid such dependencies, or they will
effectively be "baked in" forever.
3) Xerces is heading for a release in december which will use a milestone
drop of XPath2. If we time things right, the "damage" going forward will be
managable. By "damage" I mean the effort for adpters to discontinue use of
the current API practices which should be deprecated, and use the
alternatives instead.

But as Dave Carver suggests, let's focus on full compliance first, and then
afterwards create a bugzilla to track the proposed changes.

As for 1.3 / 1.4 compatibility I just tried using retrotranslator on the
current test suite, and it appears to be a viable option. If we can support
1.3+1.4 using a special build using retrotranslator and a different package
name (using JarJarLinks or similar) we can support Xerces in a way which
will not hinder Eclipse itself from consuming Xerces 2.10, which could also
be a problem down the road, unless there's some OSGi magic I don't know
about.

-Jesper