Re: Re: EXSLT 1.0 Proposed List

> 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.

Glad to hear this! I will be very much interested in the extensions to XSLT 
2.0.

> In summary, I don't see why the XSLT1 camp has to religiously convert
> the XSLT2 camp, or vice versa.
-------------------------^^^^^^^^^^^

Glad to hear this -- let's forget the unsubstantiated statements about XSLT 
2.0/XPath 2.0 from the previous posts and look towards the future.


Cheers,
Dimitre Novatchev

"Uche Ogbuji" <[email protected]> wrote in message 
news:[email protected]...
> 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.
>
>
> -- 
> Uche Ogbuji                               Fourthought, Inc.
> http://uche.ogbuji.net                    http://fourthought.com
> http://copia.ogbuji.net                   http://4Suite.org
> Articles: http://uche.ogbuji.net/tech/publications/