Re: Re: EXSLT 1.0 Proposed List

I agree.  It has become fairly obvious to me over the last 6 months 
overall, and the last 30-45 days more specifically that there is a 
fairly large camp of folks who, at this stage of the game, have no 
interest in an XSLT 2.0 implementation, as what XSLT 2.0 brings to them 
in its entirety is not something they see as beneficial.  Its a sticking 
point that I don't think will be overcome, at least not anytime in the 
foreseeable future.

That said, there's a *TON* of desirable pieces of the (XPath/XSLT) 2.0 
family that have found there way into John's and Uche's proposal.  And 
it seems that there's is evidence that suggests that at least four 
separate and major camps are willing to move forward with an EXSLT 1.0 
implementation when this comes into "Final Rec" status from the EXSLT group.

It seems to me that the devout XSLT 2.0  group of folks have two choices.

 * Fight it and create separation between the two camps, ultimately 
doing more damage than good to XSLT as a language,  no matter the 
version or family of extensions.

 * Accept it and work with the EXSLT group to ensure a clear message is 
created, a migration path from EXSLT 1.0 to XSLT 2.0-Basic (theres 
already a Basic to SA no need to create another on) established, and 
then an EXSLT 1.0 for XSLT 2.0 specification created and a 
recommendation from the EXSLT group brought-to-pass, which includes the 
pieces that have been proposed thus far, and any others that may be 
brought forward as extensions to the XSLT 2.0 recommendation.

Given that EXSLT 1.0 as it has been recently proposed has enough support 
to move forward no matter what, I can't see any benefit and a *WHOLE 
BUNCH* of harm in point one.  As such, I personally plan to work with 
this group of folks in any capacity necessary to ensure that the 
collective points contained in point two can be achieved.

To me anyway, its the only choice that makes any sense.

---
/m

Uche Ogbuji wrote:

>Dimitre Novatchev wrote:
>  
>
>>I should very definitely express the respect I have towards Uche Ogbuji and 
>>his XSLT 1.0 + EXSLT related activities. At the same time, I can only accept 
>>as a personal opinion that is not absolutely true, Uche's statements about 
>>XSLT 2.0 ("painful excess") and XPath 2.0 ("is a mess").
>>  
>>    
>>
>
>Of course that's personal opinion.  So is yours and so would be Mike's
>or Jeni's.  That's not really the point.
>
>
>  
>
>>To be objective we need to hear the opinion of people that are in the heart 
>>of XSLT 2.0 and XPath 2.0 design, such as Michael Kay.
>>  
>>    
>>
>
>That almost certainly won't sway me any more than I expect my opinion to
>sway Mike or you.  Again, I don't find much use in this line of pursuit.
>
>  
>
>>I strongly believe that EXSLT is and should be the result of collective 
>>effort, not based just on single opinions and believes.
>>  
>>    
>>
>
>Actually we *do* have a collective effort going to cement EXSLT 1.0.  
>Like it or not, I'm far from acting alone.  Furthermore, you can read in
>this very forum (and elsewhere) that others agree with me that a set of
>extensions for XSLT 1.0 is still valuable, so here we are doing just
>that.  I'm sorry if it puts you off.
>
>But I also don't see that it should be a problem for you.  The whole
>point of the current burst of activity here is to settle on a
>(reasonably) final set of extensions for XSLT 1.0.  Once we have that
>the decks are a bit more clear, and we should be able to support the
>XSLT1 camp *and* the XSLT2 camp without complete chaos as a result. 
>EXSLT did start as a set of extensions for XSLT 1.0, and I would think
>there is no harm even to XSLT2 afficionados if we bring that effort to a
>clear milestone (rather than the vague sort of trailing-off we currently
>have).  A set of extensions for XSLT2, as you indicate would be a very
>different beast.  Surely you don't need most of the current EXSLT "0.9"
>extension modules cluttering up the XSLT2 space with stuff that already
>had functional equivalents in XSLT2.  Let's get to a clean separation
>point where we can maintain two sets of modules, each of which closely
>fits the respective version of XSLT.
>
>In summary, I don't see why the XSLT1 camp has to religiously convert
>the XSLT2 camp, or vice versa.  The idea here is to provide options for
>both.
>
>
>  
>