RE: [xsl] XSL Variable not getting set

["Michael Kay" <mike@xxxxxxxxxxxx>]

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] 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