Re: Re: EXSLT 1.0 Proposed List
Uche Ogbuji <[email protected]>
| Newsgroups | gmane.text.xml.xslt.extensions |
|---|---|
| Message-ID | <[email protected]> |
Dimitre Novatchev wrote:
> 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").
>
Of course that's personal opinion. So is yours and so would be Mike's
or Jeni's. That's not really the point.
> 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.
>
That almost certainly won't sway me any more than I expect my opinion to
sway Mike or you. Again, I don't find much use in this line of pursuit.
> I strongly believe that EXSLT is and should be the result of collective
> effort, not based just on single opinions and believes.
>
Actually we *do* have a collective effort going to cement EXSLT 1.0.
Like it or not, I'm far from acting alone. Furthermore, you can read in
this very forum (and elsewhere) that others agree with me that a set of
extensions for XSLT 1.0 is still valuable, so here we are doing just
that. I'm sorry if it puts you off.
But I also don't see that it should be a problem for you. The whole
point of the current burst of activity here is to settle on a
(reasonably) final set of extensions for XSLT 1.0. Once we have that
the decks are a bit more clear, and we should be able to support the
XSLT1 camp *and* the XSLT2 camp without complete chaos as a result.
EXSLT did start as a set of extensions for XSLT 1.0, and I would think
there is no harm even to XSLT2 afficionados if we bring that effort to a
clear milestone (rather than the vague sort of trailing-off we currently
have). A set of extensions for XSLT2, as you indicate would be a very
different beast. Surely you don't need most of the current EXSLT "0.9"
extension modules cluttering up the XSLT2 space with stuff that already
had functional equivalents in XSLT2. Let's get to a clean separation
point where we can maintain two sets of modules, each of which closely
fits the respective version of XSLT.
In summary, I don't see why the XSLT1 camp has to religiously convert
the XSLT2 camp, or vice versa. The idea here is to provide options for
both.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://fourthought.com
http://copia.ogbuji.net http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/