Re: Re: Re: EXSLT 1.0 Proposed List

Hi there,

My opinion is just the one of an average user. EXSLT is the only way for 
me to bring a couple of features I miss when I use XSLT 1.0

At first I was thrilled by XSLT 2 (even more after reading Jeni's book 
on it) but then I did realise that the XSLT implementation I use 
(4suite) does not offer XSLT 2 support and as Uche suggests will never do.

I am entirely cool with that because I also realised that I could do the 
same business with XSLT 1.0/EXSLT and a toolkit such as Amara. Guess 
what, I did also realise that it was a better combination because XSLT 
should not meant to carry all the logic XSLT 2 tries to bring.

It was the time I was workig with C# and .NET for my job and Python + 
Amara for my personal projects. Well, I would welcome more XSLT 2 in an 
environment such as J2EE or .NET because programming languages such as 
Java or C# do not have the same flexibility as Python, Perl or Ruby. To 
me it looks like XSLT 2 is more an attempt at fixing the lack of 
flexibility of the former. (Note that I do not mean to say C# or Java 
are weak or bad languages but I suspect their static nature is the root 
of their lack of flexibility in our context).

XSLT is templating language and should stick to that. XSLT 2 should have 
been given a different name because it aims at much much different target.

Note that If I wanted to use XSLT 2 with Python, I would try IronPython 
and Saxon.NET from M. David. However I still haven't really reached a 
point where It was better design to put that much logic inside my 
stylesheet anyway.

My 2 cents...

- Sylvain

Dimitre Novatchev a écrit :
>> I can definitely see your side of things and agree, comments from Dr. Kay 
>> would bring GREAT value to this conversation.
> 
> Another GREAT specialist in the field is certainly Jeni Tennison -- she 
> played a more important role for EXSLT than anyone else. She is also on the 
> XSLT 2.0 WG.
> 
>> From both yours and my standpoint, we have the tools we both want and need 
>> in regards to Saxon/Saxon.NET.
> 
> So, this shows that there is definitely a group of XSLT users, for whom 
> EXSLT for XSLT 2.0 will be useful, but who do not need and do not intend to 
> use EXSLT for XSLT 1.0.
> 
> We must be well aware of this fact. This was not the situation when the 
> EXSLT (as we know today) was being conceived.
> 
> Cheers,
> Dimitre Novatchev
> 
> "M. David Peterson" <[email protected]> wrote in message 
> news:[email protected]...
>> Hi Dimitre,
>>
>> I can definitely see your side of things and agree, comments from Dr. Kay 
>> would bring GREAT value to this conversation.  From both yours and my 
>> standpoint, we have the tools we both want and need in regards to 
>> Saxon/Saxon.NET.  I also feel we have reason to believe that Microsoft 
>> will deliver at very least an XSLT 2.0-basic processor in the not too 
>> distant future.  But of course, this is pure speculation.
>>
>> On the other side of the coin, I think there are enough vendors out there 
>> who have balked at an XSLT 2.0 processor... at least for now... but have 
>> expressed interest in something similar to what John and Uche have 
>> proposed.  As such, I feel this provides *tremendous* value.
>>
>> I do recognize that the possibility exists for fragmentation.  I don't 
>> think I have *anywhere* near enough experience to give a valuable analysis 
>> in this regard, and as such leave it to those folks who do.
>>
>> Dimitre Novatchev wrote:
>>
>>> My *personal* opinion is that if I can develop XSLT 2.0 applications with 
>>> even the current XSLT 2.0 processors and IDEs for them, I'd never use 
>>> EXSLT for XSLT 1.0 unless I'm paid to do this.
>>>
>>> Even after a group of people makes a big effort and produces a library 
>>> that make XSLT 1.0 + EXSLT very *slightly* resemble XSLT 2.0.
>>>
>>> On the other side, I will readily use valuable EXSLT extensions for XSLT 
>>> 2.0 such as the
>>>
>>>   xxx:memo-function attribute
>>>
>>> and the
>>>
>>>   xxx:compiled-stylesheet element.
>>>
>>> Another group of useful extensions to XSLT 2.0 would be a module of 
>>> functions that implement retrospectiveness (although FXSL already provides 
>>> such functions).
>>>
>>> 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").
>>>
>>> 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.
>>>
>>> I strongly believe that EXSLT is and should be the result of collective 
>>> effort, not based just on single opinions and believes.
>>>
>>>
> 
> 
> 
> _______________________________________________
> exslt mailing list
> [email protected]
> http://www.exslt.org/list