Subject: Re: [xsl] Findings: Merging XSL:FO & HTML Style Sheets From: Peter Davis <pdavis152@xxxxxxxxx> Date: Tue, 5 Mar 2002 14:57:46 -0800 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Findings: Merging XSL:FO , Peter Davis | Thread | Re: [xsl] Findings: Merging XSL:FO , Jeni Tennison |
RE: [xsl] @* and xmlns:xsl, Michael Kay | Date | RE: [xsl] Xpath problem, Michael Kay |
Month |