Subject: RE: Non-XML XSL output From: "Simon St.Laurent" <simonstl@xxxxxxxxxxxx> Date: Sat, 27 Feb 1999 18:36:48 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Non-XML XSL output, Jonathan Borden | Thread | Re: Non-XML XSL output, James Clark |
RE: Non-XML XSL output, Jonathan Borden | Date | Re: XT and HTML conversion, Paul Prescod |
Month |