You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Jacek R. Ambroziak" <ja...@yahoo.com> on 2002/03/06 19:17:08 UTC
experimental XSLTC-2, a clarification
Dear XSLTC users,
I owe you clarification about the status of
my XSLTC version, binaries of which are served
from my website www.ambrosoft.com.
The version is derived from Apache/Xalan/XSLTC 2.3.1
which in turn is derived from my final project
at Sun Microsystems.
I have returned to this topic because I myself need
XSLTC for my commercial work; the direct trigger was
an email from Stefano Mazzocchi on lack of benchmarking
data and bugs prohibiting him from the unrestricted use
of this promising technology in Cocoon.
I started to work on XSLTC again after a long break
thinking that perhaps it was a matter of fixing a few
outstanding bugs and everything will be fine.
After many long days of intensive effort I realized
that the code is in fact quite far from fully
realizing the potential of the original vision.
This is my personal opinion. I am not going to discuss
details here, but improvement opportunities are numerous
and I am implementing them.
My current version represents an uncompromising overhaul
of the code base and is no longer implementation compatible
with Xalan/XSLTC (although it is API compatible).
Therefore at this point I cannot CVS-commit nor -update
as doing so would mess up the Apache and/or my versions.
I am calling my version "experimental" because I indeed
experiment freely with any, however far-reaching, changes
I feel are beneficial to the technology. I am addressing
performance and architectural issues with a fresh perspective.
Maybe my long break was not such a bad thing after all :-)
This level of free experimenting would not be possible
in the context of the Xalan community effort,
neither would it be a good thing: it would be destabilizing.
Naturally, I wouldn't be investing energy into
reenginering XSLTC if I didn't believe a worthwhile outcome
would result.
I will continue to post information about XSLTC-2
at my website, but I strongly feel it inaproppriate to
continue discussing it at this forum. That's why I had asked
people interested in progress/use of XSLTC-2
to contact me directly.
I am sorry if this explanation disappoints some of you
but I hope my results will end up being useful
to XML/Java users.
--Jacek
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: experimental XSLTC-2, a clarification
Posted by Stefano Mazzocchi <st...@apache.org>.
"Jacek R. Ambroziak" wrote:
>
> Dear XSLTC users,
>
> I owe you clarification about the status of
> my XSLTC version, binaries of which are served
> from my website www.ambrosoft.com.
> The version is derived from Apache/Xalan/XSLTC 2.3.1
> which in turn is derived from my final project
> at Sun Microsystems.
>
> I have returned to this topic because I myself need
> XSLTC for my commercial work; the direct trigger was
> an email from Stefano Mazzocchi on lack of benchmarking
> data and bugs prohibiting him from the unrestricted use
> of this promising technology in Cocoon.
>
> I started to work on XSLTC again after a long break
> thinking that perhaps it was a matter of fixing a few
> outstanding bugs and everything will be fine.
> After many long days of intensive effort I realized
> that the code is in fact quite far from fully
> realizing the potential of the original vision.
> This is my personal opinion. I am not going to discuss
> details here, but improvement opportunities are numerous
> and I am implementing them.
>
> My current version represents an uncompromising overhaul
> of the code base and is no longer implementation compatible
> with Xalan/XSLTC (although it is API compatible).
> Therefore at this point I cannot CVS-commit nor -update
> as doing so would mess up the Apache and/or my versions.
>
> I am calling my version "experimental" because I indeed
> experiment freely with any, however far-reaching, changes
> I feel are beneficial to the technology. I am addressing
> performance and architectural issues with a fresh perspective.
> Maybe my long break was not such a bad thing after all :-)
>
> This level of free experimenting would not be possible
> in the context of the Xalan community effort,
> neither would it be a good thing: it would be destabilizing.
>
> Naturally, I wouldn't be investing energy into
> reenginering XSLTC if I didn't believe a worthwhile outcome
> would result.
>
> I will continue to post information about XSLTC-2
> at my website, but I strongly feel it inaproppriate to
> continue discussing it at this forum. That's why I had asked
> people interested in progress/use of XSLTC-2
> to contact me directly.
>
> I am sorry if this explanation disappoints some of you
> but I hope my results will end up being useful
> to XML/Java users.
Jacek,
being relatively new to Apache, you might not be aware of the 'rules for
revolutionaries' (these are not stated explicitly on any apache web site
because there is not much need for such a thing... but the PMC should
greatly considering adopting them)
http://www.x180.net/Mutterings/OpenSource/RulesForRevEmail.html
They were written and proposed by James Duncan Davidson, former Sun's
leader for open source ventures, original author of Ant and Tomcat, ASF
member and part of the Jakarta founders.
In short they state:
1) any Apache committer has the right to propose the creation of an
'internal fork', stating a codename for it.
2) if the above is done, the community automatically grantes a location
in the project CVS, normally under /proposal/[codename]
3) the 'internally forking' committer has the right, at any time, to
call for a 'take-over' vote on the dev community: if passed with a
majority of pending votes, the internal fork becomes the new codebase.
This has been adopted in the past several times:
1) JServ 0.9.11 vs. JServ 1.0b (proponent myself! yes, JServ was
created out of an internal fork and the community voted to take it over
the old one!)
2) Tomcat 3.x vs. Tomcat 4.0 (proponent Craig McClanahan, codename
Catalina, result: not yet clear even if the community voted in favor of
Catalina)
3) Ant 1.x vs. Ant 2.x (proponent Peter Donald, codename ??, no vote
placed yet... there are several proposals, actually)
4) Cocoon 1.x vs. Cocoon 2.x (proponent myself, codename Cocoon2
(sometimes called C2), result: 2.x took over 1.x)
5) Xalan 1.x vs. Xalan 2.x (proponent Scott Boag, codename Xalan2,
result: 2.x took over 1.x)
6) Xerces 1.x vs. Xerces 2.x (proponent Andy Clark, codename Xerces2,
result: no clear result, currently in a transition period, but 2.x will
clearly take over 1.x)
and, last but not least,
7) Apache 1.3.xx vs. Apache 2.0.x (proponent many, codename Apache
two-'o', result: transition period, but 2.x will clearly take over 1.x)
The trend is clear: Apache has been dealing with internal forks in the
past so you're definately wrong stating that there is no space here for
your development and there is no support for your effort.
In case you need any help bootstrapping this effort of yours, I'll be
very happy to give you a hand.
Ah, for the proposal codename, I think Gregor would be really cool :)
Tom,
regarding
> It does not seem ethical or even legal to take open
> source software -- even if you were the original
> architect -- and use it for your own purposes.
As for legality, you are wrong in this respect: the Xalan license
doesn't say anything about any restriction of use of the 'XSLTC' term,
not even on the restriction of 'forking' the project (actually, I would
not use a license which stops people from forking my code: it keeps me
honest and them loyal!)
As for ethic: everyone of us uses software for our own purposes. There's
nothing wrong in that. The balance of open development comes from the
fact that being selfish *is* also being altruistic, that is: I make my
software open so that others contribute and help me out. I loose money,
but I gain a huge development power.... in fact, a development power
which would be far more expensive than the money I loose. This is why
the model, if understood and applied correctly, works.
This is exactly the reason why I'd like Jacek to do its internal fork
within the Xalan community: we cocoon devs are not happy with Xalan-j
performance-wise and we are not happy with XSLTC compliance-wise. Jacek
wants to bring the two together and we will support him as much as we
can.
But if he chooses to fork the project externally, we'll be forced to
fork it back into apache because otherwise, we fear of powerful code
that lacks a community around it (see JClark's XT, for a great example)
[hoping that Jacek keep the source of his changes open, which is not
automatic since the ASF isn't viral in that respect]
Hope this helps both of you to gain better knowledge of the Apache
processes.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: experimental XSLTC-2, a clarification
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
The future, as it has always been the case, is unknown :-) and wide open
Right now I concentrate on getting XSLTC back on track.
--Jacek
On Thursday 07 March 2002 07:27 am, Stuart Roebuck wrote:
> Do I take it that this means that the discussed improvements to XSLTC
> are no longer Apache license compatible and cannot therefore be relied
> upon to be something that can be integrated into Cocoon in the future?
>
> If so, it looks like, given the speed benefits, we need to encourage
> participation in another attempt at the same thing.
>
> Stuart.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: experimental XSLTC-2, a clarification
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
The future, as it has always been the case, is unknown :-) and wide open
Right now I concentrate on getting XSLTC back on track.
--Jacek
On Thursday 07 March 2002 07:27 am, Stuart Roebuck wrote:
> Do I take it that this means that the discussed improvements to XSLTC
> are no longer Apache license compatible and cannot therefore be relied
> upon to be something that can be integrated into Cocoon in the future?
>
> If so, it looks like, given the speed benefits, we need to encourage
> participation in another attempt at the same thing.
>
> Stuart.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: experimental XSLTC-2, a clarification
Posted by Stuart Roebuck <st...@adolos.co.uk>.
Do I take it that this means that the discussed improvements to XSLTC
are no longer Apache license compatible and cannot therefore be relied
upon to be something that can be integrated into Cocoon in the future?
If so, it looks like, given the speed benefits, we need to encourage
participation in another attempt at the same thing.
Stuart.
On Wednesday, March 6, 2002, at 10:01 pm, Jacek R. Ambroziak wrote:
> On Wednesday 06 March 2002 04:23 pm, Tom Amiro wrote:
>
>> It does not seem ethical or even legal to take open
>> source software -- even if you were the original
>> architect -- and use it for your own purposes.
>
> Strong words Tom.
>
> This case has nothing to do with my being
> the original XSLTC inventor and developer.
> Everybody uses this software as all othe Apache Software
> "for their own purposes" commercial or otherwise
> and there is nothing illegal or unethical about that.
> At this point I am just another user who rather urgently
> needs a version that works as desired.
>
> I was perfectly aware that my explanation
> would be disappointing to some people.
>
> --Jacek
>
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
Re: experimental XSLTC-2, a clarification
Posted by Stuart Roebuck <st...@adolos.co.uk>.
Do I take it that this means that the discussed improvements to XSLTC
are no longer Apache license compatible and cannot therefore be relied
upon to be something that can be integrated into Cocoon in the future?
If so, it looks like, given the speed benefits, we need to encourage
participation in another attempt at the same thing.
Stuart.
On Wednesday, March 6, 2002, at 10:01 pm, Jacek R. Ambroziak wrote:
> On Wednesday 06 March 2002 04:23 pm, Tom Amiro wrote:
>
>> It does not seem ethical or even legal to take open
>> source software -- even if you were the original
>> architect -- and use it for your own purposes.
>
> Strong words Tom.
>
> This case has nothing to do with my being
> the original XSLTC inventor and developer.
> Everybody uses this software as all othe Apache Software
> "for their own purposes" commercial or otherwise
> and there is nothing illegal or unethical about that.
> At this point I am just another user who rather urgently
> needs a version that works as desired.
>
> I was perfectly aware that my explanation
> would be disappointing to some people.
>
> --Jacek
>
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: experimental XSLTC-2, a clarification
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
On Wednesday 06 March 2002 04:23 pm, Tom Amiro wrote:
> It does not seem ethical or even legal to take open
> source software -- even if you were the original
> architect -- and use it for your own purposes.
Strong words Tom.
This case has nothing to do with my being
the original XSLTC inventor and developer.
Everybody uses this software as all othe Apache Software
"for their own purposes" commercial or otherwise
and there is nothing illegal or unethical about that.
At this point I am just another user who rather urgently
needs a version that works as desired.
I was perfectly aware that my explanation
would be disappointing to some people.
--Jacek
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: experimental XSLTC-2, a clarification
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
On Wednesday 06 March 2002 04:23 pm, Tom Amiro wrote:
> It does not seem ethical or even legal to take open
> source software -- even if you were the original
> architect -- and use it for your own purposes.
Strong words Tom.
This case has nothing to do with my being
the original XSLTC inventor and developer.
Everybody uses this software as all othe Apache Software
"for their own purposes" commercial or otherwise
and there is nothing illegal or unethical about that.
At this point I am just another user who rather urgently
needs a version that works as desired.
I was perfectly aware that my explanation
would be disappointing to some people.
--Jacek
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
RE: experimental XSLTC-2, a clarification
Posted by Steven Noels <st...@outerthought.org>.
Tom Amiro wrote:
> Jacek,
>
> I am very disappointed to hear this. You were
> the originator, but a lot of work has been done
> by others on XSLTC since you moved on.
>
> It does not seem ethical or even legal to take open
> source software -- even if you were the original
> architect -- and use it for your own purposes.
just nitpicking: it is legal - that's what the entire Apache license vs.
GPL is about
see the interesting thread on jakarta-general:
http://marc.theaimsgroup.com/?t=101532678600005&r=1&w=2
other than that, from a user's perspective, I really would like to see
XSLTC2 become a branch of Xalan, too
after all, it was the Apache spirit (scratching an itch) that motivated
some Cocoon developers to start bugging Jacek to step into the arena
again
I'm pretty sure putting XSLTC2 in broad daylight will serve Jacek's
business purposes, too, as my involvement in Apache projects does for my
little business
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: experimental XSLTC-2, a clarification
Posted by Tom Amiro <To...@Sun.COM>.
Jacek,
I am very disappointed to hear this. You were
the originator, but a lot of work has been done
by others on XSLTC since you moved on.
It does not seem ethical or even legal to take open
source software -- even if you were the original
architect -- and use it for your own purposes.
You are correct that this alias is not the proper
forum for your one-man XSLTC-2 project. Neither
should you use this alias to garner information
on bug fixes offered in the spirit of sharing.
I seriously hope you reconsider and find a way
to work within the XalanJ2 project. As others have
suggested, using a branch would give you the freedom
do your grand scale experimental work. Otherwise,
I fear you will you will alienate yourself in the
XML/XSLT community.
Tom
"Jacek R. Ambroziak" wrote:
>
> Dear XSLTC users,
>
> I owe you clarification about the status of
> my XSLTC version, binaries of which are served
> from my website www.ambrosoft.com.
> The version is derived from Apache/Xalan/XSLTC 2.3.1
> which in turn is derived from my final project
> at Sun Microsystems.
>
> I have returned to this topic because I myself need
> XSLTC for my commercial work; the direct trigger was
> an email from Stefano Mazzocchi on lack of benchmarking
> data and bugs prohibiting him from the unrestricted use
> of this promising technology in Cocoon.
>
> I started to work on XSLTC again after a long break
> thinking that perhaps it was a matter of fixing a few
> outstanding bugs and everything will be fine.
> After many long days of intensive effort I realized
> that the code is in fact quite far from fully
> realizing the potential of the original vision.
> This is my personal opinion. I am not going to discuss
> details here, but improvement opportunities are numerous
> and I am implementing them.
>
> My current version represents an uncompromising overhaul
> of the code base and is no longer implementation compatible
> with Xalan/XSLTC (although it is API compatible).
> Therefore at this point I cannot CVS-commit nor -update
> as doing so would mess up the Apache and/or my versions.
>
> I am calling my version "experimental" because I indeed
> experiment freely with any, however far-reaching, changes
> I feel are beneficial to the technology. I am addressing
> performance and architectural issues with a fresh perspective.
> Maybe my long break was not such a bad thing after all :-)
>
> This level of free experimenting would not be possible
> in the context of the Xalan community effort,
> neither would it be a good thing: it would be destabilizing.
>
> Naturally, I wouldn't be investing energy into
> reenginering XSLTC if I didn't believe a worthwhile outcome
> would result.
>
> I will continue to post information about XSLTC-2
> at my website, but I strongly feel it inaproppriate to
> continue discussing it at this forum. That's why I had asked
> people interested in progress/use of XSLTC-2
> to contact me directly.
>
> I am sorry if this explanation disappoints some of you
> but I hope my results will end up being useful
> to XML/Java users.
>
> --Jacek
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
--
Tom Amiro -- SQA Engineer
Sun XML Technology Development
voice: 781-442-0589 Fax: 781-442-1437
eMail: tom.amiro@.sun.com
Re: experimental XSLTC-2, a clarification
Posted by Stefano Mazzocchi <st...@apache.org>.
"Jacek R. Ambroziak" wrote:
>
> Dear XSLTC users,
>
> I owe you clarification about the status of
> my XSLTC version, binaries of which are served
> from my website www.ambrosoft.com.
> The version is derived from Apache/Xalan/XSLTC 2.3.1
> which in turn is derived from my final project
> at Sun Microsystems.
>
> I have returned to this topic because I myself need
> XSLTC for my commercial work; the direct trigger was
> an email from Stefano Mazzocchi on lack of benchmarking
> data and bugs prohibiting him from the unrestricted use
> of this promising technology in Cocoon.
>
> I started to work on XSLTC again after a long break
> thinking that perhaps it was a matter of fixing a few
> outstanding bugs and everything will be fine.
> After many long days of intensive effort I realized
> that the code is in fact quite far from fully
> realizing the potential of the original vision.
> This is my personal opinion. I am not going to discuss
> details here, but improvement opportunities are numerous
> and I am implementing them.
>
> My current version represents an uncompromising overhaul
> of the code base and is no longer implementation compatible
> with Xalan/XSLTC (although it is API compatible).
> Therefore at this point I cannot CVS-commit nor -update
> as doing so would mess up the Apache and/or my versions.
>
> I am calling my version "experimental" because I indeed
> experiment freely with any, however far-reaching, changes
> I feel are beneficial to the technology. I am addressing
> performance and architectural issues with a fresh perspective.
> Maybe my long break was not such a bad thing after all :-)
>
> This level of free experimenting would not be possible
> in the context of the Xalan community effort,
> neither would it be a good thing: it would be destabilizing.
>
> Naturally, I wouldn't be investing energy into
> reenginering XSLTC if I didn't believe a worthwhile outcome
> would result.
>
> I will continue to post information about XSLTC-2
> at my website, but I strongly feel it inaproppriate to
> continue discussing it at this forum. That's why I had asked
> people interested in progress/use of XSLTC-2
> to contact me directly.
>
> I am sorry if this explanation disappoints some of you
> but I hope my results will end up being useful
> to XML/Java users.
Jacek,
being relatively new to Apache, you might not be aware of the 'rules for
revolutionaries' (these are not stated explicitly on any apache web site
because there is not much need for such a thing... but the PMC should
greatly considering adopting them)
http://www.x180.net/Mutterings/OpenSource/RulesForRevEmail.html
They were written and proposed by James Duncan Davidson, former Sun's
leader for open source ventures, original author of Ant and Tomcat, ASF
member and part of the Jakarta founders.
In short they state:
1) any Apache committer has the right to propose the creation of an
'internal fork', stating a codename for it.
2) if the above is done, the community automatically grantes a location
in the project CVS, normally under /proposal/[codename]
3) the 'internally forking' committer has the right, at any time, to
call for a 'take-over' vote on the dev community: if passed with a
majority of pending votes, the internal fork becomes the new codebase.
This has been adopted in the past several times:
1) JServ 0.9.11 vs. JServ 1.0b (proponent myself! yes, JServ was
created out of an internal fork and the community voted to take it over
the old one!)
2) Tomcat 3.x vs. Tomcat 4.0 (proponent Craig McClanahan, codename
Catalina, result: not yet clear even if the community voted in favor of
Catalina)
3) Ant 1.x vs. Ant 2.x (proponent Peter Donald, codename ??, no vote
placed yet... there are several proposals, actually)
4) Cocoon 1.x vs. Cocoon 2.x (proponent myself, codename Cocoon2
(sometimes called C2), result: 2.x took over 1.x)
5) Xalan 1.x vs. Xalan 2.x (proponent Scott Boag, codename Xalan2,
result: 2.x took over 1.x)
6) Xerces 1.x vs. Xerces 2.x (proponent Andy Clark, codename Xerces2,
result: no clear result, currently in a transition period, but 2.x will
clearly take over 1.x)
and, last but not least,
7) Apache 1.3.xx vs. Apache 2.0.x (proponent many, codename Apache
two-'o', result: transition period, but 2.x will clearly take over 1.x)
The trend is clear: Apache has been dealing with internal forks in the
past so you're definately wrong stating that there is no space here for
your development and there is no support for your effort.
In case you need any help bootstrapping this effort of yours, I'll be
very happy to give you a hand.
Ah, for the proposal codename, I think Gregor would be really cool :)
Tom,
regarding
> It does not seem ethical or even legal to take open
> source software -- even if you were the original
> architect -- and use it for your own purposes.
As for legality, you are wrong in this respect: the Xalan license
doesn't say anything about any restriction of use of the 'XSLTC' term,
not even on the restriction of 'forking' the project (actually, I would
not use a license which stops people from forking my code: it keeps me
honest and them loyal!)
As for ethic: everyone of us uses software for our own purposes. There's
nothing wrong in that. The balance of open development comes from the
fact that being selfish *is* also being altruistic, that is: I make my
software open so that others contribute and help me out. I loose money,
but I gain a huge development power.... in fact, a development power
which would be far more expensive than the money I loose. This is why
the model, if understood and applied correctly, works.
This is exactly the reason why I'd like Jacek to do its internal fork
within the Xalan community: we cocoon devs are not happy with Xalan-j
performance-wise and we are not happy with XSLTC compliance-wise. Jacek
wants to bring the two together and we will support him as much as we
can.
But if he chooses to fork the project externally, we'll be forced to
fork it back into apache because otherwise, we fear of powerful code
that lacks a community around it (see JClark's XT, for a great example)
[hoping that Jacek keep the source of his changes open, which is not
automatic since the ASF isn't viral in that respect]
Hope this helps both of you to gain better knowledge of the Apache
processes.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: experimental XSLTC-2, a clarification
Posted by Tom Amiro <To...@Sun.COM>.
Jacek,
I am very disappointed to hear this. You were
the originator, but a lot of work has been done
by others on XSLTC since you moved on.
It does not seem ethical or even legal to take open
source software -- even if you were the original
architect -- and use it for your own purposes.
You are correct that this alias is not the proper
forum for your one-man XSLTC-2 project. Neither
should you use this alias to garner information
on bug fixes offered in the spirit of sharing.
I seriously hope you reconsider and find a way
to work within the XalanJ2 project. As others have
suggested, using a branch would give you the freedom
do your grand scale experimental work. Otherwise,
I fear you will you will alienate yourself in the
XML/XSLT community.
Tom
"Jacek R. Ambroziak" wrote:
>
> Dear XSLTC users,
>
> I owe you clarification about the status of
> my XSLTC version, binaries of which are served
> from my website www.ambrosoft.com.
> The version is derived from Apache/Xalan/XSLTC 2.3.1
> which in turn is derived from my final project
> at Sun Microsystems.
>
> I have returned to this topic because I myself need
> XSLTC for my commercial work; the direct trigger was
> an email from Stefano Mazzocchi on lack of benchmarking
> data and bugs prohibiting him from the unrestricted use
> of this promising technology in Cocoon.
>
> I started to work on XSLTC again after a long break
> thinking that perhaps it was a matter of fixing a few
> outstanding bugs and everything will be fine.
> After many long days of intensive effort I realized
> that the code is in fact quite far from fully
> realizing the potential of the original vision.
> This is my personal opinion. I am not going to discuss
> details here, but improvement opportunities are numerous
> and I am implementing them.
>
> My current version represents an uncompromising overhaul
> of the code base and is no longer implementation compatible
> with Xalan/XSLTC (although it is API compatible).
> Therefore at this point I cannot CVS-commit nor -update
> as doing so would mess up the Apache and/or my versions.
>
> I am calling my version "experimental" because I indeed
> experiment freely with any, however far-reaching, changes
> I feel are beneficial to the technology. I am addressing
> performance and architectural issues with a fresh perspective.
> Maybe my long break was not such a bad thing after all :-)
>
> This level of free experimenting would not be possible
> in the context of the Xalan community effort,
> neither would it be a good thing: it would be destabilizing.
>
> Naturally, I wouldn't be investing energy into
> reenginering XSLTC if I didn't believe a worthwhile outcome
> would result.
>
> I will continue to post information about XSLTC-2
> at my website, but I strongly feel it inaproppriate to
> continue discussing it at this forum. That's why I had asked
> people interested in progress/use of XSLTC-2
> to contact me directly.
>
> I am sorry if this explanation disappoints some of you
> but I hope my results will end up being useful
> to XML/Java users.
>
> --Jacek
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
--
Tom Amiro -- SQA Engineer
Sun XML Technology Development
voice: 781-442-0589 Fax: 781-442-1437
eMail: tom.amiro@.sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: experimental XSLTC-2, a clarification
Posted by Gunnlaugur Thor Briem <gt...@dimon.is>.
Hi Jacek,
it sounds like what you are doing is a branch
of the XSLTC codebase.
If the changes you are making are that radical,
they should really, *really* be done as a CVS
branch in the xml.apache.org CVS server. This
has no destabilizing effects on the Xalan
baseline. Only when the code on the branch is
stable and shows marked improvements will it
be merged onto the trunk. Meanwhile, changes
occurring on the trunk that are appropriate
to the branched code as well can be merged as
you go along, to ease the final merge onto
the trunk. This is easy, does not compromize
stability, allows others to easily work with
you on the experimental XSLTC changes, and
promotes easier future use of those changes
in the baseline XSLTC product (pr
The alternative, which is effectively what
you are doing now, is to spawn a new
(presumably open-source) project out of
the XSLTC codebase. Obvious flaws in that
approach:
- it fragments the development effort
- it doubles the open-source infrastructure
(assuming you will allow others to make
changes in your forked project) which is
unneeded effort -- there is an established,
secure CVS server already running, a bug
database and all that -- why not use it? :)
- the longer this goes on, the harder it is
to eventually merge the two versions ...
if the two branches aren't in the same
CVS, they will grow apart.
So for the benefit of XSLTC, I strongly
urge you to reconsider! :)
Cheers,
- Gulli
> -----Original Message-----
> From: Jacek R. Ambroziak [mailto:jacek_ambroziak@yahoo.com]
> Sent: 6. mars 2002 18:17
> To: xalan-dev@xml.apache.org; cocoon-dev@xml.apache.org
> Cc: jra@ambrosoft.com
> Subject: experimental XSLTC-2, a clarification
>
>
> Dear XSLTC users,
>
> I owe you clarification about the status of
> my XSLTC version, binaries of which are served
> from my website www.ambrosoft.com.
> The version is derived from Apache/Xalan/XSLTC 2.3.1
> which in turn is derived from my final project
> at Sun Microsystems.
>
> I have returned to this topic because I myself need
> XSLTC for my commercial work; the direct trigger was
> an email from Stefano Mazzocchi on lack of benchmarking
> data and bugs prohibiting him from the unrestricted use
> of this promising technology in Cocoon.
>
> I started to work on XSLTC again after a long break
> thinking that perhaps it was a matter of fixing a few
> outstanding bugs and everything will be fine.
> After many long days of intensive effort I realized
> that the code is in fact quite far from fully
> realizing the potential of the original vision.
> This is my personal opinion. I am not going to discuss
> details here, but improvement opportunities are numerous
> and I am implementing them.
>
> My current version represents an uncompromising overhaul
> of the code base and is no longer implementation compatible
> with Xalan/XSLTC (although it is API compatible).
> Therefore at this point I cannot CVS-commit nor -update
> as doing so would mess up the Apache and/or my versions.
>
> I am calling my version "experimental" because I indeed
> experiment freely with any, however far-reaching, changes
> I feel are beneficial to the technology. I am addressing
> performance and architectural issues with a fresh perspective.
> Maybe my long break was not such a bad thing after all :-)
>
> This level of free experimenting would not be possible
> in the context of the Xalan community effort,
> neither would it be a good thing: it would be destabilizing.
>
> Naturally, I wouldn't be investing energy into
> reenginering XSLTC if I didn't believe a worthwhile outcome
> would result.
>
> I will continue to post information about XSLTC-2
> at my website, but I strongly feel it inaproppriate to
> continue discussing it at this forum. That's why I had asked
> people interested in progress/use of XSLTC-2
> to contact me directly.
>
> I am sorry if this explanation disappoints some of you
> but I hope my results will end up being useful
> to XML/Java users.
>
> --Jacek
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
Re: experimental XSLTC-2, a clarification
Posted by Torsten Curdt <tc...@dff.st>.
As a lurker on xalan and being a cocoon guy I am quite disappointed to
hear this... (especially after the latest performance measurements;)
Do you just don't want to port your changes back into the current version
or do you want complete freedom of work without anyone interfearing with
you...
IMHO this can be bad for the general progress in the long run. This
reminds me a little on the samba/samba-ng controversy (I am far from
knowing what really happend there - just heard some things)
But wouldn't it be much more desirable to create a new branch or even a
new repository (let's say XSLTC-2) in the apache CVS?
Let's keep our force together....
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org