Nomination for new contributors & XSLTC Code Donation

[Sc...@lotus.com]

I and the contributors at Lotus have been talking to the Sun XSLTC team
(http://www.sun.com/software/xml/developers/xsltc/) for a while now about
merging the XSLTC code into Xalan, and forming a collaboration which is
bound to produce the best possible XSLT processor technology.  I am very
excited and enthusiastic about this contribution.  Building a real
community around Xalan composed of multiple company contributions is a
major goal for us, and this is a great step in that direction.

The basic plan is as follows:
1) The XSLTC folks initially drop the code into the
xml-xalan/java/src/org/apache/xalan directory in the CVS repository.
2) We modify build.xml to produce an xsltc.jar and a xalan.jar, and add the
xsltc documentation to the xalan.docs.  The docs will describe why you
would want to use one processor over another for a given purpose.
3) Modify our command line so that XSLTC execution becomes an option.
4) Probably do a release at this point.
5) Understanding of requirements is all important to the success of this
merge.  We should begin to rework the Xalan requirements at this point.
5) Bring XSLTC fully up to JAXP 1.1 support (I think it is currently still
dependent on Sun's ProjectX parser).
6) At this point begin to merge some infrastructure where it makes sense,
work through the issues, take it from there...

I don't want to predict too much how the architecture is going to evolve.
I believe strongly that at least the source tree structure (BTW, the DTM
work I have been doing is partly in anticipation of a shared source tree
model with XSLTC) and the serializers can be shared.  I suspect the
iteration and function execution may eventually be able to be shared, but
am not sure (I haven't actually seen their code yet).  Certainly the
extension mechanism can be shared.  Hopefully the parsing and validation of
both the XSLT and the XPath can be eventually shared.  On the other hand,
we want to keep the XSLTC concept as ultra-high performance, and the
existing Xalan concept as a heavy-duty feature rich for tooling and
diagnostics.  In other words, we can't hurt either of the processor
strengths through the merge.

A bit of preaching: Sincerity, honesty, trust is the base for any marriage.
As this collaboration takes place, each of us needs to listen, consider,
discuss, and resolve... work as a distributed team.  Even contention should
be enjoyable, as long as ego is removed.  This should be science, not art.
The bottom line is that we should all want to create the best possible XSLT
processor technology to fulfill the requirements of the users.

And so I nominate Tom Amiro (QA testing, tom.amiro@east.sun.com), Morten
Jorgensen (Lead Engineer, morten.jorgensen@Ireland.sun.com), and Todd
Miller (Programmer, todd.miller@east.sun.com) as committers to the Xalan
project.

I hope I can obtain hearty +1s from all contributors.

-scott

Re: Nomination for new contributors & XSLTC Code Donation

[Co...@eng.sun.com]

+1 :-)

Costin

On Fri, 13 Apr 2001 Scott_Boag@lotus.com wrote:

> I and the contributors at Lotus have been talking to the Sun XSLTC team
> (http://www.sun.com/software/xml/developers/xsltc/) for a while now about
> merging the XSLTC code into Xalan, and forming a collaboration which is
> bound to produce the best possible XSLT processor technology.  I am very
> excited and enthusiastic about this contribution.  Building a real
> community around Xalan composed of multiple company contributions is a
> major goal for us, and this is a great step in that direction.
> 
> The basic plan is as follows:
> 1) The XSLTC folks initially drop the code into the
> xml-xalan/java/src/org/apache/xalan directory in the CVS repository.
> 2) We modify build.xml to produce an xsltc.jar and a xalan.jar, and add the
> xsltc documentation to the xalan.docs.  The docs will describe why you
> would want to use one processor over another for a given purpose.
> 3) Modify our command line so that XSLTC execution becomes an option.
> 4) Probably do a release at this point.
> 5) Understanding of requirements is all important to the success of this
> merge.  We should begin to rework the Xalan requirements at this point.
> 5) Bring XSLTC fully up to JAXP 1.1 support (I think it is currently still
> dependent on Sun's ProjectX parser).
> 6) At this point begin to merge some infrastructure where it makes sense,
> work through the issues, take it from there...
> 
> I don't want to predict too much how the architecture is going to evolve.
> I believe strongly that at least the source tree structure (BTW, the DTM
> work I have been doing is partly in anticipation of a shared source tree
> model with XSLTC) and the serializers can be shared.  I suspect the
> iteration and function execution may eventually be able to be shared, but
> am not sure (I haven't actually seen their code yet).  Certainly the
> extension mechanism can be shared.  Hopefully the parsing and validation of
> both the XSLT and the XPath can be eventually shared.  On the other hand,
> we want to keep the XSLTC concept as ultra-high performance, and the
> existing Xalan concept as a heavy-duty feature rich for tooling and
> diagnostics.  In other words, we can't hurt either of the processor
> strengths through the merge.
> 
> A bit of preaching: Sincerity, honesty, trust is the base for any marriage.
> As this collaboration takes place, each of us needs to listen, consider,
> discuss, and resolve... work as a distributed team.  Even contention should
> be enjoyable, as long as ego is removed.  This should be science, not art.
> The bottom line is that we should all want to create the best possible XSLT
> processor technology to fulfill the requirements of the users.
> 
> And so I nominate Tom Amiro (QA testing, tom.amiro@east.sun.com), Morten
> Jorgensen (Lead Engineer, morten.jorgensen@Ireland.sun.com), and Todd
> Miller (Programmer, todd.miller@east.sun.com) as committers to the Xalan
> project.
> 
> I hope I can obtain hearty +1s from all contributors.
> 
> -scott
> 
> 
>