Re: EXSLT 1.0 Proposed List

David,

Adding to Uche's comments, while the primary objective is *not* to 
create an easier migration path to XSLT 2.0, the very fact that XSLT 
2.0-esque functionality is being proposed, coupled with the module-based 
format does allow for a step-based migration path. 

For example, let's say a year after implementing EXSLT 1.0 it is 
discovered by a particular group that much of the difference between 
EXSLT 1.0 and XSLT 2.0 is something that they have determined to be of 
value.  The fact that they are already a good portion of the the way 
there makes the path to XSLT 2.0 that much easier.  The fact the EXSLT 
1.0 is modularized makes the release path to a full EXSLT 1.0 processor 
*EXTREMELY* nice.

All of these are good things that will bring about a greater adoption 
rate of XSLT, no matter what the version.

Uche Ogbuji wrote:

>Pawson, David wrote:
>  
>
>>    > What motivation can there be to implement something as a 
>>    1.0 extension 
>>    > when it is available as 2.0 base functionality?
>>    >   
>>    
>>    As you can see in the legend, there is a lot in EXSLT *now* 
>>    that is also available in XSLT 2.0.  Why did people 
>>    implement those extensions?
>>
>>Because of the timing Uche? 
>>XSLT 2.0 is nearing rec status.
>>  
>>    
>>
>
>What does the timing of XSLT2 have to do with EXSLT?  I for one will
>almost certainly never implement XSLT 2, and I know of a lot of other
>implementors who feel the same way.  In fact, right now it's easier to
>find XSLT 1 implementors who don't plan to move on to XSLT 2 than it is
>those who do.
>
>
>  
>
>>    Of course the answer is that implementing a handful of 
>>    useful functions/elements that happen to be similar to ones 
>>    available in XSLT 2.0 is *much* simpler than implementing 
>>    XPath 2.0 and XSLT 2.0 itself. 
>>Agreed. 
>>    A hell of a lot easier.  Several implementors, including 
>>    me, have expressed the preference to move the most useful 
>>    and sensible extensions into EXSLT so that people don't 
>>    have to deal with the XPath/XSLT 2.0 mess if they don't want to.
>>
>>
>>*slowly* I'm becoming a convert to 2.0. Yes, there is a mess in there,
>>but at the same time there are some very useful bits too.
>>  
>>    
>>
>
>Well, that's fine for you, buit for those of us not willing to bother
>with the mess, EXSLT should provide some of the more useful stuff in
>XSLT 1.0.
>
>XSLT 2 could have done a lot of useful things incrementally (the
>node-set/RTF issue, grouping, dates...) without making the enormous leap
>in complexity represented by XSLT 2 (mostly by virtue of XPath 2).  I
>think EXSLT can and should offer that incremental step.
>
>
>  
>
>>Useful and sensible as the criteria? I guess that makes sense,
>>even if its 4suite on the route to an XSLT 2.0 implementation
>>it will allow for a cleaner migration?
>>
>>  
>>    
>>
>
>I don't know who is planning to implement XSLT 2 in 4Suite.  I'm not
>sure I want anyone to.  4Suite's big enough.
>
>  
>
>>Do you think other implementations would show similar levels of interest?
>>Daniel, Apache, Oleg?
>>
>>Spec'd without implementations could appear silly.
>>  
>>    
>>
>
>EXSLT originally had no implementations until I whipped up 4EXSLT.
>
>This is a spec built on practical needs and working with existing
>material.  As such I expect it will invite implementations.
>
>
>  
>