xml-xalan-j-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Jenkins <adamjenkinstmpredir...@yahoo.com.au>
Subject XalanJ Future - Part 2
Date Thu, 10 Dec 2009 16:47:57 GMT
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

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 :)


See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/

View raw message