[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Smoke Test Time
|
David Carver wrote:
DOUG SATCHWELL wrote:
Please bear with me on this. It has got nothing to do with the Saxon
debugger - I have deleted this code from CVS.
*without the Saxon plugin, the user cannot add Saxon processor
instances*
The Saxon plugin contributes the Saxon processor _type_. NOT the
Saxon processor itself. The user adds this himself via the preferences.
Please, just try out the code a) with the Saxon plugin installed and
b) without it. Try adding processor instances via the preferences.
Add a Xalan one, and a Saxon one. I think after playing with it for a
while you will understand what I am trying to say (email is so
frustrating sometimes!).
Doug, I see what you are saying, and I think that particular
functionality needs to be reworked. I personally don't think that a
person should have to pre-define a processor type in order to add an
available processor. I think you might be able to get by with making
it more generic. Something like:
1. Java Processor
2. Command Line
Or something else. Regardless, I do like the extension point for
adopters to use to provide specific functionality for their specific
processors, but Saxon we have to avoid for now. That functionality
along with the debugger extensions needed by it, should come from
Saxon or an Adopter of XSLT Tooling.
I've just reviewed what's actually in the Saxon plugin, and I think it
is justified as is. It contains the metadata for the Saxon specific
parameters for which the user has chosen Saxon. The way I see it, we
might want the following:
1. Java Processors
- JRE Default (provided - has standard param info)
- Xalan (provided - has param info)
- Saxon (not provided - has param info)
- Generic (not provided - has no/standard param info)
2. Command Line
- Generic - has no param info
If we allow saxon, then we have to allow Sabletron for Perl, LibXSLT
for PHP/C, Xalan C++ for CDT, etc. It's a slope I'd rather stay away
from, and encourage adopters to add the necessary support, or rewrite
the way it is currently implemented to give the user more control with
out having to pre-define Processor Types.
Allow, yes, but I don't see how we are obliged to do anything other that
having a good extension points, and providing some suitable
("exemplary") extensions for those.
As I see it, keeping or ditching Saxon is pretty much a matter of taste
or preference. I don't have a strong bias either way. One way out would
be to start a Saxon plugin project elsewhere, or find somebody who will.
If that happens, I think we (Doug) should move the Saxon support there,
since it would be very awkward to have competing extensions for Saxon.
Did that make sense?
-Jesper
