Hi Again,
Some of you may remember that recently I noted that a lot of my clients,
students and colleagues were moving all their XSLT work to Saxon, and did not
have very nice things to say about Xalan. That led me to ponder the state of
XalanJ and ask the question, what is XalanJs future (see XalanJ Future and
XalanJ Future - Summary on this mailing list).
I must admit I have a bias here. I'm a set in my ways kinda guy, and I've been
doing this stuff (enterprise java) for longer than I can remember, so much so
now I spend most of my time teaching. I like Xalan, I've used it for most of
my career, and nothing against Saxon, Michael's a great guy and his project is
amazing, I still have a soft spot for Xalan.
Over the years, I've developed a rather large library of extension elements and
functions that I've used in contracting. They've been really useful for me and
my colleagues, and I though I might as well get round to open sourcing them. I
spoke to my current boss about it and she thought it was a great idea...she
would put some resources towards it, we could structure some courses around it,
and it might inject some life and interest back into Xalan which would give me
the warm and fuzzies. She also requested I extend my functions by adding one
or two more things I though useful, but had never been able to do because the
Xalan extension element framework didn't currently support it.
But, we didn't want to waste our energy if Xalan wasn't under active
development, so I asked the question, what is XalanJs future? Why are so many
people leaving it...should I rewrite my extension for Saxon?
The response I got was mixed, but if you look to XalanJ Summary, you'll see
most of it boiled down to too much work, not enough hands. So I thought, wow,
that's perfect...I can make some mods, get my library out there....hopefully
the renewed interest will bring in more hands...you know, how open source
works. I also posted that I would love to know the reason for the lack of
workers...I mean, Xalan is the premier (only?) fully open source XSLT framework
for Java, it seemed odd to me that there were was a committer problem.
Be careful what you wish for :) I now have a fair idea of the answer to that
question, which I'll post here, hopefully with a solution.
My experiences (negative by the way) with the Xalan team fall into 2
categories...."You can't do that in XSLT" and "What-If?"
1) "You can't do that in XSLT"
Over the years I've asked many questions on these lists, and if there's a
common theme in the responses, it would be "You can't do that in XSLT". Now,
when I say can't, I don't mean can't in the same way you can't ignore a checked
exception in java, but can't in the way "you can't use instanceof everywhere"
in java....not that it can't be done, it's just not great practice. It's
interesting, because it seems that XSLT is one of the only languages that I've
ever hit this with. Maybe it comes from the fact that a lot of people ask
silly questions about XSLT and do silly things when they're learning (I know I
sure did), that we develop a thick skin, and shoot down anything that differs
from the norm.
But here's the kicker...most innovation in life comes from people who push
systems beyond their current limitations...and if you tell those people that
they "can't" do something, they'll generally do it anyway...but somewhere else.
I recently asked for guidance on a way to return an XObject (getting Xalan
technical here) from an extension element, similar to how you do for extension
functions.
I was told I can't do that...it's a bad idea, just use extension functions,
don't rock the boat. If it's a bad idea, why allow it at all? Why allow it
from extension functions? It didn't make sense.
Now, I know, if some first year graduate came to you and said "how do you
return a variable from an extension element", my first response might be to
tell him he can't, or it's a bad idea (actually, I wouldn't say that at all,
but I can understand the motivation to). But when a seasoned professional asks
the same question quoting intricate details of both XSLT and Xalan internals,
you can pretty much bet he's weighed the pros and cons, and decided, in the
interest of innovation, he wants to give it a shot anyway, see what
happens...after all, we're just talking about 1s and 0s here, no ones going to
die...if ever an industry should be open to experimentation is should be ours,
perhaps more than all others because the cost of failure is so spectacularly
low.
Luckily, I have a thick skin, so I dove into the Xalan code, and discovered,
with a minor modification, you could quite easily do this...asked for
architectural guidance on how I might best structure my patch. Again, I got
some "just use functions" responses...which I ignored....but is pause for
though.
People learn from mistakes. People innovate from learning. How do we expect
to get better as a product, as an industry...hell, as a society, if we don't
embrace that which seems odd, or different, or beyond what we consider to be
the usual...especially when it comes from our seasoned professionals.
Anyway, I went ahead and coded it the way I though best (this is not my first
time at this dance, I've been around for a while and know what I'm doing) and
submitted the patch...which brings me to my next point...the "What-Ifs".
2) The "What-Ifs"
So, my patch (XalanJ-2510) is about 10 lines of code, surrounded in a big
optional IF statement to ensure backward compatibility and no impact to
existing functionality. I always expect a bit of back and forth when
submitting a patch...usually you get a committer says something like "have you
considered this, or that"...offers some solutions, points you in the direction
of some code you might want to use or look at, or perhaps have over
looked...generally helps you out because you made the effort to at least spend
your valuable time learning the code base and submitting a patch rather than
just raising an issue and posting a bunch of "are we there yet?" comments.
I wasn't, in my wildest dreams, prepared for the next 2 (probably more, haven't
printed it out) pages of back and forth that followed. Covering every possible
scenario from relevant, but very low probability techinical corner cases, right
up to the injection of malicious XSLT segments by no good hackers. Now, I'm
all one for thinking through a problem, and I know that some people are agile,
while other prefer BDUF...but we can all agree, at some point we have to cease
the mental masturbation and stroking of our own technical egos by seeing how
many scenarios we can dream up and just get on with the job.
So, where to from here? Well, any other project I'd just say "hell with this"
and go use a competitor....which I'm guessing is why I had to ask that initial
question about XalanJ future to begin with...that's what people are doing, en
mass. But here's the kicker....XSLT integration in java is the backbone of
business around the world...it's a staple of all java work, and is really
critically important to the future of Java. I do a lot of work in that area, I
do a lot of teaching in that area. It's just too darn important for me to walk
away from.
So, I'm going camping with a mate next week...a week 4x4-ing on Fraser Island,
can't wait...looking forward to it.
And when I get back I'll be forking the XalanJ codebase over to dev.java.net.
The new fork will be a fork of innovation, where ideas and contributions are
not just welcomed, but actively encouraged...where pushing XSLT beyond it's
current limitations will be applauded, not derided. Where you can happily try
and fail, and no matter how silly, or stupid, or odd the attempt, your courage
will be applauded, not judged.
Where performance will be analyzed and profiled, until people can't say "but
Saxon is way faster". Where XSLT 2.0 will be a priority. And a massive range
of extension functions and elements will be available to assist in complex
integration projects. Where any idea, no matter how crazy, will be presumed
innocent until proven guilty, not the other way around.
And where you won't here "You can't do that in XSLT".
I don't have the time for this, but this Xalan is stagnating. Through my own
extension work I've seen how powerful XSLT can be, way beyond it's current
level. It's too important for me not to make time.
It would be great to return from camping and see that this email had shaken
some trees, and got some changes to occur that made a fork no longer necessary,
but if there not, please read this as an invitation.
Anyone that wants to help will be welcomed with open brackets :)
Cheers
Adam
__________________________________________________________________________________
See what's on at the movies in your area. Find out now:
http://au.movies.yahoo.com/session-times/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
