Subject: RE: XSL Variable not getting set
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Wed, 14 Mar 2007 15:17:48 -0000
|
I don't think this is correct:
- your 'current-group' is out of scope in a named template, selecting the
empty sequence always.
current-group() like most other aspects of the XSLT dynamic context is
passed through to a named template. I don't think it's good coding style to
do this, but it's permitted.
Michael Kay
http://www.saxonica.com/
> -----Original Message-----
> From: Abel Braaksma [mailto:abel.online@xxxxxxxxx]
> Sent: 14 March 2007 14:55
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: XSL Variable not getting set
>
> mIchael wolff wrote:
> >
> > The desired output would be:
> >
> >
> 2007,0017016990001001703914F537,2970.0,3505.0,0,0,0,123.0,0,0,0,0,0,0
> >
> >
> hmm, I get
>
> 2007,0017016990001001703914F537,,0,0,0,0,0,0,0,0,0
>
> which is different by a landslide, I think.
>
> Can you take our request for "smallest possible example, but
> large enough to illustrate your problem" more literal please?
>
> A few remarks on your code:
> - you use 'xsl:apply-imports', but you do not have any
> imports. Also, consider using 'xsl:next-match' instead, which
> gives you more flexibility
> - you have a parent in most match expressions in your
> templates, this is not needed, costs an extra parent-lookup
> by the processor and makes your code less readable.
> - you do not have an entry point for your input (only
> apply-imports there, but no imports). I assumed
> xsl:apply-templates on the same spot.
> - your 'current-group' is out of scope in a named template,
> selecting the empty sequence always.
> - I believe your code can be down to 90% of its size by
> removing the named template 'monthly' and removing the 12
> call-templates. Instead, use a simple xsl:function and/or a
> tiny for-in-return. This will also aid in readability.
> - there's a throw-away template that creates an empty text
> node. This can be rewritten as an empty <xsl:template match="..." />
>
> Not sure this will get you any further, but the results of
> your code are not an error of the processor at least.
>
> Cheers,
> -- Abel Braaksma
|