ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Proposal for a new task <xslt> (different semantics than <style>)
Date Tue, 30 Jan 2001 09:47:51 GMT
Ivan,

the <style> task has changed quite a bit since Ant 1.2. I'm not sure,
but I think it already addresses a couple of your points.

Ivan Mikushin <ivan@vismech.ru> wrote:

> - one may need to specify XSLT transforms not bound to basedir for
> the <style> task instances

<style> now has in/out parameters for situations like this.

> - one may need to supply parameters to an XSL transform

<style> has a nested <param>.

> - <style> has a redundant attribute 'processor' which is unneeded
> when TrAX interfaces (seems to become standard) are used

I think we should not drop Xalan1 support right now. <style> now also
supports a TrAX processor which may very well become the only major
option in the long term.

> - XSLT transforms are not necessarily used for styling: you may use
> it to generate code, and whatever, so it's reasonable to name the
> task <xslt> and to indicate XSLT file with 'transform' attribute.

Agreed, we could alias it to be called in both ways and deprecate
<style> if we all agree on that. This is much the same way <expand>
has been renamed to <unzip> a while back.

> I rewrote XSLTProcess class (mine is named XSLTProcess2) to meet
> these issues (actually took XSLTProcess and changed it a little).

I'd ask you to take a look at the version of <style> in CVS and merge
in whatever functionality is missing from your implementation.

Stefan

Mime
View raw message