Re: Compiled Transformation Function Library

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 <[email protected]> wrote:
> On Tue, 19 Jun 2007 16:19:22 -0600, M. David Peterson <[email protected]>
> 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
> [email protected]
> http://www.exslt.org/list
>