I have still created an org.eclipse.wst.xsl.saxon plugin, but without saxon.jar in it. Doing this means that a user can add Saxon themselves to their local Eclipse installation via the Installed Processors preference page, which is a simple operation. Not as neat as having Saxon installed by the plugin itself, but not too bad either.
Other than that, I've ironed out most of the remaining issues with the Xalan debugger, and it now works a treat. Of course, there are enhancements I can make to it, but its good enough to be released now.
How are we on the release schedule, do we want to do WTP+1 or WTP+2, and how do we get the builds integrated with the WTP build process?
----- Original Message ----
From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Wednesday, 2 January, 2008 6:34:54 PM
Subject: [wtp-incubator-dev] Saxon 9
Unfortunately it looks like I'm going to have to withdraw the CQ for
Saxon 9 to be approved by IP. I have not heard back from Michael Kay
the author in regards to the questions that still need to be answered.
So how to proceede:
1. Concentrate onf XSLT 1.0 support with EXSLT extensions that are
supported by Xalan.
2. Continue working with Michael Kay to work out the issues.
3. Work on support for XSLT 2.0 editing with in the editor. This
doesn't necessarily require an XSLT 2.0 interpretor. Possibly create
our own compiler/checker to make sure all XSLT
2.0 rules are being followed.
However, any support for XSLT 2.0 debugging would have to be treated
like an adopter implementing it through extension points. Unless anyone
knows of an alternative XSLT 2.0 engine that we could look at.
Might be a good How To article to show how an adopter could implement
XSLT 2.0 support using the framework.
Dave
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev