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(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--