Re: mode computation case

Regards,
Andri

Dear Andre,

I see the appeal of your line of thinking, but I also agree with Mike
that there are other facilities and features in XSLT 2.0 that could
meet the need, perhaps as gracefully.

In particular, have you looked at XSLT's capability of assigning more
than one mode to a template, and in particular to the new keywords for
modes #default, #current, and #all? Using these in combination with
cascading template matches (using xsl:next-match and explicit priority
settings when necessary) one might accomplish a great deal of what you
are after.

In the simple case:

<xsl:apply-templates select="$nodetree" mode="#current">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>

Please forgive me if your question assumes this kind of thing is
already being done.

Cheers,
Wendell

At 07:08 AM 8/31/2010, you wrote:

Hi Michael,

Interesting idea.

My use-case is about processing a highly structured XML document in
many different ways, including for various types of transformations,
calculations, statistics, reporting, and presentation, as the
document is maintained and evolves, hence the use of different modes,
typically selected, along with a set of parameter values, from user
input, for example.  For a more concrete example, the document could
be a model from a building, or a car, or anything one may wish to
model as a structured XML document, ideally, the universe;).  I see
this pattern as quite basic and fundamental.  I also feel that it
needs to match on the nodes in the different modes rather than on the
modes in different nodes.

What do you think?

Regards,
Andre

 I'm sure one can devise ways of using this feature, but the real
question is whether there are already acceptable ways of solving the
user-level problem. To answer that question, we need a high-level
description of the transformation you want to carry out.

One alternative that comes to mind is to do

<xsl:apply-templates select="@mode">
<xsl:with-param name="nodetree" select="$nodetree"/>
  ...
</

and then have template rules

<xsl:template match="@mode[.=mode1]">
  ...
</xsl:template>

etc.

On 31/08/2010 5:27 AM, ac wrote:

Hi,

I have something like

...
<xsl: variable name="var1" select="...some value or node-set
generating expression"/>
<xsl: variable name="var1" select="...some other value or node-set
generating expression"/>
<xsl: variable name="var1" select="...some other other value or
node-set generating expression"/>
<xsl: variable name="var1" select="...another value or node-set
generating expression"/>
<xsl:choose>
<xsl:when test="@mode eq 'mode1'">
<xsl:apply-templates select="$nodetree" mode="mode1">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode2'">
<xsl:apply-templates select="$nodetree" mode="mode2">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode3'">
<xsl:apply-templates select="$nodetree" mode="mode3">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode4'">
<xsl:apply-templates select="$nodetree" mode="mode4">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode5">
<xsl:apply-templates select="$nodetree" mode="mode5">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode6'">
<xsl:apply-templates select="$nodetree" mode="mode6">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="$nodetree" mode="modeX">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:otherwise>
</xsl:choose>
...

And there is here only 7 modes and 4 parameters, instead, if the
apply-templates could be computed, I would have liked to possibly
have something less redundant, for any number of modes and
parameters, more like
...
<xsl:apply-templates select="$nodetree" mode="@mode">
<xsl:with-param name="param1" tunnel="yes" select="...some value or
node-set generating expression"/>
<xsl:with-param name="param2" tunnel="yes" select="...some other
value or node-set generating expression"/>
<xsl:with-param name="param3" tunnel="yes" select="...some other
other value or node-set generating expression"/>
<xsl:with-param name="param4" tunnel="yes" select="..another value
or node-set generating expression"/>
</xsl:apply-templates>
...

It seems that it could save space, variables, design time, run
time, typos, errors, as well as ease maintenance and update (e.g
adding mode7 and forgetting to add another xsl:when clause for it
...), while increasing readability.

Are there more elegant ways to handle mode selection? Can this be a
useful use-case to support allowing "mode" to be computed somehow,
in future XSLT updates?

Thank you,
ac

======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================