RE: Non-XML XSL output
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format