xsl-list
[Top] [All Lists]

Re: [xsl] output the result of the transformation twice, indented and not indented, without duplicating the code

2022-05-23 15:31:23
At 2022-05-23 20:17 +0000, Wolfhart Totschnig wolfhart(_dot_)totschnig(_at_)mail(_dot_)udp(_dot_)cl wrote:
Thank you very much, Ken, Martin, and Graydon!

Martin's solution seems the simplest. I found that it can be shortened to the following:

   <xsl:output method="xml" indent="no"/>
   <xsl:template match="/">
      <xsl:apply-templates/>
      <xsl:result-document href="indented.xml" indent="yes">
         <xsl:apply-templates/>
      </xsl:result-document>
   </xsl:template>

That is, I can omit one of the <xsl:result-document>, given <xsl:output/>.

@Ken: I don't understand why <xsl:next-match/> would be better than <xsl:apply-templates/> and where and why I should put "priority='1000'". You write: "That will allow Wolfhart's stylesheet also to support a template rule for the root node." But the above code is the template for the root node, no?

Indeed it is ... but what if already you had written a template for the root node? Using <xsl:apply-templates/> as you have above would push the children of the root node and your previously-written template for the root node never would be triggered.

Regarding priority, if your <xsl:template match="/"> is in the same stylesheet fragment as your template above, there would be an ambiguous match for the root node when processing begins. Adding priority="1000" (or some number higher than the highest priority you have if you have multiple templates for the root node as I do in some of my projects) removes the ambiguous match and ensures your new template above would trigger first, and not your original template rule for the root node. Then your original template rule for the root node would fire as expected.

I like Martin's approach because you don't need the memory for the storage of the template results ... but I didn't realize you ALWAYS wanted both results. I thought you were looking for two stylesheets with different results but with no maintenance headaches (at least related to having the two stylesheets!). Then you could invoke either or both.

Graydon's approach saves the time for executing the transformation twice, but with the penalty of internal storage, so you would have to factor that in to weighing your alternatives.

. . . . . . Ken



On 23-05-22 15:29, Martin Honnen <mailto:martin(_dot_)honnen(_at_)gmx(_dot_)de>martin(_dot_)honnen(_at_)gmx(_dot_)de wrote:

On 23.05.2022 21:07, G. Ken Holman <mailto:g(_dot_)ken(_dot_)holman(_at_)gmail(_dot_)com>g(_dot_)ken(_dot_)holman(_at_)gmail(_dot_)com wrote:
Martin, I would suggest a slight change to your code:

  <xsl:next-match/>

... rather than:

  <xsl:apply-templates/>

... and when the heavy-lifting code is not being imported, then put a
priority="1000" on the suggested match.

That will allow Wolfhart's stylesheet also to support a template rule
for the root node.


Agreed, that is a better way, should have thought about it probably as
it is an easy way in XSLT 2 and 3.


<http://www.mulberrytech.com/xsl/xsl-list>XSL-List info and archive
<http://lists.mulberrytech.com/unsub/xsl-list/96802>EasyUnsubscribe (<>by email)


--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/s/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--


<Prev in Thread] Current Thread [Next in Thread>