This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: hardware xml / xslt


> > It's certainly possible in theory. However, I think a very 
> > considerable amount of the work that's currently done at 
> compile time 
> > would end up being done at link time, so linking the modules 
> > dynamically for each transformation might not give great 
> performance.
> 
> I was not thinking of linking them dynamically. When 
> compiling the primary XSL, you know what includes are 
> present. I was wondering if there was some way to statically 
> link the includes so it would mimic a fully compiled XSL, but 
> still keep it separate for memory purposes. Of course, I 
> don't know how to do this :)
> 
Well, it could be done, but it would definitely need some fixup (or
linking) at run-time. Consider: a stylesheet module C.xsl might be
imported by both A.xsl and by B.xsl. C.xsl contains a reference to a
global variable $x which has different declarations in A.xsl and B.xsl.
So you need a compiled representation of C.xsl that works whether you
are using A.xsl or B.xsl; this means that the variable reference $x is
going to have to be bound to the declaration of $x at link time, not at
compile time.

> >
> > I'm currently working on a different approach, which is to 
> make sure 
> > that all the unused variables, templates etc from imported 
> modules are 
> > discarded from the compiled stylesheet. This creates a few problems 
> > for things like saxon:evaluate(): which actually confirms 
> the reasons 
> > some implementors were reluctant to put an evaluate() 
> function in the 
> > spec.
> 
> Isn't this totally dependant on the source XML? How can you 
> know which variables and templates will be unused if you are 
> making the decision at compile time? Wouldn't you need the 
> source and any XML brought in through the document function?
> 
> I assume everyone strives to only write XSL that has what 
> they need. I don't always need every template for every 
> transformation, but when I need it, I need it. Most likely, I 
> am missing something here??

I think that it's quite common to import large general-purpose
stylesheet modules that contain libraries of named templates or global
variables, few of which are actually used by the importing stylesheet.
Ensuring that the compiled stylesheet contains only the ones that are
used gives a big reduction in memory.

It also scuppers the Saxon extension to select named templates
dynamically....

Discarding template rules that are overridden is also an interesting
possibility.

Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com  


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]