[Bug 8253] [XSLT 2.1] Allow xsl:variable before xsl:param

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8253





--- Comment #4 from Greg Beauchesne <gbeauch1@jhu.edu>  2009-11-10 11:35:53 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Reclassifying this as input to XSLT 2.1.
> > 
> > I don't have strong views on it either way.
> > 
> > There's been a related request to allow xsl:variable to appear before xsl:sort.

Yes, I saw that request and figured this one was along similar lines.

> To be able to specify xsl:variable before xsl:sort is quite useful, and can
> solve quite a number of new use cases.
> 
> But specifying xsl:variable between xsl:param's doesn't look good to me. To my
> thinking, that would violate the widely accepted norms of subroutine structure.

Well, there are a few things, though.

1. The ability to specify xsl:variable before xsl:sort doesn't add any
functional capability to the language that it didn't already have (and thus
doesn't allow you to solve anything you couldn't already solve). But it, like
this, allows you to follow that common rule of programming: "don't repeat
yourself." XSLT, being a functional language, doesn't suffer any side effects
from throwing in variables there, which makes them a nice tool for reuse in
both places.

2. As demonstrated, this is already possible with xsl:param. If you want to
argue from a design standpoint, it would seem to me that it's better design to
reflect the intent of the programmer when possible, rather than resorting to
workarounds with potentially unintended consequences. In this case, the intent
is "here's a sub-expression I want to reuse" as opposed to "here's a parameter
I want to allow callers to override".

3. Parameter defaults can already get pretty complicated when using the element
content instead of @select, and that includes putting xsl:variable inside.
(although of course that has no scope outside of the parameter default)
Granted, a good editor with XML element-folding capabilities will hide this
part from you, but when looking at the full XML, there's visually not much
difference between this:

<xsl:param name="param1">
    <xsl:variable name="x" select="..." />
    <xsl:variable name="y" select="..." />
    ...
</xsl:param>
<xsl:param name="param2" select="..." />

...and this:

<xsl:param name="param1" select="..." />
<xsl:variable name="x" select="..." />
<xsl:variable name="y" select="..." />
<xsl:param name="param2" select="..." />

-----

Overall, were it not for the existence of default parameter values, I would
agree with you; hence why I said in the initial request "Likewise for
xsl:function if it is ever decided to allow for default parameter values
there." -- there's no need without the defaults. But we have them, they are
incredibly useful (especially when defining defaults in terms of other
parameters), and I think this would be something that would not hurt the
language.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 10 November 2009 11:35:55 UTC