An XSL processor can do other things with the result tree than just
write it out as XML.
If you want to use XSL to produce some non-XML format, first you need to
devise an XML representation of it. For example, in the case of HTML,
this would be "well-formed HTML", that is XML using the element types
and attributes of XML. Now write some code that turns this XML
representation into the real thing. Now you've just got to arrange for
this code to get run instead of the usual code that writes the result
tree out as XML. You've got two possibilities. One possibility is to
make this a run-time option for your XSL processor. Another is to use
the result-ns attribute. To use this you need to define a namespace for
your HTML representation, make all result elements be from this
namespace, and specify this using result-ns. Then your XSL processor
can recognize the namespace and do the right thing. For example,
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/TR/WD-xsl"
xmlns:h="http://www.w3.org/TR/REC-html40"
result-ns="h">
<xsl:template match="/">
<h:html>
...
</h:html>
</xsl:template>
</xsl:stylesheet>
This gives an XSL processor everything it needs to recognize that you're
generating HTML and do the right thing so you get real HTML.
The XML representation for another format can be very simple. For
example, if you wanted to generate RTF, you could probably get away with
two element types: one element type for the root, and one element type
to contain RTF control information (outside elements of this type you
would escape {, } and \ as \{, \} and \\}, inside it you would not).
You might want an element type for \bin too.
James