RE: Non-XML XSL output

At 04:16 PM 2/27/99 -0500, Jonathan Borden wrote:
>	Yes, this is always correct. The result of an XSL <em>transformation</em>
>is the tree representation of an XML document. However, this tree may serve
>as an intermediate data structure to be fed into a back-end processor which
>then outputs a non-XML document.
>
>	The way to understand this is that an FO tree is really an intermediate
>data structure which is to be fed into a 'back-end' processor. This back-end
>processor is responsible for taking an FO tree, i.e. the tree which is
>created via the XSL transformation step, and creating the output document.
>This output document may be in an arbitrary text or binary format e.g.
>postscript, rtf, pdf, gif, html etc.
>
>	It is also conceivable that a non-FO tree which is produced via the
>transformation stage (e.g. XHTML) be output as traditional HTML in the
>post-transformation stage (for example optional start and/or end tags could
>be ommitted and legal HTML would still be produced. This is especially true
>when empty content model elements such as the META tag are used. Old-style
>HTML validation 'complains' about <META ... /> as opposed to <META .. >
>
>> On the other hand, taking a 'worse-is-better' approach here
>> might lead to other questions regarding a 'worse-is-better'
>> approach to the
>> entire spec, which is why I've been questioning the need for FOs
>> (and their
>> incompatibility with CSS) all along.
>
>	I imagine that one reason vendors have delayed implementing the FO part of
>XSL is that unless the intention is to output other than XHTML, FO doesn't
>provide anything that can't be accomplished by HTML+CSS (leaving intact the
>possibility that FO might be a preferred mechanism even when using XHTML).
>FO sees its use when the intention is to output other than HTML or another
>XML derivative (i.e. for ps,pdf,rtf etc.)
>
>	It is conceivable that a use of result-ns might be a signal to an XSL
>processor than the FOT be subsequently processed into a particular non-XML
>format after the initial transformation.

All of this is great, and highly useful, but in the context of 'full' XSL,
and not just the tree-construction part.  What I find difficult to accept
is that a tool which purports only to handle the transformation end is
outputting stuff that ain't XML, especially given the context of the
discussions on this list and section 2.5, based on a namespace.

If I started outputting troff files directly without concern for formatting
objects, I think there'd be a sudden round of griping.

It seems as if we're sticking back-end processors on XSL here that have
behaviors not defined by the specification but without acknowledging that
fact.  Supporting old-style SGML-valid HTML is pretty much a waste of time
in my book - 99.5% of HTML authors never gave a damn about SGML validity,
though with luck, some of them may find XML validity more interesting.
(I'm striving to make my site well-formed XML, not valid HTML.  Browsers
don't mind, not at all.)

If we're going to operate this way, it's fine with me - just drop all the
"we're only generating XML" rhetoric and make XSL a more generally usable
tool.  If 'worse is better' is genuinely the game plan, lets figure out
which worse we're implementing and do it right.

Simon St.Laurent
XML: A Primer / Building XML Applications (April)
Sharing Bandwidth / Cookies
http://www.simonstl.com


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