[Home]  [List]  [News]  [Docs]  [FAQ]  [Downloads]  [Resources]  [About]
Search :
/Home /List

list4xt : Mailing list for the XT users community.

[list4xt] Re: saxon:evaluate

Subject: [list4xt] Re: saxon:evaluate

User: Website

From: Paul Tchistopolskii (pault12@pacbell.net)
Date: 28/08/2000 - 17:06


> > From: James Clark
> >
> > > Paul T wrote:
> > >
> > > > If there is any probability to get xt:evaluate() in the XT core -
> > > > I'l dance and be the happiest person in the world.
> > >
> > > I would fight very hard to keep xt:evaluate out of XT (and XSLT). I
> > > think it misconceived and completely at variance with the design of
> > > XSLT.
> >
> > Why?
>
> The main reason is that it inhibits compilation.

1. So does document('') and I think 'calculatable key'.

2. It makes compilation a bit more complex.
It is similiar to Class.forName() dynamic loading
in Java. Java to C compilers have
the ways to work this limitation around.
I mean that even C has no dynamic loading
at all, but Java has - existing Java2C compilers
are capable of translating this widely used
Java construction into C.

3. I hardly understand how can we judge on
impact of xt:evaluate on XSLT compilers
before we get at least one XSLT compiler
implemented. SAXON ( which has saxon:evaluate )
has a compiler implemented, but I think when
saying 'compilation' - SAXON's compiler should
not count.
 
4. "Generate stylesheet on the fly" technique
is clear compilation killer, but this technique
is supported with namespace - alias. Why the
same could not be done with xt:evaluate ?

Rgds.Paul.

--
Mailing list for the XT users community.     (http://onecalbank.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)



Archive générée par hypermail 2b28 le 06/11/2001 - 11:46 CET

webmaster@4xt.org