On 2015-09-12 Henning Hraban Ramm wrote:
> Am 2015-09-12 um 18:14 schrieb luigi scarso <luigi.scarso@gmail.com>:
> 
> > Do you know a good XSLT processor except Saxon? Its free version is
> > just too limited.
> > 
> > xsltproc for xslt 1.0, but you are looking for xslt 2.0 , right ?
> 
> No, the only extension from commercial Saxon ...
 
XSLT 1.0 is capable to handle anything (turing machine).
XSLT 2.0 brings some syntactic sugar.
XSLT 3.0 supports streaming.
 
If you need 2.0 features, you can use Saxon-B 9.1.0.8 (free, but not
maintained any more).

> ... I would need are global variables.

In pure XSLT any variable is fixed and its value cannot be changed. There
are, however, different approaches how to accomplish this. Most common is
defining template parameters and passing the proper values via them, see
below.

> E.g. if I don’t markup all my paragraphs (because it clutters the
> source too much and is tedious), I get <break />s between the original
> paragraphs. I could convert these to HTML <p>s like:
> 
> 
> <xsl:variable name="within-paragraph">0</xsl:variable >
> 
> <xsl:template match="break">
> <xsl:if test="within-paragraph = 0">
> <xsl:text disable-output-escaping="yes"><![CDATA[</p><p>]]></xsl:text>
> </xsl:if>
> <xsl:if test="within-paragraph > 0">
> <br />
> </xsl:if>
> </xsl:template>
> 
> <xsl:template match="paragraph">
> <xsl:variable name="within-paragraph">1</xsl:variable >
> <p><xsl:apply-templates/></p>
> <xsl:variable name="within-paragraph">0</xsl:variable >
> </xsl:template>


<xsl:template match="your-element" name="your-element">
   <!-- default value -->
   <xsl:param name="within-paragraph" select="0"/>
   <!-- your code -->
</xsl:template>

<xsl:apply-templates select="your-element">
   <!-- overriding a default value -->
   <xsl:with-param name="within-paragraph" select="1">
</xsl:apply-templates>


Btw, istead of 
<xsl:text disable-output-escaping="yes"><![CDATA[</p><p>]]></xsl:text>

you can write 
<p/>


> Maybe there’s another solution, but I’m not comfortable enough in XSL
> to see it.

Yes, functional programming requires different approaches, but I undestand
it can be tough. As for me in early stages :-)

Jan