& XSLT On Tue, 19 Jun 2007 16:19:22 -0600, M. David Peterson <m.david@[...].com>   
wrote:

>  I think that specifying such an extension falls exactly into the
>  subject area of EXSLT, unfortunately until no one has proposed a
>  specification.

One thing I should point out with this: This feature in particular (the  
ability to link to precompiled XSLT modules within new transformation  
files) both can and should be completely portable across XSLT versions, or  
in other words, this is not the kind of feauture that would have to be  
developed as part of a larger EXSLT 2.0 specification and instead as  
either its own extension module, or more appropriately, as part of the  
Dynamic module.

Of course this brings up what I consider to be a fair question: Does EXSLT  
really need to be versioned?  Couldn't one just state (like they do now)  
"We provide support for EXSLT module X and Z but not Y?  It seems to me  
that one of the primary reasons why attempting to develop an EXSLT  
v.Next() specification has been so difficult to do is that 1) It's a *TON*  
of work, 2) There are too many suggested modules that cross over or come  
extremely close to the XPath 2.0 line and in some cases re-introduce  
functionality that is part of the XSLT 2.0 spec, and as such, there are  
those folks who simply have no interest in developing support for and as  
such, 3) the motivation to develop support for "EXSLT 2.0" (or whatever it  
would be termed) is diminished which has an immediate and direct impact on  
the motivation to finalize the specification itself.

Of course I'm not suggesting that EXSLT should "leave the XPath 2.0 and  
XSLT 2.0 space alone" by not developing modules that mimic the  
functionality introduced in X^2v.2, and instead that by decoupling things  
 from an effort to develop, finalize, and publish an official EXSLT  
recommended specification, replacing it instead with one-off efforts to  
define and develop each extension, the chances of each extension being  
both completed and implemented is far greater than it would be if done as  
a complete set, and "all or nothing" type approach which, to me anyway,  
seems to go against the entire purpose of an *extension* in the first  
place: It's not part of the official spec... It's an *extension* to that  
spec; an enhancement considered to be helpful to a broad base of XSLT  
developers after the official specification was released.

In this regard one could easily develop extension familys; extensions with  
last names, if you will, that specify "Hi, my name is  
dyn:compiled-module() of the XSLT 1.0 clan which means I can be  
implemented on a any processor that claims support for either XSLT 1.0 or  
2.0."  Maybe its just me, but it seems as if taking things at this level  
is exactly the way to get things moving forward again, a side-effect of  
which would be a built-in filtration system that utilizes motivation for  
implementation as the determining factor in regards to what gets specified  
and what does not.

Thoughts/comments/criticisms/suggestions?

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155
_______________________________________________
exslt mailing list
list@[...].org
http://www.exslt.org/list