I didn't know about XProc - it looks good. I would like to use it instead of the XML config file I created. Could you knock together an example pipeline that works in the same way as the one we have now? I can use it as a template.
XProc is very comprehensive, so much so that it would be almost impossible to make a run dialog page that could configure it. So I think the alternative would be to allow the user to specify a path to an XProc file they have created instead.
----- Original Message ----
From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent:
Wednesday, 26 December, 2007 2:27:57 PM
Subject: 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.htmlBut 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.
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev