RE: [xsl] Re: Accounting for Arbitrary Wrappers Without Going Mad

Subject: RE: [xsl] Re: Accounting for Arbitrary Wrappers Without Going Mad
From: "McNally, David" <David.McNally@xxxxxxxxxx>
Date: Thu, 24 Oct 2002 14:41:06 -0400
I see the problem of using wrapper elements to indicate changes and how they
can interfere with regular style sheet processing.  I reckon it would be
possible to write your style sheet to work around the possibility of these
wrapper elements, but I can see situations where it would be hard (e.g. if
you wanted to check the position of an element's grandparent - maybe
position(ancestor::*[name() != 'delete'][1]/ancestor::*[name() !=
'delete'][1]) - pretty horrible).  

Dimitre's solution of converting to attributes instead of wrappers seems the
only way to proceed, but obviously if you are tied to Epic you need to be
able to do this conversion seamlessly.  I'm not sure if it's a good idea,
but here's my attempt that applies generic templates to remove the delete
wrappers and add the attributes, feeding the result into a variable that
then gets processed by the main templates (mode secondrun).  Obviously it
requires the node-set extension function.  I don't know if this is an
obvious strategy, but it was non-intuitive to me, so I thought I'd post it.
I also wonder if there are problems with doing this...

Thanks,
David.
--
David McNally            Moody's Investors Service
Software Engineer        99 Church St, NY NY 10007 
David.McNally@xxxxxxxxxx            (212) 553-7475 

XML:
<?xml version="1.0" encoding="UTF-8"?>
<document>
  <title>My document</title>
  <section num="1">
    <title>First Section</title>
    <subsection num="1">
      <title>First Subsection</title>
      <para>1.1.1 Some text some text some text some text </para>
      <para>1.1.2 Some text some text some text some text </para>
    </subsection>
    <subsection num="2">
      <title>Second Subsection</title>
      <para>1.2.1 Some text some text some text some text </para>
<delete>
      <para>1.2.2 Some text some text some text some text </para>
</delete>
    </subsection>
  </section>
  <section num="2">
    <title>Second Section</title>
<delete>
    <subsection num="1">
      <title>First Subsection</title>
      <para>2.1.1 Some text some text some text some text </para>
      <para>2.1.2 Some text some text some text some text </para>
    </subsection>
</delete>
    <subsection num="2">
      <title>Second Subsection</title>
      <para>2.2.1 Some text some text some text some text </para>
      <para>2.2.2 Some text some text some text some text </para>
    </subsection>
  </section>
</document>

XSLT:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
exclude-result-prefixes="msxsl">
  <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

<xsl:template match="/">
  <xsl:variable name="document">
    <xsl:apply-templates select="*" mode="firstrun"/>
  </xsl:variable>
  <xsl:apply-templates select="msxsl:node-set($document)" mode="secondrun"/>
</xsl:template>
  
<xsl:template match="delete" mode="firstrun">
  <xsl:copy-of select="@*"/>
  <xsl:apply-templates mode="firstrun"/>
</xsl:template>

<xsl:template match="*" mode="firstrun">
  <xsl:element name="{name(.)}">
    <xsl:copy-of select="@*"/>
    <xsl:if test="ancestor::delete">
      <xsl:attribute name="delete">
        <xsl:text>YES</xsl:text>
      </xsl:attribute>
    </xsl:if>
    <xsl:apply-templates mode="firstrun"/>
  </xsl:element>
</xsl:template>

<xsl:template match="document/title" mode="secondrun">
  <h1>
    <xsl:attribute name="style">
      <xsl:if test="@delete">
        <xsl:text>color: red</xsl:text>
      </xsl:if>
    </xsl:attribute>
    <xsl:apply-templates mode="secondrun"/>
  </h1>
</xsl:template>

<xsl:template match="section/title" mode="secondrun">
  <h2>
    <xsl:attribute name="style">
      <xsl:if test="@delete">
        <xsl:text>color: red</xsl:text>
      </xsl:if>
    </xsl:attribute>
    <xsl:apply-templates mode="secondrun"/>
  </h2>
