Re: why split? [was RE: XSL intent survey]
Hi. On the subject of a super or subset approach to XSL, wouldn't it be the case of transformation as the core and formatting as the superset? XSL at essence is surely transforming one XML tree into another... am I missing something here? If it's not transforming you feed XML in, and all you get out is... what, the same XML? And while it may not be the case in fact, I had certianly fallen into thinking of the XSL flow-objects as a superset of XSL core... although I admit on reflection that this may well be an erroneous attitude on my part (I'll have to go to the spec and think on that.) I think this position understandable as the flow-objects occupy a seperate namespace. I'm going to have to go back over the archives really and read up on the history of this discussion of an XSL split... I'm obviously missing something fundamental.... and I shouldn't really be shooting my mouth off from an historicaly ill-informed position. It just seems to me we have XSL transformation syntax, which can be refined and developed, and on top of that we have proposed flow objects that may be *optionaly* used (sounds like a superset to me). I'm not understanding what the problem is with this arrangement. As for the issue of XSL operating like a scripting language... Why? Why would anybody want it to. If you want XML transformation with a programatic approach rather than a declarative, descriptive approach there are countless languages one could choose to do this with. For those that want to push the extra mile, <xsl:eval> with ECMAscript would do that (if it becomes part of the spec.) So we'd have transformative declarative syntax, with optional flow objects, and optional scripting. To my mind (and I realise everybody has their own biased interests) this would be an appropriate order for prioritising consideration. Please feel free to knock holes in my statements, I'm genuinely assuming that I'm missing something here, and would appreciate being filled in. Cheers Guy. xsl-list@xxxxxxxxxxxxxxxx on 11/23/98 04:51:51 PM To: xsl-list@xxxxxxxxxxxxxxxx cc: (bcc: Guy Murphy/UK/MAID) Subject: Re: why split? [was RE: XSL intent survey] Oren (et al.) -- Something just occurred to me that might let us "have it both ways." I offer it in the hopes that it will either be peppered with buckshot as essentially unworkable, or not :). The discussion has been framed as a choice between splitting XSL into transformation and presentation components, and putting both of those components into a single baseket, as it were. I wonder if there might be a "middle way": supersetting XSL with a more robust transformation-only level. As I'm envisioning it, XSL-Core would provide all of the formatting facilities and a modicum of transformations -- certainly at least those necessary to make the formatting work. XSL-Enhanced (or whatever) would use the same "syntax" as -Core but provide a richer, more complex set of transformational capabilities (such as those possible with full-blown DSSSL or TeX, maybe, although I'm not familiar enough with either to say for sure). This would not completely resolve the issue. As an XML application in its own right, XSL would still remain at root a declarative language, not a procedural one, and so those who long to make it function as a "scripting" language are probably going to remain disappointed. Best, JES ============================================================= John E. Simpson | It's no disgrace t'be poor, simpson@xxxxxxxxxxx | but it might as well be. | -- "Kin" Hubbard XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 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