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

compiled stylesheets was Re: [xsl] Re: RE: creating a string of repeated charactors


Subject: compiled stylesheets was Re: [xsl] Re: RE: creating a string of repeated charactors
From: "cutlass" <cutlass@xxxxxxxxxxx>
Date: Mon, 16 Jul 2001 10:45:23 +0100

----- Original Message -----
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
To: <timw@xxxxxxx>
Cc: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 16, 2001 10:03 AM> This template is "verbose" by
necessity -- it solves the ***general*** case, when
> neither the filling characters, nor an upper limit for the length are nown
in
> advance.
>
> It is also quite space-consuming (and time) -- because the string length
is doubled
> until a larger string is constructed, this will use twice as much memory,
as
> necessary for the resulting string.
>

i agree with Dimitre that there are much better ways of implementing most of
the exslt templates with respect to memory use, though the javascript
implementations are fairly optimized.

as a rule of thumb the exslt templates are firstly created to illustrate
clearly 'what is happening' ( i think ...), we hope that these functions
will eventually be supported by the parsers or maybe we provide compiled
versions of templates; that 'plug in' to parser structure.

The days of optimizing from build start to end are nearly over ( gasp should
i be saying this.....) in a world where things are still slow with 1 gig
chip and 500 meg RAM, i am convinced that hardware advances ( and network )
will far outstrip code optimisation, and us programmers shall get lazier and
lazier.. due to sheer ability to be lazy ( or not enough time to be super
efficient ), not to mention that overall lifetime of any particular software
is quite short lived ( at least the crap i write ).

so using the lazy=efficient algorithim i would like to kick off debate on
compiled stylesheets, as a possible 1st order standard optimisation here are
some keypoints;

- compiled stylesheets can occur as a translet, as defined by Sun's XSLTC
effort, which compiles down the stylesheet into a java class, whereby the
transformation happens with the assistance of a runtime library.
- i would like to see a standard effort which is independant to java, are
there any out there ?
- is there any effort at the moment standardizing the integration of
compiled stylesheets at runtime with major parsers?
- would the use of TRAX be the first port of call in integrating compiled
stylesheets, as TRAX seems to be adopted by major parsers ?

due to this dependance on runtime library, i cannot see a standard method of
adoption, unless of course the Sun runtime is incorporated into java xslt
parsers, but this still doesnt solve language independance problem  ( for
those that do not want to work within java framework ).

compiled stylesheets offer an interesting advantage in this situation, by
gaining a significant performance gain, with clear verbose code, without the
need ( this is the lazy part) to be overly concerned of optimisation.

the demonstration of Sun's compiled stylesheets at XSLT UK was very
interesting but there probably needs to be a meta data format that will
allow for the standard integration of these stylesheets, maybe we will make
another module for the exslt effort..... in a world where web services may
deliver not just payloads of data, i can see payloads consisting of compiled
stylesheets upgrading local applications ( and not necc being xslt ).

any thoughts,

jim fuller


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread
Keywords