</xsl:template>

<xsl:template match="subsection/title" mode="secondrun">
  <h3>
    <xsl:attribute name="style">
      <xsl:if test="@delete">
        <xsl:text>color: red</xsl:text>
      </xsl:if>
    </xsl:attribute>
    <xsl:apply-templates mode="secondrun"/>
  </h3>
</xsl:template>

<xsl:template match="para" mode="secondrun">
  <p>
    <xsl:attribute name="style">
      <xsl:if test="@delete">
        <xsl:text>color: red</xsl:text>
      </xsl:if>
    </xsl:attribute>
    <xsl:apply-templates mode="secondrun"/>
  </p>
</xsl:template>
  
</xsl:stylesheet>

> -----Original Message-----
> From: Dimitre Novatchev [mailto:dnovatchev@xxxxxxxxx]
> Sent: Tuesday, October 22, 2002 1:07 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] Re: Accounting for Arbitrary Wrappers Without Going Mad
> 
> 
> 
> --- W. Eliot Kimber wrote:
> 
> > I'm trying to implement support in my FO style sheet for Epic
> > Editor's 
> > change tracking markup. This markup is in a unique name 
> space and may
> > be 
> > wrapped around any element or text to indicate whether the 
> element is
> > 
> > added or deleted.
> > 
> > Within the scope of paragraphs it's not a big deal because the 
> > processing in that context is pretty simple. But above the 
> paragraph 
> > level it gets pretty funky because the presence of the 
> wrappers will 
> > throw off match statements. I could of course add match 
> options that 
> > include the Epic change tracking elements, and would do so if that
> > were
> > 
> > the end of it. Unfortunately, I also want to do different 
> processing 
> > based on the interaction of the change tracking markup and a
> > parameter 
> > that's passed in (reflecting the "view change tracking" setting in
> > Epic
> > 
> > itself).
> > 
> > I can't think of an elegant solution to this sort of 
> problem. An easy
> > 
> > solution would be to have the XPath matches simply ignore 
> elements in
> > a
> > 
> > particular name space, but I don't think that's possible. That would
> > at
> > 
> > least keep the base transform working whether the wrappers 
> were there
> > or 
> > not. But it wouldn't solve the larger problem of explosion 
> of matches
> > 
> > and templates.
> > 
> > I'm wondering if there's a general pattern for approaching this type
> > of
> > 
> > markup other than the brute force method?
> > 
> > Thanks,
> > 
> > Eliot
> > -- 
> > W. Eliot Kimber, eliot@xxxxxxxxxxxxxxxxxx
> > Consultant, ISOGEN International
> 
> Hi Eliot,
> 
> You would not have such big problems, in case Epic did not use
> wrappers, but just a simple attribute belonging to their namespace.
> 
> Therefore, if I were in your place, I would try a two-phase approach:
> 
> 1. Convert the Epic editor's markup into an intermediate one, where
> changes are tracked in attributes (or why not even get rid completely
> of Epic's "added value").
> 
> 2. Perform my regular transformation on the standard XML structure
> (just ignoring or copying the tracking attributes)
> 
> 3. (Only if necessary) convert the result back to Epic's wrappers.
> 
> =====
> Cheers,
> 
> Dimitre Novatchev.
> http://fxsl.sourceforge.net/ -- the home of FXSL
> 


---------------------------------------

The information contained in this e-mail message, and any attachment thereto, is confidential and may not be disclosed without our express permission.  If you are not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution or copying of this message, or any attachment thereto, in whole or in part, is strictly prohibited.  If you have received this message in error, please immediately notify us by telephone, fax or e-mail and delete the message and all of its attachments.  Thank you.

Every effort is made to keep our network free from viruses.  You should, however, review this e-mail message, as well as any attachment thereto, for viruses.  We take no responsibility and have no liability for any computer virus which may be transferred via this e-mail message.


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


Current Thread