RE: [xsl] Problem with handling processing instructions

Subject: RE: [xsl] Problem with handling processing instructions
From: "Nagai, Paul" <pnagai@xxxxxxxxxxx>
Date: Fri, 7 Mar 2003 07:31:56 -0800
Hi Jon,

> I've written this xslt template to process deletion marks:
> 			<xsl:template
match="processing-instruction('xm-deletion_mark')">
> 			  <fo:block color="red">
> 			   **** deleted item
> 			   <xsl:apply-templates/>
> 			  </fo:block>
> 			</xsl:template>
> But the template is ignored when I run the MSXML xslt parser.  Can anyone
tell me what I'm > doing wrong?  or if this is possible?

I am trying to do something similar with a pair of nolinebreak PIs. I have
it about 80% working. I can match the first PI. I can then process the text
node between the two PIs from the template matching that first PI. However,
I need to write templates that will prevent re-processing of the text node
contained between the two PIs. (I already ignore the second PI.) I
<xsl:naive>assumed</xsl:naive> that when I matched the first PI I was
actually processing the entire "PI-node" just like it was an element. Wrong.
Are you making this same assumption? Are you wrong, too?

Anyhow, Dimitri, I believe, helped me with the code to process the text node
between the two PIs. I figure it might be helpful for your changemarkup
pairs.

If you've written a template to ignore the text node in between, I'd love to
see that template. Also, I am pretending for the moment there aren't OTHER
element nodes that might be nested between the nolinebreak PIs. You are
probably much more likely to have to consider that sort of case ... again,
I'd like to see your code.

Finally, my PI looks like this: <?Pub _nolinebreak?>. Note that I am able to
match the Pub easily but that there is an odd behavior (bug?) comparing the
_nolinebreak "attribute" or content of the PI. I must include a trailing
space! Don't know why. Hate it. But, so it goes.

I'm using the xalan processor included with Arbortext Epic v4.2.3 ... I
don't know what version that makes it.
================================================
<!-- required for replacing space with &nbsp; -->
<xsl:variable name="amp">&#38;</xsl:variable>

<!-- called from the initial nolinebreak PI to parse the text node -->
<xsl:template name="replace-text">
   <xsl:param name="text"/>
   <xsl:param name="replace" />
   <xsl:param name="by"  />
   <xsl:choose>
   <xsl:when test="contains($text, $replace)">
      <xsl:value-of select="substring-before($text, $replace)"/>
      <xsl:value-of select="$by" disable-output-escaping="yes"/>
      <xsl:call-template name="replace-text">
         <xsl:with-param name="text" select="substring-after($text,
$replace)"/>
         <xsl:with-param name="replace" select="$replace" />
         <xsl:with-param name="by" select="$by" />
      </xsl:call-template>
   </xsl:when>
   <xsl:otherwise>
      <xsl:value-of select="$text"/>
   </xsl:otherwise>
   </xsl:choose>
</xsl:template>			

<xsl:template match="processing-instruction('Pub')">
	<xsl:variable name="instruct">
		<xsl:value-of select="."/>
	</xsl:variable>
	<xsl:choose>
		<xsl:when test="$instruct='_newline '">
			<br/>	
		</xsl:when>
		<xsl:when test="$instruct='_nolinebreak '">
			<xsl:variable name="contextpi" select="."/>
			<xsl:variable name="followingpi"
select="following::processing-instruction()[1]"/>
			<xsl:variable name="nbsptext"
select="$contextpi/following-sibling::node()[count(. |
$followingpi/preceding-sibling::node())=count($followingpi/preceding-sibling
::node())]"/>
			<xsl:call-template name="replace-text">
				<xsl:with-param name="text"
select="$nbsptext"/>
				<xsl:with-param name="replace" select="'
'"/>
				<xsl:with-param name="by"
select="concat($amp, 'nbsp;')"/>
			</xsl:call-template>
		</xsl:when>
		<xsl:otherwise></xsl:otherwise>
	</xsl:choose>
</xsl:template>
================================================

I have considered (dare I admit this on this list?) doing a global replace
of the nolinebreak PIs, formatting them like an element, so I can use XSL
much more easily to process the interior text and possible element nodes.
Maybe I'll just use that strategy as a stop-gap solution until I get more
time to write better XSL. Brute force does work ... :/

------
Paul Nagai

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread