Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-incubator-dev] XSL Launching questions 
DOUG SATCHWELL wrote:
> 1. The transformation pipeline just seems to be a list of stylesheets to 
> run against the source XML files.  This doesn't cover the more typical
> use case of One stylesheet, creating output that the next stylesheet in
> the pipeline will use.    The transformation pipeline should be
> configurable so that different XML inputs may be used for each step in
> the pipeline.
I'm not sure I quite understand what you mean - the output from each step in the pipeline is the input to the next step. As far as I know, this is the typical way to configure a pipeline. Also, I don't see the point in configuring different inputs for each step - if you want to do this then it is better to create separate launch configurations for each?
Well, it isn't uncommon to have three or four XSLTs, working on different files, and then the final XSLT in a chain to use the other three in the final xslt, one as the input and two other's as cross reference/lookup tables.
Or have lookup tables generated that are used by XSLTs used farther in the chain. 

The basic concept you have implemented as depicted here:

http://www.reilly2001.info/xml-2-html/ch03s13.html
But there are more advanced situations. I guess that is why XProc was invented. 

http://xproc.org/

XProc is an XML Pipeline language, for handling the more advance scenarios.
> 2. Is there a dependency on any portion of the JDT for creating the 
> launch configurations?  Ideally we shouldn't have a dependency with JDT
> at all.  This way if an adopter wanted to build just a pure XML IDE,
> they wouldn't need to include the JDT plugins just to use the XSLT
> options.  This may require rewriting some functionality that was in JDT
> or requesting that they make the functionality available in the platform. Yes, there is a dependency. The JDT is used in multiple places - for instance, we re-use its Classpath page in the launch dialog, and we extend its launch config class (because we are in fact launching a Java application). It would be quite a big job to cut out the JDT and implement our own code. And I'm not sure that it is even desirable to do that in all cases - for instance, if I set JDK 1.4 to be the desired JRE in my Java preference page, I would expect my Java transform to be using that JRE by default? Only the JDT knows about JRE instances that are available - without a JDT dependency we wouldn't know how to discover these. And another reason to use the JDT launching is that we can make use of it for profiling - simply let it profile as you would any other Java application. So, there's a few reasons why we depend on the JDT. It would be possible to separate this out, but I'm not sure its achievable during this iteration. We can put it as an enhancement request?
And I don't think it should be in this iteration, and I understand the need for the various tabs, but what if I didn't want to create a launch configuration that used a Java processor, what if I needed to develop a stylesheet that needed to be tested on Multiple Processors that run on different platforms and different frameworks. It isn't uncommon to need to test a stylesheet to make sure that it runs the same against the .Net Framework, as well as Java, Perl, PHP, libXSLT, etc. Sure I can set these up using External Tools and an ANT script, but that shouldn't be necessary especially if we have an XSLT Launcher.
So while I agree that this can't be done now right now.. I think we can't make it depend on the JDT to be there. I've implemented a XML IDE for the member companies of the standards orgranization I work for, and ideally, I'd like to distribute just the following as an IDE platform, and can currently do so with just delievering the Web Standard Tools: 

1. Eclipse Platform.
2. Web Standard Tools and EMF-SDO-XSD
That combindation does not require the use of JDT at all in order to function as an XML IDE. As mentioned above, it isn't just JAVA that we need to be concerned about, almost every language has a way to execute XSLT 1.0 transformations, so we should make it extensible enough so that it doesn't depend on JDT to be used.

Back to the top