You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Adam Jenkins <ad...@yahoo.com.au> on 2009/12/10 17:47:57 UTC
XalanJ Future - Part 2
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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XalanJ Future - Part 2
Posted by Adam Jenkins <ad...@yahoo.com.au>.
Hi Henry,
Thanks for the post. I'm currently doing a bunch of code diving to see how big the impact of implementing your requirements are going to be. The way Xalan does variable assignment is quite different to what I'm used to seeing in interpretter code, with all variables being preprocessed and assigned an index, which is then used to reference the variable. At this stage I need a greater understanding of the code to decide whether a branch is even possible, or whether a complete fork is necessary.
For example, the current variable management system makes it quite difficult (for me with my limited knowledge at least) to extend it in any meaningful way....I'm not just talking about the extensions that I wanted to make, but also things like custom variable resolvers, which is a common concept in other interpretter systems. I am pretty confident (again, more investigation being done this week and next week) that if I was to try to meet your requirements for the extension element functionality, my modifications to the variable handling code would be quite large, so probably wouldn't make it into trunk anyway because of regression testing requirements.
But again, still code diving to gain a full understanding of the impact of this and future changes. At the moment, I seem to be in a bit of a "damned if you do, damned if you don't" scenario, with a low impact change not robust enough to make it to trunk, and a robust change too high impact to make it into trunk. The more I look at it, the more a fork feels like the only option available.
So what I'm trying to figure out at the moment is how large my changes are going to be, and from that, how likely is it that any branch I were to create would ever make it back into trunk. Because if it turns out that, for example, the entire variable handling code need a rewrite (not something I want, I hate rewrites) then it's probably best if it spawns to be a seperate offering as the chance of that modification going back into trunk are probably tiny.
Anyway, I'll keep the list posted as things progress.
Cheers
Adam
--- On Tue, 5/1/10, Henry Zongaro <zo...@ca.ibm.com> wrote:
> From: Henry Zongaro <zo...@ca.ibm.com>
> Subject: Re: XalanJ Future - Part 2
> To: "Adam Jenkins" <ad...@yahoo.com.au>
> Cc: xalan-dev@xml.apache.org, xalan-j-users@xml.apache.org
> Received: Tuesday, 5 January, 2010, 3:54 AM
>
>
> Hi, Adam.
>
>
>
> Adam Jenkins
> <ad...@yahoo.com.au>
> wrote on 12/10/2009 11:47:57 AM:
>
> > And when I get back I'll be forking the XalanJ
> codebase over to
>
> > dev.java.net.
>
>
>
> I recently added a comment
> on your enhancement
> request [1] suggesting a way we might move forward - in
> particular, I wrote,
> "the right way forward might be to create a branch and
> add your contribution
> there. Then people can extract and build the code, play
> with it, make further
> contributions to address the concerns. After that, we could
> fold it back
> onto the main trunk. Let me know how you feel about that
> suggestion."
>
>
>
> I haven't seen a
> response to that proposal,
> and I haven't seen anything in dev.java.net to indicate
> that you'd forked
> the Xalan-J code, so I thought I'd ping you to get your
> thoughts.
>
>
>
> Thanks,
>
>
>
> Henry
>
> [1] http://tinyurl.com/yf9esym
>
> ------------------------------------------------------------------
>
> Henry Zongaro
>
> XML Transformation & Query Development
>
> IBM Canada Lab T/L 313-6044; Phone +1 905
> 413-6044
>
> mailto:zongaro@ca.ibm.com
>
>
__________________________________________________________________________________
See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/
Re: XalanJ Future - Part 2
Posted by Adam Jenkins <ad...@yahoo.com.au>.
Hi Henry,
Thanks for the post. I'm currently doing a bunch of code diving to see how big the impact of implementing your requirements are going to be. The way Xalan does variable assignment is quite different to what I'm used to seeing in interpretter code, with all variables being preprocessed and assigned an index, which is then used to reference the variable. At this stage I need a greater understanding of the code to decide whether a branch is even possible, or whether a complete fork is necessary.
For example, the current variable management system makes it quite difficult (for me with my limited knowledge at least) to extend it in any meaningful way....I'm not just talking about the extensions that I wanted to make, but also things like custom variable resolvers, which is a common concept in other interpretter systems. I am pretty confident (again, more investigation being done this week and next week) that if I was to try to meet your requirements for the extension element functionality, my modifications to the variable handling code would be quite large, so probably wouldn't make it into trunk anyway because of regression testing requirements.
But again, still code diving to gain a full understanding of the impact of this and future changes. At the moment, I seem to be in a bit of a "damned if you do, damned if you don't" scenario, with a low impact change not robust enough to make it to trunk, and a robust change too high impact to make it into trunk. The more I look at it, the more a fork feels like the only option available.
So what I'm trying to figure out at the moment is how large my changes are going to be, and from that, how likely is it that any branch I were to create would ever make it back into trunk. Because if it turns out that, for example, the entire variable handling code need a rewrite (not something I want, I hate rewrites) then it's probably best if it spawns to be a seperate offering as the chance of that modification going back into trunk are probably tiny.
Anyway, I'll keep the list posted as things progress.
Cheers
Adam
--- On Tue, 5/1/10, Henry Zongaro <zo...@ca.ibm.com> wrote:
> From: Henry Zongaro <zo...@ca.ibm.com>
> Subject: Re: XalanJ Future - Part 2
> To: "Adam Jenkins" <ad...@yahoo.com.au>
> Cc: xalan-dev@xml.apache.org, xalan-j-users@xml.apache.org
> Received: Tuesday, 5 January, 2010, 3:54 AM
>
>
> Hi, Adam.
>
>
>
> Adam Jenkins
> <ad...@yahoo.com.au>
> wrote on 12/10/2009 11:47:57 AM:
>
> > And when I get back I'll be forking the XalanJ
> codebase over to
>
> > dev.java.net.
>
>
>
> I recently added a comment
> on your enhancement
> request [1] suggesting a way we might move forward - in
> particular, I wrote,
> "the right way forward might be to create a branch and
> add your contribution
> there. Then people can extract and build the code, play
> with it, make further
> contributions to address the concerns. After that, we could
> fold it back
> onto the main trunk. Let me know how you feel about that
> suggestion."
>
>
>
> I haven't seen a
> response to that proposal,
> and I haven't seen anything in dev.java.net to indicate
> that you'd forked
> the Xalan-J code, so I thought I'd ping you to get your
> thoughts.
>
>
>
> Thanks,
>
>
>
> Henry
>
> [1] http://tinyurl.com/yf9esym
>
> ------------------------------------------------------------------
>
> Henry Zongaro
>
> XML Transformation & Query Development
>
> IBM Canada Lab T/L 313-6044; Phone +1 905
> 413-6044
>
> mailto:zongaro@ca.ibm.com
>
>
__________________________________________________________________________________
See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XalanJ Future - Part 2
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Adam.
Adam Jenkins <ad...@yahoo.com.au> wrote on 12/10/2009
11:47:57 AM:
> And when I get back I'll be forking the XalanJ codebase over to
> dev.java.net.
I recently added a comment on your enhancement request [1] suggesting a
way we might move forward - in particular, I wrote, "the right way forward
might be to create a branch and add your contribution there. Then people
can extract and build the code, play with it, make further contributions
to address the concerns. After that, we could fold it back onto the main
trunk. Let me know how you feel about that suggestion."
I haven't seen a response to that proposal, and I haven't seen anything in
dev.java.net to indicate that you'd forked the Xalan-J code, so I thought
I'd ping you to get your thoughts.
Thanks,
Henry
[1] http://tinyurl.com/yf9esym
------------------------------------------------------------------
Henry Zongaro
XML Transformation & Query Development
IBM Canada Lab T/L 313-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Re: XalanJ Future - Part 2
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Adam.
Adam Jenkins <ad...@yahoo.com.au> wrote on 12/10/2009
11:47:57 AM:
> And when I get back I'll be forking the XalanJ codebase over to
> dev.java.net.
I recently added a comment on your enhancement request [1] suggesting a
way we might move forward - in particular, I wrote, "the right way forward
might be to create a branch and add your contribution there. Then people
can extract and build the code, play with it, make further contributions
to address the concerns. After that, we could fold it back onto the main
trunk. Let me know how you feel about that suggestion."
I haven't seen a response to that proposal, and I haven't seen anything in
dev.java.net to indicate that you'd forked the Xalan-J code, so I thought
I'd ping you to get your thoughts.
Thanks,
Henry
[1] http://tinyurl.com/yf9esym
------------------------------------------------------------------
Henry Zongaro
XML Transformation & Query Development
IBM Canada Lab T/L 313-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com