Page: http://wiki.cocoondev.org/Wiki.jsp?page=XSLTDisableOutputEscaping ,
version: 1 on Tue May 27 23:01:34 2003 by JoergHeinicke
New page created:
+ !! What's bad with {{disable-output-escaping}} in XSLT?
+
+ {{{
+ <xsl:text disable-output-escaping="yes">&amp;nbsp;</xsl:text>
+ }}}
+
+ Quoting a message from Michael Kay from March 2001:
+
+ "...Cocoon, I think, does further processing of the XSLT output. This is
exactly the scenario that makes "{{disable-output-escaping}}" bad programming
practice, and the reason that the XSLT spec says processors aren't obliged to
support it. Basically, if the XSLT output is serialized to text and sent
straight to the browser, your're probably OK, but if the output is a tree that
is then input to further stages of processing, then you aren't..."
+
+ J. Pietschmann provided a [collection of several
issues|http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=105362820521196&w=2]:
+
+ "A JAXP conformant XSLT processor may generate PIs embedded in the output to
signal a {{disable-output-escaping="yes"}} to downstream processing stages. If
the serializer finally gets these PIs and
+ understands them, d-o-e will work fine even in Cocoon.
+ \\
+ However, there's plenty of stuff that can go wrong:
+ # The d-o-e'd stuff is still text to downstream XML processing stages, it
can't be processed as elements.
+ # Generating the PIs is not required. Xalan does, I'm not sure whether Saxon
does.
+ # The PIs are not standardized. So you'd better use an identity
transformation with the same XSLT processor which generates them for
serialization. Fortunately, Cocoon does exactly this. Nevertheless, if you mix
processors, you're likely to get trouble.
+ # If some processing stage decides to eat or mangle the PIs or to change
their position relative to the stuff intended to be d-o-e'd, you're hosed."
+
+ Other stuff about {{disable-output-escaping}} can be found in the [XSLT
FAQ|http://www.dpawson.co.uk/xsl/sect2/N2215.html].
+
Page: http://wiki.cocoondev.org/Wiki.jsp?page=HtmlTableCellNonBlanking ,
version: 18 on Tue May 27 23:02:19 2003 by JoergHeinicke
+ Why? Please read on this issue at [XSLTDisableOutputEscaping].
- Quoting a message from Michael Kay from March 2001:
-
- "...Cocoon, I think, does further processing of the XSLT output. This is
exactly the scenario that makes "{{disable-output-escaping}}" bad programming
practice, and the reason that the XSLT spec says processors aren't obliged to
support it. Basically, if the XSLT output is serialized to text and sent
straight to the browser, your're probably OK, but if the output is a tree that
is then input to further stages of processing, then you aren't..."
-
- J. Pietschmann provided a [collection of several
issues|http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=105362820521196&w=2]:
-
- "A JAXP conformant XSLT processor may generate PIs embedded in the output to
signal a {{disable-output-escaping="yes"}} to downstream processing stages. If
the serializer finally gets these PIs and
- understands them, d-o-e will work fine even in Cocoon.
- \\
- However, there's plenty of stuff that can go wrong:
- # The d-o-e'd stuff is still text to downstream XML processing stages, it
can't be processed as elements.
- # Generating the PIs is not required. Xalan does, I'm not sure whether Saxon
does.
- # The PIs are not standardized. So you'd better use an identity
transformation with the same XSLT processor which generates them for
serialization. Fortunately, Cocoon does exactly this. Nevertheless, if you mix
processors, you're likely to get trouble.
- # If some processing stage decides to eat or mangle the PIs or to change
their position relative to the stuff intended to be d-o-e'd, you're hosed."
-
- Other stuff about {{disable-output-escaping}} can be found in the [XSLT
FAQ|http://www.dpawson.co.uk/xsl/sect2/N2215.html].
