Altova Mailing List Archives


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

From: Wendell Piez <wapiez@---------------->
To:
Date: 3/21/2007 10:10:00 PM
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
======================================================================

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.