Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 01:47 PM 8/27/2008, Andy wrote:
The above doesn't handle namespaces, processing-instructions, comments, or mixed content, but it could be hacked to do so. Is there a reason why this approach would not work in XSL 1.0 to satisfy his needs? No, there isn't. And see http://www.xmlportfolio.com/xml-to-string/. Martin writes: Yes, the reason is that you can't do the apply-templates on the result tree fragment, you would first need to convert it to a node-set with an extension function. This being the case, he could still do tag-writing instead of RTF-building in the logic that created the RTF to begin with: <xsl:template match="paragraph" mode="HTMLwrite"> <!-- write an HTML-ish 'p' --> <xsl:text><p></xsl:text> <xsl:apply-templates mode="HTMLwrite"/> </xsl:text></p></xsl:text> </xsl:template> Note that: (a) In the real world, I'd struggle mightily to avoid having to do this. The requirement is fishy, and I'd want to see it justified within a reasonable architecture before I'd willingly code it. This kind of thing is done for bad reasons far more often than for good reasons, and usually shouldn't have to be done at all. (But I can imagine respectable reasons.) (b) Having accepted the requirement, I'd far sooner do it by pipelining (as suggested by Martin) rather than the hard way, as illustrated here. (c) If I really had to do it the hard way, I'd probably still write a couple of utility templates so I could do something like: <xsl:template match="paragraph" mode="HTMLwrite">
<xsl:call-template name="HTMLtag"/>
<xsl:with-param name="tag" select="'p'">
<xsl:with-param name="attributes">
<xsl:apply-templates select="." mode="HTMLattributes"/>
</xsl:with-param>
</xsl:call-template>
</xsl:template>... which is easier to maintain and less prone to break. Cheers, Wendell
|
