Re: [xsl] Findings: Merging XSL:FO & HTML Style Sheets

[Peter Davis <pdavis152 at attbi dot com>]

On Tuesday 05 March 2002 11:38, Kurt Cagle wrote:
> Peter,
>
> I second your call. There are a few others where I think loosening the
> restrictions on parameter expansion would make a world of difference:
>
> 1) xsl:import and xsl:include href attribute. Is there any reason
> whatsoever why you couldn't change at least <xsl:include> parametrically?
> Unlike procedural headers, you're talking about JIT compilation here, so
> there really isn't a great deal of benefit to keeping these static. In the
> case of working with compiled XSL, the issue becomes a little more complex,
> but as I see it the worst case scenario is that you effectively end up
> having to rebuild the XSLT instance again.

Parameterizing @href in xsl:include unfortunately would be almost impossible 
for a compiler to implement.  To do that, the compiled stylesheet would 
basically have to have another compiler/interpreter built in in order to read 
the included stylesheet, and any performance gains would be lost.  The best I 
think the XSLT group could do was to specify that parameterized @href's are 
only optionally supported, but I think if the major implementations could 
manage it then people would be happy.  Perhaps all of the currently 
un-parameterizable attributes could be made "optionally" parameterizable.  
That's one more thing to make stylesheets less portable, but it's no worse 
than disable-output-escaping.

Another option would be to have, in addition to <xsl:param> (at the top 
level, I'm not talking about template params), something like 
<xsl:compile-param>.  So you could have <xsl:compile-param 
name="include-uri"/> and would pass in the value of $include-uri when you 
create a new Transformer instance.  Then further specify that 
xsl:include/@href can only use attribute value templates that use a 
compile-param and not anything from the source document or normal params (in 
otherwords, anything not available at compile time is not allowed).  This 
restriction could also be placed in other compilable things like 
<xsl:call-template name="{}"/>.

Unfortunately that might be kind of (or a lot of) a hack -- probably too much 
so for anyone to consider ammending the specification so drastically :)

> 2) Modal invocations on <xsl:apply-templates> - as you say, there are
> workarounds, bu they are cumbersome. I can think of a number of situations
> where being able to change the mode could turn a long and ugly <xsl:choose>
> statement into a one-liner.
>
> Those are two that come to mind, but I know I've stumbled across others.
>
> -- Kurt

-- 
Peter Davis
By doing just a little every day, you can gradually let the task
completely overwhelm you.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list