[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] newbie Q: is xsl going away?
Subject: Re: [xsl] newbie Q: is xsl going away? From: "Kucera, Rich" <kucerar@xxxxxxxx> Date: Mon, 25 Aug 2003 14:29:57 -0400 |
Wendell wrote: Why are vendors hopeful that it'll go away, or why do they believe we would welcome its disappearance? I don't know. I think they know we like it and that bothers them, having invested in xquery. I realize we may be talking only of a hypothetical vendor, or of a single sore thumb. Yet the notion seems to persist in places that developers don't like XSLT. I suppose there are those who don't. Yet its use continues to spread -- this can't be only because someone is forcing us to use it against our better judgment, can it? No. Its use continues to expand because developers had already (re)invented it in JSP tag libraries, in complete ignorance of xslt. Then they see xslt and realize they could get it all and more for no cost (and in a *standard*!), and ditch the tag libraries with their cost and brittleness. It's a slingshot effect. Maybe it's another instance of the "Billion-dollar Secret" phenomenon. Those who use XSL happily, use it happily. Those who don't, complain. Thus, we only hear complaints, even while there are more and more happy people all the time. Rich, could you flesh this picture out a bit? Is it more than one vendor? It's just one vendor so far that I've had dealings with that consistently includes anti-xslt in their customer processing. I imagine the other big vendors might do the same. Unless I'm mistakan, the company that was a main force behind xquery still likes xslt, since they fund it but don't make it proprietary :-) There is a java standard that may compete with another application of xslt, which is java page flows (JPF). Basically an application controller in a server-compilable file (compilable in the same sense as JSP). It's the app controller exposed in a top-level artifact in an application, which is editable and compilable on-the-fly. Well, if you piped HttpRequests turned into xml through xslt this is the same effect(a troubling thing is that a basic bare-bones servlet for doing this isn't out there that I have found, you have to bite off the entire Cocoon framework for it). The JPF file is a mixture of Java and special comments that require a special compiler. The other major files in the mix for high-tech web apps are already XML-based--.portal and .portlet files etc. The only oddball (that I've seen so far) is the JPF file. Not to worry, I have seen a way to embed XSL transformations into appropriate places in a JPF file so as to put the controller logic outside in an XSL file :-) Not as fun as a web app in a stylesheet, but still useful perhaps. I would think the more complex an app got, the more the visual IDE would not scale. Whereas with rules in xslt you could extract the pertinent summary info, edit it comparatively quickly etc. but you already know all that. What would account for the assumption that we can't wait to junk XSL and go back to vendor-proprietary technologies with all the costs they entail (now shown to be unnecessary)? Another standard, xquery. But unless I'm mistaken, xquery has formal language elements and is not a parsable file itself, like xslt. Also, unless I'm mistaken, xquery is missing the basic concept of walking the document as a fundamental mechanism to support the declarative thing. It's all pull and destructuring. It is a jump for most programmers to get to the functional xquery land of no-side-effects, but with xslt they have to also jump to the land of declarative/push. As a programmer I like to make these jumps, and don't really understand the perception that there is a reluctance among programmers to do this. Or maybe it is just a vendor or two that would like us to leave behind 80/20 XSLT 1.0, with its oddities, its facility, its ease of use (once you've climbed the initial learning curve) and its relatively small footprint, in favor of a theoretically-more-consistent 99/01 technology that, before you can use it, requires you have to have two advanced degrees, deep knowledge of three other technology "standards" (including their inconsistencies), the latest hardware (with the latest OS of course), the patience of a machine, and certified training from (guess who) the vendor? Which technology is that? :-) Seriously, I've never had that experience, nothing that complicated. Must be a publishing standard. Thanks, -Rich XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] newbie Q: is xsl going aw, Michael Kay | Thread | RE: [xsl] newbie Q: is xsl going a, Kucera, Rich |
Re: [xsl] Incrementing a Global var, Mukul Gandhi | Date | Re: [xsl] jaxp vs xalan, Mark R. Diggory |
Month |