OK - I'm happy to leave Saxon out of the equation for now.
But, for the record, lets look at the datatools platform. I've downloaded it from eclipse.org only, and I see plugins with IBM, MySQL, Oracle and Sybase in their names, amongst others. They do not contribute instances of these databases, but they do enable the user to specify the location of one of these sorts of databases and to specify their properties.
Another example is WTP itselfe, which has support for Tomcat and many other types of server.
As far as I can see (I may be wrong), but this is exactly analogous to the situation with Xalan and Saxon?
Anyway, lets leave it out for now.
Cheers,
Doug
----- Original Message ----
From: David M Williams <david_williams@xxxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Friday, 18 January, 2008 3:21:04 PM
Subject: Re: [wtp-incubator-dev] Smoke Test Time - the Saxon issue
Thanks for clarifying about the debugger.
Let be try and clarify why I think we
can't ship a "saxon" plugin, even if it doesn't have saxon
in it.
Put simply, we can't _encourage_ users
to get some third party code, that has not passed Eclipse IP.
Now, the hard part is deciding what
is encouraging vs. simply telling people what's possible.
I think providing a plugin with saxon
in the name, which provides settings specific to Saxon, I think get's
too close to "encouraging"
them. So, am I missing something obvious to you experts?
Is there anything a user could get besides
Saxon that would take advantage of our saxon plugin?
I'm not even sure anyone thinks of "Xalan"
and "Saxon" as _types_ of implementations, do they?
Is there a non-Saxon implementation
that could be substituted for Saxon and still use the "Saxon Type"?
I think our current implementation is
different than simply saying "any xsl processor can implement these
extensions" even if we point
to some other websites that provide
their own plugins that implement the extension point.
So, it may be a fine line ... but, that's
the fine line I was referring to, that I'd prefer not to cross at this
point.
I realize it could be argued other ways,
but ... that's my take at the moment.
And, as Dave mentioned, I think there's
questions about the design that might effect the ultimate solution so
perhaps best to avoid the fine line
for now, and see how the actual use-case evolves?
Above all, thanks for the education
... please continue.
