& XSLT Uche and myself just met up over XML Prague and proposed a number of
thoughts we will be putting to the larger EXSLT gang. I will fold in
these thoughts as well.

expect some movement on EXSLT in the near-med term future.

cheers, Jim Fuller

On 6/20/07, M. David Peterson <m.david@[...].com>  wrote:
>  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
> 
_______________________________________________
exslt mailing list
list@[...].org
http://www.exslt.org/list