[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Provisioning all set and done!
|
DOUG SATCHWELL wrote:
I still don't have access. However, my preference is to start from
scratch and port bits from each project as needed!
Yeah, I still don't have access yet either.
The main thing we need to do is to establish the target platform. I
think we could stay on a steady version (Europa 3.3 fall2 drop), and
occasionally move up a version as required. There should not be too
many dependencies on the rest of WTP, so that shouldn't matter anyway.
I've submitted a couple of bug requests for enhancements that I think we
can leverage. One of the issues with both OrangeVolt XSLT's and
X-Assist is that you have to include a xsi:schemaLocation attribute with
a reference to the corresponding schema for XSLT. X-Assist dynamically
adds a DTD for content proposal, but this doesn't do anything for
validity of the XSLT as you are working on it. The thought here was to
extend the existing WTP/SSE/Validation framework to allow an editor to
specify what Grammar should be used. This way, when you run into the
situation where two versions of a particular specification fall under
the same namespace, the editor can choose which grammar to use.
In our case with XSLT, it'll rely on the version attribute to indicate
what grammar should be used (i.e. either a 1.0 schema or a 2.0 schema).
I'll post the bug numbers later.
In the first iteration, I think we should aim for the ability to setup
and run a transformation using one of the built-in XSLT processors.
That sounds like quite alot but actually we have some very good
existing code that can do just that.
I'm working with one of the other eclipse committers to try and get a
version of Saxon 9.0 B included that strips out any of the IP concerns
(i.e. any dependency on GPL code). I have a stripped down version that
is completely MPL 1.0 licensed code, so I think I can work it through
the IP process to allow us to have Saxon 9 for XSLT 2.0 support.
In subsequent iterations, we can add debugging and then look into
source editing, validation etc. that hasn't had that much attention yet.
As for which code base to use, that I leave to you guys. My best
contribution is going to probably be bug fixes, and just testing
useability. I use XSLT on a daily basis, so work with it quite
extensively. I've grown used to certain debugging features from Oxygen
XML that I would like to see in the base eclipse xslt editor/debugger as
well.
Hopefully, my committer paperwork makes it through the process soon.
Dave
