I'm looking at the "force" parameter-- Sean's recent
patch for the Ant Task.  This parameter, when set to
"false", will stop xslfo files from being processed if
there hasn't been a timestamp change on the xslfo file
compared to the output file. force="true" means always

A default value of force="false" will keep us to the
same default as the force attribute on the Ant <xslt>
optional task.  That's what we're planning for the
trunk release:  question, though, what do we do for
maintenance branch?

(a) Don't include force patch at all -- only have this
option for 1.0.  Argument for this:  Haven't had too
many requests for it, we can continue as-is until 1.0.

(b) include force, but default it to "true"--keeps
functionality the same, but may cause errors when
people convert from 0.20 to 1.0; also this
functionality is opposite to <xslt> task.

(c) include force in 0.20, default it to "false", but
have a message in the release notes warning about the

Technically, even if most users forgot to read the
warning in (c) they would still be OK, as they would
be happy if no time was spent with unnecessary
regnerations.  However, due to internal links to other
files that might have changed, etc.--which force does
not capture, either here or in <xslt>--there could be
a difference in functionality.

Probably (a) is best; (c) is also OK. (b) I'm not too
keen on.



Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to