Non-XML XSL output

Subject: Non-XML XSL output
From: "Simon St.Laurent" <simonstl@xxxxxxxxxxxx>
Date: Sat, 27 Feb 1999 14:45:19 -0500
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.

I started because a key issue on this list has been the use of XSL
transformations to generate non-XML output.  At one point, this seems like
something that wasn't being encouraged, and discussions about making CSS
and XSL more amenable seemed to break on the reefs of this issue.

Looking at the draft, however, we have several possibilities.

The Note in 2.2 states:

>NOTE: If an implementation wishes to use something in the result tree 
>or stylesheet to control the output of a non-XML representation of the 
>result tree, it should use the result namespace. In particular, if it 
>wishes to make use of something in the result tree or stylesheet to 
>indicate that the result tree should be output as HTML that conforms 
>to the HTML 4.0 Recommendation rather than as XML, it should use a 
>result namespace of; for example, 

While 2.4 states: 

>XSL operates on an XML document, whether a stylesheet or a source 
>document, as a tree. Any two stylesheets or source documents that 
>have the same tree will be processed the same by XSL. The XML 
>document resulting from the tree construction process is also a tree.

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.

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.

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?

It would help with the integration of XML into legacy environments,
certainly.  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.

Just curious!

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

 XSL-List info and archive:

Current Thread