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 http://www.w3.org/TR/REC-html40; 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 http://www.simonstl.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XT and HTML conversion, Simon St.Laurent | Thread | RE: Non-XML XSL output, Jonathan Borden |
Re: XT and HTML conversion, G. Ken Holman | Date | RE: Non-XML XSL output, Jonathan Borden |
Month |