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/11/10 20:34:26 UTC
Xalan J Future - Summary
Hi Everyone,
Thanks for getting back to me with a lot of information about Xalans future. From what I can gather from the various posts, here is my summary:
XSLT 2.0 was started, but never finished (it would be great to know why...was it too difficult with the Xalan architecture?).
XalanJ no longer has much of an active contribution base, most of the developers have gone off to do their own thing on other XML/XSLT projects (again, would be great to know why, is Xalan considered finished? or too defective to continue with?)
XalanJ is currently slower than Saxon in most situations, however, this is possibly just because there's no active work on optimization going on.
So I guess what I'm trying to figure out now is if Xalan is coming to EOL? I would really like to revive it, and I have some spare development band width to put towards it, however if heavy weights (IBM) are going to open source a competing library with a view to killing off Xalan I don't want to lose a bunch of weekends fighting a losing battle :) (I still don't understand why we end up with 2 or 3 versions of open source libraries that do exactly the same thing, it seems a waste of community effort to me, surely we're mature enough to get our sh&t together :) ).
Having spent quite a bit of time code diving through Xalan, I also think it's a pretty good product and pretty good code base...and i missing something?? Why did IBM start again from scratch??
Any thoughts would be appreciated? Is Xalan worth resurrecting and continueing on with?
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Xalan J Future
Posted by David Carver <d_...@yahoo.com>.
Just a suggestion that if you are going to look into XSLT 2, you might
want to look at using the PsychoPath XPath 2.0 processor for the XPath
2.0 support. It is fully schema aware, and is open source under an
Eclipse Public License.
The Xerces-J project is using it for their XPath 2.0 assertion support
for XML Schema 1.1.
http://wiki.eclipse.org/PsychoPathXPathProcessor/UserManual
Dave
Martin von Gagern wrote:
> Henry Zongaro wrote:
>
>> Coincidentally, I was just getting myself set up to spend some time
>> reviewing some of your patches as I'd promised. If those look good, I
>> wouldn't see any impediment to nominating you for committer status.
>>
>
> That's really good to hear!
>
>
>> One weakness of XSLTC is in its error checking. It's nowhere near as
>> thorough as the Xalan-J interpreter in that respect. That's something
>> that could be remedied by having them share their abstract syntax tree
>> representations - common classes with compile() and interpret() methods
>> as you suggest.
>>
>
> Maybe I'll start a code branch working towards that direction, once I
> have access to the svn repository...
>
> -- Martin
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Xalan J Future
Posted by Martin von Gagern <Ma...@gmx.net>.
Henry Zongaro wrote:
> Coincidentally, I was just getting myself set up to spend some time
> reviewing some of your patches as I'd promised. If those look good, I
> wouldn't see any impediment to nominating you for committer status.
That's really good to hear!
> One weakness of XSLTC is in its error checking. It's nowhere near as
> thorough as the Xalan-J interpreter in that respect. That's something
> that could be remedied by having them share their abstract syntax tree
> representations - common classes with compile() and interpret() methods
> as you suggest.
Maybe I'll start a code branch working towards that direction, once I
have access to the svn repository...
-- Martin
Re: Xalan J Future
Posted by Martin von Gagern <Ma...@gmx.net>.
keshlam@us.ibm.com wrote:
> I believe there is a sketch of a "document cursor" abstraction, called
> XDM, checked into the Xalan repository.
That sounds promising. Will have a look when I find the time.
-- Martin
Re: Xalan J Future
Posted by ke...@us.ibm.com.
> > If I were to write an xslt processor from scratch, I'd either drop DTM
> > altogether, or have the transformation work on some interface which
can
> > be provided from both DOM and DTM. I'd also try to get some closer
> > integration between the xslt interpreter and the xsltc compiler, i.e.
> > have a bunch of classes, each with methods compile() and interpret(),
so
> > people could more easily ensure they perform the same operations.
I believe there is a sketch of a "document cursor" abstraction, called
XDM, checked into the Xalan repository. Our plan had been to migrate Xalan
to running over XDM, making DTM strictly a back-end representation and
allowing an XDM that ran directly over the DOM rather than the current
kluge of wrapping DOMs in a partial DTM. This would also make plugging in
other data models easier, if you wanted to run across JDOM (ugh) or some
custom model used by a particular application.
I did some additional (unpublished) work on XDM before setting it aside,
so I can attest that the approach is viable. Retrofitting it into the
processor would not be a small task -- it's on the same order of magnitude
as the work we did rewriting XSLTC to share DTM with the interpreter --
but would certainly be doable.
The result would be a somewhat cleaner architecture.
Re: Xalan J Future
Posted by Martin von Gagern <Ma...@gmx.net>.
Hello Henry!
Henry Zongaro wrote:
> Coincidentally, I was just getting myself set up to spend some time
> reviewing some of your patches as I'd promised. If those look good, I
> wouldn't see any impediment to nominating you for committer status.
Have you found any time yet? You will keep those reviews in mind, right?
Greetings,
Martin
Re: Xalan J Future
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Martin.
Martin von Gagern <Ma...@gmx.net> wrote on 11/13/2009 11:42:07
AM:
> Adam Jenkins wrote:
> > I would really like to revive it
>
> Me, too.
>
> See http://thread.gmane.org/gmane.text.xml.xalan.devel/17653
> and http://thread.gmane.org/gmane.text.xml.xalan.devel/17705
> and maybe also https://code.launchpad.net/xalan
>
> > and I have some spare development band width to put towards it,
>
> I can't make any promises, but I'm willing to contribute some time as
> well. Already have, writing a bunch of patches.
>
> What has me worried is infrastructure. As long as we are not granted
> enough access to svn and jira, we won't be able to efficiently use
> Apache infrastructure. And as the people around here at least aren't
> giving such permissions to anyone dropping by, at least not on a short
> timescale, I assume that this will hinder development.
>
> So my idea is, we might consider moving this development elsewhere. One
> possibility would be launchpad, where I've already published an svn
> import as well as a branch with some fixes included. Another possibility
> might be openjdk, where a copy of xalan forms the basis of the xslt
> processor shipped with openjdk, using mercurial as the underlying
> revision control system. Or we might prod people around here a bit
> harder, to gain the access we require to contribute efficiently.
I'm sorry that I haven't been able to contribute to the project over the
past year. My other work really hasn't permitted me the time.
Coincidentally, I was just getting myself set up to spend some time
reviewing some of your patches as I'd promised. If those look good, I
wouldn't see any impediment to nominating you for committer status.
For whatever it's worth, I think it would be most beneficial for the
Xalan-J community if development of the processor continued within this
venue. This is the place people are used to going to for questions about
Xalan-J and XSLTC, and for help.
> If I were to write an xslt processor from scratch, I'd either drop DTM
> altogether, or have the transformation work on some interface which can
> be provided from both DOM and DTM. I'd also try to get some closer
> integration between the xslt interpreter and the xsltc compiler, i.e.
> have a bunch of classes, each with methods compile() and interpret(), so
> people could more easily ensure they perform the same operations.
Certainly that would be better architecturally. The current state of the
code reflects the fact that XSLTC and the Xalan-J interpreter were
initially developed independent of one another. Some Xalan committers
spent quite a lot of time getting them to share more functionally
equivalent components.
At one point, XSLTC had its own independent implementation of the XPath
data model that was similar to DTM. We spent quite a bit of time adapting
it to share DTM with the interpreter. It also had its own independent
serializer implementation. We spent a lot of time merging those
implementations. Overall, I think those changes benefited both
processors, in that bugs found by a user of one processor could be fixed
for both; performance improvements in DTM or serialization that were
targeted to XSLTC could benefit both processors.
One weakness of XSLTC is in its error checking. It's nowhere near as
thorough as the Xalan-J interpreter in that respect. That's something
that could be remedied by having them share their abstract syntax tree
representations - common classes with compile() and interpret() methods as
you suggest.
One other thought - keeping Xalan-J development here, there's a greater
potential for cross-pollination of ideas with Xalan-C. For example, if I
recall correctly, Xalan-C does its interpretation of a stylesheet in an
iterative fashion rather than a recursive fashion. That allows it to
process stylesheets that have a much deeper recursive run-time stack than
the Xalan-J interpreter. Keeping Xalan-J here makes it easier to share
those kinds of ideas.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro
XML Transformation & Query Development
IBM Canada Lab T/L 313-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Re: Xalan J Future
Posted by Martin von Gagern <Ma...@gmx.net>.
Hi Adam,
Adam Jenkins wrote:
> I would really like to revive it
Me, too.
See http://thread.gmane.org/gmane.text.xml.xalan.devel/17653
and http://thread.gmane.org/gmane.text.xml.xalan.devel/17705
and maybe also https://code.launchpad.net/xalan
> and I have some spare development band width to put towards it,
I can't make any promises, but I'm willing to contribute some time as
well. Already have, writing a bunch of patches.
What has me worried is infrastructure. As long as we are not granted
enough access to svn and jira, we won't be able to efficiently use
Apache infrastructure. And as the people around here at least aren't
giving such permissions to anyone dropping by, at least not on a short
timescale, I assume that this will hinder development.
So my idea is, we might consider moving this development elsewhere. One
possibility would be launchpad, where I've already published an svn
import as well as a branch with some fixes included. Another possibility
might be openjdk, where a copy of xalan forms the basis of the xslt
processor shipped with openjdk, using mercurial as the underlying
revision control system. Or we might prod people around here a bit
harder, to gain the access we require to contribute efficiently.
> Having spent quite a bit of time code diving through Xalan, I also
> think it's a pretty good product and pretty good code base...and i
> missing something??
My impression is that the whole DTM thing has quite a number of
drawbacks. It doesn't interact nicely with garbage collection, imposes
pretty tight restrictions on the number of documents and nodes that can
be processed, and also imposes some limitations on the interaction with
DOM-based extension functions, e.g. with respect to the context of
returned DOM nodes, their parents in particular.
If I were to write an xslt processor from scratch, I'd either drop DTM
altogether, or have the transformation work on some interface which can
be provided from both DOM and DTM. I'd also try to get some closer
integration between the xslt interpreter and the xsltc compiler, i.e.
have a bunch of classes, each with methods compile() and interpret(), so
people could more easily ensure they perform the same operations.
But on the whole, I believe Xalan is quite a good basis, so I'd rather
improve on it than start from scratch.
> Is Xalan worth resurrecting and continueing on with?
I'd say yes. I hope it can be done.
Greetings,
Martin von Gagern