[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Non-XML XSL output
"Simon St.Laurent" wrote: > > At 04:16 PM 2/27/99 -0500, Jonathan Borden wrote: > > 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. Exactly. When you use specify the result-ns attribute, you are saying to the XSL processor: this XML tree has semantics associated with; process this tree so as to give effect to those semantics. > 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. The result of the tree construction part is a tree, not a sequence of characters or bytes. The spec does not require this tree to be converted to a sequence of characters or bytes. Why not? Because that would be useless overhead in the 'full' XSL case. So what's the right thing for a tool implementing the tree construction part to do? It should provide access to the result tree using a standard interface (in the case of XT this is SAX), and should provide access to the result-ns attribute if specified, and should allow different processing to be associated with different namespaces specified with the result-ns attribute; this allows you to plug in an implementation of the FO part and get a full XSL implementation. That's exactly what XT does. The com.jclark.xsl.sax.Driver class exercises this by associating the HTML 4.0 namespace with a SAX DocumentHandler that writes the XML tree out as an HTML 4.0 document. Note that this processing isn't triggered merely by the result tree's using the namespace. It is only triggered when you also use the result-ns attribute to indicate that you want special processing of the result tree. If you want the result tree written out as XML, don't specify the result-ns attribute. What is difficult to accept about that? > If I started outputting troff files directly without concern for formatting > objects, I think there'd be a sudden round of griping. If it was triggered by use of the result-ns attribute, there would be no cause for griping. Take TeXML for example. If that has a result namespace associated with it, then a browser could be configurable so that when a document with that namespace was encountered, it ran the TeXML to TeX filter, ran TeX and an appropriate driver and displayed the result in the browser. > 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 I don't agree. There are lots of little gotchas with this XML in HTML approach. For example, you have to play all sorts of silly games to get SCRIPT to work. And with old browsers this simply doesn't work. For example, with some browsers you have to use <dl compact> rather than <dl compact=compact>. Eventually everybody will support XHTML, and support for HTML 4.0 won't be necessary, but I think that is several years away. > If we're going to operate this way, it's fine with me - just drop all the > "we're only generating XML" rhetoric It's not rhetoric. We are only generating XML trees. We also provide a way of triggering processing of that tree. That's the minimum that's needed to support 'full' XSL. James 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
|