RE: Non-XML XSL output

["Jonathan Borden" <jborden@xxxxxxxxxxxx>]

Simon St.Laurent wrote:
>
>
> I've been studying the XSL spec today, with some help from a few folks
> who've sent me pointers.  Unfortunately, I feel like I'm stuck anyway.
>
...
>
> This suggests to me that the result of the transformation process
> is an XML
> document, or at least a tree representation of an XML document.

	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.

>
> Because there isn't really a clear explanation of what the output of the
> transformation process, when used separately from FOs, should be, I'm not
> sure.  On the one hand, it seems like a lot of folks want to say that XSL
> is for generating XML, one variety of which is formatting objects.  On the
> other hand, it seems like that dedication to XML isn't exactly hard and
> fast when it comes to implementation time.

	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 .. >

>
> Using result-ns this way seems to open up XSL transformations to an
> XML->anything transformation, which could be interesting.  But is
> that what
> we actually want here?  If that is what we want, is there more work that
> needs to be done on the transformation end to make this more
> generally useful?
>

	This is the purpose of the FO half of the XSL spec. As you and many others
have noted, the XSL transformation process is capable of generating
well-formed HTML+CSS. I think that because HTML 4.0 and XHTML are so close,
the XSL spec provides a 'shortcut' to allow a processor to generate HTML 4.0
directly, without needing to implement the full FO part of the spec.


> 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.


Jonathan Borden
http://jabr.ne.mediaone.net



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