d-o-e in extension element contents (was Re: Welcome c

Mike Brown <mike@xxxxxxxx> wrote:
> 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.

Well, i should have restricted my statement to "Standard XSLT"
without extensions. After all, extensions may break almost
everything.


I don't quite grok the purpose of the extension element you
are describing, but every time this topic is discussed i think
of a xpath function "parse()" which will parse the argument
string as a general external parsed entity and return the
resulting node set. It's a portable though not always the most
efficient way to avoid d-o-e for many purposes completely.
I wish the standardization committee had defined it this way,
you can insert strings with markup from other sources in the
result tree in a safe way but it doesn't allow hacks like
  <xsl:if test="not(val=previous-sibling::foo/val)">
   <xsl:text disable-output-escaping="yes"><[CDATA[</tr><tr>]]></xsl:text>
  </xsl:if>
I have an URIResolver implementing a "parse:" and a "parsehtml:"
protocol emulating the parse() function for doing embeddings
noted above.

Other possibilities to deal with d-o-e hassles:
- Extension of the DOM and SAX APIs to cover output controls
  and d-o-e-adornments on elements. This would also take care
  of some encoding issues which are plaguing this list regularly
  in connection with the MSXML-processor writing to a string (and
  thereby loosing the output encoding).
- Mandating serializing/reparsing of the output in case any
  d-o-e directive has been encountered. However, this lacks
  style :-)

I'm not sure how your extension element problem would fit in.

Regards
J.Pietschmann

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list