Subject: RE: [xsl] XSLT 1.1 comments - please stop the bleeding From: "Evan Lenz" <elenz@xxxxxxxxxxx> Date: Wed, 14 Feb 2001 13:47:07 -0800 |
David Carlisle wrote: >xsl:script, despite its name, isn't about encouraging the use of scripting languages. Some things are technically correct but, practically, they are just wrong. I think this is a perfect example. I have already heard some people praising XSLT 1.1's inclusion of xsl:script, because, they say, some problems are just better solved in procedural code, and this will give them a chance to do so. This is the first impression that people will get of xsl:script--that now they're able to include procedural code. This is a wrong impression, because they always were able to do so if they used an XSLT processor that supports an extension for this. With xsl:script, they will still need an XSLT processor that supports an extension for this. xsl:script is designed to lessen the sting of the non-portability of extensions. But by making extensions "somewhat more portable", it will deceive many people into thinking it is now safe to use extension functions (or thinking that they aren't using an extension function at all). The reality is that it never was safe and still isn't safe to do so, where "safe" means that all XSLT processors will support it. That's the essence of extensions; I understand that. The problem with xsl:script is that it doesn't look like an extension. XSLT 1.0 includes a purposeful hole in the model of pure, declarative tree transformations. This hole coincides with what is non-portable. In particular, this hole consists of serialization hooks (xsl:output, disable-output-escaping, etc.) and extensions. I can think of two primary advantages provided by extensions: 1) XSLT, though in its infancy, is able to solve real-world problems. 2) Implementors and users are able to provide feedback to the W3C about what extensions work well. I believe that keeping this hole small is of utmost importance. If true portability is an ultimate aim, then effort should be put into making this hole narrower, not wider. xsl:script widens this hole. The distinction between tactics and strategy comes to mind. xsl:script takes headaches away now at this stage in the game, but it is counterproductive to the ultimate strategy of developing a portable, powerful language. (Is that not the goal?) XSLT 1.0 even goes out of its way to provide fallback mechanisms for when particular extensions are not available. This is an effort to stifle the blow of the non-portability of extensions. It too is a way of making extensions "somewhat more portable." I understand that xsl:script works along these same lines. But if portability is a true goal, should we be giving extensions even *more* concessions? Especially when XSLT 2.0 is largely about taking away the need for certain extensions? Please, please, think of the long-term ramifications of xsl:script. I fully agree and recognize that xsl:script would take away many headaches, including some of my own. But I also believe this would provide only a short-term benefit that's not worthy of further widening that hole. The escape mechanisms are there; people use them. Users and implementors are learning what works and what doesn't. XSLT is growing and maturing. It takes time and experience. In my mind, this debate comes down to one very important question: Are XSLT extensions designed to be here forever or not? In any case, it seems early to assume that they will be here forever and that we should now make further efforts to make them more practical to use (xsl:script). With rumors about XPath 2.0 including support for XSDL data types, etc., it seems awfully early to signal defeat in the battle for portability. Or was this battle never to be fought? Francis Norton wrote: "But XSLT is also good at providing cross-platform portability - indeed one of it's strengths is that it is more portable than *any* language. This is something that the XSLT community are, I suspect from feedback in this list, very keen on...For me, and I suspect for many on xsl-list, what XSLT does is provide *platform-independent* XML processing." I wholeheartedly agree with Francis. I hope that the XSL Working Group will take these apparently widespread concerns to heart and reevaluate their requirements for XSLT 1.1. Evan Lenz XYZFind Corp. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 1.1 comments (in def, Uche Ogbuji | Thread | Re: [xsl] XSLT 1.1 comments - the c, Francis Norton |
Re: [xsl] XSLT 1.1 comments, Steve Muench | Date | [Fwd: Re: [xsl] XSLT 1.1 comments (, Uche Ogbuji |
Month |