Subject: [xsl] d-o-e in extension element contents (was Re: Welcome comments...) From: Mike Brown <mike@xxxxxxxx> Date: Fri, 7 Dec 2001 10:42:47 -0700 (MST) |
Joerg Pietschmann wrote: > No processor will honor a d-o-e directive unless it serializes the > result. True, but there is some ambiguity in when serialization of the result may occur. It can happen after the result tree is created, but it may also happen when processing an extension element. The XSLT spec doesn't seem to address the possibility that d-o-e can be honored by an extension element as it processes the xsl:value-of and xsl:text elements in its contents. For example, here's a situation we have in 4XSLT with 4Suite Server: We have an extension element that acts upon the serialized-as-XML form of any result fragments that are generated when instantiating its content. <foo:our-element> <greeting>hello</greeting> </foo> In this example, the foo:our-element implementation takes the 'greeting' element and its 'hello' text node child, serializes it as XML into the string '<greeting>hello</greeting>', and passes this string to some other function in the server for additional voodoo to be performed on it. There are times when you may already have the desired XML serialization as a string. In such a case you can't just plop it in an xsl:value-of inside the extension element, like in the following example, because you'll subject it to escaping as it is reserialized. <xsl:variable name="XMLstring" select="'<greeting>hello</greeting>'"/> <foo:our-element> <xsl:value-of select="$XMLstring"/> </foo> And you can't just change the extension element's implementation by plopping the string into an attribute on the element, because attributes are subjected to normalization by the XML parser. Another idea might be to implement an extension function that takes the string as an argument -- but this has the problem that it might be subjected to lazy evaluation. That is, all functions in XPath/XSLT must return the same result when given the same arguments, so a processor might cache the results the first time around and not bother, when processing subsequent function calls, to do the entire instantiation with whatever side-effects it may produce. So in this situation, unless I'm overlooking something, we are left with no option but to honor disable-output-escaping on the xsl:value-of inside the extension element. <foo:our-element> <xsl:value-of select="$XMLstring" disable-output-escaping="yes"/> </foo> - Mike ____________________________________________________________________________ mike j. brown, fourthought.com | xml/xslt: http://skew.org/xml/ denver/boulder, colorado, usa | personal: http://hyperreal.org/~mike/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Welcome comments: White s, Joerg Pietschmann | Thread | RE: [xsl] Welcome comments: White s, Oleg Tkachenko |
RE: [xsl] whitespaces, Oleg Tkachenko | Date | RE: [xsl] Is this a known msxml3 bu, Oleg Tkachenko |
Month |