Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: psychopath API changes (was Re: [Fwd: Re: [Wtp-wst-dev] Dates Times..and Duration fixes])

On Tue, Sep 22, 2009 at 2:52 PM, David Carver <d_a_carver@xxxxxxxxx> wrote:
Mukul Gandhi wrote:
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,

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,

Mukul, please open a bug for this as node_position() should be added back and it's implementation needs to call the new way of doing things.

There is no new way of doing this, we can only return 0.
  As ResultSequenceFactory is API.   Anything that you are currently using that is not in an internal package, we should add back if it has been removed.

Actually, ResultSequenceFactory is not a problem at the moment.

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(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.
One thing to keep in mind is that ElementType is in an internal package, which means that it really isn't ment to be API yet, because it was bound to change due to work on the W3C Test Suite.  In addition to the link that David Williams sent we also have: This is why before the wst.xsl items we moved much of the PsychoPath processor classes into Internal Packages.  Yes, I realize that adopters currently need to access the schema type classes, but it was the best compromise we could come up with at the time.

To support Mukul's solution 2, we must we re-add the old constructor, marking it VERY deprecated.

So with this said, what we will need after we stabilize the internal Data Types, is to have an API request made so that we can correctly expose those items as Interfaces or Classes as appropriate.

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 can see doing this for the non-internal package changes that were made, so that we maintain that contract, however, internal packages adopters will have to make the necessary changes.  Now with this said, going forward we can try to leave a migration path (especially for the Schema Types).

I am also willing to do this change for PsychoPath as well :)

My goal is to hopefully have the processor passing the test suite.  Hopefully, Jesper can get his current refactoring work implemented during 3.2M3, and we can work on providing some true API layers for adopters to use for some parts that aren't currently exposed at the level they need to be.

As for the two options: I understand Mukuls problem with option 1 (changing Xerces to avoid the internal types), but I suspect the changes to Xerces will be quite small, and if we get the retrotranslator working in time for the Xerces release, that means we can get the API improvements in place (say, for M3) and then you can use that drop for the final Xerces 2.10.

The reason is that the quality of the CVS drop from 2-3 months back is not anywhere near production quality for validating documents (performance and reentrancy issues aside), so I'm afraid that shipping it out alongside Xerces is going to be very bad publicity for PsychoPath, especially since Xerces versions typically. As in "that's just too buggy to bother with"-kind of bad publicity. Such a reputation is very hard to escape.

I'd actually consider dropping PsychoPath JRE requirements down to 1.3 if it means we can get a newer version out to Xerces (under 1.3 we'd have to drop some functionality such as Patterns).


Back to the top