[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: Tue, 26 Aug 2003 10:23:51 -0400

[resend/edit due to garbling]

WP Wrote:
>
> 
> Why are vendors hopeful that it'll go away, or why do they 
> believe we would 
> welcome its disappearance?
> 

Not sure.  I think they know we like it and that bothers 
them (having invested a lot 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 it can't.  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 forget the tag libraries with their cost and
brittleness. It's the slingshot effect of bottom-up understanding where you
have this release of tension seeing that xslt had already been done :-)

> 
> 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 comment directives 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.   

No worries,  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(it's not markup, I know
there is a tag version of xquery,  but I don't know how interested people
are in using it).   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(unless I'm missing
something).   I don't really understand the perception that there is a
reluctance among programmers to do learn declarative/push/walking and power
markup(all tags).

Thanks,
-Rich


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread
Keywords