On Thu, 17 May 2001, Paulo Gaspar wrote:
> > .......
> > XSLT is not perfect - neither is HTTP or HTML or any other standard. But
> > because Apache and many other organizations are implementing and using it
> > - I think they'll be around for a while :-)
> >
> > Costin
>
> Costin,
>
> You are still missing the point (as I wrote in my previous post on this
> thread) of the big volume of jars XSLT use would add to Tomcat minimal
> distro for JSP compilation.
AFAIK tomcat4 already includes a xslt engine ( part of JAXP1.1 ), and I
thing 3.3 will have to update to JAXP1.1 also ( we're still using the old
JAXP1.0.1 ).
But there is a point I'm not missing - I do understand the concern
regarding the size of the code.
I would point again to XSLTC - I think there are many similarities. The
XSLT compiler itself is quite big ( i.e. the piece that converts a XSTL
sheet into a .class file - same as Jasper is converting JSPs ). But the
transformation itself ( the generated code ), including all the runtime,
is small enough to run on a palm pilot.
And that doesn't matter too much anyway - for a small-memory deployment
( like an appliance or a CD runner ) you shouldn't even include the JSP
generator, XSLT or javac. That's why we have JSPC - to pre-process the WAR
file and precompile it.
There is even more - for this case you'll probably want to use
EmbededTomcat instead of server.xml-based runner, and we can pre-process
web.xml too - so it may be possible to eliminate even the parser from the
runtime-only version of tomcat.
( many embedded devices are pre-processing the .class files before
deployment, some are even generating binary code - so generating .class
files wouldn't work anyway ).
> Also, maybe the impact of using XSLT is quite larger than you expect.
> Especially via the huge memory demands and respective side effects. I
> know that you know well about the impact of creating a zillion of
> objects in memory (as it happens in even the most minimal use of XSLT),
> so I am not going to detail on what those side effects are.
Did I mentioned XSTL is a standard - with quite a few implementations, a
lot of competition and smart people, etc ?
If you look at Tomcat3.0 you may conclude servlets are quite bad - zillion
of objects in memory, big overhead, etc. There is a huge difference
between a xslt implementation one year ago and one today.
The same way as tomcat3.3 ( or 4.0 ) will generate only few dozen objects
at run time ( ok, fewer in 3.3 :-), most XSTL engines are starting to
recycle most objects. Take a look at DTM work in xalan ( and xsltc ).
> What is worse, XSLT is usualy way too much trouble because so many
> things are so counter intuitive.
Well, HTML is counter intutive too ( <H1> instead of bigger font ? ) :-)
But many of the "counter intuitive" things ( like no side efects, or the
way they treat variables ) do have a good reason behind it. And I suppose
many will find things that are counter intuitive in java ( you can't
change a String ?).
> The trap is that the really simple stuff works as expected, but when
> you need something just a little bit more complicated, sudenly you bump
> into something that does not work as expected, and you spend the next
> few days trying to figure out what.
Yes, I know the feeling. But it's not something specific to XSLT, it
happens to most programmers in most languages.
> Jon is a... er... politness challenged person and is a bit too obcessed
Too bad for him. That's why filters were invented ( or the "delete" key ).
> I used XSLT a lot and I can tell you that is easy for Velocity to be a
> better alternative (and it is not my favourite one!) just because XSLT
> is such a poor template mechanism.
Sorry, but I doubt it.
> One year ago, I was in the XSLT-LIST, bought Michael Kay book (kind of
> a very essential XSLT bible) and I was thinking about writing everything
> I could in XSLT just as any other XSLT fanatic... until I found out that:
> - I was wasting way too much time with XSLT complexities (why do you
> think the XSLT-LIST has all that traffic? Do you know that list?);
> - The outcome was always slower and more resource intensive than I
> found natural (and that the alternatives, as I discovered later).
One year ago tomcat couldn't handle 50 requests per second.
Try again today.
> Notice that I was not born with this knowledge. I went trough a lot of
> trouble to learn this. Now, you can
> - Pay attention to what I say and chek it out;
> - Think that the W3C is always right (HAHAHAHAHA!);
> - Think that your intuition is always right, which is another way of
> saying that you were born knowing it all.
Well, I do pay attention to what you say - and my day job involves working
on xslt. I don't think W3C is always right ( XML Schema ? Soap ? ), but it
wasn't that right with HTML or HTTP either ( one request per connection ?)
And I wasn't born knowing it - I spent a lot of time looking around and
reading, and I have my own doubts.
> Sorry Costin for assuming that you do not have much experience with
> XSLT and its alternatives, but I just think you are too smart to keep
> defending it if you had that experience.
:-)
Costin
