[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
Keywords