[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT 2.1: Nestable sequences or sequence references?


Subject: Re: [xsl] XSLT 2.1: Nestable sequences or sequence references?
From: Florent Georges <lists@xxxxxxxxxxxx>
Date: Tue, 9 Dec 2008 15:14:03 +0100 (CET)

Dimitre Novatchev wrote:

> On Mon, Dec 8, 2008 at 2:05 AM, Michael Kay wrote:

> > (a) nested sequences

> As I am tired of asking for (a) and learning from all prior
> experience, I absolutely don't have any illusions these will be
> part even of XSLT 4.

> Therefore, Isn't it high time for *EXSLT 2*?

  I think so (for some time now.)  Unfortunately, the EXSLT
community is not so responsive for now (XProc is not so innocent
here :-p.)  Actually I developed a few extensions and I was
naturally tempted to include the string "exslt2" somewhere in the
namespace URI used.

  I understand your concerns about the adoption of new features in
XSLT 2.1, but I don't think this is desperate.  I think the best
we can do is imlplementing the extensions we need as individual
projects.  The availability of existing implementations could help
discussions about an hypothetical EXSLT2.  And I feel that EXSLT2
is the best way to have something accepted by the WG.

> To the list of *nested sequences* and *references* I would also
> add *memoisation*.

> [...]

> Florent has written his Java implementation and it is a matter
> of days for a C# implementation of something similar ...  :( to
> surface out...

  Just to be sure, my implementation is for nested sequences, not
memoisation.

> By not standardizing we will very soon find ourselves with a
> number of incompatible definitions of such functions and will
> have to face all the resulting portability issues.

  I agree.  But we can maybe try to have common XSLT APIs for
similar extensions (I never use an extension without defining its
own XSLT module that exposes a public API through XPath functions,
hiding the extension machinery mecanism.)

  If those extensions are useful and used, new use cases will show
up, and specifications will refine...  And that mecanism is the
best advantage for adoption by a body like W3C.

> Let's be realistic and pragmatic and not wait in the next ten
> years for a committee blessing. We have EXSLT and EXSLT has
> worked well in the past and served real needs.

  Sure.  But the past showed also that they weren't opposed, by
complementary.  EXSLT helped to open new directions, to show some
real-world implementations of new features, and maybe more
important yet which one users were requesting for.  I am convinced
that something like EXSLT does facilitate adoption by the WG.

> I appeal to the EXSLT community to respond and provide the
> definitions of the above three features -- in the name of the
> ideas this movement (I still believe) stands for.

  I agree.  Even if I would have said the *XSLT 2.0* community...

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/


Current Thread
Keywords