Re: [xsl] From WordprocessingML inline styles to nested inline elements

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Yves,

At 01:29 PM 3/21/2007, you wrote:
> David,
>
> I am grateful to you for your very clear and elegant solution!
>
> Wendell,
>
> thank you for your proposition which is almost as good as David's, 
> but which I personally find more difficult to follow. And it 
> requires the stylesheet to explicitly state the element names, which 
> might be a little inconvenient.

David's was neater but mine was more fully commented. :->

And actually, they were the same solution, or based on the same 
approach in effect, with only cosmetic differences.

While David's said "*", mine said "b|i|ul", but that too amounts to a 
cosmetic difference in this case. What's "a little inconvenient" in 
one case might be suitably clear or careful coding in another.

But anyway -- David's *was* nice....

> You wrote:
>
> > I'm a bit puzzled by your statement that you don't want to "hardwire
> > the structure of the tree to create", since that's exactly what the
> > style_nesting element does (and fairly neatly too).
>
> What I meant was: Since I am using the "real" meta-stylesheet method 
> (as opposed to how you characterized your proposal) to generate the 
> stylesheet which is doing the WordprocessingML transformation, I 
> prefer to make the style transformation configurable, by specifying 
> the element equivalents of the styles as well as their nesting in an 
> external XML document with a structure that could look like the one I showed:
>
> <style_nesting>
>   <b><i><u/></i></b>
> </style_nesting>
>
> So it's certainly somehow hard-wired in XML, but not necessarily in XSL.
> Now I have become aware that this opens two ways:
>
> 1) Being totally dynamic, i.e. reading in the mapping and hierarchy 
> description at the operating stylesheet's run time. This is what 
> David's method does.
>
> 2) Being dynamic only in the first step, i.e. generating an 
> operating stylesheet with the style mapping coded in it. This is one 
> aspect of Wendell's solution.
>
> I'll try to experiment with both to find the approach which is more 
> favorable. (And I will have to refine the mapping technique to 
> account for more complex cases than local name identity.)

Now you've got me even more confused.

What I said was that my approach did *not* use a stylesheet to 
generate a stylesheet.

Neither does David's.

And as I said, they were the same solution, allowing for these two 
things to be the same:

A.
<xsl:template match="x">
  <xsl:choose>
    <xsl:when test="$cond">
      <xsl:copy>
        <xsl:apply-templates/>
      </xsl:copy>
    </xsl:when>
    <xsl:otherwise>
      <xsl:apply-templates/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

B.
<xsl:template match="x">
  <xsl:variable name="out">
    <xsl:apply-templates/>
  </xsl:variable>
  <xsl:choose>
    <xsl:when test="$cond">
      <xsl:copy>
        <xsl:copy-of select="$out"/>
      </xsl:copy>
    </xsl:when>
    <xsl:otherwise>
      <xsl:copy-of select="$out"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

... except that A (what David did) is a bit more concise, and B (what 
I did) is a bit more versatile (since you can do things like test 
what's inside $out when you do the test).

Cheers,
Wendell



======================================================================
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
======================================================================