xsl-list
[Top] [All Lists]

Re: [xsl] mode computation case

2010-08-31 12:17:56
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(_at_)mulberrytech(_dot_)com
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
======================================================================


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--